Lecture 19, 20, 21 & 22

System Modelling
 Topics covered
l Introduction
l Context Model
l Activity Diagram
l Structural Model
l Class Diagram
l Interaction Model
l Use case Diagram
l Sequence Diagram
l Behavioural Model
l State Machine Diagram
l Conclusion
 Introduction
l System modeling is the process of developing abstract models of a system
l Each model presents a different view or perspective of that system
l Each model is represented based on graphical notations using UML(Unified
Model Language)
l Model is used in Requirement Engineering Phase –
• to help derive the requirements for a system
l Model is used in Design Phase –
• to describe the system to engineers implementing the system
l Model is used after Implementation Phase-
• To document the system’s structure and operation
l We may develop models of both
• The existing system –
• What the existing system does
• To discuss the strengths and weaknesses
• These lead to requirements for the new system
• The system to be developed
• To explain the proposed system to other system stakeholders
• Engineers use these models to discuss design proposals and to document the system for
implementation
 Introduction
l Different Model is shown from different perspective
• External Perspective :
• The context or environment of the system is modeled
• Interaction Perspective :
• The interactions between a system and its environment or the components of
the system is modeled
• Structural Perspective :
• The organization of the system or
• The structure of the data that is processed by the system
• Behavioral Perspective :
• The dynamic behavior of the system
• How it responds to events
 Introduction
l Diagrams to document the system model
• Activity Diagram :
• It shows the activities involved in a process or in data processing
• Use Case Diagram :
• It shows the interactions between a system and its environment
• Sequence Diagram :
• It shows the interactions between the actors and the system and between
system components – it emphasizes on when interactions occur
• Collaboration Diagram :
• It shows the interactions between the actors and the system and between
system components – it emphasize on what interactions occur
• Class Diagram :
• It shows the object classes in the system and the associations between these
classes
• State Diagram :
• It shows how the system reacts to internal and external events
 Introduction
l Three ways in which graphical models are
commonly used
• As a means of facilitating discussion about an existing or
proposed system
• As a way documenting an existing system
• As a detailed system description that can be used to
generate a system implementation
 Context Models
l At early stage in specification, we should decide the system
boundaries
l By discussing with the stakeholders, we should decide on
• What functionality should be included in the system
• What is provided by the system’s environment
• What business process should be implemented
• What processes should be manual or supported by different
system
• Look at possible overlaps in functionality with existing system
• Where new functionality should be implemented
l Reasons to decide on system boundaries
• To limit the system costs and the time needed for understanding
the system requirements and design
 Activity Diagram
l Activity Diagrams are intended to show
• The activities that make up system process
• The flow of control from one process or action to another
• The activity diagram cannot be exactly matched with the code
l Purposes of Activity Diagram
• Draw the activity flow of a system.
• Describe the sequence from one action to another.
• Describe the parallel, branched and concurrent flow of the system
 How to draw Activity Diagram?
l Understand about the elements used in activity diagram
• Activities and actions
• Association
• Conditions
• Constraints
l Make a mental layout of the entire flow of actions within activity

l Transform the mental layout into activity diagram

Understand the elements of Make a mental layout Transform the mental layout
activity diagram of entire flow into activity diagram
 Notation of Activity Diagram
Start of a
process
Fork Node
End of a
process

Activities
and Action Join Node

Flow of
work

Decision Marge Node

Node
Notation of Activity Diagram

Local Pre-Condition and

Post-condition

Accept Event Action

Accept Signal Action

Wait Time Action

 Order Management System
l Send order by the customer
l Receipt of the order
l Confirm order
l Dispatch order
 Order Management System
Order Management
Customer Sends Order request system
the order request confirms the receipt
of order

[Not Normal Order]

[Normal Order]

[No Special [Special Confirm the order

Order] Order]

Dispatch the order

Online Shopping
Ticket Vending Machine
Process Shopping Order
Application of Activity Diagram
l Modeling work flow by using activities.
l Modeling business requirements.
l High level understanding of the system's
functionalities.
l Investigate business requirements at a later
stage.
 Structural Model
