INFO 620Lecture #71 Information Systems Analysis and Design Design Class Diagrams and others INFO 620 Glenn Booker

INFO 620 Lecture #7 1

Information Systems Analysis and Design

Design Class Diagrams and others

INFO 620Glenn Booker


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


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


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


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)

+attribute1#attribute2-attribute3

Class1


Parameter Visibility

• Parameter visibility from A to B is when B is passed as a parameter to a method of A

In this example, :Sale has parameters spec and qty visible because they were passed to it from :Register

:SalemakeLineItem(spec, qty) >

:Register


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


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


:A

:B

:C

:D

:E

msg

1()

«ass

ociat

ion »

msg2()

«parameter »

msg3()

«local »

msg4()

«global »

Fig. 18.6, p. 284

Showing Visibility (optional)

• In a collaboration diagram, these kinds of visibility can be shown with stereotypes:

(attribute)


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



• 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



• 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


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


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


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)

:ProductSpecification:ProductCatalog

spec := find(id): ()


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


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


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

Class7

Class8


Default Visibility

• Unless otherwise specified, the most common defaults for visibility are:– All attributes are private– All methods are public


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


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


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


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


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)

State1 State2getTotal()


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?


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


Statechart Diagrams

• Common statechart subjects include:– Use cases– Communication between subsystems– Entire systems– Windows interface– Controllers– Transactions– External systems


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 are based on date or

elapsed time• No need to use state diagram for internal

events (use interaction diagrams for that)


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

p. 445


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

Package2Interface3


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)


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


Component Diagram

• Each component is identified by its stereotype– <<file>>– <<database>>– <<browser>>– <<library>>– <<process>>

• Components may include DLL or JAR files

«file»Component1


Deployment Diagram

• The deployment diagram shows where components are physically located on nodes or processing units (servers), p. 606

Node1

Component2 Component3


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


Subsystem Diagram

<<subsystem>> sub1

«file»Component1

«file»Component2


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


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]

p. 608


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


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

http://users.snip.net/~gbooker/ISYS205/process_definition.pdf

Documents

INFO 620Lecture #71 Information Systems Analysis and Design Design Class Diagrams and others INFO 620 Glenn Booker