软件需求分析英文课件：Chap 5-Req to Design

1、Elaboration Iteration 1-BasicsCh12. Requirements to Design IterativelyCh13. Logical Architecture and UML Package Diagrams Ch14.On to Object Design1Chapter 12. Requirements to Design IterativelyObjectivesQuickly motivate the transition to design activitiesContrast the importance of object design skil

2、l versus UML notation knowledge2Iteratively Do the Right Thing, Do the Thing Right Requirement capture and OO analysis has focused on Do the Right Thing Object design focus on Do the Thing Right Provoke Early Change Iterative and evolutional methods “embrace change” Early programming, tests, and dem

3、os help provoke the inevitable changes early on Didnt All That Analysis and Modeling Take Weeks To Do? When one is comfortable with the skills of use case writing, domain modeling, and so forth, the duration to all the actual modeling is realistically just few hours or days3Chapter 13. Logical Archi

4、tecture and UML Package DiagramsObjectivesIntroduce a logical architecture using layers.Illustrate the logical architecture using UML package diagrams45What is Software Architecture?An architecture is the set of significant decisions about the organization of a software system, the selection of the

5、structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides th

6、is organization these elements and their interfaces, their collaborations, and their composition. BRJ996Software Architecture StyleFrank Buschmann的分类 面向模式的体系结构-卷17从混沌到结构 Layer Pipes and Filters Blackboard分布式系统 Broker(涉及“微核”和“管道-过滤器”)交互系统 Model-View-Controller Presentation-Abstraction-Control适应性系统 Re

7、flection MicrokernelLayer过程调用不同元素组合内核层可用系统基础实用层SA模式(1) -分层8每一层为上层提供服务，并作为下层的客户层只对邻层可见连接件定义了层间交互的协议支持递增抽象层的设计支持复杂问题的分解和增量式步骤序列的实现支持软件复用：体现在每层只影响邻层，所以每层可采用不同的实现方法应用分层通讯协议中，诸如OSI/ISO的分层通讯模型计算机网络协议组，如TCP/IPOS9SA模式(1) -分层优点缺点支持抽象递增的设计(复杂系统的递增分解)并不是每个系统都能分层的(即使一个系统的逻辑结构是层次化的，但出于性能的考虑，往往要将一些低级和高级的功能综合起来的)容

8、易扩展(每层只影响邻层)效率的降低(通过若干层的转换带来的)支持复用(如果对邻层的接口相同，则在同一层中使用不同的实现)抽象层次方法难以选择(特别是要选取合适的、正确的方法就更难)SA模式(1) -分层10过滤器过滤器过滤器过滤器过滤器过滤器管道管道管道管道管道管道管道Pipe&FilterSA模式(2) -管道-过滤器1112构件：过滤器（filter）是数据加工处理的功能模块，并将处理后的结果在输出端输出。连接件：管道（pipe）起信息流的导管作用。过滤器都有输入/输出集合，构件从输入处读取数据流，在输出处生成数据流。过滤器必须是独立的主体，无须知道输入/出管道的存在。但要对输入管道和输入

9、数据流进行限制。SA模式(2) -管道-过滤器词法分析/扫描器语法分析/分析器语 义 分 析中间代码生成Unix shell: cat file|grep xyz|sort|uniqout 即找到含xyz的行，排序、取掉相同的行，最后输出编译器信号处理系统并行计算SA模式(2) -管道-过滤器13优点缺点系统行为易于理解由于该模式数据交换占用大量的空间，且数据传输占用系统的执行时间。所以，它不适应大量共享数据的应用设计支持并发计算过滤器是在输入/出有相应限制情况下，才能对输入进行批量转换处理。所以,不适用于交互式的应用程序较强的可维护性和可扩展性按照此模式，经常导致成为批处理的结构相对独立的过

10、滤器为性能(吞吐量、死锁)分析提供了方便由于构件不能共享全局状态。所以错误处理困难SA模式(2) -管道-过滤器14黑板共享数据知识源存储器计算直接存取Repositories (Blackboard)知识源知识源知识源知识源知识源知识源知识源控制器SA模式(3) -仓库与黑板15知识源：与特定应用相关的独立的知识包(parcel)，只有通过黑板来完成它们之间的交互黑板数据结构：求解问题的状态的数据，并按照层次来组织。知识源通过对黑板的修改来渐进式地达到问题的求解控制器：控制器承担着限制知识源对黑板的访问，防止两个知识源同时写黑板的某一空间。控制器完全由黑板状态驱动和决定。一旦黑板数据的改变需

11、要知识源的时候，控制器会及时通知知识源随即进行响应应用信号处理与模式识别领域用于具有松散-偶合实体对共享数据的存取16SA模式(3) -仓库与黑板优点缺点便于多个客户共享大量的数据对黑板数据结构的修改比较困难(要考虑不同的知识源对共享数据达成一致)方便于添加新的知识源应用程序系统复杂(因为需要一定的同步/加锁机制保证数据结构的完整性和一致性)SA模式(3) -仓库与黑板17What is the Logical Architecture? And Layers?The logical architecture is the large-scale organization of the sof

