CHAPTER-5

SYSTEM MODELLING
 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 notationbased on
diagram types in the Unified Modeling Language (UML).
 Models are used during the requirements engineering
process to help derive the detailed 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.
System perspectives
 Different models are developed to represent the system from
different perspectives.
 External perspective: model the context or environment of the
system
 Interaction perspective: model the interactions between a
system and its environment or between the components of the
system
 Structural perspective: model the organization of a system or
the structure of the data that is processed by the system
 Behavioural perspective: model the dynamic behaviour of the
system and how it responds to events.
UML diagram types
 The Unified modeling language is a standard
graphical language for modeling object oriented
software.
 The UML has many diagram types and so supports the creation
of many different types of system model. UML diagram types
here:
1. Activity diagrams, which show the activities involved in a
process or in data processing.
2. Use case diagrams, which show the interactions between a
system and its environment.
3. Sequence diagrams, which show interactions between actors and
the system and between system components.
4. Class diagrams, which show the object classes in the system and
the associations between these classes.
5. State diagrams, which show how the system reacts to internal
and external events.
 A context model defines how context data are structured
and maintained in the system’s environment.
 Context models are used to illustrate the operational context of a
system –
 they show what lies outside the system boundaries.
 Defines the physical scope of the system:
 what is part of the system (under your control)
 what is external to the system
 Social and organizational concerns may affect the decision on
where to position system boundaries.
 Architectural models show the system and its relationship with
other systems.
 Flow Line
(Data)

External
Entity Process

Flow Line
(Information)
 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.
 Structural models of software display the organization of a
system in terms of the components that make up that system and
their relationships.
 Models may be static or dynamic model
 Static Model
 Structural models may be static models, which show the
organization of the system design
 Dynamic Model
 Show the organization of the system when it is executing

 Structural design is an important topic in software engineering,

and UML component, Class diagrams, package, and
deployment diagrams may all be used when presenting
architectural models.
 UML 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 object class can be thought of as a general definition of one
kind of system object.
 An association is a link between classes that indicates that there
is some relationship between these classes. When you are
developing models during the early stages of the software
engineering process, objects represent something in the real
world, such as a patient, a prescription, doctor, etc.
 Behavioral models are models of the dynamic behavior of a
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. Two types of stimuli:
 Some data arrives that has to be processed by the system.
 Some event happens that triggers system processing. Events
may have associated data, although this is not always the
case.
 The design process for identifying the sub-systems making up a
system and the framework for sub-system control and
communication is architectural design.
 Architectural design is concerned with understanding how a
software system should be organized and designing the overall
structure of that system.
 An early stage of the system design process
 Represents the link between specification and design processes
 Often carried out in parallel with some specification activities
 It involves identifying major system components and their
communications
 The output of the architectural design process is an architectural
model that describes how the system is organized as a set of
communicating components.
 Why Software Architecture?
16  Manage complexity of large software projects through
abstraction
 Communicate, remember and share global design
decisions among the team
 Visualize and represent relevant aspects (structure,
behaviour, deployment, …) of a software system
 Understand, predict and control how the design
impacts quality attributes of a system
 Define a flexible foundation for the maintenance and
future evolution of the system
 There are different opinions as to what views are required in well-
known view model of software architecture, suggests that there
should be four fundamental architectural views.
1. A logical view, which shows the key abstractions in the system as
objects or object classes. It should be possible to relate the system
requirements to entities in this logical view.
2. A process view, which shows how, at runtime, the system is
composed of interacting processes. This view is useful for making
judgments about non-functional system characteristics such as
performance and availability.
3. A development view, which shows how the software is
decomposed for development; that is, it shows the breakdown of
the software into components that are implemented by a single
developer or development team.
4. A physical view, which shows the system hardware and how
software components are distributed across the processors in the
system. This view is useful for systems engineers planning a
system deployment.
 Performance
• Localise operations to minimise sub-system
communication
 Security
• Use a layered architecture with critical assets in inner
layers
 Safety
• Isolate safety-critical components
 Availability
• Include redundant components in the architecture
 Maintainability
• Use fine-grain, self-contained components
 The idea of patterns as a way of presenting, sharing, and reusing
knowledge about software systems has been adopted in a
number of areas of software engineering.
 Architectural patterns “architectural styles” and briefly describe
a selection of architectural patterns that are commonly used.
 Some examples of patterns that are widely used and that capture
good architectural design principles.
 Layered architecture
 Repository architecture
 Client–server architecture
 Pipe and filter architecture
 Structuring system data requirements
 It is representation of organizational data which includes
all the major entities and relationship.
 System analysts develop a conceptual data model for the
current system that supports the scope and requirement
for the proposed system.
 Its main aim is to capture as much meaning of data as
possible.
 Most organization today use conceptual data modelling
using E-R model which uses special notation to represent
as much meaning about data as possible.
 Entity Relationship Model
 It is a technique used in database design that helps describe the
relationship between various entities of an organization.
 Terms used in E-R model:
 ENTITY − It specifies distinct real world items in an application.
For example: Patient, drug, nurse, ward, doctors, etc.
 RELATIONSHIP − They are the meaningful dependencies
between entities. For example, pharmacist stores drugs,
receptionist assign doctors, then stores and assign are relationship.
 In the relational model entities can be related as any of 'one-
to-many', 'many-to-many', one-to-one' and so on.
 ATTRIBUTES − It specifies the properties of relationships. For
example, Patient_name, ward_ID.
Example of ERD for PMS
Drug
Bill
Store

Patient Assigned Ward Pharmacist

N

Govern
Attend
Nurse Receptionist
M
Doctor P_name Dis_Cat
Maintain
Date
Appoint
Dr_name Record
 System Design Document
1. Introduction
24 1.1 Purpose of the system
1.2 Design goals
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Current software architecture
3. Proposed software architecture
3.1 Overview
3.2 Subsystem decomposition
3.3 Hardware/software mapping
3.4 Persistent data management
3.5 Access control and security
3.6 Global software control
3.7 Boundary conditions
4. Subsystem services
Glossary