Chapter 6 AD

SOFTWARE ENGINEERING
| Artichectural Design
Chapter 6
• PUNTLAND STATE UNIVERSITY

• Faculty of Computer Science/IT
• Eng: Adnan Mohamed Hassan
• adnaan.mohamed@psu.edu.so
Class : 2021 Batch

Content: Chapter 6 - Architectural Design
Period: Class 2 hr and 50 minutes
Date: july 9th 2023
1
Topics covered
Architectural Design Decision
Architectural Views
Architectural Patterns
Application Architectures
Chapter 6 Architectural Design

2
Software
Architecture
Software
Architecture
Output
Design Process
Architectural Design Output

The design process for identifying The output of this design process
sub-systems to make a system is the description of the software
and framework for sub-systems architecture
control and communication

3
Architectural
Design
System Design Process
1
Architectural Design is the early stage of the
system design process Architectural Design
2
Architectural Design represents the link
Architectural Design
between specification and design process
3 4
Often carried out in parallel with some It involves Identifying major system
specification activities components and their communications

4
The architecture of a packing robot
control system
Vision system
Object
identification Gripper
Arm Controller
system Controller
Packaging
selection
system
Packaging Conveyer
system
controller

5
Architectural abstraction
Architecture
In the large In the small

 Is concerned with architecture  Is concerned with architecture
of complex enterprise systems of individual programs
 Includes other systems,  At this level, we are
programs and components concerned with the way that
 These enterprise systems are an individual program is
distributed over different decomposed into components
computers, which may be
owned and managed by
different companies

6
Advantages of explicit architecture
Stakeholder Communication
 Architecture may be used as a focus of discussion by system
stakeholders
System Analysis
 Means that analysis of whether the system can meet its non-
functional requirements is possible
Large-scale reuse
 The architecture may be reusable across a range of systems
 Product-line architectures may be developed

7
Architectural representations
Block Diagram for Data curation layer
Real-time Data
Labelling
Advantages Limitations
 It is simple to Data Analysis  But these have been
understand criticized because they
 Informal block lack semantics, do
diagrams showing Data Representation not show the types of
Data Preservance
entities and and mapping relationships between
relationships are the entities nor the visible
most frequently used properties of entities in
method for the architecture
Hadoop File System
documenting software
architectures
Dependency
 Depends on the use of architectural
models. The requirements for
model semantics depends on how
the models are used

http://www.miningminds.re.kr/data-curation/ 8
Box and line diagrams
Definition and Abstract

 Very abstract ‐ they do not
show the nature of component
relationships nor the externally
visible properties of the sub‐
systems
 However, useful for
communication with stakeholders
and for project planning.

http://www.miningminds.re.kr/data-curation/ 9
Use of architectural models
System
Design
Facilitating discussion Facilitating documentation

 As a way of facilitating discussion  As a way of documenting an
about the system design architecture that has been designed
 A high-level Architectural view of a  The aim here is to produce a
system is useful for communication complete system model that shows
with stakeholders and project the different components in a system,
planning because it is not cluttered their interfaces and their
with detail connections.
 Stakeholders can relate to it and
understand an abstract view of the
system. They can then discuss
the system as a whole without
being confused by detail.

10
Architectural design decisions
Creative Process
 Architectural design is a creative process so the process
differs depending on the type of system being developed
Design Decision
 A number of common decisions span all design processes and
these decisions affect the non-functional characteristics of the
system

11
Architectural design decisions
3 2 1
What Is there a generic
How will the
architectural application
system be
styles are architecture that
distributed?
appropriate? can be used?
4 8
What approach How should the
will be used to Decisions architecture
structure the be
system? documented?
5 6 7
How will the How will the
What control
system be
strategy should
decomposed architectural
be used?
into modules? design be
evaluated?

12
Architecture reuse
Systems in same domain have similar

architectures that reflect domain concepts.
Domain
Similarity
Requirement
Similarity
Application product lines are built
around a core architecture with Architectural
variants that satisfy particular Patterns and
style similarity
customer requirements
 The architecture of a system may be designed

around one of more architectural patterns or ‘styles’
 These capture the essence of an architecture
Chapter 6 and can beDesign
Architectural instantiated in different ways 13
Architecture and system characteristics
Performance
 Localize critical operations and minimize
communications. Use large rather than
fine-grain components
Security
 Use a layered architecture with critical
assets in the inner layers
Safety
System  Localize Safety-critical features in a
Characteristics small number of sub-systems
Availability
 Include redundant components and
mechanisms for fault tolerance
Maintainability
 Use fine-grain, replaceable
components
Chapter 6 Architec tural Design 14

Architectural views
 What views or perspectives are useful when

Views and designing and documenting a system’s architecture.
 What notations should be used for describing
