Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization,...

45
Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W. Howden 1 06/18/22
  • date post

    21-Dec-2015
  • Category

    Documents

  • view

    224
  • download

    3

Transcript of Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization,...

Page 1: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Lecture a: Additional UML Models: Package, Activity, Deployment

Lecture b: Generalization, Aggregation and Additional Domain Model Notation

Copyright W. Howden 104/19/23

Page 2: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

More UML Models

• Package– introduced earlier in discussion of system

architecture

• Activity

• Deployment

Copyright W. Howden 204/19/23

Page 3: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 3

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

04/19/23

Page 4: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 4

UML Diagrams

• Use Case• Class• Interaction Sequence• Collaboration• Package• Activity• Deployment• State04/19/23

Page 5: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 5

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.

04/19/23

Page 6: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 6

Relationship Notation

• Containment, Dependency, Generalization

.

.

.

.

.Package5

Package6

Package3 Package7Package8

Package9

04/19/23

Page 7: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

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. Howden 704/19/23

Page 8: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 8

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

04/19/23

Page 9: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 9

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)

04/19/23

Page 10: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 1004/19/23

Page 11: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 11

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

04/19/23

Page 12: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Additional Notation

• Swimlanes

• Associates actions with different objects

• In our example, associates actions with user versus system

Copyright W. Howden 1204/19/23

Page 13: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 1304/19/23

Page 14: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 14

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

04/19/23

Page 15: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 15

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)

04/19/23

Page 16: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 16

Client Client

AppServer DBServer

GUI

DomainLogic

DBProxy

DBServer

DB

GUI

04/19/23

Page 17: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Generalization, aggregation and additional UML notation

• Generalization– basic concepts, inheritance vs generalization

• Aggregation– basic concepts, aggregation versus inheritance

in design

Copyright W. Howden 1704/19/23

Page 18: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 18

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)

04/19/23

Page 19: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 19

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

04/19/23

Page 20: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 20

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

04/19/23

Page 21: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 21

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)

04/19/23

Page 22: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

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. Howden 2204/19/23

Page 23: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 23

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

04/19/23

Page 24: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 24

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)

04/19/23

Page 25: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

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. Howden 2504/19/23

Page 26: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 26

Kinds of use of Inheritance

• specialization

• specification

• construction

• extension

• limitation

• combination

04/19/23

Page 27: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 27

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

04/19/23

Page 28: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 28

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

04/19/23

Page 29: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 29

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

04/19/23

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

Copyright W. Howden 30

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

04/19/23

Page 31: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 31

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

04/19/23

Page 32: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 32

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()

04/19/23

Page 33: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 33

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)

04/19/23

Page 34: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 34

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

04/19/23

Page 35: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 35

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

04/19/23

Page 36: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 36

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

04/19/23

Page 37: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 37

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

04/19/23

Page 38: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Generalization vs Aggregation

• In some situations, may use one or the other to achieve some goal

• May also be used together

04/19/23 Copyright W. Howden 38

Page 39: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 39

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

04/19/23

Page 40: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 40

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?

04/19/23

Page 41: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 41

UML Generalization and Aggregation Notation

• Generalization (arrow direction – “is-a”)

• Aggregation, Composition (arrow–“has-a”)

Class1 Class2

Class3 Class4 Class5 Class6

1 *1 *

04/19/23

Page 42: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 42

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)

04/19/23

Page 43: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 4304/19/23

Page 44: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

Copyright W. Howden 44

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

04/19/23

Page 45: Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.

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

04/19/23 Copyright W. Howden 45