12、tware classes into packages, subsystems, and layers. A layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive responsibility for a major respect of the system Typical layers in an OO system includes User Interface Application Logic and Domain Objects Technical

13、Services Strict layered architecture (closed) Relaxed layered architecture (opened)18Layers shown with UML package diagram notation19Applying UML: Package DiagramsUML packages diagrams are often used to illustrate the logical architectures of a system the layers, subsystems, packages (in the Java se

14、nse). A layer can be modeled as a UML package. A UML package diagram provides a way to group elements. A UML packages can group anything: classes, other packages, use cases, and so on. It is common to want to show dependency (a coupling) between package so that developers can see the large-scale cou

15、pling in the system. A UML package represents a namespace a more general concept than simply a Java package or .NET namespaceSome UML tools can reverse-engineer package diagrams from code20Alternate UML approaches to show package nesting21Mapping Code Organization to Layers and UML PackagesMost popu

16、lar OO languages provide support for packagesJava, C#, C+, Python, , called namespaces in C# and C+).Java Example/ - UI Layer com.mycompany.nextgen.ui.swing com. mycompany.nextgen.ui.web / - Domain Layer com.mycompany.nextgen.domain.sales com.mycompany.nextgen.domain.payments / - Technical Service L

17、ayer com.mycompany.service.persistence22Guideline: Design with LayersLayer patterns are applicable to various domains Human Society: UN, Country, Province, City, County . Scientific Research: Universe, ., atom, quark Software system The essential ideas of using layers are simple: Organize the large-

18、scale logical structure of a system into discrete layer of distinct, related responsibilities, with a clean, cohesive separation of concerns such that the “lower” layers are low-level and general services, and the higher layers re more application specific. Collaboration and coupling is from higher

19、to lower layers; lower-to-higher layer coupling is avoided23Benefits of Using LayersIn general, there is a separation of concernsa separation of high from low-level services, and of application-specific from general services. This reduces coupling and dependencies, improves cohesion, increases reuse

20、 potential, and increases clarity.Related complexity is encapsulated and decomposable.Some layers can be replaced with new implementationsLower layers contain reusable functions.Some layers (primarily the Domain and Technical Services) can be distributed.Development by teams is aided because of the

21、logical segmentation.2425Common layers in an information system logical architectureDomain Layer vs. Application Layer; Domain ObjectsHow do we design the application logic with objects? A typical software system has UI logic and application logic, such as UI widget creation and tax calculation. We

22、could create one class called XYZ and put all the methods, for all the required logic, in that one class, it could technically work, but it isnt the recommended approach in the spirit of OO thinking.Creating software objects with names and information similar to the real-world domain, and assign app

23、lication logic responsibilities to them 26Relationship between the Domain Layer and Domain Model27Definition: Tiers, Layers, and PartitionsThe original notion of a tier in architecture as a logical layer, not a physical node, but the word has become widely used to mean a physical processing node, su

24、ch as the “client tier” The layers of an architecture represent the vertical slices, while partitions represent a horizontal division of relatively parallel subsystems of a layer 28Guideline: Dont Show External Resources as the Bottom Layer29Guideline: Cohesive Responsibilities; Maintain a Separatio

25、n of ConcernsThe responsibilities of the object in a layer should be strongly related to each other and should not be mixed with responsibilities of other layersObjects in the UI layer should focus on UI work Objects in the application logic or “domain” layer should focus on application logicUI obje

26、cts should not do application logic A Java Swing JFrame (window) object should not contain logic to calculate taxes or move a game piece Microsoft VB doesnt follow this rule, it makes the VB program difficult to maintain30Guideline: The Model-View Separation PrincipleThe Model-View Separation Princi

27、ple Don not connect or couple non-UI objects directly to UI objects. Do not put application logic in the UI object methods. The motivation for Model-View Separation To support cohesive model definition that focus on the domain processes, rather than on user interfaces To allow separate development o

28、f the model and user interface layers To minimize the impact of requirements changes in the interface upon the domain layer To allow new views to be easily connected to an existing domain layer, without affecting the domain layer To allow multiple simultaneous views on the same model object 31Connec

29、tion Between SSDs, System Operations, and Layers32Chapter 14. On to Object DesignObjectivesUnderstand dynamic and static object design modeling.Try agile modeling, or a UML CASE tool for drawing.33Three Ways For Developers To Design Objects CodeDesign-while-coding (Java, C#, ) ideally with power too

30、ls suc as refactoring. From mental model to code Draw, then codeDrawing some UML on a whiteboard or UML CASE tools, then switching to #1 with text-strong IDE Only draw Somehow, the tool generate everything from diagrams. Many a dead tool vendor has washed onto the shores of this steep island34Agile

31、Modeling and Lightweight UML Drawing To reduce drawing overhead and model to understand and communicate, rather than document. Try the simple agile modeling approach. Using lots of whiteboards or special white plastic static cling sheets covering large wall areas using markers, digital cameras, and printers to capture “UML as sketch” Modeling with others Creating several models in parallel35UML CASE Tools Wall-sketching and agile modeling doesnt imply the UML CASE tools arent usefulChoose a U