System Modeling and Architecture Design

Context models

Interaction models

Structural models

Behavioural models

Model-driven engineering

Architectural design decisions

Architectural views

Architectural patterns

Application architectures

Web Application Design

Mobile Application Design

Chapter objective

1) Introducing a number of system models that may be developed during the requirements
engineering process.
2) Understand how graphical models can be used to represent software systems and to
establish the boundaries of a system and model its context.
3) Introduced the notations defined in the Unified Modeling Language (UML) and
understand how these notations may be used to develop system models.

Model: A model is a simplified representation of a system at some particular point in time or

space intended to promote understanding of the real system. A model is an abstract view of a
system that ignores some system details. Complementary system models can be developed to
show the system’s context, interactions, structure, and behavior.

System model: The most significant feature of a system model is that it lacks detail. A
system model is an abstraction of the system under study, not an alternate representation.

Various methods of abstraction serve as the foundation for various kinds of system models.

For instance, a data-flow model focuses on the movement of data and the functional
modifications made to that data. It omits information on the data structures.

Modeling: Modeling is a discipline for developing a level of understanding of the interaction

of the parts of a system, and of the system as a whole. It is also very much an art form.

System Modelling
 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 modelling helps the analyst to understand the functionality of the system and
models are used to communicate with customers.
 System modeling typically involves employing graphical notations based on the Unified
Modeling Language (UML).
 Documenting the system specification as a collection of system models is one popular
method.

 System models are graphical representations of business processes, problems, and

systems to be developed.
 Models are frequently easier to grasp than in-depth descriptions of the system
requirements written in common language because of the graphical representations that
are used. Additionally, they serve as a crucial link between the procedures for analysis
and design.
 Models can be used in the analysis process to specify the new system that is needed or to
gain a knowledge of the current system that has to be replaced or enhanced.
 Model-driven analysis is a method of problem-solving that places a strong emphasis on
creating graphical or pictorial system models in order to record and verify proposed or
existing systems.

Different models to represent the system from different perspectives:

 External perspective: An external perspective, where the context or environment of the

system is modeled.
 Behavioural perspective: A behavioural perspective, where the behaviour of the system
is modeled.
 Structural perspective: A structural perspective, where the architecture of the system or
the structure of the data processed by the system is modelled.

Models for the existing system: Models of the existing system are utilized in requirements
engineering. They clarify the system's function and serve as a foundation for discussing its
advantages and disadvantages. This leads to requirements for the new system.

Models of the new system: Models of the new system are used in requirements engineering
to communicate suggested requirements to stakeholders. Engineers use these models to
review design concepts and record systems for implementation.

Based on the system model, model-driven engineering enables full or partial system
implementation.

Benefits of System Modeling

 Ease project management tasks.

 Can provide complete views of a system, as well as detailed views of subsystems.
 Clarify structures and relationships.
 Offer a communication framework for ideas within and between teams.
 Can generate new ideas and possibilities.
 Allow quality assurance and testing scenarios to be generated.
 Are platform independent.

The following are some examples of system models you could develop when doing the
analysis:

 A data- flow model: Data-flow models show how data is processed at different stages in
the system.
 A composition model: A composition or aggregation model shows how entities in the
system are composed of other entities.
 An architectural model: Architectural models show the principal sub-systems that make
up a system.
 A classification model: Object class/inheritance diagrams show how entities have
common characteristics.
 A stimulus-response model: A stimulus-response model, or state transition diagram,
shows how the system reacts to internal and external events.

The UML provides several diagram kinds, allowing for the design of various system models.
Most UML users believed that five diagram kinds were sufficient to represent the essence of
a system.

 Activity diagrams, which show the activities involved in a process or in data processing.
Activity diagrams may be used to model the processing of data, where each activity
represents one process step.
 Use case diagrams, which show the interactions between a system and its environment.
 Sequence diagrams, which show interactions between actors and the system and
between system components.
 Class diagrams, which show the object classes in the system and the associations
between these classes.
 State diagrams, which show how the system reacts to internal and external events. State
diagrams are used to model a system’s behavior in response to internal or external events.

