Software Engineering [19SCS44]

Module 2

SYSTEM MODELS, DESIGN AND

IMPLEMENTATION
SYSTEM MODELS
 System modeling is the process of developing abstract models of a system, with each
model presenting a different view or perspective of that system.
 System modeling 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 Modeling Language (UML).
 Models are used during the requirements engineering process to help derive the
requirements for a system, during the design process to describe the system to
engineers implementing the system and after implementation to document the
system’s structure and operation.

2.1 Context Models

 At an early stage in the specification of a system, it is necessary to decide on the
system boundaries.
 This involves working with system stakeholders to decide what functionality should
be included in the system and what is provided by the system’s environment.
 A decision might be taken about a automated support for some business processes
should be implemented but others should be manual processes or supported by
different systems.
 Possible overlaps must also be noted in functionality with existing systems and decide
where new functionality should be implemented.
 These decisions should be made early in the process to limit the system costs and the
time needed for understanding the system requirements and design.
 Fig 2.1 is a simple context model that shows the patient information system and the
other systems in its environment.
 From fig 2.1, it is seen that the MHC-PMS is connected to an appointments system
and a more general patient record system with which it shares data.
 The system is also connected to systems for management reporting and hospital bed
allocation and a statistics system that collects information for research.
Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 1
 Software Engineering [19SCS44]

 Finally, it makes use of a prescription system to generate prescriptions for patients’

Medication.

Fig 2.1: The context of the MHC-PMS

 Fig 2.2 is a model of an important system process that shows the processes in which
the MHC-PMS is used.
 Fig 2.2 is a UML activity diagram.
 Activity diagrams are intended to show the activities that make up a system process
and the flow of control from one activity to another.
 The start of a process is indicated by a filled circle; the end by a filled circle inside
another circle.
 Rectangles with round corners represent activities, that is, the specific sub-processes
that must be carried out.
 Objects can be included in activity charts.

Fig 2.2: Process model of involuntary detention

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

 In fig 2.2, it can be seen that guards showing the flows for patients who are dangerous
and not dangerous to society.
 Patients who are dangerous to society must be detained in a secure facility. However,
patients who are suicidal and so are a danger to themselves may be detained in an
appropriate ward in a hospital.

2.2 Interaction Models

 All systems involve interaction of some kind.
 This can be user interaction, which involves user inputs and outputs, interaction
between the systems being developed and other systems or interaction between the
components of the system.
 Modeling system to system interaction highlights the communication problems that
may arise.
 There are 2 approaches to interaction modeling:
1. Use case modeling, 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.
2.2.1 Use Case Modeling
 Each use case represents a discrete task that involves external interaction with a
system.
 In its simplest form, a use case is shown as an ellipse with the actors involved in the
use case represented as stick figures.
 Fig 2.3 shows a use case from the MHC-PMS that represents the task of uploading
data from the MHC-PMS to a more general patient record system.

Fig 2.3: Transfer data use case

 This more general system maintains summary data about a patient rather than the data
about each consultation, which is recorded in the MHC-PMS.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

 There are two actors in this use case: the operator who is transferring the data and the
patient record system.
 Use case diagrams give a fairly simple overview of an interaction so more details will
have to be added in order to understand what is involved.
 This detail can either be a simple textual description, a structured description in a
table, or a sequence diagram.
 Fig 2.4 shows a tabular description of the ‘Transfer data’ use case.

Fig 2.4: Tabular description of the transfer data use case

 Figure 2.5 shows all of the use cases in the MHC-PMS in which the actor ‘Medical
Receptionist’ is involved

Fig 2.5: Use cases involving the role “medical receptionist”

2.2.2 Sequence Diagrams

 Sequence diagrams in the UML are primarily used to model the interactions between
the actors and the objects in a system and the interactions between the objects
themselves.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

 A sequence diagram shows the sequence of interactions that take place during a
