ANALISIS DE RESULTADOS

The authors have also identified five types of transformation to use in the method. First, the architecture can be transformed by imposing an architectural style. This means that the fundamental organisation of the architecture changes.

Second, the architecture can be transformed by imposing an architectural pattern. The difference from imposing a style is that a pattern is not changing the fundamentals of the architecture, but impose a rule on all elements of the architecture. For example, adding a concurrency mechanism to all elements using Periodical objects pattern.

Thirdly, the architecture can be transformed using a design pattern. The result is a less dramatic change of the architecture.

Fourthly, the architecture can be transformed by converting the quality requirements into functionality. For example increasing the fault-tolerance by introducing the exceptions.

Finally, the quality requirements can be distributed. For example, instead of putting a availability requirement on the complete system, the availability of the server part in a client server, could have higher requirements than needed for the clients.

5. Strengths and weaknesses

The 4+1 View Model show has its three major strengths in its tools support, experience with the application of the method and its solution to the problem of to many aspects in the same document. However, the method as presented in the paper is to little to give real benefit to the reader interested in using the method and to my knowledge no other literature exists about the method.

In [18] the authors fails in proving its case for the recursive design of an application independent architecture. The method suffers from several un-charities and limitations. For example, the system generation script seem to be the key to the whole automatic code generation and the developing organisation have to implement it themselves. That is not what is in general meant by supporting automatic code generation. Also the lack of experience in using this method makes any architect reluctant to try the method in an industrial case.

The scenario-based software architecture design method has its major strengths in the way evaluation is addressed. In the previous method the evaluation of the design results is left to the architect to deal with in what ever fashion seems appropriate. In the 4+1 View Model the evaluation supports is basically the scripting and what ever conclusions the architect can make of it. At the same time as it also is the

strong point of the scenario-based design method, it is also it current drawback, since the method does not attach a list of concrete techniques for the architect to choose from it is very high on the wish list for this method. Also speaking for scenario-based models benefits are the ease of understanding the why the method is defined in the fashion it is. The transformation part of the method also suffers from the problem that no list of concrete transformation with additional information of its application is part of the method.

6. Future Work

In the domain of software architecture design I see a need for two main things. First, the documentation issue needs to be worked out. To date there are no architecture description method that servers it purpose. A number or ADLs exist, but none have the made it as a industry de facto standard. The software architecture domain of software engineering need a way to communicate the software architecture and to make it tangible.

Second, the software architecture evaluation are a poorly understood area. The state of practise is heavily relying on experienced architects and mostly subjective ways of evaluation. Even though types of evaluation have been defined in ARCS method, a compilation of proven techniques of each type is missing.

Acknowledgements

Thanks to all the participants of the PhD course in Software Architecture, spring 1998, for insightful and valuable comments on the presentation of this topic and on this paper.

References

[1] L. Bass, P. Clements, R. Kazman, Software Architecture in

Practice, Addison Wesley, 1998

[2] B. Boehm, ‘Aids for Identifying Conflicts Among Quality Requirements,’ International Conference on Requirements Engineering (ICRE96), Colorado, April

1996, and IEEE Software, March 1996.

[3] G. Booch, Object-Oriented Analysis and Design with

Applications (2nd edition), Benjamin/Cummings

Publishing Company, 1994.

[4] J. Bosch, P. Molin, ‘Software Architecture Design: Evaluation and Transformation,’ submitted, 1997. [5] F. Buschmann, C. Jäkel, R. Meunier, H. Rohnert, M.Stahl,

Pattern-Oriented Software Architecture - A System of Patterns, John Wiley & Sons, 1996.

[6] R. Gamma et. al., Design Patterns Elements of Reusable

Design, Addison.Wesley, 1995.

[7] I. Jacobson, M. Christerson, P. Jonsson, G. Övergaard,

Object-oriented software engineering. A use case approach, Addison-Wesley, 1992.

[8] P.B. Kruchten, ‘The 4+1 View Model of Architecture,’ IEEE

Software, pp. 42-50, November 1995.

[9] J.W.S. Liu, R. Ha, ‘Efficient Methods of Validating Timing

