1. 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

2. “Progressive” Picture of Software
More Progress
Design
to satisfy:
-performance
-consistency
-reliability
-usability
-extensibility
-etc.
Some Progress
early days
Code
Patterns
&
Algorithms
(speed/space)
Code
Relative Complexity/Size/Concern growth

3. 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.

4. 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
What is abstraction?
If you describe these,
do you have a design ?

5. 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

6. 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
Software Architecture (the product from designing)
The documented output from the architectural design activities.
(what is this framework?)

7. Architecture-Centric Development
Architecture-Centric approach to software development places an emphasis on “design” with an aim for:
Good quality (e.g. less defects) and many other product attributes (reliability, extensibility, usability, etc.)
Cost-effective development
High leveraging of past experiences (reuse)
Prohibitive requirement
for young/inexperienced developers

8. Analogy to Physical Building
Software architecture/design and physical building architecture have some similarities:
Architecture exist independently from, but strongly linked to, the (building) (code)
Properties of the (structures) (software component configuration) are induced by the design of their architecture
The architect needs to have “broad” skills beyond just (construction) (programming)
Architecture is more important than the “process”of (building activities) (software development process)
Architecture has matured into a discipline of its own with many architectural (building) design styles. (this one may be questionable for software)

9. One way to “visualize” “software component configuration (building)”
How is configuration
specified here?
Func 1
Func n
“vertical”
&
“horizontal”
functional
structure is
sometimes
thought of
as “Architecture”
Common UI screen looks and icons
Common error processing and messaging
Only common
“horizontal”
features
Sometimes ---
Thought of as
“Architecture” .
Common interface to Database Base

10. 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.

11. 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

12. 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

13. 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 ): 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 ----”

14. Why the Big emphasis on Architecture?
Giving architecture the deserved attention provides:
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”?

15. 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)
Set of independent resources, interconnected by computing systems, that provide some services
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.
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 ?

16. 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.

17. 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
process file
This architecture style focuses
on the dynamic (interaction) and forces
a fairly simple, sequential structure and
flow of data
filter
pipe
* NOTE:
Design/Architecture – components (filters) and relations (pipes) ;
Style - constraint on architecture (flow is “sequential”)

18. 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) :
$ cat my.txt
i live in
the city
of Atlanta
$cat my.txt I sed “s/i/o/g”
o love on
the coty $
Example :
Assume that in the file called my.txt is
the following:
i live in
the city
of Atlanta
Note the pipe
symbol, l
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 “l”
and other processing commands, such as sort, to form a sophisticated software.

19. 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)

20. Product “Family” ---- and Versioning
General
Requirements
(Version 3)
General
Requirements
(Version 2)
US (common) code v3
General
Requirements
US (common) code v2
French
( version 3 )
If Fench Version 2.1
came after Version 3,
we may need to build
a French V3.1
US (common) code v1
French
( version 2 )
French
( version 1 )
French
(version 2.1)
Japanese
( version 3 )
Japanese
( version 2 )
Japanese
( version 1 )
Brazilian
( version 3)
Relook at the
“vertical and
horizontal” design
configuration with
“product family”
In mind
Brazilian
( version 2 )
Brazilian
( version 1 )
Product “Family” ---- and Versioning

21. 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 ?