Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W. Howden16/30/2015

More UML Models Package –introduced earlier in discussion of system architecture Activity Deployment Copyright W. Howden26/30/2015

Copyright W. Howden3 Warning - UML Terminology Special definitions for: classifier, class, implementation class, interface, type, data type, operation and method Sometimes conforms to “normal” usage of the word and sometimes is a variation Not that important for our informal use of UML models 6/30/2015

Copyright W. Howden4 UML Diagrams Use Case Class Interaction Sequence Collaboration Package Activity Deployment State 6/30/2015

Copyright W. Howden5 UML Package Diagrams – Package Relationships Containment In addition to classes, a package may contain other packages Dependencies If one package is dependent on others, changes to their classes/packages may require changes to it also Generalization A “subtype” package must conform to the interface for the more general package. 6/30/2015

Copyright W. Howden6 Relationship Notation Containment, Dependency, Generalization 6/30/2015

Notation (Previous slide) Large super package contains packages 5 and 6 Large package depends on packages 3 and 7 Package 3 is a generalization of packages 8 and 9 Copyright W. Howden76/30/2015

Copyright W. Howden8 DS Package Examples DS system package contains sub-packages for GUI, DL and DB packages Dependencies: e.g. changes to classes in DL package/subsystem may require changes to classes in GUI package/subsystem Generalization: e.g. DB package has a facade interface that can be implemented with different DB instances, including a mock DB for phase 1 6/30/2015

Copyright W. Howden9 UML Activity Diagrams Similar to (control) flow charts but includes parallelism Are functional, not OO models Parts of diagram (notation can vary) –Activities (Oval), Flow edges, Synchronization bars (splitting and merging), Decision boxes (diamond - conditional branch) 6/30/2015

Copyright W. Howden106/30/2015

Copyright W. Howden11 DS Activity Diagram Example Describes what the system must do when the user asks for a date –Use? Abstract functional design –Parallelism in example: FrequentDatee Warning and DateeDataMessage have no temporal ordering 6/30/2015

Additional Notation Swimlanes Associates actions with different objects In our example, associates actions with user versus system Copyright W. Howden126/30/2015

Copyright W. Howden136/30/2015

Copyright W. Howden14 Activity Diagram Applications Use case documentation Determining action sequences in designs Describing development process workflows Additional notation: –Swimlanes: divide diagram into zones depending on actor responsible for action –e.g. earlier DS example 6/30/2015

Copyright W. Howden15 UML Deployment Diagrams Purpose: shows how software components are distributed to hardware components Diagram parts hardware nodes, software packages/subsystems Connections: –solid: communication paths –dotted: dependencies (changes to one may change other) E.g. DS diagram where there could be more than one client (differs from my DS system) 6/30/2015

Copyright W. Howden166/30/2015

Generalization, aggregation and additional UML notation Generalization –basic concepts, inheritance vs generalization Aggregation –basic concepts, aggregation versus inheritance in design Copyright W. Howden176/30/2015

Copyright W. Howden18 Generalization A general term in UML, also applicable to entities other than classes, such as packages, use cases, etc. Generalization: abstraction, something a set of individuals hold in common Focus here mostly on UML class models domain models (general concepts, no methods) class design models (classes with details) 6/30/2015

Copyright W. Howden19 Generalization and Types Type A specification of a class –name, attribute definitions, method signatures (name, parameter definitions) Subtype A subset of the instances of some type, each of which has special properties of its own. Supertype More abstract type having common properties of a set of subtypes 6/30/2015

Copyright W. Howden20 Valid and Useful Generalization When do we have a “true” generalization? When is a generalization “useful” –e.g. the goal is *not* to create as many (sub) classes as possible –A generalization may be “valid” but not that useful 6/30/2015

Copyright W. Howden21 Valid Generalization is-a An instance of a subtype is also an instance of the supertype Other rules –Substitutability Suppose B is a subtype of A. It should be possible to substitute an instance of B any place that requires something of type A. –100% rule All of the supertype’s definition should also apply to the subtype (i.e. its attributes, associations) 6/30/2015

Generalization Examples A DeleteMember is-a AdminCommand Suppose that we create an interface class DB’ for the data base, and write all calls form DL to DB’ using this interface. Later on, when we have a real DB we can substitute DB for DB’ Copyright W. Howden226/30/2015

Copyright W. Howden23 Generalization Usefulness Guidelines – SubType Creation Useful to include in model or diagram if subtype has additional attributes of interest –primitive data types or associations (class variables defined using new classes) Subtype has additional methods of interest Subtype is operated on differently than other supertype members 6/30/2015

Copyright W. Howden24 Generalization Usefulness Guidelines – SuperType Creation Subtypes will be “variations on a general theme” Subtypes have common attributes that can be factored out and given to supertype –primitive data types and associations (class variables defined using new classes) 6/30/2015

Generalization vs Inheritance Class inheritance is the means for implementing generalization in a program Inheritance can be used in ways that do not correspond to generalization Copyright W. Howden256/30/2015

Copyright W. Howden26 Kinds of use of Inheritance specialization specification construction extension limitation combination 6/30/2015

Copyright W. Howden27 Specialization Re-defines defined parent properties and methods. –Not something completely new, just a refinement (more details, additional information returned, etc.) E.g. Suppose we have a stack class where a message is returned when an item is pushed on the stack success if pushed, or error if stack is full change this so stack-is-full warning is returned when stack becomes full, i.e. last item is pushed 6/30/2015

Copyright W. Howden28 Specification Used to “specify” behavior, but not “define” it Subtype defines the behavior i.e. gives method definitions e.g. ActionListener interface in Java GUI. Specifies behavior (method signatures) for listener classes which will implement ActionListener, and define the behavior 6/30/2015

Copyright W. Howden29 Construction For the purposes of re-use of methods and data structures Define new methods and data structures in terms of inherited ones Subtype may have no logical relationship with supertype(s) E.g. Stack defined as subtype of Vector 6/30/2015

Copyright W. Howden30 Extension Adding new properties and methods No modification of parent properties Similar to construction but has the is-a property, which construction may not have E.g. adding button declarations to the Dialog class in a new extends class 6/30/2015

Copyright W. Howden31 Limitation Override some methods with blank/null methods –Limits access to certain behaviors May be used with construction to block methods that have no meaning in the subtype E.g. In Java, WindowAdpator class is a limitation of WindowListener interface 6/30/2015

Copyright W. Howden32 Combination Uses multiple inheritance for two or more applications of generalization DS example –MessageDialog extends (i) Dialog and implements (ii) ActionListener (i) extension: add buttons, panels (ii) specification: define actionPerformed method() 6/30/2015

Copyright W. Howden33 Review of Valid Generalization is-a An instance of a subtype is also an instance of the supertype. e.g. an administrator is a DS user Substitutability Suppose B is a subtype of A. It should be possible to substitute an instance of B any place that requires something of type A. 100% rule All of the supertype’s definition should also apply to the subtype (i.e. its attributes, associations) 6/30/2015

Copyright W. Howden34 Which Kinds of Inheritance are Generalizations? Yes – is-a, substitutability, 100% Specification, Extension, Combination (sometimes) Maybe – is-a Specialization, Limitation (could be a kind of specialization) No Construction: if that is all it is 6/30/2015

Copyright W. Howden35 Aggregation A has an aggregation relationship with B and C if they are “parts of” A –e.g. A has class variables of type B and type C –e.g. DS MemberData has a DateeData part 6/30/2015

Copyright W. Howden36 Composition Strong form of aggregation –Parts only belong to one whole –If whole is deleted, parts get deleted E.g. composition – fingers on your hand E.g. simple aggregation – change in your pocket 6/30/2015

Copyright W. Howden37 Aggregation Rules has-a The composite object has an instance of each class that it aggregates –Contrast with the is-a correctness rule for generalization 6/30/2015

Generalization vs Aggregation In some situations, may use one or the other to achieve some goal May also be used together 6/30/2015Copyright W. Howden38

Copyright W. Howden39 Choosing Between Generalization and Aggregation Defining a new class, e.g. stack from vector Generalization –Subtype vector and define new stack class operations that use the inherited operations Aggregation –New stack class has a vector class variable –Use define stack operations using vector operations 6/30/2015

Copyright W. Howden40 Which is Better? Which is the better OO definition of a stack? Apply the is-a/substituability and has-a validity rules  Stack is-a vector? substitute a stack any place where you need a vector?  Stack has-a vector? 6/30/2015

Copyright W. Howden41 UML Generalization and Aggregation Notation Generalization (arrow direction – “is-a”) Aggregation, Composition (arrow–“has-a”) 6/30/2015

Copyright W. Howden42 Phase 2 DS Domain Model Add additional Phase 2 functionality –Include use of generalization, aggregation and composition notation Class/concept attributes listed separately, as before My design assumes a single DS terminal –(bug: somehow arrows were left out of aggregation edges in following diagram) 6/30/2015

Copyright W. Howden436/30/2015

Copyright W. Howden44 Generalization and Aggregation Examples in Domain Model Generalization: AddMember and DeleteMember are shown as subtypes of Admin Command Aggregation: DatingSystem’s relation to DatingTerminal Composition: DatingSystem’s relation to DataBase 6/30/2015

New Deliverables Re-do your domain models –Augment them for additional functionality of phase 2 –Consider the use of super and subtypes in the model and use the UML generalization and aggregation notation in the domain model 6/30/2015Copyright W. Howden45