Experiences from representing software architecture in a large industrial project using model driven development
Anders Mattsson1 Björn Lundell2 Brian Lings2 Brian Fitzgerald3 1 Combitech AB, P.O. Box 1017, SE-551 11 JÖNKÖPING, Sweden [email protected] 2 University of Skövde, P.O. Box 408, SE-541 28 SKÖVDE, Sweden {bjorn.lundell, brian.lings}@his.se 3 Lero – the Irish Software Engineering Research Centre University of Limerick, Ireland [email protected]
Abstract There exist several approaches to MDD such as OMG’s MDA [5], Domain-Oriented Programming [6], A basic idea of Model Driven Development (MDD) and Software Factories [7] from Microsoft. A basic is to capture all important design information in a set idea of MDD is to capture all important design of formal or semi formal models that are automatically information in a set of formal or semi formal models kept consistent by tools. This paper reports on that are automatically kept consistent by tools to raise industrial experience from use of MDD and shows that the level of abstraction at which the developers work the approach needs improvements regarding the and to eliminate time consuming and error prone architecture since there are no suggested ways to manual work in keeping different design artifacts formalize design rules which are an important part of consistent, or to cite Brent Hailpern and Peri Tarr: the architecture. Instead, one has to rely on time “The primary goal is to raise the level of abstraction consuming and error prone manual interpretations, at which developers operate and, in doing so, reviews and reworkings to keep the system consistent reduce both the amount of developer effort and the with the architecture. To reap the full benefits of MDD complexity of the software artifacts that the it is therefore important to find ways of formalizing developers use” [4]. design rules to make it possible to allow automatic enforcement of the architecture on the system model. An important design artefact in any software development project, with the possible exception of 1. Introduction very small projects, is the software architecture: “The architecture serves as the blueprint for both the system and the project developing it. It defines Model-Driven development (MDD) [1] is still an the work assignments that must be carried out by emerging discipline [2, 3] where the prevalent design and implementation teams and it is the software-development practices in the industry are still primary carrier of system qualities such as immature [4]. The success of MDD in practice is performance, modifiability, and security – none of currently an open question [4] and there is a lack of which can be achieved without a unifying reported experience on MDD in large industrial architectural vision. Architecture is an artifact for projects. One aspect of such projects is the importance early analysis to make sure that the design approach of architecture. This report presents experience from will yield an acceptable system. Moreover, architectural work practices using MDD in a large architecture holds the key to post-deployment industrial project. system understanding, maintenance, and mining
29th International Conference on Software Engineering Workshops(ICSEW'07) 0-7695-2830-9/07 $20.00 © 2007 efforts. In short, architecture is the conceptual glue different markets. New variants had to be that holds every phase of the project together for all developed and maintained efficiently. of its many stakeholders.”[8] − Products would be competing on performance and quality; the product with the best performance and A primary role of the architecture is to capture the quality would win the final contract. design decisions, the rules that have to be followed in the detailed design of the system, made by the architect So we found ourselves with the challenging task of to ensure that the system meets its quality building high quality, high performance software requirements. Current architectural methods state that supporting efficient maintenance and a lightweight this shall be done by specifying patterns [9] to be spawning of variants. This had to be done on an followed in the design [8, 10, 11]. Since there is no imaginary hardware platform with requirements that suggested formal way to describe patterns or pattern would change during the development on a fixed, very usage there is a problem in describing the architecture short, timescale. in an MDD context where the idea is to use formal At the time of the project, CS was a Swedish models for all important design artifacts. This means consultancy company specialising in services for that with this way of using MDD one cannot achieve developing embedded real-time systems. CS had the potential benefits of MDD for the architecture. approximately 250 consultants of which about 75 This report shows that this can pose big problems in where involved in the project. The total effort of the large industrial software development projects where project was 100+ person years expended over an 18 architecture is very important. months period. The project was distributed across five sites located in Jönköping, Linköping, Växjö, 2. Background Helsingborg and Trollhättan. CS developed the platform as a phased fixed price In the year 2000 the company Combitech Systems (price negotiated for each phase) assignment for a (CS) faced the challenging task of developing a customer company. CS had full responsibility for the software platform for a new generation of digital TV software but the customer wanted control of the set top boxes for the DVB standard. The development architecture of the software so the architecture team had to be done in 18 months under strict quality was actually managed by the customer and not by CS, requirements and on a completely new, customized although they were CS employees. This meant that hardware platform developed in parallel by another there was a need for a counterpart on the CS side, company. making sure that the architecture also was feasible The challenge consisted of the following elements: within the budget. This was the project role of one of − Short time to market; since CS were in the authors of this paper, technically responsible within competition with other developers the product had the CS project management team, with prime to be ready at a fixed date. responsibility to negotiate the architecture with the − Since the hardware was to be developed in parallel architecture team. with the software there would be little time to integrate the two, leading to a significant risk of 3. Rationale for choosing MDD errors and misunderstandings that would have to be handled by very late changes in the software. Importantly, CS had relevant previous experience Therefore CS needed to test the software on a from maintenance on the previous generation of the range of platforms, from host PC to real target product. There was to be more functionality and hardware with several intermediate hardware completely different hardware, but the base platforms. functionality would remain the same. So there was − The requirements were a moving target where the pretty good knowledge about the capabilities of the initial requirement specifications would be product and how to realize them. The older product overridden by acceptance tests delivered late in was developed by another company. When CS took the project. over the maintenance of the product the company had − Maintenance would be long and had to be very difficulties both in maintaining it and adapting it for cost effective. different markets. This was caused by poorly − There was a requirement to be able to differentiate structured code in C with documentation that was the product, releasing different variants for obsolete through lack of maintenance.
29th International Conference on Software Engineering Workshops(ICSEW'07) 0-7695-2830-9/07 $20.00 © 2007 Within CS there was also extensive experience of − modeling in standard UML, to minimize the working with models in UML and earlier modeling need for training; languages, both for analysis and design models. CS − generation of code with good performance on also had experience of using rule-based transformation our target platform, the host platform and the from design models directly into code which executed G1 platform since this would be used as an on a platform. However, in real projects CS had only intermediate test platform; done the transformations manually so far, although − 100% of the developed code generated from experimentation with automatic code generation had the model (to avoid synchronization problems been done to a degree where the company felt ready to with code and model) having at the same time apply it in a real project. Given this experience there the ability to use pure C++ code where there was conviction that model driven development would was a need (to remove any risk that one could help in taking on the challenges of the project. not do some things that it was possible to do in the traditional way); 3.1. Agility − the ability to debug at the model level; − support for distributed team working; The approach made it possible to work in an agile − a high probability that the vendor would way where one could quickly go from requirements to continuously improve the tool towards the tested implementation without having to skip requirements of embedded real-time system documentation, something very important for the development. maintainability of the product. After a short evaluation Rhapsody from Ilogix was selected as the only tool that seemed to satisfy all these 3.2. Test on several HW platforms requirements. The selection of Rhapsody meant that a system is MDD would make it possible to test most of the designed in a UML model with action code in C++. code without access to the actual hardware by simply This model (the system model) is then automatically generating code for different platforms, as the project converted to full production code in C++ by the tool. gained access to hardware that became increasingly The generated code uses an execution framework similar to the final target. (OXF), provided by the tool, to abstract out the target execution platform. In terms of MDA [5], the model 3.3. Performance built in Rhapsody corresponds closest to the PIM, where OXF and the generated code corresponds to the For performance reasons it was important to pay PSM. special attention to generated code, which had to be efficient. But if this requirement was satisfied, the 4. Capturing the architecture ability to keep the work on a higher abstraction level would enable refactoring with less effort, which in turn To be able to meet the deadline quite a lot of made it easier to fine tune the system to obtain better developers had to work in parallel with different parts performance. of the system. This required a stable architecture before the project scaled up. A product line 3.4. Product variability architecture approach [10] was selected to address the requirements for efficient development and Of course product variability is primarily an issue maintenance of product variants. In addition to this for the architecture, but there was also a thought that there were other important quality requirements such MDD would make it easier to both communicate and as portability (the software was anticipated to outlive enforce the architecture since a big part of it would the hardware) and overall performance, which had to actually be represented directly in the system model. be handled by the architecture. So, architecture was very important. 3.5. Tool selection One of the first problems to face was how to represent the architecture when working in a MDD Since there was very little calendar time an out-of- context. A basic idea in MDD is to use models instead the-box tool solution was required that would give the of documents to represent the requirements and design following: of a system and to generate the implementation code from these models. The traditional way of representing
29th International Conference on Software Engineering Workshops(ICSEW'07) 0-7695-2830-9/07 $20.00 © 2007 the architecture is in a document that guides and − “Any arcComponent with behavior similar to constrains the detailed design. In model oriented an arcPort should be a specialization of methods, like Rational Unified Process, where models arcPort.” have replaced requirement specifications and design − “All specializations of arcPort may have one descriptions you still represent the architecture in a overloaded method for each of the methods document. Our aim was higher than this; the aim was, Open(), Close() and Write()”. as much as possible, to automatically connect the − “All specializations of arcPort may have architecture to the design to minimize both the several methods for the method Ctrl(). These maintenance problem and the effort to enforce the methods shall be named as architecture on the design. In the end the project settled ctrl_
and de-allocation). 5.1. Manual enforcement and guidance is time Unfortunately the project didn’t reach all the way to consuming and error prone capturing the architecture in a formal model. There was a need to use natural language to express the rules Using natural language to describe architectural on how to use the architectural framework to design design rules meant that we had to rely heavily on the components in the architecture. There were more manual reviews to enforce conformance with the than sixty rules that had to be followed. Below is a architecture. The rules also proved to be hard to small subset of these rules.
29th International Conference on Software Engineering Workshops(ICSEW'07) 0-7695-2830-9/07 $20.00 © 2007 ComponentRegistry::arcComponentRegistry 1 ComponentRegistry::arcComponentUser
1 * Notifyer::arcListener
<
ComponentRegistry::arcProfile Notifyer::arcNotifyer <
*
ComponentRegistry::arcComponentFactory * ComponentRegistry::arcComponent <
Locked::arcLockedUser <
Locked::arcLocked <
Port::arcPortUser <
Port::arcPort <
Figure 1 Architectural framework
enforce and ambiguous, and thus prone to different changes to the architecture in order to fine tune it interpretations. against its quality requirements did not hold. Several developers reported having a hard time trying to understand and follow all of the detailed 6. Summary rules. This was manifested by the fact that a lot of time was spent by the architects on reviews and by the fact As we have seen in this example MDD allows some that corrective actions were generally needed after of the architecture to be captured in formal models but reviews. Sometimes this meant that a lot of reworking current methods and tools for MDD do not support had to be done since reviews were often held when formal representation of architectural rules that go design had continued too long. This was caused by beyond structure. These rules are instead typically work overload on the architects, which in turn was represented as text in natural language to be followed caused by a lot of effort having to be spent on by developers in the detailed design. This means that communicating and reviewing the designs generated one has to rely on manual interpretations and reviews by the different teams. of rules that often are hard to understand and ambiguous. This requires a lot of effort from 5.2. Late changes to design rules are time developers and places a heavy burden on architects, consuming and error prone. who represent a sparse resource and so quickly become a bottleneck in the development process. It is also bad Since part of the architecture had to be manually for quality, since manual routines are error prone, transformed into model constructs throughout the especially when time is scarce, which it is if you are a model, it required a lot of effort to change the rules or bottleneck. the architectural framework. This made it almost Another problem is that since the architectural rules impossible to make late changes to the architecture. So are manually introduced throughout the models it is the initial idea that MDD would allow us to make late very hard to make late changes to them: it often involves massive reworking. These rules are typically
29th International Conference on Software Engineering Workshops(ICSEW'07) 0-7695-2830-9/07 $20.00 © 2007 an attempt to find a compromise between conflicting [4] B. Hailpern and P. Tarr, "Model-driven solutions to different quality requirements. Early in the development: The good, the bad, and the ugly," project you generally don’t have enough information IBM Systems Journal, vol. 45, pp. 451-461, to make an optimum solution but you still have to have 2006. a stable architecture before you can ramp up the project. So, you have to guess some things. Some of [5] MDA, "MDA Guide version 1.0.1," OMG, these guesses are probably wrong. This means that you 2003. generally have a need to change some of your architectural rules late in the project, so the ability to [6] T. Dave and M. B. Brian, "Model driven have a tool to automatically update your model when development: the case for domain oriented you change the rules could save a lot of time, or enable programming," in Companion of the 18th annual optimization of the system. ACM SIGPLAN conference on Object-oriented Therefore, if one could capture architectural rules in programming, systems, languages, and a way that would make it possible to automatically applications Anaheim, CA, USA: ACM Press, enforce them on, and propagate changes to the system 2003. model, it would represent an opportunity to dramatically improve both efficiency and quality. [7] J. Greenfield and K. Short, Software factories : From this experience we believe that to obtain the assembling applications with patterns, models, full benefits from MDD there is a need for support of frameworks, and tools. Indianapolis, IN, USA: formal modeling of architectural rules and automatic Wiley Pub., 2004. enforcement of these rules on the generated models of the system. [8] L. Bass, P. Clements, and R. Kazman, Software architecture in practice, 2nd ed. Boston: 7. Acknowledgements Addison-Wesley, 2003.
This research has been financially supported by the [9] F. Buschmann, Pattern-oriented software ITEA project COSI (Co-development using inner & architecture : a system of patterns. Chichester ; Open source in Software Intensive products) New York: Wiley, 1996. (http://itea-cosi.org) through Vinnova (http://www.vinnova.se/). [10] J. Bosch, Design and use of software architectures : adopting and evolving a product- 8. References line approach. Reading, MA: Addison-Wesley, 2000. [1] B. Selic, "The pragmatics of model-driven development," IEEE Software, vol. 20, pp. 19- [11] L. Bass, M. Klein, and F. Bachmann, "Quality 25, Sep-Oct 2003. attribute design primitives and the Attribute Driven Design Method," Software Product [2] D. C. Schmidt, "Model-driven engineering," Family Engineering 4th International Workshop, IEEE Computer, vol. 39, pp. 25-31, Feb 2006. PFE 2001 Revised Papers Lecture Notes in Computer Science Vol 2290, vol. 2290, pp. 169- [3] K. Balasubramanian, A. Gokhale, G. Karsai, J. 86, 2002. Sztipanovits, and S. Neema, "Developing applications using model-driven design [12] E. Gamma, Design patterns : elements of environments," IEEE Computer, vol. 39, pp. 33- reusable object-oriented software. Reading, 40, 2006. Mass.: Addison-Wesley, 1995.
29th International Conference on Software Engineering Workshops(ICSEW'07) 0-7695-2830-9/07 $20.00 © 2007