Unified Object Modeling with UML

Unified Object Modeling with UML

Use Case Driven Object Modeling -- A 99% FatFree Approach Doug Rosenberg ICONIX Software Engineering, Inc. http://www.iconixsw.com Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 1 History

In The Beginning, There Was OMT, Objectory, and The Booch Method Let There Be A Unified Notation All that notation and no process? Let There Be RUP Help, all this process is paralyzing us! New Idea -- Code and Youre Done! Theres another wayDo OOAD but Keep It Simple Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 2 In The Beginning, There Was

OMT, Objectory, and The Booch Method Three very different kinds of OO methods. Each method had strengths. Each method had weaknesses. Much of the original modeling knowledge from the OMT, Objectory, and Booch methods is not repeated in the current UML literature, which mostly focuses on notation. Copyright 2000 ICONIX Software Engine

ering, Inc. www.iconixsw.com 3 Each method had strengths Rumbaugh Domain object (problem space) models Jacobson User-driven solution space models Booch Detailed design-level models Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com

4 Each method had weaknesses Rumbaugh: strong for problem space; simplistic for solution space Jacobson: deemphasized domain modeling; didnt offer enough for detailed OOD Booch: targeted squarely at OOD; not strong with regard to analysis

Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 5 Let There Be A Unified Notation Jacobson Jacobson Booch Rumbaugh Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com

6 All that notation and no process? I can draw all these diagrams, but how do they all relate to each other? 80% of modeling can be done with 20% of the UML. Which 20% was that again?

Were supposed to be Use Case Driven but... How do we get from Use Cases to Code??? Were thrashing with use cases Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 7 Let There Be RUP

Marketing-Driven process Hey, we have this big suite of tools.. But nobody understands how the tools work together We can repackage this Objectory Process And use THAT to explain how the tool suite fits together! Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 8 Theory vs. practice

In theory, there is no difference between theory and practice, but in practice there is. In practice, theres never enough time for modeling. The ICONIX Process is a STREAMLINED approach to software development that helps you get from use cases to code quickly and efficiently, using a concentrated subset of the UML and related tools and techniques. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 9 Help, all this process is

paralyzing us! RUP is BIG When you need an iteration plan planner to plan the plan, youre dealing with a BIG process Analysis Paralysis -- the great crippler of young software projects Many projects dont need all of RUP -- TAILOR IT to fit

Were STILL thrashing with use cases! Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 10 New Idea -- Code and Youre Done! At least we wont get bit by Analysis Paralysis Code Early and Code Often

(is this really a NEW paradigm?) Catchy slogans The Design Is The Code, Design by Testing etc. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 11 Theres another way Do OOAD but Keep It Simple Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 12

Lets work backwards from code Lets assume that weve done a little prototyping, and started to write some use cases. But code is our desired destination. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 13 Before we get to code... We need a complete set of classes, with accompanying attributes and

methods. We show this information on designlevel class diagrams. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 14 Design-Level Class Diagrams Our design-level class diagrams serve as the structure for our code. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com

15 Before we have classes with attributes and methods, though We need to allocate behavior into our classes We have only enough information to make good decisions about which classes are responsible for which methods while we are drawing sequence diagrams. So, we need to draw a sequence diagram

for each use case. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 16 Sequence Diagrams We allocate methods to classes as we draw sequence diagrams. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 17 Before we do sequence diagrams, though... We

need to have a good idea about what objects will be performing in which use case, and what functions the system will perform as a result of user actions. We get this information from robustness diagrams, the result of robustness analysis. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 18 Robustness Diagrams -- the missing link!

We discover new objects, and add attributes to classes, as we draw robustness diagrams. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 19 But we cant draw robustness diagrams before... We describe system usage in the context of the object model. This means that we dont write abstract, vague

use cases that we cant design from. Instead, we need to write use case text that references the names of objects in the problem domain. We also reference the names of "boundary objects" in the use case text. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 20 First, though... We need to identify the main abstractions that are present in the

