System

modelling &
Design
Software Engineering

1 Presented By Dr. Huda Amin

Information Systems
[email protected]
Software Engineering - H.A.
 A General Model of the Design Process
2

Software Engineering - H.A.

 Design Inputs
3

 Platform Information: Most software interfaces with other software systems. These
include the operating system, database, middleware, and other application systems.
These make up the ‘software platform’, the environment in which the software will
execute. Information about this platform is an essential input to the design process, as
designers must decide how best to integrate it with the software’s environment.

 The requirements specification is a description of the functionality the software must

provide and its performance and dependability requirements.

 Data Description: If the system is to process existing data, then the description of that
data may be included in the platform specification; otherwise, the data description must
be an input to the design process so that the system data organization to be defined.
Software Engineering - H.A.
 Design Process Activities
4

 The activities in the design process vary, depending on the type of

system being developed.
 1. Architectural design, where you identify the overall structure of
the system, the principal components (sometimes called sub-systems
or modules), their relationships, and how they are distributed.
 2. Interface design, where you define the interfaces between
system components. This interface specification must be
unambiguous. With a precise interface, a component can be used
without other components having to know how it is implemented.
Once interface specifications are agreed, the components can be
designed and developed concurrently.
Software Engineering - H.A.
5

 3. Component design, where you take each system component and

design how it will operate. This may be a simple statement of the
expected functionality to be implemented, with the specific design
left to the programmer. Alternatively, it may be a list of changes to
be made to a reusable component or a detailed design model. The
design model may be used to automatically generate an
implementation.
 4. Database design, where you design the system data structures
and how these are to be represented in a database. Again, the
work here depends on whether an existing database is to be reused
or a new database is to be created.
Software Engineering - H.A.
 Design Outputs
6

 The detail and representation of these vary considerably.

 For critical systems, detailed design documents setting out precise
and accurate descriptions of the system must be produced.
 If a model-driven approach is used, these outputs may mostly be
diagrams.
 Where agile methods of development are used, the outputs of the
design process may not be separate specification documents but
may be represented in the code of the program.

Software Engineering - H.A.

 Goal of Design Process
7

 The design must implement all of the explicit requirements

contained in the analysis model, and it must accommodate all
of the implicit requirements desired by the customer.
 The design must be a readable, understandable guide for
those who generate code and for those who test and
subsequently support the software.
 The design should provide a complete picture of the software,
addressing the data, functional, and behavioral domains
from an implementation perspective.
Software Engineering - H.A.
System Modelling

 System modelling is the process of developing abstract

models of a system, with each model presenting a different
view or perspective of that system.

 System modelling has generally come to mean representing

the system using some kind of graphical notation, which is now
almost always based on notations in the Unified modelling
Language (UML).
 When to use
9

 During the requirements engineering process: Models

are used to help derive the requirements for a system.

 During the design process: Models are used to

describe the system to engineers implementing the
system.

 After implementation to document the system’s

structure and operation.
Software Engineering - H.A.
10

 You may develop models of both the existing system and the system to
be developed:
1. Models of the existing system are used during requirements engineering.
They help clarify what the existing system does and can be used as a basis
for discussing its strengths and weaknesses. These then lead to
requirements for the new system.
2. 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.
Software Engineering - H.A.
 System Perspectives
11

 You may develop different models to represent the system from different
perspectives.
 For example:
1. An external perspective, where you model the context or environment of
the system.
2. An interaction perspective where you model the interactions between a
system and its environment or between the components of a system.
3. A structural perspective, where you model the organization of a system or
the structure of the data that is processed by the system.
4. A behavioural perspective, where you model the dynamic behaviour of the
system and how it responds to events.
Software Engineering - H.A.
12

 There are three ways in which graphical models are

commonly used:
 1. As a means of facilitating discussion about an existing
or proposed system. (stimulate the discussion amongst the
software engineers involved in developing the system “agile
modelling”)
2. As a way of documenting an existing system.
3. As a detailed system description that can be used to
generate a system implementation.
Software Engineering - H.A.
 Benefits
13

 Help project teams communicate

 Communication between users, developers, analysts,
