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

1、Elaboration Iteration 1-BasicspCh12. Requirements to Design IterativelypCh13. Logical Architecture and UML Package Diagrams pCh14. On to Object Design1Chapter 12. Requirements to Design Iterativelyo Objectivesn Quickly motivate the transition to design activitiesn Contrast the importance of object d

2、esign skill versus UML notation knowledge2oIteratively Do the Right Thing, Do the Thing Right nRequirement capture and OO analysis has focused on Do the Right Thing nObject design focus on Do the Thing Right oProvoke Early Change nIterative and evolutional methods “embrace change” nEarly programming

3、, tests, and demos help provoke the inevitable changes early on oDidnt All That Analysis and Modeling Take Weeks To Do? nWhen 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

4、 13. Logical Architecture and UML Package Diagramso Objectivesn Introduce a logical architecture using layers.n Illustrate the logical architecture using UML package diagrams45: RegisterenterItem(itemID, quantity): ProductCatalogspec = getProductSpec( itemID )Require-mentsBusiness ModelingDesignSamp

5、le UP Artifact RelationshipsVisionGlossaryThe logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec.Domain Model*SupplementarySpecificationUse-Case ModelRegister.makeNewSale()enterItem(.).ProductCatalog.getProductSpec(.).11class diagrams(a s

6、tatic view)interaction diagrams(a dynamic view)UIpackage diagramsof the logical architecture(a static view)DomainTech ServicesDesign ModelWhat is Software Architecture?oAn architecture is the set of significant decisions about the organization of a software system, the selection of the structural el

7、ements 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 this organizati

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

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

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

11、入处读取数据流，在输出处生成数据流。o过滤器必须是独立的主体，无须知道输入/出管道的存在。但要对输入管道和输入数据流进行限制。SA模式(2) -管道-过滤器词法分析/扫描器语法分析/分析器语 义 分 析中间代码生成Unix shell: cat file|grep xyz|sort|uniqout 即找到含xyz的行，排序、取掉相同的行，最后输出编译器o信号处理系统o并行计算SA模式(2) -管道-过滤器13优点优点缺点缺点系统行为易于理解由于该模式数据交换占用大量的空间，且数据传输占用系统的执行时间。所以，它不适应大量共享数据的应用设计支持并发计算过滤器是在输入/出有相应限制情况下，才能对输

12、入进行批量转换处理。所以,不适用于交互式的应用程序较强的可维护性和可扩展性按照此模式，经常导致成为批处理的结构相对独立的过滤器为性能(吞吐量、死锁)分析提供了方便由于构件不能共享全局状态。所以错误处理困难SA模式(2) -管道-过滤器14黑板共享数据知识源存储器计算直接存取Repositories (Blackboard)知识源知识源知识源知识源知识源知识源知识源控制器SA模式(3) -仓库与黑板15o知识源：与特定应用相关的独立的知识包(parcel)，只有通过黑板来完成它们之间的交互o黑板数据结构：求解问题的状态的数据，并按照层次来组织。知识源通过对黑板的修改来渐进式地达到问题的求解o控制

13、器：控制器承担着限制知识源对黑板的访问，防止两个知识源同时写黑板的某一空间。o控制器完全由黑板状态驱动和决定。一旦黑板数据的改变需要知识源的时候，控制器会及时通知知识源随即进行响应o应用n信号处理与模式识别领域n用于具有松散-偶合实体对共享数据的存取16SA模式(3) -仓库与黑板优点优点缺点缺点便于多个客户共享大量的数据便于多个客户共享大量的数据对黑板数据结构的修改比较困难对黑板数据结构的修改比较困难(要考虑不同的知识源对共享数据达成一致)方便于添加新的知识源应用程方便于添加新的知识源应用程序序系统复杂系统复杂(因为需要一定的同步/加锁机制保证数据结构的完整性和一致性)SA模式(3) -仓库

14、与黑板17What is the Logical Architecture? And Layers?oThe logical architecture is the large-scale organization of the software classes into packages, subsystems, and layers. oA layer is a very coarse-grained grouping of classes, packages, or subsystems that has cohesive responsibility for a major respe

15、ct of the system oTypical layers in an OO system includes nUser Interface nApplication Logic and Domain Objects nTechnical Services oStrict layered architecture (closed) oRelaxed layered architecture (opened)18Layers shown with UML package diagram notation19DomainUISwingnot the Java Swing libraries,

16、 but our GUI classes based on SwingWebSalesPaymentsTaxesTechnical ServicesPersistenceLoggingRulesEngineApplying UML: Package DiagramsoUML packages diagrams are often used to illustrate the logical architectures of a system the layers, subsystems, packages (in the Java sense). oA layer can be modeled

17、 as a UML package. oA UML package diagram provides a way to group elements. nA UML packages can group anything: classes, other packages, use cases, and so on. oIt is common to want to show dependency (a coupling) between package nso that developers can see the large-scale coupling in the system. oA

18、UML package represents a namespace na more general concept than simply a Java package or .NET namespaceoSome UML tools can reverse-engineer package diagrams from code20Alternate UML approaches to show package nesting21Domain:SalesUI:WebUI:SwingSalesWebSwingUIDomainDomainUISwingSalesWebMapping Code O

19、rganization to Layers and UML PackagesoMost popular OO languages provide support for packagesnJava, C#, C+, Python, , called namespaces in C# and C+).oJava Example/ - UI Layer com.mycompany.nextgen.ui.swing com. mycompany.nextgen.ui.web / - Domain Layer com.mycompany.nextgen.domain.sales com.mycompa

