5 architecture

Software Architecture 1
Software Architecture

Background
 Any complex system is composed of
sub-systems that interact
 While designing systems, an approach
is to identify sub-systems and how they
interact with each other
 Sw Arch tries to do this for software
 A recent area, but a lot of interest in it

Background…
 Architecture is the system design at the
highest level
 Choices about technologies, products to use,
servers, etc are made at arch level
 Not possible to design system details and then
accommodate these choices
 Arch must be created accommodating them
 Is the earliest place when properties like
rel/perf can be evaluated

Architecture
 Arch is a design of the sw that gives a very
high level view of parts and they relate to
form the whole
 Partitions the sys in parts such that each part can
be comprehended independently
 And describes relationship between parts
 A complex system can be partitioned in many
diff ways, each providing a useful view
 Same holds true of software also
 There is no unique structure; many possible

Architecture
 Defn: Software arch is the structure or
structures which comprise elements, their
externally visible properties, and relationships
among them
 For elements only interested in external properties
needed for relationship specification
 Details on how the properties are supported is not
important for arch
 The defn does not say anything about whether an
arch is good or not – analysis needed for it
 An arch description describes the different
structures of the system

Key Uses of Arch Descriptions
 Understanding and communication
 By showing a system at a high level and
hiding complexity of parts, arch descr
facilitates communication
 To get a common understanding between
the diff stakeholders (users, clients,
architect, designer,…)
 For negotiation and agreement
 Arch descr can also aid in understanding of
existing systems

Uses…
 Reuse
 A method of reuse is to compose systems from
parts and reuse existing parts
 This model is facilitated by reusing components at
a high level providing complete services
 To reuse existing components, arch must be
chosen such that these components fit together
with other components
 Hence, decision about using existing components
is made at arch design time

Uses..
 Construction and evolution
 Some structures in arch descr will be used to
guide system development
 Partitioning at arch level can also be used for work
allocation to teams as parts are relatively
independent
 During sw evolution, arch helps decide what
needs to be changed to incorporate the new
changes/features
 Arch can help decide what is the impact of
changes to existing components on others

Uses…
 Analysis
 If properties like perf, reliability can be determined
from design, alternatives can be considered during
design to reach the desired perf levels
 Sw arch opens such possibilities for software
(other engg disciplines usually can do this)
 E.g. rel and perf of a system can be predicted
from its arch, if estimates for parms like load etc is
provided
 Will require precise description of arch, as well as
properties of the elements in the description

Architectural Views
 There is no unique arch of a sys
 There are different views of a sw sys
 A view consists of elements and relationships
between them, and describes a structure
 The elements of a view depends on what the
view wants to highlight
 Diff views expose diff properties
 A view focusing on some aspects reduces its
complexity

Views…
 Many types of views have been proposed
 Most belong to one of these three types
 Module
 Component and Connector
 Allocation
 The diff views are not unrelated – they all
represent the same system
 There are relationships between elements of diff
views; this rel may be complex

Views…
 Module view
 A sys is a collection of code units i.e. they
do not represent runtime entitites
 I.e. elements are modules, eg. Class,
package, function, procedure,…
 Relationship between them is code based,
e.g. part of, depends on, calls,
generalization-specialization,..

Views…
 Component and Connector (C&C)
 Elements are run time entities called
components
 I.e. a component is a unit that has identity
in executing sys, e.g. objects,
processes, .exe, .dll
 Connectors provide means of interaction
between components, e.g. pipes, shared
memory, sockets

Views…
 Allocation view
 Focuses on how sw units are allocated to
resources like hw, file system, people
 I.e. specifies relationship between sw
elements and execution units in the env
 Expose structural properties like which
process runs on which processor, which
file resides where, …

Views…
 An arch description consists of views of diff
types, each showing a diff structure
 Diff sys need diff types of views depending on the
needs
 E.g. for perf analysis, allocation view is necessary;
for planning, module view helps
 The C&C view is almost always done, and
has become the primary view
 We focus primarily on the C&C view
 Module view is covered in high level design,
whose focus is on identifying modules

Component and Connector View
 Two main elements – components and connectors
 Components: Computational elements or data stores
 Connectors: Means of interaction between comps
 A C&C view defines the comps, and which comps are
