Information Systems Analysis and Design

Design Class Diagrams and others INFO 620 Glenn Booker Lecture #7 INFO 620 1

Visibility

• As we get deeper into design, we need to consider what objects can “see” each other • Sometimes we want to restrict visibility so that objects which are used in one area remain invisible as far as the rest of the system is concerned – Avoids accidental conflicts from the same attribute names INFO 620 Lecture #7 2

Visibility

• For object A to send a message to object B, A must be visible to B • There are four kinds of visibility: – Attribute visibility – Parameter visibility – Local visibility – Global visibility INFO 620 Lecture #7 3

Attribute Visibility

• Attribute visibility from A to B is when B is an attribute of A • Very common; such as when an attribute uses a non-primitive data type INFO 620 Lecture #7 4

Class1

+attribute1 #attribute2 -attribute3

Attribute Visibility

• Within a class of objects, each attribute can have its visibility controlled • Public (+) attributes can be used outside that class • Protected (#) attributes can be used in that class and its subclasses • Private (-) attributes can only be used in that class (default) INFO 620 Lecture #7 5

Parameter Visibility

• Parameter visibility from A to B is when B is passed as a parameter to a method of A :Register makeLineItem(spec, qty) > :Sale In this example, :Sale has parameters

spec

and

qty

visible because they were passed to it from :Register INFO 620 Lecture #7 6

Local Visibility

• Local visibility from A to B is when B is a local object within a method of A • So as long as the method exists, so does visibility INFO 620 Lecture #7 7

Global Visibility

• Global visibility from A to B exists as long as the objects A and B exist • The Singleton pattern is often used for global visibility INFO 620 Lecture #7 8

Showing Visibility (optional)

• In a collaboration diagram, these kinds of visibility can be shown with stereotypes: (attribute) :B ms g1 () «a ss oc iat ion » msg 2() «pa ramet er » :C :A msg3() Fig. 18.6, p. 284 ms g4 () «local » :D «g lob al » :E INFO 620 Lecture #7 9

Design Class Diagrams

• The design class diagrams (DCD’s) are generally created at the same time as the interaction diagrams • DCD’s add several dimensions to the conceptual class diagram (domain model) – Methods for each class – Attributes, with type and visibility defined – Navigation between objects INFO 620 Lecture #7 10

Design Class Diagrams

• In addition, the classes in the DCD are now software classes instead of conceptual classes – May include interfaces to external systems • The DCD is part of the Design Model in the Unified Process • A DCD does not have to include boundary and control objects INFO 620 Lecture #7 11

Design Class Diagrams

• A DCD can show all classes for a simple system • In industry, a DCD shows all classes in each subsystem or major component, and the other subsystems are represented by interfaces INFO 620 Lecture #7 12

Creating DCD’s

• Now start with the conceptual class diagram • Determine which classes need to be broken down into software classes • Identify attributes, many of which carry over from the conceptual class diagram • Use the interaction diagrams to identify methods for each class INFO 620 Lecture #7 13

Method Notes

• Note that

create

is not a method for each class – it is a concept used to make an object appear based on its class – In C++ and Java, the

new

operation actually implements the

create

concept • Getters and setters (formally known as accessor and mutator methods, or accessing methods) do not have to be shown on DCD INFO 620 Lecture #7 14

Method Notes

• A multiple object symbol is used when a message needs to access a container or collection of objects (Fig. 19.6, p. 290) spec := find(id): () :ProductCatalog :ProductSpecification INFO 620 Lecture #7 15

Navigability

• Each association can show whether it is possible to navigate that direction by using an arrowhead • No arrowheads implies bi-directional navigability • Navigability implies visibility; usually attribute visibility INFO 620 Lecture #7 16

DCD Associations

• In a DCD, associations are only those needed to make the software work – Fulfill visibility and memory needs dictated by the interaction diagrams • In contrast, the domain model could show all possible associations INFO 620 Lecture #7 17

Dependency Relationships

• A dashed line with an arrow at the end is used to show a dependency relationship; to show non-attribute visibility between classes

Class8 Class7

Lecture #7 INFO 620 18

Default Visibility

• Unless otherwise specified, the most common defaults for visibility are: – All attributes are private – All methods are public INFO 620 Lecture #7 19

DCD and the RUP

• Some CASE tools can create DCD’s from source code; this is called reverse engineering • In the Rational Unified Process, DCD’s are started in the Elaboration phase, and refined in the Construction phase INFO 620 Lecture #7 20

Statechart Diagrams

• Statechart diagrams (also known as state transition diagrams, or just state diagrams) show how a system responds to events • A state diagram applies to one series of events – here, typically one use case • An

event

is some action which occurs during use of the system, such as a mouse click INFO 620 Lecture #7 21

Statechart Diagrams

• A

state

is the condition of an object at some moment in time between events • A

transition

is the change from one state to another • We don’t care much what causes these changes in states, we just want to be able to describe them INFO 620 Lecture #7 22

Statechart Diagrams

• Statechart diagrams are particularly handy for use cases which are strongly time dependent, or which need to respond to many different sequences of events • The initial state of the use case is shown by a big black dot • The end of the use case is shown by a big black dot in a circle INFO 620 Lecture #7 23

Statechart Diagrams

• Each state is shown by a rounded rectangular box with the name of the state in it • Each event is shown by a line with an arrowhead on one end (events are always directional) getTotal() State1 State2 INFO 620 Lecture #7 24

Statechart Diagrams

• A class may also be represented by a state diagram • Events which are not specifically shown on the state diagram produce no result • Any use case or class might be modeled using a state diagram to better understand its dynamic behavior – what events are “legal” at any point in the system’s life?

INFO 620 Lecture #7 25

Statechart Diagrams

• These are particularly helpful to understand complex decision making, or just know what possible events are meaningful at any point in the chain of events • Hence complex state-dependent objects (they respond differently to an event depending on the sequence of previous events) are prime state diagram candidates INFO 620 Lecture #7 26

Statechart Diagrams

• Common statechart subjects include: – Use cases – Communication between subsystems – Entire systems – Windows interface – Controllers – Transactions – External systems INFO 620 Lecture #7 27

Event Categories

• Events can fall into three categories –

External events

are from something outside the system boundary –

Internal events

are methods within the system being used –

Temporal events

elapsed time are based on date or • No need to use state diagram for internal events (use interaction diagrams for that) INFO 620 Lecture #7 28

p. 445

More State Diagram Notation

• A

transition action

is some method which occurs during the transition • A

transition guard condition

is a Boolean condition which must be True for the transition to take place, e.g. [valid] • State diagrams can be nested to show complex behavior within one overall state INFO 620 Lecture #7 29

Packages

• Packages are logical groupings of objects – In Java, called packages; in C++, namespaces • Packages appear as tabbed folders • An external interface can appear as a line with a dot on it Interface3

Package2

INFO 620 Lecture #7 30

Packages

• At the lowest level, a package can show the class diagram for all classes which belong to it • Packages can also be composed of other packages, and show their dependencies (circa pages 424-425) INFO 620 Lecture #7 31

Component Diagram

• Components represent how the system is implemented; based on

logical

grouping of implementation (application) classes • Each component encapsulates part of the system and represents it to the rest only by its interfaces (e.g. like façade) • A component diagram (p. 605) shows the components and their interfaces INFO 620 Lecture #7 32

Component Diagram

• Each component is identified by its stereotype – <> – <> – <> – <> – <> «file»

Component1

• Components may include DLL or JAR files INFO 620 Lecture #7 33

Deployment Diagram

• The deployment diagram shows where components are

physically

located on nodes or processing units (servers), p. 606

Node1 Component2 Component3

INFO 620 Lecture #7 34

Subsystem Diagram

• A subsystem could be defined by its components or nodes – more likely the former, since several subsystems could reside on the same physical node • Each subsystem could be independent for many functions, and only interface with other subsystems for specific needs • Adapt Deployment diagram notation INFO 620 Lecture #7 35

INFO 620

Subsystem Diagram

<> sub1

«file»

Component1

«file»

Component2

Lecture #7 36

Activity Diagrams

• Activity diagrams are the process flowchart of UML • It shows processes, roles, and decisions, making it good for – Software algorithms – Business modeling – Use case analysis INFO 620 Lecture #7 37

p. 608

Activity Diagrams

• Activity diagrams have vertical lanes which each represent an organization • Each process step is a rounded rectangle with the process name in it • Lines between steps show the transition after the step was completed • Decisions (if) are shown by diamond shapes, with options in brackets like [rush] INFO 620 Lecture #7 38

Activity Diagrams

• Multiple flow options, either splitting or converging, are shown by a heavy horizontal line Flow of objects are shown by dotted lines with arrowheads INFO 620 Lecture #7 39

Activity Diagrams

• Objects are shown in rectangles, often with their state below their name, e.g. [fulfilled] • Start and stop symbols are the same as for a state diagram (and are optional here) • For another approach for process modeling, see http://users.snip.net/~gbooker/ISYS205/process_definition.pdf

INFO 620 Lecture #7 40