COMET. Component and Model-based development Methodology. Adapted from COMET I and COMBINE. COMET Toolset Handbook

Transcription

1 COMET Component and Model-based development Methodology Adapted from COMET I and COMBINE COMET Toolset Handbook Objecteering/UML and UMT tool documentation Date: 05. April 2004 Authors: Arne-Jørgen Berre, Brian Elvesæter, Jan Øyvind Aagedal, Jon Oldevik, Arnor Solberg, Philippe Desfray (Softeam), Gilbert Raymond (Softeam) Affiliation: SINTEF ICT Version: 2.4

2 TABLE OF CONTENTS 1 INTRODUCTION UML TOOL OVERVIEW Rational Rose Objecteering ArgoUML Poseidon Together Control Center XMI EXPORT FROM RATIONAL ROSE XMI EXPORT FROM OBJECTEERING OBJECTEERING WORK CONTEXT ARCHITECTURE WORK CONTEXT STRUCTURE WORK CONTEXT TEMPLATE LANGUAGE STRUCTURE WORK CONTEXT COMPONENTS Work context editor Work context manager WORK CONTEXT NOTION Overview COMBINE work context WORK CONTEXT MANAGER OVERVIEW INSTALLATION Needed files Installation steps Parameters summary WORK CONTEXT MANAGEMENT Select a Work context Documentation COMMANDS SUMMARY USAGE Introduction Validate a model Views generation Document generation XML generation GENERIC UTILITY: DEPENDENCY MANAGEMENT Features overview Features usage GENERIC UTILITY: CREATION BOX Overview Usage WORK CONTEXT EDITOR INSTALLATION Release Files Installation process FIRST STEPS (PREDEFINED VIEW EXAMPLE) FIRST STEPS (VALIDATION RULES EXAMPLE) UML PROFILE BUILDER COMMANDS Template edition window: left-hand part...62 Page 2 of 123

3 4.4.2 Template edition window: right-hand part UML MODELER COMMANDS DOCUMENT GENERATION Principle UML Profile Builder Specific commands (template editor window) XML GENERATION USING DOCUMENT METAMODEL WORK CONTEXT MANAGEMENT ADDING SCAN METHOD BUSINESS WORK CONTEXT INSTALLATION Module Installation Business work context installation Work Context Configuration OVERVIEW USAGE Creation of a Business model skeleton structure Edition of the Goal model Creation of the root Community Creation of a sub-community Edition of a Business process COMMANDS UML MAPPING VALIDATION RULES PREDEFINED VIEWS REQUIREMENTS WORK CONTEXT INSTALLATION Module Installation Requirements work context installation Work Context Configuration Requirements work context selection OVERVIEW USAGE Creation of a User Requirements model Use Case edition Requirement edition Document generation COMMANDS UML MAPPING VALIDATION RULES PREDEFINED VIEWS DOCUMENTATION GENERATION ARCHITECTURE WORK CONTEXT INSTALLATION Module Installation Architecture work context installation Work Context Configuration Architecture work context selection OVERVIEW USAGE Creation of an Architecture model Edition of Component specifications...82 Page 3 of 123

4 7.3.3 Creation of components Validate the components Generate pre-defined views COMMANDS UML MAPPING VALIDATION RULES PREDEFINED VIEWS WORKFLOW WORK CONTEXT INSTALLATION Module Installation Workflow work context installation Work Context Configuration Workflow work context selection USAGE Creation of a Workflow model Edition of a Workflow Edition of the properties of a step Validate a Workflow Generate the XML Workflow COMMANDS UML MAPPING VALIDATION RULES PREDEFINED VIEWS WORKFLOW AND BUSINESS MODEL WARM MODEL WORKFLOW GENERATION WORKFLOW PRODUCTION LINE UML MODEL TRANSFORMATION TOOL (UMT) OVERVIEW HIGH-LEVEL ARCHITECTURE UMT TOOL-CHAIN XMI integration XMI Light TRANSFORMER DEVELOPMENT XSLT transformer Java transformer UMT USAGE Starting the UMT GUI Working with projects After opening a project Forward transformation The Result tab Reverse transformation Settings Checking a model's consistency to a profile COMMAND-LINE TRANSFORMATIONS ACTIVITY GRAPHS IN UMT UMT SUMMARY Page 4 of 123

5 TABLE OF FIGURES FIGURE 1: EXPORTING XMI FROM RATIONAL ROSE...10 FIGURE 2: OPTIONS FOR XMI EXPORT...11 FIGURE 3: MODULE SELECTION DIALOG...12 FIGURE 4: DIRECTORY SELECTION DIALOG...12 FIGURE 5: THE OBJECTEERING MODELLING ENVIRONMENT...13 FIGURE 6: GENERATING XMI...14 FIGURE 7: INTERNAL STRUCTURE OF WORK CONTEXT...15 FIGURE 8: TEMPLATE PATTERN EXAMPLE...16 FIGURE 9: PREDEFINED VIEW TEMPLATE EXAMPLE...16 FIGURE 10: STARTING MODEL...17 FIGURE 11: GENERATED DIAGRAM WITH PREDEFINED VIEW TEMPLATE...17 FIGURE 12: WORK CONTEXT TEMPLATE EDITOR...18 FIGURE 13: WORK CONTEXT MANAGER INTERFACE...19 FIGURE 14: MODELLER TOOL ARCHITECTURE...19 FIGURE 15: MODULE USED AS WORK CONTEXT CONTAINER...20 FIGURE 16: THE COMBINE MODEL ARCHITECTURE...21 FIGURE 17: CONFIGURING DOCUMENT GENERATION...23 FIGURE 18: CONFIGURING EXTERNAL EDITION...23 FIGURE 19: SET WORK CONTEXT...25 FIGURE 20: CHOOSE WORK CONTEXT...25 FIGURE 21: SAMPLE UML MODEL...27 FIGURE 22: VALIDATION REPORT...28 FIGURE 23: SOURCE UML MODEL...29 FIGURE 24: MY VIEW...29 FIGURE 25: MY DETAILED VIEW...29 FIGURE 26: DEFINE DEFAULT DIAGRAM...30 FIGURE 27: DEFAULT DIAGRAM FOR A MODEL ELEMENT...30 FIGURE 28: ADD DEFAULT DIAGRAM...31 FIGURE 29: DOCUMENT TEMPLATE DEFINITION...32 FIGURE 30: DOCUMENTATION GENERATION...32 FIGURE 31: CHOOSE A DOCUMENT TYPE...33 FIGURE 32: RTF DOCUMENT...33 FIGURE 33: XML META-MODEL...34 FIGURE 34: GENERATING XML...35 FIGURE 35: CHOOSE XML DOCUMENT TYPE...35 FIGURE 36: XML DOCUMENT...36 FIGURE 37: BOOK TENDER...37 FIGURE 38: BOOKINGSERVICE TRACES...38 FIGURE 39: BOOKINGSERVICE...38 FIGURE 40: BOOKINGSERVICE REVERSE ROOT...39 FIGURE 41: UML WORKSPACE...40 FIGURE 42: PORT1 IMPLEMENTATION CD...41 FIGURE 43: DEFAULT DIAGRAM...41 FIGURE 44: ADD DEPENDENCY...42 FIGURE 45: VIEW DEPENDENCY TREE...42 FIGURE 46: SAMPLE UML PROFILE...43 FIGURE 47: AVAILABLE COMMANDS...44 FIGURE 48: DEMOPACKAGE UML WORK SPACE...45 FIGURE 49: DEMOPACKAGE AVAILABLE COMMANDS...45 FIGURE 50: DEMOPACKAGE SINGLETON...46 FIGURE 51: WORK CONTEXT EDITOR DOCUMENT GENERATION...48 Page 5 of 123

6 FIGURE 52: WORK CONTEXT EDITOR EXTERNAL EDITION...48 FIGURE 53: WORK CONTEXT ADD WORK CONTEXT COMMANDS...49 FIGURE 54: WORK CONTEXT EDITOR ADD WORK CONTEXT EDITOR COMMANDS...49 FIGURE 55: WORK CONTEXT EDITOR IMPORT META...49 FIGURE 56: MYMODULE MYCONTEXT...50 FIGURE 57: MYCONTEXT WORK CONTEXT DEFINITION...50 FIGURE 58: MYCONTEXT TEMPLATEVIEW...51 FIGURE 59: VIEW TEMPLATEBOX...51 FIGURE 60: VIEW SCANMETHODBOX...52 FIGURE 61: VIEW CLASS...52 FIGURE 62: VIEW OPERATION...52 FIGURE 63: OPERATION FILTERBOX...53 FIGURE 64: OPERATION MAIN FILTER FIELD...53 FIGURE 65: ATTRIBUTE MAIN FILTER FIELD...53 FIGURE 66: MYCONTEXT TEMPLATEVIEW...54 FIGURE 67: MYCONTEXT SELECTWORKCONTEXTBOX...54 FIGURE 68: TESTPROJECT CLASSES...55 FIGURE 69: TESTPROJECT MY VIEW...55 FIGURE 70: TESTPROJECT UPDATE VIEW SETTINGS...55 FIGURE 71: TESTPROJECT UPDATE VIEW (BEFORE)...56 FIGURE 72: TESTPROJECT UPDATE VIEW (AFTER)...56 FIGURE 73: VALIDATION TEMPLATE BOX...57 FIGURE 74: VALIDATION ALL CLASSES...57 FIGURE 75: VALIDATION CONDITION BOX FOR PACKAGE...58 FIGURE 76: VALIDATION CLASSES OF THE PACKAGE...58 FIGURE 77: VALIDATION CONDITION BOX FOR CLASS...58 FIGURE 78: VALIDATION PARENT CLASSES NODE...59 FIGURE 79: VALIDATION PARENT CLASSES TREE...59 FIGURE 80: VALIDATION PARENT CLASSES CONDITION BOX...59 FIGURE 81: VALIDATION PARENT CLASSES...60 FIGURE 82: VALIDATION SET WORK CONTEXT...60 FIGURE 83: VALIDATION TEST MODEL...61 FIGURE 84: VALIDATION AUTOMATIC VALIDATIONS...61 FIGURE 85: VALIDATION VALIDATION REPORT...62 FIGURE 86: DOCUMENT TEMPLATE DEFINITION...63 FIGURE 87: TESTPROJECT DOCUMENT METAMODEL...64 FIGURE 88: EXAMPLE OF XML TEMPLATE METAMODEL...65 FIGURE 89: STANDARD DOCUMENT GENERATOR METAODEL...66 FIGURE 90: XML METAMODEL EXAMPLE (WSFL GENERATOR)...67 FIGURE 91: BUSINESS MODEL STRUCTURE...70 FIGURE 92: GOAL STRUCTURE...70 FIGURE 93: GOAL MODEL...71 FIGURE 94: COMMUNITY STRUCTURE...71 FIGURE 95: BUSINESS PROCESS COMMANDS...72 FIGURE 96: BUSINESS PROCESS GOALS...73 FIGURE 97: ARCHITECTURE MODEL CREATE COMMANDS...82 FIGURE 98: ARCHITECTURE MODEL STRUCTURE...83 FIGURE 99: TOOL SPECIFICATION...83 FIGURE 100: TOOL SPECIFICATION CLASS DIAGRAM...84 FIGURE 101: APPLICATION SPECIFICATION...84 FIGURE 102: APPLICATION SPECIFICATION CLASS DIAGRAM...85 FIGURE 103: SURVEY BOOKING AUTOMATIC VALIDATIONS...85 FIGURE 104: BOOKING EDITOR PRE-DEFINED VIEWS...86 FIGURE 105: BOOKINGEDITOR DIAGRAM FIGURE 106: BOOKINGEDITOR DIAGRAM Page 6 of 123

7 FIGURE 107: BOOKINGEDITOR DIAGRAM FIGURE 108: CREATION OF A WORKFLOW MODEL...92 FIGURE 109: WORKFLOW COMMANDS...93 FIGURE 110: CONTROL FLOW EXAMPLE...93 FIGURE 111: DATA FLOW EXAMPLE...94 FIGURE 112: SYSTEM ATOMIC STEP...95 FIGURE 113: WORKFLOW MODULE SET DOMAIN OBJECT...95 FIGURE 114: WORKFLOW FILE GENERATION ARCHITECTURE FIGURE 115: TWO WORKFLOW ENGINES USING SAME WARM MODEL SOURCE FIGURE 116: UMT HIGH-LEVEL USE CASES FIGURE 117: UMT HIGH-LEVEL ARCHITECTURE (PLATFORM-INDEPENDENT) FIGURE 118 UMT HIGH-LEVEL ARCHITECTURE (PLATFORM-SPECIFIC) FIGURE 119: UMT TOOL CHAIN FIGURE 120: XMI LIGHT META MODEL FIGURE 121: UML TICKET EXAMPLE FIGURE 122: NEWLY STARTED UMT FIGURE 123: CREATING A NEW PROJECT FIGURE 124: CREATE NEW PROJECT DIALOG FIGURE 125: PROJECT SELECTOR DIALOG FIGURE 126: PROJECT PROPERTIES FIGURE 127: UMT WITH LOADED MODEL (INFORMATION VIEW) FIGURE 128: UMT W. LOADED MODEL (XMI LIGHT VIEW) FIGURE 129: TRANSFORMATION MENU FIGURE 130: TRANSFORMATION MENU (2) FIGURE 131: RESULT TAB FIGURE 132: RESULT TAB (SEVERAL FILES) FIGURE 133: REVERSE TRANSFORMATION FIGURE 134: TRANSFORMATION EDITOR FIGURE 135: ADDING A NEW TRANSFORMATION FIGURE 136: ADD TRANSFORMATION DIALOG FIGURE 137: PROFILE EDITOR FIGURE 138: ADDING A PROFILE CONCEPT FIGURE 139: CHANGING A CONCEPT FIGURE 140: UMT ACTIVITY VIEW Page 7 of 123

8 PREFACE This document describes the toolset for the COMET methodology: Chapter 1 gives an overview of selected UML modelling tools. Chapter 2 describes the architecture of the modules (work contexts) for the Objecteering UML tool. Chapters 3 9 describe the prototype modules (work contexts) for the Objecteering UML tool that have been developed by SOFTEAM and SINTEF in the context of the COMBINE project. Chapter 10 describes the prototype UMT tool that has been developed by SINTEF in the context of the COMBINE project. Page 8 of 123

