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

2. INFO 620Lecture #72 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

3. INFO 620Lecture #73 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

4. INFO 620Lecture #74 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

5. INFO 620Lecture #75 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)

6. INFO 620Lecture #76 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

7. INFO 620Lecture #77 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

8. INFO 620Lecture #78 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

9. INFO 620Lecture #79 Showing Visibility (optional) In a collaboration diagram, these kinds of visibility can be shown with stereotypes: (attribute)

10. INFO 620Lecture #710 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

11. INFO 620Lecture #711 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

12. INFO 620Lecture #712 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

13. INFO 620Lecture #713 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

14. INFO 620Lecture #714 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

15. INFO 620Lecture #715 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)

16. INFO 620Lecture #716 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

17. INFO 620Lecture #717 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

18. INFO 620Lecture #718 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

19. INFO 620Lecture #719 Default Visibility Unless otherwise specified, the most common defaults for visibility are: –All attributes are private –All methods are public

20. INFO 620Lecture #720 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

21. INFO 620Lecture #721 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

22. INFO 620Lecture #722 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

23. INFO 620Lecture #723 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

24. INFO 620Lecture #724 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)

25. INFO 620Lecture #725 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?

26. INFO 620Lecture #726 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

27. INFO 620Lecture #727 Statechart Diagrams Common statechart subjects include: –Use cases –Communication between subsystems –Entire systems –Windows interface –Controllers –Transactions –External systems

28. INFO 620Lecture #728 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)

29. INFO 620Lecture #729 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

30. INFO 620Lecture #730 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

31. INFO 620Lecture #731 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)

32. INFO 620Lecture #732 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

33. INFO 620Lecture #733 Component Diagram Each component is identified by its stereotype – > Components may include DLL or JAR files

34. INFO 620Lecture #734 Deployment Diagram The deployment diagram shows where components are physically located on nodes or processing units (servers), p. 606

35. INFO 620Lecture #735 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

36. INFO 620Lecture #736 Subsystem Diagram

37. INFO 620Lecture #737 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

38. INFO 620Lecture #738 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

39. INFO 620Lecture #739 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

40. INFO 620Lecture #740 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