connected through which connector
 The C&C view describes a runtime structure of the
system – what comps exist at runtime and how they
interact during execution
 Is a graph; often shown as a box-and-line drawing
 Most commonly used structure

Components
 Units of computations or data stores
 Has a name, which represents its role, and
provides it identity
 A comp may have a type; diff types rep by diff
symbols in C&C view
 Comps use ports (or interfaces) to
communicate with others
 An arch can use any symbols to rep
components; some common ones are shown

Some Component
examples…

Connectors
 Interaction between components happen
through connectors
 A connector may be provided by the runtime
environment, e.g. procedure call
 But there may be complex mechanisms for
interaction, e.g http, tcp/ip, ports,…; a lot of
sw needed to support them
 Important to identify them explicitly; also
needed for programming comps properly

Connectors…
 Connectors need not be binary, e.g. a
broadcast bus
 Connector has a name (and a type)
 Often connectors represented as protocol –
i.e. comps need to follow some conventions
when using the connector
 Best to use diff notation for diff types of
connectors; all connectors should not be
shown by simple lines

Connector examples

An Example
 Design a system for taking online survey of
students on campus
 Multiple choice questions, students submit online
 When a student submits, current result of the
survey is shown
 Is best built using web; a 3-tier architecture is
proposed
 Has a client, server, and a database components
(each of a diff type)
 Connector between them are also of diff types

Example…

Example…
 At arch level, details are not needed
 The connectors are explicitly stated,
which implies that the infrastructure
should provide http, browser, etc.
 The choice of connectors imposes
constraints on how the components are
finally designed and built

Extension 1
 This arch has no security – anyone can
take the survey
 We want that only registered students
can take the survey (at most once)
 To identify students and check for one-only
submission, need a authentication server
 Need to use cookies, and server has to be
built accordingly (the connector between
server and auth server is http with cookies)

Extension 1…

Extension 2
 It was found that DB is frequently down
 For improving reliability, want that if DB
is down, student is given an older
survey result and survey data stored
 The survey data given can be outdated
by at most 5 survey data points
 For this, will add a cache comp, which
will store data as well as results

Extension 2…

Example…
 One change increased security, 2nd
increased performance and reliability
 I.e. Arch level choices have a big
impact on system properties
 That is why, choosing a suitable arch
can help build a good system

Architectural Styles for C&C View
 Diff systems have diff C&C structure
 Some structures are general and are useful
for a class of problems – architectural styles
 An arch style defines a family of archs that
satisfy the constraint of that style
 Styles can provide ideas for creating arch for
a sys; they can be combined also
 We discuss a few common styles

Pipe and filter
 Well suited for systems that mainly do data
transformations
 A system using this style uses a network of
transforms to achieve the desired result
 Has one component type – filter
 Has one connector type – pipe
 A filter does some transformation and passes
data to other filters through pipes

Pipe and Filter…
 A filter is independent; need not know the id
of filters sending/receiving data
 Filters can be asynchronous and are
producers or consumers of data
 A pipe is unidirectional channel which moves
streams of data from one filter to another
 A pipe is a 2-way connector
 Pipes have to perform buffering, and
synchronization between filters

Pipe and filter…
 Pipes should work without knowing the
identify of producers/consumers
 A pipe must connect the output port of
one filter to input port of another
 Filters may have indep thread of control

Example
 A system needed to count the
frequency of different words in a file
 One approach: first split the file into a
sequence of words, sort them, then
count the #of occurrences
 The arch of this system can naturally
use the pipe and filter style

Example..

Shared-data style
 Two component types – data repository and
data accessor
 Data repository – provides reliable permanent
storage
 Data accessors – access data in repositories,
perform computations, and may put the
results back also
 Communication between data accessors is
only through the repository

Shared-data style…
 Two variations possible
 Black board style: if data is posted in a
repository, all accessors are informed; i.e.
shared data source is an active agent
 Repository style: passive repository
 Eg. database oriented systems; web
systems; programming environments,..

Example
 A student registration system of a
university
 Repository contains all the data about
students, courses, schedules,…
 Accessors like admin, approvals,
registration, reports which perform
operations on the data

Example…

Example..
 Components do not directly
communicate with each other
 Easy to extend – if a scheduler is