testers, managers, and anyone else involved with a
project

 Validate the architectural design of the software

 Be independent of particular programming

languages and development processes
Software Engineering - H.A.
 Context Model
14

 Context models normally show that the environment includes several other
automated systems. However, they do not show the types of relationships
between the systems in the environment and the system that is being specified.
 External systems might produce data for or consume data from the system.
 They might share data with the system, or they might be connected directly,
through a network or not connected at all.
 They might be physically co-located or located in separate buildings.
 All of these relations may affect the requirements and design of the system being
defined and must be taken into account.
 Therefore, simple context models are used along with other models, such as
business process models. These describe human and automated processes in
which particular software systems are used.
Software Engineering - H.A.
 The Context of the MHC-PMS
15

Software Engineering - H.A.

 UML
16

 UML stands for Unified Modeling Language. The Unified modelling Language is a set of more than 9
different diagram types that may be used to model software systems. It emerged from work in the
1990s on object-oriented modelling where similar object-oriented notations were integrated to
create the UML. A major revision (UML 2) was finalized in 2004. The UML is universally accepted as
the standard approach for developing models of software systems. Variants have been proposed
for more general system modelling.
 Business Use Case diagram
 Use Case diagram
 Activity diagram
 Class diagram
 Sequence diagram
 Collaboration diagram
 Statechart diagram
 Component diagram
 Deployment diagram
These model diagrams illustrate different aspects of the system

Software Engineering - H.A.

 Interaction models
17

 All systems involve interaction of some kind. This can be

 User interaction, which involves user inputs and outputs (helps to identify user
requirements)
 Interaction between the system being developed and other systems (highlights
the communication problems that may arise)
 Interaction between the components of the system (helps us understand if a
proposed system structure is likely to deliver the required system performance
and dependability)

 Two related approaches to interaction modelling:

1. Use case modelling, which is mostly used to model interactions between a
system and external actors (users or other systems).
2. Sequence diagrams, which are used to model interactions between system
components, although external agents may also be included.
Software Engineering - H.A.
 Use Case modelling
18

 Use case modelling was originally developed by

Jacobson et al. (1993) in the 1990s and was
incorporated into the first release of the UML
(Rumbaugh et al., 1999).

 Use case modelling is widely used to support

requirements elicitation because it describes what a
user expects from a system.

Software Engineering - H.A.

19

 Each use case represents a discrete task (functionality) that

involves external interaction with a system.

 A use case is shown as an ellipse with the actors involved in

the use case represented as stick figures (user, system, time,
hardware).

Software Engineering - H.A.

 Use Case Diagram
20

 Use cases represent system functionality, the

requirements of the system from the user's perspective
 Use cases just focus on automated processes
 Use case diagrams show the interactions between
 Use cases: what the system should do
 Actors: anyone or anything outside the system’s scope but
interacts with it with the system (Individual, group,
company,…)
Software Engineering - H.A.
 Actors
21

 There are three types of actors:

 Users of the system (Physical person, or a user who will
be directly using the system)
 Other systems that will interact with the system being
built
 Time (Time becomes an actor when the passing of a
certain amount of time triggers some event in the
system (out of control))
Software Engineering - H.A.
 Use Case
22

 The functionality the system will provide a value to the end

user

 They should be named in user terms, not technical terms, and

should be meaningful to the customer

 Use cases are an implementation-independent

 High-level view of what the user expects from the system

 Focus on what the system should do, not how the system will

 Use Case diagrams aren't intended to show in which order the

use cases are executed Software Engineering - H.A.
 Association Relationship
23

 Association relationship is used to show the

relationship between a use case and an actor only

 Every use case must be initiated by an actor, With

the exception of use cases in includes and extends
relationships

Software Engineering - H.A.

24

So, when you have the final list of use cases, how do you know if you've found them all?

- Is each functional requirement in at least one use case? If a requirement is not in a

use case, it will not be implemented.

- Have you considered how each end user will be using the system?

- What information will each end user be providing for the system?

- What information will each end user be receiving from the system?

- Have you considered maintenance issues? Someone will need to start the system and
shut it down.

- Have you identified all of the external systems with which the system will need to
interact?

