Architecture Component Development - generating more code from your UML models

Transcription

1 Aonix Architecture Component Development - generating more code from your UML models Software through Pictures White Paper May 2000 Stefan Huber, Siemens AG Österreich, PSE Heinz G. Seidl, Aonix GmbH Page 1 of 14

2 Architecture Component Development The most important thing to design properly is the user s conceptual model. Everything else should be subordinate to making that model clear, obvious, and substantial. That is almost exactly the opposite of how most software is designed. Terry Winograd in Bringing Design to Software Executive Summary The Unified Modeling Language (UML) provides a wide range of graphical notations and textual means to describe a software system in an abstract way. Depending upon the architecture of the system, the detailed design is often complex and difficult to maintain. This white paper discusses the Architecture Component Development (ACD) technology, a proven and comprehensive development approach, where the objective is to get a clearer, compact, more easily understandable and maintainable UML design model. Large parts, conceivably up to 70%, of the application implementation can be generated automatically from the design model according to the target application architecture. The advantages are obvious: dramatically higher productivity, better quality, and easier maintainability, whilst also assisting with creating reusable components. "A Model is an Abstraction of Reality" (UML User Guide) The relatively short history of software engineering marks a quest for higher levels of abstraction. Abstraction from the concrete implementation of a program towards the abstract user and business oriented requirements of the problem domain. Software development has evolved from machine code to symbolic assembler and on to procedural and more recently object oriented languages. Unfortunately, with the rise in the level of abstraction of programming languages, the level of complexity of the systems to be implemented has increased as well. In order to deal with this rise in complexity, systems were described with graphical languages and notations, from which textual implementation languages could be derived either manually or automatically using tools. Page 2 of 14

3 Today many systems are described graphically using the Unified Modeling Language (UML) which provides nine diagram types, and many graphical and textual elements to capture and model the requirements of a system. However, there is a basic flaw with this approach. Whilst we may achieve a greater understanding of the user and system requirements, only a small amount of these modelling elements are typically realised in the implemented system as source code. This leads to models which are constructed to achieve maximum code generation, rather than accurately representing the business or user requirements in a maintainable way. Are your UML Models an Abstraction of Reality? A design model should ideally specify a software system in an abstract way that is it should be an abstraction (higher level view) of the implementation. However, what typically happens, is that the class models are constructed as a direct copy of the implementation s static class structure, giving a one to one mapping. This is great for code generation, but results in models that are bloated with unnecessary details, making them difficult to modify and maintain. Instead of models illustrating a blueprint that describe the architecture, most models describe where each "brick" belongs. This concentration on the implementation view is entirely understandable after all, since the physical realisation of this view is the only piece of the overall puzzle that the business and the users see and interact with. The majority of software developers and UML users have more experience in brick-laying (coding software) than in creating architectural models. The advantages of a good architectural design are still not generally recognized enough in day to day practice. This concentration on the implementation view means that a lot of effort is required for low potential gain - as illustrated in Figure 1. Where tools are used, code is often only generated from the UML Class Model, which to be effective means that the degree of abstraction in the model is very low compared to the implementation. Therefore, in most projects, many very detailed class models are created, just so that code can be generated, leaving the other features of UML unused. Page 3 of 14

4 UML Model Application Code 50 % Class traditional code generation generated % State Use Case Scenario Code to be manually implemented % Other Figure 1: High modelling effort typically yields very little source code Since most UML tools only generate 10% - 15% of the application source code automatically, even with detailed models of low abstraction, the rest of the system has to be coded manually. Some approaches will provide a higher percentage of generated code, but this is offered at a price of reduced flexibility, with limited architectures, a narrow selection of implementation languages, and restrictions on modifying the generated source code. Reduce modelling effort but increase the amount of generated code In order to translate a 1 to 1 design model into source code, it is necessary, subject to architecture, conventions and programming language, to include many details in the model, which are actually redundant. Redundant because these details can be derived from the architecture or design conventions or from standard design patterns, and furthermore because these details are typically used identically in many classes. There are many examples where this might be the case, and it is in these areas where code can be generated automatically, if these details and conventions are expressed in a form that is accessible by an intelligent generator, in conjunction with the analysis and design model. These include: Set and get operations read and write functions for attributes. Page 4 of 14

5 Standard methods e.g. constructors/destructors that solve various standard tasks depending on the architecture or the project s conventions. Standard interfaces, design patterns or design conventions The project or architecture can define these. For example, an important portion of component technologies such as Enterprise Java Beans (EJB) is the definition of special design conventions and standard interfaces, which must be met. Help classes Factory classes that generate or load new business objects. Test frame classes that support the class and component test of objects or business objects. Code to support testing Standardised functions and code fragments that are implemented in every class. Persistence How information is stored/retrieved from a relational or object-oriented database. Logging Error, event and testware logging. If all these details are represented in the design model, it becomes unnecessarily cluttered, overloaded, and difficult to maintain and modify. Further the model does not accurately represent the business model, but is polluted with non-core application details. In practice, models are often somewhere between these two extremes: A compact, well structured design model that has no implementation details. The implementation is 100 % manually coded. Its disadvantage is that the design model and the implementation will eventually diverge. Highly detailed, but confusing class models that accurately reflect the code. However, this model is often not generated before coding, but rather as pure graphical documentation of the code by using roundtrip engineering. What is actually required is a compact, well-structured design model, without unnecessary detail, and where as much code as possible can be generated automatically. We call this approach and its supporting technology Architecture Component Development (ACD). The following sections will describe this approach and supporting tools. Page 5 of 14

