软件需求分析英文课件：Chap 5(1) - Object Oriented Design

1、Chapter 5(1) Object Oriented Design 5.1 OO Design Overview 5.2 Architectural Design 5.3 Use Case Design 5.4 Subsystem Design 5.5 Class DesignOO Design Overview5.1 OO Design Overview Understanding Design Analysis Versus Design Object Oriented DesignUnderstanding DesignA process that uses the products

2、 of analysis to produce a specification for implementing a system. A logical description of how a system will work. Emphasizes a conceptual solution (in software and hardware) that fulfills the requirements, rather than its implementation.“do the right thing (analysis), and do the thing right (desig

3、n)”. Analysis Versus DesignAnalysisFocus on understanding the problemIdealized designBehaviorSystem structureFunctional requirementsA small modelDesignFocus on understanding the solution Operations and AttributesPerformanceClose to real code Object lifecyclesNon-functional requirementsA large modelO

4、bject Oriented DesignThe specification of a logical software solution in terms of software objectssuch as their classes, attributes, methods, and collaborations. During object-oriented design (or simply, object design) there is an emphasis on defining software objects and how they collaborate to ful

5、fill the requirements. Architectural Design5.2 Architectural Design Architectural Patterns Identify Design Elements Organizing the design model packagesIdentify Design MechanismsResolution of Architectural FactorsDescribe the Run-time ArchitectureDescribe DistributionWhat is An Architectural Pattern

6、?An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them Buschman et al, “Pattern-Oriented Softw

7、are Architecture A System of Patterns”Architectural patterns - Common Architectural StylesLayersModel-view-controller (M-V-C)Pipes and filtersBlackboardExamples of Architectural Patterns - Blackboard1) Pattern Name Blackboard2) Context A domain in which no closed (algorithmic) approach tosolving a p

8、roblem is known or feasible. Examples are AI systems, voice recognition, and surveillance systems.3) Problem Multiple problem-solving agents (knowledge agents) mustcooperate to solve a problem that cannot be solved by anyof the individual agents. The results of the work of the individual agents must

9、 be accessible to all the other agents so they can evaluate whether they can contribute to finding a solution and post results of their work.Examples of Architectural Patterns - Blackboard4) Forces Sequence in which knowledge agents can contribute to solving the problem is not deterministic and may

10、depend on problem solving strategies. Input from different agents (results or partial solutions) may have different representations. Agents do not know of each others existence directly but can evaluate each others posted contributions5) Solution A number of Knowledge Agents have access to a shared

11、data store called the Blackboard. The blackboard provides an interface to inspect and update its content. The Control module/object activates the agents following some strategy. Upon activation an agent inspects that blackboard to see if it can contribute to solving the problem. If the agent determi

12、nes that it can contribute, the control object can allow the agents to put its partial (or final) solution on the board.Examples of Architectural Patterns - BlackboardExamples of Architectural Patterns - Pipes & Filters1. 基本结构2.特征过滤器是独立实体，相互之间不共享状态过滤器不了解其它过滤器的信息Examples of Architectural Patterns - P

13、ipes & Filters3. 例子：Procedural processing system4. 缺点经常导致批处理方式，不利于交互。当有大量和不同方式的输入/输出数据时，复杂性增加,性能降低。Examples of Architectural Patterns - Pipes & Filters5. 优点系统总体行为是各个独立过滤器行为的简单组合。支持复用：任何两个过滤器之间，如果交流的数据格式匹配，即可以连接在一起。系统的维护与扩展方便：新的过滤器可以添加到现有系统中，或者利用改进的过滤器替换老的过滤器。方便系统分析：例如，吞吐量、死锁等。并发性好：每一个过滤器可以作为一个单独的任务实

14、现，可以与其它过滤器并行执行。Typical Layering ApproachGeneral functionalitySpecific functionalityExamples of Architectural Patterns - Layers1) Pattern Name: Layers2) Context A large system that requires decomposition.3) ProblemA system which must handle issues at different levels of abstraction. For example: hard

