object-oriented design tools & uml intro to uml • uml: unified modeling language • system...

1

Object-oriented design

Part 2: intro to UML

2

Intro to UML

• UML: unified modeling language • System for graphically representing &

manipulating an object-oriented software system

• Both a representation of design & tool to assist in design process

3

Class Diagram

• Detail diagrams: – 3 parts: class name, attributes, methods -

generally listed in that order – Don’t have to list all attributes or methods -

usually just the most important • Can use abbreviated diagrams for depicting

relationships among classes: omit all but the class name

4

Attributes

• Attributes generally correspond to data members of a class

• Can include the following information in a class diagram: – access designation:

+ means public - means private # means protected

– name – data type

5

Methods in Class Diagram

• Constructor – same name as class – has no return type & no access designation

• Other methods – access designation (+, - or #) – method name – parameter list, if needed - in parentheses – return type after colon

Methods

• The general syntax for a method’s signature in a class diagram is: X methodName: returnType(parameter(s)) Where: – X is either +, - or # (or nothing, if constructor) – returnType and parameter(s) represent data category,

but not necessarily an actual data type (since UML is not language-specific); void is still used to mean no return value

– If there are no parameters, omit the () 6

7

Example: musical Note

Class name

} Attributes

Methods

8

Example from ATM

9

Depicting class relationships

• Relationships between classes are represented by lines between (abbreviated) class diagrams

• Line type (solid vs. dotted) and arrowhead type distinguish between various kinds of relationships

10

Aggregation

• Aggregation is used when a class is made up of class components – Acar has an engine, an electrical system, etc. – A musical score has notes, time signatures, dynamics,

etc. • Examples of things that are not aggregations:

– A store has customers, but doesn’t own them – A student has a list of classes, but isn’t made up of

them

11

Aggregation & UML

• Aggregations are represented with diamond-headed lines connecting an aggregate class to its components

• The diamond is at the aggregate end • Can use multiplicity notation to depict the

number of instances of each component

12

ATM Example Although we didn’t choose to model it this way, an ATM can be thought of as an aggregate of several things, for example, display device, keypad, deposit slot, receipt printer and bank card reader

13

Multiplicity notation

• A number or symbol near either end point of a connecting line indicates multiplicity

• Common notations include: – 0 or more: * – 1 or more: 1 .. * – 0 or 1: 0 .. 1 – exactly 1: 1

14

Multiplicity examples

From voice mail system: a message queue can contain several messages

JukeBox: A SongList (songs picked by an individual user) can have 1-4 songs, depending on the amount of money deposited; the PlayList consists of all the SongLists queued up as other users’ songs are played

Aggregation vs. Association

15

• Aggregation is sometimes subdivided into the categories of true aggregation (where a thing is the sum of its (independent) parts) and composition, where the parts don’t have an independent existence

• An association diagram is a more general depiction of the relationship between classes

16

Associations

• Represent services provided between classes - a.k.a. collaborations

• Association is represented by a line between client & server class diagrams

• There is no indication of direction of flow of service

17

Associations

• Can add role designations to lines in association

• Helps clarify bidirectional relationship before a final decision is made about which class actually manages the pertinent information

18

Association Example from ATM

Each line represents a collaboration:

• ATM collaborates with transaction in fulfillment of ATM responsibility: create & initiate transactions • Transaction collaborates with Account in fulfillment of transaction responsibility: commit transaction to database • Various transaction types collaborate with Account to perform their responsibilities

19

Notes on Graph Complexity

• A diagram needs to depict system, but also needs to be readable

• All collaborations could be represented on a single association graph, but in a complex system the diagram would be so complicated as to be unusable

20

Notes on Graph Complexity

• Best approach is to create multiple diagrams that represent collaborations in fulfillment of a set of related responsibilities

• Previous example represented all collaborations in support of 3 contracts

21

Inheritance

• UML represents inheritance relationships between classes as a line beginning from a subclass diagram and ending in an arrow pointing to the superclass

