Tech Kaizen: Introduction to Software Architecture

Software Architecture:

Software architecture is a description of a software system in terms of its major components, their relationships, and the information that passes among them. In essence, architecture is a plan for building systems that meet well-defined requirements and, by extension, systems that possess the characteristics needed to meet those requirements now and in the future.

A fundamental purpose of software architecture is to help manage the complexity of software systems and the modifications that systems inevitably undergo in response to external changes in the business, organizational, and technical environments.

We like to describe architecture as having to answer three main questions:

1. What are the important concepts?

2. What are the relationships among them? How do these relationships describe the behavior of the system?

3. How do the concepts and relationships provide value higher up? How do they serve the purpose of the overall system rather than the purpose of the individual parts?

An architectural style is a family of architectures related by common principles and attributes. In other words, an architectural style contains a well-defined set of patterns that constitute a common way for enterprise solution components to interact with one another. For example, we consider client/server, 3-tier, n-tier, and enterprise application integration (EAI) approaches all to be architectural styles.

There is a saying in the industry that "any problem in computer science can be solved by adding a layer of abstraction." An abstraction layer provides indirection between two layers, allowing for increased flexibility. Typically, the abstraction also provides a higher level of interaction. For example, rather than writing directly to a database, you write SQL, which provides a higher-level interaction model, as well as an abstraction and indirection layer above the lower-level database interfaces. The abstraction provides higher productivity (in the sense that one SQL statement corresponds to many invocations of the lower-level database interfaces) and also supports multiple different datastores.

Software Architecture = {Elements, Form, Rationale}

Elements
– Processing Elements are components that supply transformation on Data Elements
– Data Elements are components that contain information that is used or transformed
– Connecting Elements are the glue that hold different pieces of architecture together

Form
– Properties: Constraints on the elements to the degree desired by the architecture
– Relationships: Constraints on how the different elements will interact and how they are organized with each other
– Weight: Importance of the property or the relationship and the alternatives

Rationale
– Underlying basis for various choices made in defining the architecture
– Explains the satisfaction of basic functional aspect to nonfunctional Requirements

Example

A complier that is organized sequentially

The Multi-phase Architectural Style

– Elements
• Processing: Lexer, Parser, Semantor, Optimizer, Code Generator
• Data: Characters, Tokens, Phrases, Correlated Phrases, Annotated Correlated Phrases, Object Code

– Form
• Property: Optimizer and Annotated Phrases must be found together
• Weight: Optimizer and Annotated Phrases are preferred elements not necessary
• Relationship: Linear relationship between Character & Token, Token & Phrase. But non-linear between Phrase and Correlated Phrases

Ref: