Software Architecture

Definition of Software Architecture (IEEE 1471-2000)
The fundamental organization of a system [as] embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.


Where does software architecture fit in?

Rational Unified Process (RUP)

Software architecture becomes increasingly important as the size of the code base and project increases. This doesn't mean that you should neglect the architecture of a project until it becomes too difficult to manage. In the context of the Rational Unified Process (RUP), the architecture would be considered between the requirements and implementation phases, effectively during the analysis and design stage. In terms of the design, the architecture can be viewed as the top-level design which is then further elaborated upon in the detailed design (Class diagrams, System Sequence diagrams, etc...). Naturally, since the architecture can be viewed as the top-level design, and fits into the RUP just after the requirements phase has commenced, a highly dependent relationship exists between the two phases. As we've seen above, architecture can be viewed as a form of design, but it should be noted that not all design activities are architectural activities. The levels of  design, from the top-most layer are, architectural design, detailed design and lastly the implementation (executable designs).

Benefits of an Architectural Design
- Reduced rates of failure
- Qualify rationale for architectural decisions
- Outline and mitigate risks
- Schedule and cost projects more effectively
- Useful for learning about the system
- Re-use of architectural styles
- Increases maintainability

Requirements Versus Design

Requirements Artifacts	Design Artifacts
Domain Model	Software Architecture Document
Use-Cases	Design Model
Non-Functional Requirements	User-Interface Design

How To Start Your Design
A natural way to begin the design is to build on some of the work that you've already put in. The domain model is an excellent place to create the first approximation of the design  as it guides the designers into crafting a solution with a minimal representational gap. Whenever tasked with creating a design for a software project always consider whether this same type of application has been created in the past. If so, then analyze how the current solutions are implemented and make use of whatever code or structure is available. Quite often an architectural style will have already been applied to the problem which you may likely want to re-use.

Common Architectural Styles
Data-Flow	Data-Centered	Virtual Machine	Call and Return	Independent Components
Pipes and Filters	Repository	Interpreter	Main Program and Subroutine	Communicating Processes
Batch Sequential	Blackboard	Rule-Based System	Object-Oriented (& Data Abstraction)	Client/Server
			Layered	Event Systems
				Implicit Invocation
				Explicit Invocation

Conceptual Integrity
"I will contend that Conceptual Integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."

- The Mythical Man-Month, by Fred Brooks, 1975


Enterprise Applications
Generally, enterprise applications form a class of software solutions that deal with large volumes of complex data that is persistent and concurrently accessed by many users and or applications. The software does not usually have strong hardware/software integration requirements. A common approach to constructing enterprise applications is to use the layered or client-server architecture.


Enterprise Application Architectural Styles
As we've just seen, two very common architectures are often employed in the construction of enterprise applications. We'll now take a closer look at both styles.

Layered Architecture
At the most basic level, the layered approach typically consists of at least three layers: presentation,  domain and data source. As far as functionality is concerned in the this architecture, lower level layers service requests from higher ones, thus providing functionality upwards from the bottom. Dependencies however move in the opposite direction from higher level layers to lower ones. One variation of the classic layered style exists, the pure layered style, where the dependencies are further restricted by allowing higher level layers to depend solely on services from components within the same layer or the layer immediately below.

Presentation 

------------------------------

Domain

------------------------------

Data Source

Client-Server Architecture
Client server applications, such as a web browser will usually utilize the Internet for communications. We'll provide a few quick definitions of what exactly we mean when we say the Internet versus the web. The Internet is the hardware infrastructure in which the web operates. The web is just software along with a set of associated protocols. As an example, Hyper-Text Transport Protocol (HTTP) is a stateless and fairly simple request-response protocol that is used extensively on the web. Now that the Lingua Franca has been defined we can better understand the interaction between the clients and servers. A client is responsible for sending HTTP requests to severs, while servers have the task of sending HTTP responses. A web server is a piece of software which implements the web protocols (i.e. HTTP). The clients (more software) make requests using the web protocol to the web servers and receive responses. Web servers can only serve static content, thus helper applications are needed in order for the server to serve dynamic content. An example of one such helper is a Java Servlet. The typical environment in which Java servlets reside is Tomcat, a servlet container. In the weakest possible terms the role of Tomcat is to facilitate the interaction between the web sever and the servlets. Tomcat

