Object-Oriented Analysis and Design. Pre-UML Situation. The Unified Modeling Language. Unification Efforts

Transcription

1 Object-Oriented Analysis and Design Analysis vs. Design Analysis Activities Finding the Objects/ Classes An Analysis Example The Unified Modeling Language Pre-UML Situation Early 90s Explosion of OO methods/notations No agreed terminology No standards No method/notation that satisfies a users needs completely Booch, OMT and OOSE among the most popular methods New generations of methods/notations Unification efforts OOSD--fall'04 Copyright by jubo@cs.umu.se 28 OOSD--fall'04 Copyright by jubo@cs.umu.se 29 Unification Efforts UML consortium Booch, OMT and OOSE Rational Booch, Rumbaugh (10/94) Jacobson (fall 95) Unified (v0.8, 10/95) UML consortium ( 96) UML (v0.9, 06/96) Unified process ( 98/ 99) OPEN consortium Fusion, MOSES, SOMA Firesmith, Graham, Henderson-Sellers, Yourdon, Toolbox approach Tailorable The Unified Modeling Language UML partners: Microsoft, Oracle, IBM, HP, Ericsson,... Here v1.4 (no visible difference to v1.5) Notations (8 official diagram types) Use case diagram Class diagram Interaction diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Component diagram Deployment diagram OMG standard (v1.1, 11/97) ISO standard (v1.3, 10/00) OML ( 97) OPEN process ( 97) Integration with UML? OOSD--fall'04 Copyright by jubo@cs.umu.se 30 XMI (XML Metadata Interchange, standardised XML- DTD for UML, developed by an IBM-lead consortium) UML 2.0 adopted (draft, 06/03) OOSD--fall'04 Copyright by jubo@cs.umu.se 31

2 Rational s 4+1 View Logical View Process View packages, classes, scenarios, STDs Use Case View processes, threads, synchronization Implementation View actors, use cases Deployment View physical nodes subsystems, modules, code UML 2.0 Infrastructure: UML kernel and extension mechanisms Superstructure: UML user level constructs OCL: Object Constraint Language Diagram Interchange The UML metamodel describes the UML model elements Abstract syntax in terms of UML Well-formedness rules in terms of OCL and English prose Semantics (model usage) in terms English prose OOSD--fall'04 Copyright by jubo@cs.umu.se 32 OOSD--fall'04 Copyright by jubo@cs.umu.se 33 UML 2.0 Diagrams Organising Models Packages diagrams are used to organise models Defines namespaces á la C++ GUI User Forms Admin Forms javax.swing DB Interface Can be used for all diagram types Inofficial UML1.x diagram OOSD--fall'04 Copyright by jubo@cs.umu.se 34 OOSD--fall'04 Copyright by jubo@cs.umu.se 35

3 Class Diagrams Static analysis and design models Types of objects and their (static) interrelationships Basically similar to UML2.0 (but more carefully defined) Main elements: <class name> Classes <attribute list> Attributes Methods Relationships <method list> Dependency Association strength Aggregation/Composition Generalisation Realisation OOSD--fall'04 Copyright by 36 Class Notations Analysis Window Window size: Area maxsize create() resize() repaint() Design Window {author = Joe, status = tested} +size: Area = (100, 100) #maxsize: Rectangle -xwindowptr -components [*] {ordered} +create() +resize( in f: real = 1.25): Area #repaint( in gc: Graphics) Attribute :: [visibility] [/] name [: type] [multiplicity] [= default-value] [{ property-string }] Operation :: [visibility] name ( [parameter-list] ) [: return-type [{ property-string }]] Parameter :: [direction] name : type-expression [multiplicity] [= default-value] [{ property-string }] OOSD--fall'04 Copyright by jubo@cs.umu.se 37 Dependency Dependencies define a usage relationship A change in the used thing may affect things that use it Dependencies can have names (there is a set of predefined dependency keywords stereotypes) VideoClip name play( on: Channel) start() stop() rewind() <<use>> Channel Association 1 Associations specify structural relationships It specifies that objects are interconnected Associations can be navigated in both directions (default) Associations are quite similar to the relationships known from ER modelling Associations have cardinalities Associated classes may have roles Company * Works-for 1..* employer employee Person OOSD--fall'04 Copyright by jubo@cs.umu.se 38 OOSD--fall'04 Copyright by jubo@cs.umu.se 39

