MODELING WITH UML - INTRODUCTION - PowerPoint PPT Presentation

Loading...

PPT – MODELING WITH UML - INTRODUCTION PowerPoint presentation | free to download - id: 8572c0-MzhlM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

MODELING WITH UML - INTRODUCTION

Description:

MODELING WITH UML - INTRODUCTION UML ... An example of swimlanes in a UML activity diagram. UML DIAGRAMS ... Name Purpose Members Clock A device that measures time. – PowerPoint PPT presentation

Number of Views:66
Avg rating:3.0/5.0
Slides: 67
Provided by: Dr232035
Learn more at: http://elista.akprind.ac.id
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: MODELING WITH UML - INTRODUCTION


1
MODELING WITH UML - INTRODUCTION
  • UML
  • offers a well defined syntax (for object
    representation/description), well defined
    semantics (to foster common understanding of
    notation), and well suited (in broadly describing
    all aspects of systems under discourse). That
    is, it is a unified modeling language.
  • ISSUES
  • The concept of modeling objects using UML
    notations (five key graphical syntactic
    notations)
  • Notations Use Cases, Class Diagrams, Sequence,
    Diagrams, Statechart Diagrams, Activity Diagrams,
    plus management notations Component and
    Deployment Diagrams
  • Environment or CASE for UML object modeling
    (Rational Rose and Real-Time Rational Rose)
  • Background of UML Origins in OMT, Booch, OOSE,
    etc. plus Harels state diagrams
  • SYSTEM MODELS (in UML notation)
  • Functional Model use case diagrams (synthesized
    from scenarios from phenomena and concepts)
  • Object Model class diagrams (representing
    object structures as objects, attributes,
    associations, and operations)
  • Dynamic Model sequence diagrams, statechart
    diagrams and activity diagrams (describe the
    internal behavior or finite state machine of the
    system). SD are inter-object messaging and
    interactions, while SC-diagrams depict the finite
    state machine description of an objects behavior

2
2.2 UML OVERVIEW - USE CASE DIAGRAMS
  • DESCRIBE SYSTEM FUNCTIONALITY FROM EXTERNAL VIEW,
    UML Use Cases provide the notation for eliciting
    and analyzing the functionality
  • ACTORS (entities users, other systems, the
    operating environment) ARE ENTITIES EXTERNAL TO
    AND INTERACT WITH THE SYSTEM FUNCTIONALITY (The
    Use Cases)
  • THE SYSTEMS BOUNDARY IS DEFINED BY THE ACTORS
    AND THE USE CASES THE INTERNALS (represented by
    the Use Cases) AND THE EXTERNAL (represented by
    the Actors)
  • USE CASE DIAGRAMS Notation for representing the
    Use Cases, Actors, and the Boundary. The
    Relationship between the Use Cases and the Actors
    is represented by the LINKS (or lines)
  • (Fig 2-1)

3
SimpleWatch
WatchUser
Figure 2-1. A UML use case diagram describing the
functionality of a simple watch. The WatchUser
actor may either consult the time on her watch
(with the ReadTime use case) or set the time
(with the SetTime use case). However, only the
WatchRepairPerson actor may change the battery of
the watch (with the ChangeBattery use case).
Actors are represented with stick figures, use
cases with ovals, and the boundary of the system
with a box enclosing the use cases.
4
CLASS DIAGRAMS
  • NOTATION FOR DESCRIBING SYSTEM STRUCTURE
  • EACH CLASS IS AN ABSTRACTION (Containment) OF A
    SET OF RELATED OBJECTS
  • CLASSES ARE LINKED THROUGH ASSOCIATION, AND
    OBJECTS ARE INSTANCES OF CLASSES
  • CLASS DIAGRAMS ARE SPECIFIED IN TERMS OF
  • objects, classes, attributes, operations, and
    associations
  • CLASSES ARE INTERCONNECTED BY ASSOCIATIONS
    (labeled links)
  • The numbers, called MULTIPLICITIES, at the two
    ends of the link indicate the number of
    associations/relationships between the pair of
    linked classes
  • EACH CLASS IS GRAPHICALLY REPRESENTED AS A
    RECTANGLE OF 3 COMPARTMENTS
  • The class-name, The object-attributes, The
    object-methods
  • (Fig 2-2)