l Structural model
• It displays the organization of a system in terms of the
components that make up that system and their relationship
l Class Diagram shows
• The classes in a system
• The associations between these classes
l The class diagram describes
• Attributes and operations of a class
• Constraints imposed on the system
Object-Oriented Modeling
 Class and Object
l Object
• An entity that encapsulates data and behavior
l Class
• A set of objects that share the same attributes, operations and
relationships
l Classes describe the type of objects, while objects are
usable instances of classes
l A Class is a blueprint for an object
l An object is an instance of a class and object - Objects
have states and behaviors
Example of Class and Object
 Building Class Diagram
l In Object Oriented System Analysis and Design
1. Identification of classes or things of system, which is done by
• Looking at the problem domain
• Identifying the essential objects
• Representing these as classes
2. Modeling the system domain using
• These things or classes
• Relationship between these classes
 Finding Objects
l We often think of objects in code as mapping to some
object we want to represent in the real world. Although
this isn't always the case.
l Here are some categories of objects to look for:
• Entity objects -- these represent persistent information tracked by a
system. This is the closest parallel to "real world" objects.
• Boundary objects -- these represent interactions between user and
system. (For instance, a button, a form, a display)
• Control objects -- usually set up to manage a given usage of the
system. Often represent the control of some activity performed by a
system
l There are some different popular techniques for
identifying objects.
• Natural language analysis (i.e. parts of speech)
• CRC cards
 Natural Language Analysis
l Pioneered by Russell Abbott (1983), popularized by
Grady Booch
l This can be done from a general problem description, or
better, from a use case or scenario
l Map parts of speech to object model components.
• nouns usually map to classes, objects, or attributes
• verbs usually map to operations or associations
 Finding Entity Objects
l Some things to look for. These may be candidates for objects, or they may
help identify objects:
• Terms that are domain-specific in use cases
• Recurring nouns
• Real-world entities and activities tracked by system
l Use good naming conventions. Good to use names from the application
domain -- they understand their own terminology best
l Example: In a Report Emergency use case -- "A field officer submits
information to the system by filling out a form and pressing the 'Send
Report' button"
• Field Officer is a real world entity that interacts with the system
• This is also likely an actor from the use case
• As an actor, Field Officer is an external entity
• But we see that the field officer submits information -- here's data to be
tracked
• We'll create the entity object type Emergency Report, as that's the more
common name for the information the officer submits (according to client)
 Finding Boundary Objects
l Identify general user interface controls that
initiate a use case
• Note: Don't bother with the visual details here. This will evolve
later
l Identify forms or windows for entering data into
a system
l Identify messages used by system to respond to
a user
 Finding Control Objects
l Control objects can help manage
communication and interaction of other objects
l If a use case is complex and involves many
objects, create a control object to manage the
use case
l Identify one control object per actor involved in a
use case
l Life span of control object should last through
the use case
 Steps of Class Identification
l Steps for Identification of classes (Things)
1. Identify all nouns and noun phrases using use cases, actors and other information
about the system –including inputs and outputs
2. Add items or categories of information needed using current procedures, reports
and forms of the system
3. As the list of nouns build, refine it
• Asking questions to decide whether the nouns should be included
 Is it unique thing the system needs to know about? If yes- include it
 Is it inside the scope of system I am working on? if yes – include it
 Does the system need to remember more than one of these items? If yes – include
it
 Is it really synonyms of some other thing I have identified? If so – exclude it
 Is it really just an output of the system produced from other information I have
identified? If so – exclude it
 Is it really an input that results in rearranging some other information I have
identified? if so – exclude it
4. Create a master list of all nouns identified and then note whether it should be
included, excluded or research furthered
5. Review the lists with users and stakeholders and team members and define the
list of things or classes in problem domain
 Building Class
l Identifying Attributes of classes
• Describes one piece of information about each instance of the
class
• Example: Customer has first name, last name and phone
number
l Identify key or identifier
• One attribute uniquely identifies an instance of the class
• It is optional for class diagram
l Compound Attribute
• Two or more attributes combined into one structure to simplify
the model - address
l Attributes vs. values
• Class is a type of thing
• Object is a specific instance of a class
• Each instance has its own values for an attribute
 Instances

