1. EKT 421 SOFTWARE ENGINEERING
System Modelling
Part I
Dr. Nik Adilah Hanin Zahri

2. Today’s Topics
Context models
Process models
Interaction models

3. System Modeling System modeling is the process of
developing abstract models of a system
each model presenting a different view or perspective of that system
Using graphical notation e.g. notations in the Unified Modeling Language (UML)
Objective:
To helps the analyst to understand the functionality of the system
To act as communication models between developer and customers

4. Existing System Models
Models of the existing system are used during requirements engineering for the following objectives:
To help clarify what the existing system does
Also used as a basis for discussing its strengths and weaknesses
These then lead to requirements for the new system

5. Planned System Models
Models of the new system are used during requirements engineering
to help explain the proposed requirements to other system stakeholders
engineers use these models to discuss design proposals and to document the system for implementation
In a model-driven engineering process, it is possible to generate a complete or partial system implementation from the system model

6. System Perspectives
An external perspective, where you model the context or environment of the system.
An interaction perspective, where you model the interactions between a system and its environment, or between the components of a system.
A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system.
A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events.

7. Use of Graphical Models
Purpose:
To facilitating discussion about an existing or proposed system
As a way of documenting an existing system
Types of graphical models
Context models e.g. context diagram
Process models e.g. activity diagram
Interaction models e.g. Use case diagram and sequence diagram
Structural models e.g. class diagram
Behavioral models e.g. state diagram

8. 1. Context Models

9. Context Models
Context models are used to illustrate the operational context of a system - what lies outside the system boundaries
System boundaries are established to define what is inside and what is outside the system
They show other systems that are used or depend on the system being developed
The position of the system boundary has a profound effect on the system requirements
Defining a system boundary is a political judgment
There may be pressures to develop system boundaries that increase / decrease the influence or workload of different parts of an organization
UML system context diagram may be used for context modelling

10. System Context Diagram of MHC-PMS

11. 2. Process Models

12. Process Perspective
Context models simply show the other systems in the environment
not how the system being developed is used in that environment
Process models reveal how the system being developed is used in broader business processes
UML activity diagrams may be used to define business process models

13. Process Model Using Activity Diagram
Figure : Process model of purchase order using activity diagram

14. Activity Diagram
Activity diagram is a UML diagram used to describe dynamic aspects of the system.
Activity diagram is basically a flow chart to represent the flow form one activity to another activity also can be described as an operation of the system.
The purposes of activity diagram can be described as:
To draw the activity flow of a system
To describe the sequence from one activity to another
To describe the parallel, branched and concurrent flow of the system

15. Drawing An Activity Diagram
The main element of an activity diagram is the activity itself performed by the system.
After identifying the activities we need to understand how they are associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements:
Activities
Association
Conditions
Constraints

16. Labels/Symbols/Notation
Initial node - The filled in circle is the starting point of the diagram. 
Activity final node - The filled circle with a border is the ending point.  An activity diagram can have zero or more activity final nodes.
Activity/Action - The rounded rectangles represent activities that occur. An activity may be physical, such as Receive Request.
Flow/edge -  The arrows represent the flow of activities in the diagram. 

17. Labels/Symbols/Notation
Fork -  A black bar with one flow going into it and several leaving it.  This denotes the beginning of parallel activity
Join - A black bar with several flows entering it and one leaving it.  All flows going into the join must reach it before processing may continue.  This denotes the end of parallel processing.

18. Labels/Symbols/Notation
Condition - Text such as [Correct] on a flow, defining a guard which must evaluate to true in order to traverse the node.
Decision - A diamond with one flow entering and several leaving.
Merge - A diamond with several flows entering and one leaving.  The implication is that one or more incoming flows must reach this point until processing continues, based on any guards on the outgoing flow.
[Correct]

19. Labels/Symbols/Notation
Partition. Partitions also called swimlanes, indicating who/what is performing the activities.
Sub-activity indicator.  The rake in the bottom corner of an activity indicates that the activity is described by a more finely detailed activity diagram. 
Flow final.  The circle with the X through it.  This indicates that the process stops at this point. 