Context Models
 Context models show how a system that is being modeled is positioned in an environment
with other systems and processes. They help define the boundaries of the system to be
developed.
 Context models are used to illustrate the boundaries of a system. This involves working
with system stakeholders to distinguish what is the system and what is the system’s
environment. You should make these decisions early in the process to limit the system
costs and the time needed for analysis.
 Shows the scope and boundaries of a system at a glance including the other systems that
interface with it.
 Context models provide an overview (abstraction) of an entire system, and shows the
most important aspects. Context models highlight the key elements of a system. Details
are not included.
 Context models typically indicate that the environment involves multiple automated
systems.
 Context models typically indicate the presence of multiple more automated systems in the
environment. They do not, however, depict the kinds of connections that exist between
the system under specification and the systems in its surroundings.
 Determining the boundaries of a system should be done early in the specification process.
This entails deciding what features belong in the system and what the system's
environment provides in collaboration with system stakeholders. Collaboration with
stakeholders determines system functionality and environment requirements.
 Understanding the diagram does not necessitate or require technical understanding.
Because of its concise notation, it is simple to draw and edit.
 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.

Determining that context and the dependencies a system has on its surroundings is a part of
the analysis process, once the limits of the system have been decided upon. Creating a basic
architectural model is typically the first phase of this undertaking.

Figure below is a simple context model that shows the patient information system and the
other systems in its environment.
 Figure: The context of the MHC-PMS

Here in the above diagram we are creating the specification for a patient information system
in mental healthcare.

This system manages information on mental health clinic patients and their prescribed
treatments.

In above system we must determine when creating the system's specification if the system
should just be used to gather data about consultations or whether it should additionally get
private patient data.

From figure above, we can see 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.

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

medication.

Context models with process models

Contextual models are used with other models, including business process models. These
refer to human and automated processes that utilize certain software platforms.
 Figure: Process model of involuntary detention

The figure above is a UML activity diagram. Activity diagrams depict the activities in a
system process and the control flow between them. A filled circle marks the beginning and
end of a procedure. Rectangles with round corners symbolize activities, or required sub-
processes.

Arrows in a UML activity diagram indicate the flow of work from one activity to another. A
solid bar is used to show activity coordination. When many activities result in a solid bar,
they must all be completed before progress is possible. When a solid bar triggers multiple
actions, they can run simultaneously.

Therefore, the operations of informing social care and next of kin, as well as updating the
detention register, may occur concurrently.

In figure above, you can see 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.
Context models of ATM system

Figure: The context of an ATM system

Figure above is an architectural model that illustrates the structure of the information system
that includes a bank auto-teller network.

We see that each ATM is connected to an account database, a local branch accounting
system, a security system and a system to support machine maintenance.

The system is also connected to a usage database that monitors how the network of ATMs is
used and to a local branch counter system.

This local branch counter system provides services such as backup and printing.

Simple architectural models are typically enhanced by additional models, such as process
models, which illustrate the system-supported process activities. The data that is transmitted
between the system and other systems in its environment can also be displayed using data-
flow models.

The figure below shows a process model for acquiring equipment in an organization. The
process includes specifying equipment, selecting suppliers, ordering, receiving, and testing it.
When specifying computer support for this process, determine which activities will be
supported. Other actions occur outside of the system. In figure below, the dotted line
encloses the activities that are within the system boundary.
 Figure: Process model of equipment procurement

Interaction models

There is some sort of interaction in every system. This can be system-to-system or system-
component interaction, involving user inputs and outputs, or interaction between the system
under development and other systems. Creating Models, user contact is crucial because it
facilitates the identification of user needs. System-to-system interaction modeling brings to
light potential communication issues.

We can determine whether a suggested system structure is likely to provide the necessary
system performance and reliability by modeling the interaction between the components.

Needs two related 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.

Notes: Use case diagrams and sequence diagrams are used to describe the interactions
between user the system being designed and users/other systems. Use cases describe
interactions between a system and external actors; sequence diagrams add more information
to these by showing interactions between system objects. Use case models and sequence
diagrams present interaction at different levels of detail and so may be used together.
1) Use case modeling: Use case modeling is commonly used to facilitate requirements
elicitation. A use case is a simple scenario that describes a user's expectations from a
technology. Each use case refers to a specific task that requires external interaction with
the system.