HTTP Methods	Description
GET	get a resource a given URL
POST	basically a GET with extra parameters
HEAD	GET the header part of the response only
TRACE	loopback request message
PUT	put info at given URL
DELETE	delete the given URL
OPTIONS	list the HTTP methods the URL can respond to
CONNECT	This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).

The anatomy of an HTTP request, picture by Dr. Chalin

The anatomy of an HTTP response, Dr. Chalin

Pipes and Filters
The metaphor of pipes and filters can be directly applied as a software architectural style. A pipe carries a fluid through it until it reaches a filter. The filter then outputs it's modified fluid back into another pipe. In using this metaphor  as a basis for the software implementation say that a pipe should carry data between filters and a filter should accept data and output it to a pipe. The advantages of using this data flow style is that it assumes concurrent processing since output from a pipe can be continuously consumed by a filter while simultaneously outputting it's content to another pipe and ultimately filter. Each filters is independent all other filters, thus each filter maintains it's own state. Filters are thought of black boxes and are only responsible for accepting input in a specific format and outputting data in a specific format, thus filters can be swapped easily. No complex interactions exists in pipes, simple data transfers are the only responsibility of pipes. Some weaknesses of this style are that it's use can lead to batch sequential programming, it is also not well suited for interactive applications. As mentioned a data format must be defined for the input and output of the filters, thus additionally complexity is added to the filters for the encoding of decoding of outputs.

Variations of Pipes and Filters
Pipeline: A linear sequence of filters.
Batch Sequential System: A pipeline in which each filter runs to completion before the next begins.
Bounded Pipes: Restriction on the amount of data that can be temporarily in a pipe.
Types Pipes: The data passed between two filters is restricted to a well-defined type.
UI Pipes: Each filter is associated with a user-interface to allow the user to set parameters of operation.


Event-Based Architecture
Event-based programming is the chief architecture used in the development of graphical user interfaces. Someone clicks a button for instance and an event is fired notifying someone else that the button has been pressed and action must now be taken. It is also well suited for multi-core systems since events can be processed in a number of locations. UML2 has even made provisions for it within it's specification.

Components and Connectors
A component is an active or passive object, capsule or module. A connector is a callback, channel or binding. Notable component types are publishers and subscribers. A component does not explicitly invoke another component, instead an event is generated (message is passed). In order for a component to become aware of events stemming from another component it must subscribe or register with component. This relationship can be thought of as subscribing to a newsletter for instance. I must register myself on the subscribers list in order to be notified of updates. Once I am notified I can take whatever action I choose, read, disregard, forward, etc... A connector is tasked with carrying events being signals or messages from one component to another. Connectors can have a range of multiplicities with components, ranging from one-to-one to one-to-many, or many-to-one. The advantage of using this style is that it encourages code reuse through low coupling and provides opportunities for evolution as new components are introduced. Asynchronous communication is handled extremely well within this type of design. All of the weaknesses that arise in this architectural style stem from the lack of control components have over event processing. Components are restricted to simply generating events while a framework is tasked with the event dispatching. Furthermore, respondents to events are not ordered, sometimes making global system analysis more challenging. Asynchronous events explicitly highlight this problem. ow can we ensure that at least one object has processed an event? Another weakness associated with this style is a problem arising from the exchange of data between components which can lead to a resources management challenge.

Process Control
This architectural style is particularly well suited for modeling physical control systems. In this model software interacts with peripheral devices like sensors and actuators in order to control physical systems. This architecture can be applied in real-time, continuous, adaptable (load balancing) and control system environments. The disadvantages of this architectural style are that the reuse of components are often confined to one particular domain of the application and it can become difficult to adapt when are two or more interdependent processes to control.


Architectural Views

4+1 View Model

When analyzing the architecture of a system it is often most useful to consider the aspects of it relative to a particular view. A view is a fairly intuitive term in terms are architecture, it implies looking at something from a specific view-point. Naturally a single view-point cannot provide anyone with a complete picture, unless it is one dimensional, which large software projects are not.

"4 + 1" View Model of Architecture
This is one of the most popular view models conceived for software projects by Phillipe Kruchten in 1995.

