2. Software Architecture 2
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
3. Software Architecture 3
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
4. Software Architecture 4
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
5. Software Architecture 5
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
6. Software Architecture 6
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
7. Software Architecture 7
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
8. Software Architecture 8
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
9. Software Architecture 9
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
10. Software Architecture 10
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
11. Software Architecture 11
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
12. Software Architecture 12
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,..
13. Software Architecture 13
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
14. Software Architecture 14
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, âĻ
15. Software Architecture 15
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
16. Software Architecture 16
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
17. Software Architecture 17
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
19. Software Architecture 19
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
20. Software Architecture 20
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
22. Software Architecture 22
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
24. Software Architecture 24
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
25. Software Architecture 25
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)
27. Software Architecture 27
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
29. Software Architecture 29
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
30. Software Architecture 30
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
31. Software Architecture 31
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
32. Software Architecture 32
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
33. Software Architecture 33
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
34. Software Architecture 34
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
36. Software Architecture 36
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
37. Software Architecture 37
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,..
38. Software Architecture 38
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
40. Software Architecture 40
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
41. Software Architecture 41
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
42. Software Architecture 42
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
43. Software Architecture 43
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
44. Software Architecture 44
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
45. Software Architecture 45
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
46. Software Architecture 46
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
47. Software Architecture 47
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
48. Software Architecture 48
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
49. Software Architecture 49
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,..
50. Software Architecture 50
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
51. Software Architecture 51
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
52. Software Architecture 52
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
53. Software Architecture 53
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
54. Software Architecture 54
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
55. Software Architecture 55
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