15、ware control issues, common services issues and domain-specific issues. It would be extremely undesirable to write vertical components that handle issues at all levels. The same issue would have to be handled (possibly inconsistently) multiple times in different components.Examples of Architectural

16、Patterns - Layers4) ForcesParts of the system should be replaceable Changes in components should not ripple. Similar responsibilities should be grouped together Size of components - complex components may have to be decomposed 5) SolutionStructure the systems into groups of components that form laye

17、rs on top of each other. Make upper layers use services of the layers below only (never above). Try not to use services other than those of the layer directly below (dont skip layers unless intermediate layers would only add pass-through components).Modeling Architectural LayersArchitectural layers

18、can be modeled using stereotyped packages stereotypeLayer Reuse drivingApplicationBusiness-Specific Middleware Examples of Architectural Patterns - LayersPartial logical view of layers in the NextGen application System Operations and Layers Upward Collaboration with ObserverWhen the lower Applicatio

19、n or Domain layer needs to communicate upward with the Presentation layer, it is usually via the Observer patternUI objects in the higher Presentation layer implement an interface such as Property Listener or AlarmListener, and are subscribers or listeners to events (such as property or alarm events

20、) coming from objects in the lower layers.The lower layer objects are directly sending messages to the upper layer UI objects,but the coupling is only to the objects viewed as things that implement an interface such as PropertyListener, not viewed as specific GUI windows.Review: The Observer pattern

21、 Consider several graphical windows presenting the same information, possibly in different ways (e.g. spreadsheet table, pie chart, bar chart). When the information changes, all windows must be updated to reflect the changes. In order to have the “observed” object independent of the observers, we wi

22、ll use the Observer pattern (equivalent to publish-subscribe). The Observer pattern (Detailed)A subject object (the “observed” object) notifies upon change anonymous observers The Observer pattern (Detailed)the observed object is not required to know about the observers ahead of time. Example: A GUI

23、 Observes a PersonExample: A GUI Observes a Person Upward Collaboration with Observer Comments on typical coupling between layersAll higher layers have dependencies on the Technical Services and Foundations layerFor example, in Java all layers depend on java.util package elementsIt is primarily the

24、Domain layer that has dependency on the Business Infrastructure layerPresentation layer makes calls on the Application layer, which makes service calls on the Domain layer; the Presentation layer does not call on the Domain, unless there is no Application layer.If it is a single-process desktop appl

25、ication, software objects in the Domain layer are directly visible to, or passed between, Presentation, Application, and to a lesser extent, Technical Services.If it is a distributed system, then serializable replicates (also known as data holder or value objects) of objects in the Domain layer are

26、usually passed to a Presentation layer. In this case, the Domain layer is deployed on a server computer, and client nodes get copies of server data. Mixing views of the architecture Terminology: Tiers, Layers, and PartitionsThe original notion of a tier in architecture was a logical layer, not a phy

27、sical node, but the word has become widely used to mean a physical processing node (or cluster of nodes) such as the client tier (the client computer).The layers of an architecture are said to represent the vertical slicesThe partitions represent a horizontal division of relatively parallel subsyste

28、ms of a layer. Layers and partitionsLayer - N-Tier (C/S)ServerClient AClient N.Layer - N-Tier (3 tier)Relational Database Server(s)Client CWWW BrowserWebServerHTMLCGIASPJavaBusiness ObjectServicesBusiness ObjectEngineApplicationBusiness ObjectServicesClient ABusiness ObjectEngineThinner client, thic

29、ker serverClient BApplicationBusiness ObjectServicesBusiness ObjectEngineBusiness Object ServerDCOMADO/RCORBABeansCOMMTSBeansETSIdentify Design Elements Identify Design Elements Identify Classes, Active ClassesIdentify Subsystems and Subsystem Interfaces Purpose： To analyze interactions of analysis

30、classes to identify design model elements From Analysis Classes to Design Elements Identify Design Elements classes, to represent a set of rather fine-grained responsibilities; subsystems, to represent a set of coarse-grained responsibilities, perhaps composed of a further set of subsystems, but ult

