Difference between revisions of "Software Architecture"

From Suhrid.net Wiki
Jump to navigationJump to search
Line 33: Line 33:
 
* Domain specific software architectures can be developed.
 
* Domain specific software architectures can be developed.
 
* Process becomes oriented towards component assembly rather than programming.
 
* 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.

Revision as of 06:44, 19 March 2012

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.