9 1 Introduction The goal of this chapter is to give a brief overview of some of the available UML tools that can be used in COMET. We do not want to restrict the choice of UML tool to a specific product, but we have one requirement for the tool: In order for the COMET model-driven tool-chain to work: The UML tool must support export of XMI (XMI version 1.1 for UML version 1.3). This XMI export is the bridge that integrates the UML-tool and UMT. Currently, UMT has been tested with Objecteering and Rational Rose. Other tools supporting the correct XMI version are expected to work, but have not been tested. Together Control Center, ArgoUML, and Poseidon are examples of other UML tools supporting XMI. The XMI integration implemented in UMT is currently based on structural UML models in XMI (class models). Behavioural models are not considered. 1.1 UML tool overview Rational Rose Rational Rose is one of the market leaders on the UML case tool market, delivered by Rational Inc. Rational Rose is a high-priced tool, with an easy-to-use interface and support for most UML capabilities. (See chapter 1.2 for description of XMI export.) The Rational Rose tool can be obtained from Objecteering Objecteering is a lower profiled tool, developed by a French company called Softteam. Objecteering is in the lower-end market and provides enterprise versions as well as a freely available, fully functional Personal Edition. One of the strengths of Objecteering (Enterprise ed.) is its profiling capabilities, which allows for easy creation of UML extensions in terms of profiles. (See chapter 1.3 for description of XMI export.) The Objecteering tool can be obtained from ArgoUML ArgoUML is a open source UML tool, with good support for most of the UML notations. ArgoUML stores models in terms of XMI packaged inside a zipped file. In order to use the XMI-file, it must be un-zipped from the model file. The ArgoUML tool can be obtained from Poseidon Poseidon is a commercialisation of ArgoUML and provides equivalent functionality for free in a community edition. Poseidon is available for Together Control Center Together Control Center is a high-end and high-priced UML tool, which is particularly known as a good design tool, since it integrates UML class diagrams with implementation code (e.g. Java) within the tool. It supports XMI export and import. Page 9 of 123

10 Check out for more information. 1.2 XMI export from Rational Rose Rational Rose supports XMI export through a plug-in developed by Unisys, which is freely available. (It can be downloaded from at this location: The XMI-plugin appears in terms of menu items within the Rational Rose tool. To use the XMI export functionality, look for the Export model to UML item in the Tools menu (Figure 1). Figure 1: Exporting XMI from Rational Rose When choosing the XMI export, a dialog box will appear (Figure 2) that lets the user select some options. Select the option XMI 1.0 for XMI format and single file for granularity. When the OK -button is pressed, the export is done, and the user can choose a name for the exported file. Page 10 of 123

11 1.3 XMI export from Objecteering Figure 2: Options for XMI export XMI export from Objecteering is supported through a plug-in (called module in Objecteering), which can be downloaded from the Objecteering web site. The plug-in can be downloaded from ftp://ftp.objecteering.com/xmimodule_v1.1.e.exe. This is a self-extracting zip file that contains an Objecteering.prof file. This is installed either by double-clicking on the file itself (after installing Objecteering) or by using the Objecteering Administration tool. To use the XMI module in a particular project, the module must be activated in that project. Start the selection dialog from the Tools/Modules menu. A dialog similar to the one in Figure 3 will appear. Find the XMIModule item in the Available modules window and press the Add >> button. The XMIModule will move to the Modules used window. Press ok to activate the selection. If you want to keep this selection for all future projects, you can select the Keep selection as default option at the bottom of the dialog. Page 11 of 123

12 Figure 3: Module selection dialog To export XMI, an XMI export link must be created on a package. Select the desired package in the model explorer. Then select the Items tab in the properties window. In the items tab of the properties window, there is a function button called XMI that can be pushed. This will create an XMI export document. A small dialog appears that allows you to select export directory, as shown in Figure 4. Figure 4: Directory selection dialog Figure 5 shows the Objecteering environment, with a model explorer, a diagram window, and the property editor with the item tab selected and a newly created XMI export. Page 12 of 123

13 Figure 5: The Objecteering modelling environment To generate the XMI, select the XMI-export item and press secondary mouse-button. From the appearing menu, select menu-item XMI/Generate, as shown in Figure 6. Page 13 of 123

14 Figure 6: Generating XMI For further information about XMI generation in Objecteering, install it and consult its documentation. Page 14 of 123

15 2 Objecteering Work Context Architecture 2.1 Work context Structure A work context is composed of a set of Templates, organized by Template types. Work context Validation Templates View Templates Gen doc Templates Figure 7: Internal structure of work context Validation templates: establish validation rules to check the model (constraints, metrics) View templates: use to create and update predefined view (typed UML diagram), with contents precisely defined. Document generation templates: generate external document ( HTML or Word format) XML generation: generates XML files Notice that the number of types of templates is not definitive. The language used to describe the template allows adding new type of template with minimal effort. 2.2 Work context Template language structure. The main structure work context, the work context template, is based on a navigation tree structure through UML models. A pattern template represents each work context rules and is used by a dedicated engine. This template is composed of three key elements: Node: linked to an UML metaclass Navigation operation: operations that define the path from one node to another node. Filter: Filter can be attached to node to select elements in operation result. Page 15 of 123

16 Navigation operation getclasses isstereotyped(«interface» ) Package getoperations Filter Template root Class ispublic Operation Figure 8: Template pattern example In the example (Figure 8), the root node is a package, the second node represents classes owned by the package with the <<interface>> stereotype, and the third node represents all public operations for each class. Note: the language used to express navigation operations can be OCL or equivalent. Applied to one UML element, a navigation operation returns a set of UML elements. Filters are Boolean expressions. Examples: Applied on one package, the getclasses operation returns all classes of the package. Applied on one class, the getoperations operation returns all operations of the class. Based on this general structure, sub languages are dedicated to specific targets. For example, presentation rules contain predefined views that establish named UML diagram templates (blue prints). In this context, the Color property is added to nodes to define the color of the element. This kind of pattern template generates a UML diagram. getclasses Package getoperations Class ispublic Color=Red Operation ispublic getattributes Attribute Figure 9: Predefined view template example For example, the predefined view template described in Figure 9, applied to the package 2 in the model represented Figure 10 generates the diagram Figure 11. Page 16 of 123

17 ::PackageB::ClassB1 Attribute : undefined Attribute1 : undefined ClassA1 PrivateAttribute : boolean PubicAttribute : integer 0..1 * ClassA2 PrivateOperation() PublicOperation() 0..1 * ::PackageB::ClassB2 Operation() Operation1() Figure 10: Starting model ClassB1 ClassA1 PubicAttribute : integer 0..1 * ClassA2 PublicOperation() 0..1 * ClassB2 Figure 11: Generated diagram with predefined view template The predefined view Figure 9 says that the generated diagram contains (and only contains) all classes of the package with public operations and attributes, and linked classes to the classes of the current package. Operations and attributes of linked classes are not shown in the view. In the same way, other sub-languages can be defined: Document generation UML model generation Page 17 of 123

18 Code source generation Validation controls 2.3 Work context components Work context editor The work context editor provides capabilities to create, manage, and deliver work contexts. According to the work context structure, template edition is the main function provided. A graphical editor is entirely dedicated to allow the user to create and modify templates without any knowledge of the internal structure Work context manager Figure 12: Work context template editor Templates created using work context editor are executed on the UML model. Work context manager contains a template engine activated by the user through a set of specific generic commands. Depending on the chosen work context, the engine performs actions defined in templates. These actions could be for example document generation, diagram creation or update, model check. Page 18 of 123

19 Generate doc Create diagram Check model Work context manager user interface Generate Xml Figure 13: Work context manager interface In addition, the work context manager contains a set of additional generic capabilities to assist the user during model elaboration process. The dependency manager allows managing of all kind of dependency between model elements independently of their type. Typically it is used to establish and display traceability links. The stereotype manager provides direct stereotyped element creation. The structure creation tool provides automatic basic model structure creation 2.4 Work context notion Overview A work context can be viewed as UML Profile extensions, organized as follow: Presentation rules, which are used to define specialized UML diagrams or blue print. Validation rules, as a set of control on models. Model transformation or generation rules, which express internal or external production based on UML model. UML model HUTN Text Editor UML HUTN representation UML tool representation UML Profiles A Modeller Tool Editor Facilities Transformation Rules UML model UML HUTN representation UML tool representation UML XMI representation UML XMI representation Validation Rules Presentation Rules Model Rules Management Private Repository Workspace Communication SW Component Document Figure 14: Modeller tool architecture One of our goals is to provide means to build such a modeler tool for each work context. Page 19 of 123

20 A specific language, Work Context Language (WCL) applied on UML model defines each work context and allows flexible and powerful tool customizations and automations. The main structure of the WCL language, the wcl pattern template, is based on a navigation tree structure through UML models. A pattern template represents each work context rules and is used by a dedicated engine. The D14 document contains more detailed description of this language. A work context is saved as an Objecteering module that contains UML profiles and work context templates created by the user, plus all information associated (in particular required external files). When a developer needs to use it, he or she deploys and selects the module in the UML modeller. As a result, all the templates of the work context are available, and can be activated directly on UML elements of the model. Profiling tool Work context editor Profile editor UML Modeler tool Work context manager UML editor Objecteering Module Profile ProfileProfile Work Work context context Templates Template Template Template Extern utilities Extern files Extern files Extern files Figure 15: Module used as work context container The developer can change a work context depending on its type of activity. The module, as a unique container (both for profile, template and other items), facilitates global configuration management. But, for local conveniences, it is possible to manipulate a template as a single artefact COMBINE work context COMBINE centre defines 4 main work contexts: Business Requirement Architecture Workflow Page 20 of 123

21 Input from OMG UML profiles OMG MDA, UML for EDOC, UML2.0 and ISO RM-ODP viewpoints COMBINE Model world Real world MDA PIM (Business) Platform Independent Models Enterprise viewpoint (CCA, Business Processes, Entities, Relationships, Events) + ext. Activity-diagrams and use-cases MDA PIM (Architecture) Platform Independent Models Computational viewpoint (CCA, Entities, Events) + UML2 Architecture Modeling Information viewpoint (Entities, Events, Relationships) MDA PSM Architecture) Platform Specific Models Engineering viewpoint (Technology abstraction: FCM, Events, Workflow, DCP,) Technology viewpoint (UML for J2EE/EJB- JSR-26, Web Services, ) Business model Context statement Vision for change Risk analysis Architecture model HLA Model Platform specific model Goal Model Requirements model Use case Prototype Other requirements Role structure Model model System Boundary Model Use case Scenario Model Component Interface Model Business Process Model Business Information Model Component Structure Model Component Interaction Model Component implementation model COMBINE Models Concepts& Artifacts Processes Actors Legacy User interface User Service Service Entity Service Business Service Entity Resource Res. Service Service Component Infrastructure COMBINE Component Architecture Business System Figure 16: The COMBINE model architecture In addition, it is necessary to supply support for transverse rules. Typically, consistency rules from one context to another or automatic generations. This can be done in to way: by integration of global rules directly in each work context, or by supplying a dedicated global work context. Page 21 of 123

22 3 Work Context Manager 3.1 Overview The work context manager is a framework that provides generic additional functions in the Objecteering UML Modeller. The validation, presentation and transformation rules declared by a selected work context can only be executed from the work context manager command. The work context manager provides also two tools: One is dedicated to the edition of links between model elements (for example, traceability links) The other is used to create pre-initialised stereotyped model elements The usage of the work context manager is explained by illustrating a basic sample work context. 3.2 Installation Needed files File WorkContextModule.prof xt.exe (**) rtf.xsl, html.xsl (*) style.dot (*) Description Objecteering/UML work context module used in UML Modeller XSLT processor. Needs Windows Java execution engine XSL style sheet for RTF and HTML document generation Winword model (*) File that is part of the WorkContextModule directory (**) You can choose you own XSLT processor. You have just to adapt the XSLT command parameter (see chapter 3.2.3) Installation steps Deliver the WorkContextModule (by double-clicking on the.prof file) Create your document generation directory (for example C:\ProjectDocuments ) Copy xt.exe, rtf.xsl, html.xsl and style.dot into this directory..xsl files and style.dot files can be found in the WorkContext module directory {OBJ_PATH}\modules\WorkContextModule\version\res, where OBJ_PATH is the home directory of Objecteering Open your UML modelling project Install the WorkContextModule in your project via the Tools Modules command Set the WorkContextModule s parameters via the Tools Modify configuration command: Page 22 of 123

23 Figure 17: Configuring document generation We recommend that you define the same directory for the three document generation parameters. Figure 18: Configuring external edition In the Windows environment, leave the external edition parameters undefined. The operating system will open the proper editor according to the file extension. Choose 'Open editor after generation' to visualize document just after the generation. Page 23 of 123

24 3.2.3 Parameters summary Parameter(group name) Document generation XSLT command (*) Document generation Gendoc directory Document generation Word Models Document generation Format External edition XML editor External edition RTF editor External edition Open editor after generation Interface JboxExternalEditor (unused) Interface UseExternalEditor (unused) Description XSLT processor command. Path where the XML and documentation will be generated Path where are stored the word models used for documentation generation Choose HTML or RTF default generation format. Path to the XML editor that will be used to display generated XML documents Path to the RTF editor that will be used to display generated documentation When activated, the generated XML or RTF documents are automatically displayed using the editors specified by the previous parameters This parameter is unused. It is inherited from a referenced profile utilized in the WorkContext tool. So leave void this parameter As for the JBoxExternalEditor parameter, it is unused, do not check it (*) The command must be defined with the full path executable, and some parameters: %x ( xml source file ), %s (xls stylesheet) and %r (resulting file). These parameters will be replaced by actual filename in order to specify command line depending on xslt processor used. The parameter %s will be substituted by html.xsl or rtf.xsl depending on target format. Examples: c:\util\xt.exe %x %s %r (XT processor) c:\util\saxon o %r %s %s (SAXON processor) XT processor can be found at: (Win32 executable. Necessitate Microsoft java VM ). Saxon processor can be found at: Unicorn processor: These processors are based on W3C XSLT specification: Work context management Select a Work context The selection of a Work context allows you to use a particular Work context in a UML project. Follow the steps: Open the Select Work context GUI (right-click on a Package in the explorer window then select the menu item Work Context Set work context ) Page 24 of 123

25 Figure 19: Set work context Select the Work context you want to work with in the Work contexts list and click on the Apply button: Figure 20: Choose work context Confirm and return to the explorer window (using the OK button). The Work context is set Page 25 of 123