5
Figure 2-2. A UML class diagram describing the
elements of a simple watch.
6
SEQUENCE DIAGRAMS
  • USED TO FORMALIZE THE BEHAVIOR AND INTERACTIONS
    AMONG OBJECT CLASSES
  • DEPICT OR GIVE VISUAL PRESENTATION OF THE FLOW OF
    COMMUNICATION AMONG THE OBJECTS IN A USE CASE
  • THE DIAGRAMMING PROCESS HELPS IN IDENTIFYING MORE
    PARTICIPATING OBJECT, WHICH WERE MISSING FROM THE
    USE CASES
  • COLUMNS IN A SEQ DIAGRAMS REPRESENT
  • The Actors (typically, the leftmost column) that
    interact with that Use Case
  • Objects that participate in that Use Case (object
    names are underlined)
  • Labeled arrows that indicate the stimuli or
    message an object sends to other objects
  • (See Fig 2-3)

7
Figure 2-3. A UML sequence diagram for the
SimpleWatch. The leftmost column represents the
timeline of the WatchUser actor who initiates the
use case. The other columns represent the
timeline of the objects that participate in this
use case. Object names are underlined to denote
that they are instances (as opposed to classes).
Labeled arrows are stimuli that an actor or an
object sends to other objects.
8
STATECHART DIAGRAMS
  • DESCRIBE THE BEHAVIOR OF INDIVIDUAL OBJECTS AS
  • States representing a set of values for the
    object
  • Transitions representing the future state an
    object can move into, along with a specification
    of the condition (annotations) under which the
    object can move
  • STATECHARTS REPRESENT DIFFERENT INFORMATION FROM
    SEQ DIAGRAMS
  • (Fig 2-4)

9
Figure 2-4. A UML statechart diagram for SetTime
use case of the SimpleWatch.
10
ACTIVITY DIAGRAMS
  • ACTIVITIES ARE STATES THAT REPRESENT THE
    EXECUTION OF A SET OF OPERATIONS
  • STATES ARE CONNECTED BY TRANSITIONS, REPRESENTING
    CONTROL FLOW AND THICK RECTANGULAR BARS,
    REPRESENTING SYNCHRONIZATION POINTS
  • SEQUENCE AND CONCURRENT ACTIVITIES (and
    Swimlanes) CAN BE DESCRIBED
  • (See Fig 2-5)

11
Figure 2-5. An example of a UML activity diagram.
Activity diagrams represent behavior in terms of
activities and their precedence constraints. The
completion of an activity triggers an outgoing
transition, which in turn may initiate another
activity.
12
2.3 MODELING CONCEPTS
  • OBJECT-ORIENTED MODELING Building an
    abstraction of a system as a model of objects
  • CONCEPTS
  • System An organized set of communicating parts
    for a purpose (Watch components for time, Car
    components for transportation, Payroll software
    components for preparing employees pay)
  • Subsystem A recursively defined subset of a
    system, whose atomic parts are objects, performs
    a sub-function of the system (Engine of a Car,
    The Display unit of a Watch)
  • Modeling Constructing a structure for complexly
    interconnected subsystems of a system. The
    modeling process is guided by
  • abstraction (I.e., deference of details),
  • divide-and-conquer,
  • ignoring the irrelevant
  • E.g., modeling an airplane with subsystems
    flight simulator, instrument panel, exterior
    layout, engine
  • (Fig 2-6)

13
Scale model
Electrical
All blueprints
Airplane
Fuel
Flight simulator
Figure 2-6. A Model is an abstraction describing
a subset of a System. A View depicts selected
aspects of a Model. Views and Models of a single
System may overlap each other.
14
MORE CONCEPTS
  • VIEW A specific focus of a (sub)model on
    current interest, enough to understand by one
    person
  • NOTATIONS Graphical or textual rules (syntax)
    for representing views (E.g., UML class diagram
    notation)
  • UML diagramming notations focus on Classes,
    Events, States, Interactions, Activities
  • Fig 2-7 Fig 2-8

