Requirements To Design--Iteratively

  • View

  • Download

Embed Size (px)


Requirements To Design--Iteratively. Chapter 12 Applying UML and Patterns Craig Larman. Introduction. A transition from primarily a requirements focus to primarily a design and implementation focus will occur in each iteration. - PowerPoint PPT Presentation

Text of Requirements To Design--Iteratively

Object Oriented Analysis and Design

Requirements To Design--IterativelyChapter 12Applying UML and PatternsCraig Larman IntroductionA transition from primarily a requirements focus to primarily a design and implementation focus will occur in each iteration.Actual modeling that has been explored so far is realistically done in just a few days.Other activities such as proof-of-concept programming, planning, setting up the environment could take weeks

Objectives During Transition Motivate the transition to design activitiesShift emphasis to designing a solution for iteration as collaborating software objectsContrast the importance of object design skill versus UML notation knowledge On to Object DesignDuring object design, a logical solution based on the object-oriented paradigm is developed. Interaction diagrams illustrate how objects collaborate to fulfill the requirements.In practice, after or in parallel with drawing interaction diagrams, (design) class diagram can be synergistically drawn

Object Design vs UML NotationDrawing UML interaction diagrams is the result of making decisions about the object design.The object design skills are what really matter

Fundamental object design requires knowing:Principles of responsibility assignmentDesign patterns

6Logical Architecture and UML Package DiagramsChapter 13Applying UML and Patterns7Architectural Dimension and ViewsThe common system descriptions are:logical architecture--the system as a conceptual organization in layers, packages, classes, interfaces and subsystems.

deployment architecture--the system as an allocation of processes to processing unit and network configurations

8LayersA coarse-grained grouping of classes packages or subsystems that has cohesive responsibility for a major aspect of the system.Higher layers call upon services of lower layersTypical layers in OO systems:User InterfaceApplication Logic and Domain ObjectsTechnical Services (e.g. database interface support or error logging objects) typically independent and reuseable 9Architectural Patterns and Pattern CategoriesArchitectural patterns: Relates to large-scale design and typically applied during the early iterationsDesign patterns: Relates to small and medium-scale design of objects and frameworksIdioms: Relates to language or implementation-oriented low-level design solutions.10Inter-Layer and Inter-Package CouplingIt is informative to include a diagram in the logical view that shows the coupling between the layers and packages.Emphasizes the dynamics of how objects across the layers connect and communicate.The interaction diagram focuses on the logical view and on the collaborations between the layers and package boundaries.

11Partial coupling between Packages

12Package DiagramsUML Package Diagrams are often used to show the contents of components, which are often packages in the Java sense.Packages, as components, can be nested inside other packages.13Package DiagramUIDomainSwingWebSales14Designing Application Logic with ObjectsPossible Alternative: create one class and put all logic in itViolates the spirit of object orientationBetter Alternative: create software objects with names drawn from the real worldAssign application logic responsibilities to them.Skill and experience required to do good job of choosing objects and assigning responsibilities.15Domain Layer and Domain ModelThese are not the same thingDomain model shows the real world Domain layer shows the software architectureDomain model inspires the Domain layer, and is the source of many of the concepts, especially class names.16Information Systems LayersA three-tier (layer) architecture has interface, Application logic and storage layersSeparates the application logic into distinct logical middle tier of software.The interface tier is relatively free of application processingThe middle tier communicates with the back-end storage layer.


18Alternative Two-tier DesignIn this design, the application logic is placed within window definitions, which read and writes directly to database.There is no middle tier that separates out the application logic.

19The Model-View Separation PrincipleDo not connect or couple non-UI objects directly to UI objectsModel (domain) objects should not have direct knowledge of view (UI) objectsDo not put application logic in the UI object methodsOnly model (domain) classes should encapsulate the behavior of application logicUI objects should only receive UI events, delegate application logic requests, and initialize UI elements

20Model-View Separation AdvantagesSupports cohesive model definitions that focuses on the domain process, rather than on interfacesAllows separate development of the model and user interface layers.Minimizes impact of requirements changes in the interface upon the domain layerAllow new views to be easily connected to an existing domain layer, without affecting the domain layer21Model-View Separation AdvantagesAllow multiple simultaneous views on the same model objectAllow execution of the model layer independent of the user interface layerAllow easy porting of the model layer to another user interface framework