Software Architecture Design in Information Systems Development: A Method Engineering View Kari Smolander Lappeenranta University of Technology Department of Information Technology Laboratory of Information Processing Telecom Business Research Center P.O.Box 20, FIN-53851 Lappeenranta Finland e-mail:
[email protected] Abstract This paper examines how current research treats software architecture design, places it in the context of information systems development (ISD), and brings forward arguments about the nature of the architecture design and its effects on the selection and usage of systems development methods. It is noted that the architecture guides ISD group’s perceptions on the object system and offers patterns that can be used as first-class modelling constructs in analysis and design. The need for dynamic method engineering and flexible modelling tools with architecture design is also noted and required future research efforts are listed.
1
INTRODUCTION
In the last years, much attention has been paid to software architecture. It seems that people need strong analogues and metaphors from the physical world to understand collectively the structure and the organization of the software domain. One of the hot topics of software engineering in the 90’s has been the analogue from building architecture to the coarse structure of software. At the same time, component architectures (CORBA, COM, EJB) gained acceptance in the software industry and somewhat naïve “Lego-brick” thinking claimed that systems can be composed of standard components when the architecture is defined soundly (e.g. van der Linden & Müller, 1995). The metaphor from building architecture to software architecture has gone even so far that a famous building architect has been invited to a software engineering conference for a keynote address about living structures (Alexander, 1999). In addition, one can find several articles and speeches where a direct comparison between building and software architectures is made (e.g. Zachman, 1987, Booch, 1999, Perry & Wolf, 1992, Jacobson & al., 1999). In spite of masses of articles and detailed research on software architectures, it is hard to find an adequate treatment on what architecture design1 is and where does it belong in the information systems 1
Actually, it is not clear if even software architecture has a common meaning. This can be observed for example from the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE, 2000), where the
1
development context. In addition, it is not clear, if software architecture design is something extra to the traditional analysis/design/implementation-style development process or if it is something that is included in the analysis/design stage. This unclear situation can be perceived when observing modelling languages. The current de-facto modelling language in software industry (UML) does not seem to offer enough power to model architectural decisions and structures in its standard form2 (e.g. Medvidovic & al., 1999, Robbins & al., 1998, Rumpe & al., 1999). The existence of various architecture description languages (see Medvidovic & Taylor, 2000) shows also that better and more suitable modelling techniques are needed for architecture. However, only few sources (for example Rational, 2000) have approached architecture design as an integral part of information systems development process, but the effect of architecture to development methods is still an unexplored territory. Despite this unclear situation and an undefined relationship between information systems development and software architecture design, there are many practical reasons that make software architecture design a central issue in information systems development. For example, distribution, platform heterogeneity, and security are major issues in mobile and web-based information systems necessitating rigorous and well-designed software architecture. In addition, fast time-to-market and sufficient quality are conflicting but necessary requirements for commercially successful software development. Welldesigned software architecture plays also a major role in resolving this conflict by enabling reusability and rapid change. Because of this observed importance of software architecture, we need to clarify the role of software architecture and software architecture design in information systems development. In this paper, we aim to put software architecture design into a larger methodical context and demonstrate how software architecture design and information systems development intersect. The organization of the paper reflects this: first, we make some notes about how current research treats architecture design. After that, we place architecture design in the context of information systems development (ISD) and bring forward arguments about the nature of architecture design and its effects on systems development methods and method engineering. In the conclusions, we also make a partial list of required research efforts to complete this study.
2
CURRENT EMPHASIS IN SOFTWARE ARCHITECTURE DESIGN RESEARCH
In research, architecture design is typically seen either as a separate task, which can be executed before the analysis/design phase, or as an otherwise separate task which needs different kind of knowledge, skills, and tools than analysis and design normally does. Major part of the research on software architecture design seems to fall on the following categories:
2.1
•
Architecture description languages and component/connector models.
•
Architectural styles and patterns.
•
Modifications to UML to support architecture design.
Architecture description languages and component/connector models
Architecture description languages (ADLs) have been subjects of extensive research in the 90’s. In most of the research in this category, architecture design starts from analysing the requirements and results to a “standalone” formal design which can be either executed, analysed, simulated or which can be used as a formal input to the further design. A typical conception about software architecture in conjunction with ADLs can be found for example from Luckham & Vera (1995), where “an architecture … is an executable specification of a class of systems. … An architecture consists of interfaces, connections, definition has been left for the reader of the standard. The standard defines that an architectural description consists of a number of viewpoints, which are then left undefined. 2
A clear sign of this is the abundance of articles where UML is modified to fit in architectural design purposes. If UML fully enabled modelling of architecture, no such modifications would be needed.
2
and constraints.” (p. 717). This definition shows the essence of this approach: architecture is concerned about components (and their interfaces), connections between interfaces, and the constraints that restrict the behaviour of the interfaces and connections. Most of the ADLs are formal and aim at an explicit representation of the component-connector structure of a software system. They usually include tool support for creating and editing the descriptions, analysis tools for checking different aspects of the described architecture, and some kind of code generation facilities. Examples of formal approaches include RAPIDE (Luckham & Vera, 1995), AML (Wile, 1999), and WRIGHT (Allen & Garlan, 1997), among many others. An analogous and probably influencing approach to ADLs can be found from the hardware domain, namely the IEEE VHDL standard (IEEE, 1994) for electronic hardware architecture description.
2.2
Architectural styles and patterns
The research on ADLs and component-connector models seems to forget an important aspect on software architecture. Software architecture determines the recurring patterns3 or textures (cf. Jazayeri & al., 2000) that are system-wide general solutions for solving common situations related to architecture, such as patterns related to transaction and database management, data communications, or exception and error management. These situations require the usage of a general pattern (cf. Gamma & al., 1994), which may in O-O terms involve the implementation of several classes and relationships. Current ADLs stay on the component/connector level and offer little or no help on designing and applying these architectural patterns in software design and implementation. The research of architectural patterns and their utilization is still in its infancy. Are the architectural patterns just examples as the archetypes in Bosch (2000) or could it be possible to use patterns as domain-specific modelling constructs in further analysis and design (cf. Kelly & Tolvanen, 2000)? In the UML reference (Booch & al., 1999), the need for representing architectural patterns as stand-alone modelling constructs is recognized, but the support in modelling is far from adequate. For modelling patterns, UML offers a construct called ‘collaboration’, which is actually only a mnemonic placeholder for a generic behaviour that can be applied in the situation4. The notion of an architectural style has received more attention on the architecture research. In Monroe & al. (1997), an architectural style is defined so that it “characterizes a family of systems that are related by shared structural and semantic properties” (p. 45). Monroe & al. (1997) list four things that styles typically provide: a vocabulary of design elements, design rules that determine which compositions are permitted, semantic interpretations of the design elements, and analyses that can be performed on systems built in that style. It is interesting to note here the discrepancy between object-oriented design methods and architectural styles. Object-oriented design supposes that systems are composed of communicating objects (or, the data and behaviour encapsulation in discrete objects, message passing abstraction, and explicit interfaces as noted in Monroe & al., 1997). Not all architectural styles follow this kind of an abstraction, as is shown in Shaw (1996), where eight different informal patterns5 that guide high-level system design are identified. The division between styles in Shaw (1996) is made based on differences and similarities in control and data flows. 3
These are called archetypes in Bosch (2000) and architectural mechanisms in Kruchten (1999). The terminology is very confusing here. Shaw (1996) and Buschman et al. (1996) call the basic structure by which architecture can be perceived as an architectural pattern, whereas for example Monroe & al. (1997) and Bosch (2000) call it an architectural style, which seems to be a more common term for that purpose. However, the line is vague, and by certain aspects, some of the patterns in Buschmann et al. (1996) fall in the category of styles here, and some in the category of patterns.
4
See Catalysis (D’Souza & Wills, 1998) for extended and more precisely defined collaborations.
5
They should be called here ‘styles’ like in many other sources (e.g. Monroe & al., 1997). The different styles in Shaw (1996) are pipeline, data abstraction, communicating processes, implicit invocation, repository, interpreter, main program and subroutines, and layered style.
3
Although the selection of an architectural style includes certain vocabulary, design rules, and semantic interpretations, there is no clear reflection available that considers the implications of the selection of an architectural style to the usage and selection of systems development methods. On the contrary, standardization in methods is strong (e.g. OMG, 2000), and, for example, UML is claimed to fit in modelling of almost every kind of a system (Booch & al., 1999).
2.3
Modifications to UML to support architecture design
There is no lack of research dealing with UML’s abilities in architecture modelling. For example, Garlan & al. (2000) presents five strategies of using UML in architectural modelling and shows that each of them has their weaknesses. Hofmeister & al. (1999) use UML stereotypes and special symbols for architectural constructs. Rumpe & al. (1999) show some features that UML is lacking and propose extensions. Egeyed & Medvidovic (1999) use stereotypes and the object constraint language to specify C2-style architectures (Taylor & al. 1996). All the approaches mentioned above are mostly dealing with UML’s ability to model componentconnector structures. None of them is particularly interested in representing architectural patterns or connecting these patterns to architectural descriptions. An exception of this is Catalysis (D’Souza & Wills, 1998), which extends the conventional UML with frameworks that can describe generic patterns.
3
SOFTWARE ARCHITECTURE IN INFORMATION SYSTEMS DEVELOPMENT
Information systems development (ISD) is a change process, which aims at changing the object system according to some objectives (Welke, 1981; Lyytinen, 1987). The object system consists of the phenomena perceived by the development group and it identifies the target of change in the ISD process. A development group carries out the process of change and at least partly shares a common language and a concept structure to enable communication and common understanding. They make perceptions on the object system, act to change it, and describe the system using the description languages and conventions offered by the ISD approach and method (cf. Iivari & al., 1999). The final aim of the development group is to implement the change in the user organization or community according to the objectives. This change usually includes composition and installation of formal artefacts (such as software and hardware) and changes in the rules and practices in the user organization or community. The whole process takes place in a set of environments, including organizational, technical, and social environments. Where does software architecture belong in this picture? Is it part of the technical environment that affect on the change process or is it a solid part of the object system that must be perceived, described, and changed? To argue about these questions, we must introduce the concepts of problem and solution contexts.
3.1
Problem context and solution context in ISD
Typically, information systems development starts from the user or business perspective. We might talk about user needs, business requirements, use cases, functional requirements, etc. When doing so we are approaching the system in terms of a problem and the primary need for an ISD group is to understand the problem. On the other hand, we might see the system as a set of technical constructs, organizational principles, procedures, algorithms, data structures, data communication patterns, and so on. We then see the system as a solution to the problem. The main constituents of the system are then the constructs and the structure in the solution context. The primary objective for an ISD group in the solution context is to find out a viable structure for the solution (cf. Jackson, 1994). Software architecture is clearly on the solution context. When designing architecture, we are structuring the solution – we do not perceive architecture in terms of the problem. Essential parts of architecture are for example the components, their interfaces and connections, modules, and recurring software patterns and policies that are determined by the architecture. The place of architecture in respect to the problem and solution contexts is depicted in figure 1. The object system model is divided here into the analysis and design models. The problem context is represented in the analysis model that imposes requirements and application domain concepts to the design model representing the solution context. Architecture is 4
Design Model represents
software architecture = abstraction of software
imposes requirements on
offers possibilities and sets constraints on
Solution Context
Analysis Model Problem Context represents
Figure 1. Object system models included in the design model and we see architecture as a model or abstraction describing the software in the solution context (cf. Jacobsen & al., 1999). We argue that architecture is not only important in terms of solution and design. Architecture is also important because it guides (either consciously or subconsciously) the ISD group by offering possibilities and setting constraints on how the problem context may be perceived when keeping the ISD objectives in mind. In short, architecture forms the visible part of the solution context when perceiving the problem context. We can also argue that the ISD group needs an architecture description because it must collectively understand in general terms how the problem is transformed to the solution to enable a common language and a concept structure. Here, understanding and communication between different stakeholders participating in the ISD process are the primary objectives – the generation of formal artefacts (such as code) and formal analysis are secondary. This is against the current state of the ADL research where formality and exactness are the primary objectives. Formality and exactness should be put in a proper context within software architecture design. In our opinion, they are means and not the objectives when designing software architecture.
3.2
Recurring architectural patterns as modelling constructs
Today, no information system is an island without predecessors, given technological environments, or interfaces with other systems. Therefore, even in the very beginning of an ISD process, an implicit architecture exists, in some cases stronger, in some cases weaker. We cannot perceive the problem without having a primitive solution in mind. Object-oriented methods, however, forces us to see the problem in a very general way - as a network of discrete objects that are communicating mutually by passing messages. The reflection of a primitive solution or an initial architecture may however guide us to see the problem or a part of it for example as a series of pipes and filters, or as a set of user interface forms bound to database entities with query processing capabilities. We could list also other examples like ones related to data communications and distribution. Particularly relevant this “pattern guidance” is when a domain-specific application framework is used or a product line architecture is being built or extended6. We argue that it would be economical to give up tight object-orientation and accept architecture-determined patterns as first-class modelling constructs in situations where the patterns are occurring frequently and the variability of patterns is relatively low. This would however necessitate some kind of method engineering and flexible modelling tools that would incorporate new architecturedetermined constructs.
6
For examples of general architectural patterns, see Buschmann & al., 1996
5
Environment (technical, organizational,…)
Standard method
Architecture design
Requirements
Initial architecture description Recurring architectural patterns
Method engineering
Analysis/design/ implementation/ deployment
Method
Tool development
Software based information system
Modelling tool
Figure 2. Architecture design in process context
3.3
Architecture design in systems development context
As we stated above, first, architecture gives the ISD group understanding and common knowledge about the system’s technical environment and guides the perceptions on the problem and solution contexts by offering possibilities and setting constraints. Second, architecture determines recurring software patterns that may be used as economical modelling constructs in analysis and design. By using these arguments, we can draw a sketch on the ISD process and place architecture design in its context. Figure 2 shows how we see the placement of architecture design in the context of the ISD process. The figure should not be interpreted as a sequence of ordered actions. Instead, it serves as a simplification of a complex process of which some parts are occurring concurrently. Architecture design is situated in a set of environments, including technical and organizational environments. It produces a description of the architecture using a given set of requirements and a set of recurring patterns that are determined by the architecture. Neither the architecture description nor the recurring patterns will be final for the rest of the process. They will evolve during the analysis and design, but the development group must have some assumptions of the architectural structure and patterns related to it even in the beginning of the analysis and design process. This model will not take any particular viewpoint on what kind of a process model should be used in ISD. We argue only that architecture design differs from the rest of the process by producing recurring patterns that may be used as modelling constructs in further development. An architecture description will evolve during analysis and design phases but some information about the recurring patterns is needed to adjust the ISD method and its modelling constructs to fit in the selected architecture. The adaptation of the architecture and the method necessitate some form of method engineering. In the simplest form, this method engineering consists of adding new stereotypes and tagged values to UML elements and writing scripts for code generation. In an advanced form, this would require the usage of an adaptable metaCASE tool (cf. Smolander & al., 1991) and a definition of 6
a new modelling language with code generation facilities. What is different here from a conventional method engineering process (e.g. Tolvanen, 1998) is that these patterns and constructs will probably change and evolve during analysis and design and therefore the method engineering process where the method is defined before the ISD project does not completely work in practice. Instead, we need tools that are based on a dynamic metamodel, i.e. tools whose modelling constructs are changing according to their models. With such tools, the method engineering work cannot be fully distinguished from the actual modelling work. Parts of the tool’s metamodel will evolve during modelling and therefore the modelling constructs will change dynamically.
4
CONCLUSIONS AND FUTURE WORK
We have noted that architecture influences to the perception of the problem context. It gives the ISD group understanding and common knowledge about the system’s technical environment and offers possibilities and sets constraints on the perception of the problem and on the construction of the solution. Architecture also defines recurring software patterns that may be used as economical modelling constructs in analysis and design. We noted that there is a mismatch between the standard object-orientation and architecture-specific modelling. The usage of these architecture-specific modelling constructs however necessitates the involvement of method engineering and flexible tools that can be adapted to architecture-specific modelling constructs. We see these arguments only as initial perceptions of a research in progress. We have identified several open research questions including •
How to represent architectural patterns in terms of metamodelling?
•
How to enable the tool support for dynamically changing architectural patterns as modelling constructs?
•
How to integrate overall architecture design with architectural pattern modelling?
The research is currently going on and we expect to see results in the future.
ACKNOWLEDGEMENTS This research is funded by Sonera Corporation. The author wishes to thank professors Anne Eerola (University of Kuopio) and Heikki Kälviäinen for their comments. The role of the East Finland Universities Graduate School in Computer Science and Engineering (ECSE) is also acknowledged.
REFERENCES Alexander C. (1999), "The Origins of Pattern Theory: The Future of the Theory, and The Generation of a Living World", IEEE Software, Sep/Oct 1999, pp. 71-82. Allen R., Garlan D. (1997), "A Formal Basis for Architectural Connection", ACM Transactions on Software Engineering and Methodology, July 1997. Booch G. (1999), "Software Architecture and the UML". Presentation at the UML World 1999, http://www.rational.com/media/uml/arch.zip. Booch G., Rumbaugh J., Jacobson I. (1999), The Unified Modeling Language User Guide, AddisonWesley. Bosch, J. (2000), Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach, Addison-Wesley. Buschmann F., Meunier R., Rohnert H., Sommerlad P., Stal M (1996), Pattern-Oriented Software Architecture, Volume 1: A System of Patterns, John Wiley & Sons. D'Souza D.F., Wills A.C. (1998), Objects, Components, and Frameworks with UML: The Catalysis Approach, Addison-Wesley.
7
Egyed A., Medvidovic N. (1999), “Extending Architectural Representation in UML with View Integration”, in Proceedings of the 2nd International Conference on the Unified Modelling Language (UML), Fort Collins, CO, Oct 1999, pp. 2-16. Gamma E., Helm R., Johnson R., Vlissides J.O. (1994), Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley. Garlan D., Kompanek A., Pinto P. (2000), “Reconciling the Needs of Architectural Description with Object-Modeling Notations”, in Proceedings of the Third International Conference on the Unified Modelling Language - 2000, York, UK, Oct 2000. Hofmeister C., Nord R., Soni D (1999), “Describing Software Architecture with UML”, in Proceedings of the First Working IFIP Conference on Software Architecture, Kluiwer Academic Publishers. IEEE (1994), IEEE Standard VHDL Language Reference Manual, IEEE Std 1076-1993. IEEE (2000), IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std 1471-2000. Iivari J., Hirschheim R., Klein H.K. (1999), "Beyond Methodologies: Keeping up with Information Systems Development Approaches through Dynamic Classification", in Proceedings of the 32nd Hawaii International Conference on System Sciences. Jackson M. (1994), “Problems, Methods and Specialization”, IEEE Software, Nov 1994, pp. 57-62. Jacobsen E.E., Kristensen B.B., Nowack P. (1999), “Architecture = Abstractions over Software”, in Proceedings of the Technology of Object-Oriented Languages and Systems, TOOLS 32, 22-25 Nov 1999, pp. 89-99. Jacobson I., Booch G., Rumbaugh J. (1999), The Unified Software Development Process, AddisonWesley. Jazayeri M., Ran A., Linden F. (2000), Software Architecture for Product Families: Principles and Practice, Addison-Wesley. Kelly S., Tolvanen J-P. (2000), “Visual domain-specific modelling: Benefits and experiences of using metaCASE tools”, in International Workshop on Model Engineering (in ECOOP2000), 13th June 2000. Kruchten P.B. (1999), Rational Unified Process: An Introduction, Addison-Wesley. Luckham D.C., Vera J. (1995), “An Event-Based Architecture Definition Language”, IEEE Transactions on Software Engineering, 21(9), Sep 1995, pp. 717-734. Lyytinen K. (1987), “A Taxonomic Perspective of Information Systems Development: Theoretical Constructs and Recommendations”, in Critical Issues in Information Systems Research, R.J. Boland Jr. and R.A. Hirschheim, John Wiley & Sons, pp. 3-41. Medvidovic N, Taylor R.N. (2000), “A Classification and Comparison Framework for Software Architecture Description Languages”, IEEE Transactions on Software Engineering, 26(1), Jan 2000, pp. 70-93. Medvidovic N., Egyed A., Rosenblum D.S. (1999), “Round-Trip Software Engineering Using UML: From Architecture to Design And Back”, in Proceedings of the 2nd Workshop on ObjectOriented Reengineering (WOOR), Toulouse, France, Sept. 1999, pp. 1-8. Monroe R.T., Kompanek A., Melton R., Garlan D. (1997), “Architectural Styles, Design Patterns, and Objects”, IEEE Software, 14(1), Jan/Feb 1997, pp. 43-52. OMG (2000), OMG Unified Modeling Language Specification, Version 1.3, Object Management Group, Mar 2000. Perry D. E., Wolf A.L. (1992), "Foundations for the Study of Software Architecture", ACM SIGSOFT Software Engineering Notes, 17(4), Oct 1992, pp. 40-52. Rational (2000), “Rational Unified Process”, Rational Software Corporation. Online documentation. Robbins J.E., Medvidovic N., Redmiles D.F, Rosenblum D.S. (1998), “Integrating Architecture Description Languages with a Standard Design Method”, in Proceedings of the International Conference on Software Engineering, 19-25 Apr 1998, pp. 209-218. 8
Rumpe B., Schoenmakers M., Radermacher A., Schürr A. (1999), “UML + ROOM as a Standard ADL”, in Fifth IEEE International Conference on Engineering of Complex Computer Systems, Oct 1999, pp. 43-53. Shaw M. (1996), “Some Patterns for Software Architecture”, in Pattern Languages of Program Design, Vlissides J., Coplien J., Kerth N., Addison-Wesley, pp. 255-269. Smolander K., Marttiin P., Lyytinen K., Tahvanainen V-P (1991), “MetaEdit - a Flexible Graphical Environment for Methodology Modelling”, in Advanced Information Systems Engineering, Proceedings of the Third International Conference CAiSe’91, Springer-Verlag, Berlin, pp. 168193. Taylor R.N., Medvidovic N., Anderson K.M., Whitehead E.J., Robbins J.E., Nies K.A., Oreizy P., Dubrow D.L. (1996), “A Component- and Message-Based Architectural Style for GUI Software”, IEEE Transactions on Software Engineering, 22(6), Jun 1996, pp. 390-406. Tolvanen J-P (1998), Incremental Method Engineering with Modeling Tools, University of Jyväskylä. (Jyväskylä Studies in Computer Science, Economics and Statistics 47, PhD Dissertation). van der Linden F.J., Müller J.K. (1995), "Creating Architectures with Building Blocks", IEEE Software, Nov 1995, pp. 51-60. Welke R.J. (1981), “IS/DSS: DBMS Support for Information Systems Development”, ISRAM WP8105-1.0, McMaster University, Hamilton. Wile D. (1999), "AML: an Architecture Meta-Language", in Proceedings of the 14th International Conference on Automated Software Engineering, pp. 183-190. Zachman J.A. (1987), "A Framework for Information Systems Architecture", IBM Systems Journal, 26(3), 1987. Reprint in IBM Systems Journal, vol 38, nos 2&3, 1999, pp. 454-470.
9
