1. Object Oriented Analysis and Design Using the UML
OOADv4.2 Instructor Notes
Object Oriented Analysis and Design Using the UML
Analysis and Design Overview
Module 5 - Analysis and Design Overview

2. Objectives: Analysis and Design Overview
OOADv4.2 Instructor Notes
Objectives: Analysis and Design Overview
Introduce the analysis and design process,
Understand the difference between analysis and design
Note that the details of each of the Analysis and Design activities will be covered later.
Present a context for the detailed analysis and design activities.
Module 5 - Analysis and Design Overview

3. Analysis and Design in Context
OOADv4.2 Instructor Notes
Analysis and Design in Context
Inception
Elaboration
Construction
Transition
Review the Rational Unified Process Framework and the relationship of the Analysis and Design workflow to the other workflows in the Rational Unified Process Framework.
The Rational Unified Process Framework was introduced in the Introduction to RUP Module.
Highlight what part of the overall process we will be concentrating on (analysis and design activities in an early elaboration iteration).
Requirements
Analysis & Design
Test
Configuration & Change Mgmt
Management
Environment
Preliminary Iteration(s)
Iter. #1
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m
Iter. #m+1
The purposes of Analysis and Design are:
To transform the requirements into a design of the system to-be.
To evolve a robust architecture for the system.
Note: Analysis and Design taken ‘together.’ WHY?????
Olden days versus Modern Times…..
Module 5 - Analysis and Design Overview

4. Requirements  Analysis and Design
OOADv4.2 Instructor Notes
Requirements  Analysis and Design
Input Artifacts – from Requirements Workflow
Design Model
If a separate analysis model is desired, then an Analysis Model would be listed as a separate artifact (in addition to the Design Model).
Use-Case Model
Ultimately, we wish to produce a Design Model
Analysis and Design
Architecture
Document
Glossary
Data Model
Supplementary
Specification
(additional ‘features’ &
non-functional requirements…)
Module 5 - Analysis and Design Overview

5. Analysis and Design Overview (continued)
OOADv4.2 Instructor Notes
Analysis and Design Overview (continued)
Design model is an abstraction of source code and serves as the blue print for Construction.
Design Model consists of Design Classes structured into Design packages
Design Model also contains descriptions as to how objects of these design classes interact to perform Use Cases (Use Case Realizations)
The Use Case Realizations are:
Class diagrams and
Interaction Diagrams
Module 5 - Analysis and Design Overview

6. Analysis and Design Overview (continued)
OOADv4.2 Instructor Notes
Analysis and Design Overview (continued)
Design activities are centered around the notion of an architecture.
Production and validation of this architecture is the main focus of early design iterations.
Architectural design takes place during Elaboration.
Architecture is represented by a number of architectural views that capture the major structural design decisions.
Architectural views are the abstractions or simplifications of the entire design, in which important characteristics are made more visible by leaving details aside.
Module 5 - Analysis and Design Overview

7. Analysis and Design Overview (continued)
OOADv4.2 Instructor Notes
Analysis and Design Overview (continued)
We will create an Analysis Model as the first part of Analysis and Design.
We create Analysis Classes from Use Cases and other sources of requirements (Vision, Domain Model, …)
Our Design Model will then take the artifacts from Analysis Modeling (analysis classes) and create our Use Case Realizations:
Static View: Design classes, and
Dynamic View: showing how objects collaborate in ‘realizing’ each flow in a use case.
Module 5 - Analysis and Design Overview

8. Analysis Versus Design
OOADv4.2 Instructor Notes
Analysis Versus Design
Difference is on emphases
Design
Focus on understanding the solution
Operations and Attributes
Performance, Efficiency…
Close to real code
Object lifecycles
Non-functional requirements in detail
A large model
An instructor once said: “Analysis Vs. Design is important because of the mind-set. If you tried to manage all of the analysis and design issues in one go, your brain would explode on all but the most trivial developments. It’s just too much to take in, comprehend, and model in one go. So I mentally switch “OK, analysis - problem domain - don’t care about memory, persistence, databases, language, etc”. “Right now it’s design and I do care about all those things - but now I can stop thinking (too a degree) about trying to understand the business domain.” It’s about managing the 7+/-2 things I can think about in one go. It also separates out the skills (a bit).”
Another instructor once said: “analysis is the study of and eventual comprehension of “some thing” [the problem space]. But to understand it, we must invent some entities to hold onto the thing that we have just grasped - this inventive process is design. That is, human cognitive thinking is actually interwoven analysis/design and any attempt to separate them is really only an idealization. Therefore, if I try to apply two separate “steps” in the production of, say, a class diagram [and call those steps A and then D], I will introduce ambiguity into my process because cognitive process forces one to “produce a solution” in order to “understand a problem” - that D is necessary to have any results from A.”
Think of analysis as an idealized design step - where we ignore several complicating issues. This can turn into a religious debate.
Analysis
Focus on understanding the problem
Idealized design
(Generalized) Behavior
Separation of Concerns
System structure
Functional requirements
Some recognition for non-functional requirements
A small model
Analysis: understanding the problem; develop a visual model of
What you are trying to build
Module 5 - Analysis and Design Overview