- What information will each external system be providing to the system and receiving
Software Engineering - H.A.
from the system?
25

 Use case diagrams give a fairly simple overview of

an interaction so you have to provide more detail to
understand what is involved. This detail can either be
 A simple textual description (flow of events)

 A structured description in a table.

 A sequence diagram

Software Engineering - H.A.

 Use Case: Flow of Events
26

 To actually build the system, though, you'll need

more specific details. These details are written as
the flow of events

 The purpose of the flow of events is to document

the flow of logic through the use case

 Although it is detailed, the flow of events is still

implementation-independent
Software Engineering - H.A.
 Flow of Events Pattern
27

 This document will describe in detail what the user of

the system will do and what the system itself will do

 Notice the pattern in the flow of events:

 The user does something, then
 The system does something in response,
 Then the user does something, then the system responds,
and so on
Software Engineering - H.A.
 Use Case: Flow of Events
28

 It includes:

 *A brief description: Each use case should include a short description that explains
what the use case will do

 Preconditions: list any conditions that have to be met before the use case can start
at all. For example, the precondition for one use case may be that another use
case has run

 *Flow of events

 Post conditions: are conditions that must always be true after the use case has
finished executing. Like preconditions, post conditions can be used to add
information about the order in which the use cases are run

Software Engineering - H.A.

 A tabular description of the ‘Transfer data’ use case
29

Software Engineering - H.A.

 Use Case: Flow of Events Types
30

 There are three types of flows:

 Primary flow is the "happy day" scenario, or the most frequently used
path through the use case (Ex: When purchasing a ticket, the primary flow is
a successful ticket purchase)
 Alternate flows are deviations from the primary flow that do not suggest
an error condition (Ex: the requested flight may not be available)
 Error flows are deviations from the primary or alternate flows that suggest
some sort of error condition. Error flows suggest that there is a problem
with the system itself (Ex: the system may be unable to verify the credit
card or the flight availability)

Software Engineering - H.A.

 Use Case: Flow of Events Users
31

• There are three primary users of the flow of events:

1- The customers will be reviewing this document to make sure it
accurately reflects their expectations
2- The system designers will be using it to create the system design
and eventually to build the system
3- The quality assurance team will use the flow of events to create test
scripts

 The flow of events must give them enough information to understand

the sequence of events that needs to occur through the use case
Software Engineering - H.A.
 Relationships
32

 Association the relationship

between a use
 Includes case and an actor
only two types of
only
relationships
 Extends allowed between
use cases
 Generalization
 Between actors

Software Engineering - H.A.

 Include Relationship
33

 Includes relationship allows one use case to use the functionality provided by
another use case
 This relationship can be used in one of two cases:
 First, if two or more use cases have a large piece of functionality that is
identical
 The second case where an includes relationship is helpful is a situation in which a
single use case has an unusually large amount of functionality
 An includes relationship suggests that one use case always uses the functionality
provided by another

<<includes>>

Make Reservation Check Credit

While the “Make Reservation" use case is running, "Check Credit" must run
Software Engineering - H.A.
 Extends Relationship
34

 Extends relationship allows one use case the option to

extend the functionality provided by another use case

 It is very similar to an includes relationship, because in both

of these types of relationships, you separate some common
functionality into its own use case
<<extends>>

Change Reservation Check Credit

 While the "Change Reservation" use case is running, "Check Credit" runs if and only
if the amount of the reservation has changed. If the amount has not changed,
"Check Credit" does not need to run

IMP: The arrow is drawn from the use case that is optionally run ("Check Credit") to
the use case that is being extended ("Change Reservation")
Software Engineering - H.A.
 Abstract Use Case
35

 An abstract use case is one that is not started directly by an

actor
 Instead, an abstract use case provides some additional
functionality that can be used by other use cases
 Abstract use cases are the use cases that participate in an
includes or extends relationship

<<includes>>

Purchase Ticket Check Credit

<<extends>> Abstract
Use Case
Software Engineering - H.A.
Change Reservation
 Relationships: Generalization
36

 Generalization relationship is used to show that several actors

 For example, you may have two types of customers. If the type A