15
Booch
N
Book
Chapter
composed-of
Figure 2-7. Example of describing a model with
two different notations. The model includes two
classes, Book and Chapter, with the relationship,
Book is composed of Chapters. In UML, classes are
depicted by rectangles and aggregation
associations by a line terminated with a diamond.
In the Booch notation, classes are depicted by
clouds, and aggregation associations are depicted
with a line terminated with a solid circle.
16
Figure 2-8. Example of describing the same model
with two different notations. This UML diagram
represents the information of Figure 2-6 A
System can be described by many different Models
that can be depicted by many different Views.
17
CONCEPTS, PHENOMENA, MODELING PROCESS
  • PHENOMENON A perceived object or idea or entity
    or fact or occurrence
  • CONCEPT An unifying description, which
    abstractly describes a set of phenomena (as a
    collective object or idea or entity or fact or
    occurrence)
  • A Concept also describes the common attributes
    of the set
  • A Concept has 1) a name 2) purpose or properties
    and 3) membership the phenomena
  • ABSTRACTION The classification of phenomena
    into concepts
  • MODELING Development or construction of
    abstractions (with deferred details)
  • (E.g., the periodic table of atoms, biological
    classification)
  • A model may be constructed prior to the
    concept/phenomena it represents (.e.g., new
    theories)
  • (See Fig 2-9)

18
Name
Purpose
Members
Clock
Figure 2-9. The three components of the Clock
concept name, purpose, and members.
19
DATA TYPES, ABSTRACTION DATA TYPES, AND INSTANCES
  • Language Perspective An abstraction of data,
    with unique name, purpose (structure and
    operations on members) and members. E.g., int,
    float, ,
  • ADT Special type with supporting information
    hiding, with separation of specs from
    implementation. E.g., Person, getName.Person()
    Implementation of Name type is hidden
  • An Instance Any member of specific type. E.g.,
    1291 is member of int-type
  • Data Type Concepts Instances Phenomena

20
CLASSES, ABSTRACT CLASSES, AND OBJECTS
  • CLASS Like ADT, class is an abstraction in
    object-oriented programming languages, which
    encapsulates both structure (objects or members)
    and behavior (operations)
  • SUPERCLASSES Unlike ADT, Classes can be
    generalized into higher classes through
    inheritance mechanism or principle. Where there
    are superclasses, subclasses refine the
    superclass by defining new attributes and
    operations. (Fig 2-10)
  • ABSTRACT CLASSES A generalization in which the
    superclass models only shared attributes and
    operations, and never instantiated (Fig 2-11).
    Used to reduce complexity and increase reuse
  • OPERATIONS Defined in a class and applied to
    its instances. A superclasss operations are
    inherited and applied to objects of the
    subclasses.
  • ATTRIBUTES Defined and applied to all
    instances. Attributes have unique names and
    serve as place-holders for object values.
  • OBJECT Instance of a class, has unique name
    (underlined), and stores values of attributes,
    has behavior and defined only in one class (fig
    2-12). Unlike ADT, object attribute can be
    visible to outside world (public), i.e., known or
    seen from outside of class definition