9. OOADv4.2 Instructor Notes
Goal of Analysis
Understand the problem; try to build a visual model of what you are trying to do independent of implementation or technology concerns.
Focus on translating the functional requirements into software concepts, abstractions Note: Nothing in Use Cases says ‘Objects.’
Get rough cut at objects that from our system but focusing on behavior and separation of Concerns…
Some authors include an Analysis Model here –
 I consider analysis modeling as the prelude to architectural
design.
Sometimes considered first part of Design;
Sometimes merely considered part of Design itself.
In some circles, there is ‘only’ Requirements and then Design…
Many ‘organizations’ tailor activities to their own ‘interpretations.’
Module 5 - Analysis and Design Overview

10. OOADv4.2 Instructor Notes
Goal of Design
Refine the Analysis Model with goal to creating a Design Model that will facilitate our moving “quickly and seamlessly” into more detailed design and implementation.
(Morph Analysis Classes into Design ‘components,’ specific classes or other…)
Note that design model elements are abstractions of code / implementation.
Design Model constitutes the ‘Solution Space’
Module 5 - Analysis and Design Overview

11. OOADv4.2 Instructor Notes
Use Case Realization
A Use Case Realization describes how a particular use case is implemented in the design model in terms of collaborating objects.
 In the UP, each use case has a use case realization!!
 They are one-to-one.
A Use-Case Realization maps use cases from the use-case model to design model in terms of classes and other related design entities and relationships.
A Use-Case Realization specifies what software classes must be built, how they collaborate (relationships, dependencies…), and the messages passed between objects necessary to implement each use case
Use Case Realizations have a static component and a dynamic component.
Module 5 - Analysis and Design Overview

12. What is a Use-Case Realization?
OOADv4.2 Instructor Notes
What is a Use-Case Realization?
 A use-case realization in the design model can be traced to
a use case in the use-case model.
A “realization relationship” is drawn from the use-case realization
to the use case it “realizes.”
If you consider use cases and scenarios to be black box descriptions of the system, then the use-case realizations are the associated white box descriptions.
Use-case realizations are introduced here because use-case realizations may be mentioned when providing the overview of the analysis and design workflow (the developing of use-case realizations is the main goal of Use-Case Analysis and the refinement of these use case realizations is the main goal of Use-Case Design). The use case realizations are identified in Architectural Analysis, initially developed in Use-Case Analysis and then refined in Use-Case Design.
The Rational Unified Process includes templates for the the use-case realization, as well as the use-case realization icon.
In Rose, you cannot draw realizations between use cases, so a stereotyped association must be used instead. In Rose, use-case realizations are modeled as stereotyped use cases. This is discussed in more detail in the Use-Case Analysis module.
Use-Case Model
Design Model
Use Case
Use-Case Realization
(realizes relationship)
Module 5 - Analysis and Design Overview

13. What is a Use-Case Realization?
OOADv4.2 Instructor Notes
What is a Use-Case Realization?
Interaction Diagrams
If you consider use cases and scenarios to be black box descriptions of the system, then the use-case realizations are the associated white box descriptions.
Use-case realizations are introduced here because use-case realizations may be mentioned when providing the overview of the analysis and design workflow (the developing of use-case realizations is the main goal of Use-Case Analysis and the refinement of these use case realizations is the main goal of Use-Case Design). The use case realizations are identified in Architectural Analysis, initially developed in Use-Case Analysis and then refined in Use-Case Design.
The Rational Unified Process includes templates for the the use-case realization, as well as the use-case realization icon.
In Rose, you cannot draw realizations between use cases, so a stereotyped association must be used instead. In Rose, use-case realizations are modeled as stereotyped use cases. This is discussed in more detail in the Use-Case Analysis module.
Sequence Diagrams
Collaboration Diagrams
Use Case
A use case realization can be represented using a set of diagrams which model the context of the collaboration – class diagrams and
the interactions of these collaborations:
communications and sequence diagrams.
Class Diagrams
Module 5 - Analysis and Design Overview

14. Software Architecture Model: The “4+1 Architectural View”
OOADv4.2 Instructor Notes
Software Architecture Model: The “4+1 Architectural View”
Discuss the 4+1 views. These are covered in detail in the Rational Unified Process.
The 4+1 model is introduced here and because it is important for the students to see how the views fit together up front, in order to set context. The individual views are addressed in the specific architecture modules:
The Logical view will be discussed in the Architectural Analysis and Architectural Design module.
The Process View will be discussed in the Describe Concurrency module.
The Deployment View will be discussed in the Describe Distribution module.
The Implementation View will be discussed briefly in the Architectural Design module; however, the Implementation View is developed during Implementation and is thus considered out of scope for this analysis and design course.
Logical View
Implementation View
End-user
Functionality
Analysts/Designers
Structure
Programmers
Software management
Use-Case View
Process View
Deployment View
Performance
Scalability
Throughput
System integrators
System engineering
System topology
Delivery, installation
communication
This diagram describes how architectural views model software architecture.
Projects have multiple stakeholders – each with unique concerns and views.
Here we define a 4+1 architectural view – a series of simplified descriptions
views (abstractions) from particular perspectives – omitting entities not relevant to this view.
A project may document all views, a subset, or additional views. But EACH VIEW is
complete from the perspective of specific stakeholder(s).
Module 5 - Analysis and Design Overview