Attributes Each customer has a value for each attribute

Customer ID 101 102 103
First Name Jhon Dagny Henry
Last Name Galt Taggarat Reardon
Home Phone 555-213 423-454 874-1297
Work Phone 555-242 423-676 874-1234
 UML Notation of Class Diagram
l A class represent a concept which encapsulates
state (attributes) and behavior (operations)
• Each attribute has a type
• Each operation has a signature
l Class Diagram
• A UML diagram that shows classes with attributes, methods
and associations
l Notation of Class
• The name of the object class is in the top section
• The class attributes are in the middle section
• The operations associated with the object class are in the lower
section of the rectangle

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
l UML diagrams can include a label known as
a stereotype, above the class name in a class diagram.
l This would be placed inside << >> marks, like this:
• <<entity>>
• <<boundary>>
• <<control>>
 UML Notation of Class Diagram
l Class Visibility
• + denotes public attributes or operations
• - denotes private attributes or operations
• # denotes protected attributes or operations

l Static Data Member PrototypeDemo

• Underline can be used for static data member

+main():void

l Abstract Class and Method Computer

• Without definition +getRAM():String

• Both should be in Italic +getHDD():String
+getCPU():String

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
l Parameter Directionality
• Each parameter in an operation (method) may be
denoted as in, out or inout which specifies its direction
with respect to the caller

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
l Perspectives of Class Diagram
• Conceptual: represents the concepts in the domain
• Specification: focus is on the interfaces of Abstract Data
Type (ADTs) in the software
• Implementation: describes how classes will implement
their interfaces

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
l Relationships between classes
• A class may be involved in one or more relationships with
other classes

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
l Association
• A naturally occurring relationship between classes ( UML term)
• Associations are relationships between classes in a UML Class
Diagram
• They are represented by a solid line between classes in UML.
• Associations are typically named using a verb or verb phrase
which reflects the real world problem domain

Accounting
Order # 123 “is placed by” “Works in ”
Dept.

“Mr. Smith”

“Contains” “Contains”

Jeans Shirt

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
l Simple Association (Bidirectional Association)
l A structural link between two peer classes.
l One class uses another class
l There is an association between Class1 and Class2
l There is an association that connects the <<control>>
class Class1 and <<boundary>> class Class2
l The relationship is displayed as a solid line connecting the
two classes.

LogInControl LogInPage

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
Directed Association (Unidirectional Association)
l refers to a directional relationship represented by a line
with an arrowhead
l The arrowhead depicts a container-contained directional
flow

Notification Member
Sentto

https://creately.com/blog/diagrams/class-diagram-relationships/
 UML Notation of Class Diagram
Dependency :
l A special type of association.
l Exists between two classes if changes to the
definition of one may cause changes to the other
(but not the other way around).
l Class1 depends on Class2
l The relationship is displayed as a dashed line with
an open arrow.
l The Person class might have a hasRead method
with a Book parameter that returns true if the
person has read the book (perhaps by checking
CourseSchedule Course
some database).
+add(): void
+remove() : void

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
Reflexive Association :
l This occurs when a class may have multiple
functions or responsibilities.
l For example, a staff member working in an airport
may be a pilot, aviation engineer, a ticket
dispatcher, a guard, or a maintenance crew
member. If the maintenance crew member is
managed by the aviation engineer there could be a
managed by relationship in two instances of the
same class.

https://creately.com/blog/diagrams/class-diagram-relationships/
 UML Notation of Class Diagram
l Multiplicity is term for the number of associations
between classes
• 1 to 1
• 1 to many
• Many to 1
• Many to many
• It is placed on the opposite end of the
association line

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
UML Notation of Class Diagram
Customer Account Branch
ID ID ID
Name 1..* AccType Name
Phone 1 Balance 0..* 1 Phone
add() add() add()
delete() delete() delete()
Update() Update() Update()
1
1..*
Transaction
ID
Type
Amount
add()
delete()
Update()
 UML Notation of Class Diagram
