Unit 3

System Models

• Context Models – Interaction model – Structural models –

Behavioral models – Model-driven engineering – Architectural
design decisions – Architectural views – Patterns – Application
Architectures – Object Oriented Design using UML – Design
Patterns – Implementation issues – Software Reuse.
System Models

• System modeling is the process of developing abstract models of a system,

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

• System modeling has generally come to mean representing the system

using some kind of graphical notation, which is now almost always based on
notations in the Unified Modeling Language

• Models are used during the requirements engineering process to help derive
the requirements for a system, during the design process to describe the
system to engineers implementing the system and after implementation to
document the system’s structure and operation.
System Models

• Developing different models to represent the system from different

perspectives.

• For example:
1. An external perspective, where you model the context or environment of the system.

2. An interaction perspective where you model the interactions between a system

and its environment or between the components of a system.

3. A structural perspective, where you model the organization of a system or the

structure of the data that is processed by the system.

4. A behavioral perspective, where you model the dynamic behavior of the system

and how it responds to events.

Context models

• you should decide on the system boundaries. This involves working with system
stakeholders to decide what functionality should be included in the system and
what is provided by the system’s environment.

• You may decide that automated support for some business processes should be
implemented but others should be manual processes or supported by different
systems.

• You should look at possible overlaps in functionality with existing systems and
decide where new functionality should be implemented.

• These decisions should be made early in the process to limit the system costs and
the time needed for understanding the system requirements and design.
Context models

• For example, say you are developing the specification for the patient
information system for mental healthcare.

• This system is intended to manage information about patients attending

mental health clinics and the treatments that have been prescribed.

• In developing the specification for this system, you have to decide whether
the system should focus exclusively on collecting information about
consultations (using other systems to collect personal information about
patients) or whether it should also collect personal patient information.

• The advantage of relying on other systems for patient information is that you
avoid duplicating data.
Context models
Interaction models

• All systems involve interaction of some kind.

• This can be user interaction, which involves user inputs and outputs,
interaction between the system being developed

• other systems or interaction between the components of the system.

• Modeling user interaction is important as it helps to identify user

requirements.

• Modeling system to system interaction highlights the communication

problems that may arise.
Interaction models

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

Interaction models - Use case modeling

• Use case modeling was originally developed by Jacobson et al. (1993) in

the 1990s
Interaction models - Use case modeling
Actor

• Someone interacts with use case (system function).

• Named by noun.

• Actor plays a role in the business

• Similar to the concept of user, but a user can play different roles

• For example:
• A prof. can be instructor and also researcher
• plays 2 roles with two systems

• Actor triggers use case(s).

• Actor has a responsibility toward the system (inputs), and Actor has expectations from the system (outputs).
Interaction models - Use case modeling
Use Case

• System function (process - automated or manual)

• Named by verb + Noun (or Noun Phrase).

• i.e. Do something

• Each Actor must be linked to a use case, while some use cases may not be linked to actors..
Interaction models - Use case modeling
Communication Link

• The participation of an actor in a use case is shown by connecting an actor to a use

case by a solid link.

• Actors may be connected to use cases by associations, indicating that the actor and
the use case communicate with one another using messages.
Interaction models - Use case modeling
Boundary of system

• The system boundary is potentially the entire system as defined in the

requirements document.

• For large and complex systems, each module may be the system boundary.

• For example, for an ERP system for an organization, each of the modules such as
personnel, payroll, accounting, etc.

• can form a system boundary for use cases specific to each of these business
functions.

• The entire system can span all of these modules depicting the overall system
boundary
Interaction models - Use case modeling
Include Relationship

• The include relationship adds additional functionality not specified in the base use case.

• The <<Include>> relationship is used to include common behavior from an included use case into a base
use case in order to support the reuse of common behavior.
Interaction models - Use case modeling
Extend Relationship

• The extend relationships are important because they show optional functionality or system behavior.

• The <<extend>> relationship is used to include optional behavior from an extending use case in an
extended use case.
Interaction models - Use case modeling
Generalization Relationship

• A generalization relationship means that a child use case inherits the behavior and meaning of the parent
use case.

• The child may add or override the behavior of the parent.

• The figure below provides a use case example by showing two generalization connectors that connect
between the three use cases.
Interaction models - Sequence diagrams
• The sequence diagram represents the flow of messages in the system and is also termed as an event
diagram.

• It helps in envisioning several dynamic scenarios.

• Sequence diagrams are particularly useful for depicting the dynamic behavior of a system and how
different components collaborate to achieve a specific task or goal.

