[Unit 3]

System modeling

Prof. Chavan V.D.

System Models in Software Engineering
In software engineering, a system model is a procedure of creating abstract models to
understand the system to be developed. It is an important step while creating software
because, with the help of an abstract model, software developers can easily explain the
system's structure and behaviour to customers.
System Model
The graphical representation of the system which the software developer wants to develop is called a system
model. The system is developed based on user requirements and system requirements. The system models
describe the system in detail using graphical notation. There are four types of system models: context
model, interaction structural model, behavioural model, and structural model.
A system is a set of components related to each other and performing some functions. It is important to
capture and keep in mind some key aspects. The key aspects are:
•defining the parts within the system
•identifying the types of relationships between those parts
•comprehending how those parts relate to the whole system that performs certain functions and
•examining how the whole system interacts with its environment.
We can say that a system model is a procedure that represents the abstract view of the system with the help of
graphical notation, which is based on notations in the UML (Unified Modeling Language). A system model contains a
set of elements that have an interdependent relationship with each other. These models communicate with clients and
explain the whole system to them.
System Perspectives
The abstract models represent a system from different perspectives:
•External perspective: It represents the context of the system.
•Interaction perspective: It deals with the interaction between systems and environments.
Also, it deals with the parts of the system.
•Structural perspective: The model shows the data structure and the system's organization.
•Behavioural perspective: The model shows the system's dynamic behaviour and how it
replies to events.
Types of System Models
Context Model
The external perspective model represents how the system that must be built will interact with
other systems within its environment. It shows the boundaries of a system that includes various
automated systems in an environment. The requirements of employees and stakeholders are
discussed while creating the context model to decide the system's functionality that needs to
be developed. It shows the relationships between the system to be created and other systems.
It is used to explain developers, stakeholders, or customers. Some factors need to be kept in
mind while creating the context model. The factors can be the overall cost of the system, the
time required to analyze the system, etc.
System Boundaries
It describes the inside and outside of the system. It is important to find what is inside and
outside of the environment. The position of the system boundary plays a vital role that affects
the system's requirements.
Examples of the Context Model
Let us see some examples of the context model to comprehend it properly.

1. Example of the Bank ATM System:

The context model diagram has the main system in the middle called the "Bank ATM System".
The main system is connected to actors in an environment. The actors can be users and other
systems. The other systems are the Local Branch Accounting System, Account Database, User
Database, Hardware/ Software Maintenance Staff, Security System, and Cash Counter Staff.
The Bank ATM System is used to dispense cash and permit to make other banking transactions.
The Local Branch Accounting System contains the accounts of the local branch users. The Bank
ATM System interacts with the Local Branch Accounting System to get the user account details.
The Account Database allows user to access their information. The Hardware/ Software
Maintenance Staff tests and maintains the ATM. The Security System is used to protect the ATM
from hackers. The Cash Counter Staff is used to count the cash.
2. Example of the Order Processing System:
The context model diagram has the main system in the middle called the "Order Processing
System". The main system is connected to other systems, which are Customer Channels,
Delivery Dispatch System, Inventory Management System, and Payment Processing System.