particular use case or use case instance.
 Fig 2.6 is an example of a sequence diagram that illustrates the basics of the notation.
 This diagram models the interactions involved in the View patient information use
case, where a medical receptionist can see some patient information.
 Fig 2.6 can be read as follows:
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.
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.

Fig 2.6:
Sequence
diagram for
View patient
information

 Fig
2.7
is a

second example of a sequence diagram from the same system thatillustrates

two additional features.
 These are the direct communication between the actors in the system and the creation
of objects as part of a sequence of operations.
 Diagram below can be read as:
1. The receptionist logs on to the PRS.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

2. There are two options available. These allow the direct transfer of updated
patient information to the PRS and the transfer of summary health data from
the MHC-PMS to the PRS.
3. In each case, the receptionist’s permissions are checked using the
authorization system.
4. Personal information may be transferred directly from the user interface object
to the PRS. Alternatively, a summary record may be created from the database
and that record is then transferred.
5. On completion of the transfer, the PRS issues a status message and the user
logs off.

Fig 2.7:
Sequence
diagram for
transfer data

2.3

Structural Models
 Structural models of software display the organization of a system in terms of the
 components that make up that system and their relationships.
 Structural models may be static models, which show the structure of the system
design or dynamic models, which show the organization of the system when it is
executing.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

2.3.1 Class Diagrams

 Class diagrams are used when developing an object-oriented system model to show
the classes in a system and the associations between these classes.
 An association is a link between classes that indicates that there is a relationship
between these classes.
 Class diagrams in the UML can be expressed at different levels of detail The simplest
way of writing these is to write the class name in a box.
 Note the existence of an association. by drawing a line between classes.
 For example, Figure 2.8 is a simple class diagram showing two classes: Patient and
Patient Record with an association between them.
 In Fig 2.8, each end of the association is annotated with a 1, meaning that there is a
1:1 relationship between objects of these classes.
 That is, each patient has exactly one record and each record maintains information
about exactly one patient

Fig 2.8: UML classes and association

 Fig 2.9 develops this type of class diagram to show that objects of class Patient are
also involved in relationships with a number of other classes.

Fig 2.9: classes and associations in the MHC-PMS

 At this level of detail, class diagrams look like semantic data models. Semantic data
models are used in database design.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

 They show the data entities, their associated attributes, and the relations between these
entities.
 When showing the associations between classes, it is convenient to represent these
classes in the simplest possible way.
 To define them in more detail, information can be added about their attributes (the
characteristics of an object) and operations .
 For example, a Patient object will have the attribute Address and you may include an
operation called ChangeAddress, which is called when a patient indicates that they
have moved from one address to another.
 In the UML, attributes and operations can be shown by extending the simple rectangle
that represents a class. This is illustrated in Figure 2.10 where:
1. The name of the object class is in the top section.
2. The class attributes are in the middle section. This must include the attribute
names and, optionally, their types.
3. The operations (called methods in Java and other OO programming languages)
associated with the object class are in the lower section of the rectangle

2.4

Behavioral Models
 Behavioral models are models of the dynamic behavior of the system as it is
executing.
 They show what happens or what is supposed to happen when a system responds to a
stimulus from its environment.
 There are 2 types:
1. Data: Some data arrives that has to be processed by the system
2. Events: Some event happens that triggers system processing. Events may have
Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10
 Software Engineering [19SCS44]

associated data but this is not always the case.

2.4.1 Data-driven modeling
 Data-driven models show the sequence of actions involved in processing input data
and generating an associated output.
 They are particularly useful during the analysis of requirements as they can be used to
show end-to-end processing in a system.
 Data-flow models are useful because tracking and documenting how the data
associated with a particular process moves through the system helps analysts and
designers understand what is going on.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

 Data-flow diagrams (DFD’s) are simple and intuitive and it is usually possible to
explain them to potential system users who can then participate in validating the
model.
 Fig 2.14 shows the chain of processing involved in the insulin pump software.

