Lecture 23, 24, 25 & 26
Architectural Design
Topics covered
l Introduction
l Architectural Design Decisions
l Architectural views
l Architectural Patterns
l Application Architectures
l Conclusion
Software Architecture
l Software architecture encompasses the set of significant
decisions about the organization of a software system
• Selection of the structural elements and their interfaces by which
a system is composed
• Behavior as specified in collaborations among those elements
• Composition of these structural and behavioral elements into
larger subsystem
• Architectural style that guides this organization
l It is important because it affects (Bosch 2000)
• Performance
• Robustness
• Distributability
• Maintainability
Architectural Design
l Architectural Design is concerned with understanding
• How a system should be organized and designing the overall structure
of that system
l It is the first stage in the software design process
l It is the link between design and requirement engineering
l It identifies the main structural components in a system and the
relationships between them
l The output of architectural design process is an architectural
model that describes
• How the system is organized as a set of communicating components
l The architecture is a high-level presentation of a system
• that can be used as a focus for discussion by a range of different
stakeholders
Robot Control System
Vision
System
Object Arm Gripper
Identification Controller Controller
System
Packaging
Selection
System
Packing Conveyor
System Controller
Architectural level of abstraction
l Software architectures are designed at two levels of
abstractions
• Architecture in the small :
• It is concerned with the architecture of individual programs
• At this level individual program is decomposed into components
• Architecture in the large :
• It is concerned with the architecture of complex enterprise systems
that include other systems, programs and program component
• These systems are distributed over different computers, which may
be owned and managed by different companies
Advantages of explicitly designing and
documenting architecture (Bass et al -2003)
l Stakeholder communication
• Architecture is high level presentation
• Architecture may be used as a focus of discussion by system
stakeholders
l System analysis
• Architectural design decisions have a profound effect on
whether or not the system can meet critical requirements :
• Performance
• Reliability
• Maintainability
l Large-scale reuse
• The model of architecture is a compact, manageable description
of how a system organized and the components interoperate
• The system architecture is often the same for systems with
similar requirements
• The architecture may be reusable across a range of systems
Architectural Design Decision
l Architectural Design is a creative process where
• You design a system organization that satisfy the functional and non-functional
requirements of a system
l The considered 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 cores or processors?
• What architectural patterns or styles might be used? – Description of system
organization
• What will be the fundamental approach used to structure the system?
• How will the structural components in the system be decomposed into sub-
components?
• What strategy will be used to control the operation of the components in the
system?
• What architectural organization is best for delivering the non-functional
requirements of the system?
• How will the architectural design be evaluated?
• How should the architecture of the system be documented ?
Architectural Design Decision
l The choice of architectural style and structure
depends on non-functional requirements
• Performance :
• The architecture should be designed to localize critical operations
within a small number of components , with these components all
deployed on the same computer rather than distributed across
network
• It reduce the number of component communication
• You may consider run-time system organizations that allow the
system to be executed on different processors
• Security :
• If the security is critical, a layered structure should be used
• Here the most critical assets are protected in the innermost layers
• The high level of security validation are applied to these layers
Architectural Design Decision
l The choice of architectural style and structure
depends on non-functional requirements
• Safety :
• The architecture should be designed so that safety related
operations are located in either a single component or in a small
number of components
• The system can be safely turned off in the event of failure
• Availability :
• It should be included redundant components so that it is possible to
replace and update components without stopping the system
• Maintainability :
• The system architecture should be designed using fine-grain, self-
contained components that may readily be changed
• Producers of data should be separated from consumers and shared
data structures should be avoided
Architectural View
l The views are used to describe the system from the
viewpoint of different stakeholders, such as
• End-users
• Developers and
• Project managers
l Krutchen (1995) suggested in his very well-known
4+1 view model of software architecture
• It has four fundamental architectural views, which are related
using use cases or scenarios
• Logical view
• Process View
• Development View
• Physical View
• In addition selected use case view or scenarios are used to illustrate
the architecture serving as the 'plus one' view.
Architectural View
Architectural View
l Logical View
• It is concerned with the functionality that the system
provides to the end users
• It shows the parts that comprise the system as well as the
interactions
• It shows the key abstractions in the system as objects or
object classes
• It emphasizes classes and objects
• UML Diagrams to represent the logical view
• Class Diagram
• Object diagram
• Communication Diagram
• Sequence Diagram
• State Diagram
Architectural View
l Process View
• It describes a system’s processes or actions
• It shows any communication between those processes
• It explores what needs to happen inside the system
• It is very helpful when system will have a number of
simultaneous threads or processes
• It is also helpful for making judgments about non-
functional system characteristics such as performance
and availability
• It deals with the dynamic aspects of the system
• UML Diagrams to represent the process view
• Activity Diagram
Architectural View
l Physical View
• It shows the system's execution environment
• It shows the system hardware and how the software
components are distributed across the processors in the
system
• It is useful for systems engineers planning a system
deployment
• UML Diagram to represent the Physical view
• Deployment Diagram
Architectural View
l Development View
• It shows the breakdown of the software into components
that are implemented by a single developer or
development team
• It shows the system’s modules or components including
packages, sub-systems and class libraries
• It gives the building block view of the system
• It is useful for software manager or programmers
• It is also called implementation view
• UML Diagrams to represent the Physical view
• Component Diagram
• Package Diagram
Architectural View
l Use Case View
• It shows the functionality of the system
• It captures the user goals and scenarios
• It offers the an outside-world perspective on the system
• It is helpful in defining and explaining the structures and
functionality in the other four views
• It is Plus One view to provides guides on other four views
• It is useful for software manager or programmers
• UML Diagrams to represent the Physical view
• Use Case Diagram
Roles of Software Architect
Architectural Pattern
l It defines the overall shape and structure of software
applications
l It was proposed in the 1990s under the name ‘Architectural
Styles’ – shaw and garlan, 1996
l It should describe a system organization that has been
successful in previous system
l It is a concept that solves and delineates some cohesive
elements of a software architecture
l The most popular layered architectural patterns
• MVC Architecture
• Layered architecture
• Repository Architecture
• Client-Server Architecture
• Pipe and Filter Architecture
MVC Pattern
l It separates presentation and interaction from the system data
l It is the basis of interaction management in many web-based
system
l This pattern has three logical components:
• Model
• It manages the system data and associated operations on that data
• View
• It is the presentation layer
• It consists of all user interface
• It defines and manages how the data is presented to the user
• Controller
• It handles communications between users and model
• It manages user interaction and passes this interactions to the view
MVC Pattern
Waiter COOK Presenter
Restaurant
MVC Pattern
Waiter COOK
Model
Order slip - from
customer to cook
Presenter Food – from cook to
Presenter
Restaurant
MVC Pattern
Business
Controller Logic
View
MVC Pattern
Business
Servelet Logic
JSP
MVC Pattern
l When Used
• When there are multiple ways to view and interact with
data
• When the future requirements for interactions and
presentations of data are unknown
l Advantages
• It allows the data to change independently of its
representation and vice versa
• It supports presentation of the same data in different
ways
l Disadvantages
• It can involve additional code and code complexity when
the data model and interactions are simple
Layered Architectural Pattern
l The notions of separation and independence are
fundamental to architectural design because
• They allow changes to be localized
l MVC pattern separates the elements of a system
allowing them to change independently
• Adding a new view or changing an existing view can be
done without any changes to the underlying data in the
model
l Layered architectural pattern is another way of
achieving separation and independence
Layered Architectural Pattern
l The system functionality is organized into separate
layers
l Each layer relies on the facilities and services
offered by the layer immediately beneath it
l It is not triangle like MVC, but linear
l Example
• Sharing copyright documents held in different libraries
l When used
• When building new facilities on top of existing systems
• 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
A Generic Layered Architecture
User Interface
User Interface Management
Authentication and Authorization
Core Business Logic
System Support
(OS, Database)
Architecture of LIBSYS
Web Browser Interface
LIBSYS Form and Query Print
Login Manager Manager
Distributed Document Rights Accounting
Search retrieval Manager
Library Index
DB1 DB2 DB3 DB4
3-tier Architecture
l Presentation Layer
• Occupies the top level and displays information related to
services available on a website
• Translates tasks and results to something the user
understands
l Application Layer
• It is also called middle tier, logic tier or business logic tier
• It coordinates the application, processes commands,
makes logical decisions and performs calculations
l Data Access Layer
• Information is retrieved and stored from a database
management system
3-tier Architecture
Store
Presentation Business Data
Layer Logic Access Retrieve
Database
Layer Logic
JSP C#, Java, [Link] JDBC, ODBC My SQL, Oracle
Layered Architectural Pattern
l Advantages
• It allows replacement of entire layers so long so the interface is
maintained
• Redundant facilities (authentication) can be provided in each
layer to increase the dependability of the system
l Disadvantages
• Performance can be a problem because of multiple levels of
interpretation of a service request as it is processed a each layer
Repository Architectural Pattern
l All data in a system is managed in a central repository that is
accessible to all system components
l A set of interacting components can share data
l Components do not interact directly, only through the repository
l For example, IDE- includes different model-driven development , MIS
and CAD system
UML Code
Editors Generators
Java
Editors
Design Project
Translator Repository
Design Report Python
Analysis Generators Editors
Repository Architectural Pattern
l When used
• Large volume of information are generated that has to be stored
for a long time
• Data driven systems where the inclusion of data in the
repository triggers an action or tool
l Advantages
• Components can be independent
• Changes made by one component can be propagated to all
components
• All data can be managed consistently as it is all in one place
l Disadvantages
• The repository is a single point of failure so problems in the
repository affect the whole system
• May be inefficiencies in organizing all communication through
the repository
• Distributing the repository across several computers may be
difficult
Client-server Architectural Pattern
l A run time organization for distributed
systems
l The major components
• A set of servers
• The functionality of the system is organized into services, with each
service is delivered from a separate server
Print Servers
File Servers
Compile Servers
• A set of clients
• Clients are users of these services and access servers to make use
of them
• A network
• That allows the client to access these services
• Most client-server systems are implemented as distributed systems,
connecting using internet protocols
Client-server Architectural Pattern for
Film and Library
Client 1 Client 2 Client 3 Client 4
Internet
Catalogue Video Picture Web Server
Server Server Server
Film and
Library Film Store Picture Photo Info.
Store
Client-Server Architectural Pattern
l When used
• Data in a shared database has to be accessed from a range of
locations
l Advantages
• Servers can be distributed across a network
• Separation and independency- services and servers can be
changed without affecting other parts of the system
l Disadvantages
• Performance may be unpredictable because it depends on the
network as well as the system
Pipe and Filter Pattern
l The processing of the data in a system is organized so that
• Each processing component (filter) is discrete
• Caries out one type of data transformation
l The data flow from one component to another for processing
l When used
• Where inputs are processed in separate stages to generate related
outputs
Issued Receipts Receipts
Read Issued Identify
Invoices Payments
Invoices Payments
Find Payments
Issue Payment Remainders
Due Remainder
Pipe and Filter Pattern
l Advantages
• It is easy to understand
• It supports transformation reuse
• Workflow style matches the structure of many business processes
• Evolution by adding transformations is straightforward
• It can be implemented as either a sequential or concurrent system
l Disadvantages
• The format for data transfer has to be agreed upon between
communicating transformations
• Each transformation must parse its input and unparse its output to the
agreed form
• So this increases system overhead
Application Architecture
l Application Architectures encapsulate the principal
characteristics of a class of systems
l Two types of Applications
• Transaction Processing System
• Language Processing System
Transaction Processing System
l It is database-centered applications that
• Process user requests for information
• Update the information in a database
• are organized in such a way that user actions can’t interfere with each
other and the integrity of the database is maintained
l Database Transaction
• Is sequence of operations that is treated as a single unit, where all
operations have to be completed before the database changes are
made permanent
l This class system includes
• Banking system
• E-commerce system
• Information system
• Booking system
Structure of TPS
I/O Application Transaction
Processing Logic Manager Database
User makes a request to the Transaction is created and
system through I/O passed to a transaction
manager Transaction Manager ensure
the transaction is properly
The request is processed by completed and it signals to
some application specific Transaction Manager usually
the application that
logic embedded in the database
processing is finished
management system
Language Processing System
l Users intentions are expressed in a formal
language
l The LPS translates a natural or artificial
language into another representation of that
language
l For example, Compiler
• It translates high-level language programs into
machine code
Compiler
l The components are
• Lexical Analyzer
• Symbol Table
• Syntax Analyzer
• Syntax tree
• Semantic Analyzer
• Code Generator
Pipe and Filter compiler
architecture
Symbol
Table
Syntax
Tree
Lexical Syntactic Semantic Code
Analysis Analysis Analysis Generation
Repository compiler architecture
Lexical Syntactic Semantic
Analysis Analysis Analysis
Pretty- Abstract Grammar Code
Printer Syntax tree Definition Optimizer
Symbol Output Code
Editor Table Definition Generation
Repository
Conclusion
l Software Architecture
l Architectural view
l Architectural Pattern
l Different types of applications