A use case is depicted as an ellipse, with actors portrayed as stick figures. Figure below
illustrates a use case for transferring data from the MHC-PMS to a more comprehensive
patient records system.

Figure: Transfer data use case

Notice that 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 you have to provide
more detail to understand what is involved. This detail can either be a simple textual
description, a structured description in a table, or a sequence diagram.

Figure below shows all of the use cases in the MHC-PMS in which the actor ‘Medical
Receptionist’ is involved.
 Figure: Use cases involving the role ‘medical receptionist’

2) Sequence diagrams

The main purposes of sequence diagrams in the UML are to represent the interactions that
take place within a system between its objects and its actors.

A sequence diagram shows the sequence of interactions that take place during a particular use
case or use case instance.

The diagram below models the interactions involved in the View patient information use
case, where a medical receptionist can see some patient information.

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

The sequence of interactions is from top to bottom.

The notes on the arrows indicate the calls to the objects, their parameters, and the return
values.

Here for alternatives notation. A box named alt is used with the conditions indicated in
square brackets.
 Figure: Sequence diagram for View patient information

From above sequence diagram we can see that the medical receptionist calls the ViewInfo
method on an instance P of the PatientInfo object type, passing the patient's identity (PID).
P is a user interface object that displays a form with patient information.

Instance P requests information from the database and provides the receptionist's identifier
for security checks (the origin of the UID is unimportant at this point).

The database checks with an authorization system that the user is authorized for this action.

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.

Structural models

Software structural models show how a system is organized in terms of its constituent parts
and their interrelationships. Structural models can be either dynamic or static. Static models,
which show the structure of the system design and dynamic models, which show the
organization of the system when it is executing.

Structural models show the organization and architecture of a system. Class diagrams are
used to define the static structure of classes in a system and their associations.

We create structural models of a system when you are discussing and designing the system
architecture.

(Class diagrams for representing static models)

Class diagrams
Object /Class Modeling
 Class – Template to define specific instances or objects
 Object – Instantiation of a class
 Attributes – Describes the object
 Behaviors – specify what object can do

The UML Class diagram is a graphical notation used to construct and visualize object
oriented systems. A class diagram in the Unified Modeling Language (UML) is a type of
static structure diagram that describes the structure of a system by showing the
system's:classes, their attributes, operations (or methods), and the relationships among
objects.

Structure of class diagram

 Class Name
 Set of attributes
 Set of operations(or methods)
Visibility of the class

 Private attribute/operation denoted by minus (-)

 Public attribute/operation denoted by plus (+)
 Protected attribute/operation denoted by hash (#)
 Package attribute/operation denoted by tilde (~)

Relationships between classes

Association:

 logical connection or relationship between classes.

 Eg: passenger and airline may be linked as below

Aggregation:
 refers to the formation of a particular class as a result of one class being aggregated or
built as a collection.
 draw a line from the parent class to the child class with a diamond shape near the parent
class.
 Eg: College and Student, Library and books, Room and walls, Computer and mouse,
hospitals and doctors

Composition:

 Strong form of aggregation

 the child class will be destroyed when the parent class is destroyed
 draw a line from the parent class to the child class with a filled diamond shape near the
parent class.
 Eg: Building and office, Browser and Tab, Person and Head

Example: Room is part of building. If building collapse room also collapse. So it is strong
form of aggregation. If college is not functioning all student also affecting directly.

Dependency

 A dependency means the relation between two or more classes in which a change in one
may force changes in the other. However, it will always create a weaker relationship.
 Dependency indicates that one class depends on another.
 Example: Student has a dependency on College

Inheritance(Generalization/specialization)

 Child class Inherits property of parent class

 A solid line from the child class to the parent class is drawn using an unfilled arrowhead.

Realization

 Denotes the implementation of the functionality defined in one class by another class.
 A broken line with an unfilled solid arrowhead is drawn from the class that defines the
functionality of the class that implements the function
 Eg: the printing preferences that are set using the printer setup interface are being
implemented by the printer.
Cardinality/multiplicity

 Exactly one – 1
 Zero or one - 0..1
 Many - 0..* or *
 One or more - 1..*
 Exact Number - e.g. 3..4 or 6
 Or a complex relationship - e.g. 0..1, 3..4, 6. * would mean any number of objects other
than 2 or 5

Roles

for directional purpose of association ;comes with word

 Fig: Class diagram of order processing system

Behavioural models

Behavioural models are used to describe the overall behaviour of the system. They show
what happens or what is supposed to happen when a system responds to a stimulus from its
environment.

Behavioral models are used to describe the dynamic behavior of an executing system. This
can be modeled from the perspective of the data processed by the system or by the events that
stimulate responses from a system.

Stimulus can be Data and Events:

a) Data: Some data arrives that has to be processed by the system.