• They are commonly used during the design and documentation phases of software development.
Interaction models - Sequence diagrams
Key elements and concepts in a sequence diagram include:

• Lifelines: These represent the individual objects or components involved in the interaction. Each lifeline is
typically depicted as a vertical line, and their names are often placed at the top of these lines.
Interaction models - Sequence diagrams
Key elements and concepts in a sequence diagram include:

Messages:

• These are the horizontal arrows or lines that connect lifelines, indicating
the order of messages passed between objects.

• Messages can be synchronous (blocking) or asynchronous (non-blocking),

and they typically have labels that describe the action or method being
invoked.
• As shown in the activation bars example, a synchronous message is used
when the sender waits for the receiver to process the message and return
before carrying on with another message.

• An asynchronous message is used when the message caller does not wait
for the receiver to process the message and return before sending other
messages to other objects within the system.
Interaction models - Sequence diagrams
Key elements and concepts in a sequence diagram include:

Return Message:

A return message is used to indicate that the message receiver is done processing the message and
is returning control over to the message caller. Return messages are optional notation pieces, for an
activation bar that is triggered by a synchronous message always implies a return message.
Interaction models - Sequence diagrams
Key elements and concepts in a sequence diagram include:

Activation Bars:

• These represent the period during which an object is active and processing a message.

• They are depicted as a box or vertical rectangle on the lifeline and show the duration of the object’s
involvement in the interaction.
Interaction models - Sequence diagrams
Structural models

• Structural models of software display the organization of a system in terms

of the components that make up that system and their relationships.

• Structural models may be static models, which show the structure of the
system design or dynamic models, which show the organization of the
system when it is executing.

• These are not the same things—the dynamic organization of a system as a

set of interacting threads may be very different from a static model of the
system components.

• Structural models of a system is created when you are discussing and

designing the system architecture.
Structural models

• Structural UML diagrams illustrate the organization of a system by depicting

its components, such as classes, objects, and packages.

• They represent the elements that make up the system and the relationships
between them.
Structural models
Behavioral models

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

• These stimuli may be either data or events:

1. Data becomes available that has to be processed by the system. The availability of the data
triggers the processing.

2. An event happens that triggers system processing. Events may have associated data,
although this is not always the case.
Behavioral models - Data-driven modeling

• Data-driven models show the sequence of actions involved in processing

input data and generating an associated output.

• They can be used during the analysis of requirements as they show end-to-
end processing in a system.

• That is, they show the entire sequence of actions that takes place from an
initial input being processed to the corresponding output, which is the
system’s response.
Behavioral models - Data-driven modeling
Behavioral models - Event-driven modeling

• Event-driven modeling shows how a system responds to external and

internal events.

• It is based on the assumption that a system has a finite number of states

and that events (stimuli) may cause a transition from one state to another
Behavioral models - Event-driven modeling
Behavioral models - Event-driven modeling
Model-Driven Engineering (MDE)

• Model-Driven Engineering (MDE) is an approach in software engineering

that focuses on using models as a primary artifact throughout the entire
software development lifecycle.

• Instead of traditional methods where code is the primary artifact, MDE

emphasizes the use of high-level, abstract models to design, analyze, and
generate software systems.
Key concepts and components of Model-Driven
Engineering include:

• Models: Models in MDE are abstract representations of a system, capturing its

structure, behavior, and other relevant aspects. These models can be created using
various modeling languages (e.g., Unified Modeling Language - UML) and tools.

• Metamodels: Metamodels define the syntax and semantics of modeling languages.

They provide a formal specification of how models in a particular language should
be structured. Metamodels are crucial for ensuring consistency and interoperability
in model-driven approaches.
Architectural design

• Architectural design decisions

• Architectural views

• Architectural patterns

• Application architectures
Architectural design

• Architectural design is concerned with understanding how a system should

be organized and designing the overall structure of that system

• It is the critical link between design and requirements engineering, as it

identifies the main structural components in a system and the relationships
between them.

• The output of the architectural design process is an architectural model that

describes how the system is organized as a set of communicating
components.
Architectural design
• This shows an abstract model of the architecture for a
packing robot system that shows the components that have to
be developed.
• This robotic system can pack different kinds of object.

• It uses a vision component 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.
• The architectural model shows these components and the links
between them.
Architectural design
• You can design software architectures at two levels of abstraction, architecture in the
small and architecture in the large:

1. Architecture in the small is concerned with the architecture of individual programs. At

this level, we are concerned with the way that an individual program is decomposed
into components.

2. Architecture in the large is concerned with the architecture of complex enterprise