The "Order Processing System" is used to manage the orders easily. First, the Order Processing
System will interact with customer channels, and the order may come from different channels.
The data is also exchanged between the main system and other systems. The order is received
from the customer channels, so the data exchange between the Order Processing System and
Customer Channels is "order details and customer info".
The Payment Processing System is used to get the payment from the system. The data
discussed between the Order and Payment Processing System is "order amount and payment
status". The main system will confirm the order and pass the information to the Inventory
Management System because every order requires certain ingredients. The data discussed
between the Order Processing System and Inventory Management System is "order detail and
low inventory alerts". If enough ingredients are not in the inventory, the inventory management
system will alert the main system. When the order is prepared, it must be delivered with the
help of the Delivery Dispatch System that manages the trucks and drivers required. The data
discussed between the Order Processing System and Delivery Dispatch System is "order details
and delivery status".
3. Example of the Inventory Control System:
The context model graph has the main system in the centre called "Inventory Control System".
The primary system is linked to varied systems in an environment. The systems are Inventory
Database, Accounting System, Maintenance System, Monitoring System, Report Generation
System, and Account Database.
The Inventory Control System is the system that handles the inventory, such as tracking the
goods, cost, etc. The Inventory Database holds the inventory data like the necessity of goods,
number of goods, cost, and more.
The Accounting System holds the inventory records, transactions, money paid for buying goods
to fill the inventory, etc. The Monitoring System is the system that monitors the commodities
like stock availability, goods usage patterns of customers, etc.
The Maintenance System is the system that is utilized to maintain the commodities, repair the
inventory if required, and more. The Report Generation System generates inventory-related
reports regarding purchased goods, sold goods, etc. The Account Database is used to store the
accounting information.
The main system is linked to sub-systems to communicate with each other and assist the main
system to work properly.
4. Example of the Baby Daycare System:
The context model graph has the main system in the centre, the "Baby Daycare System". The
main system is attached to users and other systems. The users are Parents, Children, Staff and
Landlord. The Licensing Authority System, Heath Agency, and Catering System are the systems.
The Baby Daycare System assists in taking care of the baby. The parents talk with the baby
daycare system to admit the children in the daycare so the parents will pay the fees to the
daycare for getting the services. The baby daycare system interacts with children and takes
care of them. The baby daycare system needs a location to keep the children so that the
system will interact with the landlord, the landlord will provide premises, and the daycare will
pay the rent.

The baby daycare system will communicate with the catering system to provide the food to
the children so that the daycare will order the food from the catering system. The baby
daycare system should have the right to provide services so that it will communicate with the
licensing authority. The daycare will provide the documents, and the licensing authority will
provide the license. The staff provides expertise to do the job and get the payment from the
daycare. The baby daycare system will interact with the health agency to provide health
facilities to the children because their health is very important.
Interaction Model:
The interaction perspective model explains how components of the system interact with each
other.
There are three types of interactions:
•User interaction: It involves user input and user output. It interacts with the user and helps to
identify user requirements.
•System interaction: It is the interaction between the system which is to be developed and
other systems. It interacts from system to system and highlights the problems that may arise in
communication.
•Component interaction: It interacts with different components of the same system and helps
understand whether the proposed system can provide the required system performance.
There are two kinds of diagrams that come under interaction models, which are as follows:

1. Use Case Diagram:

It was presented by Ivar Jacobson in 1987 in the article on use cases. It models interactions
between a system and an external user or other system. It is a popular model used to support
requirement elicitation and incorporated into the UML (Unified Modeling Language).
It is a simple scenario to explain the user's needs from a system. Every use case shows a
discrete task, including external system interaction.
Example of the Use Case Diagram:
In the simplest form, a "transfer-data" use case is shown below:
The use case is an ellipse, and the actors, i.e., users or other systems, are shown as a stick figure.
The diagram shows a use case from MHC-PMS that we have discussed in the context model.
The diagram has two actors: the Medical Receptionist and the Patient Record System. In the
diagram, you can see that the medical receptionist is initiating the transaction, and data is
transferred to the patient record system, i.e., it represents the task of uploading data to PRS
(Patient Record System). The arrows in the UML indicate the flow of data.
The receptionist must have the required security permissions to access the PRS. The data
transferred from the main system MHC-PMS to a PRS could be the patient's personal
information, treatment details, etc.
For adequate understanding, you can elaborate on the same use case in the tabular format.
Tabular description of the Transfer Data use
case:
If there are many use cases, you can describe them using a composite use case diagram, showing
various use cases in a single diagram.
Composite Use Case Diagram:
You can see the composite use case diagram above; there are five use cases: Register
Patient, Unregister Patient, Transfer Data, View Patient Information, and Contact patient.
All roles are played by the medical receptionist, which means the only actor is the medical
receptionist, and there are five use cases.
A receptionist looks at whether the patient is registered or unregistered; after that, the
receptionist views the patient's information, such as contact, address, etc., then transfers the
data and contacts the patient.

2. Sequence Diagrams:
It is used to model interactions between system components, and external systems may also
be involved. This diagram is useful in exhibiting the interaction between the actors and the
objects within the system. It represents the sequence of interactions that take place at the
time of a certain use case.

Example of Sequence Diagram:

You can see a sequence diagram below that is drawn to view patient information. This
example has been taken from MHC-PMS, where viewing patient information is a type of
functionality that MHC-PMS provides.

We will see how the sequence diagram is drawn for viewing patient information, which
means we will see the different sequences of interactions that will take place.
The sequence diagram shows interactions between actors and objects by annotated arrows. Solid
annotated arrows represent the request, and the response is represented by dotted annotated
arrows. Dotted lines are drawn below the objects to connect the different sequences of
interactions.
The top part of the diagram is listed with actors, i.e., medical receptionist and objects, i.e., patient
info, MHCPMS database, and authorization.
The interactions will occur if a medical receptionist wants to view the patient's information. The
view patient information is not a single activity, but different interactions are hidden within the
view patient activity.
Initially, the medical receptionist sends a request along with the patient ID and PID to the object
class "P: PatientInfo" to view information about the patient. From the instant "P" request is sent
along with the PID (patient ID) and UID (user ID) to the database of MHC-PMS. From MHC-PMS,
the information is not directly provided to the medical receptionist, but first authorization takes
place to check whether the action is requested from an authorized user or not, as it is secure and
private information that cannot be given to an unauthorized user that is why the request is sent to
authorization object.
A box named "Alt" shows whether the authorization is OK. If the user is authorized, only the patient
information is returned from the database to "P: PatientInfo" and then to the medical receptionist.
If the authorization fails, an error message says there will be no access to the information you are
asking for.
The vertical rectangular boxes represent the time of the object instant being active. The medical
receptionist is active from the beginning to the end of the overall session, and the authorization is
active for a short time. So, you can see, to view information, many sequences of interactions take
place.
Structural Model:
The structural perspective model represents a system's organization in terms of the parts that
build the system and their relationships. Structural models can be static models or dynamic
models. The static models represent the structure of the system design, and the dynamic
models represent the system's organization during execution. When we want to design the
system architecture, then the structural model of the system is created.

The structural model is of three types, which are as follows:

[Link] diagrams
[Link]
[Link]

We will understand these types one by one.

1. Class diagrams
It is a popular diagram that comes under UML. When creating an object-oriented system
model, classes and their association are shown in the system, then class diagrams are used.
An association is a relation between the classes that connect classes.
Class diagrams are described at varying levels of detail in UML. An object class is a type of
system object.
UML classes and association:
Let us understand how a class diagram is created.
The class name is written inside the rectangular box, and the association between the two
classes is shown with the help of a solid line. The feature of a class diagram is the ability to
demonstrate the number of objects included in the association.

You can see a simple diagram of patient and patient records below:-

In the class diagram, the association between patient and patient records is one-to-one. Each
end of the association is annotated with 1, which means one patient can have exactly one
record.
Classes and associations in the MHC-PMS
In the diagram below, various classes are written inside the rectangular boxes.
The classes are Condition, Consultant, Patient, General Practitioner, Consultation,
Medication, Treatment, and Hospital Doctor. The diagram demonstrates the data entities,
their associated attributes, and the relation between these entities. The association
between classes should be shown easily.
We can add more information about the attributes and operations of the class. We will see
a diagram of adding more information to the class. Let us see the class "Consultation"
attributes and operations in the class diagram.

You can see the diagram above; a rectangle is divided

into three parts. The object class is written in the top
part of the rectangle, Class attributes are in the
middle part, and operations are in the bottom.
2. Generalization
It is the method that is used to manage the complexity. The entities are placed in more
general classes for easy understanding. In object-oriented languages like Java, generalization
is implemented with the help of class inheritance mechanisms built into the language.
In generalization, the operations and attributes associated with higher-level classes are also
associated with lower-level classes, which are subclasses that inherit the properties from
parent classes.

You can see the diagram above where the class,

which is a more general class, is shown by using
Arrowhead pointing up. Lower classes inherit all
the operations and attributes from the parent
classes.
The higher level class is "Doctor". The lower level
classes are "Hospital Doctor" and "General
Practitioner", generalized as doctors.
The "Consultant" and "Team Doctor" classes are
generalized as hospital doctors. The "Trainee
Doctor" classes and "Qualified Doctors" are
generalized as team doctors.
3. Aggregation
The UML delivers a special kind of relationship between classes called aggregation. Objects are
composed of various parts, which the aggregation model shows.

Example of aggregation association:

In the diagram below, the "Patient Record" is an object class composed of Patients
and Consultations. A diamond shape is used to show the composition of classes.
4. Behavioural Model:
It is the behavioural perspective model that represents the dynamic behaviour of the system.
There are two types of behavioural models:
[Link]-driven modeling
[Link]-driven modeling
Let us comprehend both types in detail one by one.

1. Data-driven modeling
It means data that comes in has to be processed by the system. Data-driven modes are the first
graphical software models. Data-driven models represent the actions, which include
processing input data and generating an associated output. These models are used to show
end-to-end processing in the system, so they are helpful for analysis of requirements.
Data Flow Diagrams (DFDs) are simple diagrams for tracking and documentation purposes. It
helps to understand the developers of the system. It shows the data exchange between a
system and other systems within its environment.

Example for order processing DFD for insulin pump:

The order processing DFD for the insulin pump is shown in the diagram below. In this
example, notations used in this model are the rounded boxes for representing the functional
boxes, rectangular boxes for representing the data stored, and arrows for representing the
data flow between the functions.
Blood Sugar is taken in this example and then analyzed through the sensor. After that,
according to the blood sugar, the required insulin computation is done, and the proper amount
of insulin is given to the patient to control the sugar level. The data flows in a systematic way to
achieve the goal.
2. Event-driven modeling
It means that an event occurs that triggers the system, and that event may have associated
data. This model represents the response of the system to external and internal events.
This modeling assumes a system has several states, and events can cause transitions
between states. It is used to depict the state machine model.
The state machine model represents system states as nodes and events as arcs between
these nodes. Event-driven modeling is represented with the help of state diagrams, which
are based on state charts.

Example of State Diagram:

You can see a state diagram of a microwave oven below, but real microwaves are much
more complex than this state diagram.
In this example, a simple microwave is used to understand the state diagram easily. A
microwave has a switch for selecting half or full power, a numeric keypad for inputting the
cooking time, an alphanumeric display, and a start-stop button.
The display shows half power when the microwave oven power is 250 watts. The display
shows full power when the microwave oven power is assigned to 500 watts.
We have assumed the sequence of actions in the microwave in the following order: the first
sequence is to select the power level, either half or full; the second sequence is to input the
cooking time with the help of an alphanumeric keypad, and then the third sequence is to
press the start button. After that, there will be two conditions: "Door Open" and "Door
Closed". If the door is open, then the operation is disabled.
If the door is closed, the timer is set, and the operation is enabled. When the microwave
starts, cooking takes place for a specific time. After the cooking time is over, a buzzer
sounds, and the microwave display returns to the waiting state.
 Model-driven engineering
Model-Driven Engineering is a methodological approach in software development that involves building
and using abstractions of processes to create higher quality software compared to general programming
languages. It revolves around creating models, metamodels, and model transformations to simplify and
automate complex processes.
Model-driven software engineering provides an approach such that one can design complex software
or system in the form of a model and use that model to generate a code for the system automatically.
As the model is a preferred output of model-driven software engineering (MDSE) there is no need for
engineers to be concerned with the actual specifics of the execution platform or which programming
language has to be used, there is no need for programming language details. It allows engineers to
think about software at a high level of abstraction, without being concerned about the
implementation.
Models and abstraction levels
Models can be considered as a key in MDE as it plays an important role in developing complex systems.
While creating of model one must be concerned with the abstraction levels.
Some of the abstraction types as described as follows:
•Structure — In this type of abstraction only structural components such as classes, subclasses, modules,
interfaces which includes inputs and outputs, etc. are shown and all other details are hidden.
•Behavior — Main functionality of software to be developed i.e behavioral details are shown in this type.
•Timing — All the time-related constraints are addressed.
•Resources — Models may represent the environment of the software.
•Metamodels — Just like metadata which can be considered as data about the data, meta-models can be
considered as models about the models. They describe how the model should be.
Advantages of Model-driven engineering
•Higher Productivity — As code is generated automatically by the developed model tiring process of
programming is done autonomously by the model.
•Abstraction — Abstraction is raised to model level from program level with the help of Model-driven
software engineering.
•Consistency — As code is auto-generated it’s well maintained and consistent in nature.
•Time — More time can be given to the core problem statement and its key concepts as the time is
reduced in coding.
•Improved quality — Handwritten code comes with variations and contrasts as work is done in a
distributed manner. Hence these improvisations have to be made manually to make code more
consistent but in the case of generators, incompetency is reduced significantly thus the overall quality of
code is improved.
Disadvantages
•To build a model itself is a tedious and quite time-consuming task.
•Even after building a code generator, there are chances that it might not be sufficient enough and work in
all the cases.
•In each system, there might be a type of code that the model cant generate and has to be generated
manually.
 Architectural design
