1 / 21

Requirements To Design--Iteratively

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.

saniya
Download Presentation

Requirements To Design--Iteratively

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman

  2. Introduction • A 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

  3. Objectives During Transition • Motivate the transition to design activities • Shift emphasis to designing a solution for iteration as collaborating software objects • Contrast the importance of object design skill versus UML notation knowledge

  4. On to Object Design • During 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

  5. Object Design vsUML Notation • Drawing UML interaction diagrams is the result of making decisions about the object design. • Theobject design skills are what reallymatter Fundamental object design requires knowing: • Principles of responsibility assignment • Design patterns

  6. Logical Architecture and UML Package Diagrams Chapter 13 Applying UML and Patterns

  7. Architectural Dimension and Views The 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

  8. Layers • “A 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 layers • Typical layers in OO systems: • User Interface • Application Logic and Domain Objects • Technical Services (e.g. database interface support or error logging objects) – typically independent and reuseable

  9. Architectural Patterns and Pattern Categories • Architectural patterns: Relates to large-scale design and typically applied during the early iterations • Design patterns: Relates to small and medium-scale design of objects and frameworks • Idioms: Relates to language or implementation-oriented low-level design solutions.

  10. Inter-Layer and Inter-Package Coupling • It 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.

  11. Partial coupling between Packages

  12. Package Diagrams • UML 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.

  13. Package Diagram UI Domain Swing Web Sales

  14. Designing Application Logic with Objects • Possible Alternative: create one class and put all logic in it • Violates the spirit of object orientation • Better Alternative: create software objects with names drawn from the real world • Assign application logic responsibilities to them. • Skill and experience required to do good job of choosing objects and assigning responsibilities.

  15. Domain Layer and Domain Model • These are not the same thing • Domain model shows the real world • Domain layer shows the software architecture • Domain model inspires the Domain layer, and is the source of many of the concepts, especially class names.

  16. Information Systems Layers • A three-tier (layer) architecture has interface, Application logic and storage layers • Separates the application logic into distinct logical middle tier of software. • The interface tier is relatively free of application processing • The middle tier communicates with the back-end storage layer.

  17. Example:

  18. Alternative Two-tier Design • In 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.

  19. The Model-View Separation Principle • Do not connect or couple non-UI objects directly to UI objects • Model (domain) objects should not have direct knowledge of view (UI) objects • Do not put application logic in the UI object methods • Only model (domain) classes should encapsulate the behavior of application logic • UI objects should only receive UI events, delegate application logic requests, and initialize UI elements

  20. Model-View Separation Advantages • Supports cohesive model definitions that focuses on the domain process, rather than on interfaces • Allows separate development of the model and user interface layers. • Minimizes impact of requirements changes in the interface upon the domain layer • Allow new views to be easily connected to an existing domain layer, without affecting the domain layer

  21. Model-View Separation Advantages • Allow multiple simultaneous views on the same model object • Allow execution of the model layer independent of the user interface layer • Allow easy porting of the model layer to another user interface framework

More Related