Difference between revisions of "Software Architecture"
From Suhrid.net Wiki
Jump to navigationJump to searchLine 52: | Line 52: | ||
* Background and experience of architects. | * Background and experience of architects. | ||
* Technical environment. | * Technical environment. | ||
+ | |||
+ | = Software process and the architecture business cycle = | ||
+ | |||
+ | # Develop a business case for the system | ||
+ | # Understand the requirements | ||
+ | # Create or select the architecture | ||
+ | # Document the architecture | ||
+ | # Analyse or evaluate the architecture | ||
+ | # Implement the system based on the architecture | ||
+ | # Ensure that the implementation conforms to the architecture |
Revision as of 06:49, 19 March 2012
Contents
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
- Develop a business case for the system
- Understand the requirements
- Create or select the architecture
- Document the architecture
- Analyse or evaluate the architecture
- Implement the system based on the architecture
- Ensure that the implementation conforms to the architecture