20、ny.nextgen.domain.payments / - Technical Service Layer com.mycompany.service.persistence22Guideline: Design with LayersoLayer patterns are applicable to various domains nHuman Society: UN, Country, Province, City, County . nScientific Research: Universe, ., atom, quark nSoftware system oThe essentia

21、l ideas of using layers are simple: nOrganize the large-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 applicat

22、ion specific. nCollaboration and coupling is from higher to lower layers; lower-to-higher layer coupling is avoided23Benefits of Using LayersoIn general, there is a separation of concernsna separation of high from low-level services, and of application-specific from general services. This reduces co

23、upling and dependencies, improves cohesion, increases reuse potential, and increases clarity.oRelated complexity is encapsulated and decomposable.oSome layers can be replaced with new implementationsoLower layers contain reusable functions.oSome layers (primarily the Domain and Technical Services) c

24、an be distributed.oDevelopment by teams is aided because of the logical segmentation.2425UI(AKA Presentation, View)Application(AKA Workflow, Process,Mediation, App Controller)Domain(AKA Business, Application Logic, Model)Technical Services(AKA Technical Infrastructure, High-level Technical Services)

25、Foundation(AKA Core Services, Base Services,Low-level Technical Services/Infrastructure)width implies range of applicability GUI windowsreportsspeech interfaceHTML, XML, XSLT, JSP, Javascript, . handles presentation layer requestsworkflowsession statewindow/page transitionsconsolidation/transformati

26、on of disparate data for presentation handles application layer requestsimplementation of domain rulesdomain services (POS, Inventory)- services may be used by just one application, but there is also the possibility of multi-application services (relatively) high-level technical services and framewo

27、rks Persistence, Securitylow-level technical services, utilities, and frameworksdata structures, threads, math, file, DB, and network I/Omoreapp specificdependencyBusiness Infrastructure(AKA Low-level Business Services)very general low-level business services used in many business domainsCurrencyCon

28、verterCommon layers in an information system logical architectureDomain Layer vs. Application Layer; Domain ObjectsoHow do we design the application logic with objects? nA typical software system has UI logic and application logic, such as UI widget creation and tax calculation. oWe 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.oCreating software objects with names and information similar to the real-world domain, and assign application logic

30、responsibilities to them 26Relationship between the Domain Layer and Domain Model27PaymentamountSaledatetimePays-forPaymentamount: MoneygetBalance(): MoneySaledate: DatestartTime: TimegetTotal(): Money. . .Pays-forUP Domain ModelStakeholders view of the noteworthy concepts in the domain.Domain layer

31、 of the architecture in the UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.1111A Payment

32、 in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.This reduces the representational gap.This is one of the big ideas in object technology.inspires objects and names in

33、Definition: Tiers, Layers, and PartitionsoThe 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 “client tier” oThe layers of an architecture represent the vertical slices, while parti

34、tions represent a horizontal division of relatively parallel subsystems of a layer 28PersistenceSecurityLoggingTechnical ServicesPOSInventoryTaxDomainVertical LayersHorizontal PartitionsGuideline: Dont Show External Resources as the Bottom Layer29Guideline: Cohesive Responsibilities; Maintain a Sepa

35、ration of ConcernsoThe responsibilities of the object in a layer should be strongly related to each other and should not be mixed with responsibilities of other layersnObjects in the UI layer should focus on UI work nObjects in the application logic or “domain” layer should focus on application logi

36、coUI objects should not do application logic nA Java Swing JFrame (window) object should not contain logic to calculate taxes or move a game piece nMicrosoft VB doesnt follow this rule, it makes the VB program difficult to maintain30Guideline: The Model-View Separation PrincipleoThe Model-View Separ

37、ation Principle nDon not connect or couple non-UI objects directly to UI objects. nDo not put application logic in the UI object methods. oThe motivation for Model-View Separation nTo support cohesive model definition that focus on the domain processes, rather than on user interfaces nTo allow separ

38、ate development of the model and user interface layers nTo minimize the impact of requirements changes in the interface upon the domain layer nTo allow new views to be easily connected to an existing domain layer, without affecting the domain layer nTo allow multiple simultaneous views on the same m

39、odel object n31Connection Between SSDs, System Operations, and Layers32DomainUISwingProcessSaleFrame.RegistermakeNewSale()enterItem().: CashiermakeNewSale()enterItem()endSale()makeNewSale()enterItem()endSale()enterItem(id, quantity):System: CashierendSale()description, totalmakeNewSale()the system o

40、perations handled by the system in an SSD represent the operation calls on the Application or Domain layer from the UI layerChapter 14. On to Object Designo Objectivesn Understand dynamic and static object design modeling.n Try agile modeling, or a UML CASE tool for drawing.33Three Ways For Develope

41、rs To Design Objects o CodenDesign-while-coding (Java, C#, ) ideally with power tools suc as refactoring. From mental model to code o Draw, then codenDrawing some UML on a whiteboard or UML CASE tools, then switching to #1 with text-strong IDE o Only draw nSomehow, the tool generate everything from diagrams. Many a dead tool vendor has washed onto the shores of this steep island34Agile Modeling and Lightweight UML Drawing oTo reduce drawing overhead and model to understand and communicate, rather than document. nTry the simple agile modeling approach. nUsing lots of