Engineering System SoftwareZAHRA NIKDEL
SPRING 2019
What is software architecture? Software architecture is
the fundamental structures of a software system,
the discipline of creating such structures,
the documentation of those structures
Each structure comprises software elements, relations among them,
and properties of both elements and relations, along with rationale
for the introduction and configuration of each element[1].
The architecture of a software system is a metaphor, analogous to
the architecture of a building[2].
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 - 2019
Architecture Role
Yet, architecture must influence requirements “The art of the
possible” Helps stakeholder understanding of risk/cost Helps
stakeholder understanding of possibilities
Documenting software architecture facilitates communication between
stakeholders, captures decisions about the architecture design, and
allows reuse of design components between projects.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 5
Architecture as a series of decisions Software architecture is
about making fundamental structural choices
which are costly to change once implemented.
Each project normally has several alternative solutions. The job of
architecture is to choose between these options which we call it
Architectural options.
The Architecture makes an architectural decision to resolve each
sub- problem. This process involves choosing the best option from
among the alternatives.
6
Making decisions To make each design decision, the software
engineer uses: Knowledge of
the requirements
Creative solutions
7
Making decisions example System: controller of the space shuttle
which launch vehicle
Requirements: 1-being fast 2- being reliable.
To be fast, an appropriate real-time computing language would need
to be chosen.
To satisfy the need for reliability the choice could be made to
have multiple redundant and independently produced copies of the
program, and to run these copies on independent hardware while
cross-checking results.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 356 - 2019
Architectural model A software architectural style is determined by
the following:
A set of components
A topological layout of these components indicating their runtime
interrelationships
A set of semantic constraints (e.g. a data repository is not
allowed to changed the values in it)
A set of connectors that mediate communication, coordination, or
cooperation among components
8
Architectural model example
Component Self-contained piece of a system with clearly defined
interfaces
A component can be isolated, allowing you to replace it with a
different component that has equivalent functionality.
Components should be designed to be reusable.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 11
Connectors A linkage between components via an interface Way that
two components talk
e.g. Webserver talks http or Database server talks sql
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 12
Architecture view points A system’s architecture can be described
in terms of several different views The logical breakdown into
subsystems
The interfaces among the subsystems
The dynamics of the interaction among components at run time
The data that will be shared among the subsystems
The components that will exist at run time, and the machines or
devices on which they will be located
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 13
Architecture view points Popular viewpoint models include the 4+1
views on software architecture, the viewpoints and perspectices
catalog by Nick Rozanski and Eoin Woods, and the IBM ADS viewpoint
model by Phlippe Spaas et al.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 14
Architecture view example Functional Viewpoint (logical view)
Purpose: capture the functional structure of the system
Content: the system’s runtime functional elements and their
responsibilities, interfaces, and primary interactions
Concerns: functional capabilities, external interfaces, internal
structure, and design philosophy
Models: functional structure model
Architecture view example
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 16
Design stable architecture To ensure the maintainability and
reliability of a system, an architectural model must be designed to
be stable.
Being stable means that the new features can be easily added with
only small changes to the architecture
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 17
Developing an architectural model[3] Start by sketching an outline
of the architecture Based on the principal requirements
and use cases
Choose among the various architectural patterns
https://msdn.microsoft.com/en-us/library/ff647894.aspx
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 18
Developing an architectural model[3] Refine the architecture
Identify the main ways in which the components will interact and
the interfaces
between them
Decide how each piece of data and functionality will be distributed
among the various components
Determine if you can re-use an existing framework, if you can build
a framework
Consider each use case and adjust the architecture to make it
realizable
Mature the architecture
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 19
Describing an architecture using UML All UML diagrams can be useful
to describe aspects of the
architectural model
Four UML diagrams are particularly suitable for architecture
modelling: Package diagrams
Component diagrams
Deployment diagrams
Package diagrams[3]
Component diagrams[3]
Deployment diagrams[3]
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 23
Architectural Styles The notion of patterns can be applied to
software architecture. These are called architectural patterns or
architectural styles.
Each allows you to design flexible systems using components
Garlan and Shaw define an architectural style as:
“ family of systems in terms of a pattern of structural
organization. More specifically, an architectural style determines
the vocabulary of components and connectors that can be used in
instances of that style, together with a set of constraints on how
they can be combined. These can include topological constraints on
architectural descriptions (e.g., no cycles). Other
constraints—say, having to do with execution semantics—might also
be part of the style definition.” [4]
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 24
Architectural Styles There are several common styles for
architecture:
Client/Server Architectural Style
Component-Based Architectural Style
Layered Architectural Style
Message-bus Architectural Style
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 25
Client/Server Architectural Style Segregates the system into two
applications, where the client makes requests to the server. In
many cases, the server is a database with application logic
represented as stored procedures. [5]
A system composed of various software components that are
distributed over several hosts.
There is at least one component that has the role of server,
waiting for and then handling connections.
There is at least one component that has the role of client,
initiating connections in order to obtain some service.
A further extension is the Peer-to-Peer pattern.
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 26
An example of a distributed system[3]
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 27
Component-Based Architectural Style Decomposes application design
into reusable functional or logical components that expose
well-defined communication interfaces[5].
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 28
Domain Driven Design Architectural Style An object-oriented
architectural style focused on modeling a business domain and
defining business objects based on entities within the business
domain.
Domain Driven Design Architectural Style Picture from:
https://cdn.infoq.com/statics_s2_ 20191122-
0331/resource/articles/ddd-in- practice/en/resources/Architecture
Diagram_lg.gif
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 29
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 30
Layered architectural Style Partitions the concerns of the
application into stacked groups (layers).
Each layer has a well-defined interface used by the layer
immediately above. The higher layer sees the lower layer as a set
of services.
It is important to have a separate layer for the UI. Layers
immediately below the UI layer provide the application functions
determined by the use-cases.
Bottom layers provide general services.
e.g. network communication, database access
Layered Architectural Style
Message-bus Architectural Style
Prescribes use of a software system that can receive and send
messages using one or more communication channels, so that
applications can interact without needing to know specific details
about each other[5].
https://msdn.microsoft.com/en-us/library/aa302165.aspx
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 33
N-Tier / 3-Tier Architectural Style Segregates functionality into
separate segments in much the same way as the layered style, but
with each segment being a tier located on a physically separate
computer[5].
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 34
Object-Oriented Architectural Style A design paradigm based on
division of responsibilities for an application or system into
individual reusable and self-sufficient objects, each containing
the data and the behavior relevant to the object[5].
http://www.hostitwise.com/software_design/nenios_architectural_component_llevel_design.html
Service-Oriented Architectural Style Refers to applications that
expose and consume functionality as a service using contracts and
messages.
https://www.eclipse.org/edt/papers/topics/egl_soa_overview.html
ZAHRA NIKDEL UNIVERSITY OF VICTORIA SENG 468 356 - 2019
reference 1. Clements, Paul; Felix Bachmann; Len Bass; David
Garlan; James Ivers; Reed
Little; Paulo Merson; Robert Nord; Judith Stafford (2010).
Documenting Software Architectures: Views and Beyond, Second
Edition. Boston: Addison-Wesley. ISBN 0- 321-55268-7.
2. Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of
software architecture" . ACM SIGSOFT Software Engineering Notes. 17
(4): 40. doi:10.1145/141874.141884
3. Timothy C. Lethbridge and Robert Laganière (2002)Object-Oriented
Software Engineering: Practical Software Development using UML and
Java .
4. [David Garlan and Mary Shaw, January 1994, CMU-CS-94-166, see
"An Introduction to Software Architecture" at
http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf]
5.
https://msdn.microsoft.com/en-ca/library/ee658117.aspx#LayeredStyle