needed, it is added as a new accessor
 No existing component needs to be
changed
 Only one connector style in this –
read/write

Client-Server Style
 Two component types – clients and servers
 Clients can only communicate with the server,
but not with other clients
 Communication is initiated by a client which
sends request and server responds
 One connector type – request/reply, which is
asymmetric
 Often the client and the servers reside on
different machines

Client-server style…
 A general form of this style is the n-tier
structure
 A 3-tier structure is commonly used by
many application and web systems
 Client-tier contains the clients
 Middle-tier contains the business rules
 Database tier has the information

Some other styles
 Publish-subscribe style
 Some components generate events, and others
subscribe to them
 On an event, those component that subscribe to it
are invoked
 Peer-to-peer style
 Like object oriented systems; components use
services from each other through methods
 Communication processes style
 Processes which execute and communicate with
each other through message passing

Architecture and Design
 Both arch and design partition the system into
parts and their org
 What is the relationship between design and
arch?
 Arch is a design; it is about the solution domain,
and not problem domain
 Can view arch as a very high level design focusing
on main components
 Design is about modules in these components that
have to be coded
 Design can be considered as providing the module
view of the system

Contd…
 Boundaries between architecture and design
are not clear or hard
 It is for designer and architect to decide
where arch ends and design begins
 In arch, issues like files, data structure etc are
not considered, while they are important in
design
 Arch does impose constraints on design in
that the design must be consistent with arch

Preserving the Integrity of
Architecture
 What is the role of arch during the rest of the
development process
 Many designers and developers use it for
understanding but nothing more
 Arch imposes constraints; the implementation must
preserve the arch
 I.e. the arch of the final system should be same as
the arch that was conceived
 It is very easy to ignore the arch design and go
ahead and do the development
 Example – impl of the word frequency problem

Documenting Arch Design
 While designing and brainstorming,
diagrams are a good means
 Diagrams are not sufficient for
documenting arch design
 An arch design document will need to
precisely specify the views, and the
relationship between them

Documenting…
 An arch document should contain
 System and architecture context
 Description of architecture views
 Across view documentation
 A context diagram that establishes the sys
scope, key actors, and data sources/sinks
can provide the overall context
 A view description will generally have a
pictorial representation, as discussed earlier

Documenting…
 Pictures should be supported by
 Element catalog: Info about behavior,
interfaces of the elements in the arch
 Architectural rationale: Reasons for making
the choices that were made
 Behavior: Of the system in different
scenarios (e.g. collaboration diagram)
 Other Information: Decisions which are to
be taken, choices still to be made,..

Documenting…
 Inter-view documentation
 Views are related, but the relationship is not clear
in the view
 This part of the doc describes how the views are
related (eg. How modules are related to
components)
 Rationale for choosing the views
 Any info that cuts across views
 Sometimes views may be combined in one
diagram for this – should be done if the
resulting diagram is still easy to understand

Evaluating Architectures
 Arch impacts non-functional attributes like
modifiability, performance, reliability,
portability, etc
 Attr. like usability etc are not impacted
 Arch plays a much bigger impact on these
than later decisions
 So should evaluate a proposed arch for these
properties
 Q: How should this evaluation be done?
 Many different ways

Evaluating Architectures…
 Procedural approach – follow a sequence of
steps
 Identify the attributes of interest to different
stakeholders
 List them in a table
 For each attribute, evaluate the architectures
under consideration
 Evaluation can be subjective based on experience
 Based on this table, then select some arch or
improve some existing arch for some attribute

Summary
 Arch of a sw system is its structures
comprising of elements, their external
properties, and relationships
 Arch is a high level design
 Three main view types – module, component
and connector, and allocation
 Component and connector (C&C) view is
most commonly used

Summary…
 There are some C&C styles that are
commonly used, e.g. pipe-and-filter,
shared data, client server,....
 An arch description should document
the different views and their relationship
– views can be combined
 Rationale and other supporting
information should also be captured

Summary…
 Arch can be analyzed for various non-
functional attributes like performance,
reliability, security, etc
 ATAM is one approach for analyzing
architectures, which evaluates
attributes of interest under different
scenarios

5 architecture

More Related Content

What's hot (20)

Similar to 5 architecture (20)

Recently uploaded (20)

5 architecture