Software Architecture #2

My previous blogpost start from the house picture - as analogy about architecture. But I found some problems with this analogy:

• There is no software construction industry in the same degree that there is for buildings. The building industry has substantial substructure, reflection numerous specialisations, skill sets, training paths, corporate organisations, standards bodies, and regulations. While the software industry has some structure, including that seen in offshore development practices, it is much less differentiated than the building industry
• The disciple off architecture does not have anything akin to the issue of deployment in software: Software is built in one place, but deployed for use in many places, often with specialisation and localisation. Manufactured building, otherwise known as trailers, are somewhat similar, but still there is no corresponding notion to dynamic distributed, mobile architectures, as there is with software
• Software is a machine; building are not (notwithstanding Le Corbusier's declaration that, "A house is machine for living in"). The dynamic character of software - the observation that led to Edsger Dijkstra's famous "goto statement considers harmful" paper (Dijkstra 1968), provides a profoundly difficult challenge to designers, for which there is not counterpart in building design

Fundamental understanding

There are three fundamental understandings of architecture, the recognition of which helps situate architecture with respect to rest of software engineering:

• Every application has an architecture
• Every application has at least one architect
• Architecture is not a phase of development

All applications do have architectures because they all result from key design decision.
The architect is the person, or in most cases, group who makes the principal decisions about applications, who establishes and (it is hoped) maintains the foundational design.
Architecture refers to the conceptual essence of an application, the principal decision regarding its design, the key abstractions that characterise the application.

Requirements

Consideration of architecture rightly and properly begins at the outset of any software development activity. Notions of structure, design, and solution are quite appropriate during the requirements analysis activity.
In waterfall model, indeed in most process models, the initial phase of activities is focused on developing the requirement for an application - the statement of what the application is supposed to do.

• Existing design and architecture provide the vocabulary for talking about what might be
• Understanding of what works now, and how it works, affects our wants and perceived needs, typically in very solution-focused terms
• The insights from experiences with existing system helps imagine what might work and enable to assess, at an early stage, how long we must be willing to wait for it, and how much we will need to pay for it

Design

Designing is, by definition, the activity that creates a system's software architecture -its set of principal design decisions.

• The traditional design phase is not exclusively "the place or the with" when a system's architecture is developed - for that happens over the course of development - but it is a time when particular emphasis is placed on architectural concerns.
• Since principal design decisions are made throughout development, designing must be seen as an spect of many other development activities
• Architectural decisions are of many different kinds, requiring a rich repertoire of design techniques

The architect must deal, for example, with:

• Stakeholder issues, such as choices concerning the use of proprietary, commercial off-the-shelf or open-source components, with their attendant and varying licensing obligation
• Over arching style and structure
• Types of connector for composing subelements
• Package and primary class structure(this, is low-level style and structure when working in an object-oriented development context)
• Distributed and decentralised system concerns
• Deployment issues
• Security and other nonfunctional properties
• Post-implementation issues (means for supporting upgrade and adoption)

Design techniques

Object-oriented design

Object-oriented design (OOD) is usually tight in the context of object-oriented programming, that is, reduction of an algorithm to machine-executable form. The essence of OOD is the identification of so-called objects, which are encapsulations of state with function for accessing and manipulation that state. Numerous variations are found in different object-oriented programming languages regarding the way object are specified, related to one another, created destroyed, and so on.

• OOD views all application as consisting, solely, of one software species (namely, "object"), regardless of purpose. Forcing all concepts and entities int a single mold can obfuscate important differences. The REST style, for instance, maintains distinct notions of "user agent", "origin-server", and "cache". Apart from using programming language types to try characterise these distinct elements, OOD does not offer any helpful modelling mechanism.
• OOD provides only one kind of encapsulation (the object), one notion of interface, one type of explicit connector (procedure call), no real notion of structure (objects are constantly created and destroyed), and no notion of required interfaces. This implies that all richness of a given solution approach has to be mapped down or transformed to this level of single choice. Some architectures such as pipe-and-filter-may not be at all effective after such transformation
• OOD is so closely related to programming language concerns and choices that it tends to have the forest obscured by the Rees. For instance, the vagaries of type inheritance may obscure identification of principal objects critical to the design. Similarly, it is so bound with programming language issues that the language may start dictating what the important decisions are.

Domain-Specific Software Architectures

This approach known as domain specific software architecture, is appropriate when prior experience and prior architectures are able to strongly influence new projects. The key notion is that if a developer or company has worked within particular application domain for many years, it is likely that a best approach or best general solution for application within that domain will have been identified. Future application in that domain can leverage this knowledge, whit those application having their fundamental architecture determined by the architecture of the past generation applications. The technical essence of the domain-specific software engineering approach is to capture and characterise the best solutions and the best practices from past projects within domain in such a way that production of new applications can focus more or less exclusively on the points of novel variation.
To effectively follow the DSSA approach, good technical support is required: The architecture of the previous generation of application must be capture and refined for reuse; the points of allowable variation must be identified and isolated, the interfaces between the points of variation and the core architecture must be made explicit, the dependencies between multiple points of variation must be identified, and so on.

Implementation and implementation strategies

The task of the implementation activity is to create machine-executable source code that is faithful to the architecture and that fully develops all outstanding details of the applications. This is true whether speaking from the perspective of classical forward engineering or from the software architecture-centric view of software engineering.
First, the implementation activity may add to or modify the architecture - if key design decisions are made while working with the source code, they are part of the architecture as much as any principal decision made much earlier in the process. Second, there is no presumption that architecture is completed before implementation begins.
The source code:

• Must not utilise major new computation elements that have no corresponding elements in the architecture
• Must not contain new connection between elements of the architecture (for example, such as might be motivated by efficiency concerns) that are not found in the architecture

The implementation does have an architecture: It is latent, as opposed to what is documented.
Failure to recognize this distinction:

• Robs one of the ability to reason about the implemented application's architecture in the future.
• Misleads all stakeholders regarding what they believe they have as opposed to what they really have
• Makes any development or evolution strategy that is based on documented but inaccurate architecture doomed to failure

Analysis and testing

Analysis and testing are activities undertaken to asses the qualities of an artifact. One of the virtues of conduction analysis before code exists is cost savings: The earlier an error is detected and corrected, the lower the aggregate cost.
First, the structural architecture of an application can be examined for consistency, correctness, and exhibition of desired nonfunctional properties. If the architecture upon which the implementation is (later) based is of high quality, the prospects for a high-quality implementation are significantly raised
Second, the architectural model may be examined for consistency with requirements. Regardless of whether the requirements were developed in the classical way (that is, before any development solution notions).
Third, the architectural model may be used in determining and supporting analysis and testing strategies applied to the source code
Fourth, there architectural model can be compared to a model derived from the source code of an application. This is a form checking your answer.

Evolution and maintenance

Software evolution and software maintenance - the terms are synonymous - refer to all manner of activities that chronologically follow the release of an application. There range from bug fixes to major additions of new functionality to creation of specialised version of the application for specific markets or platforms.
The typical software engineering approach to maintenance is largely ad hoc. In a best-practices situation, each type of change cause the software process to return to whatever point. Thus, if new functionality is requested, the requires returning the requirements analysis phase and then moving forward sequence from there.

The design process

The typical assumption of software design is that the process can proceed in general manned of architectural design or engineering design, which can be summarised (Jones 1970) as consisting of the following four stages

1. Feasibility stage: Identifying a set of feasible concepts
2. Preliminary design stage: Selection and development of the best concept
3. Detailed design stage: Development of engineering description of the concept
4. Planning stage: Evaluation and altering the concept to suit the requirements of production, distribution, consumption and product retirement