M M M e er e rr ll l ii i n n n W W W h hi h ii tte t e e p p p a ap a p pe e e rr r
R R R e e e p p p o o o r r r t t t o o o n n n t t t h h h e e e t t t o o o o o o l l l e e e v v v a a a l l l u u u a a a t t t i i i o o o n n n o o o f f f t t t o o o o o o l l l s s s f f f o o o r r r p p p r r r e e e p p p a a a r r r a a a t t t i i i o o o n n n a a a n n n d d d a a a n n n a a a l l l y y y s s s i i i s s s o o o f f f s s s o o o f f f t t t w w w a a a r r r e e e a a a r r r c c c h h h i i i t t t e e e c c c t t t u u u r r r e e e s s s
The Merlin project addresses the increasing demand to find and discover new efficient ways to support collaborative embedded systems development. Embedded systems are increasingly developed globally in collaboration with partners, such as subcontractors, third party developers and also with in-house developers.
The Merlin project established working practices that build upon the benefits of collaboration but neutralise its negative effects. Central in this approach is the industrial application of technologies. No technology can be considered for industrial usage if there is no observed and proven experience of its benefit in practice. All Merlin results have been validated for applicability in specified industrial environments.
This white paper summarises one of the Merlin results: Evaluations of tools for the preparation and analysis of software architectures. In case you are interested in more information on the project or you are interested in the full deliverable, please get in touch with us via the web-site: http://www.merlinproject.org/
Also we are interested in your opinion or feedback. Our contact details can be found on the Merlin web-site.
Authors:
Teemu Kanstrén, VTT Pentti Tarvainen, VTT
Merlin
- Embedded Systems Engineering in Collaboration
The Merlin Consortium consists of:
Incode, Ericsson, LogicaCMG, Lund University, Nokia, Philips, Solid, Sony Ericsson, TU Delft, University of Oulu, VTT Technical Research Centre of Finland
© Copyright MERLIN Handbook
TABLE OF CONTENTS
TERMINOLOGY... 3
1. INTRODUCTION ... 4
2. BACKGROUND ... 5
2.1 Tool selection ... 5
2.2 QADA ... 5
2.3 Tool Validation Framework ... 7
3. TOOLS ... 9
3.1 The RAP Reliability and Availability Prediction tool ... 9
3.2 The Stylebase knowledge base... 11
3.3 The design requirements Traceability tool... 14
3.4 The Q-TRA Transformation tool ... 15
4. CONCLUSIONS ... 19
REFERENCES... 20
TERMINOLOGY
COM Component Object Model
COTS Commercial Of The Shelf
IDE Integrated Development Environment
MDA Model-Driven Architecture, framework for standards for MDD
MDD Model-Driven Development, a model based software development method NGN Next Generation Networks, hybrid telecommunication networks
OSS Open Source Software PFA Product Family Architecture R&A Reliability and Availability
RAP Reliability and Availability Prediction, a method for evaluating reliability and availability from architectural models
QADA Quality-driven Architecture Design and Analysis, architectural design and analysis method
Q-RDL Quality-driven Rule Description Language, transformation rule description language Q-TRA Quality-driven architecture TRAnsformation, tool for quality-driven architecture model
transformation
VTT Technical Research Centre of Finland
1. INTRODUCTION
Collaboration is becoming increasingly important in software development. Various reasons such as the growing size and complexity of software systems, politics, resource and competence needs lead to increasing needs for collaboration. Large companies develop products internally in a distributed, multi-sited environment and especially large systems are developed by many companies in collaboration. Companies use externally developed components such as COTS and OSS components in their systems, create components working together and out-source the development of parts of their own products. In its extreme, this leads to what is called off-shore development when the sub-contractor or other collaborator is located on a different continent, distances are great and observing the results becomes more difficult. Thus information sharing between the interested parties is one of the most important processes in collaboration.
Software architecture is one of the most important artefacts in collaborative software development as it defines the higher level structures and relations of the different parts of the software. These architectural descriptions define what is expected of the different parties and subcomponents and how they interact. From the architectural collaboration viewpoint it is important to be able to evaluate, design and share knowledge of these software architectures. The use of COTS, OSS and out-sourced components take away part of the control from the system developer and emphasize the need to be able to assess the qualities of the provided and used components and their properties. This document reviews tools developed at VTT as part of methods for designing and evaluating software architectures and how these tools can assist in different parts of the architecture design, evaluation and information sharing.
2. BACKGROUND
This section describes the background for the selected tools and the architecture design activities they are designed to support.
2.1 TOOL SELECTION
The tools described in this document have been developed at VTT to help design and analyse software architectures. These tools have been developed in the context of a method called QADA (Quality-driven Architecture Design and Analysis) for software architecture design and evaluation.
Thus, as understanding what QADA is about helps understand the ideas behind many of these tools, a brief summary of QADA is also given. To help understand how the tools have been validated, the software systems used in validating the tools are presented. In the case of three tools, the same system (DiSeP) has been used, and it is presented in its own section. The validation of one of the tools has used a different case study and this case is described in the section with the tool in question.
2.2 QADA
QADA is a quality centric method for designing and evaluating software architectures [1]. The main steps of QADA are shown in Figure 1. The process starts with defining the quality requirements for the system from the business and product drivers. Different architectural views are used at both concrete and conceptual levels to describe the system architecture. A database called the stylebase acts as a knowledgebase and is used as a repository to share information and knowledge about the system architecture, patterns and the quality properties of the system and architectural designs. The system architecture is designed starting from defining its business and product drivers and using the methods developed as part of QADA to design for the required quality attributes. The stylebase is used as a supporting tool in both the design and evaluation of the architecture. The information in the architectural models and stylebase are used to evaluate the system architecture and its quality goals. The design and evaluation process is iterated until the set quality goals are achieved. Different methods for evaluating and designing architectures with regard to given qualities have been developed as a part of QADA.
Figure 1. The QADA circle.
The four principles of QADA can be mapped to Figure 1 and are:
• business-driven family architecture development,
• quality-driven architecture modelling,
• pattern-based knowledge reuse, and
• quality evaluation based on architectural models.
Mapping these principles to the figure is described next. The development is driven by the business and product drivers as defined in the first phase and is visible in Figure 1 as the part where the arrow enters the circle from the outside. The process starts with the definition of the business and product drivers and requirements. In the second phase, the architecture is modelled based on the quality-driven methods that are a part of QADA. This is visible on the right hand side of the figure where quality design takes place, making use of modeling techniques and tools such as Product Family Architecture design and evaluation strategies and variability representations.
The stylebase supports knowledge reuse and sharing as is based on architectural and design patterns. This is visible at the bottom of the circle in the figure, with the supporting arrows going to both design and evaluation. In phase three, quality evaluation of the designed architecture is performed, making use of the stylebase and other design information. If the quality is evaluated as not met, the process is repeated by starting with the refinement of the business and product drivers. Both quality-driven design and evaluation have a central role in the development cycle of QADA.
To represent the software architecture, QADA employs four architectural views:
• structural view,
• behavior view,
• deployment view, and
• development view
Each of these views is considered at two abstraction levels: concrete and conceptual. The conceptual level is a higher abstraction of the views, while the concrete level provides more detailed views into the architecture.
The structural view at the conceptual level describes the architectural elements, including the structural components, their relationships and the responsibilities they have in the system. The structural components divide the system into functional blocks. The relationships are abstracted interfaces between components, describing if an element passes control or data to, or uses another component. Responsibilities define the role of each element in the system, answering the questions on ‘how’, ‘why’ and ‘what’. At the concrete level the structural view is represented by capsules, ports and protocols. Capsules represent the control flow in the system and are composed in a hierarchical manner with a top capsule containing subsystem capsules and subsystem capsules containing component capsules. Messages are considered the sole means of communication between capsules and they are sent and received through ports. Protocols define the valid types of messages that can be exchanged.
The behavior view at the conceptual level specifies the behavior of the system on a high abstraction level. Similar to the structural view, it is defined by behavioral components, their relationships and responsibilities in the system. Behavior components are derived from structural components and are called service components. The behavioral relationships are described as ordered sequences of actions among the service components. Responsibilities define similar items as in structural view, namely answering the questions of ‘how’, ‘why’ and ‘what’. At the concrete level, the behavioral view is represented by interaction instances of capsules, interactions and messages. The interaction instances of capsules conform to the run-time instances of capsules representing services. An interaction is a pattern of communication among objects at run-time and represented by sequence diagrams. Messages are specifications of communication among capsules.
The deployment view at the conceptual level identifies the distribution of hardware nodes in the system, groups conceptual components to units of deployment and specifies allocations of deployment units to computing units. The hardware deployment nodes are called computing units and host the various system services. The combination of the services across the nodes is clustered into deployment units according to their mutual requirements. Allocations recognize the relationships between the deployment nodes and units of deployment.
The development view describes the actual development artefacts of a system, including the source code and other similar components. The development view is still a view least considered in QADA as QADA is mostly focused on higher level architectural issues and the development view is as such not quite as central in QADA as the other views.
2.3 TOOL VALIDATION FRAMEWORK
In the case of three of the four tools described in this document, the architecture of a system called Distributed Services Platform (DiSeP) has been used. The DiSeP architecture is described in this section. DiSeP is a distribution platform for a product family of software systems and was first introduced in [1]. DiSeP is a service oriented platform that offers a variety of services on different layers. The goal of the DiSeP platform is to enable spontaneous networking between the application nodes in a network, allowing a dynamically changing network. At any time the number of modules or the range of services available can vary.
Example services from the DiSeP platform include:
• DirectoryService for accessing the available nodes and services in the network formed by the DiSeP nodes,
• LeaseService for requesting and granting leases for nodes to use the services of other nodes, and
• TransactionService for handling transactions crossing network nodes and services.
Figure 2. The DiSeP architecture.
The platform itself is built on layers that provide services to higher layers while using services from the lower layers. The conceptual architecture showing the four layers of the platform is shown in Figure 2. The highest level service layer on the top is the one through which the applications interact with the DiSeP and use its services. The lowest level on the bottom is responsible for network communication. The implementation of the services is in the middle layers. The product family used for the validation of the tools has been built on top of the DiSeP platform and includes three family members: an emergency intervention application, a health care application and a game application.
3. TOOLS
This section describes the selected tools and reviews their ability to support collaborative software development on the architectural level. The tools reviewed have been developed closely with the ongoing research on developing QADA. An overview of the selected tools is given in the coming sections.
3.1 THE RAP RELIABILITY AND AVAILABILITY PREDICTION TOOL
The RAP (Reliability and Availability Prediction) method is a method for predicting the reliability and availability of a system from its architectural descriptions [2]. In the context of the RAP method reliability is defined as the probability of failure-free operation of a software system for a specified period of time in a specified environment. Similarly availability in RAP is defined as the probability of the system being available when needed.
As change is cheaper when done earlier in the software development process, the RAP method aims at enabling the evaluation of the R&A (Reliability and Availability) goals of a system from its architectural descriptions as early as possible before it is implemented in code. The possibility for early evaluation of candidate solutions enables comparing different candidate architectures early in the development phase with regards to their R&A properties. The RAP method has three main phases, which correspond to the phases of QADA as described in section 2.2:
1. Defining R&A goals
2. Representing R&A in the architecture
3. Analyzing R&A from the architectural models
In the first step the R&A requirements are identified, based on the R&A requirements of the system, the candidate architectural styles are identified and the most suitable style selected. In the second step the R&A requirements are mapped to the architectural views and the R&A properties are presented in the architectural models. In the third step the architecture is analyzed with regards to meeting the R&A goals and requirements. Both quantitative and qualitative analysis is performed to evaluate the R&A goals. The quantitative analysis is based on state- and path-based models and their simulation. The qualitative analysis is based on heuristics and analysis of design rationale. The RAP tool is intended to assist in the quantitative analysis part.
The quantitative analysis performed by the RAP tool is based on the properties of the components and their interactions. The components are described with state-based diagrams which describe the probability of the components moving from one state to another or the system state changing from one component to another. The possible states include the failure probabilities of the components and their interactions. The RAP tool uses Markov-chain analysis of the state diagrams and model properties to analyze the reliability of the components. For analyzing the reliability of the whole system, the RAP tool uses simulation of the system through a path-based model. These calculations enable the RAP tool to give the failure probabilities of the components and the system as a whole. The RAP method also includes qualitative analysis and the use of heuristics, but the RAP tool only assists in the quantitative part of the analysis and thus the qualitative parts are not described here.
The RAP tool is not a tool intended to work as a standalone tool. Instead, it integrates with an UML 2.0 modelling tool to provide the functionality through the modelling tool. The RAP tool requires that the modelling tool supports integration through a COM interface and provides functionality to access and modify the model elements. It is implemented on the .NET platform and as such requires the .NET runtime to be available. The RAP tool requires the modelling tool to support UML
2.0 to support all the views of QADA required for performing the RAP analysis. Currently integration is implemented for the Enterprise Architect tool from Sparx Systems.
Figure 3. Showing the R&A information as notes in the model.
The R&A information is stored in the properties of the model elements by entering this information in a separate window that can be accessed by clicking on the model elements. Also a requirement id is given for every R&A data element to enable traceability to the requirements. At least the value of the components probable failure must be given to enable the R&A analysis from the model. As the R&A information is normally not visible in the model, the RAP tool supports displaying the information as notes in the diagrams for better visibility as shown in Figure 3.
With the required models designed and the R&A information for the model components entered it is possible to use the RAP tool to evaluate the R&A properties of the different components. The RAP tool provides its own evaluator component that is integrated as a plug-in in the modeling tool and calculates the R&A property values from the model information. Different message sequences of the models are evaluated based on their paths and R&A properties. These values are used to calculate the R&A values for the components. The idea is to help locate critical spots in the architecture that need the most focus and are most likely to be places for system failure. The evaluator component is shown in Figure 4.
The RAP tool has been validated using the DiSeP platform described in section Error! Reference source not found. as a case study. The Figure 3 shows a part of the DiSeP architecture, which has been refined with the R&A properties of the RAP tool. By extending the models with the R&A properties it was possible to use the RAP tool to analyze the R&A properties of the architecture.
The main window of the analysis tool when used for analyzing DiSeP is shown in Figure 4. Using the RAP tool the R&A properties of the DiSeP architecture were evaluated and analyzed. The experiences from the case study were that the tool was easy to use and provided several benefits to the user. It was considered to save time, eliminate possibilities for error and highlight possible problem spots in the architecture.
Figure 4. The RAP evaluator component.
The RAP tool helps in collaborative software engineering and designing of architectures by enabling easier evaluation of the candidate architectures. Collaborating companies can make use of the RAP tool to design and evaluate candidate architectures that will best meet everyone’s R&A requirements. When development of components or systems is outsourced, the R&A attributes of the proposed solutions can be evaluated faster and more easily by using the automation support provided by the RAP tool. When software is developed in collaboration the solutions being developed can be faster and more easily assessed from the different perspectives of the interested parties. As the R&A data elements used by the RAP tool are also linked to the R&A requirements in the data models, this information can also be used to track how the requirements for a system are implemented. Thus it is easier for one organization to track the deliverables proposed and delivered by another company and to evaluate their conformance to the R&A requirements.
3.2 THE STYLEBASE KNOWLEDGE BASE
The stylebase [3] has been designed to assist in designing and evaluating software architectures and is a central component in QADA as is shown in section 2.2. It is a knowledge base containing information on architectural patterns and design patterns. For each pattern a number of data elements are stored including its abstraction level, example diagram, purpose, supported quality attributes, component types and roles, connector types and the topologies of the pattern. As the idea of the stylebase is to assist in designing and evaluating the quality attributes of software architectures, the various patterns are linked to quality attributes they are considered to support.
The stylebase also contains information on the required components involved in implementing a pattern, their ordering, connectors and other elements required to implement the patterns in the architecture. Guidance information is included to help users adopt the patterns and understand how the patterns promote specific qualities in the architectures.
The goal of the stylebase is to act as a central repository from which architects can access and share information about patterns and design rationale. The stylebase is implemented as a distributed system with a central database component and client components that can access the stylebase concurrently over the network. This makes it easy for a number of users to have up-to- date information on the different patterns and their related properties available. The architects and
other interested parties can share their pattern knowledge and thoughts by entering them into the stylebase and all interested parties will have the up-to-date information available.
The user of the stylebase can search the pattern repository with different attributes. The patterns can be looked up by their name, quality attributes and abstraction levels (design or architectural patterns). For example, the user can look for architectural patterns that will help promote extensibility in the system. The stylebase will then list a set of matching patterns and from the candidate patterns the user can browse more detailed information to choose the one most suited for their needs. The query dialog of the stylebase is shown in Figure 5 and allows looking for patterns by the abstraction level and related quality attributes. Detailed information for the patterns can be viewed in the advanced information panel of the stylebase as shown in Figure 6.
The stylebase is intended to be used in three ways:
• Electronic library of patterns,
• A quality-driven architecture model construction guide, and
• A quality-driven architecture evaluation guide
As an electronic library it serves as an information source and can be browsed for information on patterns in a similar way to the pattern catalogues in the literature. When designing architectures, it provides means for finding suitable solutions for the system being developed. In the evaluation phase it can be used to find information about the patterns used in the system. In both design and evaluation it provides the information on the supported quality attributes and detailed properties and implementation details of the patterns.
Figure 5. Pattern query dialog.
Figure 6. Detailed information for a pattern.
The stylebase has been designed with extensibility in mind and future additions would include making it a more integrated part of the architects and developers process, enabling further communication between the stakeholders. The stylebase provides an easy means of communicating information design decisions and properties in the form of the used patterns. It also provides a means of communicating other related information on architectural decisions and solutions by incorporating this information in the stylebase and pattern descriptions. The relations of the patterns to the quality attributes as expressed in the stylebase still need refinement as no systematic or explicit means for mapping these qualities to the patterns exists. Some mappings exist in literature and the information in the stylebase is based on these mappings, however these are based on experiences and no systematic and explicit way to do the mapping has been defined [3]. The stylebase describes use cases of the patterns and the ways they can be useful in a given context and application of this information requires the expert knowledge of the architect. However, it is a useful tool as the architect’s assistant and in communicating the gained architectural design information between interested stakeholders.
The Stylebase has been validated with the DiSeP platform as described in section Error!
Reference source not found. as a case study. In the case study the architecture was evaluated and redesigned to support the requirement of the extensibility quality attribute. This requirement was considered as the ability of the platform to acquire new service components without influencing other components in the system. To evaluate the quality attributes, the architecture of DiSeP was viewed at the conceptual level as architectural patterns and their quality attributes. As the layers pattern is not linked to extensibility in the architectural pattern of the stylebase, it was not considered suitable to meet the extensibility requirement. To find a suitable architectural solution, the Stylebase was used to search for a pattern supporting the extensibility quality attribute. The blackboard patterns was found to support extensibility and as all the other properties of the pattern
were also found to be matching the properties of the layers pattern, it was suggested that the architecture should be redesigned to the blackboard architectural pattern.
From the collaboration perspective the stylebase promotes collaboration by allowing the interested parties to share information related to the architectural decisions and solutions in the system. As the architect(s) designing the system use the information in the stylebase and document it, the people evaluating the architectures can refer to the stylebase for the information about the used patterns to help in the evaluation. As the stylebase is a distributed system, it can be used across organizations and departments to share and communicate information.
3.3 THE DESIGN REQUIREMENTS TRACEABILITY TOOL
The traceability tool described in this section has been designed to assist in tracing the requirements in product families to different levels of the design [4]. As product families are about reusing as much of the design as possible and presenting the differences between the products as variation in the product family, the basic idea of the tool is to enable tracing which requirements are implemented where to enable maximum possible reuse. This way reuse becomes easier and we can be convinced that a proper set of variable features are incorporated in the products. The tool described in this section is especially focused on traceability inside product families.
The traceability tool has been implemented as an extension to Together Control Center and is designed for tracing the features and requirements of product family architecture, components and implementation. It has been designed to support both top-down and bottom-up traceability from the product (family) feature graph down to the implementation files and back. The tool uses representation of the product family at three abstraction levels:
• Product Family (PF) level,
• Product level, and
• Implementation level
On the PF level, the product family is modelled with a PF Feature Map (FM). This model describes the product family features and variation points. The product level describes the individual products in the product family as the subset of the PF features supported by that product. The product level is modeled with a Product Component Map (CM), which describes the design decisions. Finally, the implementation level includes the actual implementation artefacts implementing the features of the products and associated documentation. These levels are shown in Figure 7.
The actual traceability is made possible and described by following the relationships between the abstraction levels and the product-related maps. Three levels of traceability are defined:
• Traceability between PF FM and Product FM,
• Traceability between Product FM and Product CM, and
• Traceability between Product CM and implementation
These associations can be followed in both directions, providing both the top-down and bottom-up traceability. The relations of these different abstraction levels and their components are shown in Figure 7.
Figure 7. Relations of the traceability abstraction levels and their components.
The traceability tool has been validated by applying it to a product family in the Next Generation Networks (NGN) domain, for which the required models as described in this section were available.
NGNs integrate hybrid telecommunication networks via middleware platforms. The middleware provides basic communication services and hides the network details, enabling independence from the underlying network and enabling the applications to implement their own services. The product family used in the validation included six related products in the NGN domain. The first goal was to see if the notation and methodological support was sufficient to model the existing family. The second goal was to evaluate the support of the tool and methodology in communicating the represented knowledge. Both evaluations were successful: The required information could be successfully modelled and traceability was found to be a fundamental factor in communicating knowledge about reusable assets. Some future improvements for the tool were found to be needed to filter the most important information from the complex models and the relations of the features and dependencies of the system.
Traceability is always important, and in the case of collaborative development even more so.
Collaborating parties must be able to coordinate their work and design artefacts must be made matching both to requirements, to designs and to each others. Especially when using third-party components, subcontracting or using outsourcing it is important to be able to trace and manage the different parts of the process. The tool described in this section helps in automating parts of this work and thus makes collaboration easier and more manageable. Different parties can use the views and abstractions provided to represent their designs and check their conformance to the system as a whole.
3.4 THE Q-TRA TRANSFORMATION TOOL
Q-TRA is a tool for quality driven model transformation [5]. A quality driven model transformation means transforming a model to another model at the same abstraction level, while addressing different quality attributes. An overview of the transformation process is shown in Figure 8. Q-TRA
uses architectural and design patterns for defining the transformations between the patterns.
These patterns are stored in the stylebase (see section 3.2), in which they are also linked to a set of quality attributes. The actual transformations are carried out based on a set of transformation rules. These rules consist of admissibility rules and feasibility rules which are combined to form mappings. These mappings define the transformations from the source to the target model.
Since these transformation definitions are usually more specific than general, they result mostly in pair-specific transformation rules for the patterns. This means all the transformation rules have to be defined for each pair of patterns that are to be transformed. To help automate the transformations and to ease the use of the tool, Q-TRA includes a special database called the rulebase for these transformation rules. It contains all the pair-specific mappings defined in a uniform way that can be used by an automated tool to carry out the transformations. To describe the mappings in the rulebase, Q-TRA uses a special transformation rule description language called Quality-driven Rule Description Language (Q-RDL). This language defines the needed information to map elements from one pattern to another. To enable the definition of the rules, Q- TRA tags the model elements with marks that define their place in the pattern, their types and roles. Using these marks and the mappings, the actual transformations can be carried out.
Figure 8. Q-TRA transformation process.
Performing the actual transformation consists of the following steps:
• Finding and defining the source and target patterns with the stylebase,
• Applying the admissibility rules to validate the transformation,
• Defining the transformation mappings,
• Describing the transformation rules with Q-RDL, and
• Performing the actual transformation by marking the model components and applying the rules
The stylebase is used to find the patterns of interest for the transformation and their related quality attributes. If the patterns are not yet in the stylebase, they should first be entered in to ensure all required information is available. The admissibility rules are a set of rules that validate that the transformation can be performed and makes sense. In practice, these rules state that to be able to perform the transformation between two patterns, the patterns must be at the same abstraction level and they must have the same purpose (a property defined in the stylebase). Once these constraints are satisfied, the mappings between the patterns are defined. In practice this means adding to the transformation models the needed information such as component types and roles.
Defining the mappings makes use of the two defined feasibility rules: component type is not allowed to vary in the transformation and connector topology must be constructed from the scratch and connection rules must depend solely on the target pattern. Component roles include such roles as layer component, data source component and blackboard component. Component types include such types as data component, control component and computation component. With all the markings and mapping information available, Q-RDL is used to define these rules formally, in a way that enables the automated transformation. Once all the required information is available, the actual transformation is performed by applying the Q-TRA transformation tool. The Q-TRA transformation dialog is shown in Figure 9.
Figure 9. Q-TRA transformation dialog.
Q-TRA has been used in a case study for transforming the architecture of the DiSeP platform as described in section Error! Reference source not found. in a blackboard architecture. The results of the transformation are shown in Figure 10. The target architecture is chosen by searching the Stylebase for an architectural pattern supporting extensibility and thus the blackboard pattern is chosen. First all the components in the layers model are marked to reveal their roles and types in the layers architecture. As the rule base already contains the required transformation rules, once all the required information is available, the transformation is as simple as pressing a button in the Q-TRA tool. The resulting architecture contains also the transferred model properties that were marked to the layers model and are now transformed by the Q-TRA. Although the transformation is carried out successfully, the case study shows how some parts are left unmodified when no transformation rules for the interface components in the architecture are found. Finally, the architect is required to check the new model and its properties to evaluate the results of the transformation.
From the collaboration point of view model transformations are useful in helping to transform design artefacts from one party to a form usable by another party. In vertical transformations this could mean for example generating source code from the models. In horizontal transformations such as employed by the tool described in this section, this means transforming a given model to another model at the same level but with properties of interest to the other party. By allowing the transformation of models from supporting one quality attribute to another, collaborating parties can share and reuse their design artefacts more widely. As Q-TRA is designed to be used with the stylebase described in section 3.2, the collaborating parties can also use and share their design knowledge and decisions through the knowledge base. This enables faster communication and finding good design solutions faster. Design knowledge and decisions can be shared through the stylebase and different solutions can be experimented with through the transformations provided by Q-TRA.
Figure 10. Q-TRA architecture transformation from layers to blackboard.
4. CONCLUSIONS
Software architecture is one of the most important artefacts in collaborative software development as it defines the higher level structures, their partitioning to subsystems and relations of the different parts. From the architectural collaboration viewpoint it is important to be able to evaluate, design and share knowledge of these software architectures. This document described tools developed at VTT to support the activities of quality prediction, modeling, product evolution and model transformation at the architectural level. These tools can help the architectural collaboration by automating parts of the process and helping in information sharing.
The tools described in this document have been developed as a part of research projects. In some cases, more work is still needed to make them usable in industrial setting. The architectural transformation concept addressed with the Q-TRA tool is still a research problem that has not been fully solved and needs more work. Traceability as addressed by the traceability tool described here is a more mature field and several commercial implementations exist. However, the tool described here focuses more on validating one approach in the field. In the case of these two tools, it can be considered that they are more at the level of developing research concepts. For the RAP and Stylebase tools, the development has progressed in the form of open source plug-in development for the Eclipse Integrated Development Environment (IDE). In these cases, the tools are becoming more mature and already have an established user base and continue to be developed. These two tools are something to consider when there is interest in reliability and availability prediction or sharing of architectural knowledge, and the tools can be integrated into the workflow as part of the Eclipse framework.
REFERENCES
[1] Matinlassi, M., Niemelä, E., and Dobrica, L., Quality-driven architecture design and quality analysis method, A revolutionary initiation approach to a product line architecture, 2002, VTT Technical Research Centre of Finland: Espoo, p. 129 p.
[2] Immonen, A. and Niskanen, A. (2005), A Tool for Reliability and Availability Prediction. In:
Proceedings of the 31st Euromicro Conference on Software Engineering and Advanced Applications, Porto, Portugal. Pp 416 - 423.
[3] Merilinna, J. and Niemelä, E. (2005), A Stylebase as a Tool of Quality-Driven Software Architecture Modelling. In: Proceedings of the Ninth Symposium on Programming Languages and Software Tools, August 13-14, 2005, Tartu, Estonia. Pp. 97-111. ISBN 9949-11-113-7.
[4] Lago, P, Niemelä, E. and van Vliet, H. (2004), Tool Support for Traceable Product Evolution, European Conference on Software Maintenance and Reengineering, CSMR, Tampere, Finland, March 24-26, 2004, 261-269.
[5] Merilinna, J. (2005), A Tool for Quality-driven Architecture Model Transformation. Oulu; FI, University of Oulu University of Oulu, Department of Electrical and Information Engineering.