customers will be initiating some use cases that type B customers will not, it's
probably worth including the actor generalizations. If both types of
customers use the same use cases, it's probably not necessary to show an
actor generalization

Software Engineering - H.A.

37

 Sometimes, it is possible to include all possible interactions with a system in

a single composite use case diagram. However, this may be impossible
because of the number of use cases.
 In such cases, you may develop several diagrams, each of which shows
related use cases.
 The figure shows all of the use cases in the MHC-PMS in which the actor
‘Medical Receptionist’ is involved.

Software Engineering - H.A.

38

Software Engineering - H.A.

 Sequence Diagrams
39

 Sequence diagrams in the UML are used to model

the interactions between the actors and the objects
in a system and the interactions between the objects
themselves.

 A sequence diagram shows the sequence of

interactions that take place during a particular use
case or use case instance.
Software Engineering - H.A.
 Interaction Diagrams
40

 Shows, step-by-step, flows through a use case:

 What objects are needed for the flow
 What messages the objects send to each other

 What actor initiates the flow

 What order the messages are sent

Software Engineering - H.A.

 Sequence Diagrams
41

 Sequence diagrams are interaction diagrams ordered by time

 Each diagram represent one of the flows through a use case
 Sequence Diagram users:
 Users can look at these diagrams to see the specifics of their business
processing
 Analysts see the flow of processing in the Sequence diagrams
 Developers see objects that need to be developed and operations for
those objects
 Quality assurance engineers can see the details of the process and
develop test cases based on the processing

Software Engineering - H.A.

42

 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.
 The rectangle on the dotted lines indicates the lifeline of the object
concerned (i.e., the time that object instance is involved in the
computation).
 You read the sequence of interactions from top to bottom. The
annotations on the arrows indicate the calls to the objects, their
parameters, and the return values.

Software Engineering - H.A.

 Interactions involved in the
“View patient information” use case
43

Software Engineering - H.A.

44

 1. The medical receptionist triggers the ViewInfo method in an instance P of

the PatientInfo object class, supplying the patient’s identifier, PID. P is a user
interface object, which is displayed as a form showing patient
information.
 2. The instance P calls the database to return the information required,
supplying the receptionist’s identifier to allow security checking (at this
stage, we do not care where this UID comes from).
 3. The database checks with an authorization system that the user is
authorized for this action.
 4. If authorized, the patient information is returned and a form on the user’s
screen is filled in. If authorization fails, then an error message is returned.
Software Engineering - H.A.
 Alternatives
45

The notation used to denote

alternatives: A box named alt is
used with the conditions indicated
in square brackets.

Software Engineering - H.A.

 Loops
46

Software Engineering - H.A.

 Boundary Class
47

 Boundary classes are

those classes that lie on
the boundary between
your system and the rest
of the world
 These would include all
of your forms, reports,
interfaces to hardware
such as printers or
scanners, and interfaces
to other systems

Software Engineering - H.A.

 Entity Class
48

 Entity classes hold

information that you may
save to persistent storage

 An entity class may need

to be created for a table.
While the table holds a
record's information
permanently, the entity
class will hold the
information in memory
while the system is running

Software Engineering - H.A.

 Control Class
49

 Control classes are responsible for coordinating the

efforts of other classes
 Notice that the control class doesn't carry out any
functionality itself, and other classes don't send many
messages to it. Instead, it sends out a lot of messages.
The control class simply delegates responsibility to the
other classes
 For this reason, control classes are sometimes called
manager classes
 Ex:
 SecurityManager class that is responsible for controlling
events related to security
 TransactionManager class that is responsible for
coordinating messages related to database transactions

Software Engineering - H.A.

 System Sequence Diagram SSD
50

Create System Sequence Diagrams in order

to:
 Identify System events and major operations

Software Engineering - H.A.

 System Sequence Diagram SSD
51

For a use case scenario, an SSD shows:

 The System (as a black box)

 The external actors that interact with System

 The System events that the actors generate

 SSD shows operations of the system in response to

events, in temporal order

Software Engineering - H.A.

 SSD for Process Sale scenario
52

Software Engineering - H.A.

53 Thanks for Listening
Any Questions!

Software Engineering - H.A.