modeling with uml introduction l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
MODELING WITH UML - INTRODUCTION PowerPoint Presentation
Download Presentation
MODELING WITH UML - INTRODUCTION

Loading in 2 Seconds...

play fullscreen
1 / 66

MODELING WITH UML - INTRODUCTION - PowerPoint PPT Presentation


  • 394 Views
  • Uploaded on

MODELING WITH UML - INTRODUCTION. UML

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'MODELING WITH UML - INTRODUCTION' - Leo


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
modeling with uml introduction
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
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)
slide3

ReadTime

SetTime

WatchRepairPerson

ChangeBattery

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.

class diagrams
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)
slide5

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
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)
slide7

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
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)
slide9

Increment

Hours

button2Pressed

button1&2Pressed

Blink

Hours

button1Pressed

Increment

Minutes

button2Pressed

button1&2Pressed

Blink

Minutes

button1Pressed

Increment

Seconds

button2Pressed

Blink

Stop

Seconds

Blinking

Figure 2-4. A UML statechart diagram for SetTime use case of the SimpleWatch.

activity diagrams
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)
slide11

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
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)
slide13

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
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
slide15

UML

1

*

Book

Chapter

composed-of

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.

slide16

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
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)
slide18

A device that

measures time.

Name

Purpose

Members

Clock

Figure 2-9. The three components of the Clock concept: name, purpose, and members.

data types abstraction data types and instances
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
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
slide21

EnterCalcMode()

InputNumber(n)

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.

slide22

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

slide23

<<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
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)
slide25

: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
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)
slide27

Application Domain

Solution Domain

Application Domain Model

System Model

MapDisplay

TrafficControl

SummaryDisplay

FlightPlanDatabase

TrafficController

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
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)
slide29

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

slide33

<<extend>>

OpenIncident

ConnectionDown

<<extend>>

AllocateResources

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

uml diagrams in depth 3
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)
slide35

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
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
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)
slide38

reports

1

Incident

EmergencyReport

1..*

*

reportsGenerated

*

incidentsGenerated

Dispatcher

FieldOfficer

1

1

name:String

name:String

badgeNumber:Integer

badgeNumber:Integer

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

slide39

report_1291

incident_1515

bob:FieldOfficer

name = “Bob D.”

badgeNumber = 132

john:Dispatcher

name = “John D.”

alice:FieldOfficer

badgeNumber = 12

name = “Alice W.”

badgeNumber = 23

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

slide40

Allocates

role:String

notificationTime:Time

FieldOfficer

Incident

name:String

1

resources

badgeNumber:Integer

incident

1..*

Figure 2-24. An example of an association class (UML class diagram).

slide41

Allocation

1

1

role:String

notificationTime:Time

FieldOfficer

incident

1

name:String

Incident

badgeNumber:Integer

1..*

resources

Figure 2-25. Alternative model for Allocation (UML class diagram).

slide42

State

County

Township

PoliceStation

PoliceOfficer

Directory

File

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.

slide43

name:String

badgeNumber:Integer

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.

slide44

Incident

assignResource(r)

close()

Figure 2-28. Examples of operations provided by the Incident class (UML class diagram).

uml diagrams in depth 6
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)
slide46

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

uml diagrams in depth 7
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)
slide49

Active

Inactive

Closed

Archived

incidentHandled

incidentDocumented

incidentArchived

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

slide50

MeasureTime

SetTime

DeadBattery

pressButtonsLAndR

after 2 min.

pressButtonsLAndR/beep

after 20 years

after 20 years

Figure 2-32. Statechart diagram for 2Bwatch set time function.

uml diagrams in depth 8
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)
slide52

Figure 2-33. Internal transitions associated with the SetTime state (UML statechart diagram).

uml diagrams in depth 9
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
slide55

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.

slide56

Open

Allocate

Incident

Resources

Notify

Fire Chief

Notify

Police Chief

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

slide57

Allocate

Resources

Open

Coordinate

Archive

Incident

Resources

Incident

Document

Incident

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

slide58

Dispatcher

Allocate

Resources

Open

Coordinate

Archive

Incident

Resources

Incident

FieldOfficer

Document

Incident

Figure 2-38. An example of swimlanes in a UML activity diagram.

slide59

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)
slide60

IncidentManagement

IncidentArchive

SysAdministration

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

slide61

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

slide62

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.

slide64

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 [].