b) Events: Some event happens that triggers system processing. Events may have associated
data but this is not always the case.

Behavioural model here: data-flow models, which model the data processing in the system
and state machine models, which model how the system reacts to events.
These models may be used separately or together, depending on the type of system that is
being developed.

1) Data-flow models

A dataflow model may be all that is needed to represent the behaviour of these systems.

Data-flow models are an intuitive way of showing how data is processed by a system. At the
analysis level, they should be used to model the way in which data is processed in the
existing system.

Data-flow models are used to show how data flows through a sequence of processing steps.

Data-flow models are valuable because tracking and documenting how the data associated
with a particular process moves through the system helps analysts understand what is going
on.

Data-flow models give a functional viewpoint in which every transformation stands in for a
distinct process or function. They are very helpful for demonstrating end-to-end system
processing during requirements analysis.

The notation used in Data-flow models represents functional processing (rounded rectangles),
data stores (rectangles) and data movements between functions (labelled arrows).

Figure: Data-flow model of the insulin pump

Diabetes is a relatively common condition where the human pancreas is unable to produce
sufficient quantities of a hormone called insulin. Insulin metabolises glucose in the blood.
The conventional treatment of diabetes involves regular injections of genetically engineered
insulin.

Diabetics measure their blood sugar levels using an external meter and then calculate the dose
of insulin that they should inject.

The problem with this treatment is that the level of insulin in the blood does not just depend
on the blood glucose level but is a function of the time when the insulin injection was taken.

This can lead to very low levels of blood glucose (if there is too much insulin) or very high
levels of blood sugar (if there is too little insulin).

Low blood sugar is, in the short term, a more serious condition, as it can result in temporary
brain malfunctioning and, ultimately, unconsciousness and death.

In the long term, continual high levels of blood sugar can lead to eye damage, kidney
damage, and heart problems.

Current advances in developing miniaturised sensors have meant that it is now possible to
develop automated insulin delivery systems. These systems monitor blood sugar levels and
deliver an appropriate dose of insulin when required.

Insulin delivery systems like this already exist for the treatment of hospital patients. In the
future, it may be possible for many diabetics to have such systems permanently attached to
their bodies.

A software-controlled insulin delivery system might work by using a micro-sensor embedded

in the patient to measure some blood parameter that is proportional to the sugar level. This is
then sent to the pump controller. This controller computes the sugar level and the amount of
insulin that is needed. It then sends signals to a miniaturised pump to deliver the insulin via a
permanently attached needle.

Figure above is a data-flow model that illustrates how an input blood sugar level is
transformed to a sequence of pump control commands.

There are two high-level dependability requirements for this insulin pump system:

1. The system shall be available to deliver insulin when required.

2. The system shall perform reliably and deliver the correct amount of insulin to counteract
the current level of blood sugar.

Failure of the system could, in principle, cause excessive doses of insulin to be delivered and
this could threaten the life of the user. It is particularly important that overdoses of insulin
should not occur.

State machine models

A state machine model describes how a system responds to internal or external events. The
state machine model shows system states and events that cause transitions from one state to
another. It does not show the flow of data within the system.

A state machine model is the most effective way to represent real-time systems which are
often event-driven with minimal data processing.

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.

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.

State diagram of ATM System (Event-driven Modeling)

Case:

ATM is initially turned off. After the power is turned on, ATM performs startup action and
enters Self Test state. If the test fails, ATM goes into Out of Service state, otherwise there is
triggerless transition to the Idle state. In this state ATM waits for customer interaction.

The ATM state changes from Idle to Serving Customer when the customer inserts banking or
credit card in the ATM's card reader. On entering the Serving Customer state, the entry action
readCard is performed. Note, that transition from Serving Customer state back to the Idle
state could be triggered by cancel event as the customer could cancel transaction at any time.
 Fig: State diagram of ATM System

State diagram for the weather station system

Figure below is a state diagram for the weather station system that shows how it responds to
requests for various services.

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

In the Running state, the system expects further messages. If a shutdown() message is
received, the object returns to the shutdown state.

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.
 Figure: Weather station state diagram

If a reportStatus() message is received, the system moves to the Testing state, then the
Transmitting state, before returning to the Running state.

If a signal from the clock is received, the system moves to the Collecting state, where it
collects data from the instruments. Each instrument is instructed in turn to collect its data
from the associated sensors.

If a remoteControl() message is received, the system moves to a controlled state in which it

responds to a different set of messages from the remote control room. These are not shown on
this diagram.

Model-driven engineering:

Model-driven engineering originated from model-driven architecture (MDA), a new software

development paradigm introduced by the Object Management Group (OMG) in 2001.

An approach to software development known as "model-driven engineering" (MDE) uses

models as the main product of the process rather than codes.
Model-driven engineering is an approach to software development in which a system is
represented as a set of models that can be automatically transformed to executable code.

Model-driven architecture is a model-focused approach to software design and

implementation that uses a sub-set of UML models to describe a system.

The programs that execute on a hardware/software platform are then generated automatically
from the models.

Proponents of MDE say that it enhances abstraction in software engineering. so that

engineers no longer have to be concerned with programming language details or the specifics
of execution platforms.

Software tools for model-driven engineering include:

i) AADL: AADL is used to model the software and hardware architecture of an

embedded, real-time system. Due to its emphasis on the embedded domain,
AADL contains constructs for modeling both software and hardware. This
architecture model can then be used either as a design documentation, for analyses
or for code generation like UML.
ii) Acceleo: Acceleo allows: code generation from any kind of metamodel
compatible with EMF (Eclipse Modeling Framework) like UML 1, UML 2 and
generation of any textual language (C, Java, Python, etc.)
iii) Etc………….

Model-driven engineering and model-driven architecture are often seen as the same thing.
But MDA focuses on the design and implementation stages of software development whereas
MDE is concerned with all aspects of the software engineering process. (model-based
requirements engineering, software processes for model-based development, and model-
based testing are part of MDE but not, currently, part of MDA.)

Model-based engineering is still in its early stages of development, and its impact on software
engineering practice remains uncertain.

The techniques have been used successfully in the development of large, long-lifetime
software systems such as air traffic management systems.

MDE good aspect

 MDE allows engineers to think about systems at a high level of abstraction, without
concern for the details of their implementation.
 This reduces the likelihood of errors, speeds up the design and implementation process,
and allows for the creation of reusable, platform-independent application models.
 By using powerful tools, system implementations can be generated for different platforms
from the same model. Therefore, to adapt the system to some new platform technology, it
is only necessary to write a translator for that platform. When this is available, all
platform-independent models can be rapidly rehosted on the new platform.
MDE bad aspect

It does not always follow that the abstractions that are supported by the model are the right
abstractions for implementation.

Model-driven architecture (MDA)

OMG (Object Management Group) literature speaks of three levels of abstraction, or

architectural viewpoints: the Computation-independent Model (CIM), the Platform-
independent model (PIM), and the Platform-specific model (PSM).

The CIM also called domain models describes a system conceptually i.e models the important
domain abstractions used in the system. CIM reflect the different views of the system. Example,
security CIM.

The PIM describes the computational aspects of a system without reference to the
technologies that may be used to implement it. PIM models the operation of the system
without reference to its implementation. The PIM is usually described using UML models
that show the static system structure and how it responds to external and internal events.

The PSM provides the technical details necessary to implement the system.