26 3.3.2 Documentation You can read the documentation of a Work context by following the steps: Open the Select Work context GUI (right-click on a Package in the explorer window then select the menu item Work Context Set work context ) Select the Work context of which you want to read the documentation (if it exists) Click on the Description button, a specific editor is launched, displaying the Work context s documentation 3.4 Commands summary Command UML Description Element Add dependency ModelElement Add a dependency between the model element selected in the dependency GUI and the model element selected in the explorer window Add Work context Package Add pop up menu commands commands Automatic NameSpace Check the model according to validation rules Validations (*) Automatic views (*) NameSpace Create or update the predefined view (diagram) Creation box Diagram Open the creation box for the diagram selected Deep Automatic NameSpace Check for sub-elements recursively Validations Deep Automatic NameSpace Generate views for sub-elements recursively Views Define default diagram Diagram Define the current diagram as the default diagram for chosen UML elements. Display ModelElement Open the dependency GUI starting from the model element selected dependencies Document NameSpace Generate the work context document (RTF or HTML in this version) generation Link to predefined view Diagram Link a manually created diagram to a predefined view. You can execute Update view on the diagram. Open default view (*) NameSpace Open the default diagram. Open the last predefined view created, or user defined default diagram. Set work context Package Set the current work context Update view (*) Diagram Update the diagram if it is a predefined view. XML document generation NameSpace Generate work context XML documents (*) Access directly via the pop-up menu on the element 3.5 Usage Introduction The MyDesignWorkContext example This chapter aims to explain the typical usage of Work contexts services through the use of a very simple and demonstrational-purpose Work context named MyDesignWorkContext. This Work context provides basic services that illustrate how the design phase can be toolsupported using the Work context approach. Page 26 of 123

27 Installation procedure of MyDesignWorkContext The MyDesignWorkContext is physically represented by the MyDesignModule. In order to make the examples below work, you have to deploy (double-click on the.prof file) the MyDesignModule into your Objecteering site, then install it (via the command Tools Modules ) in your UML project. Finally, you have to select the MyDesignWorkContext (see chapter 3.3.1) Validate a model MyDesignWorkContext s validation rules The validation rules defined in the MyDesignWorkContext are: UML element Rule type Description Package Cardinality A package owns at most 5 classes Class Level The maximum level of class inheritance is 3 Class Naming convention 5 class name 20 characters A sample model We will apply these rules to this sample UML model: DemoPkg Class1 aa Class2 A very big class name which is too huge Class3 Class4 Class5 Figure 21: Sample UML model The purpose of this model is to raise all possible errors when applying the preceding validation rules Applying the validation rules to the model We will now validate the preceding UML model by applying the validation rules defined in MyDesignWorkContext: Right-click on the DemoPkg Page 27 of 123

28 Select the menu item Automatic Validations A GUI displays the results of the execution: Errors found Text description of the selected error Template where is defined the rule corresponding to the selected error Template item owning the rule Figure 22: Validation report When an item is selected in the list of errors, the associated fields are updated and the model element being incriminated is selected in the explorer window Views generation MyDesignWorkContext s pre-defined views The sample pre-defined view my view displays the classes of a package in coral color. For each class, its public operations as well as its public attributes are displayed. The classes are included in the owner package which is displayed in gold. The other pre-defined view my detailed view displays also the classes of a package in coral color. But for each class, all its operations as well as all its public attributes are displayed in details Generating diagrams Considering the source UML model: Page 28 of 123

29 Figure 23: Source UML model Select the Automatic views item in the package pop-up menu. Two new diagrams are created, in conformance with the earlier specification of my view and my detailed view : Figure 24: My view Figure 25: My detailed view Page 29 of 123

30 Working with default diagrams A model element can have multiple views that can, for example, offer different levels of details (as our example). During design, a developer can decide to work only with the my view pre-defined view. During implementation, he might want to work with the my detailed view pre-defined view. This can be achieved through default diagrams. A model element can own a default view that is used to represent it by default Setting a default diagram for a model element Setting the my view diagram as the default view is performed by right click on the diagram and select the menu item Work Context definedefaultdiagram. In our example, we can set the my view diagram as the default diagram for the owner package DemoPackage : The following GUI appears: Figure 26: Define default diagram Figure 27: Default diagram for a model element Page 30 of 123

31 Widget Diagram elements List Default diagram for List Add Button Remove Button Description List of the model elements displayed in this diagram List of the model elements for which this diagram is the default diagram Add the selected element in the left-hand list to the right-hand list: it makes the diagram being the default diagram for the element selected in Diagram elements Remove the selected element from the right-hand list: the diagram is then no longer the default diagram for the removed element We want the my view diagram to be the default diagram of DemoPackage, so select this element in the list Diagram elements and click on the Add button: Confirm and quit the editor (OK button). Figure 28: Add default diagram Open the default diagram attached to a model element To open a model element s default diagram, just select the Open default view menu item in the model element pop-up menu. When no default diagram is set, the last pre-defined diagram created is opened Updating a view Suppose you have made some modifications to the my view pre-defined diagram, like the addition of a new class. You should format the diagram according to the specification of the template my view. This is achieved by selecting the Update view item on the diagram pop-up menu. Page 31 of 123

32 3.5.4 Document generation Principle Objecteering UML modeler XML XSL Processor (xt) Target Format (rtf, html..) XSL Style sheet Figure 29: Document template definition Using document template definition, Objecteering/UML generates an XML file. An XSL processor creates a target format file, based on the XSL style sheet. The current version provides two XSL style sheets (rtf.xsl and html.xsl), which produces RTF and HTML format documents MyDesignWorkContext s document template The example document template Overview documentation starts from a package, displays the default diagram attached, and resumes for each class the public operations and attributes defined. The description note attached to the model elements is used Generating the documentation From the source model: DemoPackage <<description>> Contains classes "Class1" and "Class2" <<description>> Class2 is a foo Class <<description>> Class1 is dummy Class Class1 +publicattributeclass1 : boolean -privateattributeclass1 : integer +PublicOperationClass1(In p1:real) #ProtectedOperationClass1() Class2 +apublicoperationclass2():boolean +anotherpublicoperationclass2(in p1:string) Figure 30: Documentation generation Right-click on the package and select the Work Context Documentation generation, the following GUI appears: Page 32 of 123

33 Figure 31: Choose a document type Select the item Package:Overview documentation from the Type doc list Set the User editor combo list to Yes (in order to display the generated document automatically) Confirm and quit (using the OK button) You obtain the following RTF document: Figure 32: RTF document Page 33 of 123

34 3.5.5 XML generation Introduction The process of XML generation is the translation of a UML model to an XML model according to a specific DTD on which the XML template relies. Before generating XML, you must validate the source UML model so that it does not contain any error. Indeed, most of the XML generators rely on the assumption that source UML models are coherent and correct. We will see how we use the Work Context tool in order to make it generates XML from UML models MyDesignWorkContext s XML template The sample target XML we chose here looks like a quite lightweight XMI. The DTD of this language is defined by the following XML meta-model: Model Namespace * * Name : string OwnedElement Visibility : VisibilityMode * Feature Part Name : string Visibility : VisibilityMode Class Package Operation Attribute Figure 33: XML meta-model This language allows expressing UML models into a very simple XML representation that is far from supporting the whole UML specification. The XML template LightweightXMI of the MyDesignWorkContext defines the correct browsing into a UML model in order to produce XML that satisfy the previous DTD Generating XML Considering the following source UML model, we will apply the LightweightXMI template starting from DemoPackage : Page 34 of 123

35 Figure 34: Generating XML Select the item Work Context XML document generation from the DemoPackage pop-up menu A GUI proposing the XML templates that can be applied to the element selected is displayed: Figure 35: Choose XML document type Select the item Package:Lightweight XMI from the Type doc list Set the User editor combo list to Yes (in order to display the generated XML automatically) Confirm and quit (using the OK button) You obtain the following XML document: Page 35 of 123

36 Figure 36: XML document 3.6 Generic utility: Dependency management Features overview The main purpose of the dependency GUI is to edit the links set by users between model elements. These links are stereotyped dependencies. A frequent usage is the management of traceability links between software artefacts. The GUI offers the following features: Add/remove a stereotyped dependency between two model elements Display a hierarchy tree of elements linked by a specific stereotyped dependency Select a dependency stereotype and then see the elements linked from the hierarchy tree s root element View the default diagram or pre-defined or user-defined diagram of an element in the displayed hierarchy tree Display the hierarchy in a backward or forward way Features usage Displaying the dependencies from a model element Right-click on the model element from which you want to see the outgoing dependencies, and thus its linked elements Select the Display dependencies menu item The following GUI appears (supposing you have selected the Book tender use case): Page 36 of 123

37 Book tender is linked to the Book tender/lead use case with a dependency stereotyped by <<WCL_Trace>> Actions available on the selected item in the tree Indicates if the dependencies are displayed in the forward/backward way Selected stereotype used to filter dependencies in the above tree Selection button Go To Remove Zoom View Figure 37: Book tender Action description Selects in Objecteering s explorer window the element selected in the dependency GUI Remove the dependency link between two elements Make the selected item become the root of the tree Open the default diagram associated with the selected item In the window example, the tree means that there exists a dependency link between the Book tender activity and the Book tender/lead use case which is linked to the BookingService component. The dependencies between elements are all stereotyped by <<WCL_Trace>>. Reverse root is not checked, this means that dependencies are showed in a forward way, the displayed tree is equivalent to: Page 37 of 123

38 Book tender <<WCL_Trace>> Book tender/lead <<WCL_Trace>> <<UserService>> BookingService Figure 38: BookingService Traces If you have originally selected the BookingService component and decided to show its linked elements, you will get: Figure 39: BookingService Now check Reverse root in order to see dependencies in the backward way: Page 38 of 123

39 Figure 40: BookingService Reverse root Add dependencies between elements Suppose you want to add a linked element to the Book tender/lead use case. Follow the steps: Select the Book tender/lead use case in the dependency GUI In the explorer window, right-click on the model element you want to link to the Book tender/lead use case Choose the Work Context Add dependency menu item Your UML Modeller workspace should be like that: Page 39 of 123

40 Figure 41: UML workspace Remarks: If you are in the backward way ( Reverse root is checked), the dependency is directed from the new linked element to the previously selected element. The tool prevents linking the same element twice to another (in order to avoid dependency cycles) Remove dependencies between elements Suppose you want to remove the link between the Book tender/lead use case and the BookingService component: Select the BookingService component Click on the Remove button: the link is erased How to define the default diagram of a model element The default diagram of a model element is the diagram opened when you click on the View button in the Dependency tool. It is also the diagram opened when you right-click on a model element and select Open default View. It is possible to define the default diagram of a model element with the Dependency tool. Indeed, a default diagram is linked to the element it represents through a dependency link stereotyped by <<defaultdiagram>>. Suppose you have the following portion of model and the diagrams: Page 40 of 123

41 Figure 42: Port1 implementation CD Let s say, you want the diagram Port1 implementation CD to be Port1 s default diagram: Right-click on the class Port1 and click on the item Display dependencies In the Dependency tool, select the defaultdiagram item in the Link type combo box: Figure 43: Default diagram In the explorer window, right-click on the diagram Port1 implementation CD and choose the item Work Context Add Dependency Page 41 of 123

42 Figure 44: Add dependency View the associated diagram of a model element The View button is a shortcut to display the diagram associated to the selected element in the dependency tree. Select the element from which you want to see the associated diagram Click on the View button, the tool then determines the diagram to open thanks to the following algorithm: [if not exists default diagram] [if not exists pre-defined diagram] [if exists default diagram] [if exists pre-defined diagram] Select the first user-defined diagram DefaultDiagram: Pre-defined Diagram: User-defined Diagram: Open Diagram 3.7 Generic utility: Creation box Overview Figure 45: View dependency tree When using a Work context in Objecteering, one of the basic things to do is to create UML elements, stereotype and initialize them. This can rapidly become a tedious task because you often use several Work contexts in the same project, all providing UML syntax extensions like stereotypes. The problem is that when you have selected a Work context, you still see a lot of information coming from other Work contexts that are irrelevant. The purpose of the Creation box is double: Provide a means to automate the creation of pre-initialized stereotyped UML elements Page 42 of 123

43 Isolate the UML extensions of the other Work contexts from the one selected in a UML project Usage The MyDesignWorkContext s UML profile A Work context always owns a profile that defines the UML mapping to a conceptual model. We can use a sample UML profile for the MyDesignWorkContext as: UML::core::Class <<Stereotype>> Singleton <<Stereotype>> AbstractFactory <<Stereotype>> Composite Figure 46: Sample UML profile These three stereotypes are used for the representation of the Singleton, AbstractFactory, Composite design patterns. A UML class stereotyped by one of these stereotypes designates the main class that characterizes a design pattern. This little profile is used to illustrate how the Creation box is used Opening the Creation box from a diagram The Creation box works in collaboration with an existing diagram. The Creation box works only with three kinds of UML diagram: Activity diagram Static Class diagram Use case diagram. In order to open the Creation box from a diagram, make sure that you have selected the appropriate Work context. In the context of this document, we will use the profile defined previously. Then select the item Work Context Creation box from your class diagram (create a new one if necessary) pop-up menu. The following GUI appears: Page 43 of 123

44 All the stereotypes defined in the UML profile of the Work context and that are usable in the selected diagram. Creates in the attached diagram a pre-initialised stereotyped instance from the item selected in the list Figure 47: Available commands The contents of the Available commands widget list all the stereotypes that meet these requirements: The stereotype belongs to the UML profile defined in the selected Work context The corresponding UML meta-class (Package, Class, etc.) of each stereotype can be rendered in the diagram selected (you will not be able to create classes in an Activity diagram) The corresponding UML meta-class of each stereotype can be instantiated without necessitating other UML instances (an Association cannot be created without existing Classes) For each stereotype listed, the explorer icon of the corresponding UML meta-class is displayed, or if it exists, the user-defined explorer icon Creation of pre-initialized entities From the preceding GUI, we can create three kinds of element: Class stereotyped by <<Singleton>> Class stereotyped by <<AbstractFactory>> Class stereotyped by <<Composite>> These are the possible results basically ensured by the Creation box: instances of stereotyped UML meta-classes. This creation is achieved by double-clicking on one of the item of Available commands list. Still in our example double-clicking on Singleton will produce two things: The model element itself: a Class stereotyped by Singleton owned by the name space represented by the attached diagram A view element which is the representation of the previous model element in the attached diagram Let s say that we are editing a class diagram named DemoPackage class diagram on the DemoPackage element, your Objecteering working space looks like this: Page 44 of 123

