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

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

2、 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 demo

3、s 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 Archit

4、ecture and UML Package DiagramsObjectivesIntroduce a logical architecture using layers.Illustrate the logical architecture using UML package diagrams45Layers shown with UML package diagram notation6What is the Logical Architecture? And Layers?The logical architecture is the large-scale organization

5、of the software 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

6、Technical Services Strict layered architecture (closed) Relaxed layered architecture (opened)7What is Software Architecture?An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the syst

7、em 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 this organization these elements and their interfaces, their

8、 collaborations, and their composition. 8Software Architecture StyleFrank Buschmann的分类 面向模式的体系结构-卷19从混沌到结构 Layer Pipes and Filters Blackboard分布式系统 Broker(涉及“微核”和“管道-过滤器”)交互系统 Model-View-Controller Presentation-Abstraction-Control适应性系统 Reflection MicrokernelLayer过程调用不同元素组合内核层可用系统基础实用层SA模式(1) -分层10每一层

9、为上层提供服务，并作为下层的客层只对邻层可见连接件定义了层间交互的协议支持递增抽象层的设计支持复杂问题的分解和增量式步骤序列的实现支持软件复用：体现在每层只影响邻层，所以每层可采用不同的实现方法应用分层通讯协议中，诸如OSI/ISO的分层通讯模型计算机网络协议组，如TCP/IPOS11SA模式(1) -分层优点缺点支持抽象递增的设计(复杂系统的递增分解)并不是每个系统都能分层的(即使一个系统的逻辑结构是层次化的，但出于性能的考虑，往往要将一些低级和高级的功能综合起来的)容易扩展(每层只影响邻层)效率的降低(通过若干层的转换带来的)支持复用(如果对邻层的接口相同，则在同一层中使用不同的实现)抽象

10、层次方法难以选择(特别是要选取合适的、正确的方法就更难)SA模式(1) -分层12过滤器过滤器过滤器过滤器过滤器过滤器管道管道管道管道管道管道管道Pipe&FilterSA模式(2) -管道-过滤器1314构件：过滤器（filter）是数据加工处理的功能模块，并将处理后的结果在输出端输出。连接件：管道（pipe）起信息流的导管作用。过滤器都有输入/输出集合，构件从输入处读取数据流，在输出处生成数据流。过滤器必须是独立的主体，无须知道输入/出管道的存在。但要对输入管道和输入数据流进行限制。注意：将每个过滤器的输入/出限制为单一的，则管道-过滤器退化为顺序批处理系统(Batch sequentia

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

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

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

14、ercallServicecreateRequestMicrokernalexecuteMechanisminitCommunicationfindReceivercreateHandlesendMessagecallInternalServercalls servicesend requestInitializes communicationcallsactivatesSA模式(4) -微核(microkernal)20微核：封装了应用的基本服务。具有支持其它构件在一个独立进程中运行时互相通讯的功能；负责维护资源，如文件、进程等；提供其它构件存取其功能的接口。内部服务器：实现了在微核中不能实

15、现的核心功能(出于复杂性的考虑)每个外部服务器：是一个独立的进程，即应用程序平台，它通过微核的接口获得的机制实现自己的基本功能客户机通过使用微核提供的通讯能力与外部服务器通讯一个微核系统可被看成集成了其它应用平台的公共应用支撑平台应用OS，诸如MS-Windows：核心包括进程和线程的管理，低级I/O，点到点通讯服务部分DBMS，诸如MKDE(Microkernel Database Engine)，微核提供物理数据存取，事务管理等21SA模式(4) -微核(microkernal)优点缺点可移植性(微核不移植和移植两种情况)性能(微核支持不同的视图，与只提供特定视图的系统相比，一般性能要低)

16、适应性和可扩展性(只需填加一个外部服务器)设计和实现的复杂性策略与机制的分离(微核提供机制，外部服务器实现策略)SA模式(4) -微核(microkernal)22Applying UML: Package DiagramsUML packages diagrams are often used to illustrate the logical architectures of a system the layers, subsystems, packages (in the Java sense). A layer can be modeled as a UML package. A UM

17、L 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 coupling in the system. A UML package represents a nam

18、espace a more general concept than simply a Java package or .NET namespaceSome UML tools can reverse-engineer package diagrams from code23Alternate UML approaches to show package nesting24Guideline: Design with LayersLayer patterns are applicable to various domains Human Society: UN, Country, Provin

19、ce, City, County . Scientific Research: Universe, ., atom, quark Software system The essential ideas of using layers are simple: Organize the large-scale logical structure of a system into discrete layer of distinct, related responsibilities, with a clean, cohesive separation of concerns such that t

20、he “lower” layers are low-level and general services, and the higher layers re more application specific. Collaboration and coupling is from higher to lower layers; lower-to-higher layer coupling is avoided25Using layers helps address several problemsSource code changes are rippling throughout the s

21、ystem many parts of the systems are highly coupled.Application logic is intertwined with the user interface, so it cannot be reused with a different interface or distributed to another processing node.Potentially general technical services or business logic is intertwined with more application-speci

22、fic logic, so it cannot be reused, distributed to another node, or easily replaced with a different implementation.There is high coupling across different areas of concern. It is thus difficult to divide the work along clear boundaries for different developers.2627Common layers in an information sys

23、tem logical architectureBenefits 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 potential, and increases clarity.Re

24、lated 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 logical segmentation.28Guideline: Co

25、hesive Responsibilities; Maintain a Separation 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” l

26、ayer should focus on application logicUI objects 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 maintain29Mapping Code Organization to Laye

27、rs and UML PackagesMost popular 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.paym

28、ents / - Technical Service Layer com.mycompany.service.persistence30Domain 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 could create one

29、 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 application logic r

30、esponsibilities to them 31Relationship between the Domain Layer and Domain Model32Definition: 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, such as the “clien

31、t tier” The layers of an architecture represent the vertical slices, while partitions represent a horizontal division of relatively parallel subsystems of a layer 33Guideline: Dont Show External Resources as the Bottom Layer34Guideline: The Model-View Separation PrincipleThe Model-View Separation Pr

32、inciple 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 developme

33、nt of 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 35Co

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

35、 tools 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 island38Agile 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 sp