6 Architectural Aspects of Applications and Systems Complex application systems generally have some semblance of structure, even if this has not been clearly articulated in a model or design document for example. Layers, structures, and patterns that encapsulate the actual architecture of the application are almost always present, but are often scattered throughout the implementation. CORBA applications are built around an infrastructure for distributed systems based on remote object invocation. Figure. 2 is an example classification of a CORBA 3-tier application into high level areas or architectural components. GUI Client Business Logic Mainly manually implemented or with GUI-Builder Test classes Persistency Can be generated mainly from the UML model Architectural Infrastructure Figure. 2: Example code areas for a three tiered CORBA architecture Figure 2 suggests that the different areas of the application are cleanly layered and separated. This does need not to be the case, since code like the architectural infrastructure may be pervasive in the implementation. The architectural infrastructure in this case consists of aspects necessary for a 3-tier architecture such as multi-threading and support for transactions. However, in most applications there are aspects such as memory management, error handling, design patterns, persistence, tasking etc. that are structural aspects of the application, but cut across the functional areas of the application. These are to some extent standards, conventions, language idioms and are therefore key to the application, but are not part of the business or system functionality. Of the areas shown above, only the business logic has to be completely manually modeled and implemented. With ACD, all the other pieces, the test driver, persistence Page 6 of 14

7 and architectural infrastructure environments can mostly be generated automatically from UML models, with a GUI builder being used to generate the GUI client code. Transforming High Level Designs into Applications As a rule, it is advisable to differentiate between technical and domain aspects of architecture [Ambler 97]. Typically, up to a dozen or more implementation classes will arise out of a conceptual business object depending upon the architecture. [CDS 98] comes to a similar conclusion. Figure 2 shows the details of a design at a high level, which still concentrates mainly on domain aspects (business objects). At the lower level, technical and implementation details are added to the domain aspects. High level design Room numbeds price Business object reserve OTSTransObj_i Patterns Architecture Conventions Low level design Room_p select (obj:room_i*) insert (obj:room_i*) update (obj:room_i*) delete (obj:room_i*) Room_i business logic CORBA Mgmt. Persistence Test features RoomFactory... Room_scr Figure. 3: Mapping a high level design into implementation The domain elements of the business objects, which are visible at the higher level in the design, are also found in the detailed design. In Figure 3 these are labelled as business logic in the implementation class Room_I. It is important that in practically all business objects, that the same architectural conventions or design patterns play a similar role when refining the high level design to the detailed design. For example, persistence and CORBA factory classes can be generated and implemented in the same way for all the business objects, avoiding duplication, and the introduction of bugs and inconsistencies between different implementations for the same mechanism. Instead of implementing this manually for all business classes, ACD uses templates which contain the knowledge of how to transform the high level design into the Page 7 of 14

8 implementation (see Figure. 4). Thus, there is no longer a requirement to explicitly create the implementation level design. High level design Room numbeds price reserve ACD Transformation ACD Templates Code IDL Code C++ Code business Factories Testcode Persistency Figure. 4: Automatic generation from a high level design A similar treatment of architectural aspects and extensive use of code generation allows a design to be kept at a higher level of abstraction - models are therefore more compact, easier to understand and maintain. Therefore, it is not necessary to create dozens of implementation classes explicitly in the UML design model for every conceptual business object. This information is captured in a set of templates, which defines a company or application specific architecture and all the associated standards, conventions and common mechanisms. Design and implementation patterns as well as architectural details, as they are required in the field of component software and object oriented frameworks, can mostly be generated automatically. The design model can therefore be transformed in a manner that goes beyond simple code generation. ACD thus enables the creation of a UML design of the domain. The design remains clear and easy to understand and furthermore, it is much easier to keep updated throughout the entire project life cycle and to achieve re-use of both design, implementation and of course the templates. Page 8 of 14

9 Capturing the Architecture Aspects of an Application In order to be able to use ACD, it is advisable to employ a tool that supports the UML as totally and comprehensively as possible. The goal of modelling is to represent all aspects of the application as precisely as possible and then to transform the model into source code for the appropriate platform The knowledge about the implementation of the architectural model is explicitly presented in a simple, declarative template language. This language enables access to the UML modelling elements and is much simpler but also much more abstract than the scripting languages used by current visual modelling tools. In this way, it is possible to generate with relatively little effort between 30% and 70% of the source code automatically from the repository of a UML modelling tool, using both the class and state models. Templates can be constructed to support many languages, and different architectures, thus a number of templates have been put together to support the generation of C code from UML models. Leveraging more UML Constructs into the Implementation In addition to the examples mentioned above for conventions and design patterns there are modelling elements in UML that cannot be mapped directly to the implementation language constructs. For example: Associations Static attributes/functions, e.g. in CORBA-IDL Associations, such as in CORBA IDL State models The implementation of these and other UML constructs can be captured in templates, so that the architectural or project specific constraints for implementation can be automatically applied across a project. Directives, using tagged values and stereotypes can determine a particular implementation strategy. Furthermore, templates can be reused between projects. Page 9 of 14

