1. Software Architecture
Image is of the Millau Bridge in southern France, the tallest vehicular bridge in the world. One of its masts is slightly taller than the Eiffel Tower.
Image Credit: <div xmlns:cc=" about=" rel="cc:attributionURL" href=" / <a rel="license" href=" BY 2.0</a></div>

2. The Role of Architecture
Recall that human short-term memory is limited. Some studies peg the capacity of human short-term memory at 5-9 items (seven plus or minus 2).
We use abstractions (such as “chunking”) in order to deal with our limited cognitive abilities. In the 50’s the cutting edge abstraction in programming was a high-level line of code or statement. A statement like for i=1 to 5 might translate into several assembly language instructions. It’s easier to think in terms of statements than assembly language instructions. As soon as you have statements together though, it becomes difficult to work with them or think about them as a whole. The solution? More abstraction. We group statements into procedures. As soon as a program reaches procedures though, it becomes difficult to work with them or think about them as a whole. The solution? More abstraction. We group procedures into classes. As soon as a program reaches classes though, it becomes difficult to work with them or think about them as a whole. The solution? More abstraction. We group classes into groups of classes. Architecture deals with design at the level of “groups of classes”.
Architecture = chunking at the subsystem level.
Architecture isn’t well-defined because we don’t have concrete mechanisms for programming with abstractions above classes. Design is about components and communication between components and we don’t have distinctive programming abstractions above the class level.
Consider components and relationships between components at the various levels. Procedures are groups of lines of code with additional semantics. Lines of code communicate through shared variables. Procedures communicate by passing parameters. Classes are groups of procedures with additional semantics. Classes have state and are related by associations (parameter passing), inheritance, and polymorphism. Groups of classes at the architecture level introduce no new semantics. We are waiting for someone to invent a programming construct for aggregating classes.

3. What is Architecture?
Software Architecture is the structure and organization of high-level components in a software system. This includes high level components and the relationships between these components.
High level components are typically subsystems or programs. Key classes may also be considered architecture components.
The relationships between components includes interaction between components and the nature of this interaction.
In the context of object-oriented programming, a subsystem is a group of related classes.
“The architecture of a product is the scheme by which the functions it performs are allocated to its constituent components (Ulrich, 1995).”
“For any given product, a number of architectures are likely to satisfy its functional requirements. These different architectures may differ along important performance dimensions, such as the quality of the final product, its reliability in operation, its robustness to change and its physical size. They may also imply a differing partitioning of tasks, thereby influencing the efficiency with which development can proceed (Von Hippel, 1990).”
“A good architect definitely creates an ecosystem where decisions can be delayed and / or changed with minimum impact.
A great definition of "Architecture vs Design" is anything that would be very difficult or expensive to change is architecture and other decisions are design or implementation decisions. A great architect guides the solution so more of the technical decisions are design and few are architectural decisions. If system uses the Data Access Object (DAO) pattern, the decisions around which database to use has now become deferable and is now an implementation decision and not an architectural decision.”

4. Example The architecture of the WWW is client/server.
The two types of components that make up the WWW’s architecture style are:
Clients = browsers such as Firefox
Servers = Web servers such as Apache
Nature of interaction = the http protocol, a request/response protocol. The protocol is stateless. The connection is typically open only for the duration of the request and response.