31、imately a set of classes; active classes, to represent threads of control in the system; interfaces, to represent abstract declarations of responsibilities provided by a class or subsystem. Analysis classes represent conceptual things which can perform behavior. In design, analysis classes evolve in

32、to a number of different kinds of design elements: Encapsulation is the key!Packages versus SubsystemsSubsystems Provide behaviorCompletely encapsulate their contentsAre easily replacedSubsystem APackage BClassB1ClassB2Client ClassPackages Dont provide behaviorDont completely encapsulate their conte

33、ntsMay not be easily replacedSubsystems raise the level of abstraction.Subsystem UsageSubsystems can be used to partition the system into parts that can be independently:ordered, configured, or delivered developed, as long as the interfaces remain unchangeddeployed across a set of distributed comput

34、ational nodeschanged without breaking other parts of the systemsSubsystems can also be used to:partition the system into units which can provide restricted security over key resourcesrepresent existing products or external systems in the design (e.g. components)Identifying Subsystems HintsLook at ob

35、ject collaborations.Look for optionality.Look to the user interface of the system.Look to the actors.Look for coupling and cohesion between classes.Look at substitution.Look at distribution.Look at volatility.Analysis classes which may evolve into subsystems:Classes providing complex services and/or

36、 utilitiesBoundary classes (user interfaces and external system interfaces)Existing products or external systems in the design (e.g., components):Communication softwareDatabase access supportTypes and data structuresCommon utilitiesApplication-specific productsCandidate SubsystemsSubsystem ASubsyste

37、m BSubsystem CSubsystem AIdentifying SubsystemsClassAX()W()X()W()“SupermanClass”InterfaceKSubsystemKClassA1X()ClassA2W()Stable, well-defined interfaces are key to a stable, resilient architecture.Identifying InterfacesPurposeTo identify the interfaces of the subsystems based on their responsibilitie

38、sStepsIdentify a set of candidate interfaces for all subsystems.Look for similarities between interfaces.Define interface dependencies.Map the interfaces to subsystems.Define the behavior specified by the interfaces.Package the interfaces.Interface GuidelinesInterface nameReflects role in systemInte

39、rface descriptionConveys responsibilitiesOperation definitionName should reflect operation resultDescribes what operation does, all parameters and resultInterface documentationPackage supporting info: sequence and state diagrams, test plans, etc.All other analysis classes map directly to design clas

40、ses.AnalysisDesignExample: Design Subsystems and InterfacesBillingSystem/submit bill()Billing SystemIBillingSystemsubmitBill(forTuition : Double, forStudent : Student)CourseCatalogSystem/get course offerings()Course Catalog System ICourseCatalogSystemgetCourseOfferings(forSemester : Semester, forStu

41、dent : Student) : CourseOfferingListinitialize()Analysis ClassDesign ElementCourseCatalogSystemBillingSystemAll other analysis classes map directly to design classesCourseCatalogSystem SubsystemBillingSystem SubsystemExample: Analysis-Class-To-Design-Element MapModeling Convention: Subsystems and In

42、terfacesProxy Pattern - MotivationWhat is expensive?Object CreationObject InitializationDefer creation and initialization to the time you need the objectReduce the cost of access to objectsUse another object (“the proxy”) that acts as a stand-in for the real objectThe proxy creates the real object o

43、nly if the user asks for itProxy Pattern - MotivationExampleThe Proxy provides a surrogate or place holder to provide access to an object. A check or bank draft is a proxy for funds in an account. A check can be used in place of cash for making purchases and ultimately controls access to cash in the

44、 issuers account. Proxy Pattern - StructureIntent Provide a surrogate or placeholder for another object to control access to it.ProblemYou need to support resource-hungry objects, and you do not want to instantiate such objects unless and until they are actually requested by the client. StructureThe

45、 Proxy patternHow to handle distributed objects in a way that is transparent to the local client application.How a design model can be derived from an analysis “by adding elements rather than by replacing them”. The Proxy pattern (Detailed)Imagine that we are implementing software to allow branches

