Information Systems Analysis and Design Design Class Diagrams and others - PowerPoint PPT Presentation

1 / 40
About This Presentation
Title:

Information Systems Analysis and Design Design Class Diagrams and others

Description:

Parameter Visibility. Parameter visibility from A to B is when B is passed as a ... In this example, :Sale has parameters spec and qty visible because they were ... – PowerPoint PPT presentation

Number of Views:429
Avg rating:3.0/5.0
Slides: 41
Provided by: Gle780
Category:

less

Transcript and Presenter's Notes

Title: Information Systems Analysis and Design Design Class Diagrams and others


1
Information Systems Analysis and DesignDesign
Class Diagrams and others
  • INFO 620
  • Glenn Booker

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

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

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

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)

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

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

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

9
Showing Visibility (optional)
  • In a collaboration diagram, these kinds of
    visibility can be shown with stereotypes

(attribute)
10
Design Class Diagrams
  • The design class diagrams (DCDs) are generally
    created at the same time as the interaction
    diagrams
  • DCDs add several dimensions to the conceptual
    class diagram (domain model)
  • Methods for each class
  • Attributes, with type and visibility defined
  • Navigation between objects

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

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

13
Creating DCDs
  • 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
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
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
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
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
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
Default Visibility
  • Unless otherwise specified, the most common
    defaults for visibility are
  • All attributes are private
  • All methods are public

20
DCD and the RUP
  • Some CASE tools can create DCDs from source
    code this is called reverse engineering
  • In the Rational Unified Process, DCDs are
    started in the Elaboration phase, and refined in
    the Construction phase

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

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 dont care much what causes these changes in
    states, we just want to be able to describe them

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

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)

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 systems life?

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

27
Statechart Diagrams
  • Common statechart subjects include
  • Use cases
  • Communication between subsystems
  • Entire systems
  • Windows interface
  • Controllers
  • Transactions
  • External systems

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)

29
More State Diagram Notation
p. 445
  • 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

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

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)

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

33
Component Diagram
  • Each component is identified by its stereotype
  • ltltfilegtgt
  • ltltdatabasegtgt
  • ltltbrowsergtgt
  • ltltlibrarygtgt
  • ltltprocessgtgt
  • Components may include DLL or JAR files

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

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

36
Subsystem Diagram
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

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

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

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_def
    inition.pdf
Write a Comment
User Comments (0)
About PowerShow.com