5. Other definitions of software architecture
“Architecture is what remains when you cannot take away any more things and still understand the system and explain how it works." [Kruchten, 2000]
"The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them." [Bass]
“Anything that would be very difficult or expensive to change is architecture and other decisions are design or implementation decisions”
“A word we use when we want to talk about design but want to puff it up to make it sound important." [Fowler IEEE 2003]
There is no universally-accepted definition of software architecture [

6. Important Role of Architecture
Software systems have non-functional as well as functional requirements. Non-functional requirements are quality attributes such as security, performance and scalability.
Architecture is important because it determines the degree to which non-functional requirements are present.
If a software system is being audited for the presence of non-functional requirements, the auditors are going to study the architecture for evidence that the desired non-functional requirements have been met.
If not in the architecture, where else are cross-cutting concerns such as security, performance and scalability going to be addressed?

7. Architecture and design are not the same thing
Architecture is a specific type of design.
The principle difference is:
Architecture are significant design decisions, those that impact the system as a whole. Lower level design decisions tend to have local rather than broad impact.
User needs tend to drive low and mid-level design decisions. Architects must consider the needs of all stakeholders (users, acquirers, developers, testers, maintainers, support staff, etc.)
Everything that was said about design in the last lecture also applies to architecture.

8. Example
The Winchester Mystery House in San Jose California has great design but poor architecture.

9. Arial View of Winchester Mystery House From Google Maps

10. The Winchester Mystery House
Sarah Winchester, widow of gun magnate William Wirt Winchester, inherited a large sum of money upon her husband's death.
She became convinced that her family was cursed by the spirits of all those who had been killed by the guns the family had made and the only way to ward off these evil spirits was to was to continuously build onto her house.
That’s what she did for 38 years from 1884 until her death in 1922.
Problem was she didn’t hire an architect to oversee the changes. The changes she had done to the house were all local.
The result: stairs that lead to nowhere, fire places without chimneys and doors that open onto blank walls. Wonderfully crafted stairs, chimneys and doors, mind you, but useless because of the lack of an overall plan to integrate them in with the rest of the house.

11. The Process of Software Architecture
Identify stakeholders and their needs
Identify and prioritize scenarios (architecturally significant use cases)
Look for opportunities to apply architecture styles (routine solutions to reoccurring architecture problems) (aka patterns)
Document the planned architecture
Validate the planned architecture
Ref: Part II from Software Systems Architecture Rozanski and Woods.

12. Documenting the Architecture
It’s impractical to document most architectures with just one document.
Architecture addresses the concerns of many stakeholders. In most cases, no one document can adequately address the concerns of a diverse group of stakeholders.
Different stakeholders are interested in different aspects of the architecture. What developers are looking for is not necessary what managers are looking for and vise versa.

13. The 4+1 View Model of Architecture
Philippe Kruchten defined the 4+1 view model of software architecture.
Each view addresses a specific set of concerns.
The 4+1 views are:
Logical – the logical view typically includes class diagrams and behavior diagrams to make clear that the proposed architecture covers the required functionality. Concerned with functionality provided to end users. Think analysis model (abstraction from problem domain).
Process – the process view describes concurrent threads and processes.
Physical/Deployment – the physical view describes the mapping of software onto hardware.
Development – the development view takes into account the development environment. Once you have identified all the needed software elements you can begin to map them to deployable modules, development teams, etc. Those aspects of the architecture that are driven by practical concerns of the software development environment, are addressed by the development view. Architecture from the programmer’s perspective. Think design model (abstraction of actual or anticipated implementation).
The Use Case view is the 5th or +1 view. It’s conceptually separate from the other views because it shows how the other views work together to validate the efficacy and completeness of the architecture.
Development view: (implementation view) (the software from the programmers’ perspective) “static organization of the software in its development environment”

14. Conway’s Law
Conway’s law is an adage that comes from a 1968 article by computer programmer Melvin Conway in which he predicts:
“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure.”[How Do Committees Invent?, Conway]
This idea is sometimes humorously paraphrased as:
“If you have four groups working on a compiler, you will get a four-pass compiler.”
Key to effective software architecture is maintaining flexibility in the structure or organization of the individuals contributing to the architecture. According to Conway’s law, if the structure of the organization is rigid, architecture options will be limited.
The structure of software designs that emerge from a team of individuals tends to mire the structure of the communication channels among the individuals producing the design.
“product designs “mirror” the organizations that develop them”
“.organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” [1968 article] “
“interface structure of a software system will reflect the social structure of the organization(s) that produced it.”
“Make sure the organizations is compatible with the product architecture”
“the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.”

15. Architecture Styles
Design patterns are reusable solutions to reoccurring design problems. Architecture styles is the same idea applied at a higher level—at the system level.
Architecture styles = system level organization
An architecture style provides principles and guidelines for defining architecture elements, their interfaces, patterns of communication and constraints on the combination and interaction of elements.
Design patterns / Architecture styles – widely used solutions to common design/architecture problems.
Styles, patterns and idioms = patterns at different levels.
Components and connections between components.

16. Patterns at different levels of design

17. Common Architecture Styles
Client/Server
Peer-To-Peer
Publisher/Subscriber
3-Tier or, more generally, N-Tier
Layered
Pipes and Filters
TBD: add Data Centered

18. Client / Server C/S is a distributed computing architecture style.
As the architecture style behind the WWW and , C/S may be the most popular architecture style by number of instances used daily.
Characterized by a client component, a server component and a communication protocol.
Examples: WWW (HTTP), (SMTP), Database access (proprietary protocol).
Have a whole class dedicated to this architecture style: CS423.
(Consider adding peer-to-peer arch style. Similar to client/server, but components are equals. No single point of failure (or liability!). Scalable. Peers exchange lists of known peers (may have a central peer list).

19. Client / Server [Cont]
Servers provide some service via a well defined interface (communication protocol).
Clients request services; servers provide services. Usually the server doesn't know the identity of the clients in advance (scales better that way).
The client/server distinction lasts for the duration of a session. Clients can become servers and servers can become clients at different times.
Client and server components often reside on separate machines.
Can be stateful or stateless. WWW is of course stateless.
Sometimes it is useful to make the distinction between client/server and a subset of client/server called client-dispatcher-server.
With client-dispatcher-server there is an extra component, a dispatcher that provides location transparency. Clients don’t need to know the physical location of servers. With the WWW, clients send a domain name to DNS and DNS provides the IP or location of the service. This gives you the flexibility of switching ISP’s without changing clients.
Apache might fetch data from a DB. Apache is both a client and a server.

20. Peer-To-Peer
Distributed application architecture similar to client/server, but components are equals.
Peers are both suppliers and consumers of resources, in contrast to the traditional client-server model in which the consumption and supply of resources is divided.
Peers make a portion of their resources, such as processing power, disk storage or network bandwidth, directly available to other network participants, without the need for central coordination by servers or stable hosts.
Each workstation, or node, has the same capabilities and responsibilities.
Used for many applications including content distribution. This includes software publication and distribution, content delivery networks, streaming media and peercasting for multicasting streams, which facilitates on-demand content delivery.
In P2P networks, clients both provide and use resources. This means that unlike client-server systems, the content serving capacity of peer-to-peer networks can actually increase as more users begin to access the content (especially with protocols such as Bittorrent that require users to share. This property is one of the major advantages of using P2P networks because it makes the setup and running costs very small for the original content distributor.
Peers exchange lists of known peers (may have a central peer list).
Client/Server Peer-To-Peer

21. Peer-to-Peer [cont]
No single point of failure (or accountability/liability).
Scalable. Clients both provide and use resources. Content serving capacity of peer-to-peer networks can actually increase as more users begin to access the content
With peer-to-peer, adding clients increases the capacity of the system as a whole. With Client/Server, adding clients reduces resources available to each one.

22. Publisher / Subscriber
For certain applications, client/server may be inefficient. For example, what if a consumer needs some data from a producer when it becomes available? Polling the producer would be inefficient.
Publisher/Subscriber is essentially the same as Observable/Observer but applied at the level of the whole system.
Subscribers register their interest in events from publishers. When the event occurs, publishers notify all registered subscribers. Publishers may push items of interest to subscribers or simply notify them data is ready leaving them to query for the data.
Also known as implicit invocation.

23. 3-Tiered
The 3-tier architecture style is an evolution of the 1-tier and 2-tier computing:

24. N-Tiered Business logic may be further subdivided into:
Business Process
Business Transactions
The business process tier works by sequencing more primitive business transactions
Database tier may be subdivided into:
Data Access Layer (Table Data Gateway, Row Data Gateway, Active Record, etc.)
Relational Database
Process: move money between accounts could result in 2 or more transactions.

25. Layered
Rotate the n-tiered architecture style 90 and you get the layered architecture style!
Each layer provides services to layers above using services from layers below.

26. Examples
Post from Slashdot that illustrates the value of a good architecture (and how technology has a direct impact on business):
“I remember when I was working in a large bank that went thru a merger of equals many years back.
The other bank is a Sybase shop with "enterprise" licensing based on total staff numbers.
Within a week of the merger, Sybase came knocking claiming that the bank now owes them USD 50 million because total staff numbers have basically more than doubled due to the merger.
To put that in perspective it was a few times larger than the then largest contract which was with Microsoft involving every windows desktop, laptop, windows server, office and other Microsoft stuff.
The CIO was so pissed that he had to spend all his time negotiating a new contract for the first month of the merger instead of actually planning the technology integration.
Naturally he ordered the bank to completely get rid of Sybase within 3 years. After 3 years, Sybase was almost completely gone except for a few trading systems that had major problems and risks moving.”
“Each layer uses the functionality offered by lower layers to realize its own functionality”
OS abstraction example: file system separation character.
ISO OSI Reference Model. Typical layered architecture style for business data processing applications.
[TBD: Add a diagram for layers recommended in 4+1 paper:
4+1 view paper recommends 4-6 layers in the development view.
Another layering:
User Interface
Application features and functionality
Domain-specific software services
Domain-independent utilities and support objects
5. User interface and interface to external systems
4. Application functionality
3. Domain specific set of support classes
2. Domain independent high-level services
Domain independent low-level services and utilities
1 and 2 give a insolate application logic from hardware platforms, operating systems and off-the-shelf products like databases.

27. Android system is designed around layered architecture style
I think blue is Java. Green is C/C++.

28. Layer Styles Two main styles:
Strict layering – each layer is allowed to communicate only the layer directly below it.
Relaxed layering – a layer may communicate with any layer below it.
The preference is for each layer to use only the layer below it. “Layer-skipping” dilutes the value of following this architecture style.

29. Define an interface for each layer
Access to a layer should be confined to the interface for the layer. (Façade design pattern.)
Defining an interface onto each layer improves information hiding. Changes within a layer that don’t effect the services promised through the layer’s interface, can be made without impact to other layers.
Each layer or group of functionalities is encapsulated and can evolve independently
Partitioning criteria: abstraction, granularity, hardware distance, and rate of change.
“The specific partitioning criteria can be defined along
various dimensions, such as abstraction, granularity, hardware distance,
and rate of change. For example, a layering that partitions
an architecture into presentation, application logic, and persistent
data follows the abstraction dimension. A layering that introduces a
business object layer whose entities are used by a business process
layer follows the granularity dimension, while one that suggests an
operating system abstraction layer, a communication protocol layer,
and a layer with application functionality follows the hardware distance
dimension. Using rate of change as a layering criteria separates
functionalities that evolve independently of one another.”
Multiple dimensions combined: presentation, application logic, and persistent data layers is a layering according to both levels
of abstraction and rate of change.
“Provide all layers with an interface that is separate from their implementation, and within each layer program using these interfaces only when accessing other layers.”
From page 185 of Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing, 4th Volume.

30. Layered vs. N-Tier What’s the difference between Layers and Tiers?
Layers are organized by the level of abstraction they provide. Tiers are organized by the service they provide.
Tiers tend to represent a physical distribution.
The two styles can be combined. One tier in an n-tiered architecture can be structured according to the layered architecture style.

31. Pipes and Filters
A structure for systems that process a stream of data.
There are filter components that perform some transformation from inputs to outputs and pipes which are the conduits for data traveling between filters.

32. user@machine> cat email-data.txt | grep "^From" | sort
Examples
Unix Operating system
cat -data.txt | grep "^From" | sort
Compilers
With the Unix operating system, components are processes. A pipe is an operating system construct that allows text communication between processes.
Lexical analyzer (convert a stream of characters to tokens) ==> Parser (create a syntax tree from the tokens) ==> Semantic Analyzer (annotate the syntax tree with semantic information) ==> Code generator (emit code from the syntax tree).
TBD: Add unit command for removing duplicates.

33. Characteristics
Filters must be independent. One filter should not share state with another.
Filters don’t know identity of up or down stream filters. Loose coupling!
Filters may act as a buffer but may also be as simple as a procedure call.
Data flows one-way through a pipe (i.e. pipes are unidirectional).
For maximum advantage, filters should be allowed to communicate only through pipes
Benefits: simple modularization. Support reuse and reconfiguration. Easy to parallelize.

34. Batch Sequential
One variation on the pipes filter architecture style is batch sequential.
With batch sequential each step must finish before the next is allowed to start. With the more general pipes and filter architecture style filters begin processing as soon as data is available and filter process data in parallel.
Batch sequential is one of the oldest forms of data processing.