21
Watch
time
date
SetDate(d)
CalculatorWatch
calculatorState
Figure 2-10. A UML class diagram depicting two
classes Watch and CalculatorWatch.
CalculatorWatch is a refinement of Watch,
providing calculator functionality normally not
found in normal Watches. In a UML class diagram,
classes and objects are represented as boxes with
three compartments The first compartment depicts
the name of the class, the second depicts its
attributes, the third its operations. The second
and third compartments can be omitted for
brevity. An inheritance relationship is displayed
by a line terminated with a triangle. The
triangle points to the superclass, and the other
end is attached to the subclass.
22
Figure 2-11. An example of abstract class (UML
class diagram). OrganicCompound is never
instantiated and only serves as a generalization.
23
ltltinstanceOfgtgt
Watch
simpleWatch1291Watch
calculatorWatch1515
ltltinstanceOfgtgt
CalculatorWatch
CalculatorWatch
Figure 2-12. A UML class diagram depicting
instances of two classes. simpleWatch1291 is an
instance of Watch. calculatorWatch1515 is an
instance of CalculatorWatch. Although the
operations of Watch are also applicable to
calculatorWatch1515, the latter is not an
instance of the former.
24
EVENTS CLASSES, EVENTS, AND MESSAGES
  • EVENT CLASS An abstraction of a kind of event
    for which the system has a common response
  • EVENT Instance of an event class, a stimulus,
    or relevance occurrence, which needs a response
  • MESSAGE A mechanism for conveying or
    transmitting signals that create a stimulus or an
    occurrence from a sending/requesting object to a
    receiving object. The receiving object executes
    its operation to provide a service requested by
    the sending object. Message may contain
    arguments, which define the protocol of the
    communication (Fig 2-13)

25
WatchUser
pressButton2()
getTime()
GMTTime
getTimeDelta()
GMTTime
Figure 2-13. Examples of message sends (UML
sequence diagram). The Watch object sends the
getTime() message to a Time object to query the
current Greenwich time. It then sends the
getTimeDelta() message to a TimeZone objects to
query the difference to add to the Greenwich
time. The dashed arrows represent the results
that are sent back to the message sender.
26
OBJECT-ORIENTED MODELING PROTOTYPING USING
FALSIFICATION/SIMPLIFICATION
  • APPLICATION DOMAIN The users physical
    environment including users, people, work
    processes, and all associated dynamics or changes
    over time
  • SOLUTION DOMAIN Space of all possible
    solutions, and all the possible changes due to
    changes in technological enablers. This is
    modeled as the system design and object design
    activities of the software process
  • OO ANALYSIS Focuses on modeling the application
    domain (using objects classes)
  • OO DESIGN Focuses on modeling the solution
    domain (using objects and classes)
  • SYSTEM MODEL Comprises the application domain
    model solution domain model
  • (OO UNIFORMITY Using OO paradigm for both
    Application and Solution domain modeling fosters
    traceability, class encapsulation into
    subsystems/decomposition, and reusability
  • PROTOTYPING Removal of irrelevant/details to
    simplify modeling (assumptions falsify the
    conceptual model, and refined or validated
    through evolutionary modeling or feedback)
  • Fig 2-14)

27
Figure 2-14. The application domain model
represents entities of the environment which are
relevant to an air traffic control system (e.g.,
aircraft, traffic controllers). The system model
represents entities that are part of the system
(e.g., map display, flight plan database). In
object-oriented analysis and design, the
application domain model is also part of the
system model. An example in this figure is the
TrafficControl package that appears in both
models.
28
2.4 UML DIAGRAMS IN DEPTH
  • USE CASE DIAGRAMS Represent system
    functionality from user perspectives and define
    the systems boundaries (between the internals
    and external side operating environment)
  • COMPONENTS Actors and Use Cases
  • Actors External entities interacting with the
    system. Have unique names, descriptions, and
    roles
  • Use Case Describe system external behavior (seen
    by actors). Describe system internal behavior in
    terms of events that yield results expected by
    actors. Internal use cases interact via
    invocation and service provisions, and messaging
    among themselves to fulfill functionality
    requested (by the actors). Thus actors and use
    cases communicate.
  • Each named use case represents a
    behavior/functionality invoked/initiated by an
    actor or another use case(s).
  • Links or bidirectional lines connecting actors
    and use cases represent information flow
  • (Fig 2-15)
  • USE CASE TEMPLATE (natural language or textual
    specification understandable to user)
  • A structured text of six (6) fields which
    describe each use case (represented in the Use
    Case Diagram)
  • Fields name, participating actors, entry
    condition, flow of events (listed), exit
    condition, non-functional or special requirements
  • (Fig 2-16)