architectural models?
Prospectiv
e  Each architectural model only shows a single view
or prospective of the system
It might show how a system is decomposed
into modules,
how the run-time processes interact or the
Single different ways in which system components are
View distributed across a network.
For both design and documentation, you
usually need to present multiple views of the
software architecture

15
4 + 1 view model of software architecture
Logical View
Process View
Which Shows the key
Which Shows how, at
abstractions in the
run-time, the system is
system as objects or
composed of interacting
object classes
processes.
4 + 1 Views
Physical View
Development View
which shows the system
hardware and how which shows how the
software components are software is
distributed across the decomposed for
processors in the system development
Related using use cases or scenarios (+1)

16
Architectural patterns
Architectural Patterns
Definition Stylized Description Include Information Representation
Patterns are a Architectural Pattern Patterns should Patterns may be

means of is a stylized include information represented using
 representing description of good about when they tabular and
 sharing design practice, are and when they graphical
 reusing which has been tried are not useful descriptions.
of knowledge and tested in
different
environments

17
The Model-View-Controller (MVC) pattern
Description When Used?

Separates presentation and
interaction from system data.
When: There are multiple ways to
Model Component: Manages system data
and associated operation on data.
view and interact with data.
View Component: defines and manages
When: the future requirements for
how the data is presented to the user. Example interaction and presentation of
Controller Component: manages user
interaction (e.g., key presses, mouse data are unknown.
clicks, etc.) and passes these interactions
to the View and the Model
Advantages Disadvantages
See slide No 19
 Allows the data to change
independently of its representation  Can involve additional code
and vice versa.  Code complexity increase when
 Supports presentation of the same the data model and interactions
data in different ways with are simple
changes made in one
representation shown in all of
them.
18
The organization of the Model-View-Controller
Controller View
 Maps user actions View Selection  Renders model
to model updates  Requests model
 Selects view updates
User Events  Sends user events
to controller
Change Notification
State Change
State Query
Model
 Encapsulates
application states
 Notifies view of state
changes
Chapter 6 Architectural Design 19

Web application architecture using the MVC pattern
Browser
Controller View
 HTTP request Form to display  Dynamic page
processing generation
 Application-specific  Forms
logic User Events management
 Data validation
Change Notification
Update Request
Refresh request
Model
 Business logic
 Database

Layered architecture
Definitions
Used to model the interfacing of sub-systems
Organizes the system into a set of layers (or abstract machines) each
of which provide a set of services
Supports the incremental development of sub-systems in different

layers. When a layer interface changes, only the adjacent layer is
affected
However, often artificial to structure systems in this way

The Layered architecture pattern

 Organizes the system into layers When: Building the new facilities on
with related functionality top of existing systems.
 Each layer provides services to When: Development spread across
layer above it. several teams, each team is
 The services provided by the responsible for a layer of
lowest layer are considered as Example functionality
core services When: There is requirement for
 The core services are likely to be multi-level security
used through out the system
 Allows replacement of entire  In practice, providing a clean
layers so long as the interfaces separation between layers is often
are maintained. See slide No 23 difficult and a high-level layer may
 Redundant facilities (e.g. have to interact directly with lower-
Authentication) can be provided level layers rather than through the
in each layer to increase the layer immediately below it.
dependency of the system  Multiple level of interpretation of a
service request can decrease the
performance
The generic layered architecture and Mining
Minds architecture
User interface
User interface management

Authentication and authorization
Core business logic/application

functionality system utilities
System support (OS, database

etc.)

The architecture of the LIBSYS system
Web browser interface
LIBSYS Forms and Print

Login query Manager Manager
Distributed Document Rights

Accounting
search retrieval Manager
Library index
DB1 DB2 DB3 DB4 DBn

Key points
 A Software Architectural design Architectures may Architectural

architecture is a decisions include be documented from patterns are means
description of how decisions on several different of reusing
a software  Type of perspectives or knowledge about
system is application views such as generic system
organized  The distribution of  A conceptual view architectures
the system  A logical view  They describe the
 The architectural  A process view architecture
styles to be  A development  Explanation when
used view it may be used
 Describe
advantages and
disadvantages

Repository architecture
Sub-systems must exchange data

(Two Ways)
Central Repository Multiple Repositories

 Shared data is held in  Each sub-system
central database or maintains its
repository own database
 May be accessed by  Passes data explicitly
all sub-systems to others sub-systems
Repository Model
 When large amount of data are to be shared, a Repository Model is most

commonly used
 This is an efficient data sharing mechanism
Chapter 6 Architectural design

26
The Repository pattern

When: You have a system with
 All data in a system is managed large volume of information are
in a central repository. generated
 Accessible to all sub When: You want to store data for
components of the system. long time.
 Components do not interact Example When: there is need some data-
directly, only through the driven systems where the
repository. inclusion of data in the repository
triggers an action or tool
 Components can be independent. See slide No 30
 The repository is a single point
 No need to know of the existence of failure so problems in the
