Software Architecture

1. Software Architecture

2. The Role of Architecture

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.

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]

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 thatthe desired non-functional requirements have been met.

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

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

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

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.

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.

16. Patterns at different levels of design

17. Common Architecture Styles • Client/Server • Publisher/Subscriber • 3-Tier or, more generally, N-Tier • Layered • Pipes and Filters

18. Client / Server • C/S is a distributed computing architecture style. • As the architecture style behind the WWW and email, 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), email (SMTP), Database access (proprietary protocol).

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.

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

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

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

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

24. Examples

25. Android system is designed around layered architecture style

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

27. Define an interface for each layer

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

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

30. Examples • Unix Operating system user@machine> cat email-data.txt | grep "^From" | sort • Compilers

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

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