For the program to represent software design, architectural design is required. "The process of
defining a collection of hardware and software components and their interfaces to establish the
framework for the development of a computer system" is how the IEEE defines architectural
design. The following tasks are carried out by an architectural design. One of these numerous
architectural styles can be seen in software designed for computer-based systems.

Every style shall outline a system category made up of the following:

•A collection of parts (such as computing modules and databases) that together will carry out a
task that the system needs.
•The connector set will facilitate the parts' cooperation, coordination, and communication.
•Requirements that specify how parts can be combined to create a system.
•Semantic models aid in the designer's comprehension of the system's general characteristics.
Software requirements should be converted into an architecture that specifies the components
and top-level organization of the program. This is achieved through architectural design, also
known as system design, which serves as a "blueprint" for software development. Architectural
design is "the process of defining a collection of hardware and software components and their
interfaces to establish the framework for developing a computer system," according to the IEEE
definition. The software requirements document is examined to create this framework, and a
methodology for supplying implementation details is designed. The system's constituent parts
and their inputs, outputs, functions, and interplay are described using these specifics.
[Link] establishes an abstraction level where the designers can specify the system's functional
and performance behavior.
[Link] outlining the aspects of the system that are easily modifiable without compromising its
integrity, it serves as a guide for improving the system as necessary.
[Link] assesses every top-tier design.
[Link] creates and records the high-level interface designs, both internal and external.
[Link] creates draft copies of the documentation for users.
[Link] outlines and records the software integration timetable and the initial test requirements.
[Link] following is a list of the sources for architectural design.
[Link] on the software development project's application domain
[Link] use of data flow charts
[Link] accessibility of architectural patterns and styles.
Components of Architectural Design
High-level organizational structures and connections between system components are
established during architectural design's crucial software engineering phase. It is the
framework for the entire software project and greatly impacts the system's effectiveness,
maintainability, and quality. The following are some essential components of software
engineering's architectural design:
•System Organization: The architectural design defines how the system will be organized into
various components or modules. This includes identifying the major subsystems, their
responsibilities, and how they interact.
•Abstraction and Decomposition: Architectural design involves breaking down the system into
smaller, manageable parts. This decomposition simplifies the development process and makes
understanding and maintaining the system easier.
•Design Patterns: Using design patterns, such as Singleton, Factory, or Model-View-Controller
(MVC), can help standardize and optimize the design process by providing proven solutions to
common architectural problems.
•Architectural Styles: There are various architectural styles, such as layered architecture, client-
server architecture, microservices architecture, and more. Choosing the right style depends on the
specific requirements of the software project.
•Data Management: Architectural design also addresses how data will be stored, retrieved, and
managed within the system. This includes selecting the appropriate database systems and
defining data access patterns.
•Interaction and Communication: It is essential to plan how various parts or modules will talk to
and interact with one another. This includes specifying message formats, protocols, and APIs.
•Scalability: The architectural plan should consider the system's capacity for expansion and
scalability. Without extensive reengineering, it ought to be able to handle increased workloads or
user demands.
•Security: The architectural design should consider security factors like access control, data
encryption, and authentication mechanisms.
•Optimization and performance: The architecture should be created to satisfy performance
specifications. This could entail choosing the appropriate technologies, optimizing algorithms, and
effectively using resources.
•Concerns with Cross-Cutting: To ensure consistency throughout the system, cross-cutting issues
like logging, error handling, and auditing should be addressed as part of the architectural design.
•Extensibility and Flexibility: A good architectural plan should be adaptable and extensible to
make future changes and additions without seriously disrupting the existing structure.
•Communication and Documentation: The development team and other stakeholders must
have access to clear documentation of the architectural design to comprehend the system's
structure and design choices.
•Validation and Testing: Plans for how to test and validate the system's components and
interactions should be included in the architectural design.
•Maintainability: Long-term maintenance of the design requires considering factors like code
organization, naming conventions, and modularity.
•Cost factors to consider: The project budget and resource limitations should be considered
when designing the architecture.
Advantages of Architectural Design
[Link] and Clarity: The organization of the software system is represented in a clear and
organized manner by architectural design. Modularity: In architectural design, modularity
divides a system into more manageable, independent modules or components.
[Link]: A system's scalability refers to its capacity to accommodate growing workloads and
expand over time.
[Link] and Expandability: The extensibility and maintenance of software are enhanced
by architectural design.
[Link] Optimization: Performance optimization ensures the system meets parameters
like response times and resource usage.
[Link]: An essential component of architectural design is security.
[Link]: When a system is reliable, it operates as planned and experiences no unplanned
malfunctions.
[Link]: The system's capacity to communicate with other systems or services is
known as interoperability.
[Link] Efficiency: Making cost-effective decisions is aided by an architectural design
that is in line with the project's budget and resource limitations.

Disadvantages of Architectural Design

[Link] Time Investment: Developing a thorough architectural design can take a while,
particularly for complicated projects.
[Link]-Engineering: When features or complexity in the architectural design are redundant
or unnecessary for the project's objectives, it's known as over-engineering.
[Link]: It can be difficult to adjust an architecture that is too rigid to new requirements or
technological advancements.
[Link]: Comprehending and maintaining complex architectural designs can be
challenging, particularly for developers not part of the original design process.
[Link] with Requirements: Occasionally, there may be a discrepancy between the
architectural plan and the actual project specifications, leading to needless complications or
inefficiencies. This misalignment may require additional labour and modifications to
guarantee the system achieves its objectives.
Architectural design decisions
• Architectural design is a creative process so the process differs depending on
the type of system being developed.
• However, a number of common decisions span all design processes and these
decisions affect the non-functional characteristics of the system.
• Questions:
oIs there a generic application architecture that can be used?
oHow will the system be distributed?
oWhat architectural styles are appropriate?
oWhat approach will be used to structure the system?
oHow will the system be decomposed into modules?
oWhat control strategy should be used?
oHow will the architectural design be evaluated?
oHow should the architecture be documented?
Architectural views
• What views or perspectives are useful when designing and documenting a
system’s architecture?
• What notations should be used for describing architectural models?
• Each architectural model only shows one view or perspective of the system.
It might show how a system is decomposed into modules, how the run-time processes interact or
the different ways in which system components are distributed across a network. For both design
and documentation, you usually need to present multiple views of the software architecture.
4 + 1 view model of software architecture
• A logical view, which shows the key abstractions in the system as objects or
object classes.
• A process view, which shows how, at run-time, the system is composed of
interacting processes.
• A development view, which shows how the software is decomposed for
development.
• A physical view, which shows the system hardware and how software
components are distributed across the processors in the system.
• Related using use cases or scenarios (+1)
Architectural patterns
• Patterns are a means of representing, sharing and reusing knowledge.
• An architectural pattern is a stylized description of good design practice, which
has been tried and tested in different environments.
• Patterns should include information about when they are and when they are
not useful.
• Patterns may be represented using tabular and graphical descriptions.
The Model-View-Controller (MVC) pattern
Name MVC (Model-View-Controller)

Description Separates presentation and interaction from the system data. The system is structured into three logical components
that interact with each other. The Model component manages the system data and associated operations on that
data. The View component defines and manages how the data is presented to the user. The Controller component
manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the
Model. See Figure below.
Example Second figure below shows the architecture of a web-based application system organized using the MVC pattern.

When used Used when there are multiple ways to view and interact with data. Also used when the future requirements for
interaction and presentation of data are unknown.

Advantages Allows the data to change independently of its representation and vice versa. Supports presentation of the same data
in different ways with changes made in one representation shown in all of them.

Disadvantages Can involve additional code and code complexity when the data model and interactions are simple.
Web application architecture using the MVC pattern