l Inheritance or Generalization
• A generalization is a taxonomic relationship between a
more general classifier and a more specific classifier
• Each instance of the specific classifier is also an indirect
instance of the general classifier
• the specific classifier inherits the features of the more
general classifier.
• Represents an "is-a" relationship.
• An abstract class name is shown in italics.
• SubClass1 and SubClass2 are specializations of
SuperClass.
• The relationship is displayed as a solid line with a hollow
arrowhead that points from the child element to the parent
element.

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
l Aggregation (Hollow Diamond)
• It represents a "part of" relationship
• Object of one class has object of another
• Second is a part of first
• Class2 is part of Class1
• Many instances (denoted by the *) of Class2 can be
associated with Class1
• Objects of Class1 and Class2 have separate lifetimes
• The relationship is displayed as a solid line with a unfilled
diamond at the association end, which is connected to the
class that represents the aggregate
Head Light
Car
Engine
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
l Composition (Filled Diamond)
• A special type of aggregation where parts are destroyed
when the whole is destroyed. Scroll Bar
• That is, the contained class will be obliterated when the
container
Window class is destroyed
• Title Bar
Objects of Class2 live and die with Class1.
• Class2 cannot stand by itself.
• Menu
The relationship is displayed as a solid line Bar
with a filled
diamond at the association end, which is connected to the
class that represents the whole or composite.

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 UML Notation of Class Diagram
l Realization
• Realization is a relationship between the blueprint class
and the object containing its respective implementation
level details.
• This object is said to realize the blueprint class.
• In other words, you can understand this as the
relationship between the interface and the implementing
class.
• For example, the Owner interface might specify methods
for acquiring property and disposing of property. The
Person and Corporation classes need to implement these
methods, possibly in very different ways.

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 Case Study
Use Case Scenario:
1. Customer verifies items in shopping cart.
2. Customer provides payment and address to process sales
3. System validates payment and responds by confirming order and
provides order number that customer can use to check an order status
4. System will send customer a copy of order details by email
 Case Study
Use Case Scenario:
1. Customer verifies items in shopping cart.
2. Customer provides payment and address to process sales
3. System validates payment and responds by confirming order and
provides order number that customer can use to check an order status
4. System will send customer a copy of order details by email

Noun List:
1. Customer 7. System
2. items 8. order
3. shopping cart 9. order number
4. payment 10. order status
5. Address 11. order details
6. sales 12. email
 Case Study
Use Case Scenario:
1. Customer verifies items in shopping cart.
2. Customer provides payment and address to process sales
3. System validates payment and responds by confirming order and
provides order number that customer can use to check an order status
4. System will send customer a copy of order details by email

Noun List:
1. Customer 7. System
2. Items 8. order
3. Shopping cart 9. order number
4. Payment 10. order status
5. Address 11. order details
6. sales 12. Email
 Case Study
l Conceptual Class Diagram

Uses Contains
Customer Shopping Cart Items
1 *
Places

Payment Paid by Order Email

Address
 Case Study
Use Case Scenario:
1. Customer verifies items in shopping cart.
2. Customer provides payment and address to process sales
3. System validates payment and responds by confirming order and
provides order number that customer can use to check an order status
4. System will send customer a copy of order details by email

Verb List:
1. Verify Item 5. Confirm Order
2. Provide Payment and address 6. Provide Order Number
3. Process Sales 7. Check an order status
4. Validate Payment 8. Send order details email
 1. Verify Item
2. Provide Payment and

Case Study 3.
address
Process Sale
4. Validate Payment
5. Confirm Order
6. Provide Order Number
7. Check an order status
8. Send order details email

Uses Contains
Customer Shopping Cart Item
1 *
Places
Display Totals

Payment Paid by Order Email

Set Payment Details Process Order Send Email
Validate Payment Confirm Order
Get Order Number
Address Get Order Status
Create Order Confirmation email

