requirements to design--iteratively chapter 12 applying uml and patterns craig larman
TRANSCRIPT
![Page 1: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/1.jpg)
Requirements To Design--Iteratively
Chapter 12
Applying UML and Patterns
Craig Larman
![Page 2: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/2.jpg)
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
![Page 3: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/3.jpg)
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
![Page 4: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/4.jpg)
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
![Page 5: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/5.jpg)
Object Design vs UML Notation Drawing 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 assignment Design patterns
![Page 6: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/6.jpg)
6
Logical Architecture and UML Package Diagrams
Chapter 13
Applying UML and Patterns
![Page 7: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/7.jpg)
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
![Page 8: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/8.jpg)
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
![Page 9: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/9.jpg)
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.
![Page 10: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/10.jpg)
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.
![Page 11: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/11.jpg)
11
Partial coupling between Packages
![Page 12: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/12.jpg)
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.
![Page 13: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/13.jpg)
13
Package Diagram
UI Domain
Swing Web Sales
![Page 14: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/14.jpg)
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.
![Page 15: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/15.jpg)
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.
![Page 16: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/16.jpg)
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.
![Page 17: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/17.jpg)
17
Example:
![Page 18: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/18.jpg)
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.
![Page 19: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/19.jpg)
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
![Page 20: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/20.jpg)
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
![Page 21: Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman](https://reader036.vdocuments.site/reader036/viewer/2022062518/56649ea85503460f94bab8b9/html5/thumbnails/21.jpg)
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