Software Architecture
1
Defintions - ANSI/IEEE Std 1471-2000
• “Architecture is the fundamental organization of a system, embodied
in its components, their relationships to each other and the
environment, and the principles governing its design and evolution.”
• All architecture is software design, but not all design is software architecture
• First stage of the design process
2
Architectural design decisions
• Is there a generic application architecture that can be used?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
• How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?
Chapter 6 Architectural design 3
Architecture Defines Structure
• Decomposition of system into components/modules/subsystems
• Architecture defines:
• Component interfaces
• What a component can do
• Component communications and dependencies
• How components communicate
• Component responsibilities
• Precisely what a component will do when you ask it
4
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 (reusability)
• The architecture may be reusable across a range of systems
• Product-line architectures may be developed.
Chapter 6 Architectural design 5
Quality Attribute Requirements
Quality Architecture Requirement
Attribute
Performance Application performance must provide sub-four second response times for 90% of
requests.
Security All communications must be authenticated and encrypted using certificates.
Resource The server component must run on a low end office-based server with 512MB memory.
Management
Usability The user interface component must run in an Internet browser to support remote users.
Availability The system must run 24x7x365, with overall availability of 0.99.
Reliability No message loss is allowed, and all message delivery outcomes must be known with 30
seconds
Scalability The application must be able to handle a peak load of 500 concurrent users during the
enrollment period.
Modifiability The architecture must support a phased migration from the current Forth Generation
Language (4GL) version to a .NET systems technology solution.
6
Constraints
Constraint Architecture Requirement
Business The technology must run as a plug-in for MS BizTalk, as we want to sell this to
Microsoft.
Development The system must be written in Java so that we can use existing development staff.
Schedule The first version of this product must be delivered within six months.
Business We want to work closely with and get more development funding from MegaHugeTech
Corp, so we need to use their technology in our application.
7
Structure and Dependencies
• Excessive component C1 C2 C3 C4 C1 C2 C3 C4
dependencies are bad!
• Key architecture issue
• Identifying components AL
that may change Third Party
• Reduce direct Component
dependencies on these
components Four components are directly dependent on a
Third Party
Component
• Creates more modifiable
third party component. If the third party
component is replaced with a new component
with a different interface, changes to each Only the AL (abstraction layer) component is directly
systems component are likely.
Diagram Key
dependent on the third party component. If the third party
component is replaced, changes are restricted to the AL
component only
Component
C
Dependency
8
Coupling & Cohesion (Important for Good Design)
• Lower Coupling:
• Lower dependencies between Components
• Why it is good design?????
• Higher Cohesion
• Single task (responsibility) components
• Why it is good design?????
• Lower Coupling & Higher Cohesion
• Leads to Good Architecture, Design and Implementation
9
Architecture Specifies Component Communication
• Communication involves:
• Function calls
• Remote Procedure Calls (RPC)
• Asynchronous message
• Don’t wait for reply
• Synchronization messages
• Wait for reply
10
Architecture is an Abstraction
• Architecture provides an abstract view of a design
• Hides complexity of design
• May or may not be a direct mapping between architecture
elements and software elements
• Example – A Marketecture
• informal depiction of system’s structure and interactions.
• portray the design philosophies embodied in the architecture
• Every system should have a marketecture:
• Easy to understand
• Helps discussion during design, build, review, sales (!) process
11
Marketecture Example
Local information
repositories
Internet
ICDE
Repository
ICDE Analyst
Recording Software
3rd Party
Tools
12
Decomposition
• Hierarchical decomposition is a Top Level Architecture Description Diagram Key
Component
powerful abstraction mechanism
C
Client Broker Server Dependency
• Partitions design
• Allocate components to development
teams
Security
• How this architecture lower coupling
Message
Server
Handler
between clients & Servers? Directory
Server Request Data
Handler Store
• How this architecture achieves
higher cohesion?
13
Philippe Krutchen - 4+1 View Model
• Logical view: describes architecturally significant elements of the architecture and the
relationships between them.
• Process view: describes the communications elements of an architecture.
• Physical view: depicts how the major processes and components are mapped on to the
applications hardware.
• Development view: captures the internal organization of the software components as held in
e.g. a configuration management tool.
• Architecture use cases: capture the requirements for the architecture; related to more than
one particular view
14
Architectural Patterns
• An architectural pattern is a
general, reusable solution to a
commonly occurring problem in
software architecture within a
given context
• Design Patterns
• Works at the level of classes &
relationship Code
• Architectural Patterns
• Level of subsystems, components,
external systems
N-Tier Client Server Pattern
• Separation of concerns:
Presentation, business and data Client Web Web Web
handling logic are clearly partitioned Tier Client Client Client
in different tiers.
• Synchronous communications: Web Server
Web Server
Communications between tiers is Tier
synchronous request-reply. Each tier
waits for a response from the other
tier before proceeding. Business
Application Server
Logic Tier
• Opposite to asynchronies
communication
Data
• Flexible deployment: There are no Management Databases
restrictions on how a multi-tier Tier
application is deployed. All tiers
could run on the same machine, or
each tier may be deployed on its
own machine.
16
The Client–server pattern
Name Client-server
Description In a client–server architecture, the functionality of the system is
organized into services, with each service delivered from a
separate server. Clients are users of these services and access
servers to make use of them.
Example Figure 6.11 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.
Chapter 6 Architectural design 17
Publish-Subscribe Pattern
• Many-to-Many messaging:
Published messages are sent to
all subscribers who are Subscriber
registered with the topic. Publisher Topic Subscriber
Subscriber
• Loose Coupling: As with
messaging, there is no direct
binding between publishers and
subscribers.
18
Pipe and Filter
• Pipe and Filter is a simple architectural style
that connects several filters that process a
stream of data, each connected to the next
component in the processing pipeline via
a Pipe.
The pipe and filter pattern
Name Pipe and filter
Description The processing of the data in a system is organized so that each
processing component (filter) is discrete and carries out one type of
data transformation. The data flows (as in a pipe) from one component
to another for processing.
Example Figure 6.13 is an example of a pipe and filter system used for
processing invoices.
When used Commonly used in data processing applications (both batch- and
transaction-based) where inputs are processed in separate stages to
generate related outputs.
Advantages Easy to understand and supports transformation reuse. Workflow style
matches the structure of many business processes. Evolution by
adding transformations is straightforward. Can be implemented as
either a sequential or concurrent system.
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. This increases system
overhead and may mean that it is impossible to reuse functional
transformations that use incompatible data structures.
Chapter 6 Architectural design 20
Software Architecture Modeling:
UML Component Diagram
21
UML Communication Diagram
