Download - 05 UML1 Intro
-
7/30/2019 05 UML1 Intro
1/24
1
Object Oriented Analysis and Design
UsingUnified Modeling Language (UML)
-
7/30/2019 05 UML1 Intro
2/24
2
Introduction
Object oriented analysis and design (OOAD) isbeing considered and widely used as a solution ofmany problems of SE.
UML is a generic set of notations (not
methodology, not process) that can be adoptedto suit organizational requirements. We willlearn how to apply UML in OOAD.
Some people do OOP after structured A&D, but
how? OOAD is required for OOP.
-
7/30/2019 05 UML1 Intro
3/24
3
Agenda
Learn the UML notation (may be not everything)
Apply UML in an OOAD development
process (UP/RUP) adopted by Craig Larman.
-
7/30/2019 05 UML1 Intro
4/24
4
The Birth of UML
Unified efforts:
Grady BoochOOAD:1994
Ivar JacobsonOOSE:1994
James RumbaughOMT:1991
UML 1.5upgrades 2.0
Notation NotationUse Cases
Other contributions include:
Sally Shlaer and Steve Mellor (pair of book (1989 &1991))
Peter Coad and Ed Yourdon (1991, 1995)
Smalltalk community came up with Responsibility-driven design (Wirfs-Brook, etal.1990) and Class Respon-Collab (CRC) cards (Beck and Cunningham 1989).
UML is a modeling language (not methodology): Methodology (in principle)consist ofboth modeling language and a process.
Modeling language is (mainly graphical) notation and a process is a sequence of
steps to apply notation.
Successor to the wave of OOA&D methods that appeared in late 80s andearly 90s.
-
7/30/2019 05 UML1 Intro
5/24
5
The Birth of UML contd.. During OOPSLA 94methods scene was pretty split and competitive. All of
the above mentioned methods were similar, yet contained annoying minor
differences among them. Talk ofstandardization had surfaced, but nobody seemed willing. A team from
OMG (Obj-Manag-Group) tried to but got protest from all methodologists. (Youcan negotiate with terrorist but not with methodologist).
OOPSLA 95Grady and Jim presented their first merged Unified Methodversion 0.8. More significantly Ivar Jacobson joined the Unified team.
During 1996 the three (Grady, Jim, Ivar) referred to as the three amigos, workedon their method UML.
In Jan, 1997various Orgs submitted proposals for method standardization to theOMG task force set in 1996. Rational started with UML ver 1.0 as theirproposal and ended up as OMG UML 1.5, and OMG teams adding upgrades
UML 2.0; UML 2.0 Standard Officially Adopted at OMG Technical Meeting in Paris- June 12,
2003
-
7/30/2019 05 UML1 Intro
6/24
6
How to Apply then?
UMLArtifa
ct
UML
Artifa
ct
UML
Artifact
UM
L
Arti
fact
UML
Artifact
UM
L
Artif
act
Analysis
UMLArtifa
ct
UM
L
Artif
act
UML
Artifac
t
UML
Artifac
t
UML
Artifa
ct
UML
Artifac
t
Design
The UMLThe Unified Modeling Language (UML) is a language for
specifying, visualizing, constructing, and documenting the
artifacts of software systems, as well as for business modelingand other non-software systems[OMGO1].
-
7/30/2019 05 UML1 Intro
7/24
7
Object Oriented Analysis and Design
Analysis
Investigation ofthe problem
Design
LogicalSolution
Construction
Code
Domain
Concepts,
Objects
Book
Title
Author
Print
Design
Class
Public class Book
{
Private String title;
public void print ();
}
OO
Language
Code
-
7/30/2019 05 UML1 Intro
8/24
8
Object Versus Function-Oriented Analysis Design
Decomposition is the primary strategy to deal with the complexity of S/W project.
Functional decomposition is common in the structured analysis and design. System
can be functionally divided into sub-functions differently by different people. Thats why it is more commonly called as Analysis & Design.
Thats why a functional hierarchy exists.
Object orienteddecomposition has been mentioned in few (Larman) books but
Object identification or classification are most suitable terms used in the OOA.
Thats why Object Modelingis more commonly used term as objects are identified
(they are already there) and modeled in a language rather defined by the analyst.
Thats why decomposition hierarchydoes not exist but a collaboration between
objects.
Catalog
Book Magazine
Librarian
Classification/Decomposition
by Objects/concepts
OO A&D
Lib System
Cataloging AcquisitionCirculation
Decomposition by functions/processes
Structured A&D
-
7/30/2019 05 UML1 Intro
9/24
9
More important than following an official process:
-A developer acquire skill in how to create a good design,-mastering a set of principles and heuristics related to
identifying and abstracting suitable objects and to assigning
responsibilities to them.
Recommended Process and Models - RPM
The UML standardizes artifacts and notation, but does not define a standard process.
Reasons include:
(1) To increase the likelihood ofwide spread acceptance of a standard modeling notation
without having to commit to a standard process.
(2) There is significant variability in what constitutes an appropriate process, dependingupon the staff skills, nature of the problem/project, tools, etc.
A robust modeling language and a process both are important and can be independent.
The UML is a language for modeling; it does not guide a developer
in how to do object-oriented analysis and design, or what
development process to follow.
-
7/30/2019 05 UML1 Intro
10/24
10
Unified Process
1. The Unified Process [JBR99] has emerged as a popular softwaredevelopment process forbuilding object-oriented systems. In
particular, the Rational Unified Process orRUP [Kruchten00] , a
detailed refinement of the Unified Process, has been widely
adopted.
2. The Unified Process (UP) combines commonly accepted bestpractices, such as an interactive lifecycle and risk-driven
development, into a cohesive and well-documenteddescription.3. Interactive and incremental development.
Additional UP Best Practices and Concepts1. UP is short timeboxed iterative, adaptive development.2. Another implicit, but core, UP idea is the use of object
technologies, including OOA/D and OOP.
-
7/30/2019 05 UML1 Intro
11/24
11
Some additional best practices and key concepts in theUP include:
Tackle high-risk and high-value issues in earlyiterations
Continuously engage users for evaluation, feedback,and requirements
Builds a cohesive, core architecture in early iterations Continuously verify quality; test early, often, and
realistically.
Apply use cases
Model software visually (with the UML) Carefully manage requirements
Practice change request and configurationmanagement
-
7/30/2019 05 UML1 Intro
12/24
12
At high level, major steps in delivering an application:
1. Plan and Elaborate---planing, defining requirements, building prototypes,
and so on.
2. Build--- the implementation of the system.
3. Deploy--- the implementation of the system into use.
Build DeployPlan andElaborate
2. Create PreliminaryInvestigation Report
3. Define Requirements
9. Refine Plan7. Define Draft
Conceptual Modelc
4. Record Termsin Glossary
a6. Define Use Cases
(high level & essential)
1. Define Draft Plan
5. ImplementPrototype b, d
a. ongoing
b. optionalc. may deferd. varied order
8. Define Draft SystemArchitecture a, c, d
Notes
OLD- Macro-level Steps
-
7/30/2019 05 UML1 Intro
13/24
13
Development
Cycle 1
Sync.
ArtifactsAnalyze Design Test
Refine
PlanConstruct
Development
Cycle 2...
BuildPlan and
ElaborateDeploy
Iterative development cycles are organized by use case requirements
One cycle 2weeks to 2 months
OLD- An iterative life-cycle
-
7/30/2019 05 UML1 Intro
14/24
14
UP Artifact and Process ContextAs illustrated in Figure, use cases influence many UP artifacts.
Sample UP Artifacts
BusinessModeling
Requirements
Design
ProjectManagement
Test
Partial
artifacts,refined in
each iteration
Domain Model
Vision Supplementary
Specification
Glossary
Terms, attributes, validation
Terms, attributes
relationships
Use-Case Model
requirementsSoftware Architecture Doc.
Requirements, I/O
events
Environment
Requirements,
priorities
Software Dev. Plan
Acceptance tests
Test Plan
Development Case
Figure: Sample UP artifact influence
Design Model
-
7/30/2019 05 UML1 Intro
15/24
15
UP Phases
A UP project organizes the work and iterations across
four major phases: Inception approximate vision, business case, scope,
vague estimates. Not a requirements phase; rather, itis a kind of feasibility phase.
Elaboration refined vision, iterative implementation
of the core architecture, resolution of high risks,identification of most requirements and scope, morerealistic estimates. Not requirements or design phase;rather, it is a phase where the core architecture isiteratively implemented, and high risk issues are
mitigated Construction iterative implementation of theremaining lower risk and easier elements, andpreparation for deployment.
Transition beta tests, deployment.
-
7/30/2019 05 UML1 Intro
16/24
16
Feedback on Evolutions
A two year study reported (in the MIT) of
successful software projectsidentified fourcommon factors for success[MacCormack01] ;
1) iterative development (was first on the list)
2) at least daily incorporation of new code into acomplete system build, and
3) rapid feedback on design changes (viatesting); and
4) early focus on building and providing acohesive architecture.
-
7/30/2019 05 UML1 Intro
17/24
17
You Didnt Understand
You Know You Didnt Understand the UP When
You think that inception = requirements, elaboration =
design, and construction = implementation (that is,
superimposing a waterfall lifecycle on to the UP.
You believe that a suitable iteration length is four
months long, rather than four weeks long (excludingprojects with hundreds of developers).
You try to plan a project in detail from start to finish;
you try to speculatively predict all the iterations, and
what should happen in each one.
You want believable plans and estimates for projects
before the elaboration phase in finished.
-
7/30/2019 05 UML1 Intro
18/24
18
Discipline Artifact
Iteration
Incep.
I1
Elab.
E1En
Cons
t.
C1-
Cn
Trans.
T1-
T2
Business Modeling Domain Model s
Use-Case Model s r
Vision s r
Supplementary Specification s r
Glossary s r
Design Design Model s r
SW Architecture Document s
Data Model s r
Implementation Implementation Model s r r
Project-Management SW Development Plan s r r r
Testing Test Model s r
Environment* Development Case* s r
s-start; r-refine
-
7/30/2019 05 UML1 Intro
19/24
19
Inception What Artifacts May Start in Inception?
Artifact Comment
Vision and Business Case Describes the high-level goals and constraints, the
business case, and provides an executive
summary.
Use-Case Model Describes the functional requirements, and related
non-functional requirements.
Supplementary Specification Describes other requirements.
Glossary Key domain terminology.
Risk List & Risk
Management
Describes the business, technical, resources, schedule
risks, and ideas for their mitigation or response.
Prototypes and proof-of-concepts To clarify the vision, and validate technical ideas.
Iteration Plan Describes what to do in the first elaboration iteration.
-
7/30/2019 05 UML1 Intro
20/24
20
Elaboration
ElaborationIteration 1
OOD Translating design to CodeOOA
A l i UML
-
7/30/2019 05 UML1 Intro
21/24
21
Assigning Responsibilities
The most single important ability in OOAD is to skillfully assign responsibilities
to software components.
Nine fundamental responsibility assignment principles, codified in the GRASP
patterns, are presented and applied to help master how to assign responsibilities.
Business Processes
Business Object-oriented Associated
Analogy Analysis & Design Documents
What are the busi- Requirements analysis Use cases
ness processes
What a business must do: its business processes---in order to keep running
This is analogous to requirement analysis in which business processes and requirements are
discovered and expresses in use cases.
Applying UML
-
7/30/2019 05 UML1 Intro
22/24
22
What are the roles in the organization
Business Object-oriented Associated
Analogy Analysis & Design Documents
What are the busi- Requirements analysis Use cases
ness processes
What are the empl- Domain analysis Conceptual/
Domain
oyees roles Model
Customer OrderSale
RepresentativeThings in the domain: Concepts
-
7/30/2019 05 UML1 Intro
23/24
23
Who does What? How do they collaborate
Business Object-oriented Associated
Analogy Analysis & Design Documents
What are the busi- Requirements analysis Use cases
ness processes
What are the empl- Domain analysis Conceptual/Domain
oyees roles Model
Who is responsible Responsibility Design class
for what?How do assignment, interac- diagrams,
they interact? tions design collaboration
diagrams
-
7/30/2019 05 UML1 Intro
24/24
24
Requirements
(System Functions)Plan and Elaborate
Processes (Use Case)
Ranking/Scheduling
Conceptual Model
AnalysisGlossary
Behavior (System
Sequence
Dgm/Contracts)
Real Uses casesCollaboration Dgm
Design Class Dgm
Design
?Our Road Map