Domain Model Diagram Library Management System by ufn16927

VIEWS: 1,564 PAGES: 66

More Info
									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 Harel‟s 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 object‟s behavior
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 SYSTEM‟S 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)
                                     SimpleWatch




                                            ReadTime




                                             SetTime
          WatchUser                                                             WatchRepairPerson



                                        ChangeBattery




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.
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)
                                                   SimpleWatch

                                               1      1     1     1
       2                              1                                      2      1

 PushButton                        Display                         Battery       Time




Figure 2-2. A UML class diagram describing the elements of a simple watch.
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)
                                  : S i m p l e W a t c h           : D i s p l a y                 : T i m e
      : W a t c h U s e r
                                         ( )
                  p r e s s B u t t o n 1b l i n k H o u r s ( )

                   p r e s s B u t t o n 1 ( ) n k M i n u t e s ( )
                                         b l i

                  p r e s s B u t t o n 2 ( )
                                                                           i n c r e m e n t M i n u t e s ( )
                                                                                  r e f r e s h ( )
                p r e s s B u t t o n s 1 A n d 2 ( )
                                                                             c o m m i t N e w T i m e ( )
                                                s t o p B l i n k i n g ( )




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.
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)
                                                         button2Pressed
       button1&2Pressed                   Blink                                 Increment
                                          Hours                                   Hours



                                              button1Pressed




         button1&2Pressed                                button2Pressed
                                          Blink                                 Increment
                                         Minutes                                 Minutes



                                              button1Pressed


                                                         button2Pressed
          Stop                            Blink                                  Increment
        Blinking                         Seconds                                  Seconds




Figure 2-4. A UML statechart diagram for SetTime use case of the SimpleWatch.
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)
                                                        Allocate
                                                       Resources




            Open                                      Coordinate                                   Archive
          Incident                                     Resources                                  Incident




                                                       Document
                                                       Incident




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.
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)
                                                        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.
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
                       UML
                                                1                 *
                                Book                                      Chapter

                                                 composed-of


                       B ooch

                                                                      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.
                            *    1                                  *    1
            View                                   Model                      System
                             depicts                                describes




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.
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)
   Name                                  Purpose                               Members




  Clock                           A device that
                                  measures time.




Figure 2-9. The three components of the Clock concept: name, purpose, and members.
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
    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 superclass‟s 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
                          Watch

               time
               date

               SetDate(d)
                                                                                 CalculatorWatch


                                                                             calculatorState

                                                                             EnterCalcMode()
                                                                             InputNumber(n)




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.
                                           O r g a n i c C o m p o u n d




                                                 B e n z e n e




Figure 2-11. An example of abstract class (UML class diagram). OrganicCompound is never instantiated and only
serves as a generalization.
                                               <<instanceOf>>
         simpleWatch1291:Watch                                                       Watch




          calculatorWatch1515                  <<instanceOf>>
            :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.
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)
                                  :SimpleWatch                      :Time                     :TimeZone
       :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.
OBJECT-ORIENTED MODELING & PROTOTYPING USING FALSIFICATION/SIMPLIFICATION


   APPLICATION DOMAIN – The user‟s 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)
    Application Domain                                                     Solution Domain
    Application Domain Model                                               System Model

           TrafficControl                                                                                  MapDisplay
                                                                                SummaryDisplay


                               TrafficController                                     FlightPlanDatabase
         Aircraft

                                             Airport                                     TrafficControl
                   FlightPlan




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.
2.4: UML DIAGRAMS – IN DEPTH



   USE CASE DIAGRAMS – Represent system functionality from user perspectives and define
    the system‟s 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)
                                             F R I E N D



                                                         E m
                                                 R e p o r t e r g e n c y




  F i e l d O f f i c e r                           O p e n I n c i d e n t                         D i s p a t c h e r




                                                A l l o c a t e R e s o u r c e s


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).
    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)
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 FieldOfficer‟s report is acknowledged within 30 seconds. The selected response arrives no
                      later than 30 seconds after it is sent by the Dispatcher.
                                              < < i n c l u d e > >
                         O p e n I n c i d e n t

                                                       H e l p D i s p a t c h e r
                                         < < i n c l u d e > >
                 A l l o c a t e R e s o u r c e s




Figure 2-18. An example of an <<include>> relationship (UML use case diagram).
                                                 <<extend>>

                         OpenIncident

                                                         ConnectionDown
                                           <<extend>>
                 AllocateResources




Figure 2-19. An example of an <<extend>> relationship (UML use case diagram).
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)
                            Authenticate
                             WithPassword
                                                                Authenticate



                          Authenticate
                           WithCard




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.
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
    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)
                                                    reports                         1
                           EmergencyReport                                                      Incident
                                                     1..*
              reportsGenerated            *                                                         *
                                                                           incidentsGenerated

       FieldOfficer                                                Dispatcher

                                 1                          name:String                    1
  name:String
  badgeNumber:Integer                                       badgeNumber:Integer
                                 author                                                    initiator




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
                                    report_1291                                            incident_1515
 bob:FieldOfficer


name = “Bob D.”
badgeNumber = 132
                                                            john:Dispatcher


     alice:FieldOfficer                                    name = “John D.”
                                                           badgeNumber = 12

     name = “Alice W.”
     badgeNumber = 23




Figure 2-23. An example of a UML object diagram: objects that participate in the warehouseOnFire scenario.
                                                         Allocates

                                                role:String
                                                notificationTime:Time
     FieldOfficer                                                           Incident

name:String                    resources                                           1
badgeNumber:Integer
                               1..*                                     incident




Figure 2-24. An example of an association class (UML class diagram).
                                                     Allocation
                                        1
                                                                     1
                                             role:String
   FieldOfficer                              notificationTime:Time

                                                                         incident   1
