Requirements To Design--Iteratively

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