View	Description	Artifacts
Logical View	The logical view is where the overall structure of the application is conveyed. Another way to characterize the logical view is to think of it as the interfaces to the environment in the most general of contexts.	- Package Diagrams - Class Diagrams - State Diagrams - Interaction Diagrams
Process View	The process view is used to paint a picture describing the underlying processes and tasks which are occurring within the system, as well as the channels of communication between them. The interrelationships amongst processes should be visible as well as the synchronization mechanisms.	- Class Diagrams - State Diagrams - Interaction Diagrams - Component Diagrams
Deployment View	The deployment view, sometimes called the physical view, is used to describe the hardware and software setup that is required by the system. In this view we gain an appreciation of how the hardware and software components are combined to form the deployed product.	- Deployment Diagrams
Implementation View	The implementation view, sometimes called the development view, provides perspective on the software's organization. The components of the system as well as their inter-dependencies are outlined within this view. Libraries, sub-systems, executables, object files, etc. are all commonly documented components in this view. The relationships are denoted through containment and dependencies, thus providing a high-level vantage point for observing the software's organization.	- Package Diagrams
Use Case View	The use case view takes it's place prominently in the middle of the above 4+1 view model diagram, and rightfully so. It is the use cases which necessitated the system in the first place thus any model would be incomplete without it's raison d'être. Each system is designed to satisfy the needs of some target user, and the use case view elaborates on the systems utility from the users perspective. Note that not all use cases will be represented here, only those with the most architectural significance.	- Use Case Diagrams

Siemens Four View Model
This view model prescribes activities that should be carried out within each view. The activities are, global analysis, central analysis and final analysis.

Global Analysis
1) Analyze factors
2) Identify Issues
3) Create Strategies

The purpose of global analysis is to identify issues early in the architecture so that strategies can be proposed to resolve them. Factors are further decomposed into the following three categories: Product, Organizational, Technological. Issues simply implies a potential problem or risk. Strategies alludes to a means by which an issue is resolved.

Organizational factors can be further decomposed into the following top level groupings:
management, staff skills, process and development environment, development schedule and finally the development budget.

Product factors are:
Functional features, user interface, performance, dependability, failure detection (reporting and recovery), service and product cost.

Design Principles
Definition of a good design: A good design satisfies all of the requirements and passes all tests. It is also as simple as possible and conveys intent. There is no duplication and it's easy to understand, verify, extend and evolve.

Fundamental software design principles:
- Information hiding (Parnas)
- Protected Variations (Larman)
- Open-Closed Principle (Meyer)
- Separation of Concerns (Dijkstra, Parnas)
- High cohesion (GRASP)
- Low coupling (GRASP)

Object Oriented Design Principles
Design based on responsibility assignment
- GRASP (Larman)
- Responsibility-Driven Design, RDD (Wirfs-Brock et. al.)
- Class-Responsibility Collaboration Card Design Technique (Kent Beck, Ward Cunningham)

General Responsibility Assignment Principles (GRASP)

Controller

Creator

Indirection

Information Expert

High Cohesion

Low Coupling

Pure Fabrication

Protected Variations

Polymorphism

Software Design Patterns
GoF Design Patterns

Behavioral Patterns	Creational Patterns	Structural Patterns
Chain of responsibility	Abstract Factory	Adapter
Command	Builder	Bridge
Interpreter	Factory Method	Composite
Iterator	Prototype	Decorator
Mediator	Singleton	Facade
Memento		Flyweight
Observer		Proxy
State
Strategy
Template Method
Visitor

Data Source Software Design Patterns

Row Data Gateway (RDG)

Table Data Gateway (TDG)

Active Record

Data Mapper

Document Object Model (DOM)
The document object model describes the structure of a document in a hierarchical context. Consider an HTML page, it is organized as a tree of tags, where the first tag is <html> and last tag is </html>. Thus this tag is the root of the tree which is then followed by the <head> and <body> tags. More complicated hierarchies of tags arise when we begin to consider cascading style sheets. They allow stylistic hierarchies to be created for web content and stored separately from the content itself, providing a layer of indirection. The tags in an HTML page can be generalized to the concept of nodes of which the following types exist.

DOM Node Types:
- Document
- Element
- Attribute
- Text
- Comment

Architectural Definition Languages
This field is currently under continuous research and has not yet come to reach it's full potential. The concept here is to create a new higher level language that could serve to define both the structure and behavior of a program leading to executable code. I should point out that the scenario of producing executable code has not yet been completely realized. At the moment the best that can usually be done is creating the skeletons of the classes with method and attribute placeholders that would later be filled in. Some applications of code generation however have been quite successful, Boeing reported to have generated 75% of the code that was developed for their new 747. A closely related field is Model Driven Architecture (MDA) and Model Driven Design (MDD). The most notable of players in the market is IBM with it's Rose platform.

There will be more to come on this post... very soon.