You are here: Home > Knowledge Base > Software Engineering Blog > Toward Decision Centric Repository of Architectural Knowledge
 
Newsletter
Newsletter
(Required)
Log in


Forgot your password?
 

Toward Decision Centric Repository of Architectural Knowledge

One of the topic we are working on is software architecture evaluation. Recently we have been focusing on incremental architecture evaluation method. One of the key supporting techniques is a use of the architectural knowledge repository for storing the evaluation findings and refine the architecture continuously. Therefore, we have proposed a model of repository which central concept is design decision. This work was presented at CEE-SET'09 conference. If you would like to know the details read this article.

As we have been working on iterative architecture evaluation method (ADAPT) the bunch of questions have appeared. How to deal with the evolution of the architecture? How to maintain the consistency of architectural descriptions in iterative architecture refinement? How to manage changes in requirements or architectural decisions? How to improve the risk assessment regarding each change?

The first steps have lead to us to the standards ISO 1471 and its successor ISO/IEC 42010. ISO 42010 shows the change of direction in how we think about software architecture. In the standard design decision based description is presented as an endorsement to the classic view-based description. Design decision is a very intuitive yet powerful concept. ISO 42010 (WD3) defines it as "a choice made that addresses one or more architecture-related concerns and affects (directly or indirectly) the architecture". With the use of decision we are looking at the architecture as a set of the problem-solution entities. In fact this is not a set but rather a graph.

However both view and decision centric approaches how some drawbacks. With the use of views is easy to show the overview of the system from the perspective of some concerns. However is hard to see the specific design decision and prevent knowledge vaporisation. Design decision model is able to capture additional knowledge is easier to manage (and keep the consistency of description) and navigation. However sometimes is hard to see what exactly we are building without browsing a whole space of decisions.

layered model of knowledge repository Therefore, we decided to mix these two approaches for the purpose of the repository model. First of all we have decided to focus on decision centric model for describing a knowledge. We have also added the overview of the system in a form of the system components (in the repository it is called architectural frame). Design decision space is structure with the use of links between decisions and the architectural frame components. Design decisions are interrelated on two axis: direct dependencies in the problem-solution space, and indirect dependencies with the use of decision-component mappings. This links between artefacts and the compositional structure of both layer help us to deal with the evolution of the project knowledge (eg. change impact assessment) and knowledge reuse (eg.solution search in historical data).

If you would like to know more details about the method they can be found in following presentation (please enable the comments).

You could also look at the paper.

 

This is a description of the initial work on the model. I would be thankful for any questions, comments, and suggestions.

Document Actions
Supporting only the best, so that they can become even better