From a high-level platform independent model it is possible, in principle, to generate a

working program without manual intervention.

Figure: MDA transformations

Transformations between these above models may be defined and applied automatically by
software tools.
A transformation is applied to the PSM to generate executable code that runs on the
designated software platform.

At the time of writing, automatic CIM to PIM translation is still at the research prototype
stage. It is unlikely that completely automated translation tools will be available in the near
future. Human intervention, indicated by a stick figure in figure above, will be needed for the
foreseeable future.

The translation of PIMs to PSMs is more mature and several commercial tools are available
that provide translators from PIMs to common platforms such as .NET and J2EE. There
may be several PSMs for each PIM in the system.

Figure: Multiple platform-specific models

In some cases (e.g., for user interface generation), completely automated PIM to PSM
translation may be impossible.

Architectural design:

Large systems are typically divided into sub-systems that offer related services.
Architectural design is the first design process that identifies these sub-systems and creates
a framework for sub-system control and communication.

The output of design process is a description of the software architecture which represents a
critical link between the design and requirements engineering processes.

Architectural design involves creating a framework that identifies system components and
their interactions (communication).

Advantages of designing and documenting a software architecture:

1) Stakeholder communication: The architecture provides a high-level overview of the

system and can guide discussions among stakeholders.
 2) System analysis: Explicitly defining the system architecture during early
development demands analysis. Decisions made in architectural design have a
significant impact on whether the system can achieve essential needs such as
effectiveness, dependability, and durability.

A system architecture model is compact and manageable. Description of how a system is

organized and how its components interact, systems with comparable requirements frequently
use the same system design and so can facilitate large-scale program reuse.

Software architecture serves as a framework for negotiating system requirements and

structuring interactions with clients, engineers, and management.

This tool is vital for managing complexity. Designers can focus on crucial system
abstractions by removing unnecessary details.

System architecture impacts performance, resilience (capacity to recover quickly),

distributability, and maintainability of a system.

The impact of architectural design on the non-functional system requirements:

1) Performance: If performance is a critical requirement, the architecture should be

designed to localise critical operations within a small number of subsystems, with as
little communication as possible between these sub-systems.
2) Security: If security is a critical requirement, a layered structure for the architecture
should be used, with the most critical assets protected in the innermost layers and with
a high level of security validation applied to these layers.
3) Safety: If safety is a critical requirement, the architecture should be designed so that
safety-related operations are all located in either a single sub-system or in a small
number of sub-systems. This reduces the costs and problems of safety validation and
makes it possible to provide related protection systems.
4) Availability: If availability is a critical requirement, the architecture should be
designed to include redundant components and so that it is possible to replace and
update components without stopping the system.

Architectural decomposition is necessary to structure and organise the specification.

Architecture design consist of:

Sub-system development: The subsystems found during system design are put into practice
during sub-system development. For certain subsystems, this can entail initiating a new
system engineering process; alternatively, if the subsystem is software, it might entail
initiating a software process that encompasses requirements, design, implementation, and
testing.
A sub-system design is an abstract decomposition of a system into large-grain components,
each of which may be a substantial system in its own right. Block diagrams are often used to
describe sub-system designs where each box in the diagram represents a sub-system. Boxes
within boxes indicate that the sub-system has itself been decomposed to sub-systems.

Arrows mean that data and or control signals are passed from sub-system to sub-system in the
direction of the arrows. Block diagrams present a high-level picture of the system structure,
which people from different disciplines who are involved in the system development process
can readily understand.

Sub-systems are usually developed in parallel.

Systems integration: Systems integration involves combining independently designed

components to form a full system. Integration can use a 'big bang' approach, integrating all
sub-systems simultaneously at the same time.

But for technical and managerial purposes, an incremental integration process where sub-
systems are integrated one at a time is the best approach.

Architecture of an air traffic control system: Figure below shows the architecture of a
much larger system for air traffic control. Several major sub-systems shown are themselves
large systems. The arrowed lines that link these systems show information flow between
these sub-systems.
 Figure: An architectural model of an air traffic control system

An abstract model of the architecture for a packing robot system: This robotic

