Significant Productivity Enhancement through Model Driven Techniques: A Success Story M.Born, J. Hössler, O. Kath, M.Soden IKV++ Technologies AG Bernburger Strasse 24-25, 10963 Berlin, Germany {born|kath|soden|hoessler}@ikv.de S. Saito, NTT Data Corporation 3-3-3 Toyosu, Koto-ku, Tokyo, Japan [email protected]Abstract This paper describes the automation and optimization of the software development process of NTT Data. The development process defines the business modeling, requirement capturing as well as, system planning and implementation activities to be carried out by the development project members. The target systems of this development process are large web based information systems implemented by leveraging Java/Java EE 5 technologies. The automation and optimization of that process was achieved by the application of model driven techniques, mainly the integration of development tools via a Meta Object Facility (MOF) repository backbone, the provision of automation by facilitating model transformations and code generation and by increasing the consistency and traceability of all development artifacts. An evaluation within NTT Data showed a development effort and time reduction of more than 50%. The main lessons learned form this case include the necessity of model-to-model transformations, the need to preserve advantage of existing development process and tools landscape, the requirements to care about configuration and change management from the beginning and requirements to support also non modeling tools. 1. Introduction Software and systems development techniques and tools have dramatically increased their capabilities during the last years. New products and paradigms are coming down the road, claiming to have the potential to increase particular activities or steps in the systems modeling and development process of a software development company. However, those new methods or tools often require the adaptation of the modeling and development process established in such a company. Changes or adaptations in the development process definition can easily be done in small, agile companies who might always adapt their systems development to each customer project. In contrast to them, for a large system integration company like NTT Data the situation is different, because they have their own software development processes and design techniques. Such processes and techniques usually construct their competitive advantage and are widely accepted by their employees. Therefore, in such circumstances, new methods and tools have to adapt to the modeling and development process as well as to the existing development tools landscape. That justifies why large organizations usually cannot just apply out-of-the-box solutions and do always require an integrated and customized, process specific version of new system development techniques and tools. Accordingly, solutions need to be provided to such large organizations that allow both keeping the existing development process and tools on the one hand and introduce new development methods and techniques on the other. The provision of such solutions by IKV++ Technologies AG is based its core technologies called medini. medini comprises of a set of tools and components around the Model Driven Architecture (MDA) [6] initiative. In MDA, well-defined models replace programming code as primary development artifacts. Based on a clear semantic foundation using Meta Object Facility (MOF) [5] system modeling and development methods and tools are seamlessly
Transcript
Significant Productivity Enhancement through Model Driven Techniques: A Success Story
M.Born, J. Hössler,
O. Kath, M.SodenIKV++ Technologies AG
Bernburger Strasse 24-25, 10963 Berlin, Germany
{born|kath|soden|hoessler}@ikv.de
S. Saito, NTT Data Corporation3-3-3 Toyosu, Koto-ku,
This paper describes the automation andoptimization of the software development process ofNTT Data. The development process defines thebusiness modeling, requirement capturing as well as,system planning and implementation activities to becarried out by the development project members. Thetarget systems of this development process are large webbased information systems implemented by leveragingJava/Java EE 5 technologies. The automation andoptimization of that process was achieved by theapplication of model driven techniques, mainly theintegration of development tools via a Meta ObjectFacility (MOF) repository backbone, the provision ofautomation by facilitating model transformations andcode generation and by increasing the consistency andtraceability of all development artifacts. An evaluationwithin NTT Data showed a development effort and timereduction of more than 50%. The main lessons learnedform this case include the necessity of model-to-modeltransformations, the need to preserve advantage ofexisting development process and tools landscape, therequirements to care about configuration and changemanagement from the beginning and requirements tosupport also non modeling tools.
1. Introduction
Software and systems development techniques andtools have dramatically increased their capabilitiesduring the last years. New products and paradigms arecoming down the road, claiming to have the potential to
increase particular activities or steps in the systemsmodeling and development process of a softwaredevelopment company. However, those new methods ortools often require the adaptation of the modeling anddevelopment process established in such a company.Changes or adaptations in the development processdefinition can easily be done in small, agile companieswho might always adapt their systems development toeach customer project. In contrast to them, for a largesystem integration company like NTT Data the situationis different, because they have their own softwaredevelopment processes and design techniques. Suchprocesses and techniques usually construct theircompetitive advantage and are widely accepted by theiremployees. Therefore, in such circumstances, newmethods and tools have to adapt to the modeling anddevelopment process as well as to the existingdevelopment tools landscape. That justifies why largeorganizations usually cannot just apply out-of-the-boxsolutions and do always require an integrated andcustomized, process specific version of new systemdevelopment techniques and tools. Accordingly,solutions need to be provided to such large organizationsthat allow both keeping the existing developmentprocess and tools on the one hand and introduce newdevelopment methods and techniques on the other.
The provision of such solutions by IKV++Technologies AG is based its core technologies calledmedini. medini comprises of a set of tools andcomponents around the Model Driven Architecture(MDA) [6] initiative. In MDA, well-defined modelsreplace programming code as primary developmentartifacts. Based on a clear semantic foundation usingMeta Object Facility (MOF) [5] system modeling anddevelopment methods and tools are seamlessly
integrated to form open, extensible environments -customized and specialized to the targeted modeling anddevelopment process. An overview of a typical solutionbased on medini technology is shown in Fig. 1. Multipledistinguished methods and tools are used for thedifferent activities and steps in the development process.Enabled by medini, these methods and tools can run in aseamless environment. This environment takes care ofthe storage and management of all development artifactsin a repository infrastructure which forms the backbonefor integration. The demanded automation andconsistency can be delivered by model transformationand consistency checking technologies as they are alsopart of medini. For model transformation, medini in itscurrent production version provides a MOF transformerskeleton generator and for consistency checking itcontains a full Object Constraint Language (OCL) 2 [3]compliant constraint engine which runs on MOFcompliant models.
Fig. 1 Development tool integration based on MOF repository technology
The medini technology has been applied for theautomation of one of the system development processesapplied in the Public Business Unit of NTT Data. Thedevelopment process aims on the provision of Web-based information systems which are running on a NTTData specific platform which is an abstraction layer forJ2EE/Java [9] technology. The result of this work is theAMEDATO solution - it integrates modeling tools andtechniques applied by NTT Data and automatedesignated development phases and steps.
In the section 2 of this paper we talk about the startingconditions for the process optimization task that lead tothe AMEDATO solution. The first version of theAMEDTAO solution which has been provided mid 2006
and its technology foundation is described in section 3.This first release of AMEDATO has been evaluated byNTT Data in a project context and the results of thisevaluation are summarized in section 4. Some of therecent extensions to AMEDATO are explained insection 5. The lessons which we have learned during theexecution of the project are provided in section 6. Theywill guide the further work on technology improvementas well as further solution projects for other companies.
2. Starting Conditions
The AMEDATO initiative stared in December 2004.At NTT Data, the corporate wide development processfor business modeling, requirements definition, designand coding of large information systems was preciselydefined in a bunch of documents. The process definitionwas widely used in most of NTT Data's developmentprojects. The process has been constructed based on alot of experiences from large scale softwaredevelopments NTT Data has done so far now. Thisprocess definition documents include the detaileddescription of the to-be produced development artifacts.Furthermore they describe how the developmentinformation is exchanged between the developmentphases. Mostly, this exchange was realized in practiceby text documents and spreadsheets, but also UMLdiagrams were already in use for some artifacts like UseCases. The development process and main phases aresketched in Fig. 2.
Fig. 2 Document centric development process as target for automation
Although the process description document containedalready a specification of transformations rules (forexample the transformation of design classes onplatform specific Java code was explained) theautomation degree was very low. In fact, some small
systemplanning
requirementscapturing
test , integrat ionand operat ion
development systemdesign
systemplanning
requirementscapturing
test , integrat ionand operat ion
development systemdesign
BusinessModeling
User InterfaceDesign
Use CasesDesign
DetailedImplementation
Design
Coding andUnit Testing
BusinessModeling
User InterfaceDesign
Use CasesDesign
DetailedImplementation
Design
Coding andUnit Testing
BusinessModeling
User InterfaceDesign
Use CasesDesign
DetailedImplementation
Design
Coding andUnit Testing
tools existed which could extract information out ofspreadsheets and transformed them into code. Theusability of these tools was limited in the sense that theinformation was not combined, changed or enriched asfor usual transformations but just extracted and forexample inserted into XML documents or one-to-onespit out to Java code. Besides the lack of automation, alot of development resources have been wasted forkeeping all development artifacts up to date. In otherwords, the consistency between the developmentartifacts at the various steps in the development processhas been identified as the main problem which requireda solution. Change requests, e.g. if a customer contactsNTT Data to change the development goal model orrequirements specification, do usually result ininconsistencies between the development informationcontained in different documents. Since there are noautomatically managed references - which we call traces- between the various information elements it has beenhard to maintain consistency by manual maintenancework. Moreover, changes did have to be manuallypropagated through all the subsequent phases in thedevelopment process without automation support. Thisapproach has been especially error-prone in the case thatchanges do effect early phases like requirements orbusiness models.
NTT Data therefore requested a significantimprovement of the productivity by automation and alsosupport for consistency checking and maintenance.Furthermore, they wanted to preserve the process itselfand also the tools used so far should be kept in place. Ifa change to the tools landscape would turn out to benecessary, it was required that the resulting solutionshould not rely on expensive new tools.
The overall business modeling, requirementcapturing, system planning and realization process ismade up of 15 different phases, targeting all of them inone shot turned out to be not efficient. Therefore it wasdecided to firstly target the phases Use Case Design,Screen Flow Design, Control Design, Detailed ClassDesign and Coding. This selection was natural due tothe fact that they showed a high potential forautomation. After successfully finishing this first step,the solution should be extended to the more upstreamphases and the testing as well.
In technology terms, at the starting point of theAMEDATO project, the medini base technology at IKVcontained a MOF repository generator which was ableto completely generate model repositories from MOF1.4 metamodels in C++ language including remoteaccess via CORBA [4] and XMI [8] technology.Furthermore, an OCL constraint checker was available,which can generate C++ code for the constraint
evaluation with high performance as well as to interpretthem at runtime.
3. The AMEDATO Solution
For the provision of the AMEDATO solution, the"medini process pattern" of IKV++ Technologies AGhas been applied. This methodology has been developedto interweave the concept of Model Driven Architectureinto existing or to-be defined workflows (e.g.development processes) of customers enabling them tobenefit from the MDA advantages without having torecreate their existing development cycles from scratch.Making the entire MDA aspects - specifically theapplication of abstract techniques such as MOF, OCLetc. - completely transparent to the customer during thejoint development and collaboration is one of the keyfeatures of the medini way of helping applicants tobecome more efficient without having to worry aboutthe intrinsic details of the underlying technologiesapplied. According to the medini process pattern, theoptimization and automation of development processesbegins with an in-depth analysis of the currently appliedprocess, the applied development tools, the artifacts tobe produced in each development phase and theirvarious relations. This analysis work leads to ametamodel or metamodels for development aretfacts.These metamodels are used later in the process as theheart of the tools integration and automationenvironment: they are the main source for providingmodel repositories which do form the backbone of anytools integration and automation environmnet.According to the medini process pattern, under carefulconsideration of the as-is methods, techniques and toolssituation, the selected development tools aresubsequently customized and tailored to the process.They are connected to a model repository infrastructureobtained by application of the MOF standard to themetamodel. Model transformations, consistencychecking and maintenance as well as traces managementbetween development artifacts are realized byleveraging the detailed information in the modelrepositories. The following subsections do give anoverview on how the medini process pattern has beenapplied to AMEDATO.
3.1. Process Analysis and Metamodel Definition
The development process applied in NTT Data isdefined in terms of the supported development phasesand the artifacts to be produced in each of these phases.It is described in a set of documents available to the
developers. For each phase, a set of tools or notations isalso defined which is applied to let the developersproduce the necessary information. During the processanalysis done according to the medini process pattern, itis the task to understand the development artifacts indetail. This deep understanding by the developmentprocess analysts is necessary to formalize the gainedinformation in a set of metamodels since each and everyaspect and property of a development artifact elementhas to be precisely defined there to let the resulting setof metamodel definitions be a mirror of the actualdevelopment process.
As the first target for automation of the NTT Datadevelopment process, 5 phases have been selectedranging from the system use case description to theapplication coding. The AMEDATO metamodel definedduring the analysis phase presently contains the detailedspecification of the development information for thesephases and their relations. Those relations play animportant role for subsequent definition of traces,consistency rules and model transformations as well asfor code generation. The metamodel is based on arestricted subset of the Unified Modeling Language 2(UML) - the "Generic" package of the AMEDATOmetamodel is actually based on the "Kernel" package ofthe UML 2 metamodel. It contains both structural andbehavioral definitions like classes, use cases, activitiesand basic actions. The decision of using the UML 2metamodel as foundation for the AMEDATOmetamodel has not been taken for tooling reasons, butbecause the elementary concepts of the NTT Datadevelopment process do have a number of similaritieswith the UML 2 core concepts.
All elements in the AMEDATO metamodel which arespecific for the NTT Data development process phasesare inheriting from elements in the package "Generic".To define these specific elements, the documents andartifacts produced by NTT Data in real developmentprojects together with the process description documenthave been analyzed (Fig. 3). In the following we give afew examples of how the detailed metamodel has beendefined based on the analysis of existing artifacts fromreal developments:
• the system planning and development is based onuse case driven requirements capturing, leading tothe inclusion of the use case concept in the AMED-ATO metamodel,
• the detailed properties of use cases going beyondthose defined in the UML 2 metamodel, which areused for system planning and for development, areusually specified in large excel tables. The details ofthe columns of these Excel tables are candidates for
properties of a metaclass for the development pro-cess specific use cases,
• the development process includes an activity to de-scribe the structure of user interface pages (so calledscreens) and the flow of user interface pages depend-ing on user input or system output (so called screenflows); these concepts have been included in theAMEDATO metamodel as specialization of theUML 2 activities package,
• the detailed concepts used in the implementationmodel for a system under development have been in-cluded in the AMEDATO metamodel as specializa-tions of the UML 2 concepts class, interface,method, behavior etc.
Fig. 3 Example of a development artifact specified in Microsoft Excel
3.2. Notation Definition and Tool Customiza-tion
Now that the AMEDATO metamodel preciselydefines all modeling concepts and their relations in theNTT Data development process, it is the basis fordefining modeling guidelines and rules, modeltransformations between the various parts of anAMEDATO model belonging to the differentdevelopment process activities covered and it alsoserves as the specification for the AMEDATO modelrepositories to manage the artifacts of the developmentprocess. Besides, the metamodel declares an abstractlanguage for AMEDATO models due to the fact that allthe concepts are declared and the associations in themetamodel precisely define how the concepts are relatedto each other. It should be noted that the metamodel doesnot define a concrete language, i.e. how concrete modelsare to be visualized to the user (the NTT Data engineersand developers). This visualization can be done inseveral different manners. For example, there can be a
textual, tabular based presentation for the AMEDATOuse case concept. The same use case can also bepresented in a UML 2 notation. This flexibility providesthe freedom to declare a notation which fits the needs ofthe target user best. Moreover, multiple notations for thesame metamodel element can be defined thus allowingmultiple tools to be used for editing them. As said, theNTT Data development process contained the definitionof notations to be used in each process phase already.For several artifacts, graphical notations have been used.Based on the MOF metamodel, the AMEDATOarchitects defined notation elements for each metamodelconcept. These newly defined notation elements havebeen drafted to be as near as possible to the already usedgraphical notations. As implementation basis, UML 2profiles have been created for these graphical notationelements as well as tabular notations to serve the non-UML users.
As an example, NTT Data has been using a graphicalnotation for the so called screen flow design asintroduced above (Fig. 4). As said, this developmentartifact defines the screens of an user interface, thecontrols available on each screen and the transitionsbetween screens based on the controls and the systemoutput. In the AMEDATO metamodel, the concepts ofscreen, screen transition etc. have been introduced asspecializations of modeling concepts from the UML 2Activities package. The concept of a screen became aspecialization of the concept Action known from theUML 2 language; the concept screen transition becamea specialization of control flow between actions and soforth. The newly introduced graphical notation for thementioned concepts uses actions and control flowsbetween actions as well. This new notation looks quitefamiliar to the NTT Data engineer, but each element hasa quite precisely defined semantics.
After having finalized the analysis phase, metamodeldefinition and notation definition phases, appropriatefront-end tools have been selected and customized to beused by NTT Data engineers. For the graphicalnotations, the UML 2 tool Enterprise Architect of SparxSystems has been adopted. Apart from the integration ofthe tool into the AMEDATO infrastructure, which isdescribed in the subsequent sections, the toolappearance has been completely customized to supportonly those notation elements that are definedspecifically for AMEDATO, using the built-in profilemechanism.
.
Fig. 4 Example for graphical notation definition based on UML 2
For the tabular notations which will still be used in theAMEDATO solution, a hybrid approach has been taken.For some of the tabular development artifacts, specificdialogs and tabular input fields have been added to thecustomized UML 2 tool. As an alternative tool fortabular notations, which still does play an important rolewith the NTT Data development process, the MicrosoftExcel application serves as front-end, for editinggenerated programming language code, the eclipseenvironment has been integrated.
3.3. Transformation Definition
The analysis of the relations between developmentprocess artifacts lead to the detailed definition ofrelations between metamodel elements representingthose artifacts. These metamodel relations do playanother important role: many of such relations could beautomated, i.e. artifacts of one development processphase can be created partially or completely fromelements of another process phase. To achieve this, thecandidate relations have been identified and so calledmodel-to-model transformers have been realized. InAMEDATO, the approach of defining multiple sets ofmodel transformation rules was preferred instead ofhaving one large set of model transformations thatworks like a magic machine. Small transformation steps,understandable for the user, do support the acceptance ofthis technology by the engineers and developers. Thewhole solution therefore works in a way that the user
業務メニューW1001- 1登記申請一覧照会（ ）受付
登記受付業務の選択
W1101受付番号取得
受付番号取得
終了
W1102受付番号取得（受付日付変
）更中
取得
取得
受付番号取得
W1002申請一覧表示設定
表示設定変更 確認
M
M
MD
D
D
受付日付が変更されている場、合は 受付番号取得ボタン押
。下でW1102画面が起動する変更されていない場合は
。W1101画面が起動する
existing notation
UML 2 based notation
業務メニューW1001- 1登記申請一覧照会（ ）受付
登記受付業務の選択
W1101受付番号取得
受付番号取得
終了
W1102受付番号取得（受付日付変
）更中
取得
取得
受付番号取得
W1002申請一覧表示設定
表示設定変更 確認
M
M
MD
D
D
受付日付が変更されている場、合は 受付番号取得ボタン押
。下でW1102画面が起動する変更されていない場合は
。W1101画面が起動する
業務メニューW1001- 1登記申請一覧照会（ ）受付
登記受付業務の選択
W1101受付番号取得
受付番号取得
終了
W1102受付番号取得（受付日付変
）更中
取得
取得
受付番号取得
W1002申請一覧表示設定
表示設定変更 確認
M
M
MD
D
D
受付日付が変更されている場、合は 受付番号取得ボタン押
。下でW1102画面が起動する変更されていない場合は
。W1101画面が起動する
existing notation
UML 2 based notation
provides a number of definitions in the model in one stepof the development process; afterwards a set of smalltransformations from one step in the process to the nextis applied, and the user provides certain additionalproperties and aspects of the model elements created bythese model transformation steps. These enrichedelements are taken by the next set of modeltransformation rules to produce the elements of thesubsequent step in the process and so on. The mainadvantage is as said the understandability of thetransformations by the user. These transformers do notonly create elements of a model, but more importantlymerge the result of a transformation with the existingparts of the model. That means that the re-invocation ofa transformation step due to changes in thetransformation source does not just overwrites the targetelements, but merges the result of the re-invocationtogether with the existing elements in the target partswhich possibly have already been enriched by the userand thus cannot be just discarded. The concepts forautomated model merge do show another interestingaspect: the same approach has been used in AMEDATOfor managing parallel editing work of multiple engineersregarding the same model. Besides, each execution ofmodel transformations stores traces information. Tracesplay an important role for aspects like changemanagement, consistency checking of models andsystem code as well as impact analysis.
After the first phase of AMEDATO, the followingmodel-to-model transformations exist:
• the skeletons for conceptual screen flow designs1 arecreated from use case definitions,
• automated transformers produce detailed screen andscreen flow definitions from conceptual screen andscreen flow designs,
• the detailed implementation design is produced fromdetailed screen flow definitions and database defini-tions imported during transformations execution2 ,
• the configuration of controls and views is producedas a kind of Model-View-Control (MVC) diagramsfrom detailed screen flow designs.
Besides the mentioned model-to-modeltransformations, a very large part of the source code for
the target system is produced by code generators. Thecode generation rules are defined based on themetamodel part that described the detailedimplementation design. Thus, the code generation rulesproduce a one-to-one representation of the detailedimplementation design in the source code. The problemwith re-invoking code generators onto previouslyproduced code fragments appears similar to re-invokingmodel transformers. An intelligent code merge facilityhas been integrated with the code generators to avoid theunwanted effect of overwriting and thus discardingexisting code..
Fig. 5 Tool architecture of AMEDATO
3.4. Tool Architecture
The tool architecture of the AMEDATO solution (asof April 2006) is shown in Fig. 5. Out of the AMEDATOmetamodel, the AMEDATO repository has been createdautomatically using the medini technology. Thistechnology creates MOF compliant repositoriessupporting model versioning, configurationmanagement aspects as well as remote interfaces.Furthermore, a transaction mechanism takes care ofconcurrent access to AMEDATO models. A persistencylayer does support the storage of AMEDATO models indatabases. The modeling tools as well as other front-endtools have been connected to the repository facilitatingthe mentioned remote access. The customizedEnterprise Architect tool connects to the repository andis used for all graphical modeling tasks, the ER-Studiotool is used for database design; those designs areimported into the AMEDATO repository during themodel-to-model transformation from the detailed screen
1. "Conceptual screen flows" are a specific concept in theNTT Data development process that hide the details of theuser interface structure and behavior and provide a sketch-ing of the later user interface, the relation between targetuser interface pages and page mock-ups etc.2. Due to the fact that the developed information systemsdo follow an MVC approach, most of the detailed imple-mentation design can be derived from the database defini-tion and the detailed input/output definitions at the userinterface
screen flowdefinitions
robustnessdesigns
detailed classdesigns
file-basedVersioning
system
TOY Documentation
TOY Documentation
Enterprise Architect
Plug-In
eclipse IDE
use casesuse
cases
MOF based medini Repository
ER-StudioData Modeling
screen flowdefinitionsscreen flowdefinitions
robustnessdesigns
robustnessdesigns
detailed classdesigns
detailed classdesigns
file-basedVersioning
system
file-basedVersioning
system
TOY DocumentationDocumentation
System Planning and System Realization
Plug-InImport/Export
screen flowdefinitions
robustnessdesigns
detailed classdesigns
file-basedVersioning
system
TOY Documentation
TOY Documentation
Enterprise Architect
Plug-In
eclipse IDE
use casesuse
cases
MOF based medini Repository
ER-StudioData Modeling
screen flowdefinitionsscreen flowdefinitions
robustnessdesigns
robustnessdesigns
detailed classdesigns
detailed classdesigns
file-basedVersioning
system
file-basedVersioning
system
TOY DocumentationDocumentation
System Planning and System Realization
Plug-InImport/Export
and screen flow design to the detailed implementationdesign. The eclipse environment has been extended witha specific plug-in to allow for code generation fromAMEDATO detailed class designs, the code generationitself is realized by facilitating the Java EmitterTemplates (JET) technology connecting to theAMEDATO repository as well. The wholedocumentation can be generated from the artifactsstored in the repository by again applying JET with theDocBook technology as target.
3.5. Additional Functionality
A number of additional functionalities have beenprovided to maximize the value of the tools for thedevelopment in NTT Data's projects. Some selectedfeatures of those functionalities include:
• The commonly known profile mechanism fromUML 2 has been integrated and propagates profiledefinitions and profile applications to the AMEDA-TO metamodel and therefore to the AMEDATO re-pository. This feature allows for the customization ofthe AMEDATO metamodel and the instant supportof the customized AMEDATO modeling concepts inthe connected modeling tools. For the specific use ofAMEDATO in a development project, a profile def-inition may provide additional properties for ele-ments of the AMEDATO metamodel or may defineadditional relations not covered by the generalAMEDATO metamodel. Based on these extensions,the profile mechanism automatically supports edit-ing/visualization capabilities for the extensions inthe front-end tools as well as enables the storage ofvalues of such extensions in the AMEDATO reposi-tory. Profile definitions can be facilitated for addi-tional model transformation rules, specific codegeneration rules or fine grained consistency check-ing rules.
• o A model validation engine based on the ObjectConstraint Language (OCL) 2 has been integratedwith the repository. The engine is facilitated for allmodel consistency checks. These consistencychecks do rely on consistency rules, which are de-fined as OCL constraints and can be invoked on thewhole or parts of the model. The engine interpretsOCL, therefore it is possible to add new consistencyrules on the fly. In terms of usability, the constraintdefinition is hidden from the engineers view, he onlysees the meaning of the consistency rule and may in-voke the rule checking based on such meaningful de-scription. Additionally, also impact analysis rulesare expressed as OCL constraints and can be execut-
ed by an user based on a meaningful description aswell.
• o A template based engine for the export of reposito-ry elements to Microsoft Excel spreadsheets and theimport of elements from spreadsheets is integrated inthe tool environment. A user can specify an Excelimport/export template using a simple languagebased on the AMEDATO metamodel. Such tem-plates can be applied to models stored in the reposi-tory, the results are used for documentation purposesand for communication with external parties. Itshould be noted, that the definition of a import/ex-port template is based on the AMEDATO metamod-el as well: the contents of a single cell, a row or acolumn in the spredsheet to be created or read is de-fined by a kind of select statements upon metamodelelements - resulting in the production of spread-sheets containing the values store in the repositoryfor the model the template is applied upon (exportdirection) or in creating/manipulating the specifiedelements in the repository for a spreadsheet the tem-plate is applied upon (import direction)1.
4. Measurable Effects
A common problem with the introduction of newdevelopment environment into a company is that at isnecessary to clearly identify the benefits and theexpected Return of Investment. Otherwise decisionmakers cannot be convinced of investing in newtechnologies. Therefore clear measured effects need tobe proven. Even if such effects can be shown clearly, theintroduction of model driven technologies into largeorganizations still comes with a lot of uncertainties andrisks; a high level of risk acceptance of suchorganizations is required. Moreover, the introduction ofsuch technologies cannot be done from one day to thenext - it is a long, possibly expensive process and carefulconsideration of the acceptance by engineers, possiblecost saving or development time reducing effects as wellas necessary investments into the long-term roll-outseems to be required.
NTT Data has decided to prove the benefits of theAMEDATO solution by performing a virtualdevelopment project tool supported using AMEDATO.For that case, a typical mid size project was selected,which targeted the development of a web-based systemfor a division of the Japan Government. The basicdesign for that project has already been completed and
1. There are not two, but just one such template for both ex-port and import direction, but the evaluation semantics foreach direction is different.
all the necessary material from this phase was available.NTT Data engineers performed the modeling anddevelopment with AMEDATO starting with the systemuse cases, continuing via Conceptual and DetailedScreen Flow Design, Control Design and Detailed Classdesign until the Java code was generated. Theycompleted the Java code by the necessary business logicmanually afterwards. The degree of automaticallygenerated code has been measured to be 76%. (Thisdegree depends on the requirements of the project butthe selected project was a typical one so a similar resultcan be expected when applying AMEDATO to otherprojects.) The engineers provided and preformed theunit test cases for the Java code. In addition, theygenerated all the documentation with the AMEDATOtools automatically.
For comparison, NTT Data asked for a offer from oneof its typical sub-contracted companies. Such acompany offer with the same items (Javaimplementation, documentation, unit tests) and with thesame starting point (basic design specification) showedmore than double of the effort compared to the projectteam that applied AMEDATO. Furthermore, the NTTData engineers finished the project in the half of thedevelopment time estimated by the sub-contractor.According to the measured results, it is possible for NTTData to achieve a Return of Investment (break even) byperforming approx. 7 typical size projects with theAMEDATO toolset in the style described before.
To estimate the real potential, we have to consider,that the above case only shows the benefit in case ofpure forward engineering. In the more realistic situationwhere the requirements may be adapted or other changerequests appear during a development project, thebenefit of AMEDATO will be much higher since theconsistency is automatically managed. Further benefitsare expected if the test and business modeling phases arealso integrated into AMEDATO as it is already underdevelopment. The necessary training effort for theengineers is acceptable for NTT Data, since the processitself hasn't changed too much and the notations anddevelopment tools applied in each phase have been re-used or considered when replacing them by new tools.
5. Recent AMEDATO Extensions
5.1. AMEDATO Support for Business Model-ing
Before a development project based on AMEDATO isstarted, a detailed communication and negotiation takesplace between NTT Data and their customers. This
process is supported by a detailed business modelingmethod called MOYA developed by NTT Data. Withthis modeling process, the current business situation andthe anticipated business situation after the introductionof some new system can be modeled and analyzed. Themethod is based on the Soft Systems Methodology byPeter Checkland [10] with some modifications/extensions (e.g. goal oriented analysis instead ofConceptual Model). Throughout the process, thedifferent stakeholders of the business and the opinions/goals of them are identified, and the as-is businesssituation and its transition to the anticipated businesssituation is analyzed. Furthermore, the connectionbetween the business modeling result and the systemspecification and development with AMEDATO issupported. AMEDATO has been extended to cover alsothe MOYA business modeling method. The basic goal ofthat extension is to provide a tool environment tooptimally support the application of the businessmodeling method. The single-source principle based onthe AMEDATO repository is applied such that thedifferent artifacts resulting from a business modelingprocess application are managed in a repository, similarto the AMEDATO tools for the system development.Rich traceability, the consistency checking withconstraints and the support for managing modelconfigurations plays an important role in the extension.
Due to the intensive relations between MOYA and theother activities in the overall system developmentprocess it was decided not to invent a completely newarchitecture for AMEDATO-MOYA. Instead anintegration of the MOYA tools into the overallAMEDATO-X tool architecture has been planned.AMEDATO now provides an integrated toolenvironment for the MOYA process and thedevelopment process. MOYA technically consists ofseveral steps to capture the current business situation, toderive the anticipated business situation and to help insystem planning. For all of these steps, graphicalmodeling techniques are applied. The notation formodeling is based on UML 2. UML 2 structuredactivities are used for the business process modeling,UML 2 use cases are used for system planning supportand structure diagrams are used for goal modeling andbusiness resource modeling. Profiled versions of otherelements of the UML 2 language are used to expressspecific concepts of MOYA, e.g. the specific propertiesof MOYA model elements are captured as specialproperties of the UML 2 elements used to graphicallyrepresent MOYA concepts.
In more detail, the AMEDATO extension for MOYAconsists of the following components:
The AMEDATO repository extension for MOYA -The repository is used to store all elements of a MOYAapplication, e.g. all process model elements, resourceand goal models and so on including diagraminformation and trace relations to other elements in aMOYA model are managed by the repository.Everything that is modeled or somehow produced withfront-end tools is stored in the front-end toolindependent AMEDATO repository. The repository isautomatically generated out of the AMEDATOmetamodel extension for MOYA using the medinitechnology. The metamodel extension for MOYA isagain based on the UML 2 core packages and extendedby definitions specifically for MOYA. In the MOYAbusiness modeling process, the maintenance of suchrelations (e.g. between identified stakeholders, theiropinions and the goals for the business improvement) isof high importance. The management of such relationscan be executed inside the AMEDATO repository veryperformant.
The AMEDATO IDE extension for MOYA is used tomanage the tool application, the repository as well as theconnected front-end tools. In terms of the toolarchitecture, the IDE also contains a multiple versionrepository that is used by one single modeler.
The Enterprise Architect UML 2 tool customized forMOYA - the Sparx Systems Enterprise Architect tool isa generic, standard UML 2 tool and therefore does notknow about the specific semantics of the concepts usedin MOYA. The tool has to been completely customizedfor its application to support the MOYA process. Thiscustomization has been done by the provision of anUML profile and a Plug-In for the tool to provideMOYA specific modeling and editing support. ThePlug-In synchronizes the visualization of MOYAmodels in Enterprise Architect with the storage of thoseelements in the AMEDATO repository. The Plug-Inaccesses the Enterprise Architect specific modelrepresentation and uses the remote API of the repositoryto load and store model elements. It should be noted herethat an active synchronization style is realized meaningthat if a model element is added/changed/deleted insidethe Enterprise Architect model, it is at the same timeadded/changed/deleted in the repository too.Furthermore, the correctness of the static semantics ofMOYA models stored in the repository can be checkedinstantly, especially during editing of the elements.
The Microsoft Excel Import/Export Facility - NTTData uses spreadsheets to exchange information withtheir customers. These spreadsheets contain artifactsproduced during MOYA applications to communicatewith people in the customer's organization. To support
that behavior in the AMEDATO extension for MOYA,an Excel Import/Export facility has been provided.
The MS Excel based Traceability Matrix - theAMEDATO extension for MOYA does also support thecreation of a traceability matrix in a tabular notation,using MS Excel. This matrix allows to read all traceswhich are defined between elements in MOYA (or moregeneral in AMEDATO models), to edit those traces andto import edited trace matrixes back to the repository.
A specialized version of the constraint checkingengine as part of the medini meta modeler repositorycore libraries has been integrated into the AMEDATOextension. With this engine it is possible to evaluatearbitrary constraints defined in OCL against theelements in the AMEDATO repository. This engine isused for the evaluation of consistency rules forAMEDATO - and especially MOYA - models. Theengine reports all model elements that violate theconsistency rules.
5.2. Integration of Web-Design
The 1st version of the AMEDATO solution was ableto generate the initial GUI of the application based onJava Server Pages and Struts out of the information in anAMEDATO model. This kind of code generation hasbeen replaced subsequently due to the fact that the "artwork" - the production of the HTML code - and thefunctional work - the definition of the screen structureand screen flows - are usually parallel tasks in adevelopment project. In particular, the usualdevelopment process foresees that a professional userinterface designer works in parallel on a nicely layoutand styled user interface (art work). Back then,engineers manually merge the JSPs resulting from thedetailed screen flow definition and the manually createdhtml pages by the GUI designer. This process turned outto be difficult if the complete auto generated JSPs as aresult of the application of the AMEDATO environmentare assumed. As part of the AMEDATO environment,tool support has been realized to support for thesynchronization between the art work and the detailedscreen and screen flow designs as well as the merge ofthe art work and the generated JSP.
6. Conclusion
The whole AMEDATO solution is based on preciselydefined MOF metamodels. Besides its technologicalrole, the metamodeling approach turned out to be abeneficial discussion basis for further process
extensions and enhancements although it was originallyjust foreseen for an internal automation purpose. Theoften mentioned argument that metamodels are foracademic purposes only turned out not to be true, aftersome learning process, it was easy and very productiveto discuss issues in the AMEDATO team mainly basedon the metamodel definitions.
Another point is that it is simply impossible toradically change development approaches and processesin large companies. Also, the processes shouldn't beradically changed because they are a kind of "know-how" the company has. A company usually doesn'twant to waste their competitive advantage although thenew techniques offer some of potential of newadvantage. If one wants to introduce new softwareengineering techniques into existing developmentprocesses and teams, it is extremely important to keepthe current advantages which the existing process hasand to introduce the new techniques at carefullyidentified points of the process. For that identification,we used an approach of collecting painful situationdescriptions - developers and modelers know in whichsituation they feel an extraordinary difficulty or spent alot of time and efforts to achieve a certain result. Theanalysis of these painful situations was one of thereasons for the acceptance of the new tools andapproaches. The mentioned keeping of the developmentprocess also holds for re-using already existing toolslandscape.
Even if such a careful integration of model driventechnologies into an existing process is chosen, a largecompany doing so still bears a lot of risks. Whileworking on the AMEDATO solution, non-functionalissues such as usability, understandability andmaintainability did play an extraordinary important role.The technologies as such are not convincing, but theirintegration into a smooth, usable, cool environment likeAMEDATO turned out to be one success factor.
Model-to-model transformations do play animportant role in the AMEDATO solution. Many smalltransformations turned out to be more applicable thanone big fat magic model to code transformation. Inconjunction with model transformations, aspects asmodel merge, versioning and navigability (based onmanaged traces) are a key factor. As an extension to themedini technology, IKV realized a QVT engine thatimplements the Relations part of the standard. In the
next step in AMEDATO, this technology will beintegrated into the solution to improve the flexibility ofthe transformation rule definition.
The whole business modeling, requirementscapturing and development process of NTT Dataconsists of 15 different steps. Accordingly, 15 distinctkinds of models can be identified. This makes the verysimple categorization of models into CIM, PIM andPSM as promoted by the MDA difficult to be translatedinto the real world. We suggest to not specificallydiscuss in such model categories, but to simply talkabout various models at different or same levels ofabstraction that have some relation with each other.
7. References
[1] Kath, Soden, Born et.al: An Open Modelling Infrastructureintegrating EDOC and CCM, EDOC 2003, Brisbane, Austra-lia, September 2003
[2] Object Management Group: MOF Core Specification,v2.0, formal/2006-01-01, January 2006
[4] Object Management Group, The Common Object RequestBroker: Architecture and specification, Revision 3.0.3, OMGdocument formal/2004-03-12 March 2004.