of other components repository affect the whole
 Changes made by one system.
component can be propagated to  May be inefficiencies in
all components. organizing all communication.
 All data can be managed  Distributing repository through
consistently several systems is difficult
27
A repository architecture for an IDE
Code
UML Editor
Generators
Java
Editor
Design
Translator Project Repository
Python
Editor
Design Report
Analyzer Generator

28
Client-server architecture
 Set of stand-alone servers

which provide specific services
 Printing
 Data management
 Set of clients which call on

 Distributed System model these services
which shows how data and
processing is distributed
across a range of
components.
 Can be implemented on a
single computer
 Network which allows

clients to access servers

29
The Client–server pattern

 In a client-server architecture, the When: Data in a shared database
functionality of the system has to be accessed from a range of
organized into services locations.
 Each service delivered from a When: Servers want to replicated
separate server the data
 Clients are users of these services Example When: Load on the system is
and access servers to make use of variable
them
 The principal advantage of this  Each service is a single point of
model is that servers can be failure so susceptible to denial of
distributed across a network. See slide No 33 service attacks or server failure.
 General functionality (i.e.  Performance may be
printing service) can be unpredictable because it depends
available to all clients. on the network as well as the
 Does not need to be system
implemented by all services.  May be management problems if
servers are owned by different
Chapter 6 Architectural design organization. 33
33
A client–server architecture for a film library
Client 1 Client 2 Client 3 Client 4
Library index
Catalogue Video Picture Web

Server Server Server
Server
Library Film Store Photo Store Film and
Catalogue photo info

31
Pipe and filter architecture
Transformations Process
Input Output
Input Output
Pipe
Input Output
 Functional transformations process their inputs to Filter

produce outputs
 May be referred to as a pipe and filter model (as in UNIX
shell).
 Variants of this approach are very common. When
transformations are sequential, this is a batch sequential
model which is extensively used in data processing
systems.
 Not really suitable for interactive systems

32
The pipe and filter pattern

 The processing of the data in a  Commonly used in data
system is organized in a way that processing
processing component (filter) is applications
discrete and carries out one type  Used in both batch-based and
of data transformation transaction-based
 The data flows (pipe) from one Example applications
component to another for  Inputs are processed in separate
processing stages to generate related output.
 Easy to understand and supports  The format for data transfer has to
transformation reuse be agreed upon between
 Workflow style matches the See slide No 36 communicating transformations.
structure of many business  Each transformation must parse its
process input and un-parse its output to
 Evolution by adding the agreed form.
transformations is straightforward.  It increase system overhead
 Can be implemented as either a  It is impossible to reuse
sequential or concurrent system. transformations that use
Chapter 6 Architectural design 3
incompatible data structures 363
6
6
An example of the pipe and filter architecture
Issue Receipts
receipts
Read Issued Identify

Invoices Payments
Find Issue
payments payments Reminders
due reminder
Invoices Payments

34
Application architectures
Application System To meet Organizational Needs

are designed
 As businesses have  A generic application

much in common, their architecture is an
application systems architecture for a type
also tend to have a of software system
common architecture that may be
that reflects the configured and
application adapted to create a
requirements system that meets
specific requirements

35
Use of application architectures
• As a starting point for architectural design
• As a design checklist
• As a way of organizing the work of the evelopment teams
• As a means of assessing components for reuse
• As a vocabulary for talking about application types

36
Examples of application types
Data Processing Transaction Processing Event Processing Language Processing

Applications Applications Applications Applications
 Data driven  Data-centered  Applications  Applications

applications that applications that where system where the users’
process data in process user actions depend intentions are
batches without requests and on interpreting specified in a
explicit user update events from the formal language
intervention during information in a system’s that is processed
the processing system database environment and interpreted by
the system

37
Application type examples
Focus On
Transaction Language
Processing Systems Processing Systems
E-Commerce Systems Reservation Systems Compiler Systems Interpreter Systems

38
Transaction processing systems
Information from database Update database
Process User Request
 Process user requests for information from a database or requests to

update the database.
 From a user perspective a transaction is:
 Any coherent sequence of operations that satisfies a goal;
 For example - find the times of flights from London to Paris.
 Users make asynchronous requests for service which are then
processed by a transaction manager
39
The structure of transaction processing
applications
Application Transaction
I/O Processing Database
Logic Manager

40
The software architecture of an ATM system
Input Process Output
Get customer
Print Details
account id
Query Account
Validate card Return Card

Update
Account
Select Service Dispense Cash
AT Database AT
M M

41
Information systems architecture
Information systems have generic architecture that can be organized

as a layered architecture
These are transaction-based systems as interaction with these

systems generally involves database transactions
Layers Include:
 User Interface
 User Communication
 Information Retrieval
 System Database
