WicsaWikiWANParty:WICSA Themes
From WICSA Conference Wiki
Contents |
WICSA Themes
Comment on one of the WICSA themes.
Architecture Analysis
Whenever software architectures are designed and evolved, there is also a need to verify and validate the software architecture. Architecture evaluation is concerned with architecture validation, i.e. comparing the designed software architecture with its requirements, and architecture verification, i.e. comparing the implemented software architecture with the designed software architecture.
For the purpose of validation and verification of software architectures, several different terms are used, i.e. evaluation, assessment, review and analysis. Although these terms have overlaps in their semantics in the software architecture community, for reasons of consistency, we provide definitions of these terms. Architecture analysis is the key element in architecture validation as its focus is on analyzing the implementation of a functional or quality requirement in the software architecture. Analysis, however, is an element in evaluation, assessment and review, as these consist of several more elements. Finally, architecture analysis is also part of architecture design as software architects, either implicitly or explicitly, analyze the result of their design decisions in relation to the requirement being addressed.
<This is just a first start to get some thoughts in here. Please rewrite, refine and extend>
Architecture Evolution
Any architecture that has a reasonable lifetime will have to deal with new requirements. Often the architecture will have to change to do that. Note that changing the architecture (in particular the architecture description) is not extremely costly, but implementing the modified architecture, in particular modifying existing assets (code etc.) often requires a major effort.
Although the term "evolution" in the context of architecture is sometimes used for changes during run-time, the term "software evolution" traditionally denotes long-term changes occurring due to maintenance etc., such as described by Lehman's so-called "laws" of software evolution. Typical for a long-lived system is the problem of "software aging" and "software deterioration" (or architectural/design dito), due to e.g. insufficient knowledge or time to modify the architecture. This means that as a piece of software ages, and is being maintained, it becomes harder and harder to maintain. Its conceptual integrity has been violated; it has become patched and mended beyond repair.
There are two extreme approaches to architecture evolution:
- Don't plan for the future at all, but change the architecture when it is needed.
- Try to make the architecture future-proof by anticipating all kinds of possible future requirements and build in mechanisms to deal with those requirements.
Both extremes have severe disadvantages: If you don't plan for the future, there is a high probability that a new requirement will come up that requires major changes. On the other hand, building in a mechanism to deal with a possible future change is often expensive, so doing this for many possible changes is extremely expensive.
Therefore the trick is to try to predict the future requirement changes. One way of doing is this is Scenario-Based Architecting.
Architecture in practice
Architecture Methods
- COPA
- Component-Oriented Platform Architecting