4 Association 2 Associations may have attributes and behaviour (association classes) Association classes are quite similar to the relationship types known from ER modelling Association names may have reading directions Aggregation and Composition Aggregation and composition are specific associations They denote the part-of or has relationship Composition is the stronger form Parts are not shared Parts are existence dependent on the whole Company * Works-for 1..* employer employee Person Aggregation 1 Polygon 1 Composition Job salary worker * boss 0..1 Manages Point 3..* 1 Graphics color Texture OOSD--fall'04 Copyright by jubo@cs.umu.se 40 OOSD--fall'04 Copyright by jubo@cs.umu.se 41 Generalisation Generalisation specifies the is-a relationship It is the strongest relationship between classes Subclasses inherit properties from superclasses Shown as class hierarchies Also known as specialisation or inheritance Person Notes, Constraints, Qualifiers, and Interfaces BankAccount balance compare () Responsibilities: -- keep current balance -- handle deposits and withdrawals {> 0} {or} CID PersNr Corporation Person gender: {female, male} wife 0..1 husband 0..1 Student Employee Sortable Notes, like this one can be attached to any notational element {self.wife.gender = #female and self.husband.gender = #male} A constraint written in OCL (Object Constraint Language) Mentor Manager OOSD--fall'04 Copyright by jubo@cs.umu.se 42 OOSD--fall'04 Copyright by jubo@cs.umu.se 43

5 Some Guidelines for Class Diagrams Keep the analysis model simple Many simple classes are better than a few complex ones Use meaningful and familiar names Avoid god classes, behaviour should be distributed among classes Use multiple inheritance very sparely Try to avoid the too general dependency Associate methods with the providers of a service, i.e. the responsible classes Name all associations Document your model carefully Sequence Diagrams Graphical notation for scenarios Describe how objects collaborate to provide a service Good tool to uncover missing behaviour and/or missing objects/classes Very useful to document CRC role-plays Sequence diagrams OIDs (see [OOTC 97]) Collaboration diagrams are semantically equivalent, but focus on structural relationships between objects OOSD--fall'04 Copyright by jubo@cs.umu.se 44 OOSD--fall'04 Copyright by jubo@cs.umu.se 45 Sequence Diagram Example Sequence Diagram Details add a course time :Registrar 1: enter id 3: create course 4: enter course info 5: submit 8: close form Course Maintenance Form 2: verify id 6: create 7: save tdbc18: Course The lifeline of the object An activation bar Provide lots of annotations Comments (script text) Object creation and deletion Message return Conditional messages and Iteration... Supports notations for concurrency Timing and activation Asynchronous messages Quite some changes in UML2.0 OOSD--fall'04 Copyright by jubo@cs.umu.se 46 OOSD--fall'04 Copyright by jubo@cs.umu.se 47

6 Some Guidelines for Sequence Diagrams Keep the analysis scenarios simple (do not overspecify your OIDs) Analysis scenarios should usually be initiated by an actor Discriminate instances of the same class Make all assumption clear, use pre- and postconditions Concentrate on the major scenarios Manage consistency between use cases, scenarios/oids, and class diagrams Focus on general behaviour, do not implement methods too early (in UML2.0 you could actually do that) The GSS Case Study Continued 1 Assign a judge to an event An event has a judging panels assigned to it The judging panel consists of qualified scorers for this event How could this work? :League_Official assign( thejudge) success theevent is_assigned is_qualified( theevent) addjudge( thejudge) thejudge [is_assigned == `false and is_qualified == `true ] is_qualified( theevent, thejudge) Shouldn't there be a third party to decide on that???? OOSD--fall'04 Copyright by jubo@cs.umu.se 48 OOSD--fall'04 Copyright by jubo@cs.umu.se 49 The GSS Case Study Continued 2 Alternative 1: Let Event handle qualified scorers Make Event an abstract class Defer determination of qualified scorers to specific event classes Competition 5 Judge is_assigned( ): boolean 1 * Judging Panel 1..n Event {abstract} assign( Judge) is_qualified( Judge) BalanceBeam Floor Vault The GSS Case Study Continued 3 Alternative 2..n: Try to give other existing classes this responsibility League Equipment... Define a special purpose class Find out where this responsibility lies in the real world OOSD--fall'04 Copyright by jubo@cs.umu.se 50 OOSD--fall'04 Copyright by jubo@cs.umu.se 51

7 Statechart Diagrams 1 Graphical notation for class behaviour modelling Describe all possible states and state changes triggered by external stimuli Good tool to describe complex object life cycles Good tool to uncover missing state information and behaviour start An internal transition A deferred event <state name> <attribute list> entry / <action> exit / <action> do / <action> <event> / <action> <event> / defer event trigger [guard condition]/ action if event then if condition then trigger transition; execute action else nothing happens; <state name> stop Statechart Diagrams 2 States can be nested Substates may be concurrent Transitions may have multiple sources and/or destinations Basically unchanged in UML2.0 OOSD--fall'04 Copyright by jubo@cs.umu.se 52 OOSD--fall'04 Copyright by jubo@cs.umu.se 53 Some Guidelines for Statechart Diagrams Use STDs when there is (complex) state- dependent behaviour Use STDs when you are not sure when things can (are allowed to) happen Ensure that all events are covered Ensure that all states are reachable Ensure that all states can be exited Ensure that all transitions can be triggered Check each pair of states for missing transactions Check consistency with other models Contents Introduction Object-Oriented Software Development Project Management Requirements Gathering (G)UI Design Object-Oriented Analysis and Design Advanced Topics in OOA&D Implementation and Testing References OOSD--fall'04 Copyright by jubo@cs.umu.se 54 OOSD--fall'04 Copyright by jubo@cs.umu.se 61

8 Implementation and Testing REMEMBER: This no programming course. We assume you already know something about this topic from earlier courses. Some links are available from the course web page. OOSD--fall'04 Copyright by 62