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

Post on 21-Dec-2015

224 views 3 download

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

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

Lecture b: Generalization, Aggregation and Additional Domain Model Notation

Copyright W. Howden 104/19/23

More UML Models

• Package– introduced earlier in discussion of system

architecture

• Activity

• Deployment

Copyright W. Howden 204/19/23

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

Copyright W. Howden 4

UML Diagrams

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

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

Copyright W. Howden 6

Relationship Notation

• Containment, Dependency, Generalization

.

.

.

.

.Package5

Package6

Package3 Package7Package8

Package9

04/19/23

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

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

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

Copyright W. Howden 1004/19/23

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

Additional Notation

• Swimlanes

• Associates actions with different objects

• In our example, associates actions with user versus system

Copyright W. Howden 1204/19/23

Copyright W. Howden 1304/19/23

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

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

Copyright W. Howden 16

Client Client

AppServer DBServer

GUI

DomainLogic

DBProxy

DBServer

DB

GUI

04/19/23

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

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

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

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

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

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

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

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

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

Copyright W. Howden 26

Kinds of use of Inheritance

• specialization

• specification

• construction

• extension

• limitation

• combination

04/19/23

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Copyright W. Howden 4304/19/23

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

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