http://www.miningminds.re.kr/technical-report/presentations/

42
Layered information system architecture
User interface
Authentication and
User Communication
Authorization
Information retrieval and modification
Transaction Management
Database

43
The architecture of the MHC-PMS
Web browser
Form and
Login Role Checking Data Validation
menu Manager
Security Patient Info. Data Import Report

Management Manager and Generation
Export
Transaction Management
Patient Database

44
Web-based information systems
In form of Shows on
Information Systems Web Applications Browsers
Example of E-Commerce Application

Web-based information systems
 Information and resource management systems are n o

w
usually web-based systems where the user interfaces
are implemented using a web browser.
 For example, e-commerce systems are Internet-based
resource management systems that accept electronic
orders for goods or services and then arrange delivery of
these goods or services to the customer.
 In an e-commerce system, the application-specific a l yer
includes additional functionality supporting a ‘shopping
cart’ in which users can place a number of items in
separate transactions, then pay for them all together in a
single transaction.
Server implementation
These systems are often implemented as multi-tier client server/architectures
The web server is The application The database server

responsible for all server is responsible moves information
user for implementing to and from the
communications, application-specific database and
with the user logic as well as handles transaction
interface information storage management
implemented using and retrieval
a web browser requests
Web Server Application Server Database Server

Language processing systems
Natural Or Artificial language Conversion
 Accept a natural or artificial language as input and generate some

other representation of that language
 May include an interpreter to act on the instructions in the language
that is being processed
 Used in situations where the easiest way to solve a problem is to
describe an algorithm or describe the system data
 Meta-case tools process tool descriptions, method rules, etc and
generate tools

The architecture of a language processing system
Translator
Source
language
Check Syntax
instructions
Check Semantics
Generate
Abstract m/c
instructions
Interpreter
Data Fetch
Execute Results

Compiler components
Lexical Analyzer
It takes input language tokens and
converts them into an internal
form
Symbol Table
It holds information about the names of
entities (variables, classes, objects etc.)
Syntax Analyzer
It checks the syntax of the language
being translated
Syntax Tree
It is the internal structure representing
the program being compiled

A pipe and filter compiler
architecture
Symbol Table
Syntax Tree
Lexical Syntactic Semantic Code

Analysis Analysis Analysis Generation

A repository architecture for a language
processing system
Code Code Code

Generation Generation Generation
Code Abstract Grammar Code

Generation Syntax tree Generation
Definition
Output
Code Symbol Table Code
Definition
Generation Generation
Repository

Discussion
 Discuss the following Architectures
1. Cloud native architecture
2. Cloud-based architecture
3. 3-tier application architecture?

Chapter 6 AD

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 6 AD

Uploaded by

Copyright:

Available Formats

SOFTWARE ENGINEERING

• PUNTLAND STATE UNIVERSITY

Class : 2021 Batch

Architectural Design Decision

Chapter 6 Architectural Design

Architectural Design Output

Chapter 6 Architectural Design

Chapter 6 Architectural Design

Chapter 6 Architectural Design

In the large In the small

Chapter 6 Architectural Design

Chapter 6 Architectural Design

Chapter 6 Architectural Design

Definition and Abstract

Chapter 6 Architectural Design

Facilitating discussion Facilitating documentation

Chapter 6 Architectural Design

Chapter 6 Architectural Design

Chapter 6 Architectural Design

Systems in same domain have similar

 The architecture of a system may be designed

Chapter 6 Architec tural Design 14

 What views or perspectives are useful when

Chapter 6 Architectural Design

Related using use cases or scenarios (+1)

Chapter 6 Architectural Design

Patterns are a Architectural Pattern Patterns should Patterns may be

Chapter 6 Architectural Design

Description When Used?

Chapter 6 Architectural Design 19

Chapter 6 Architectural Design 20

Used to model the interfacing of sub-systems

Supports the incremental development of sub-systems in different

However, often artificial to structure systems in this way

Chapter 6 Architectural Design 21

Description When Used?

User interface management

Core business logic/application

System support (OS, database

Chapter 6 Architectural Design 23

Web browser interface

LIBSYS Forms and Print

Distributed Document Rights

DB1 DB2 DB3 DB4 DBn

Chapter 6 Architectural Design 24

 A Software Architectural design Architectures may Architectural

Chapter 6 Architectural Design 25

Sub-systems must exchange data

Central Repository Multiple Repositories

 When large amount of data are to be shared, a Repository Model is most

Chapter 6 Architectural design

Description When Used?

Chapter 6 Architectural design

 Set of stand-alone servers

 Set of clients which call on

 Network which allows

Chapter 6 Architectural design

Description When Used?

Client 1 Client 2 Client 3 Client 4

Catalogue Video Picture Web

Chapter 6 Architectural design

 Functional transformations process their inputs to Filter

Chapter 6 Architectural design

Description When Used?