20. Example of Activity Diagram
Figure : Activity diagram to authenticate PIN number

21. Example of Activity Diagram with Swimlanes
CONDITIONS
INITIAL NODE
END NODE
ACTIVITY
PARTITION
FORK
JOIN

22. More Labels/Symbols
Activity edge is notated by an open arrowhead line connecting two activity nodes.
Eg: Activity edge connects Fill Order and Review Order
Edges can be named, however, edges are not required to have unique names within an activity
If the edge has a name, it is notated near the arrow.

23. More Labels/Symbols
Activity edge can have a guard - specification evaluated at runtime to determine if the edge can be traversed.
The guard of the activity edge is shown in square brackets that contain the guard.
Fill Order when priority is 1

24. More Labels/Symbols
Connectors are generally used to avoid drawing a long edge. This is purely notational. It does not affect the underlying model.
Connector A connects two edges between Fill Order and Review Order.

25. More Labels/Symbols
Object flow edges are activity edges used to show data flow of object and data tokens between action nodes.
Object is represent by a rectangle shape
An object flow is notated by an arrowed line.
Object flow of Orders between Fill Order and Review Order actions

26. Exercise
Create an activity diagram of drawing money using an ATM machine. Your diagram should include interaction between customer, ATM machine and the bank. The activities should include
authentication of the card based on entered pin numbered
Drawing money
Checking account balance
(Hint: use swimlanes to indicates activities by different parties)

27. 2. Interaction Models Use Case Diagram

28. Interaction Models
Modeling user interaction is important as it helps to identify user requirements
Modeling system-to-system interaction highlights the communication problems that may arise
Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability
Use case diagrams and sequence diagrams may be used for interaction modelling

29. Use Case Modeling Use case diagrams is used to:
visualize, specify, construct, and document the (intended) behavior of the system, during software specification and analysis
provide a way for developers, domain experts and end-users to Communicate
serve as basis for testing
Each use case represents a discrete task that involves external interaction with a system
Represented diagrammatically to provide an overview of the use case and in a more detailed textual form
Use case diagrams contain use cases, actors, and their relationships

30. Example : Transfer-data Use Case
A use case in the MHC-PMS

31. Tabular Description of Use Case
MHC-PMS: Transfer data
Actors
Medical receptionist, patient records system (PRS)
Description
A receptionist may transfer data from the MHC-PMS to a general patient record database that is maintained by a health authority.
The information transferred may either be updated personal information (address, phone number, etc.) or a summary of the patient’s diagnosis and treatment.
Data
Patient’s personal information, treatment summary
Stimulus
User command issued by medical receptionist
Response
Confirmation that PRS has been updated
Comments
The receptionist must have appropriate security permissions to access the patient information and the PRS.

32. Role of ‘Medical Receptionist’ in MHC-PMS

33. Drawing Use Case Diagram
Use cases specify desired behavior or functional requirements of a system
A use case is a description of a set of sequences of actions including variants, a system performs to yield an observable result of value to an actor
System behavior

34. How to name a Use Case? Use Case names begin with a strong verb
Name Use Cases using domain terminology
Place the primary Use Cases in the top-left corner of the diagram
Imply timing considerations by stacking use case 

35. Relationships between Use Cases
Generalization
use cases that are specialized versions of other use cases
Include
use cases that are included as parts of other use cases
Extend
use cases that extend the behavior of other core use cases

36. 1. Generalization
The child use case inherits the behavior and meaning of the parent use case
The child may add to or override the behavior of its parent
parent
child

37. Example of Generalization
Register Course
Register course for repeated student
Register course for new student

38. <<include>>
The base use case explicitly incorporates the behavior of another use case at a location specified in the base
The included use case never stands alone
only occurs as a part of some larger base that includes it
base
included
<<include>>

39. More about Include
use to avoid describing the same flow of events several times by putting the common behavior in a use case of its own
updating
grades
output
generating
verifying
student id
<<include>>

40. <<extend>>
The base use case implicitly incorporates the behavior of another use case at certain points called extension points
The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case
base
extending
<<extend>>

41. More about Extend
use to model optional behavior or branching under conditions
Request exam copy
Appeal
Exam grade
<<extend>>

42. Actors
An actor represents a set of roles that users of use case play when interacting with these use cases
Actors can be human or automated systems
Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions
Actors are not part of the system
name

43. Use Cases and Actors
From the perspective of a given actor, a use case does something that is of value to the actor
E.g. calculate a result or change the state of an object
The Actors define the environments in which the system lives

44. Relationships between Actors
Generalization
student
graduate
student
non-graduate
student

45. Relationships between Use Cases and Actors
Actors may be connected to use cases by associations indicating that the actor and the use case communicate with one another using messages
update
grades
faculty

46. Type of Relations Between Use Case and Actor
Associations
student
registration
updating
grades
output
generating
faculty

47. Type of Relations Between Use Case and Actor
2. Directed Associations
The directionality of the arrow shows if the relations is navigable or not
If true for only one role, an arrow appears in the navigable direction

48. Example of Complete Use Case Diagram
Notes1 : Solid arrows/pointers indicates association or directed association
Notes2 : Dotted arrows/pointers indicates <<include>> and <<extend>>

49. Exercise
Create a use case diagram to describe behavior of an ATM machine. Your diagram should include interaction between bank customer, ATM technician and the bank. Includes all possible actions between all actors.

50. 2. Interaction Models Sequence Diagram

51. Sequence Diagrams
Sequence diagrams are used to model the interactions between the actors and the objects within a system
A sequence diagram shows the sequence of interactions that take place during a particular use case
Emphasizes time ordering of messages
Can model simple sequential flow, branching, iteration, recursion and concurrency
Used during requirements analysis
To refine use case descriptions
to find additional objects (“participating objects”)
Used during system design
to refine subsystem interfaces

52. Sequence Diagram for View Patient Information
The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these
Interactions between objects are indicated by annotated arrows

53. Sequence Diagram for Transfer Data

54. Drawing Sequence Diagrams
The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these
Interactions between objects are indicated by annotated arrows
Notations:
Actors are represented by human symbol
Objects are represented by rectangles
Classes are represented by columns
Messages are represented by arrows
Activations are represented by narrow rectangles
Lifelines are represented by dashed lines
selectZone()
pickupChange()
pickUpTicket()
insertCoins()
Passenger
TicketMachine

55. Nested Messages
Passenger
Tarif Schedule
Display
Zone Selection F.
selectZone()
lookupPrice(selection)
price
displayPrice(price)
Dataflow
The source of an arrow indicates the activation which sent the message
An activation is as long as all nested activations
Horizontal dashed arrows indicate data flow
Vertical dashed lines indicate lifelines

56. Iteration & Condition
Passenger
ChangeProcessor
insertChange(coin)
CoinIdentifier
Display
CoinDrop
displayPrice ( billed Amount)
lookupCoin(coin)
price
[billed Amount<0] returnChange(-billedAmount)
Iteration *
Condition
Iteration is denoted by a * preceding the message name
Condition is denoted by boolean expression in [ ] before the message name

57. Creation and Destruction
Passenger
ChangeProcessor
Ticket
createTicket(selection)
free()
Creation
Destruction
print()
Creation is denoted by a message arrow pointing to the object.
Destruction is denoted by an X mark at the end of the destruction activation.
In garbage collection environments, destruction can be used to denote the end of the useful life of an object.

58. Example of Complete Sequence Diagram

59. Exercise
Create a sequence diagram for ATM money withdrawal to model the flow and interaction between object and actors. The interaction must begin with card authentication until successful money withdrawal. Your diagram should include interaction between bank customer, ATM machine and the bank database. Includes all possible class, message and activation in all interactions.

60. Q & A