Information Systems Analysis and Design Design Class Diagrams and others

1. Information Systems Analysis and DesignDesign Class Diagrams and others INFO 620 Glenn Booker 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 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 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 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) Lecture #7

6. Parameter Visibility • Parameter visibility from A to B is when B is passed as a parameter to a method of AIn this example, :Sale has parameters spec and qty visible because they were passed to it from :Register 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 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 Lecture #7

9. Showing Visibility (optional) • In a collaboration diagram, these kinds of visibility can be shown with stereotypes: (attribute) 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 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 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 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 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 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) 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 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 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 Lecture #7

19. Default Visibility • Unless otherwise specified, the most common defaults for visibility are: • All attributes are private • All methods are public 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 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 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 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 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) 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? 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 Lecture #7

27. Statechart Diagrams • Common statechart subjects include: • Use cases • Communication between subsystems • Entire systems • Windows interface • Controllers • Transactions • External systems 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) Lecture #7

29. 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 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 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) 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 Lecture #7

33. Component Diagram • Each component is identified by its stereotype • <<file>> • <<database>> • <<browser>> • <<library>> • <<process>> • Components may include DLL or JAR files Lecture #7

34. Deployment Diagram • The deployment diagram shows where components are physically located on nodes or processing units (servers), p. 606 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 Lecture #7

36. Subsystem Diagram 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 Lecture #7

38. Activity Diagrams p. 608 • 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] Lecture #7

39. Activity Diagrams • Multiple flow options, either splitting or converging, are shown by a heavy horizontal lineFlow of objects are shown by dotted lines with arrowheads 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 Lecture #7