Set Address Details

 Class Diagram Example: Order
System

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 Class Diagram Example: GUI

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/
 Interaction Model
l Types of interaction
• User interaction: it involves user inputs and outputs
• Interaction between the system being developed and
other systems
• Interaction between the components of the system
l Modeling User Interaction
• Helps to identify user requirements
l Modeling System to System interaction
• Highlights the communication problems that may arise
l Modeling component interaction
• Helps us understand if a proposed system structure is
likely to deliver the required system performance and
dependability
 Interaction Model
l Approaches of interaction modeling
• Use Case Modeling
• To model interactions between a system and external
actors (users or other systems)
• Sequence Diagram
• To model interactions between system components
• It may include external agents
 Use Case Modeling
l It is developed by Jcobson et al. 1993
l Use Case :
• A simple scenario that describes what a user expects
from system
l Each Use Case represents a discrete task that
involves external interaction with a system

Transfer
Data

Medical Patient Record

Receptionist System
 Sequence Diagram
l It shows the sequence of interactions that
take place during a particular use case
l It describes the flow of messages, events
and actions between objects
l It is used to model
• The interactions between actors and the objects
in a system
• The interactions between the objects
themselves
Notation of Sequence Diagram
l Actors are represented as stick figure
l Objects are represented as a square
• With object type, optionally preceded by name
l Both are placed at the top of the diagram and a dotted line is
drawn from these
l Interactions between objects are indicated by annotated
arrows with message
• It consists message name and arguments
• Dashed arrow back indicates return
l The rectangle on the dotted lines indicates the ‘lifeline’ of the
object
Notation of Sequence Diagram
Actor object

:System

Life line
addItem (itemId, quantity)
description, price

Activation
Box
 Notation of Sequence Diagram
l Loop frame is represented using a rectangle, where test condition for
repetition is written in left corner

Actor object
Test Condition
for Repetition :System

Loop for all items

addItem (itemId, quantity)
description, price
 Notation of Sequence Diagram
l “If“ or opt frame is also represented using a rectangle, where “opt” is
written in left corner
• Brackets [] is used for true/false condition
• If it evaluates to true, then the message is sent
• Otherwise not

Actor object

:System

Opt
[item selected ] addItem (itemId, quantity)

Item detailed
 Notation of Sequence Diagram
l Alt Frame (If-Else)
• Alt is written in the left corner of the rectangle
• Brackets [] is used for true/false condition
• If it evaluates to true, then the message is sent
• Otherwise the message of “else” is sent

:System

Alt
[Taxable item] addTax(location code)

Sales Tax

[Else] addTaxExempt(code)
Tax exempted detail
 Steps of Sequence Diagram
1. Identify input message
-See use case flow of activity or activity diagram
2. Describe the message from the external actor to the system
using the message notation
-Name it verb-noun : what the system asked to do
-Consider parameters the system will need
3. Identify any special conditions on input
- Iteration/loop frame
-Opt or alt frame
4. Identify and add output return values
- An explicit return on separate dashed line
 View Information
Medical Receptionist
P:Patientinfo D:MHCPMS-DB AS: Authorization

ViewInfo(PID)
Report (Info,PID,UID)
Authorize(Info,UID)

Authorization

Alt

[Authorization Patient Info

ok]

[Authorization
Fail]
Error No Access
 Transfer Data
Medical Receptionist PRS
P:Patientinfo D:MHCPMS-DB AS: Authorization
Login()
OK

Alt
[SendInfo]
UpdateInfo() Update PRS (UID) Authorize(TF,UID)
Authorization Update (PID)
Update Ok
Message (Ok)

[SendSummery]
UpdateSummery()
Summarize (UID) Authorize(TF,UID)
Authorization
:Summery
Update(PID)
Message (Ok) Update Ok

Logout()
 Behavioral Model
