EKT 421 SOFTWARE ENGINEERING System Modelling Part I

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 2

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 3

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 4

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 5

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

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 1. Context models e. g. context diagram 2. Process models e. g. activity diagram 3. Interaction models e. g. Use case diagram and sequence diagram 4. Structural models e. g. class diagram 5. Behavioral models e. g. state diagram 7

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 10

System Context Diagram of MHC-PMS 11

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 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. [Correct] • 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. 19

Labels/Symbols/Notation • 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 PARTITION INITIAL NODE FORK ACTIVITY CONDITIONS JOIN END NODE 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)

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 32

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 33

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

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

Role of ‘Medical Receptionist’ in MHC-PMS 36

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 37

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 38

Relationships between Use Cases 1. Generalization • use cases that are specialized versions of other use cases 2. Include • use cases that are included as parts of other use cases 3. Extend • use cases that extend the behavior of other core use cases 39

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

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

2. 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 <<include>> included 42

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 <<include>> verifying student id output generating <<include>> 43

3. 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 <<extend>> extending 44

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

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 46

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 47

Relationships between Actors • Generalization student graduate student non-graduate student 48

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 49

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

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 51

Example of Complete Use Case Diagram Notes 1 : Solid arrows/pointers indicates association or directed association Notes 2 : Dotted arrows/pointers indicates <<include>> and <<extend>> 52

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 55

Sequence Diagram for View Patient Information 56

Sequence Diagram for Transfer Data 57

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 Passenger Ticket. Machine select. Zone() insert. Coins() pickup. Change() pick. Up. Ticket()

Nested Messages Zone Selection F. Passenger select. Zone() Tarif Schedule Display lookup. Price(selection) price display. Price(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 * Change. Processor insert. Change(coin) Coin. Identifier Display Coin. Drop lookup. Coin(coin) price Iteration display. Price ( billed Amount) [billed Amount<0] return. Change(-billed. Amount) 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 Change. Processor Creation create. Ticket(selection) Ticket print() free() Destruction • 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