45 Figure 48: DemoPackage UML work space Open the Creation box for Demo Package class diagram, and double-click on the item Singleton of the Available commands list, you will get: Figure 49: DemoPackage available commands The creation process assign a default name to new element, which satisfy the format: new + <name of the stereotype> + <identifier>. It can be considered as a pre-initialization, but often there is a special pre-initialization procedure associated to each stereotype, which is invoked here. If you want to see what have been pre-initialized for a newly created element, select it in the diagram and click on the button (show contents): Page 45 of 123

46 Figure 50: DemoPackage singleton You see that the pre-initialization has created a private class attribute instance and a public class method getinstance which returns the unique instance of newsingleton0. Page 46 of 123

47 4 Work Context Editor 4.1 Installation Release Files File WorkContextModule.prof WorkContextEditor.prof XT.exe rtf.xsl, html.xsl (*) Style.dot (*) Objecteering/UML work context module used in UML Modeller. Objecteering/UML work context editor module. Only for the UML Profile Builder user. XSL processor. Necessitates Windows Java execution engine. XSL style sheet for RTF and HTML document generation Winword model (*) These 2 files are part of WorkContextModule directory. See chapter 3.2 for more explanation Installation process Deliver the WorkContextModule (by double-clicking on the file). Deliver the WorkContextEditor (by double-clicking on the file). Create your document generation directory (for example c:\projectdocument) Copy xt.exe, rtf.xsl, html.xsl and style.dot into this directory. xsl and style.dot files are found in the WorkContext module directory (..modules\workcontextmodule\version\res) Open your UML profiling project. Create a test project (if it doesn t exist) Import WorkContextModule and WorkContextEditor via Multi-UML profiling project command. To see delivered modules in the list, switch on see module database toggle. Set the module parameters: Page 47 of 123

48 Figure 51: Work Context Editor Document generation We recommend that you define the same directory for the three document generation parameters. Figure 52: Work Context Editor External edition In the Windows environment, leave the external edition parameters undefined. The operating system will open the proper editor according to the file extension. Choose Open editor after generation to visualize document just after the generation. Activate the Work context commands: on one test project package, WorkContext/Add Work context Command and WorkContextEditor/Add WorkContextEditor commands. Page 48 of 123

49 Figure 53: Work Context Add work context commands Figure 54: Work Context Editor Add work context editor commands Note: this action add pop up menu commands (Automatic view, automatic validation ) Import Meta package in your test project via WorkContextEditor/Import Meta. This command adds the package called Meta, used for Xml and doc generation. Figure 55: Work Context Editor Import meta Page 49 of 123

50 4.2 First Steps (predefined view example) Create a new module called MyModule. Create a new profile called MyContext (as a child of the external profile) Reference this profile and the WorkContextDefinition profile in the module. Figure 56: MyModule MyContext Open the MyContext context editor (select the Work context definition item in the profile popup menu). Figure 57: MyContext Work context definition Select the TemplateView item. Add a new template (New template button). A new template element named View0 is created. Page 50 of 123

51 Figure 58: MyContext TemplateView Double-click on this element to open the template editor window. Figure 59: View TemplateBox Page 51 of 123

52 In the template editor, select the my view element, which represents the template itself. Click on the Add button, to create the first element of the template. This action opens the ScanMethod window. Select VgetClasses and enter the element name, for example classes of the package. Figure 60: View ScanMethodBox Confirm and return to the main window (using the OK button). The new element appears in the template. Figure 61: View Class In the right-hand part of the window, choose the red color. Create a sub element of the classes of the package element, and click on the Add button. In the ScanMethod box, choose the VgetOperation, enter the name of the element and confirm. Figure 62: View Operation Page 52 of 123

53 Add a filter on Operations of the class element. In the right-hand part of the window, click on the Add button under the Filter field. Figure 63: Operation FilterBox Select the Specific filter type, and the Visibility==Public filter (by double-clicking on the item). The selected filter appears in the Content field. After confirmation (using the OK button), the main window filter field is updated. Figure 64: Operation Main filter field Select the class element, and add an Attribute node in the same way. The resulting template is as follows: Figure 65: Attribute Main filter field Page 53 of 123

54 Save the template (using the Save button), and close the window. The Context window is updated. Figure 66: MyContext TemplateView STATIC: the diagram type Package: starting UML metaclass Close the work context window and confirm (using the OK button). Check list issue: the profile must have the WorkContextProfile tagged value. In the test project, open the work context window on one package (set work context command). Figure 67: MyContext SelectWorkContextBox Select MyContext and confirm (using the Apply button). Close the window. Page 54 of 123

55 In your test project, add a package and two classes. Create public and private properties as shown: Figure 68: TestProject Classes Diagram creation: Select the Automatic view option in the package pop-up menu. A new diagram is created, in conformance with the my view template definition. Figure 69: TestProject My view Change the colour property in the template: open the my view template of MyContext profile. Select the gold colour for the classes of the package node. Figure 70: TestProject Update view settings Update the view: in the diagram, choose Update view in the diagram's pop-up menu. Page 55 of 123

56 Figure 71: TestProject Update view (before) The diagram is updated, using the new colour definition. 4.3 First Steps (validation rules example) Figure 72: TestProject Update view (after) As for the predefined view, create a new validation template, and double-click to open the template editor window. Page 56 of 123

57 Add a new node (scan method getallclasses ) Figure 73: Validation Template box Figure 74: Validation All classes Open the condition editor (using the Add button). Page 57 of 123

58 Figure 75: Validation Condition box for package Choose the cardinality type condition. Enter <=5 in the code field, and the description of the condition. Confirm the condition (OK button). The main template window is updated. Figure 76: Validation Classes of the package Add a new condition to the node. Select the Jcondition type and enter this condition on the class name: Figure 77: Validation Condition box for class Page 58 of 123

59 Validate the condition. Add a sub node to the classes of the package node (scan method: parent classes). Resulting tree: Figure 78: Validation Parent classes node Figure 79: Validation Parent classes tree Add a new condition to the node parent classes. Select the Level type and enter this condition: Figure 80: Validation Parent classes condition box This condition specifies that the maximum level of class inheritance is 3. Change the template name (select the root template node and enter the new name). Page 59 of 123

60 Figure 81: Validation Parent classes Confirm and quit the template editor (using the OK button). Quit and validate the Work context editor window (using the OK button). In the test project, open the work context window (set work context command on the package). Figure 82: Validation Set work context Select MyContext and confirm (using the Apply button). Close the window. Create a package test in order to test the validation template: Page 60 of 123

61 Class5 aa Class4 big name abcdefghijklmnop Class3 Class2 Class1 Call the validation on the package: Figure 83: Validation Test model Figure 84: Validation Automatic validations The validation report windows show the result. Page 61 of 123

62 Figure 85: Validation Validation report Select each item to update the associated fields. 4.4 UML Profile Builder commands Command UML Element Work context definition Profile Open the work context editor Add WorkContextEditor commands Package Add pop up menu commands Template edition window: left-hand part Item Metaclass Description Save Import Export XML view Check template Define the starting UML metaclass Description of the template Save the current template state in the owner profile Import the template from the XML file Export the template to the XML file Display the template in the XML editor Check template consistency (only for document and xml generation templates) Add Remove Up Down Check elt Create a sub node on the current node Remove the current node Move up current node Move down current node Check the current node (only for document and xml generation) Template edition window: right-hand part Item Name By pass Returned metaclass Name of the current node (or name of the template) Do not execute treatment (generation ) Metaclass type returned by the scan method Read only Page 62 of 123

63 Method name Name of the scan method Read only Edit scan method Open the scan method editor Add Add filter Remove Remove selected filter Action Action to be executed ( J code) 4.5 UML Modeler commands Command UML Element Set work context Package Set the current work context Automatic view (*) NameSpace Create or update the predefined view (diagram). Automatic validation (*) NameSpace Check the model according to validation rules Open default view (*) NameSpace Open the default diagram. Open the last predefined view created, or user defined default diagram. Document generation NameSpace Generate the work context document (RTF or HTML in this version) XML document generation NameSpace Generate work context XML documents Deep automatic view NameSpace Generate views for sub-elements recursively Deep automatic validation NameSpace Check for sub-elements recursively Update view (*) Diagram Update the diagram if it is a predefined view. Define default diagram Diagram Define the current diagram as the default diagram for chosen UML elements. Add Work context commands Package Add pop up menu commands (*) Access directly via the pop-up menu on the element. 4.6 Document generation Principle Objecteering UML modeler XML XSL Processor (xt) Target Format (rtf, html..) XSL Style sheet Figure 86: Document template definition Using document template definition, Objecteering/UML generates an XML file. An XSL processor creates a target format file, based on the XSL style sheet. The current version provides two XSL style sheets, which produces RTF and HTML format documents UML Profile Builder Specific commands (template editor window) Item Check template Check template consistency, according to the metamodel chosen (Type field for root template node) Page 63 of 123

64 Check elt Type Type TypeProp Title Content AddContent Check the current node. If the node selected is the root template, the Type is the name of the metamodel. If the node is one of the template nodes, type of the node. For example: Chapter, bullet, para. This depends on document metamodel definition. Table properties Title for Chapter, Para, Bullet. Not used for the other types. Content for all types. Helps you enter content (J code) Word Macro: the style.dot Word model contains 2 useful macros: LinkPict2: insert in the document graphics (usually UML diagrams) that are linked as external files during generation. This action is necessary if you want to send the document as a unique file. UpdateField: update bookmark and reference fields. Hints: save your document as a WinWord document to reduce size. 4.7 XML generation Item Type TypeProp Content XML Tag type To define XML attributes on the node Text (data) 4.8 Using document metamodel The metamodel is used only for document and XML templates. The type list in the Type field and the check command are based on the chosen document metamodel. Each class of the metamodel represents a tag type. The root class must derive from the XmlType class, situated in the Meta/MetaType package in the test project. Figure 87: TestProject Document metamodel Two kinds of metamodel are possible: DocType and XmlType, respectively for document and Xml templates. All the metamodel elements are situated in the Meta package of the test project. Do not change this package's structure. Page 64 of 123

65 ::Meta::MetaType::XmlType 0..1 xmltypeexample 0..1 * TagElt * subelt Tag1 Tag3 Tag2 Figure 88: Example of XML template metamodel You can define your own document metamodel to drive template definition, with respect to the following rules: All non-leaf classes must be abstract. Use only aggregation links between classes. Class names represent the name of the XML tag. This facility is particularly useful for the XML generator. We recommend that you use the standard metamodel (StdDoc) for the document (rtf, html) generator. Document standard metamodel. Page 65 of 123

66 ::Meta::MetaType::DocType StdDoc <<comment>> Abstract class * * recurse Chapter 0..1 * ChapterElt <<comment>> Abstract class 0..1 DocElt * 0..1 Para StdText * recurse Liste Table IncludedDiagram 0..1 <<comment>> Abstract class * Bullet Line 0..1 * Cell Figure 89: Standard document generator metaodel The metamodel used in the WSFL generator module: Page 66 of 123

67 ::Meta::MetaType::XmlType WSFL_Template 0..1 * FlowModelElement performer * * 0..1 flowmodel datalink controllink activity 0..1 * * serviceprovider input * implement 0..1 output * * export fault * Figure 90: XML metamodel example (WSFL generator) 4.9 Work context management Work context contains a set of templates (4 types: view, validation, document, XML generators). In addition, templates are described as a part of the XML language. You can look at the XML template representation with XmlView in the template editor. It is possible to save and load a work context from one profile. These commands are available in the work context global window. A context is saved as a set of files (one for each template), and one work context file which contains work context properties. File type Work context Predefined view Validation rule Document gerator Xml generator Extension.ctx.xml.view.xml.valid.xml.doc.xml.doxXml.xml The Save context command creates work context files in the specified directory. You can load a saved work context using the Load context command. Select the.ctx.xml file according the work context you wish to load Adding scan method The module contains a set of scan methods that allows you to build templates in various situations. You can also add your own scan methods, to specialize your navigation. A scan method must have the following properties: A scan method is a tagged template. Page 67 of 123

68 A scan method must return a set of typed UML elements (for example Class, UseCase, Operation ) To add a new scan method, just create this method (J method) in a profile on the source metaclass. This method will appear in the scan method list. Don t forget to define the method description in the summary note; this text note helps you in the scan method window, as well as all required elements. Page 68 of 123

69 5 Business Work Context 5.1 Installation Module Installation You have to deploy the CombineBusiness module : Ensure that you have deployed the WorkContext module Double-click on the corresponding CombineBusinessModule_Vx.x.prof file. These steps are done only once Business work context installation Launch Objecteering s UML Modeler and open your project. Then click on the Tools Modules menu item of the main menu. A new window has been displayed, showing the available and used modules. Ensure that the WorkContext module is installed Add the CombineBusinessModule Vx.x item from the Available modules list Validate the addition by clicking on the OK button These steps are done only once in a UML project Work Context Configuration Still in the same project, click on Tools Modify Configuration items of the main menu. Select the Work Context Document generation tree items in the new window, the parameters should be correctly set (i.e. the paths exist). These steps are done only once in a UML project Business work context selection In order to work with the Business work context you need to select it in your UML project. Right-click on a Package and select the menu item Work Context Set work context Select the BusinessProfile item in the WorkContexts list and click on the Apply button Validate by clicking on the OK button 5.2 Overview The Business work context defines tool support for developing business models according to the concepts defined in the business metamodel 5.3 Usage Creation of a Business model skeleton structure Business model skeletons can be automatically created, the resulting structure is : Page 69 of 123

70 Figure 91: Business model structure Use the command Business Module Create a Business Model Edition of the Goal model Edit the class diagram attached on the package stereotyped <<GoalModel>>. Open the Creation box by right-clicking on the diagram and select the menu item WorkContext Module Creation box. The following GUI appears: Figure 92: Goal structure As you can see, there are a lot of elements that can be created in a class diagram that are not useful in a Goal model. You just need to create Goals and define a hierarchy between them. The creation of a goal can be done by double clicking on the item Goal in the Creation box GUI. You define the hierarchy by defining UML aggregations between goals, here is an example: Page 70 of 123