15. Analysis & Design Overview Topics
OOADv4.2 Instructor Notes
Analysis & Design Overview Topics
Key Concepts
Analysis & Design Workflow Overview
Module 5 - Analysis and Design Overview

16. Analysis and Design Workflow
OOADv4.2 Instructor Notes
Analysis and Design Workflow
Walk the students through the workflow diagram, reviewing the meaning of the representational icons (e.g., workers, activities, etc.). Activities can be considered operations on the workers.
The order shown is not the only order in which the activities can be executed. It is an idealized picture.
Note the emphasis on architecture -- how it is developed first and then drives the rest of the other activities -- Architecture-driven at its finest!
The process as described in this course develops a design model, not a separate analysis model. To maintain a separate analysis model, some modifications to the process would be necessary, the discussion of which is out of the scope of this course.
Emphasize the Use-Case Analysis activity and how it describes a process for finding classes and objects from use cases. Some people have called it: 'closing the traceability gap’ -- use cases and scenario's help you get from requirements to objects.
Architectural
Analysis
Architectural
Describe
Describe
Review the
Architecture
Architect
Concurrency
Architecture
Design
Distribution
Reviewer
Subsystem Design
Use-Case
Analysis
(Analysis Modeling)
Use-Case
Review the
Design
Design
Designer
Design
Reviewer
(Interaction Diagrams
And Class Diagrams)
Use Case Realizations 
Class
Design
Remember, we start off with the Use Case Model and Supplementary info (Glossary;
Domain model; business model…) from Requirements Workflow and ultimately end up with a Design Model – an abstraction of the source code produced via an Analysis and Design Workflow.
Design activities center around architecture – the main focus of early design iterations.
Look at the activities of the architect and the designer (roles!!)
Module 5 - Analysis and Design Overview

17. The Software Architect
OOADv4.2 Instructor Notes
The Software Architect
Establishes the overall structure for each architectural view: This includes layers, if a layered approach…
the decomposition of the view,
the grouping of elements, and the interfaces between these major groupings.
In contrast with the other workers, the Architect's view is one of breadth, as opposed to depth
Frequently, the architect is the most experienced member of the team. (likely a good idea)
Architect must constantly observe all design activities to ensure that they are compatible with the overall architecture.
Module 5 - Analysis and Design Overview

18. OOADv4.2 Instructor Notes
The Designer
Defines the responsibilities, operations, attributes, and relationships of one or several classes and determines how they should be adjusted (modified, refined, morphed into other design / implementation artifacts (like packages, subsystems, etc.)) to support the implementation environment with the software architecture.
Must be compatible with overall architecture!
 Is usually responsible for Use-Case Realizations, in order to ensure the overall consistency of how a particular use case is realized using design elements.
Software Architect works carefully here to ensure compatibility!!
Module 5 - Analysis and Design Overview

19. OOADv4.2 Instructor Notes
The Database Designer
Defines the tables, indexes, views, constraints, triggers, stored procedures, table spaces or storage parameters, and other database-specific constructs needed to store, retrieve, and delete persistent objects.
Will be familiar with design / implementation support from, say, APIs, such as java.sql, etc.
This information is maintained in the Data Model.
Module 5 - Analysis and Design Overview

20. OOADv4.2 Instructor Notes
Reviewers
Architecture Reviewer plans and conducts the formal reviews of the software architecture in general.
The Design reviewer plans and conducts the formal reviews of the design model.
Can be project manager in consultation with these other roles…Team efforts!
Module 5 - Analysis and Design Overview

21. Workers and Their Responsibilities
OOADv4.2 Instructor Notes
Workers and Their Responsibilities
Architect
Architect: Establishes overall
structure of each of the views.
Decomposition; Breadth
Designer
Use-Case
Realization
Again, the focus of this course is on the activities and artifacts of the Designer.
Design Model
Package/ Subsystem
Software Architecture
Document
Class
Design
Reviewer
DB Designer: Designs tables,
stored procedures, Indexes,
etc. needed to store, maintain
persistent data
Data Model
Database Designer
Architecture
Reviewer
Designer: Responsible for the operations, attributes, and
relationships of one or several classes and how
they are implemented; Design packages; UC Realizations
Module 5 - Analysis and Design Overview

22. Review: Analysis and Design Overview
OOADv4.2 Instructor Notes
Review: Analysis and Design Overview
What is the purpose of Analysis and Design?
What are the input and output artifacts?
Name and briefly describe the 4+1 Views of Architecture.
What is the difference between Analysis and Design?
What is the purpose of Architectural Analysis?
What is the purpose of Use-Case Analysis?
What are the major responsibilities of the Architect, Developer, Database workers?
Module 5 - Analysis and Design Overview