10 De-coupling the analysis and design from the implementation One of the most powerful concepts of ACD is type mapping, which allows the decoupling of types used in the analysis and design from the types needed in the implementation. Type mapping also helps to generate all the necessary include, forward or import statements allowing the creation of 100% compilable code. Furthermore, technology specific type handling, e.g. in the CORBA environment the mapping of the CORBA-types to the respective implementation language types, and even project specific type conventions, can be supported in the framework of type mapping. Roundtrip Engineering Considered Harmful Roundtrip-engineering has been coined to described the potential synchronisation between models and source using reverse engineering. In practice this is tricky to use effectively, since it only works in the case where there is a 1:1 correspondence between code and design model. Starting out with an abstract model will result in a model that mirrors the source code - with all the attendant problems. When using ACD there is, however, no 1:1 correspondence between classes in the UML-tool and in the source code (see Figure. 4). Rather, applying transformation rules to the design model generates complex implementation code. For example, depending upon the project or architecture, additional details could emerge in the form of classes (such as the factory classes) or standard operations (e.g. setter, getter) during the transformation from design into implementation. All of this automatically generated code does not add any relevant information to the design and therefore it does not make sense to reverse engineer it into a class model. Roundtrip engineering from a software engineering perspective is questionable anyway. It makes even less sense when using ACD. Instead, an iterative development process is suggested where all relevant design changes are made in the design model. Page 10 of 14

11 Design model Reverse Engineering??? ACD ACD Transformation IDL Code C++ Business Factory Test Code Persistence Figure 4. 1:n Mapping of the design into the implementation ACD improves Productivity and Quality Obviously, the effort to describe the transformation rules in the ACD template language is small compared to the effort of the manual implementation of the code. Depending upon the architecture one can expect that roughly 50% of the source code for an application can be automatically generated. Each manually implemented code line is a possible source for bugs and therefore code re-work and must be changed manually when modification is necessary. Generated code has a higher quality, is consistent, can be very easily adapted, through modification of the templates. Therefore, with ACD, dramatic improvements in productivity and quality are the result. Especially during later project stages, like maintenance or further development, the advantages of ACD become even more noticeable. Because of the fact that architecture specifics can be implemented by using ACD-templates, it even becomes possible to reuse architectures. Page 11 of 14

12 Making More Effective Use of Technology Specialists Many software development projects and IT departments of larger companies do not have enough technology specialists to implement the business and user requirements using state of the art technology. For IT departments it is already hard enough to understand all the requirements to support the business's core needs. To be up to date on all the new developments in technology parallel to this is almost impossible. This, in turn, results in application and domain specialists being forced to get involved with database design and to trouble themselves with COM. With ACD, the application specialists can concentrate on the business view. The few technology specialists write templates and develop architectural concepts as well as develop central technical classes. There is little need to document design and coding rules in project manuals,, which are usually hard to communicate and check anyway. Instead, the templates will automatically take care of many of these rules. Summary Architecture Component Development (ACD) provides new mechanisms and tools, which allow the use of UML in a software development project as a consistent and upto-date information base. There is no need to create and maintain a detailed design model, which is overburdened with implementation details. ACD helps to realise many sought after benefits in software projects today. To try and bring in projects on schedule, whilst meeting budgets, required functionality and quality objectives with the available staff. Page 12 of 14

13 References and Literature [Ambler 97] Scott W. Ambler: Architecture Driven Modeling. Software Development, Dec.97, pg.71f [AOP] Aspect Oriented Programming (see: [Booch 96] G.Booch: Managing the Object-Oriented Project. Addison-Wesley 96, pg.46 [CDS 98] Component Development Strategies, Sept. 98. Cutter Group, pg.4 [DeMarco 98] Tom DeMarco: The deadline, Dorset House, 1997 [Winograd 96] Terry Winograd: Bringing Design to Software, ACM Press, 1996 [Boehm 87] Barry Boehm: Improving Software Productivity, IEEE Software 9/1987 Page 13 of 14

14 To obtain more information, please contact Aonix at or your local Aonix office. Aonix World Headquarters Phone: (800) 97-AONIX Fax: (858) France Phone: +33 (0) Fax: +33 (0) info@aonix.fr United Kingdom Phone: +44 (0) Fax: +44 (0) info@aonix.co.uk Karlsruhe, Germany Phone: +49 (0) 7 21/ Fax: +49 (0) 7 21/ info@aonix.de München, Germany Phone: +49 (0) 89/ Fax: +49 (0) 89/ info@aonix.de Sweden Phone: +46 (0) Fax: +46 (0) info@aonix.se 2000 Aonix. All rights reserved. Aonix is a registered trademark of Aonix Corporation. All other company and product names are the trademarks of their respective companies. SMS Page 14 of 14