Information Systems Analysis and Design Design Class Diagrams and others
description
Transcript of Information Systems Analysis and Design Design Class Diagrams and others
INFO 620 Lecture #7 1
Information Systems Analysis and Design
Design Class Diagrams and others
INFO 620
Glenn Booker
INFO 620 Lecture #7 2
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 3
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 4
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 5
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
INFO 620 Lecture #7 6
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
INFO 620 Lecture #7 7
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 8
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 9
:A
:B
:C
:D
:E
msg
1()
«ass
ocia
tion
»
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)
INFO 620 Lecture #7 10
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 11
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 12
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 13
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 14
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 15
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): ()
INFO 620 Lecture #7 16
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 17
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 18
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
INFO 620 Lecture #7 19
Default Visibility
• Unless otherwise specified, the most common defaults for visibility are:– All attributes are private– All methods are public
INFO 620 Lecture #7 20
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 21
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 22
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 23
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 24
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()
INFO 620 Lecture #7 25
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 26
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 27
Statechart Diagrams
• Common statechart subjects include:– Use cases– Communication between subsystems– Entire systems– Windows interface– Controllers– Transactions– External systems
INFO 620 Lecture #7 28
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)
INFO 620 Lecture #7 29
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
INFO 620 Lecture #7 30
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
INFO 620 Lecture #7 31
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 32
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 33
Component Diagram
• Each component is identified by its stereotype– <<file>>– <<database>>– <<browser>>– <<library>>– <<process>>
• Components may include DLL or JAR files
«file»Component1
INFO 620 Lecture #7 34
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 35
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 36
Subsystem Diagram
<<subsystem>> sub1
«file»Component1
«file»Component2
INFO 620 Lecture #7 37
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 38
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
INFO 620 Lecture #7 39
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 40
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