46、from a bank to retrieve any account information such as the account balance. The Proxy pattern (Detailed)Retrieving the balance of an account whose number is 123456-0 The Proxy pattern (Detailed) The use of the proxy pattern on the Account class will allow us to handle distributed account objects wi

47、thout having to change our model The Proxy pattern (Detailed)Example: Subsystem Context: CourseCatalogSystem Example: Subsystem Context: Billing System Organizing the Design Model PackagesA package is a general purpose mechanism for organizing elements into groups.It is a model element that can cont

48、ain other model elements.A package can be usedTo organize the model under development.As a unit of configuration management.Review: What Is a Package?University ArtifactsYou can base your packaging criteria on a number of different factors, including:Configuration unitsAllocation of resources among

49、development teamsReflect the user typesRepresent the existing products and services the system usesPackage C Group Design Classes in PackagesPackage BPackage A Packaging Tips: Boundary ClassesIf it is likely the system interface will undergo considerable changesBoundary classes placed in separate pa

50、ckagesIf it is unlikely the system interface will undergo considerable changesBoundary classes packaged with functionally related classesPackaging Tips: Functionally Related ClassesCriteria for determining if classes are functionally related:Changes in one class behavior and/or structure necessitate

51、 changes in another classRemoval of one class impacts the other classTwo objects interact with a large number of messages or have a complex intercommunicationA boundary class can be functionally related to a particular entity class if the function of the boundary class is to present the entity class

52、Two classes interact with, or are affected by changes in the same actor Packaging Tips: Functionally Related Classes (continued)Criteria for determining if classes are functionally related (continued):Two classes have relationships between each otherOne class creates instances of another classCriter

53、ia for determining when two classes should NOT be placed in the same package:Two classes that are related to different actors should not be placed in the same packageAn optional and a mandatory class should not be placed in the same packagePackages can be related to one another using a dependency re

54、lationshipDependency ImplicationsChanges to the Supplier package may affect the Client packageThe Client package cannot be reused independently because it depends on the Supplier packagePackage Relationships: DependencyClient PackageSupplier PackageDependency relationshipPackageBPackageAPublic visib

55、ilityPrivate visibilityOnly public classes can be referenced outside of the owning packageOO Principle: EncapsulationPackage Dependencies: Package Element VisibilityAB+ Class A1+ Class A2+ Class A3+ Class B1 - Class B2CABHierarchy should be acyclicABCACircular dependencies make it impossible to reus

56、e one package without the otherAvoiding Circular DependenciesABNo Cycles in PackagesABXPackage Coupling: TipsPackages should not be cross-coupled Packages in lower layers should not be dependent upon packages in upper layersIn general, dependencies should not skip layersABUpper LayerLower LayerCXX =

57、 Coupling violationXExample: Architectural LayersMiddlewareBase ReuseglobalApplicationBusiness ServicesNecessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI.RegistrationApplicationExample: Application LayerSecurityGUI FrameworkSecure Inte

58、rfacesApplicationBusiness ServicesApplicationBusiness ServicesExample: Application Layer ContextUniversity ArtifactsRegistrationExternal System InterfacesExample: Business Services LayerCourseCatalogSystemExternal System InterfacesUniversity ArtifactsObjectStore SupportBusiness ServicesGUIFrameworkS

59、ecureInterfacesSecuritySecurityManagerBillingSystemMiddlewareBusiness ServicesExample: Business Services Layer Contextjava.sqlcom.odiMiddlewareBillingSystemCourseCatalogSystemExternal System InterfacesUniversity ArtifactsObjectStore SupportBusiness ServicesGUIFrameworkSecureInterfacesSecuritySecurit

60、yManagercom.odiDatabase(from com.odi)Session(from com.odi)Transaction(from com.odi)Map(from com.odi)java.sqlResultSet(from com.odi)Connection(from com.odi)Statement(from com.odi)DriverManager(from com.odi)Example: Middleware LayerMiddlewareExample: Registration PackageMainRegistrarForm111MainStudent