軟件需求分析課件：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的分類 面向模式的體系結(jié)構(gòu)-卷19從混沌到結(jié)構(gòu) Layer Pipes and Filters Blackboard分布式系統(tǒng) Broker(涉及“微核”和“管道-過濾器”)交互系統(tǒng) Model-View-Controller Presentation-Abstraction-Control適應(yīng)性系統(tǒng) Reflection MicrokernelLayer過程調(diào)用不同元素組合內(nèi)核層可用系統(tǒng)基礎(chǔ)實(shí)用層SA模式(1) -分層10每一層

9、為上層提供服務(wù)，并作為下層的客層只對(duì)鄰層可見連接件定義了層間交互的協(xié)議支持遞增抽象層的設(shè)計(jì)支持復(fù)雜問題的分解和增量式步驟序列的實(shí)現(xiàn)支持軟件復(fù)用：體現(xiàn)在每層只影響鄰層，所以每層可采用不同的實(shí)現(xiàn)方法應(yīng)用分層通訊協(xié)議中，諸如OSI/ISO的分層通訊模型計(jì)算機(jī)網(wǎng)絡(luò)協(xié)議組，如TCP/IPOS11SA模式(1) -分層優(yōu)點(diǎn)缺點(diǎn)支持抽象遞增的設(shè)計(jì)(復(fù)雜系統(tǒng)的遞增分解)并不是每個(gè)系統(tǒng)都能分層的(即使一個(gè)系統(tǒng)的邏輯結(jié)構(gòu)是層次化的，但出于性能的考慮，往往要將一些低級(jí)和高級(jí)的功能綜合起來的)容易擴(kuò)展(每層只影響鄰層)效率的降低(通過若干層的轉(zhuǎn)換帶來的)支持復(fù)用(如果對(duì)鄰層的接口相同，則在同一層中使用不同的實(shí)現(xiàn))抽象

10、層次方法難以選擇(特別是要選取合適的、正確的方法就更難)SA模式(1) -分層12過濾器過濾器過濾器過濾器過濾器過濾器管道管道管道管道管道管道管道Pipe&FilterSA模式(2) -管道-過濾器1314構(gòu)件：過濾器（filter）是數(shù)據(jù)加工處理的功能模塊，并將處理后的結(jié)果在輸出端輸出。連接件：管道（pipe）起信息流的導(dǎo)管作用。過濾器都有輸入/輸出集合，構(gòu)件從輸入處讀取數(shù)據(jù)流，在輸出處生成數(shù)據(jù)流。過濾器必須是獨(dú)立的主體，無須知道輸入/出管道的存在。但要對(duì)輸入管道和輸入數(shù)據(jù)流進(jìn)行限制。注意：將每個(gè)過濾器的輸入/出限制為單一的，則管道-過濾器退化為順序批處理系統(tǒng)(Batch sequentia

11、l)SA模式(2) -管道-過濾器詞法分析/掃描器語法分析/分析器語 義 分 析中間代碼生成Unix shell: cat file|grep xyz|sort|uniqout 即找到含xyz的行，排序、取掉相同的行，最后輸出編譯器信號(hào)處理系統(tǒng)并行計(jì)算SA模式(2) -管道-過濾器15優(yōu)點(diǎn)缺點(diǎn)系統(tǒng)行為易于理解由于該模式數(shù)據(jù)交換占用大量的空間，且數(shù)據(jù)傳輸占用系統(tǒng)的執(zhí)行時(shí)間。所以，它不適應(yīng)大量共享數(shù)據(jù)的應(yīng)用設(shè)計(jì)支持并發(fā)計(jì)算過濾器是在輸入/出有相應(yīng)限制情況下，才能對(duì)輸入進(jìn)行批量轉(zhuǎn)換處理。所以,不適用于交互式的應(yīng)用程序較強(qiáng)的可維護(hù)性和可擴(kuò)展性按照此模式，經(jīng)常導(dǎo)致成為批處理的結(jié)構(gòu)相對(duì)獨(dú)立的過濾器為性能(

12、吞吐量、死鎖)分析提供了方便由于構(gòu)件不能共享全局狀態(tài)。所以錯(cuò)誤處理困難SA模式(2) -管道-過濾器16黑板共享數(shù)據(jù)知識(shí)源存儲(chǔ)器計(jì)算直接存取Repositories (Blackboard)知識(shí)源知識(shí)源知識(shí)源知識(shí)源知識(shí)源知識(shí)源知識(shí)源控制器SA模式(3) -倉庫與黑板17知識(shí)源：與特定應(yīng)用相關(guān)的獨(dú)立的知識(shí)包(parcel)，只有通過黑板來完成它們之間的交互黑板數(shù)據(jù)結(jié)構(gòu)：求解問題的狀態(tài)的數(shù)據(jù)，并按照層次來組織。知識(shí)源通過對(duì)黑板的修改來漸進(jìn)式地達(dá)到問題的求解控制器：控制器承擔(dān)著限制知識(shí)源對(duì)黑板的訪問，防止兩個(gè)知識(shí)源同時(shí)寫黑板的某一空間?？刂破魍耆珊诎鍫顟B(tài)驅(qū)動(dòng)和決定。一旦黑板數(shù)據(jù)的改變需要知識(shí)源的時(shí)