name:String
badgeNumber:Integer                                                          Incident
                             1..* resources




Figure 2-25. Alternative model for Allocation (UML class diagram).
                             1         *                            1         *
           State                                 County                               Township

                             1         *
    PoliceStation                          PoliceOfficer

                             1         *
       Directory                                  File




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.
                                    PoliceOfficer

                                name:String
                                badgeNumber:Integer




                                                                                        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.
                                                 Incident



                                           assignResource(r)
                                           close()




Figure 2-28. Examples of operations provided by the Incident class (UML class diagram).
    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)
                               :SimpleWatch                 :LCDDisplay                   :Time
      :WatchUser

               pressButton1()
                                            blinkHours()

               pressButton1()               blinkMinutes()

               pressButton2()                                        incrementMinutes()

                                                                           refresh()

               pressButtons1And2()
                                                                     commitNewTime()
                                            stopBlinking()




Figure 2-29. Example of a sequence diagram: setting the time on 2Bwatch.
                       a                                   b              c


                                     [i>0]          op1()



                                       [i<=0]            op2()


                                   *op3()




Figure 2-30. Examples of conditions and iterators in sequence diagrams.
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)
  Active                      Inactive                          Closed                  Archived


           incidentHandled              incidentDocumented               incidentArchived




Figure 2-31. A UML statechart diagram for the Incident class.
                                          pressButtonsLAndR



                              MeasureTime                        SetTime



                                                after 2 min.


                                       pressButtonsLAndR/beep
          after 20 years
                                                                           after 20 years


                                               DeadBattery




Figure 2-32. Statechart diagram for 2Bwatch set time function.
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)
                                                           S e t T i m e
                         e   n   t   r   y   /   b   l   i n k h     o   u   r   s
                         p   r   e   s   s   B   u   t   t o n 1 /   b   l   i   n k n e x t n u m b e r
                         p   r   e   s   s   B   u   t   t o n 2 /   i   n   c   r e m e n t c u r r e n t   n u m b e r
                         e   x   i   t   /   s   t   o   p b l i     n   k   i   n g




Figure 2-33. Internal transitions associated with the SetTime state (UML statechart diagram).
                                                   S e t T i m e
                                           b 1                       b 1


                                         B                  e s
                       B l i n k H o u r s l i n k M i n u tB l i n k S e c o n d s
                      b 2 / i n c r h o u r / i n c r m ib 2 / i n c r s e c .
                                          b 2               n .

             b 1                                                                              b 1

                        B l i n k Y e a r B l i n k M o n t h B l i n k D a y
                                          b 2                .
                      b 2 / i n c r y e a r / i n c r m ob 2 / i n c r d a y


                                           b 1                    b 1



Figure 2-34. Refined statechart associated with the SetTime state (UML statechart diagram).
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
              Handle                             Document                            Archive
             Incident                            Incident                           Incident




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.
                                              [lowPriority]
       Open                                                                                      Allocate
    Incident                                                                                    Resources


                                                       [fire & highPriority]


        [not fire & highPriority]

                                                                 Notify
                                                              Fire Chief



                                  Notify
                              Police Chief




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.
                                                    Allocate
                                                   Resources


           Open                                   Coordinate                 Archive
         Incident                                  Resources                Incident



                                                    Document
                                                    Incident




Figure 2-37. An example of complex transitions in a UML activity diagram.
                                                                    Dispatcher
                                                   Allocate
                                                  Resources


           Open                                  Coordinate        Archive
         Incident                                 Resources       Incident


                                                                  FieldOfficer
                                                   Document
                                                   Incident




Figure 2-38. An example of swimlanes in a UML activity diagram.
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-do‟s, reminders,
         etc. (See Fig 4-42)
                                        IncidentManagement




                                               Report     Emergency




                                                  OpenIncident                                 Dispatcher

   FieldOfficer


                                               AllocateResources

                       IncidentArchive                         SysAdministration




                          ArchiveIncident                            ManageUsers


Librarian                                                                                            SysAdmin
                           SearchArchive                          ManageTerminals



 Figure 2-39. Example of packages: use cases of FRIEND organized by actors (UML use case diagram).
                                              IncidentManagement
   FieldOfficer                                                                                    Dispatcher




                     IncidentArchive                            SysAdministration
Librarian                                                                                                 SysAdmin




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).
       F i e l d S t a t i o n                          D i s p a t c h e r S t a t i o n


      F i e l d O f f i c e r                                D i s p a t c h e r



                        E m e r g e n c y R e p o r t                                 I n c i d e n t




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.
         FieldStation                                            DispatcherStation


       FieldOfficer                                                   Dispatcher

                                                  Th e E mergencyRep ort
                                                             ined in Field Station
                                                  class is def
                                                  e p sed t
                              E m e r g e n c y R and uo r in bo th stations .                 Incident




Figure 2-42. An example of a note. Notes can be attached to a specific element in a diagram.
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, <<string>>, 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 - <<control>>, <<boundary>>,
              <<entity>>
             (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 [].
           <<entity>>                       <<control>>                   <<boundary>>
             Year                                                        l
                                         C h a n g e D a t e C o n t r oB u t t o n B o u n d a r y

           <<entity>>                         <<entity>>                <<boundary>>
             Month                              Day                   LCDDisplayBoundary




Figure 2-43. Examples of stereotypes (UML class diagram).
                                r e p o r t s                      1
            E m e r g e n c y R e p o r t                                    I n c i d e n t
                                 1 . . *
                                         { o r d e r e d     b y   t i m e    o f   r e c e i p t }




Figure 2-44. An example of constraint (UML class diagram).

								
To top