So --- Why Software Architecture?
• As software systems continue to grow in size
and complexity (both breadth and depth),
just looking at algorithms and data
structures is not enough.
• “Large” systems, by definition, is made of
many sub-components that interact with
each other. So ---- to design “it,” we need to
study the architecture/design behind it.
Architecture
Design
Coding
“Progressive” Picture of Software
More Progress
Design
to satisfy:
Some Progress
early days
Code
Code
Patterns
&
Algorithms
(speed/space)
-performance
-consistency
-reliability
-usability
-extensibility
-etc.
Relative Complexity/Size/Concern growth
Software Architecture
• Your Text: “ A system’s architecture is the set of
principal design decisions made during its
development and any subsequent evolution.”
• Tsui modifies it to say: “ A system’s architecture is
the result of a set of principal design decisions made
and expressed (in design document, code, etc.) during
its development and subsequent evolution
what ?
As we develop/build software --- we make decisions and tradeoffs to satisfy ---These decisions emerge as the design/architecture and also influence code.
Software Architecture (definitions)
• From Roy Fielding’s PhD thesis (UC Irvine-2000):
“A software architecture is an abstraction of the run-time
elements of a software system during some phase of its
operation. A system may be composed of many levels of
abstraction and different phases of operations, each with its
own software architecture.”
– Software operational phases may be depicted as:
•
•
•
•
•
•
Start up
Initialization
Normal Processing
Error Processing
Possible re-initialization/re-process
Termination
If you describe these,
do you have a design ?
What is
abstraction?
Software Architecture Definitions
• There is NO “standard” definition of
software architecture, yet; there are
more definitions in Chapter 3 of your
text
What do you all think --- ?
At an earlier lecture (1/7/2014), a student said that a software design artifact was
composed of a set of software “pieces/components” ---- how about a little more
A Definition from McMaster Univ. (Canada)
• Architectural Designing (the designing activity --- verb)
The process of i) identifying the components and
ii) establishing a “framework” for a) control and b)
communications of these components
(what is this framework?)
• Software Architecture (the product from designing)
The documented output from the architectural design activities.
Architecture-Centric Development
• Architecture-Centric approach to software
development places an emphasis on “design”
with an aim for:
1. Good quality (e.g. less defects) and many other
product attributes (reliability, extensibility, usability,
etc.)
2. Cost-effective development
3. High leveraging of past experiences (reuse)
Prohibitive requirement
for young/inexperienced developers
Analogy to Physical Building
•
Software architecture/design and physical
building architecture have some similarities:
1. Architecture exist independently from, but strongly
linked to, the (building) (code)
2. Properties of the (structures) (software component
configuration) are induced by the design of their
architecture
3. The architect needs to have “broad” skills beyond
just (construction) (programming)
4. Architecture is more important than the “process”of
(building activities) (software development process)
5. Architecture has matured into a discipline of its own
with many architectural (building) design styles.
(this one may be questionable for software)
One way to “visualize” “software
component configuration (building)”
How is
configuration
specified
here?
“vertical”
&
“horizontal”
functional
structure
is
sometimes
thought of
as
“Architecture”
F
u
n
c
........
1
F
u
n
c
n
Common UI screen looks and icons
Common error processing and messaging
.
.
Common interface to Database Base
Only common
“horizontal”
features
Sometimes --Thought of as
“Architecture”
Some Differences from Physical Building
• Buildings have been around for a much longer time
than software; so a lot less is known about software
• Software does not have a “medium” such as
materials of wood, stone, etc. for physical building;
so software is not as “visible”
• Software is more malleable than a physical building;
so software changes are more frequently requested,
---- changes that are later in development stage, the
bigger are their magnitude of disruption.
Architectural “Style”
• Style is a set of “constraints” placed on
the architecture to achieve certain
properties
– Recall architecture is a set of design decisions
• Style is a characterization of a set of
common features that resulted from a set
of constraints on the architecture.
So - - - - “style” results from placing constraints on design decisions
Architectural “Styles”
• In physical building there are:
Gothic style
Ranch style
Bavarian Chalet style
Italian Villa style
English Tudor style
etc.
• In software we have:
Layered style
Pipe & Filter style
Model-View-Control
etc.
from Roman Architect Vitruvius to Today’s
Software Designer Mitch Kapor (not in your text)
• Paraphrasing (Vitruvius):
“ ---- well-designed buildings were those which exhibited firmness,
commodity, and delight -----”
• Paraphrasing (Mitch Kapor-lotus 1-2-3 ): for software we
want similar characteristics as what Vitruvius said:
firmness: No Bugs (or less bugs and reliable)
commodity: functionalities that satisfy the requirements/users
delight: “pleasurable” experience (exciting usage experience)
• Paraphrasing (T. Winograd-Stanford U.):
“ --- architects and designers work with commodity and delight, and
the engineers works with firmness ----”
Why the Big emphasis on Architecture?
•
Giving architecture the deserved attention provides:
1.
2.
3.
4.
•
Conceptual integrity
A basis for reuse of ---- knowledge, experience, design, and code
Effective project communication
Management of “families” of systems
Architecture must be considered the “heart” of
developing software system, even:
–
–
–
More than processes and methodologies
More than programming
More than requirements analysis (Tsui “objects” to this one; you?)
Your thoughts on “architecture centric-ness”?
World Wide Web ---- Describe at Arch. Level ?
• What is the web?
– Multiple ways to describe it depending on the “view” which
provided different design decisions (or architecture)
1. Set of independent resources, interconnected by computing
systems, that provide some services
2. Set of computing programs that interact with each other
according to a set of rules specified in standards and protocols
such as HTTP, XML, etc.
3. Set of interactions of agents and servers through interconnected
systems .
• None of these “views,” even with diagrams, would give us a deep
understanding of what the web is. But we can not get into all the
details because it would need close to infinite amount of
descriptions to explain all the programs, all protocols, all data,
etc.
– Thus we need to describe the “rules” (decisions) by which the
main parts work and interact ---- use architectural style ?
Observations made in trying to describe
the World Wide Web
• The architecture of the Web is totally separate from
the code that implements all the various parts. (One
needs to describe the Web at an architectural level.)
• There is no “single” piece of code that implements the
web, and thus neither its architecture --- mixed design
• There are multiple, equivalent pieces of code that exist
and implement various components of the Web.
• The stylistic constraints that constitute the definition
of the Web is not apparent in any one piece of the
code, but the effects as implemented in all the pieces
are evident in the Web ---- showing a mix of
architecture/design styles.
a specific Architectural Style: Pipe and Filter
• Main components:
– Filter: processes a stream of input-data to produce some
out- put data
– Pipe: a conduit that allows the flow of data
read input file
filter
pipe
process file
This architecture style focuses
on the dynamic (interaction) and forces
a fairly simple, sequential structure and
flow of data
* NOTE:
Design/Architecture – components (filters) and relations (pipes) ;
Style - constraint on architecture (flow is “sequential”)
Pipe and Filter : UNIX Influence
• UNIX command line processing of the pipe symbol, l
the output from the command to the left of the symbol, l, is to be
sent as input to the command to the right of the pipe;
this mechanism got rid of specifying a file as std output of a
command and then specifying that same file as the std input to
another command, including possibly removing this intermediate file
afterwards
Example ( UNIX commands)
:
Example :
Assume that in the file called my.txt is
the following:
i live in
the city
of Atlanta
$ cat my.txt
i live in
the city
of Atlanta
$cat my.txt
o love on
the coty
of Atlanta
$
Note the pipe
symbol, l
I
sed “s/i/o/g”
First cat command outputs my.txt to screen. The second cat command reads my.txt and
sends it to sed command which search” for “i’ and “globally replace it with “o.” You can have more
and other processing commands, such as sort, to form a sophisticated software.
“l”
Architecture is critical for ---- Product Family
• Software Product family is a set of “related”
software components which has
i) some common components and
ii) some variable components
• The variable components provide, for each
product within the family, the differentiator by
features, by cost (price), by time, etc.
• Reuse and cost sharing is the big advantage
of common components in Product Family (in
reality ---- schedule also played a part)
General
Requirements
(Version 2)
General
Requirements
General
Requirements
(Version 3)
US (common) code
v3
US (common) code
v2
US (common) code
v1
French
( version 1 )
French
( version 3 )
French
( version 2 )
French
(version 2.1)
Japanese
( version 3 )
If Fench Version 2.1
came after Version 3,
we may need to build
a French V3.1
Japanese
( version 2 )
Japanese
( version 1 )
Brazilian
( version 3)
Brazilian
( version 2 )
Brazilian
( version 1 )
Product “Family” ---- and Versioning
Relook at the
“vertical and
horizontal” design
configuration with
“product family”
In mind
Summarizing Arch & Design: We Should Ask
• What are the major functional components of the architecture?
– Decompose the requirements
– Synthesize “similar” functionalities into major components
– Decompose the major components (& data) into subcomponents
• How are the components related?
– Structure of relationship under static condition
– Dynamic flow of control and flow of data during execution
• What elements are needed to “facilitate” the architecture?
– Connector elements introduced to bring in versatile interaction
– Additional functional components introduced to improve a
particular attribute (e.g. security, performance, availability)
• How do we design and evaluate various non-functional & behavioral
properties?
– Performance, security, maintainability, availability, etc. needs to be
defined, specified, measured.
• What execution environment/platform needs to be considered and
resolved?
• Is there any over-riding constraint (e.g. style) that should be
invariant?
What about data ? Do we need to worry about it ?