• Abstract classes are represented using {} around their names

22

Example from ATM Design

Interfaces

• An interface is a language construct specific to Java

• Java does not support multiple inheritance • Interfaces provide some of the same

functionality – A Java class can only inherit from one class – But can implement many interfaces

ATM Example

This hierarchy chart represents the ATM device classes as envisioned by the preliminary design Each of the concrete subclasses represents an actual physical device; the abstract classes are used to abstract their common behavior The design calls for Bank Card Reader and Receipt Printer to inherit from multiple superclasses, but this can’t be done in Java

Using Interfaces

• Instead of redoing the design, can make the abstract classes into interfaces

• An interface specifies, but does not implement, specific methods; the implementation is left up to the subclasses that “inherit” the interface

Inheritance vs. Interfaces

• We can think of “real” inheritance as implementation inheritance – Subclasses inherit and may extend functionality

of superclass – Superclasses pass on structure and behavior

Inheritance vs. Interfaces

• Interfaces provide only definition inheritance – Methods may be specified, but there is no

superclass implementation – Instead, the subclasses define what is specified

in the interface – Interfaces pass on structure, but not behavior

Interfaces & UML

• Interface relationships look like inheritance relationships, except a dashed line is used for connecting subclasses to superclasses

• Each interface’s name is enclosed in a double set of angle brackets: << >>

ATM Example

Dependency

• Dashed lines with closed arrowheads, as shown in the previous diagram, indicate definition inheritance via interfaces

• A dashed line with an open arrowhead simply indicates a dependency - that is, one class depending on another to fulfill a responsibility

Dependency example Several slides ago, this diagram appeared:

This is an association diagram, but the names strongly suggest a dependency:

Sequence Diagrams

• Sequence diagrams describe the interaction of classes as their methods are called

• Where class diagrams provide a static picture of class relationships (basically just telling us that a relationship exists), sequence diagrams provide a dynamic picture of a system in action

• Time is represented by the vertical dimension; the further down in the diagram, the later a method is invoked

Sequence diagram: example 1

aMailbox is the client object - calls newMessages.add(message)

Elements of a sequence diagram

• Rectangles representing classes and objects – object names are underlined, and may appear in

several forms: • full description: objectname: Classname • no class specified: objectname • class specified without object name; read as “some

instance of this class”: : Classname – class names are not underlined

• Method names and other text

Elements of a sequence diagram • Lifelines: dashed vertical lines

representing the period of time during which an object exists (can be left indeterminate)

• Activation bars: rectangles laid over lifelines, representing a method’s execution in process

• Call arrows: horizontal arrows pointing from the calling object or class to the object or class that owns the called method

Elements of a sequence diagram

• Data tokens: short lines with an arrowhead on one end and a circle on the other, representing data items flowing between objects – Tokens pointing to the right represent arguments passed

to methods – Tokens pointing the left represent return values

Sequence diagram: example 2

This diagram represents a self call: the unnamed MailSystem object is calling its own locateMailbox method

Sequence diagram: example 3

In this diagram, a MailSystem object calls the constructor for a Mailbox object. The <<create>> stereotype indicates the constructor call; note that the Mailbox object is slightly below the MailSystem object, because its lifeline doesn’t start until MailSystem creates it

Sequence diagram: example 4 • User pressing key

spawns call to dial() • Connection object must

find Mailbox object: Calls findMailbox on MailSystem object

• Connection wants to get greeting to play: Each Mailbox knows its greeting

• Note that connection holds on to that mailbox over multiple calls

Note: parameters and return values are not displayed in this diagram; may be omitted to reduce complexity

State diagrams

• Some objects have a discrete set of states that affect their behavior; this is particularly true of objects that interact with the user

• A state diagram shows the various states of a system while a particular process is carried out

• State diagrams can be used to illustrate variations in a use case

State diagram example - ATM

State diagram example - voice mail system

• Rounded rectangles represent the various states of the system (from user’s point of view)

• Arrows show transitions between states – text labels indicate actions that move system from state to state