Software Architecture

Introduction to Software Architecture

• Software architecture encompasses the set of significant decisions about the organization of a software system :
  • Selection of structural elements and their interfaces by which a system is composed.
  • Behaviour as specified in collaborations among those elements.
  • Composition of these structural and behavioural elements into larger subsystem.
  • Architectural style that guides this organization.

• Definition:
  • The structure or structures of the system which comprise of software elements, the externally visible properties of those elements and the relationships among them.

Why Architecture

Communication

• There are different stakeholders (client, user, project manager, developer, maintainer) who want different qualities of the system being built.
• E.g. client is concerned about cost, user about usability, project manager about dividing work, developer about implementation and maintainer about making changes.
• An architecture provides a framework and structure for airing these concerns.

Capture early design decisions

• An architecture constrains implementation.
• An architecture can help to determine organisational structure.
• Allow apriori reasoning about change.
  • Probably the most important - since 80% of software cost occurs after deployment.
  • Enables risk assessment of future project changes.
• Support analysis and prediction about future properties.

Reusable abstraction of systems

• The earlier a software artefact can be reused, greater the payoff.
• Architectural reuse - means not only reuse code, but also requirements and development experience.
• Domain specific software architectures can be developed.
• Process becomes oriented towards component assembly rather than programming.

Problems due to lack of architecture

• Costly maintenance - prone to side effect problems.
• Evolution not possible and reuse difficult.
• Inefficient or infeasible
  • Arch may partition the work in such a way that every engineer must communicate with every other engineer.
  • Throughput problems - processing bottlenecks, etc.

Influences on architecture

• Software architecture is a result of technical, business and social influences.
• System stakeholders.
• Developing organisation.
  • Org may have a business investment in certain assets.
  • May wish to make a long term business investment.
  • The organizational structure can shape the software architecture.
• Background and experience of architects.
• Technical environment.

Software process and the architecture business cycle

1. Develop a business case for the system
2. Understand the requirements
3. Create or select the architecture
4. Document the architecture
5. Analyse or evaluate the architecture
6. Implement the system based on the architecture
7. Ensure that the implementation conforms to the architecture

Process Recommendations

• Arch should be the product of a single architect/small group of architects
• Architect should have functional requirements and a prioritized set of quality attributes.
• Arch should be well documented with at least one static view and one dynamic view.
• Arch should be analysed.
• Arch should result in a specific (and small) set of resource contention areas.

Structural Recommendations

• Well defined modules.
• Well defined interface that encapsulates changeable aspects.
• Quality attributes should be achieved using well known tactics specific to each attribute.
• Arch should never depend on a specific version of a commercial product or tool.
• Data producing modules should be different from data consuming modules.
• For parallel processing systems, arch should feature well defined processes.
• Should feature a small number of interaction patterns.