Upload
prosper-barrett
View
218
Download
1
Tags:
Embed Size (px)
Citation preview
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
1
Use Case Driven Object Use Case Driven Object Modeling -- A 99% Fat-Modeling -- A 99% Fat-Free ApproachFree Approach
Doug RosenbergDoug Rosenberg
ICONIX Software Engineering, Inc.ICONIX Software Engineering, Inc.
http://www.iconixsw.comhttp://www.iconixsw.com
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
2
HistoryHistory
In The Beginning, There Was OMT, In The Beginning, There Was OMT, Objectory, and The Booch MethodObjectory, and The Booch Method
Let There Be A Unified NotationLet There Be A Unified Notation All that notation and no process?All that notation and no process? Let There Be RUPLet There Be RUP Help, all this process is paralyzing us!Help, all this process is paralyzing us! New Idea -- Code and You’re Done!New Idea -- Code and You’re Done! There’s another way…Do OOAD but Keep There’s another way…Do OOAD but Keep
It SimpleIt Simple
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
3
In The Beginning, There Was In The Beginning, There Was OMT, Objectory, and The OMT, Objectory, and The Booch MethodBooch Method
Three very different kinds of OO Three very different kinds of OO methods.methods.
Each method had strengths.Each method had strengths. Each method had weaknesses.Each method had weaknesses. Much of the original modeling Much of the original modeling
knowledge from the OMT, Objectory, knowledge from the OMT, Objectory, and Booch methods is not repeated in and Booch methods is not repeated in the current UML literature, which mostly the current UML literature, which mostly focuses on notation.focuses on notation.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
4
Each method had Each method had strengthsstrengths
Rumbaugh Rumbaugh Domain object (problem space) Domain object (problem space) modelsmodels
Jacobson Jacobson User-driven solution space models User-driven solution space models Booch Booch Detailed design-level models Detailed design-level models
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
5
Each method had Each method had weaknessesweaknesses
Rumbaugh: strong for problem space; Rumbaugh: strong for problem space; simplistic for solution spacesimplistic for solution space
Jacobson: deemphasized domain modeling; Jacobson: deemphasized domain modeling; didn’t offer enough for detailed OODdidn’t offer enough for detailed OOD
Booch: targeted squarely at OOD; not strong Booch: targeted squarely at OOD; not strong with regard to analysiswith regard to analysis
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
6
Let There Be A Unified Let There Be A Unified NotationNotation
Jacobson Booch
Jacobson
Rumbaugh
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
7
All that notation and no All that notation and no process?process?
I can draw all these diagrams, but how I can draw all these diagrams, but how do they all relate to each other?do they all relate to each other?
80% of modeling can be done with 20% 80% of modeling can be done with 20% of the UML. of the UML. Which 20% was that again?Which 20% was that again?
We’re supposed to be “Use Case Driven” We’re supposed to be “Use Case Driven” but...but...
““How do we get from Use Cases to How do we get from Use Cases to Code???”Code???”
We’re “thrashing” with use casesWe’re “thrashing” with use cases
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
8
Let There Be RUPLet There Be RUP
““Marketing-Driven” processMarketing-Driven” process Hey, we have this big suite of tools…..Hey, we have this big suite of tools….. But nobody understands how the tools But nobody understands how the tools
work togetherwork together We can repackage this Objectory We can repackage this Objectory
Process…Process… And use THAT to explain how the tool And use THAT to explain how the tool
suite fits together!suite fits together!
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
9
Theory vs. practiceTheory vs. practice
In theory, there is no difference between In theory, there is no difference between theory and practice, but in practice there is.theory and practice, but in practice there is.
In practice, there’s never enough time for In practice, there’s never enough time for modeling.modeling.
The ICONIX Process is a STREAMLINED The ICONIX Process is a STREAMLINED approach to software development that approach to software development that helps you get from use cases to code helps you get from use cases to code quickly and efficiently, using a concentrated quickly and efficiently, using a concentrated subset of the UML and related tools and subset of the UML and related tools and techniques.techniques.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
10
Keep it simple!Keep it simple!
Open window (A) and fly kite (B). String (C) lifts small door (D) allowing moths (E) to escape Open window (A) and fly kite (B). String (C) lifts small door (D) allowing moths (E) to escape and eat red flannel shirt (F).and eat red flannel shirt (F).
As weight of shirt becomes less, shoe (G) steps on switch (H) which heats electric iron (I) and As weight of shirt becomes less, shoe (G) steps on switch (H) which heats electric iron (I) and burns hole in pants (J).burns hole in pants (J).
Smoke (K) enters hole in tree (L), smoking out opossum (M) which jumps into basket (N), Smoke (K) enters hole in tree (L), smoking out opossum (M) which jumps into basket (N), pulling rope (O) and liftingpulling rope (O) and lifting
cage (P), allowing woodpecker (Q) to chew wood from pencil (R), exposing lead. Emergency cage (P), allowing woodpecker (Q) to chew wood from pencil (R), exposing lead. Emergency knife (S) is always handy knife (S) is always handy
in case opossum or the woodpecker gets sick and can't work.in case opossum or the woodpecker gets sick and can't work.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
11
Help, all this process is Help, all this process is paralyzing us!paralyzing us!
RUP is BIG RUP is BIG When you need an iteration plan planner to plan the When you need an iteration plan planner to plan the
plan, you’re dealing with a BIG processplan, you’re dealing with a BIG process ““High in Saturated Fat” -- like Eggs Benedict, with High in Saturated Fat” -- like Eggs Benedict, with
Chocolate Mousse for dessertChocolate Mousse for dessert Analysis Paralysis -- the great crippler of young software Analysis Paralysis -- the great crippler of young software
projectsprojects Aren’t “artifacts” what the archaeologists dig up after Aren’t “artifacts” what the archaeologists dig up after
everybody’s dead?everybody’s dead? Many projects don’t need all of RUP -- TAILOR IT to fitMany projects don’t need all of RUP -- TAILOR IT to fit We’re STILL “thrashing” with use cases!We’re STILL “thrashing” with use cases!
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
12
New Idea -- Code and You’re New Idea -- Code and You’re Done!Done!
Knee-Jerk (Extreme) response to too much Knee-Jerk (Extreme) response to too much processprocess
““At least we won’t get bit by Analysis Paralysis”At least we won’t get bit by Analysis Paralysis” Code Early and Code Often Code Early and Code Often
(is this really a NEW (is this really a NEW paradigm?)paradigm?)
Catchy slogans…Catchy slogans… ““Oral Documentation, ”,“The Design Is The Code”, Oral Documentation, ”,“The Design Is The Code”,
“Design by Testing” etc.“Design by Testing” etc. ““Tofu Burger with Wheat Grass juice” -- no fat, Tofu Burger with Wheat Grass juice” -- no fat,
but...but...
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
13
There’s another way…There’s another way…Do OOAD but Keep It Do OOAD but Keep It SimpleSimple
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
14
Let’s work backwards from Let’s work backwards from codecode
Let’s assume that we’ve done a little Let’s assume that we’ve done a little prototyping, and started to write some use prototyping, and started to write some use cases.cases.
But code is our desired destination.But code is our desired destination.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
15
Before we get to code...Before we get to code...
We need a complete set of classes, We need a complete set of classes, with accompanying attributes and with accompanying attributes and methods.methods.
We show this information on We show this information on design-level class diagrams.design-level class diagrams.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
16
Design-Level Class Design-Level Class DiagramsDiagrams
Our design-level class diagrams serve as Our design-level class diagrams serve as the structure for our code.the structure for our code.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
17
Before we have classes Before we have classes with attributes and with attributes and methods, though…methods, though…
We need to allocate behavior into our We need to allocate behavior into our classesclasses
We have only enough information to We have only enough information to make good decisions about which classes make good decisions about which classes are responsible for which methods while are responsible for which methods while we are drawing sequence diagrams.we are drawing sequence diagrams.
So, we need to draw a sequence So, we need to draw a sequence diagram for each use case.diagram for each use case.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
18
Sequence DiagramsSequence Diagrams
We allocate methods to classes as we We allocate methods to classes as we draw sequence diagrams.draw sequence diagrams.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
19
Before we do sequence Before we do sequence diagrams, though...diagrams, though...
We need to have a good idea about what We need to have a good idea about what objects will be performing in which use objects will be performing in which use case, and what functions the system will case, and what functions the system will perform as a result of user actions.perform as a result of user actions.
We get this information from robustness We get this information from robustness diagrams, the result of robustness diagrams, the result of robustness analysis.analysis.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
20
Robustness Diagrams -- the Robustness Diagrams -- the missing link!missing link!
We discover new objects, and add We discover new objects, and add attributes to classes, as we draw attributes to classes, as we draw robustness diagrams.robustness diagrams.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
21
But we can’t draw But we can’t draw robustness diagrams robustness diagrams before...before...
We describe system usage We describe system usage in the context of the in the context of the object modelobject model..
This means that we don’t write abstract, vague This means that we don’t write abstract, vague use cases that we can’t design from.use cases that we can’t design from.
Instead, we need to write use case text that Instead, we need to write use case text that references the names of objects in the problem references the names of objects in the problem domain.domain.
We also reference the names of "boundary We also reference the names of "boundary objects" in the use case text.objects" in the use case text.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
22
First, though...First, though...
We need to identify the main We need to identify the main abstractions that are present in the abstractions that are present in the problem domain.problem domain.
In other words, we need a domain In other words, we need a domain model.model.
We show our domain model on class We show our domain model on class diagrams.diagrams.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
24
Refining our class Refining our class diagramsdiagrams
We'll refine our (static) analysis level We'll refine our (static) analysis level class diagrams (our domain model) class diagrams (our domain model) continuously as we explore the dynamic continuously as we explore the dynamic behavior of the system in more and more behavior of the system in more and more detail during analysis and design.detail during analysis and design.
This will ultimately result in our design-This will ultimately result in our design-level class diagrams, which we can code level class diagrams, which we can code from.from.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
25
The ICONIX ProcessThe ICONIX Process
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
26
Key features of the ICONIX Key features of the ICONIX ProcessProcess
Avoidance of analysis paralysisAvoidance of analysis paralysis Streamlined usage of the UMLStreamlined usage of the UML Minimalist yet sufficientMinimalist yet sufficient High degree of traceabilityHigh degree of traceability Based on fundamental OOAD Based on fundamental OOAD
questionsquestions Work from the outside inWork from the outside in Work from the inside outWork from the inside out
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
27
High degree of traceabilityHigh degree of traceability
Courses of action describe what goes on Courses of action describe what goes on in a use case (normally and in in a use case (normally and in exceptional cases)exceptional cases)
Robustness diagrams bridge the Robustness diagrams bridge the “what/how” gap“what/how” gap
Sequence diagrams are done for each use Sequence diagrams are done for each use casecase
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
28
Robustness diagrams bridge Robustness diagrams bridge the “what/how” gapthe “what/how” gap
Most current UML texts do not address Most current UML texts do not address crossing this what/how gap.crossing this what/how gap.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
29
Based on fundamental OOAD Based on fundamental OOAD questionsquestions
What are the users doing? (Jacobson)What are the users doing? (Jacobson) What are the objects in the real world? What are the objects in the real world?
(Rumbaugh)(Rumbaugh) What objects are needed for each use case? What objects are needed for each use case?
(Jacobson)(Jacobson) How do the objects collaborate with each How do the objects collaborate with each
other? (Jacobson and Booch)other? (Jacobson and Booch) How will we implement real-time control? How will we implement real-time control?
(state models)(state models) How are we really going to build this How are we really going to build this
system? (Booch)system? (Booch)
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
30
Work from the outside inWork from the outside in
Objectory and the Unified Process are use-case driven (outside-in)By keeping use cases as the primary unit of system decomposition, we stay user-focusedBy using prototyping in conjunction with use cases, we stay user-focused
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
31
Work from the inside outWork from the inside out
OMT was object driven OMT was object driven (inside-out)(inside-out)
OMT models == real-world OMT models == real-world (domain)(domain)
Some upfront thought about Some upfront thought about the problem domain makes the problem domain makes everything easiereverything easier
Reuse across systems Reuse across systems comes from the domain comes from the domain modelmodel
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
32
Update your domain Update your domain modelmodel
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
33
Use robustness analysis to Use robustness analysis to update your static modelupdate your static model
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
34
Use the robustness diagram Use the robustness diagram to get the sequence diagram to get the sequence diagram startedstarted
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
35
Use the Sequence Use the Sequence Diagram to Allocate Diagram to Allocate BehaviorBehavior
Which class does an operation Which class does an operation belong in?belong in?
Halbert and O’Brien criteria:Halbert and O’Brien criteria: Reusability: does it make this class more Reusability: does it make this class more
general?general? Applicability: does it fit? Is it relevant?Applicability: does it fit? Is it relevant? Complexity: is it easier to build it here or Complexity: is it easier to build it here or
elsewhere?elsewhere? Implementation knowledge: does it rely on Implementation knowledge: does it rely on
internal details?internal details?
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
36
Update your static model, Update your static model, againagain
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
37
Add “Booch stuff” to the Add “Booch stuff” to the analysis-level UML class analysis-level UML class diagramdiagram
Booch constructs show Booch constructs show additional design informationadditional design information
abstract classes, parameterized abstract classes, parameterized and instantiated classesand instantiated classes
aggregation vs compositionaggregation vs composition friend, virtual, and static friend, virtual, and static
relationshipsrelationships
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
38
Drill down from the high-Drill down from the high-level models to detailed level models to detailed OODOOD
Booch provided the most Booch provided the most comprehensive OOD methodcomprehensive OOD method
Only OOD method to thoroughly treat Only OOD method to thoroughly treat software packaging, physical software packaging, physical assignment across multiple processorsassignment across multiple processors
Especially strong for details of message Especially strong for details of message synchronization, instantiation, synchronization, instantiation, parameter passingparameter passing
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
39
Design-Level Class Design-Level Class DiagramsDiagrams
What is a “quality” class?What is a “quality” class? Parameterized and instantiated classesParameterized and instantiated classes Design patternsDesign patterns
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
40
What is a “quality” class?What is a “quality” class?
Coupling: should be loosely coupled Coupling: should be loosely coupled with other classeswith other classes
Cohesion: should be highly cohesiveCohesion: should be highly cohesive Sufficiency: does it do enough?Sufficiency: does it do enough? Completeness: does it cover all the Completeness: does it cover all the
relevant a abstractions?relevant a abstractions? Primitiveness: stick to basic operationsPrimitiveness: stick to basic operations
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
41
Design patternsDesign patterns
Component
Operation()Add(Component)Remove(Component)GetChild(int)
Client
Leaf
Operation()
Component
Operation()Add(Component)
Remove(Component)GetChild(int)
children
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
42
Code and TestCode and Test
Component Diagrams show packaging Component Diagrams show packaging of classes into distributable unitsof classes into distributable units
Usage scenarios (use cases) become Usage scenarios (use cases) become test scenarios (test cases)test scenarios (test cases)
We can link requirements, test cases We can link requirements, test cases and other software quality assurance and other software quality assurance (SQA) information to these models and (SQA) information to these models and follow them through the design.follow them through the design.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
43
Component Diagrams show Component Diagrams show packaging of classes into packaging of classes into distributable unitsdistributable units
Components are physical, replaceable Components are physical, replaceable parts of a system that conform to, and parts of a system that conform to, and provide the realization of, interfaces.provide the realization of, interfaces.
Examples: dynamic link library (DLL), Examples: dynamic link library (DLL), COM+ object, Enterprise Java Bean (EJB)COM+ object, Enterprise Java Bean (EJB)
Unlike classes, components are Unlike classes, components are physical, not logical, and components physical, not logical, and components have operations that are reachable only have operations that are reachable only through their interfaces.through their interfaces.
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
44
Tracing requirementsTracing requirements
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
45
We CAN avoid Analysis We CAN avoid Analysis Paralysis without skipping Paralysis without skipping OOADOOAD
We want the MINIMAL YET SUFFICIENT amount of processWe want the MINIMAL YET SUFFICIENT amount of process Start small and tailor up as needed [opposite from RUP)Start small and tailor up as needed [opposite from RUP) Best effort to “get it right the first time” [opposite from Best effort to “get it right the first time” [opposite from
XP]XP] The ICONIX approach was synthesized from OMT, The ICONIX approach was synthesized from OMT,
Objectory, Booch starting in 1993Objectory, Booch starting in 1993 It has been refined over 7+ years and hundreds of It has been refined over 7+ years and hundreds of
projectsprojects It works. And it scales.It works. And it scales. Book: “Use Case Driven Object Modeling with UML -- Book: “Use Case Driven Object Modeling with UML --
A Practical Approach” Addison-Wesley 1999 A Practical Approach” Addison-Wesley 1999
Copyright 2000 ICONIX Software Engineering, Inc. www.iconixsw.com
46
For further informationFor further information
EMAIL: [email protected]: [email protected] http://www.iconixsw.com/UMLBook.htmlhttp://www.iconixsw.com/UMLBook.html http://www.iconixsw.com/http://www.iconixsw.com/
UMLTraining.htmlUMLTraining.html Phone: 310-458-0092Phone: 310-458-0092 FAX: 310-396-3454FAX: 310-396-3454