13、候，控制器會(huì)及時(shí)通知知識(shí)源隨即進(jìn)行響應(yīng)應(yīng)用信號(hào)處理與模式識(shí)別領(lǐng)域用于具有松散-偶合實(shí)體對(duì)共享數(shù)據(jù)的存取18SA模式(3) -倉庫與黑板優(yōu)點(diǎn)缺點(diǎn)便于多個(gè)客戶共享大量的數(shù)據(jù)對(duì)黑板數(shù)據(jù)結(jié)構(gòu)的修改比較困難(要考慮不同的知識(shí)源對(duì)共享數(shù)據(jù)達(dá)成一致)方便于添加新的知識(shí)源應(yīng)用程序系統(tǒng)復(fù)雜(因?yàn)樾枰欢ǖ耐?加鎖機(jī)制保證數(shù)據(jù)結(jié)構(gòu)的完整性和一致性)SA模式(3) -倉庫與黑板19ClientdoTaskExternal ServerreceiveRequestdispatchRequestexecuteServiceInternal ServerexecuteServicereceiveRequestAdapt

14、ercallServicecreateRequestMicrokernalexecuteMechanisminitCommunicationfindReceivercreateHandlesendMessagecallInternalServercalls servicesend requestInitializes communicationcallsactivatesSA模式(4) -微核(microkernal)20微核：封裝了應(yīng)用的基本服務(wù)。具有支持其它構(gòu)件在一個(gè)獨(dú)立進(jìn)程中運(yùn)行時(shí)互相通訊的功能；負(fù)責(zé)維護(hù)資源，如文件、進(jìn)程等；提供其它構(gòu)件存取其功能的接口。內(nèi)部服務(wù)器：實(shí)現(xiàn)了在微核中不能實(shí)

15、現(xiàn)的核心功能(出于復(fù)雜性的考慮)每個(gè)外部服務(wù)器：是一個(gè)獨(dú)立的進(jìn)程，即應(yīng)用程序平臺(tái)，它通過微核的接口獲得的機(jī)制實(shí)現(xiàn)自己的基本功能客戶機(jī)通過使用微核提供的通訊能力與外部服務(wù)器通訊一個(gè)微核系統(tǒng)可被看成集成了其它應(yīng)用平臺(tái)的公共應(yīng)用支撐平臺(tái)應(yīng)用OS，諸如MS-Windows：核心包括進(jìn)程和線程的管理，低級(jí)I/O，點(diǎn)到點(diǎn)通訊服務(wù)部分DBMS，諸如MKDE(Microkernel Database Engine)，微核提供物理數(shù)據(jù)存取，事務(wù)管理等21SA模式(4) -微核(microkernal)優(yōu)點(diǎn)缺點(diǎn)可移植性(微核不移植和移植兩種情況)性能(微核支持不同的視圖，與只提供特定視圖的系統(tǒng)相比，一般性能要低)

16、適應(yīng)性和可擴(kuò)展性(只需填加一個(gè)外部服務(wù)器)設(shè)計(jì)和實(shí)現(xiàn)的復(fù)雜性策略與機(jī)制的分離(微核提供機(jī)制，外部服務(wù)器實(shí)現(xiàn)策略)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 “l(fā)ower” 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