29
Figure 2-15. An example of a UML use case
diagram Incident initiation in an accident
management system. Associations between actors
and use cases represent information flows. In
UML, these associations are bidirectional They
can represent the actor initiating a use case
(e.g., FieldOfficer initiates ReportEmergency) or
a use case providing information to an actor
(e.g., ReportEmergency notifies Dispatcher).
30
UML DIAGRAMS IN DEPTH - 2
  • COMPONENTS Scenarios
  • Use Case abstracts all possible scenarios in the
    specific functionality (containment)
  • Scenario An instance of a use case describing a
    concrete set of actions. The totality of sets of
    scenarios (I.e., all use cases) completely
    describes the system
  • SCENARIO TEMPLATE (natural language or textual
    specification understandable to user)
  • A structured text of three (3) fields which
    describe each scenario
  • Fields name (unique and underlined),
    participating actors (with underlined names),
    flow of events (sequence of steps, with logical
    order) (Fig 2-17)
  • RELATIONSHIPS BETWEEN USE CASES (among) AND
    ACTORS
  • Communication Between actors and use cases,
    depicted by a solid, bidirectional line (cf. Fig
    2-15)
  • Include A use case that encapsulates common
    functions and sharable by other use cases. A
    dashed arrow pointing from all the sharing use
    cases to the common use case model is used to
    represent the relationship. The common use
    case is referenced in the using use case
    template, either in the special-requirements
    field Or explicitly in the flow-of-event field
    like ref to library units (Fig 2-18)
  • Extend Special, exception-like functions which
    are described in a use case model to handle
    pathological conditions (extension to some main
    functionalities) like exception-handling
    routines. A dashed arrow pointing from the
    extended use case model to all the using use
    cases is used to represent the relationship.
    The extended use case is represented in the
    entry field of the using use casess. (Fig 2-19
    and Fig 2-20)

31
  • Use case name Report Emergency
  • Participating actor Invoked by FieldOfficer
  • Communications with Dispatcher
  • Entry Condition 1. The FieldOfficer activates
    the Report Emergency function of her terminal.
    FRIEND responds by presenting a form to the
    officer.
  • Flow of events 2. The FieldOfficer fills the
    form by selecting the emergency level, type,
    location, and brief description of the
    situation. The FieldOfficer also describes
    possible responses to the emergency situation.
    Once the form is completed, the FieldOfficer
    submits the form, at which point the
    Dispatcher is notified.
  • 3. The Dispatcher reviews the submitted
    information and creates an Incident in the
    database by invoking the OpenIncident use case.
    The Dispatcher selects a response and
    acknowledges the emergency report.
  • Exit condition 4. The FieldOfficer receives the
    acknowledgement and the selected response.
  • Special requirements The FieldOfficers report
    is acknowledged within 30 seconds. The selected
    response arrives no later than 30 seconds
    after it is sent by the Dispatcher.

32
Figure 2-18. An example of an ltltincludegtgt
relationship (UML use case diagram).
33
ltltextendgtgt
OpenIncident
ConnectionDown

ltltextendgtgt
AllocateResources
Figure 2-19. An example of an ltltextendgtgt
relationship (UML use case diagram).
34
UML DIAGRAMS IN DEPTH - 3
  • RELATIONSHIPS BETWEEN USE CASES (among) AND
    ACTORS 2
  • Generalization Also called specialization
    relationship, is a mechanism to move details or
    specialization to other use cases with a
    high-level use case (the generalized one). A
    solid line with an open rectangular head from the
    specialized use cases to the general use case is
    used to represent the relationship. (Fig 2-21)