l Behavioral models are models of the dynamic
behavior of the system as it is executing
l They show what happens or what is supposed to
happen when a system responds to a stimulus from
its environment
l Two types
• Data-Driven Modeling
• It shows the sequence of actions involved in processing input data
and generating an associated output
• DFD
• Event-Driven Modeling
• It shows how a system responds to external and internal events
• It is based on the assumption that a system has a finite number of
states and that events may cause a transition from one state to
other
• State-Machine Diagram
 State Machine Diagram
l The UML diagram
• It describe the behavior of one object over several use
cases in the system
• It shows the life of an object in states and transitions
• It is described for a class
• Each object has it’s own state machine
l States
• A condition during an objects life when it
• Satisfies some criterion
• Performs some action and
• Waits for an event
l Action
• It is an executable atomic computation
• It includes operation calls, the creation or destruction of
another object or sending of a signal to an object
 State Machine Diagram
l A state is represented by a rounded rectangle that contains the state
name
l Event
• It is described as Event-Name(comma- separated- parameter list )
• Events appear in the internal transition of a state or on a transition
between states

State Name
Action performed on entry to State
At work
Action performed while in State
Entry/Unlock Door
Do/Prepare Materials Action performed while arrival of named event
Telephone ring / answer
Include/Lecture State Name of sub-state machine
Exit/ Lock Door
Action performed on leaving State
 State Machine Diagram
l Start / Pseudo state State
• The starting point of a state machine diagram
• It is represented by a solid circle
l Final State
• A final state is reached when the object's lifetime is over
• It is represented by a solid circle surrounded by an open circle
l Original / source state
• The original state of an object before transition
l Destination state
• The state to which the object moves after the transition
l Guard Condition
• A true false test to see whether a transition can fire
 State Machine Diagram
l Action Expression
• A description of activities performed as a part of transition
l Transition
• The movement of object from one state to other state
• A transition string is described as
• Event-signature [guard condition] action expression
l States are connected together by transitions that
point from a source state to a destination state
• The behavior that causes the state change, such as an
event, conditions, or time, if there is any, is described
near the arrow
• A transition with no events, conditions, or time limits, is
performed automatically upon completion of the state's
activities
State Machine Diagram

go to home
At work At Home
go to work

die die
 State Machine Diagram

Invoice Invoice
created Unpaid paying Paid destroyed
 State Machine Diagram

Off onButtonPush [cover closed]/self test On

offButtonPushed
 State Machine Diagram
l Steps for developing State Machine Diagram
• Review the class diagram and select classes that might require machine
diagrams
• For each class, make a list of status conditions (states) you can identify
• Identify transitions that cause an object to leave the identified state
• Sequence these states in the correct order
• Review paths and look for independent, concurrent paths
• Look for additional transitions and test for both directions
• Expand each transition with appropriate message event, guard condition
and action expression
• Review and test the state machine diagram for the class
• Make sure state are the really state for the object in the class
• Follow the lifecycle of an object coming into existence and being deleted
• Be sure diagram covers all exception condition
• Look again for concurrent paths and composite states
State Machine Diagram

BookCopy
Accession_No
Title OnSelf:=‘Y’ on the self
OnSelf : Boolean
OnSelf:=‘N’ on loan
Type

return() action / onSelf=‘Y’

borrow() action / onSelf=‘N’

 State Machine Diagram

object is myBkCpy

On Loan return() On the Self

entry/myBkCpy.borrow() entry/myBkCpy.return()
borrow()
exit/myBkCpy.return() exit/myBkCpy.borrow()
 State Machine Diagram
Full Power Full Power
Do/Set Power=600
Operation
Do/Operate Oven
Timer
Full Number
Power
Waiting Start
Do/Display Time
Set Time Open
Do/Get Number Door Cancel
Exit : Set Time
Half Door
Timer Closed Enable
Power Open
Half Do/Display ‘Ready’
Power Door
Door
Closed
Half Power
Do/Set Power=300 Disabled
Do/Display ‘Waiting’
Waiting
Do/Display Time
 Conclusion
l Context Model
l Activity Diagram
l Structural Model
l Class Diagram
l Interaction Model
l Use case Diagram
l Sequence Diagram
l Behavioural Model
l State Machine Diagram