71 Make money High fleet utilization Win profitable bids Get competitor inteligence Be prepared for upcomming bids Make a profitable bid Creation of the root Community Figure 93: Goal model Under the business model package (stereotyped by <<BusinessModel>>) create a package stereotyped by <<Community>>. Inside the Community, new Business processes are created as Classes stereotyped by <<BusinessProcess>> and corresponding ActivityGraphs Creation of a sub-community A Sub-community details a Business Process. From a step of a business process you can automatically create a sub-community that will detail it. Use the command Business Module create a Community from this step on ActionStates stereotyped by <<Step>> The GUI that appeared lists the available Community models present in the current project, select the target one The sub-community created has the name of the responsible resource + doing + the name of the source step. A business process class and its representing ActivityGraph, standing for the source step, are also created. Example: Figure 94: Community structure Page 71 of 123

72 5.3.5 Edition of a Business process The edition of a business process is easily handled via the Creation box facility. First you have to edit the diagram attached to the ActivityGraph that stands for the Business process Open the Creation box on the diagram you will get the following GUI: Figure 95: Business process commands You can create the different elements of a business process by double-clicking on the listed items Each business process must meet at least one goal defined in the Goal model. To see/edit the goals met by a business process you should use the Dependency GUI facility: Right-click on the ActivityGraph that represents the interesting business process Select the menu item Display dependencies In the GUI that appeared, select the toggle WorkContext filter and choose the link type AchievesGoal The goals met by the Business process are shown, here is an example: Page 72 of 123