systems that include other systems, programs, and program components. These
enterprise systems are distributed over different computers, which may be owned and
managed by different companies.
Three advantages of explicitly designing and
documenting software architecture:
1. Stakeholder communication:

• The architecture is a high-level presentation of the system that may be used as a focus for discussion by
a range of different stakeholders.

2. System analysis:

• Making the system architecture explicit at an early stage in the system development requires some
analysis.

• Architectural design decisions have a profound effect on whether or not the system can meet critical
requirements such as performance, reliability, and maintainability.

3. Large-scale reuse:

• A model of a system architecture is a compact, manageable description of how a system is organized and
how the components interoperate.

• The system architecture is often the same for systems with similar requirements and so can support
large-scale software reuse.
Architectural design decisions

• Architectural design is a creative process where you design a system organization

that will satisfy the functional and non-functional requirements of a system.

• the activities within the process depend on the type of system being developed, the
background and experience of the system architect, and the specific requirements
for the system.

• During the architectural design process, system architects have to make a number
of structural decisions that profoundly affect the system and its development
process.
Architectural design decisions - Fundamental questions about the system:

1. Is there a generic application architecture that can act as a template for the system

that is being designed?

2. How will the system be distributed across a number of cores or processors?

3. What architectural patterns or styles might be used?

4. What will be the fundamental approach used to structure the system?

5. How will the structural components in the system be decomposed into subcomponents?

6. What strategy will be used to control the operation of the components in the system?

7. What architectural organization is best for delivering the non-functional requirements

of the system?

8. How will the architectural design be evaluated?

9. How should the architecture of the system be documented?

Architectural design decisions:
Relationship between non-functional requirements and software architecture

• There is a relationship between non-functional requirements and software

architecture

• The particular architectural style and structure that you choose for a system
should depend on the non-functional system requirements:
• Performance

• Security

• Safety

• Availability

• Maintainability
Architectural views

• For design and documentation, you usually need to present multiple views
of the software architecture.

• There are different opinions as to what views are required.

• Krutchen (1995), in his well-known 4+1 view model of software architecture,

suggests that there should be four fundamental architectural views
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 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.
Architectural patterns

• The idea of patterns as a way of presenting, sharing, and reusing knowledge about
software systems is now widely used.

• There are various ways to organize the components in software architecture. And
the different predefined organization of components in software architectures are
known as software architecture patterns.

• Layered architecture

• Repository architecture

• Client–server architecture

• Pipe and filter architecture

Architectural patterns - Layered architecture

• As the name suggests, components(code) in this pattern are separated into

layers of subtasks and they are arranged one above another.

• Each layer has unique tasks to do and all the layers are independent of one
another. Since each layer is independent, one can modify the code inside a
layer without affecting others.

• It is the most commonly used pattern for designing the majority of software.
This layer is also known as ‘N-tier architecture’..
Layered architecture - A generic layered architecture
Layered architecture – The architecture of the LIBSYS system
Architectural patterns - Repository architecture

• The majority of systems that use large amounts of data are organized
around a shared database or repository.

• This model is therefore suited to applications in which data is generated by

one component and used by another.

• Examples of this type of system include command and control systems,

management information systems, CAD systems, and interactive
development environments for software
Architectural patterns - A repository architecture for an IDE
Architectural patterns - Client–server architecture

• The client-server pattern has two major entities. They are a server and
multiple clients.

• Here the server has resources(data, files or services) and a client requests
the server for a particular resource. Then the server processes the request
and responds back accordingly.
Architectural patterns - A client server architecture for a film library
Architectural patterns – An example of the pipe and filter architecture
Architectural patterns - Pipe and filter architecture
• This is a model of the run-time organization of a system where functional transformations process
their inputs and produce outputs.

• Data flows from one to another and is transformed as it moves through the sequence.

• Each processing step is implemented as a transform.

• Input data flows through these transforms until converted to output.

• The transformations may execute sequentially or in parallel.

• The data can be processed by each transform item by item or in a single batch.

• The term ‘filter’

• The name ‘pipe and filter’ comes from the original Unix system where it was possible to link
processes using ‘pipes’. These passed a text stream from one process to another.

• The term ‘filter’ is used because a transformation ‘filters out’ the data it can process from its inpu
data stream.
Application Architectures
• This is a model of the run-time organization of a system where functiona
transformations process their inputs and produce outputs.

• Data flows from one to another and is transformed as it moves through the sequence.

• Each processing step is implemented as a transform.

• Input data flows through these transforms until converted to output.