35
Figure 2-21. An example of a generalization
relationship (UML use case diagram). The
Authenticate use case is a high-level use case
describing, in general terms, the process of
authentication. AuthenticateWithPassword and
AuthenticateWithCard are two specializations of
Authenticate.
36
UML DIAGRAMS IN DEPTH - 4
  • CLASS DIAGRAMS Describe the structure of the
    system in terms of objects and classes
  • COMPONENTS
  • Classes Abstraction or containment which
    describe the attributes and behaviors of a set of
    objects. Class names begin with a capital letter
  • Objects Entities that encapsulate state and
    behavior, with a unique identity or name
    (underlined). Object names are in lower case
    letters, underlined and followed by a colon and
    name of its class.
  • Each class/object diagrams has three
    compartments The Top (name of class or object),
    The Center (displays attributes), The Bottom
    (displays operations). The Center and Bottom
    can be omitted to reduce clutter.
  • The attributes could be typed (preceded by the
    attribute name and a colon) in the Class Diagram
  • The attributes could be assigned values (preceded
    by the attribute name and the assignment op) in
    Object Diagrams

37
UML DIAGRAMS IN DEPTH - 5
  • RELATIONSHIPS BETWEEN CLASS/OBJECT DIAGRAMS
  • Associations and Links A link is a solid line
    between objects/classes. An association is a
    bundle of relationships between same. (An
    inter-object class link represents a state rather
    than relationship.) (Fig 2-22, Fig 2-23)
  • Roles Labels at the ends of a link or
    association, and help distinguish between
    multiple associations originating from a class
    and also clarify purpose of the association (Fig
    2-23)
  • Multiplicity A set of integers (or range of
    integers) labeling the end of a link or
    association. The specified number (or range)
    indicate the number of associations originating
    from the instance to the association end. There
    could a one-to-one, one-to-many, and many-to-many
    associations. (Fig 2-22, Fig 2-25)
  • Association Class When an association link
    carries more information (attributes and
    operations) to be represented as a class and
    depicted by a class symbol. The AC is connected
    by a dashed line to the link (which connects the
    principal classes). A transformed AC (which
    removes the principal link) results in a two,
    one-to-one associations between the AC and each
    of the principal classes). (Fig 2-24 and Fig
    2-25)
  • Aggregation or Composition A one-to-many
    association modeling which represents the concept
    of an aggregation, with hierarchical
    representation. Depicted by a simple line with
    a diamond at the container end of the association
    Fig 2-26
  • Generalization Representing the common
    attributes and operations in a general class,
    leaving specifics to subordinate classes, with
    inheritance to create a (abstract) superclass and
    subclasses (Fig 2-27)
  • Operations/Methods Operations specify the
    signature of object behaviors (a set of which
    represents a service of the class) and Methods
    define the implementations of the operations.
    Request for a service is via message exchanges
    between objects in the client-server object
    classes. (Fig 2-28)

38
reports
1
Incident
EmergencyReport
1..

reportsGenerated

incidentsGenerated
Dispatcher
FieldOfficer
1
nameString
1
nameString
badgeNumberInteger
badgeNumberInteger
initiator
author
Figure 2-22. An example of a UML class diagram
classes that participate in the ReportEmergency
use case. Detailed type information is usually
omitted until object design
39
report_1291
incident_1515
bobFieldOfficer
name Bob D.
badgeNumber 132
johnDispatcher
name John D.
aliceFieldOfficer
badgeNumber 12
name Alice W.
badgeNumber 23
Figure 2-23. An example of a UML object diagram
objects that participate in the warehouseOnFire
scenario.
40
Allocates
roleString
notificationTimeTime
FieldOfficer
Incident
nameString
1
resources
badgeNumberInteger
incident
1..
Figure 2-24. An example of an association class
(UML class diagram).
41
Allocation
1
1
roleString
notificationTimeTime
FieldOfficer
incident
1
nameString
Incident
badgeNumberInteger
resources
1..
Figure 2-25. Alternative model for Allocation
(UML class diagram).
42


1
1

1

1
Figure 2-26. Examples of aggregations (UML class
diagram). A State contains many Counties, which
in turn contains many Townships. A PoliceStation
has many PoliceOfficers. A file system Directory
contains many Files.
43
PoliceOfficer
initiator
author
FieldOfficer
Dispatcher
1
1
reportsGenerated