73 Figure 96: Business process goals The BusinessProcess0 meets three goals. You can add a met goal by selecting the BusinessProcess0 item and in the Objecteering s explorer window select the command WorkContext Module Add Dependency on the goal to meet. 5.4 Commands TransformStep_to_UseCase: Creates a use case in a desired package from a business step defined in the business model. A traceability link is automatically generated between the step and the use case. o Right click on a business step(an ActionState stereotyped by <<Step>>) o Select the menu item "Business Module Transform this step to a use case" o Select in the new GUI the package where the use case has to be generated TransformRole_to_Actor: Creates an actor in the desired package from a business role defined in the business model. A traceability link is automatically generated between the role and the actor. o Same steps as the previous command(right click on a Partition) CreateBusinessModel: Create a default business model. Packages : Vision for change, Context statement, Risk analysis, etc. are automatically created. The command is launched by right-clicking on a Package then select "Business Module Create a Business Model" CreateCommunityFromStep: Create a community to detail a Business Process. o Right-click on a ActionState (representing a Step in a Partition (representing a Resource in Role) o Select the menu-item "Business Module create a Community from this step" o In the GUI selects the Community model in which the community will be generated Page 73 of 123

74 5.5 UML Mapping The UML profile defines the stereotypes that Combine Component Center will use for business modeling. These are derived from the meta-models above, al-though not all concepts are represented as stereotypes. The business modeling profile will also use stereotypes from the component architecture profile, in order to bridge a business specification with component architecture. Concept UML correspondence Icons Community Package <<Community>> diagram : small : explorer : Vision for Change Package <<VisionForChange>> diagram : none small : none Context statement Risk analysis Goal model Community model Business resouce model Business process & Role model Business model Goal Business process Resource Behavioural policy Package <<ContextStatement>> Package <<RiskAnalysis>> Package <<GoalModel>> Package <<CommunityModel>> Package <<BusinessResourceModel>> Package <<BusinessProcessAndRoleModel>> Package <<BusinessModel>> Class <<Goal>> Class <<BusinessProcess>> Class <<Resource>> Class <<BehaviouralPolicy>> explorer : none diagram : none small : none explorer : none diagram : none small : none explorer : none diagram : none small : none explorer : none diagram : none small : none explorer : none diagram : none small : none explorer : none diagram : none small : none explorer : none diagram : none small : none explorer : none diagram : small : explorer : diagram : small : explorer : diagram : small : explorer : diagram : none small : none explorer : none Page 74 of 123

75 Step Event Resource in role Resource as artefact Role ActionState <<Step>> ActionState <<Event>> Partition <<ResourceAsRole>> ObjectFlowState <<ResourceAsArtefact>> ClassifierRole <<Role>> Association <<achieves>> Dependency <<AchievesGoal>> diagram : small : explorer : diagram : none small : none explorer : none diagram : small : explorer : diagram : small : explorer : diagram : none small : none explorer : none diagram : none small : none explorer : none diagram : none small : none explorer : none 5.6 Validation rules Name MetaClass Description Check Goal model Package Checks that each goal is achieved by at least one business process Check Community Package Checks that each business process achieves at least one goal Checks sub communities Check Model Structure Package Checks the first level package structure of a business model Check Business Process AG ActivityGraph Checks that each step is under the responsibility of one role 5.7 Predefined views Name MetaClass Description Context Statement View Package Displays the main functions of a system and the main interacting actors Process and goal structure Package Displays the goals achieved by the business process Goal structure Package Displays the goal hierarchy Business process structure Package Displays the business process of a Community, related resources and roles Business resource model structure Package Displays resources and relationships between them(compositions, uses, inheritances) Process view ActivityGraph Displays steps, roles, control and data flow of a businesses process Page 75 of 123

76 6 Requirements Work Context 6.1 Installation Module Installation You have to deploy the CombineRequirementsModule module : Ensure that you have deployed the WorkContext module Double-click on the corresponding CombineRequirementsModule_Vxx.prof file. These steps are done only once Requirements work context installation Launch Objecteering s UML Modeler and open your project. Then click on the Tools Modules menu item of the main menu. A new window has been displayed, showing the available and used modules. Ensure that the WorkContext module is installed Add the CombineRequirementsModule Vx.x item from the Available modules list Validate the addition by clicking on the OK button These steps are done only once in a UML project Work Context Configuration Still in the same project, click on Tools Modify Configuration items of the main menu. Select the Work Context Document generation tree items in the new window, the parameters should be correctly set(i.e. the paths exist). These steps are done only once in a UML project Requirements work context selection In order to work with the Requirements work context you need to select it in your UML project. Right-click on a Package and select the menu item Work Context Set work context Select the RequirementsProfile item in the WorkContexts list and click on the Apply button Validate by clicking on the OK button 6.2 Overview The Requirements Modelling work context (CombineRequirementsModule) defines tool support for developing requirements models according to the concepts defined in the requirements metamodel. Page 76 of 123

77 6.3 Usage Creation of a User Requirements model There exists a command that automates the creation of user requirements model. The command Requirements Module create a user requirements model creates a user requirements skeleton model. The created model contains the first level package structure : User requirements model <<rq_userrequirementsmodel>> o System Vision <<rq_systemvision>> o System Boundary Model<<rq_SystemBoundaryModel>> o Requirements Model<<rq_Requirement>> o BCE Analysis Model<<rq_BCEAnalysisModel>> o Use Case Scenarios<<rq_UseCaseScenarios>> Use Case edition You can edit a Use Case in the Objecteering tool using standard elements. For example, to add a pre condition, add a rq_pre-cond note to the Use case and enter the text in the note. In addition we provide an add-on facility based on dialog box that allows you to edit use case properties more easily. The Requirements Module Open properties command on use case elements open a dedicated dialog box that contains: Pre conditions Post conditions Non-functional constraints Exceptions Plus a toggle top level Use Case Requirement edition In the same way, a specific dialog box on package <<rq_requirement>> allows you to edit requirement properties. The Requirements Module Open properties command on requirement elements open dedicated dialog box that contains: Items Categories Description Document generation The documentation of the System Boundary Model can be automatically generated. The document generated gives the full list of all the use cases, actors, and requirements, and also overview of these elements. The generation is launched by: Page 77 of 123

78 Right-click the package representing the System Boundary Model of the requirements model Select the menu item Work Context Documentation generation A GUI has appeared proposing the available documentation templates, choose the Package:UseCaseDocument one The document UseCaseDocument.rtf has been generated in the directory you set for the Gendoc directory parameter in the Document generation group of the Work Context module 6.4 Commands OpenPropertiesUC: Use Case edition. The "Requirements module/open properties" command on use case elements open a dialog box dedicated to the edition of the properties of a use case OpenPropertiesReq: Requirement edition. The "Requirements module Open properties" command on requirement elements open a dialog box dedicated to edition of requirements CreateReqModel: Creates a user requirements skeleton model Right-click on a Package then select "Requirements Module create a user requirements model"uml Mapping 6.5 UML Mapping Concept UML correspondence Icons Class <<bce_boundary>> diagram : Class <<bce_control>> small : explorer : none diagram : Class <<bce_entity>> small : explorer : none diagram : small : explorer : none Requirement Category Package None BCE Analysis Model Package None <<rq_bceanalysismodel>> Prototype Package None Collection of Requirements <<rq_prototype>> Package <<rq_requirement>> diagram : none small : none explorer : System Vision Package None Page 78 of 123

79 Use Case model <<rq_systemvision>> Package <<rq_systemboundarymodel>> Use Case Scenarios Package <<rq_usecasescenarios>> User Requirements Model Package None <<rq_userrequirementsmodel>> Event Role Actor None <<rq_eventrole>> Human Role Actor None <<rq_humanrole>> System Role Actor None <<rq_systemrole>> UseCase None <<rq_manage>> Use Case Exception UseCase None Note type : rq_exception Use Case Non functional UseCase None constraint Note type : rq_non-functconstraint Use Case Post condition UseCase None Note type : rq_post-cond Use Case Pre condition UseCase None Note type : rq_pre-cond Use case identification UseCase None Tagged-value : rq_id UseCase None Tagged-value : rq_private Top level use case UseCase None Tagged-value : rq_top Requirement Item None Requirement Initiator Item None Note type : rq_initiator Requirement Priority Item None Note type : rq_priority Dependency None <<tracetocomponent>> 6.6 Validation rules diagram : none small : none explorer : None Name MetaClass Description Check use case package Package Checks some metrics on use cases and actors, and verifies for the existence of description on use cases Check Actors Package Checks that each actor (recursively) has a dependency to a business actor/resource. Checks that each actor has a description Check model structure Package Checks the first level package structure of a requirements model 6.7 Predefined views Name MetaClass Description UseCaseGlobal Package Global view of all the use cases : package's use cases with the relationships between them and to actors UseCaseLocal UseCase Local view of a use case : a particular use case with the use cases and actors that are directly linked to it Top level view Package Global view of all top level use cases belonging to Page 79 of 123

80 a package. The relationships between them and to actors are displayed Actor view Actor Displays for a particular actor its communicating use cases 6.8 Documentation generation Name MetaClass Description UseCaseDocument Package Documents the user requirements model. The document generated firstly presents an overview then a detailed description of the model. Least, a requirements table shown the use cases associated with the requirements Page 80 of 123

81 7 Architecture Work Context 7.1 Installation Module Installation You have to deploy the CombineArchitecture module: Ensure that you have deployed the WorkContext module Double-click on the corresponding CombineArchitectureModule_Vx.x.prof file. These steps are done only once Architecture work context installation Launch Objecteering s UML Modeler and open your project. Then click on the Tools Modules menu item of the main menu. A new window has been displayed, showing the available and used modules. Ensure that the WorkContext module is installed Add the CombineArchitectureModule Vx.x item from the Available modules list Validate the addition by clicking on the OK button These steps are done only once in a UML project Work Context Configuration Still in the same project, click on Tools Modify Configuration items of the main menu. Select the Work Context Document generation tree items in the new window, the parameters should be correctly set (i.e. the paths exist). These steps are done only once in a UML project Architecture work context selection In order to work with the Architecture work context you need to select it in your UML project. Right-click on a Package and select the menu item Work Context Set work context Select the ArchitectureProfile item in the WorkContexts list and click on the Apply button Validate by clicking on the OK button 7.2 Overview The Architecture work context defines tool support for developing architecture models according to the concepts defined in the architecture meta-model. Page 81 of 123

82 7.3 Usage Creation of an Architecture model There is no particular first level structure for an Architecture model. The architecture work context acts on component and their specifications Edition of Component specifications Using dedicated commands From the model explorer window component specifications are created via the commands: create an application specification create a tool specification create a business service specification create a user service specification create a resource service Figure 97: Architecture Model create commands Each command will create a default component and a provided interface inside the specification package, for example you can create application specifications by clicking on the Architecture Module create an application specification menu item from the Architecture Model package: Page 82 of 123

83 Figure 98: Architecture model structure Inside the created application specification package there is also a default application component (anapplication1) and a default empty provided interface that the user can use as a start. Other creation commands will behave the same respectively for Tool, Business service, etc Using the Creation box The Creation box is typically used for the edition of component specification diagrams. For an Application specification structure diagram you will create owned Tool and Business services specifications like this: Open the Creation box (right-click on the diagram and select WorkContext Module Creation box ): Figure 99: Tool specification For example, double-clicking on the item ToolSpecification will create a package stereotyped by <<ToolSpecification>> in the source diagram Page 83 of 123

84 7.3.3 Creation of components Figure 100: Tool specification class diagram As for components specification, you can use the Creation box facility to create components inside components specifications. From a local application specification structure diagram, you create components and provided interfaces like this: Open the Creation box (right-click on the diagram and select WorkContext Module Creation box ) : Figure 101: Application specification Double click on the Application item, this will create an application component in the model and a view in the selected diagram : Page 84 of 123

85 Figure 102: Application specification class diagram An application component class and an empty provided interface are automatically created. Component internals like ports can be created from the Creation box in the same way Validate the components Validation on components is launched from any component specification through the command Automatic Validations. You can launch validation rules on application specification packages, so that it will verify the whole structure of the specification and the presence of correct definitions components. Right-click on the Automatic validations item from an application specification popup menu to launch the validations: Generate pre-defined views Figure 103: Survey booking Automatic validations From any component specification you can generate three pre-defined views: Component specifications structure Local specification structure Global specification structure Select the Automatic views menu item from a component specification popup menu, say for the Booking Editor tool specification: Page 85 of 123

86 You might get the diagrams: Figure 104: Booking Editor pre-defined views Figure 105: BookingEditor Diagram 1 Figure 106: BookingEditor Diagram 2 Page 86 of 123

87 7.4 Commands Figure 107: BookingEditor Diagram 3 CreateApplication: Creates an Application specification. It also creates inside it an Application component and a provided interface. CreateTool: Creates a Tool specification. It also creates inside it a UserInterface and UserService specifications. CreateBusinessService: Creates a BusinessService specification. A default BusinessService component class and a provided interface are also created. CreateUserService: Creates a UserService specification. A default UserService component class and a provided interface are also created. CreateResourceService: Creates a ResourceService specification. A default ResourceService component class and a provided interface are also created. 7.5 UML Mapping Concept UML correspondence Icons Application Class <<Application>> diagram : none small : explorer : Auxiliary Class None BusinessService CompositeData Entity EntityData Event EventInterface Focus InteractionWorkflow <<Auxiliary>> Class <<BusinessService>> Class <<CompositeData>> Class <<Entity>> Class <<EntityData>> Class <<Event>> Class <<EventInterface>> Class <<Focus>> Class <<InteractionWorkflow>> diagram : none small : explorer : None None None None diagram : small : explorer : None diagram : none small : explorer : Page 87 of 123

88 InterworkingWorkflow Message MessageInterface PrimaryKey Port Protocol ResourceService Tool UserInterface UserResourceService UserService ValueType ApplicationSpecification BusinessServiceSpecification InterworkingWorkflowSpecification Class <<InterworkingWorkflow>> Class <<Message>> Class <<MessageInterface>> Class <<PrimaryKey>> Class <<Port>> diagram : none small : explorer : None None None diagram : small : explorer : Class <<Protocol>> diagram : Class <<ResourceService>> Class <<Tool>> Class <<UserInterface>> Class <<UserResourceService>> Class <<UserService>> Class <<ValueType>> Package <<ApplicationSpecification>> Package <<BusinessServiceSpecification>> Package <<InterworkingWorkflowSpecification>> small : explorer : diagram : none small : explorer : diagram : none small : explorer : diagram : none small : explorer : diagram : none small : explorer : diagram : none small : explorer : None diagram : none small : none explorer : diagram : none small : none explorer : diagram : none small : none explorer : InteractionWorkflowSpecification ProtocolSpecification ResourceServiceSpecification UserInterfaceSpecification Package <<InteractionWorkflowSpecification>> Package <<ProtocolSpecification>> Package <<ResourceServiceSpecification>> Package <<UserInterfaceSpecification>> diagram : none small : none explorer : None diagram : none small : none explorer : diagram : none small : none explorer : Page 88 of 123

89 UserResourceServiceSpecification UserServiceSpecification ToolSpecification TypeLibrary Package <<UserResourceServiceSpecification>> Package <<UserServiceSpecification>> Package <<ToolSpecification>> Package <<TypeLibrary>> Use <<rolebinding>> Use <<implements>> Association <<initiates>> Association <<responds>> Association <<protocol>> Association <<connector>> AssociationRole <<Connection>> Operation <<oneway>> Operation <<request-response>> Operation <<notification>> Operation <<solicit-response>> Link <<Connector>> diagram : none small : none explorer : diagram : none small : none explorer : diagram : none small : none explorer : None None None None None None None None None None None None None 7.6 Validation rules Name MetaClass Description Check component specification Package These rules are launched on ComponentSpecification : - Checks if there is one and only one Component class in each ComponentSpecification package - Checks if each Component class defined in a ComponentSpecification provides at least one interface Check ApplicationSpecification Package These rules are launched from the root of the ComponentSpecifications : - Checks if Application specifications are decomposed by Tool or BusinessService or ResourceService specifications - Checks if Tool specifications are decomposed by UserInterface or UserService specifications Check Package Check business services specifications BusinessServiceSpecification Check Package Check resource services specifications ResourceServiceSpecification Check Package Check user interface specifications UserInterfaceSpecification Check UserServiceSpecification Package Check user services specifications Check ToolSpecification Package Check tool specifications Page 89 of 123

90 7.7 Predefined views Name MetaClass Description Component specifications structure Package This view is launched from a ComponentSpecification. Elements displayed : - ComponentSpecifications owned by the ComponentSpecification from which the view is launched Local specification structure Global specification structure Component Interface View Package Package Package - Use links between these sub specifications This view is launched from a ComponentSpecification. Elements displayed : - Components classes - Provided and required intefaces of the Components classes This view is launched from a ComponentSpecification. Elements displayed : - All the Components classes defined by sub specifications - Provided and required interfaces Displays the interface of the selected component specification package Page 90 of 123

91 8 Workflow Work Context 8.1 Installation Module Installation You have to deploy the CombineWorkflow module: Ensure that you have deployed the WorkContext module Double-click on the corresponding CombineWorkflowModule_Vx.x.prof file. These steps are done only once Workflow work context installation Launch Objecteering s UML Modeler and open your project. Then click on the Tools Modules menu item of the main menu. A new window has been displayed, showing the available and used modules. Ensure that the WorkContext module is installed Add the CombineWorflowModule Vx.x item from the Available modules list Validate the addition by clicking on the OK button These steps are done only once in a UML project Work Context Configuration Still in the same project, click on Tools Modify Configuration items of the main menu. Select the Work Context Document generation tree items in the new window, the parameters should be correctly set (i.e. the paths exist). These steps are done only once in a UML project Workflow work context selection In order to work with the Workflow work context you need to select it in your UML project. Right-click on a Package and select the menu item Work Context Set work context Select the WorkflowProfile item in the WorkContexts list and click on the Apply button Validate by clicking on the OK button 8.2 Usage Creation of a Workflow model From scratch Workflow models can be created from scratch, i.e. not from Business process. There is no particular indication for the creation of the structure of a workflow model. You can adopt you Page 91 of 123

92 own model structure. Just create a package named Workflow model and organize the ActivityGraphs representing your workflows as you wish From a Business Process model But Workflow models could be inferred from Business Process model. In that case, there should exist a Workflow that defines the execution schema and automation for each business process. Follow the steps in order to create the Workflow model: Create a new UML package named Workflow model For each community in the business model create a sub-package of Workflow model, with the same name as the corresponding community For each Business processes defined in a community of the business model, create an ActivityGraph having the same name as the business process prefixed by Workflow for. This ActivityGraph is owned by the package representing the community in the Workflow model Edition of a Workflow Create steps Figure 108: Creation of a workflow model Workflow steps are created easily through the Creation box facility. First you have to edit the activity diagram of the Workflow in which you want to create steps. Right-click on the diagram and select the menu item Work Context Creation box The Creation GUI appeared, showing the different kinds of steps you can instantiate : Page 92 of 123

93 Figure 109: Workflow commands For example, double-clicking on the WF_RepeatUntil item will instantiate an SubActivityState stereotyped by <<WF_RepeatUntil>> that contains a PseudoState standing for the exit condition of a repeat until step. As you can see, it is impossible to create atomic steps inside composite steps through the Creation box, because it instantiates elements directly in the root element of the diagram. To achieve this, you should use the commands defined on SubActivityState. For example, if you want to create a ToolAtomicStep inside a Repeat until step: Right-click on the repeat until step and select the menu item Workflow Module create a ToolAtomicStep To make the created step visible in the diagram, click on button Create the control flow You can use the UML Fork, Join, and Branch states in order to define the behaviour aspects of the Workflow. There is a special usage of the transitions that come out of a conditional symbol. There must exist two outgoing transitions having respectively the guard transitions [T] and [F]: T means that the information about the next step to execute results from a true evaluation of the condition F means that the information about the next step to execute results from a false evaluation of the condition Example : [F] B [T] A Figure 110: Control flow example Page 93 of 123

94 The execution chronology of the steps is defined by the UML transitions that exist between them. A step can only have at most one incoming transition and one outgoing transition. You can define guards on transitions, allowing steps to be executed under particular conditions Create the data flow The relationships between data, their type and structure are described by the data flow. Steps can exchanged data by specifying a data link between them, which is a triplet {, ObjectFlowState, } : A data:msg1 B Figure 111: Data flow example The structure of a message is defined by the parts of a message. A message is the type of a data exchanged between two steps. You can create data links directly with Objecteering native GUI facilities. Be sure that the messages Class you create are easily accessible (they must be owned by a parent package of the Workflow one, or in used package). Messages cannot yet be generated in WSDL from Objecteering, but you can specify the XML Schema that your Workflow will use for the definition of the data types. This is achieved through the Workflow Module Set Data Types location command. In the GUI that appears, you type the URI that localize your datatypes definition Edition of the properties of a step Each step defines properties that are needed at execution time. There exist different properties for each kind of steps. Type of step System atomic step Human atomic step Tool atomic step Human step Automatic step Repeat until step Properties PreCondition : domain class that implements the Condition interface with one 'evaluate' method that returns either 'true' or 'false'. This feature is currently turned off and if no value is specified it defaults to a class name that always returns true DomainObject : domain class that implements an 'execute' method. Domain objects are domain specific classes that execute the business logic in an automatic fashion (i.e. no human interaction is modelled in the workflow) PreCondition WorkItemGenerator : domain class that puts domain specific information in a work item when the work item is created. So that when the user tries to see the work item it knows what information to display. This class is invoked during work item creation Tool : domain class responsible for invoking a tool component that will interact with the user Same as Human atomic step PreCondition PreCondition PreCondition GuardEvaluator : Class that implements the GuardEvaluation interface. It will be invoked in order to evaluate the loop guard of a Repeat until step Page 94 of 123

95 These properties can be easily set by right-clicking on a step and select the menu item Workflow Module Edit properties. A GUI appears listing the properties of the selected step. For example suppose you have edit the properties of system atomic step, you will get: Figure 112: System atomic step This GUI works in collaboration with the explorer window. If you want to set the DomainObject property, you have to right-click in the explorer the interesting Class and select the menu item Workflow Module set DomainObject in "Edit properties" GUI : Figure 113: Workflow module Set domain object The edition of the properties of the other kind of steps is based exactly on the same mechanism Validate a Workflow Automatic validations are launched by right-clicking on the ActivityGraph representing the Workflow then select the menu item Automatic Validations. Please refer to the Validation rules chapter for more details. Page 95 of 123

96 8.2.5 Generate the XML Workflow The XML generation is launched by : Right-click on the ActivityGraph that represents the Workflow you want to translate into XML, then select the menu item WorkContext Module Automatic XML Select in the GUI the XML template ActivityGraph:INESC s XML Workflow The file INESC's XML Workflow.xml has been generated in the directory you set in the Worflow Module Document generation Gendoc directory parameter Important remark: not all the elements of a Workflow are supported in the generation of the XML Workflow. Elements not supported are: Conditional, Join and Fork states. 8.3 Commands createhumanatomicstep: Creates a human atomic step inside the selected composite step o Right click on a composite step(a SubActivityState) in the explorer or in an activity diagram o Select the menu item "Workflow Module create a HumanAtomicStep" o If you have performed the command from an activity diagram, you can display the created element by right-clicking on the Composite step owning it then select "Show contents" createrepeatuntilstep: Creates a repeat until step inside the selected composite step o Right click on a composite step(a SubActivityState) in the explorer or in an activity diagram o Select the menu item "Workflow Module create a RepeatUntilStep" o If you have performed the command from an activity diagram, you can display the created element by right-clicking on the Composite step owning it then select "Show contents" createtoolatomicstep: Creates a tool atomic step inside the selected composite step o Right click on a composite step(a SubActivityState) in the explorer or in an activity diagram o Select the menu item "Workflow Module create a ToolAtomicStep" o If you have performed the command from an activity diagram, you can display the created element by right-clicking on the Composite step owning it then select "Show contents" createsystematomicstep: Creates a system atomic step inside the selected composite step o Right click on a composite step(a SubActivityState) in the explorer or in an activity diagram o Select the menu item "Workflow Module create a SystemAtomicStep" Page 96 of 123

97 o If you have performed the command from an activity diagram, you can display the created element by right-clicking on the Composite step owning it then select "Show contents" SetDataTypesLocation: Used to set the data types location. Just type the URI in the text field and validate. The GUI is launched by right-clicking on an ActivityGraph and then select "Workflow Module Set Data Types location" displayeditio: This command is not yet finished, do not use it. EditProperties: Allows the editing of workflow step's execution properties. It is launched by right-clicking on a step then select "Workflow Module Edit properties" The setting of a property in the GUI that appeared, works in collaboration with the commands: o set PreCondition (available for all types of step) o set DomainObject (only for SystemAtomicStep) o set Tool (only for HumanAtomicStep and ToolAtomicStep) o set WorkItemGenerator (only for HumanAtomicStep and ToolAtomicStep) o set GuardEvaluator (only for RepeatUntil) These commands are made available when the GUI is ready, and are contextuals to the type of step that is being edited. Afterwards, when the GUI is closed, these commands are unavailable. setdomainobject: It sets the domain class that implements an 'execute' method. Domain objects are domain specific classes that execute the business logic in an automatic fashion. o Ensure that you are editing a step ("EditProperties" GUI is launched) o In the explorer window, right-click on a Class and select the menu item "Workflow Module set DomainObject in "Edit properties" GUI" This commands works in collaboration with the "EditProperties" GUI and is only available when editing a system atomic step. setprecondition: It sets the class that evaluates the PreCondition of the incoming transition of a step : o Ensure that you are editing a step ("EditProperties" GUI is launched) o In the explorer window, right-click on a Class and select the menu item "Workflow Module set PreCondition in "Edit properties" GUI" This commands works in collaboration with the "EditProperties" GUI and is only available when editing a step. setworkitemgenerator: It sets the domain class that puts domain specific information in a work item when the work item is created : o Ensure that you are editing a step ("EditProperties" GUI is launched) o In the explorer window, right-click on a Class and select the menu item "Workflow Module set WorkItemGenerator in "Edit properties" GUI" This commands works in collaboration with the "EditProperties" GUI and is only available when editing a ToolAtomicStep or HumanAtomicStep. Page 97 of 123

98 settool: It sets the domain class responsible for invoking a tool component that will interact with the user : o Ensure that you are editing a step ("EditProperties" GUI is launched) o In the explorer window, right-click on a Class and select the menu item "Workflow Module set Tool in "Edit properties" GUI" This commands works in collaboration with the "EditProperties" GUI and is only available when editing a ToolAtomicStep or HumanAtomicStep. setguardevaluator: It sets the class that evaluates the guard of repeat until step : o Ensure that you are editing a step ("EditProperties" GUI is launched) o In the explorer window, right-click on a Class and select the menu item "Workflow Module set GuardEvaluator in "Edit properties" GUI" This commands works in collaboration with the "EditProperties" GUI and is only available when editing a repeat until step. 8.4 UML Mapping Concept UML correspondence Icons Workflow ActivityGraph None ActivityGraph None Tagged-value : WF_DataTypesLocation Human atomic step ActionState None <<WF_HumanAtomicStep>> System atomic step ActionState None <<WF_SystemAtomicStep>> Tool atomic step ActionState None <<WF_ToolAtomicStep>> Automatic step SubActivityState None <<WF_AutomaticStep>> Human step SubActivityState None <<WF_HumanStep>> Repeat until step SubActivityState None <<WF_RepeatUntil>> Repeat until guard PseudoState None Note type : LoopGuard SystemAtomicStep.domainObject Dependency None <<DomainObject>> SystemAtomicStep.guardEvaluator Dependency None <<GuardEvaluator>> Step.precondition Dependency None <<PreCondition>> HumanStep.tool Dependency None <<Tool>> HumanStep.workItemGenerator Dependency <<WorkItemGenerator>> None 8.5 Validation rules Name MetaClass Description Check composite steps ActivityGraph Checks the type of the steps inside Composite steps Checks that there are no cycles between the steps inside Composite steps Check atomic steps ActivityGraph Checks that the owner step of atomic steps is correct Page 98 of 123

99 8.6 Predefined views Name MetaClass Description Workflow overview ActivityGraph Displays first level steps, which are composite steps Workflow detailed view ActivityGraph Displays all the contents of first level steps Page 99 of 123

100 9 Workflow and Business Model 9.1 WARM model Discussions on workflow and business model reach to some changes. The new version of the business model contains full representation of WARM (Work Analysis Refinement Model). In particular the WARM extensions add a set of stereotypes on Activity graph elements that can be directly used in the workflow context (toolstep, humanstep). List of WARM stereotypes: Metaclass Stereotype Icon SubActivityState Step Diagram: Small: Explorer: SubActivityState HumanStep Diagram: Small: Explorer: SubActivityState ToolStep Diagram: SubActivityState Actor ImmediateStep ActorResource Small: Explorer: Diagram: Small: Explorer: Actor Actor Actor HumanTool Human OtherSystem Diagram: Small: Explorer: Diagram: Small: Explorer: Diagram: Small: Explorer: Actor Workflow Diagram: Small: Explorer: Diagram: Page 100 of 123

101 Small: Actor Product Explorer: Actor BusinessService Diagram: Small: Explorer: ObjectFlowState Partition ResourceAsArtefact ResourceAsRole Diagram: Small: Explorer: Diagram: Small: Explorer: Diagram: Small: Explorer: 9.2 Workflow generation Nevertheless, workflow model has another objective: to generate a workflow format file from the activity graph model. This generation necessitates some additional information. Typically, workflow generation requires precise information on IT elements, used tools or parameters. Notice that these additional elements don t introduce any change in the structure of the WARM model. Defined as tagged-value extensions, there are rather considered as properties on the model without any new element type (no new stereotype). Tagged-values defined in workflow profile: Metaclass Name Description SubActivityState wf_domainobject Domain class that implements an 'execute' method. Domain objects are domain specific classes that execute the business logic in an automatic fashion (i.e. no human interaction is modelled in the workflow). Applies to: ImmediateStep. SubActivityState wf_precondition Domain class that implements the Condition interface with one 'evaluate' method that returns either 'true' or 'false'. This feature is currently turned off and if no value is specified it defaults to a class name that always returns true. Applies to: ImmediateStep, ToolStep, HumanStep SubActivityState wf_tool Reference for invoking a tool component that will interact with the user. Applies to: ToolStep. SubActivityState wf_workitemgenerator Put domain specific information in a work item when the work item is created. So that when the user tries to see the work item it knows what information to display. This class is invoked during work item creation. Applies to: ToolStep, HumanStep SubActivityState wf_toolparameter Describes the parameters to be passed to a tool. Applies to: ToolStep. The format of the note should be: (name: astring value: astring name: astring messagepartname: Page 101 of 123

102 astring) (1) ObjectFlowState wf_sourcemessage Name of the source message to which this object flow refers ObjectFlowState wf_targetmessage Name of the target message to which this object flow refers ObjectFlowState wf_sourcepart Name of the source message part of the chosen source message. Used if only part of the message should be read ObjectFlowState wf_targetpart Name of the target message part of the chosen target message. Used if only part of the message should be written (1) The name is just the name of the parameter. The value should be used when passing a pre-known value. The messagepartname should be used when the parameter to pass comes from a part of the ToolsStep s input message. 9.3 Workflow production line The main function is to transform an UML activity graph (WARM model) in a workflow structure that can be interpreted directly by the workflow engine. To reduce complexity and to facilitate future modifications, we choose to separate this transformation in two steps (Figure 114): first step generates simple XML file using work context tool kit facility. The second step generate final workflow format (also an XML file) using a dedicated java program. Edition WARM model edition WARM XML generation UML modeler tool Business work context Workflow work context XML WARM Generation Java program UML model XML Workflow WorkFlow Engine Exploitation Figure 114: Workflow file generation architecture Notice that with this structure, one can easily replace the workflow engine by another, or introduce changes in the input workflow format. Page 102 of 123

103 Java program1 XML Workflow1 Workflow Engine3 XML WARM Java program2 XML Workflow2 Workflow Engine2 Figure 115: Two workflow engines using same WARM model source Typically, the simplified process can be described as the following steps: The business expert defines business processes including activity graphs according to WARM notations. The workflow expert adds specific information on the WARM model The workflow external XML file is generated, and workflow engine execution can be tested Page 103 of 123

104 10 UML Model Transformation Tool (UMT) UMT (UML Model Transformation Tool) is a prototype developed within the scope of the DAIM, CAFÉ, COMBINE, and ACEGIS projects Overview UMT is a tool to support model transformation and code generation based on UML models in the form of XMI. XMI models are imported by the tool and converted to a simpler intermediate format, which is the basis for validation and generation towards different target platforms. The intermediate format is an XML format, which in UMT is called XMI Light. The end-user of the tool doesn t need be concerned about this format. However, the developers of code generators (emitters) need to know its details. (In this context, an emitter is a mechanism that generates output from a source model, e.g. code. An emitter is also called a code generator or a transformer.) The main usage scenario is to import a UML XMI model and generate code for the desired target platform. Figure 116 shows the high-level use cases that are most pertinent to a developer using UMT. Export XMI UML Tool XMI <<extend>> HUTN <<extend>> Import/export models Choose target transformation User configuration Install/Uninstall transformation System Developer (UMT user) Preview transformation Edit target properties Execute reverse transformation Execute transformation Figure 116: UMT high-level use cases Figure 116 shows the high-level use cases for a UMT user. The user will typically import models in the form of XMI or XMI Light, which represent UML models from some UML tool. The user will have the choice of choosing target technology, edit some properties for the target technology, preview and then execute the transformation. This will produce output for the target technology. The user will also configure project- or user-specific settings and install/un-install transformations. Page 104 of 123

105 10.2 High-level architecture Figure 117 and Figure 118 illustrates the high-level architecture of UMT. Figure 117 describes the high-level components independent of technology (platform-independent). Figure 117 shows a more technology-near architecture. <<Tool>> UMT <<Tool>> Model Browser/Editor <<Tool>> Transformation Tool <<Tool>> Project Editor <<Tool>> Profile Editor <<entity>> UMT-Model +model <<userservice>> ModelImportExportUS <<userservice>> TransformationUS ITransformationMgr ITransformation irep <<resource-component>> External Repository <<service-component>> Transformation Manager <<service-component>> UMT-Repository <<service-component>> Trans formationengine +implementati on 0..* <<entity>> TransformationSpec Figure 117: UMT high-level architecture (platform-independent) The UMT tool consists of sub-tools that provide different end-user functionality. The model browser/editor provides a viewer towards a model and the capability of assigning different kind of properties to model elements, for example technology-specific properties. The project editor provides a context for working with source models. The profile editor provides a means of providing support for the concepts in product line architectures. The transformation tool provides the means for defining and modifying new transformations. Page 105 of 123

106 <<java>> UMT UI +model <<java>> Model Editor <<java>> Transformation Tool <<java>> Profile Editor <<java>> Project Editor <<xml>> XMI-Light IFileSys ITransformat ion ITransformat ionmgr Local filesystem <<java>> Transformation Engine <<java>> Transformation Manager IPropMgr +model_files <<xml>> XMI 0..* <<java>> XSLT-transformer <<java>> Java transformer <<java>> UMT Property Manager +implementation <<xslt>> XSLT-file +imple me ntati on <<javaclass>> Java-implementat... +managed_files <<xml >> Property Files Figure 118 UMT high-level architecture (Platform-specific) Figure 118 shows a platform-specific mapping of UMT s high-level architecture, where the different components are represented by a platform-specific view of their realisation. The <<java>> stereotype reflects a java implementation; the <<xml>> stereotype reflects an XML file; the <<xslt>> stereotype reflects an xslt file; the <<javaclass>> stereotype reflects a compiled java class UMT Tool-chain UMT can be used as both a visual tool and as a command-line tool. The architecture of it s code generation component (transformation engine) is based on XSLT. It also supports other kinds of transformer implementation, e.g. java-based. Details of the transformation architecture are described in chapter An overview of the UMT tool-chain, where UMT is integrated with a UML modelling tool, is shown in Figure UML model UML Tool XMI doc of UML Model XSLT-file1 XSLT-file2 XMI Light of UML Model 6 Document Data f Process Java, C#,.. XML: GML, WSDL, Figure 119: UMT tool chain The conceptual UML model may be mapped to many technologies DB, SQL, J2EE,.Net, Page 106 of 123

107 The process of using UMT together with a modelling tool is described in a simple way below. (1) The source for using UMT is a UML model described in some UML tool capable of exporting XMI. (2) XMI is used as an intermediate format, which is exported from the UML tool and imported by UMT. XMI will provide tool-independence with respect to the UML modelling tool. (3) The XMI-representation of the model is imported by UMT. (4) UMT transforms XMI to a simpler format, called XMI Light. This transformation is done in order to simplify later transformations. XMI Light is further described in chapter UMT uses XSLT to transform XMI to XMI Light. (5) XMI Light is the internal model representation used by UMT. This is the format that is transformed to different target technologies, like Java, C#, XML-based formats like WDSL, GML, database schemas, application server technologies, like J2EE,.Net. (6) UMT transforms the XMI Light to desired target technology using a transformer (a transformation implementation). In UMT, this is normally XSLT, but may also be a Java-implementation. XMI Light is transformed to the end-result, for instance J2EE, WSDL, GML, etc XMI integration As shown in the previous chapter, UMT uses XMI as the UML integration format. The currently supported XMI is XMI version 1.0 for UML version 1.1/1.3 and XMI version 1.1 for UML 1.3 and XMI Light XMI Light is the internal model used by UMT, i.e. it is an intermediate format used by the tool. It is also, however, a simple lexical view into the UML model. UMT transforms XMI to the XMI Light format, which is used by the tool for browsing and editing. The UMT transformers use XMI Light as a source metamodel for doing code generation. Page 107 of 123

108 model datatype name : string uses target : string type : string package : string 0..* 0..* uses datatypes uses name : string stereotype : string 1..* package name : string stereotype : string classes 0..* class name : string superclass : classname abstract : boolean stereotype : string implements : list [classname] +packages 0..* <<enumeration>> enumcollectiontype set list bag dictionary <<enumeration>> enumaggregationtype composite aggregate shared none value <<enumeration>> enumdirectiontype in out in-out 0..* attribute name : string type : string stereotype : string 0..* association name : string targetclass : classname cardinality : string collectiontype : enumcollectiontype aggregationtype : enumaggregationtype stereotype : string 0..* operation name : string returntype : string visibility : string stereotype : string 0..* parameter direction : enumdirectiontype name : string type : string Figure 120: XMI Light meta model The example below shows how the XML-based representation of the XMI Light looks. The details of the format are specified in an XML schema file (XMI Light.xsd). Figure 121 shows the UML source for the example. <model xmlns:xsi=" xsi:nonamespaceschemalocation="xmi Light.xsd"> <package id="rootpack_ticket" name="ticket"> <class abstract="false" id="class_ticketservice" name="ticketservice" stereotype="service"> <implements id="class_iticketservice" /> <implements id="class_iauthorisaton" /> <attribute cardinality="1..1" name="owner" type="dt_string" /> <attribute cardinality="1..1" name="version" type="dt_string" /> <association aggregationtype="none" cardinality="0..*" collectiontype="set" name="reservations" targetclass="class_reservation" /> <operation name="buyticket" returntype="class_ticket" /> <operation name="pay"> <parameter name="amount" type="dt_integer" /> </operation> <taggedvalue tag="persistence" value="transient" /> </class> <class abstract="false" id="class_ticket" name="ticket" stereotype="entity"> <attribute cardinality="1..1" name="price" type="dt_integer" /> <attribute cardinality="1..1" name="issuedate" type="dt_date" /> <attribute cardinality="1..1" name="ticket_id" type="dt_string" /> <taggedvalue tag="persistence" value="transient" /> </class> <class abstract="false" id="class_reservation" name="reservation" stereotype="entity"> <attribute cardinality="1..1" name="reservation_id" type="dt_string" /> <association aggregationtype="none" cardinality="1..*" collectiontype="set" name="reservation_for" targetclass="class_ticket" /> <taggedvalue tag="persistence" value="transient" /> </class> <class abstract="false" id="class_iticketservice" name="iticketservice" stereotype="interface"> <operation name="payreservation" returntype="class_reservation"> <parameter name="ticket_id" type="dt_string" /> </operation> <operation name="gettickets" returntype="dt_list_ticket_" /> <operation name="reserveticket"> <parameter name="ticket_id" type="dt_string" /> </operation> Page 108 of 123

109 <taggedvalue tag="persistence" value="transient" /> </class> <class abstract="false" id="class_iauthorisaton" name="iauthorisaton" stereotype="interface"> <operation name="login" returntype="dt_string"> <parameter name="username" type="dt_string" /> <parameter name="password" type="dt_string" /> </operation> <taggedvalue tag="persistence" value="transient" /> </class> <datatype id="dt_string" name="string" /> <datatype id="dt_integer" name="integer" /> <datatype id="dt_date" name="date" /> <datatype id="dt_list_ticket_" name="list(ticket)" /> <package id="pack_ticketfactory" name="ticketfactory"> <class abstract="false" id="class_ticketfactory" name="ticketfactory"> <attribute cardinality="1..1" name="session_id" type="dt_string" /> <operation name="createticket" returntype="class_ticket" /> <taggedvalue tag="persistence" value="transient" /> </class> </package> <package id="pack_ticketshop" name="ticketshop"> <uses target="pack_ticketfactory" /> <class abstract="false" id="class_tshop" name="tshop"> <attribute cardinality="1..1" name="shop" type="dt_string" /> <taggedvalue tag="persistence" value="transient" /> </class> </package> </package> </model> <<service>> TicketS ervice + owner : st ri ng + version : string + buyticket() : Ticket + pay(amount : integer) IAuthorisaton + login(username : string, password : string) : string TicketShop + TShop ITicketService + payreservation(ticket_id : string) : Reservation + gettickets() : list(ticket) + reserveticket(ticket_id : string) +reservations 0..* TicketFactory + TicketFactory <<entity>> Reservation + reservation_id : string 1..* +reservation_for <<entity>> Ticket + price : integer + issuedate : date + ticket_id : string Figure 121: UML Ticket example Figure 121 shows the UML model representation corresponding to the XMI Light example above Transformer development The transformer architecture in UMT is based on a flexible model where different kind of transformer implementations can be plugged in. Currently, two main different types of transformers can be plugged in: Java transformers and XSLT-transformers. Page 109 of 123

110 XSLT transformer A UMT XSLT transformer is an XSLT Stylesheet that produces transformations based on XMI Light input models. Currently, there are two kinds of XSLT transformers; single-file and multi-file. Single-file XSLT transformers are aimed at producing one single output file from the source model, e.g. a WSDL or SQL file. The single-file transformation process is implemented just by an XSLT file and the result is that produced by that file. Multi-file XSLT transformers are aimed at producing several output files from the source model, e.g. a set of java files. The multi-file transformation process is implemented by an XSLT file and pre-processed by a UMT Java Transformer class. The XSLT result defines an XML structure of packages and files, which is used to produce physical files. The processing of a multi-file transformation is currently implemented by the UMT class transformer.defaultmultifiletransformer. Common to both types of transformers is that the XSLT relates to the XMI Light input. A format pattern of a single-file XSLT: <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:output method="xml" indent="yes"/> <xsl:template match="model"> <xsl:apply-templates select="package"/> </xsl:template> <xsl:template match="package"> THIS IS PRODUCED AS OUTPUT FOR THE PACKAGE. <xsl:apply-templates/> </xsl:template> <!-- *** template match class --> <xsl:template match="class"> THIS IS PRODUCED AS OUTPUT FOR THE CLASS <xsl:apply-templates select="attribute"/> <xsl:apply-templates select="association"/> <xsl:apply-templates select="operation"/> </xsl:template> A format pattern of a multi-file XSLT is shown below. The difference from the single-file patterns is that different file-outputs are separated within XML file tags. The explanation for the tags is described below the example. <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:output method="xml" indent="yes"/> <xsl:template match="model"> <xsl:apply-templates select="package"/> </xsl:template> <xsl:template match="package"> <package> <xsl:attribute name="name"><xsl:value-of select="@name"/></xsl:attribute> <xsl:attribute name="stereotype"><xsl:value-of select="@stereotype"/> </xsl:attribute> <xsl:apply-templates select="class"/> Page 110 of 123

111 <xsl:apply-templates select="package"/> </package> </xsl:template> <!-- *** template match class --> <xsl:template match="class"> <file> <xsl:attribute name="type">javaclass</xsl:attribute> <xsl:attribute name="filename"><xsl:value-of </xsl:attribute> <xsl:attribute name="location">interfaces/<xsl:value-of </xsl:attribute> <xsl:attribute name="stereotype">interface</xsl:attribute> <xsl:attribute name="extension">java</xsl:attribute> package interfaces; import java.util.*; public interface <xsl:value-of { <xsl:apply-templates select="attribute"/> <xsl:apply-templates select="association"/> <xsl:apply-templates select="operation"/> } </file> </xsl:template> <!-- *** template processattributes --> <xsl:template match="attribute"> public <xsl:call-template name="map2javatype"><xsl:with-param name="orgtype" select="@type"/></xsl:call-template> get<xsl:call-template name="firstuppercase"><xsl:with-param name="input" select="@name"/></xsl:calltemplate>(); public void set<xsl:call-template name="firstuppercase"><xsl:with-param name="input" select="@name"/></xsl:call-template>(<xsl:call-template name="map2javatype"><xsl:with-param name="orgtype" select="@type"/></xsl:calltemplate><xsl:text> </xsl:text><xsl:value-of select="@name"/>); </xsl:template> <!-- **** template processassociations --> <xsl:template match="association"> </xsl:template> <!-- *** template processoperations --> <xsl:template match="operation"> <xsl:apply-templates select="parameter"/> </xsl:template> <!-- *** template processparameter --> <xsl:template match="parameter"> </xsl:template> </xsl:stylesheet> The multi-file properties are defined for each file by the XML file-element which can have the attributes as shown in the XML extract below. <file> <xsl:attribute name="type">javaclass</xsl:attribute> <xsl:attribute name="filename"><xsl:value-of select="@name"/> </xsl:attribute> <xsl:attribute name="location">interfaces/<xsl:value-of select="../@name"/> Page 111 of 123

112 </xsl:attribute> <xsl:attribute name="stereotype">interface</xsl:attribute> <xsl:attribute name="extension">java</xsl:attribute> HERE Goes the Content of the file </file> The attribute type says what kind of target file type this is. Currently, only type= xml or type= xml-file will signify the processing result. A type of xml/xml-file will be attempted processed as an XML-file. The attribute filename signifies the result filename. The attribute location signifies the directory location of the file. The attribute stereotype signifies the stereotype that applies to the file item. This is currently not used. The attribute extension signifies the file extension for the output file Java transformer A UMT Java emitter a Java-class that implements the UMT Transformer interface transformer.transformationengine, which is shown below. public interface TransformerEngine { public void setinputsource (java.io.reader input); public void settransformationimpl (Object impl); public void setoutputdir (String dir); public void dotransformation (); public void addtransformationresultlistener (TransformationResultListener listener); } The simplest way of implementing this interface is to subtype the class transformer.abstracttransformer, which implements all but the dotransformation method. The default input that is sent in a setinputsource call is an instance of a model on XMI Light form. The transformation itself must be implemented in the dotransformation method. In order to add a new transformer (install it) in UMT, the UMT transformation configuration tool can be used. This is described in chapter UMT usage Starting the UMT GUI The UMT GUI is started by running the batch-file run.bat located at the root of UMT installation directory. This will start the tool without in start up mode as shown in Figure 122. Page 112 of 123

113 Figure 122: Newly started UMT When UMT is started, you are ready to import XMI/UML XMI models. The best way of doing so is to associate a project with your model file. It is also possible to open model files without a project context. The left side view default displays an Information View, which provides information about available actions in UMT. You can switch to XMI Light model view by choosing View Windows Xmi Light view from the menu or clicking the hyperlink under remove this view in the Information View. To change the default view to a XMI Light view, open the Settings Preferences menu and change the umt.defaultview property Working with projects Projects are the best way to work with your XMI models. It gives you a way to associate your model with a project context, which can be managed (e.g. control source generation output directory). When opening a project, the associated XMI/XMI Light file will be loaded Creating a project There are two ways of creating a project in UMT, illustrated in Figure 123. From the file menu, you can choose new project or open XMI/XMI Light as new project. Page 113 of 123

114 Figure 123: Creating a new project These two options will both open the dialog shown in Figure 124. The latter will allow you start with finding the file you want to work with. The first will launch an empty create dialog. Figure 124: Create new project dialog When you click the Ok button, a project file will be created in Project Location, associated with the model file selected in Source File. If the selected project location already contains a project file, you will be prompted to overwrite or not. (There can be only one project in a directory). The model file will be loaded, and you are ready to perform transformations Opening a project To open an existing project, choose the File Open Project from the menu. This will launch the project selector (Figure 125), which will allow you to select among the projects and open one of them. The selector dialog shows the names of the projects, and their location. (You may modify the value of the location property in this dialog. This property controls where UMT looks for the project file.) Click the Ok button or press the enter key to open the selected project. Figure 125: Project selector dialog Page 114 of 123

115 After pressing the Ok button, the project s model file will be loaded Deleting a project To delete an existing project, choose File Delete A Project from the menu. this will launch the project selector to delete a project. Also, if a project is opened, you can delete it by choosing File Delete Delete current project from the menu View/edit project properties Associated with each project is a set of project properties, some of which may be modified by the user. The Project tab gives a view of these properties and a means of changing them (Figure 126). Figure 126: Project properties The project properties are ordered in groups, which define a set of properties. The following describes the groups and the properties they contain: Property group Sources Timestamps Target Files Description Refers to the source file of the project (operational) Different time stamps for the project (informational) The name of target files associated with this Properties source_0=the source file path Created, Last opened, Last saved, Previous transformation (name), Previous transformation time Page 115 of 123

116 project (generated in this project) (not used) Transformations The transformations associated with this The names of the associated transformations project (currently only informational to be operational) Dirs Directory settings gendir=the directory to which source files are generated (for multifile generations) Profile Associated profile information Profile name (informational) User Variables User defined variables used for code generation PACKAGE_NAME PACKAGE_PATH Variables file Output file for user variables After opening a project When a project has been opened, the associated model will be loaded and become visible within the UMT model viewer. You are now ready to perform transformations. Figure 127 and Figure 128 shows the UMT gui after loading a project/model with the Information view and XMI Light view, respectively. Figure 127: UMT with loaded model (Information View) Page 116 of 123

117 Forward transformation Figure 128: UMT w. loaded model (XMI Light view) When a project (or an independent model) has been loaded, you can execute transformations available in the Transformations forward transformation menu (Figure 129). You may also mouse right-click on the model tree to launch the transformation menu (Figure 130). Figure 129: Transformation menu Page 117 of 123

118 Figure 130: Transformation menu (2) When choosing a transformation, the transformation engine will execute the associated transformation script/code. The result of a transformation is typically one or more source code files, e.g. one WSDL file or many Java files. When the result is a single file output, the user will be prompted for a place to save the result. When it is many files, these will be placed relative to the gendir property location The Result tab When the transformation is done, you can view the result in the result tab. It shows the files generated and displays their contents (Figure 131 and Figure 132). If the result is not saved to a file, the result tab will still show the produced result, but there will be no associated file. Figure 131: Result tab Page 118 of 123

119 Figure 132: Result tab (several files) To view a file wihtin the result tab, single click on the file name in the list view. To open the file in an external editor, double click on the file name. This will launch an external viewer/editor (default notepad, but this can be modified in the Setttings Preferences menu) Reverse transformation Reverse transformations are available with or without a project context. A reverse transformation loads a source file, e.g. WSDL and generates a model, which in turn can be used for transformations, or just stored as XMI or XMI Light. Reverse transformations are defined in the same way as forward transformations, and become available in tool menu Transformations Reverse transformation (Figure 133). Figure 133: Reverse transformation An example of a reverse transformation is from WSDL to XMI Light Settings Transformations Transformations are added dynamically, through the Settings Transformations menu. This will launch a transformation editor, which allows to add, remove and modify transformations (Figure 134). Page 119 of 123

120 Figure 134: Transformation editor The transformation editor displays the available transformers and allow to view/modify their properties. The following table explains the properties of a transformation: Property Values Description Direction Forward Reverse The direction of the transformation Implementation xslt or java file name A pointer to the implementation of the emitter. Outputtype (used for type xslt) Profile Type singlefile multifile <name of the associated profile or none > xslt java velocity (to be implemented) the output result will be a single file the output will be several files Profile associated with the transformation (not operational) xslt: The emitter is implemented by an XSLT file java: The emitter is implemented by a java class. The emitter is a (set of) velocity template(s). To add a new transformation, launch the create dialog by right-clicking in the list view and choose add (Figure 135). Figure 135: Adding a new transformation Fill out the information in the dialog (Figure 136) and press Ok. A new transformation is created and available for execution from the transformation menus. If needed, the transformation can be edited from the transformation menu after it is created (e.g. to change the transformer script/class). Page 120 of 123

121 Figure 136: Add transformation dialog To remove a transformation, use the remove action from the right-click menu. The edit option will allow you to change its name Profiles Profiles define model concepts and is comparable to a UML profile. A profile in UMT define modelling concepts that is legal within a specific context/domain. It can then be used to check a model, and also to associate with projects and transformations. Profiles can be managed in the profile editor, availble via Settings Profiles menu. The editor is similar to the transformation editor (Figure 137). New profiles can be added/removed/edited by executing and add/remove/edit action from the right click menu in the list view. Figure 137: Profile editor Concepts and types can be added or removed by right-clicking within the property area for the concepts/types, and click the add or remove action (Figure 138). Page 121 of 123

122 Figure 138: Adding a profile concept A concept/type can be modified by editing the name directly or (for the concept), modify the meta type it applies to. Figure 139: Changing a concept Checking a model's consistency to a profile A model can be checked with respect to its consistency with a defined profile. In the example above, a profile can be selected and "used" for the current project/model. It can later be checked by invoking the "Profiles/Check adherence to profile" menu action Preferences UMT preferences can be edited through the preference editor, availble thorugh the Settings Preference menu. There are currently two preferences that can be modified here: Preference Values Description umt.defaultview infoview (defult) modelview The view visible in the right-most pane in UMT. This is either an information view or an XMI Light model view. umt.external.editor Default value is notepad. Can be changed to anything 10.6 Command-line transformations Editor launched in the Result tab for viewing results externally. Command-line transformations is supported through the class umtmain.umtcmdmain. It can also be run through via the (windows) batch-file umtcmd (or provide your own batchfile). The following command-line parameters are allowed/expected to the command-line interface: umtcmd -xmi -xmil -i<input_file> -t<transformation> [-o<output_file>][-d<output_dir>] -l list -s = source type xmi or xmi light. -t = transformation name. -i = input file. Page 122 of 123

123 -o = output directory (optional) (Default is./gen) -l = list available transformations Activity graphs in UMT UML Activity graphs can be read by UMT in the form of XMI for Activity Graphs. XMI 1.1 for UML1.3/UMT1.4 is currently supported. To open an activity graph, choose on the File-menu, open and then XMI Activity UMT summary Figure 140: UMT activity view Further information regarding UMT and the latest available downloads can be found at Page 123 of 123