Fig 2.14: An activity model of the insulin pump’s operation

 Fig 2.15 illustrates the use of sequence model of the processing of an order and
sending it to a supplier.
 Sequence models highlight objects in a system, whereas data-flow diagrams highlight
the functions.

Fig 2.15: Order processing

2.4.2 Event driven modeling

 Event-driven modeling 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 [stimuli] may cause a transition from one state to another.
 For example, a system controlling a valve may move from a state ‘Valve open’ to a
state ‘Valve closed’ when an operator command (the stimulus) is received.
 The UML supports event-based modeling using state diagrams, which were based on
Statecharts.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

 State diagrams show system states and events that cause transitions from one state to
another.
 They do not show the flow of data within the system but may include additional
information on the computations carried out in each state.
 The sequence of actions in using the microwave is:
 1. Select the power level (either half power or full power).
 2. Input the cooking time using a numeric keypad.
 3. Press Start and the food is cooked for the given time.
 From fig 2.16, it can be seen that the system starts in a waiting state and responds
initially to either the full-power or the half-power button.

Fig 2.16: State diagram of a microwave oven

 Users can change their mind after selecting one of these and press the other button.
 The time is set and, if the door is closed, the Start button is enabled. Pushing this
button starts the oven operation and cooking takes place for the specified time.
 This is the end of the cooking cycle and the system returns to the waiting state.
 Figure 2.17, shows a tabular description of each state and how the stimuli that force
state transitions are generated.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

2.5 Object-oriented design using the UML

 An object-oriented system is made up of interacting objects that maintain their own
local state and provide operations on that state.
 Object-oriented systems are easier to change than systems developed using functional
approaches.
 Objects include both data and operations to manipulate that data.
 They may therefore be understood and modified as stand-alone entities.
 Changing the implementation of an object or adding services should not affect other
system objects.
 To develop a system design from concept to detailed, object-oriented design, there are
several things that you need to do:
* Understand and define the context and the external interactions with the
system.
* Design the system architecture.
* Identify the principal objects in the system.
* Develop design models.
* Specify interfaces.
2.8.1 System Context and Interactions
 The first stage in any software design process is to develop an understanding of the
relationships between the software that is being designed and its external
environment.
 This is essential for deciding how to provide the required system functionality and
Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10
 Software Engineering [19SCS44]

how to structure the system to communicate with its environment.

 Understanding of the context also lets you establish the boundaries of the system.
 Setting the system boundaries helps you decide what features are implemented in the
system being designed and what features are in other associated systems.
 System context models and interaction models present complementary views of the
relationships between a system and its environment:
* A system context model is a structural model that demonstrates the other
systems in the environment of the system being developed.
* An interaction model is a dynamic model that shows how the system interacts
with its environment as it is used.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

 The context model of a system may be represented using associations.

 Associations simply show that there are some relationships between the entities
involved in the association.
 The environment of the system can be represented using a simple block diagram
showing the entities in the system and their associations.
 This is illustrated in fig 2.23, which shows that the systems in the environment of
each weather station are a weather information system, an onboard satellite system,
and a control system.

Fig 2.23: System context for the weather station

 The cardinality information on the link shows that there is one control system but
several weather stations, one satellite, and one general weather information system.
 The use case model for the weather station is shown in fig 2.24.
 This shows that the weather station interacts with the weather information system to
report weather data and the status of the weather station hardware

Fig 2.24: Weather station use cases

 The use case description is shown in fig 2.25.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

Fig 2.25: Use case description – Report weather

2.8.2 Architectural Design

 Once the interactions between the software system and the system’s environment
have been defined, this information is used as a basis for designing the system
architecture.
 The high-level architectural design for the weather station software is shown in fig
2.26.
 The weather station is composed of independent subsystems that communicate by
broadcasting messages on a common infrastructure, shown as the Communication
link in fig 2.26.
 Each subsystem listens for messages on that infrastructure and picks up the messages