incidents

1
EmergencyReport
Incident
1..
Figure 2-27. An example of a generalization (UML
class diagram). PoliceOfficer is an abstract
class which defines the common attributes and
operations of the FieldOfficer and Dispatcher
classes.
44
Figure 2-28. Examples of operations provided by
the Incident class (UML class diagram).
45
UML DIAGRAMS IN DEPTH - 6
  • SEQUENCE DIAGRAMS Describe patterns of
    communication among a set of interacting objects
    via message exchanges. Optionally parameterized
    message reception generates an event occurrence
    and execution of an operation / service. (Fig
    2-29)
  • SD are typically used to describe event flow of a
    use case, identify participating objects in the
    use case, and describe the necessary use case
    behavior of these objects to form a particular
    service.
  • COMPONENTS
  • Columns represents a participating object in the
    interaction
  • Vertical Axis represents time passage (from top
    to down), and time-intervals or elapsed can be
    labeled
  • Arrowed line indicate messages
  • Labels of arrows represent message names (with
    optional arguments)
  • Vertical rectangles Depict message activation
  • Leftmost column Represent actors (could also be
    rightmost column) Participating objects are
    typically called control and boundary objects.
  • Other Semantics
  • When describing all possible interactions, SD can
    bear conditional and iterative expressions. (Fig
    2-30)

46
Figure 2-29. Example of a sequence diagram
setting the time on 2Bwatch.
47
Figure 2-30. Examples of conditions and iterators
in sequence diagrams.
48
UML DIAGRAMS IN DEPTH - 7
  • STATECHART DIAGRAMS Statecharts make explicit
    the attribute, or set of attributes, which impact
    on the behavior of a single object using a
    sequence of states an object goes through in
    response to external events. Statecharts extend
    finite state machines.
  • The provide a notation for nesting states and
    FSM, a notation for transitions (with messages
    and conditions) between states.
  • COMPONENTS
  • A State A condition that an object satisfies
    (an abstraction of a set of valued attributes in
    a class) (Fig 2-31). Depicted by a rounded
    rectangle.
  • A Transition Changes of state triggered by
    events, conditions, or time. Depicted by an
    arrow
  • Start/End States Special states that indicate
    the initial and final states, and respectively
    indicated by a solid black circle and a circled
    solid black circle
  • (See Fig 2-32 A statechart of the 2BWatch)

49
Active
Inactive
Closed
Archived
incidentHandled
incidentDocumented
incidentArchived
Figure 2-31. A UML statechart diagram for the
Incident class.
50
pressButtonsLAndR
after 2 min.
pressButtonsLAndR/beep
after 20 years
after 20 years
Figure 2-32. Statechart diagram for 2Bwatch set
time function.
51
UML DIAGRAMS IN DEPTH - 8
  • STATECHART DIAGRAMS 1
  • Internal Transition or nested statecharts
  • Detail the event-flows within each single state
    syntactically action/state-change, with labeled
    transitions. Entry/exit states are also
    indicated.
  • Internal transitions can also be used to detail
    nested statecharts
  • Statecharts and internal transitions are used to
    identify object attributes and refine behavior
    description
  • Statecharts are used at the System Analysis and
    Object Design states to describe object dynamic
    models in the solution domain
  • (See Fig 2-33 and Fig 2-34)

52
Figure 2-33. Internal transitions associated with
the SetTime state (UML statechart diagram).
53
Figure 2-34. Refined statechart associated with
the SetTime state (UML statechart diagram).
54
UML DIAGRAMS IN DEPTH - 9
  • ACTIVITY DIAGRAMS
  • Each node represents a set of actions, whose
    completion causes a transition to the next
    action state
  • The name of the state indicates an action or
    set of activities, depicting control-flow between
    activities (See Fig 2-35)
  • Decisions Branching in the control flow,
    represented by a diamond, with one or more
    incoming transitions arrows and two or more
    outgoing transitions (set of all possible
    outcomes) (See Fig 2-36)
  • Complex transitions used to model
    synchronization of (transitions from) multiple
    activities OR forking of (transitions into)
    multiple activities (See Fig 2-37)
  • Swimlanes grouping of actions into related
    activities/functionalities, represented by
    enclosing such related-activities or subsystems
    in rectangular boxes. Transitions could cross
    swimlane boundaries (See Fig 2-38)
  • Activity diagrams are useful 1) identifying
    subsystems, 2) describing sequencing constraints
    among use cases, 3) synchronization of concurrent
    activities