system can pack different kinds of object. It uses a vision sub-system to pick out objects on a
conveyor, identify the type of object and select the right kind of packaging. The system then
moves objects from the delivery conveyor to be packaged.

It places packaged objects on another conveyor.

 Figure: Block diagram of a packing robot control system

Architecture of an alarm system

Movement sensors: Detects movement in the rooms monitored by the system

Door sensors: Detects door opening in the external doors of the building

Alarm controller: Controls the operation of the system

Siren: Emits an audible warning when an intruder is suspected

Voice synthesizer: Synthesises a voice message giving the location of the suspected intruder

Telephone caller: Makes external calls to notify security, the police, etc.
 Figure: A simple burglar alarm system

Architectural design decisions

Architectural design is a creative process where you try to establish a system organization
that will satisfy the functional and non-functional system requirements.

System architects must make crucial decisions during the architectural design process that
impact the system's evolution.

Architectural design decisions have to answer the following fundamental questions:

 Is there a generic application architecture that can act as a template for the system that is
being designed?
 How will the system be distributed across a number of processors?
 What architectural style or styles are appropriate for the system?
 What will be the fundamental approach used to structure the system?
 How will the structural units in the system be decomposed into modules?
 What strategy will be used to control the operation of the units in the system?
 How will the architectural design be evaluated?
 How should the architecture of the system be documented?

The product of the architectural design process is an architectural design document. This may
include a number of graphical representations of the system along with associated descriptive
text. It should describe how the system is structured into sub-systems, the approach adopted
and how each sub-system is structured into modules. The graphical models of the system
present different perspectives on the architecture. Architectural models that may be
developed may include:
 A static structural model that shows the sub-systems or components that are to be
developed as separate units.
 A dynamic process model that shows how the system is organised into processes at run-
time. This may be different from the static model.
 An interface model that defines the services offered by each sub-system through its public
interface.
 Relationship models that shows relationships, such as data flow, between the sub-
systems.
 A distribution model that shows how sub-systems may be distributed across computers.

Architectural views

Architectural models of a software system can be used to focus discussion about the software
requirements or design.

Although it can be used as a basis for more comprehensive design and execution, and for the
future evolution of the system, architectural models can have two relevant issues:

1) What views or perspectives are useful when designing and documenting a system’s
architecture?
2) What notations should be used for describing architectural models?

It is impossible to represent all relevant information about a system’s architecture in a single

architectural model, as each model only shows one view or perspective of the system.

An architecture model depicts the breakdown of a system into modules, the interactions
between run-time processes, and the distribution of system components throughout a
network. All of them are useful at different times, hence, in both design and documentation,
you frequently need to give multiple views of the software architecture.

Krutchen's (1995) 4+1 perspective model of software architecture proposes four essential
architectural views, which are related using use cases or scenarios.

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 run-time, the system is composed of interacting
processes. This view is useful for making judgments about nonfunctional 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. This view is useful for software managers
and programmers.
 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.
5) Conceptual view. This view is an abstract view of the system that can be the basis for
decomposing high-level requirements into more detailed specifications, help
engineers make decisions about components that can be reused, and represent a
product line rather than a single system. Figure above, which describes the
architecture of a packing robot, is an example of a conceptual system view.

Architectural patterns

Architectural patterns may also be possible to associate with Architectural views.

Architectural patterns were proposed in the 1990s under the name ‘architectural styles’.

These are the reusable solutions to commonly occurring architectural problems. They capture
the essence of proven architectural design principles and practices to address specific
concerns in system design. Architectural patterns provide high-level guidelines and templates
for designing the overall structure and organization of software systems.

An architectural pattern can be understood as an abstracted, stylized representation of best

practices that have been tried and tested in many environments and systems. So, an
architectural pattern should describe a system organization that has been successful in
previous systems.

Architectural patterns should include information of when it is and is not appropriate to use
that pattern, and the pattern’s strengths and weaknesses.

The architecture of a software system may be based on a particular architectural pattern or

style. A system organization, such as a layered architecture or client-server organization,
is described by an architectural pattern.

