These are my notes from the Chapter 2 from the book "Software Architecture: Foundations, Theory and Practice".

Now we will see how Software Architecture relates to Software Engineering.

We will reorientate these concepts away from their typical understanding. We will see that the architecture is most important.

1. Every app has an architecture
2. Every app has an architect
3. Architecture is not a phase of development

Architecture is set of principal design decisions made about a system; characterization of the essence of the application.

The traditional and inaccurate interpretation is that the architecture is the product of particular phase in development, called preliminary design (or high-level design, product design) - but this term is in fact much broader.

Now we will discuss the architecture in context of waterfall process:

1. Requirements

- in theory the requirements should be isolated first, then the solution found and implemented; but in practice requirements analysis is done in quick, superficial manner, or not at all; why is that so? they explain it by tight schedules, budget constraints, ... but the real reason might just be that requirements do not create value, products do; and after that the marketing people need to match the product to the needs, and even create the needs if neccessary..

(...)

...in some way current architectures drive the requirements - as we can see what have been done so far, how it works, what can be done and how; they provide a frame of reference, a vocabulary, also a base for improvements - to create new architectures; this works only for majority of cases, but it can happen the thing is a greenfield development (with no architecture predecessor), though we have to be careful and extensively search for existing solutions before assuming the problem is totally new.

2. Design

Design is the phase of taking the principal design decisions (the most important ones are taken now, the others can be taken later), with placing emphasis on architectural concerns.

(...)

Design techniques:

1. OOD - Object Oriented Design (...); this has also limitations
   - it is not a complete design approach, i.e. it does not say anuything about many things, like security, use of commercial components
   - it tries to view everything as object (so?!)
   - it's very bound to programming language, so the programming language can start dictating what the important decisions are
   - concern for concurrency is outside OOD purview
   * UML helped to lift the discussion of OOD above the programming language
2. DSSA - Domain Specific Software Architecture
   - used when prior experience and prior architectures can strongly influence new project
   - DSSA is consistent with development of product lines
   - while extracting the reusable parts very careful approach must be taken

3. Implementation

The task is to create machine-executable source code that is faithful to the architecture. The important things about implementation in architecture-centric view of SE are:

• the implementation activity may add to or modify the architecture
• architecture does not have to be completed before implementation begins - the only constraint is to keep the code consistent with the recorded architecture

What is faithful implementation:

• all structural elements in architecture are found in source code and vice versa
• the source code cannot contain connections not present in the architecture

Techniques for assisting in faithful development from the design:

• generation technologies
  - if only available, is the best, as it ensures consistency between the architecture and the implementation; an example is parser generators
  - this is only feasible in domains which are thoroughly understood and bounded
• frameworks
  - used when there's no generation available
  - acts as a bridge between desired architecture style and implementation
  - framework selection is a part of architecture-based system implementation; if there's no suitable framework, start from creating one by yourself
• middleware
  - it's software supporting communication between software components; it corresponds to the connectors
  - e.g. CORBA, RPC
• reuse
  - it is ideal case when certain old component perfectly matches desired architecture; but in reality we need to make choices, depending to what extend it dismatches; we can encapsulate old component in new one, exposing only desired functionalities; we can change the architecture concept to match including the old component; or just give up on reuse and write the component from scratch

When none of the assisting techniques are available for some reason, the whole software must be implemented manually - but we need to watch out not to make the real software architecure not consistent with the documented one; If we do not, then we can:

• not be able to reason about implemented application architecture
• mislead all stakeholders
• doom any further development based on the documented architecure to failure

4. Analysis and testing
It is an activity taken in order to asses the quality of an artifact. In traditional waterfall model the code is first written and then tested; however, testing does not have to happen after implementation, it can be integrated into development process; as the earlier the errors are discovered the lower cost of correcting them;

Architecture-cenetered approach offers the opportunity for early analysis; we can test not only functionality but also properties; what exactly can we test about architecture model:

1. consistency, correctness, exhibition of desired non functional properties, and internal consistency (e.g. by dataflow analysis on the architecture)
2. consistency with requirements
3. we can base our choice for source code testing and analysis methods based on the architecture model; architecture can also provide guidance and economies in development of test harnesses (automated test frameworks); (...)
4. it can help in detecting inconsistency between architecture model and the model derived from implemented code

It all is to asses and improve the quality of systems.

5. Evolution (maintenance)

This is all the activities that chronologically follow the release of an application, for example bug fixing, major additions of new functionality, creation of specialized versions of the application;

The thing is: whenever a change is required, we should go back to the phase where the issue is considered in - for example if we need new functionality, we should go back to the requirements phase - and then moving forward in sequence from there. But, in practice usually only the coding phase is revisited, as this is the easiest solution - but this results in degradation of application's quality.

What does the architecture-centric approach to software development offer here:

• before we change anything, we need to have deep understanding, do analysis of the problem and proposed change, etc; therefore,
  - if we have a clear architecture and its faithful implementation then it is easier to do it
  - if we don't have any clear architecture specified, or the code is inconsistent with the specified one, we need to do reenginering first (code=>requirements=>architecture design=>new code) - which is tough, costly and time-consuming
• after the analysis, we come up with different solutions to the problem and choose the best one; before making any changes to code we need to modify the architecture model (not the oppposite!) - to keep them consistent

Processes

Software Architecture is not a phase of software development.

(...)

Turbine Visualisation of Software Development

This model is to highlight the central role of software architecture. The axis of the core is time and the core itself represents the product. The rings around the core represent the development phases and effort. The ring's height stands for the time spent for that phase, and the ring's volume is for investment made during that ring.

• we can represent the particular stage of development by showing a cross-section of the turbine - then in the core we can place the already existing elements of the software (e.g. reaquirements, design document)
• we can have the core already having some thickness at the beginning - that means we already have some knowledge and resources carried forward from previous projects
• one ring can be composed of several parts when cross-sectioned

* Agile development does not in fact produce any particular architecture; therefore it is hard to resuse or maintain such software;

Tween Peaks Model (Nuseibeh, 2001)

(this model is two pyramides, the one on the left is Requirements, and on the right is Architecture, and the more down the more in detail it is, and the development goes from up to the bottom, going from one pyramid to the other, and back..)

• it emphasizes the co-development of requirements and architecture, incrementally elaborating details
• it represents recent work in requirements engineering

* Brook's law: "Adding people to late software makes it late" - and architecture-centric approach helps to reduce that problem! (a little..;))

A sum up

The success of a software is highly correlated to good architecture. Although many companies tend to focus on the software development process itself, and on improving it - the primary focus should be the architecture, not the process, as the architecture it the thing that generates the revenue (dochód) for a company.

Want to leave a comment? Visit this post's issue page on GitHub and just post your comment as the issue's comment (you'll need a GitHub account. What? Like you don't have one yet?!).