55
Figure 2-35. A UML activity diagram for Incident.
During the action state HandleIncident, the
Dispatcher receives reports and allocates
resources. Once the Incident is closed, the
Incident moves to the DocumentIncident activity
during which all participating FieldOfficers and
Dispatchers document the Incident. Finally, the
ArchiveIncident activity represents the archival
of the Incident related information onto slow
access medium.
56
lowPriority
fire highPriority
not fire highPriority
Figure 2-36. Example of decision in the
OpenIncident process. If the Incident is a fire
and is of high priority, the Dispatcher notifies
the FireChief. If it is a high-priority Incident
that is not a fire, the PoliceChief is notified.
In all cases, the Dispatcher allocates resources
to deal with the Incident.
57
Figure 2-37. An example of complex transitions in
a UML activity diagram.
58
Figure 2-38. An example of swimlanes in a UML
activity diagram.
59
UML DIAGRAMS IN DEPTH - 10
  • Diagram Organization using Packages
  • Dealing with complex models, group related
    elements into packages (where an elements are
    use cases, classes, activities
  • Grouping could be by actors, functions-activities,
    etc.
  • The details of elements within a package could be
    abstracted (suppressed)
  • Example of use-case grouping into packages (See
    Fig 2-39 an Fig 2-40)
  • Example of class-diagram grouping into packages
    (See Fig 2-41 based on incident site where
    objects are created)
  • Packages are just for organizing the basic UML
    diagramming elements. Packages that have any
    syntactic or semantic behaviors
  • Packages can be annotated with notes for
    comments, remarks, to-dos, reminders, etc. (See
    Fig 4-42)

60
Report

Emergency
Dispatcher
OpenIncident
FieldOfficer
AllocateResources
ArchiveIncident
ManageUsers
Librarian
SysAdmin
SearchArchive
ManageTerminals
Figure 2-39. Example of packages use cases of
FRIEND organized by actors (UML use case
diagram).
61
Figure 2-40. Example of packages This figure
displays the same packages as Figure 2-39 except
that the details of each packages are suppressed
(UML use case diagram).
62
Figure 2-41. Example of packages. The
FieldOfficer and EmergencyReport classes are
located in the FieldStation package, and the
Dispatcher and Incident classes are located on
the DispatcherStation package.
63
Figure 2-42. An example of a note. Notes can be
attached to a specific element in a diagram.
64
UML DIAGRAMS IN DEPTH - 11
  • Diagram Extensions
  • UML provides a set of basic diagramming notations
    for modeling complex systems
  • UML provides a number of extension mechanisms to
    extend the languages
  • UML extensions are called stereotypes and
    constraints
  • Stereotypes - a string enclosed in a pair of
    angle brackets, ltltstringgtgt, which is attached to
    an UML element (a class or an association)
  • Allows creation of new building blocks for the
    given application domain or problem area
  • E.g., the introduction of specific object type -
    ltltcontrolgtgt, ltltboundarygtgt, ltltentitygtgt
  • (See Fig 2-43)
  • Constraint - rule that is attached to an UML
    building block
  • E.g., attaching a rule that requires sorting of
    documents/reports in chronological order via the
    association (See Fig 2-44)
  • Constraints may be expressed using an informal
    string or using a formal language like OCL
    (Object Constraint Language subset of UML),
    when enclosed in a pair of square brackets .

65
Figure 2-43. Examples of stereotypes (UML class
diagram).
66
Figure 2-44. An example of constraint (UML class
diagram).
About PowerShow.com