Architectural patterns describe the architecture utilized in various software systems. When
making architectural decisions, it's important to understand typical patterns, their application,
and their strengths and limitations of a system.

Figure below shows a well-known Model-View-Controller pattern, which is the graphical

models of the architecture associated with the MVC pattern.
 Figure (a): The organization of the MVC (conceptual view)

Figure (b): Web application architecture using the MVC pattern (possible run-time
architecture)
This above MVC pattern is the basis of interaction management in many web-based systems.

Figure (b) above shows the architecture of a web-based application system organized using
the MVC pattern.

The MVC pattern, shown in Figure above, separates elements of a system, allowing them to
change independently. For example, adding a new view or changing an existing view can be
done without any changes to the underlying data in the model.

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.

a) Layered architecture: The layered architecture pattern is another way of achieving

separation and independence.

Figure: The architecture of the LIBSYS system

The above library system allows controlled electronic access to copyright material from a
group of university libraries. This has a five-layer architecture, with the bottom layer being
the individual databases in each library.

Organizes the system into layers with related functionality associated with each layer. A layer
provides services to the layer above it so the lowest-level layers represent core services that
are likely to be used throughout the system.

Here, the system functionality is organized into separate layers, and each layer only relies on
the facilities and services offered by the layer immediately beneath it.

This layered approach supports the incremental development of systems. As a layer is

developed, some of the services provided by that layer may be made available to users.

When used Used when building new facilities on top of existing systems; when the
development is spread across several teams with each team responsibility for a layer of
functionality; when there is a requirement for multi-level security.

Advantages Allows replacement of entire layers so long as the interface is maintained.

Redundant facilities (e.g., authentication) can be provided in each layer to increase the
dependability of the system.

Disadvantages In practice, providing a clean separation between layers is often difficult

and a high-level layer may have to interact directly with lower-level layers rather than
through the layer immediately below it. Performance can be a problem because of multiple
levels of interpretation of a service request as it is processed at each layer.

b) Client–server architecture: A system that follows the client–server pattern is organized

as a set of services and associated servers, and clients that access and use the services.

The major components of this model are:

1) A set of servers that offer services to other components. Examples of servers include
print servers that offer printing services, file servers that offer file management
services, and a compile server, which offers programming language compilation
services.
2) A set of clients that call on the services offered by servers. There will normally be
several instances of a client program executing concurrently on different computers.
3) A network that allows the clients to access these services. Most client–server systems
are implemented as distributed systems, connected using Internet protocols.
Figure below is an example of a film and video/DVD library organized as a client–server
system.
When used Used when data in a shared database has to be accessed from a range of
locations. Because servers can be replicated, may also be used when the load on a system
is variable.
Advantages The principal advantage of this model is that servers can be distributed
across a network. General functionality (e.g., a printing service) can be available to all
clients and does not need to be implemented by all services.
Disadvantages Each service is a single point of failure so susceptible to denial of
service attacks or server failure. Performance may be unpredictable because it depends on
the network as well as the system. May be management problems if servers are owned by
different organizations.

Figure: A client-server architecture for a film library

This is a multi-user, web-based system for providing a film and photograph library. In
this system, several servers manage and display the different types of media. Video
frames need to be transmitted quickly and in synchrony but at relatively low resolution.
They may be compressed in a store, so the video server can handle video compression
and decompression in different formats. Still pictures, however, must be maintained at a
high resolution, so it is appropriate to maintain them on a separate server.

The catalog must be able to deal with a variety of queries and provide links into the web
information system that includes data about the film and video clips, and an e-commerce
system that supports the sale of photographs, film, and video clips.

The client program is simply an integrated user interface, constructed using a web
browser, to access these services.
 The most important advantage of the client–server model is that it is a distributed
architecture. Effective use can be made of networked systems with many distributed
processors. It is easy to add a new server and integrate it with the rest of the system or to
upgrade servers transparently without affecting other parts of the system.

Application architectures

Application architectures refer to the structural design of software applications, which

includes the different components, modules, and interactions that comprise the application.
There are various common software architectures, each with merits and cons.

Application architecture introduces architectural models for specific classes of application

software systems.

Web Application Design

Mobile Application Design