Software Architecture

What is Architecture about

Structure

  • Architect tries to partition a system into a set of related components, objects, modules or whatever unit of software or hardware that works for you.
  • Responsibility driven design is a good technique to find components of a system
  • An important architectural goal is to minimize dependency between components
  • Technology stack != architecture
  • s/w architecture presents a view of a system as components and connections. it completes the design with additional views.
  • Architecture is design but any design is not architecture.

Components and Communication

  • When an application is partitioned into components it is necessary to decide how they communicate with each other

Abstraction

  • Architect should be able to draw a marketecture of the whole system.

Non-functional Requirements

  • Technical Constraints: Only use Java
  • Business Constraints: We need to use Paypal
  • Quality Constraints: Application should have scalability, availability, portability, etc.

Architectural Structures & Views

View is a representation of a set of architectural elements and their relations but a structure is the set of elements itself. For example a module structure or a module view are different things but we use these concepts interchangeably.

Many authors have different sets of views that usually map to each other. Here I present two sets; one that emphasises mostly on decomposition, concurrency and deployment and the other set which is 4+1 model.

Architectural Structures (views) - Bass, Kazman, …

  • Modules (units of implementation): Decomposition, Class, Uses, Layers, etc
  • Component & Connector (runtime components and connections): Client-Server, Concurrency, Process, shared Data
  • Allocation (relations between software and external environment): Work Assignment, Deployment, Implementation

Points

  • The dominant structure is module decomposition. Major data flow relationships among modules are identified through this view.
  • One of the architect's goals is to understand how these structures lead to quality attributes.
  • The layered structure comes from the uses structure.
  • Components in component and connector view are instances of modules in modules view.
  • Component and connector view can identify more modules such as a resource manager to manage runtime resourcing.
  • Component and connector view usually shows instances of modules in the modules view.
  • To better understand concurrency we need to inspect scenarios where a user is performing two similar actions, two users are doing two similar actions, system is starting up or shutting down. These scenarios help us understand resource contention, data integrity issues, activity control issues, etc.

4+1 Model - Philippe Kruchten

The views are used to describe the system from the viewpoint of different stakeholders, such as end-users, developers and project managers.

  • Logical view: Describing elements of a system with their relationships
  • Process view: Concurrency and communication between elements of a system
  • Physical view: Mapping components to hardware
  • Development view: Mapping components to software packages and development environments
  • Scenarios: a small set of important use cases
320px-4%2B1_Architectural_View_Model.jpg
  • Depending on the importance of a particular quality attribute the architect wants to deliver he or she can introduce new views such as client-server view, fault tolerant view, etc. This totally depends on the project/architect/….
  • Usually the relation among views or mapping between them is very useful.

What does an Architect should know

  • Communication with the team and customer
  • Software Engineering and design
  • Technology
  • Risk Management

Reference Architecture/Model

  • Reference Model: Is a division of functionality together with data flow between the pieces. A reference model is a standard decomposition of a known problem into parts that cooperatively solve the problem. Arising from experience, reference models are a characteristic of mature domains. This should be created in initial phases. This is not the data model.
  • Reference Architecture: Is a reference model mapped onto software elements and the data flows between them. Whereas a reference model divides the functionality, a reference architecture is the mapping of that functionality onto a system decomposition.
  • Reference Model + Architectural Pattern — > Reference Architecture — > Software Architecture
  • A single function in reference architecture could possibly map to multiple components/tiers/functions in the software architecture.

What does an Architect do

  • Work with the analysis/requirement team
  • Work with various application stakeholders
  • Lead the technical design team
  • Work with the project management

Architecture Business Cycle

Is the cycle of relationship between the following groups and the way the effect on each other. These should be identified by the architect in advance and in detail.

  1. business
  2. stakeholders
  3. technical environment
  4. architect and architecture
  5. developing system at hand

Enterprise Architecture

TOGAF framework divides the practice into three domains:

  1. Business Architecture
  2. Information Systems Architecture (divided into "Information Architecture" and "Applications Architecture")
  3. Technology Architecture

Basically EA is the parent of TA and TA deal with software intensive systems while EA deal also with non-software domains too. See the following table from Wikipedia.

Enterprise_Architecture_Domains_Subdomains.jpg

Quality Attributes

See system quality attributes

Architecture Document

See Architecture Document

Architecture Design

see Architecture Design
see Software Design

Middleware

See middleware

Architectural Patterns

see Architectural Patterns

Architecture Reconstruction

  • Also called architecture recovery or extraction
  • Architectural constructs are not represented explicitly in the source code; We have the concept of layer in architecture but there is no notation of it in the code.
  • We need tools to analyse the static source code and also profilers to analyse the system in runtime and gather all the data in a relational database about : x calls y, x uses y, x creates y, etc. and then create architectural views/patterns out of these.

Architecture Evaluations

  • Architecture Trade-off Analysis Method (ATAM) is a method of architectural evaluation and analysis.
  • ATAM investigates how well the architecture has been designed with respect to the quality attributes important to it.
  • ATAM usually does not consider time/cost/human effort.
  • For ATAM we create a utility tree where the top level elements are quality attribute names and then goes down to quality attribute refinements and then quality attribute scenarios as leaves. For example:
  • ATAM uncovers architectural decisions and links them to business goals and quality attributes.
Quality attribute names (maintainability, performance, etc)
        Quality attribute refinements  (data latency, transaction throughput)
                Quality attribute scenarios  (lower storage latency on customer db to 20 ms). We have to specify stimulus/env/response/...
  • The output of ATAM is :
    • A set of risks
    • A set of sensitivity points and trade offs
    • Mapping of architectural decisions to quality requirements
    • A good presentation of the architecture
    • Quality requirements as a set of scenarios

Cost Benefit Analysis Method (CBAM)

  • Every architectural decision making should consider time/cost/human effort. CBAM builds on ATAM to model costs and benefits of architectural design decisions and is a means of optimizing such decisions. CBAM is an assessment of the technical decisions for economic decision making.
  • CBAM builds on ATAM and elicits costs/side effects associated with each architectural decision.
  • CBAM helps stakeholders choose architectural strategies based on their ROI - ratio of benefit to cost.
  • CBAM usually uses a SET of sceharios rather than individual ones unlike ATAM. This leads to the concept of utility-response curve.

Utility-Response Curve

  • Every stimulus-response pair in a scenario gives some utility to the stakeholder.
  • These graphs show how the utility (~benefit) from a particular response varies as the response varies. For example an availability graph might show that a little change in the response level results in a very small change in utility to user.
  • These graphs show utility as a function of the response value.
curve.jpg
  • We need to elicit the utility characteristics from the stake holders. They first can come up with best and worst case.
  • It is the job of the architect to come up with architectural strategies to go from the current quality response value to a desired one.
  • The benefit of apply an architectural strategy is the sum of its benefit to all quality attributes.
  • The ROI of each architectural strategy is the ratio of the total Benefit B to the cost C : B/C.
  • Architects can fight over-engineered requirements by the argument of cost.
  • See the steps of CBAM in the book.

Architectural Mismatch

It is about whether components work together or not. AM is a form of interface mismatch. Interface of a component is much more than its API. To better study a component's interface we need to investigate component's behaviour, side effects, etc.

When using a component we deal with two assumptions; "provides" assumptions (services a component provides) and "requires" assumptions (resources a components needs); When these two do not match then we have a mismatch between components.

Patterns such as wrapper, bridge, mediator in some cases can help fixing mismatches.

Further Reading

Reference

  • Essential Software Architecture, Ian Gorton
  • Software Architecture in Practice, Kazman et al.
  • Internet
  • Grady Booch
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License