EKT 421 SOFTWARE ENGINEERING System Modelling Part I Dr. Nik Adilah Hanin Zahri adilahhanin@unimap.edu.my

Today’s Topics Context models Process models Interaction models

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

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

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

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.

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

1. Context Models

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

System Context Diagram of MHC-PMS

2. Process Models

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

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

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

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

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. 

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.

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]

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. 

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

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

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.

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

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.

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

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)

2. Interaction Models Use Case Diagram

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

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

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

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.

Role of ‘Medical Receptionist’ in MHC-PMS

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

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 

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

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

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

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

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

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

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

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

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

Relationships between Actors Generalization student graduate student non-graduate student

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

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

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

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

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.

2. Interaction Models Sequence Diagram

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

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

Sequence Diagram for Transfer Data

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

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

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

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.

Example of Complete Sequence Diagram

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.

Q & A