problem domain. In other words, we need a domain model. We show our domain model on class diagrams. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 21 Domain Model

Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 22 Refining our class diagrams We'll refine our (static) analysis level class diagrams (our domain model) continuously as we explore the dynamic behavior of the system in more and more detail during analysis and design. This will ultimately result in our designlevel class diagrams, which we can code

from. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 23 The ICONIX Process Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 24 Key features of the ICONIX Process Avoidance

of analysis paralysis Streamlined usage of the UML Minimalist yet sufficient High degree of traceability Based on fundamental OOAD questions Work from the outside in Work from the inside out Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 25 High degree of traceability

Courses of action describe what goes on in a use case (normally and in exceptional cases) Robustness diagrams bridge the what/how gap Sequence diagrams are done for each use case Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 26

Robustness diagrams bridge the what/how gap Most current UML texts do not address crossing this what/how gap. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 27 Based on fundamental OOAD questions

What are the users doing? (Jacobson) What are the objects in the real world? (Rumbaugh) What objects are needed for each use case? (Jacobson) How do the objects collaborate with each other? (Jacobson and Booch) How are we really going to build this system? (Booch) Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 28 Work from the outside in

Objectory and the Unified Process are usecase driven (outside-in) By keeping use cases as the primary unit of system decomposition, we stay user-focused By using prototyping in conjunction with use cases, we stay userfocused Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com

29 Work from the inside out OMT was object driven (inside-out) OMT models == real-world (domain) Some upfront thought about the problem domain makes everything easier

Reuse across systems comes from the domain model Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 30 Use robustness analysis to update your static model Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 31 Use the robustness diagram to get the sequence diagram

started Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 32 Use the Sequence Diagram to Allocate Behavior Which in?

class does an operation belong Reusability: does it make this class more general? Applicability: does it fit? Is it relevant? Complexity: is it easier to build it here or elsewhere? Implementation knowledge: does it rely on internal details? Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 33 Update your static model, again

Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 34 Add Booch stuff to the analysis-level UML class diagram Booch constructs show additional design information abstract classes, parameterized

and instantiated classes aggregation vs composition friend, virtual, and static relationships Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 35 Drill down from the highlevel models to detailed OOD Booch provided the most

comprehensive OOD method Only OOD method to thoroughly treat software packaging, physical assignment across multiple processors Especially strong for details of message synchronization, instantiation, parameter passing Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 36 Design-Level Class Diagrams

What is a quality class? Parameterized and instantiated classes Design patterns Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 37 What is a quality class?

Coupling: should be loosely coupled with other classes Cohesion: should be highly cohesive Sufficiency: does it do enough? Completeness: does it cover all the relevant abstractions? Primitiveness: stick to basic operations Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 38 Design patterns Component Operation() Add(Component) Remove(Component)

GetChild(int) Client Component Leaf Operation() Operation() Add(Component) children Remove(Component) GetChild(int) Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 39

Code and Test Component Diagrams show packaging of classes into distributable units Usage scenarios (use cases) become test scenarios (test cases) We can link requirements, test cases and other software quality assurance (SQA) information to these models and follow them through the design. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com

40 Component Diagrams show packaging of classes into distributable units Components are physical, replaceable parts of a system that conform to, and provide the realization of, interfaces. Examples: dynamic link library (DLL), COM+ object, Enterprise Java Bean (EJB) Unlike classes, components are physical, not logical, and components

have operations that are reachable only through their interfaces. Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 41 Tracing requirements Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 42 We CAN avoid Analysis Paralysis without skipping OOAD

We want the MINIMAL YET SUFFICIENT amount of process Start small and tailor up as needed [opposite from RUP) Best effort to get it right the first time [opposite from XP] The ICONIX approach was synthesized from OMT, Objectory, Booch starting in 1993 It has been refined over 7+ years and hundreds of projects

It works. And it scales. Book: Use Case Driven Object Modeling with UML -A Practical Approach Addison-Wesley 1999 Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 43 For further information EMAIL: [email protected] http://www.iconixsw.com/UMLBook.html http://www.iconixsw.com/

UMLTraining.html Phone: 310-458-0092 FAX: 310-396-3454 Copyright 2000 ICONIX Software Engine ering, Inc. www.iconixsw.com 44

Recently Viewed Presentations