that are intended for them.

Fig 2.26: High level architecture of the weather station

 Fig 2.27 shows the architecture of the data collection subsystem, which is included in
fig 2.26.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

Fig 2.27: Architecture of data collection system

 The Transmitter and Receiver objects are concerned with managing communications
and the WeatherData object encapsulates the information that is collected from the
instruments and transmitted to the weather information system.
 This arrangement follows the producer-consumer pattern
 There have been various proposals made about how to identify object classes in object
oriented systems:
* Use a grammatical analysis of a natural language description of the system to
be constructed. Objects and attributes are nouns; operations or services are
verbs.
* Use tangible entities (things) in the application domain such as aircraft, roles
such as manager or doctor, events such as requests, interactions such as
meetings, locations such as offices, organizational units such as companies,
and so on.
* Use a scenario-based analysis where various scenarios of system use are
identified and analyzed in turn.
 There are five object classes in fig 2.28.
 The Ground thermometer, Anemometer, and Barometer objects are application
domain objects, and the WeatherStation and WeatherData objects have been
identified from the system description and the scenario (use case) description:
* The WeatherStation object class provides the basic interface of the weather
station with its environment.
* The WeatherData object class is responsible for processing the report weather
command. It sends the summarized data from the weather station instruments
to the weather information system.
* The Ground thermometer, Anemometer, and Barometer object classes are
directly related to instruments in the system. They reflect tangible hardware

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

entities in the system and the operations are concerned with controlling that
hardware. These objects operate autonomously to collect data at the specified
frequency and store the collected data locally. This data is delivered to the
WeatherData object on request.

Design Models
This diagram shows the sequence of interactions that take place when an external system
requests the summarized data from the weather station. Sequence diagrams are read
from top to bottom:
1. The SatComms object receives a request from the weather information system
to collect a weather report from a weather station. It acknowledges receipt of
this request. The stick arrowhead on the sent message indicates that the
external system does not wait for a reply but can carry on with other
processing.
2. SatComms sends a message to WeatherStation, via a satellite link, to create a
summary of the collected weather data. Again, the stick arrowhead indicates
that SatComms does not suspend itself waiting for a reply.
3. WeatherStation sends a message to a Commslink object to summarize the
weather data. In this case, the squared-off style of arrowhead indicates that the
instance of the WeatherStation object class waits for a reply.
4. Commslink calls the summarize method in the object WeatherData and waits
for a reply.
5. The weather data summary is computed and returned to WeatherStation via

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

the Commslink object.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

6. WeatherStation then calls the SatComms object to transmit the

summarized data to the weather information system, through the
satellite communications system.
This diagram
can be read as
follows:

1. If the system state is Shutdown then it can respond to a restart(),

a reconfigure(), or a powerSave() message. The unlabeled arrow
with the black blob indicates that the Shutdown state is the initial
state. A restart() message causes a transition to norma operation.
Both the powerSave() and reconfigure() messages cause a
transition to a state in which the system reconfigures itself. The
state diagram shows that reconfiguration is only allowed if the
system has been shut down.
2. In the Running state, the system expects further messages. If a
shutdown() message is received, the object returns to the
shutdown state.
3. If a reportWeather() message is received, the system moves to
the Summarizing state. When the summary is complete, the
system moves to a Transmitting state where the information is
transmitted to the remote system. It then returns to the Running
state.
4. If a reportStatus() message is received, the system moves to the
Testing state, then the Transmitting state, before returning to the
Running state.

5. If a signal from the clock is received, the system moves to the

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10

 Software Engineering [19SCS44]

Collecting state, where it collects data from the instruments. Each

instrument is instructed in turn to collect its data from the
associated sensors.
6. If a remoteControl() message is received, the system moves to a
controlled statein which it responds to a different set of messages
from the remote control room. These are not shown on this

diagram.

Prof.Shifana Begum,Dept of CSE,SUCET,MUKKA Page 10