Constraints,’ in Advanced in Real-Time Systems, S.H. Son (ed.), Prentice Hall, pp. 199-223, 1995.

[10] D. C. Luckham, et. al., Specification and Analysis of System Architecture Using Rapide, IEEE Transactions on

Software Engineering, Special Issue on Software

Architecture, 21(4):336-355, April 1995

[11] J.A. McCall, Quality Factors, Software Engineering

Encyclopedia, Vol 2, J.J. Marciniak ed., Wiley, 1994, pp.

958 - 971

[12] P. Molin, L. Ohlsson, ‘Points & Deviations - A pattern language for fire alarm systems,’ to be published in

Pattern Languages of Program Design 3, Addison-

Wesley.

[13] D.E. Perry, A.L.Wolf, ‘Foundations for the Study of Software Architecture,’ Software Engineering Notes, Vol. 17, No. 4, pp. 40-52, October 1992.

[14] D.J. Richardson, A.L. Wolf, ‘Software Testing at the Architectural Level,’ Proceedings of the Second

International Software Architecture Workshop, pp. 68-

71, San Francisco, USA, October 1996.

[15] K. Rubin, A. Goldberg, “Object Behaviour Analysis”, Communications of ACM, September 1992, pp. 48-62 [16] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W.

Lorensen, Object-oriented modeling and design, Prentice Hall, 1991.

[17] M. Shaw, D. Garlan, Software Architecture - Perspectives on

an Emerging Discipline, Prentice Hall, 1996.

[18] S. Shlaer, S.J. Mellor, ‘Recursive Design of an Application- Independentt Architecture’, IEEE Software, pp. 61-72, January/February 1997.

Abstract

The study of software architecture has attained an increasingly interest in the software engineering community the recent years, both in industry and academia. One of the most promising software reuse approaches is the use of software architecture in a product line development context. This paper presents a state-of-the-art overview of necessary architectural processes, identified problems related to software product line architecture as well as reported lessons learned and recommendations.

1. Introduction

The study of software architecture has attained an increasingly interest in the software engineering community the recent years. Both researchers in academia and practitioners in industry has becoming aware that the notion of software architecture may be a useful mean to achieve shorter time to market and higher software product quality.

The rationale (or rationales) for investigating software architecture is:

The software architecture is there whether we as software engineers make it explicit or not. If we decide to not be aware of the architecture we have no way of 1) controlling the architecture, 2) analyzing the architecture, 3) reasoning about the architecture, or 4) evolving the architecture.In addition, if the architecture is implicit, we are not able to identify, understand, conform to or maintain the architecture.

Potential benefits of making the architecture explicit is that it 1) defines the components, their properties and relationships of the architecture, 2) defines initialization, fault recovery styles etc., 3) provides a framework for system development and evolution, including component design and implementation, and 4) provides a basis for asset

generation

Topics of interest in software architecture research comprise, among others:

Description techniques, including notation techniques

for alleviating communication between software engineers and architectural description languages (ADLs) which may ease source code generation or enable automatic architecture evaluation[12][23].

Evaluation of architectures. What techniques and

methods are available for evaluating a particular software architecture? The purpose of an evaluation can be to see whether an architecture is bearing the capability to possess the stated quality requirements (e.g. modifiability or performance) of the software system [1][6][10].

Architecture design. Techniques and methods that

supports the architectural design. One example is the notion of architectural patterns [5] which propose structural solutions that will improve one, or many, quality attributes.

Domain-specific software architectures (DSSAs).

How will the software architecture for a specific application domain look like? This is one of the most interesting topics for a software development organization developing software products. How can one get an accurate understanding and description of the domains so it will be possible to develop a software architecture that captures the domain and can be used for software product development. One possible realization technique of a domain-specific software architecture is the notion of object-oriented frameworks [13][22].

Software Product Line Architecture. How should a

generic software architecture be developed and described to ease future derivation of software products? How should commonalities and variability be captured and expressed?

If a software development organization decides to explicitly address the concept of software architecture it will have to introduce some architecture-specific processes in their development process. Perry identify four major processes [19].

Software Product Line Architecture