MDE components specification (Task 4.2)

Transcription

1 MDE components specification (Task 4.2) Michel Brisset SOFTEAM Philippe Desfray SOFTEAM Jason Xabier Mansell ESI Laurent Rioux, THALES Miguel A. de Miguel UPM JC Duenas UPM FAMILIES 17 October, 2005 Abstract: There is no "out of the box" model-driven engineering solution that satisfies each context and fulfills every requirement. Each company who wants to set up an MDE approach has to develop or adapt a metamodel and its related edition, verification, transformation and generation tools as well as process elements. The result of this is a highly strategic Artifact, that we call «MDE Component». This deliverable defines and formalizes the notion of MDE component, identifies different kinds of usage, works on the related methodology, and implements a supporting tool for this. Example MDE/MDA components are moreover developed. Keywords: Model-Driven Development (MDD), Model-Driven Architecture (MDA), Tools Relations: This work is related to the PIM/PSM modelling practices defined in Families Task 4.1, and case studies of Task 4.4. These tasks are a requirements source for Task 4.2. Task 4.4 moreover includes a case study that uses elements of the CCM MDE component developed in Task 4.2. Model transformation aspects of MDE components are retained from Task 4.3 work. References: M. De Miguel, P. Desfray, Adaptation of UML to Specific Domains and Technologies, submitted to the special issue of Science of Computer Programming Journal (Elsevier) on Model Driven Architecture: Foundations and Applications J. Bézivin, S. Gerard, P.A. Muller, L. Rioux, MDA component : challenges and opportunities, workshop "Metamodelling for MDA«, York, United Kingdom, Philippe Desfray, TECHNIQUES FOR THE EARLY DEFINITION OF MDA ARTIFACTS IN A UML-BASED DEVELOPMENT, Enterprise UML & MDA Conference, London, UK - 12 & 13 May, 2004 Philippe Desfray, MDA in practice: Making MDA accessible to the widest range of users and addressing the modelling methodology issue, Journées Internationales ICSSEA 2004 Génie Logiciel et Ingénierie de Systèmes: Wednesday, December 1. MDA component: Packaging the MDA artifacts - Proposal for an OMG RFP: Presentation to the OMG - Athens April 2005 FAMILIES 1

2 Contents Introduction General objectives of the task Chapter 2: Specification of MDE components Chapter 3: Techniques for modelling metamodels and profiles Chapter 4 : Methodology for modelling MDE components Chapter 5 : Connection of MDE component definition and software development methodology MDE Components (Task 4.2) 2 FAMILIES After recalling the general objectives of the task, the notion of MDE components will be specified. Then Chapter 3 will be dedicated to the techniques to be used. Chapter 4 will define a methodology for modeling MDE component: developing MDE components is a specific development task, and has to be supported by a methodology. FAMILIES 2

3 Introduction General objectives of the task (1) define the main features of reusable methodological component, (process components, transformation components, model definitions (domain models or application models) studied in task 4.1 or task 4.3 provide a classification of all potential methodology components, identify what is a reusable methodology component MDE Components (Task 4.2) 3 FAMILIES Within Families, the Task 4.2 has the goal to define and formalize the notion of MDA component, to identify different kinds of usage, to work on the related methodology, and to implement a supporting tool for this. FAMILIES 3

4 GB1 Introduction General objectives of the task (2) provide mechanisms and guidelines in order such methodological component may be composed, implement in a tool the notion of reusable methodology component, provide those elements in models, in order to build a methodology based on reusable component and to provide it in the market (as standard or at least as proposal). MDE Components (Task 4.2) 4 FAMILIES Obviously, MDA Components which are aimed at supporting modeling tasks and methodologies, should be themselves supported by a modeling approach, and by a methodology. FAMILIES 4

5 Diapositiva 4 GB1 The first sentence is not comprehensible; presumably a language problem. Do you perhaps mean "provide mechanisms and guidelines for composing such methodological components"? "In order to" is presumably taken different from its real meaning mch0275a; 19/05/2005

6 Introduction Approach for structuring the work (1) Make a recollection of the techniques necessary for defining and tooling meta-models and profiles. Model transformation technique is one of the necessary techniques Select from these elements the one technically necessary for building an executable and deployable unit (MDE Component) Provide a formal specification of MDE components MDE Components (Task 4.2) 5 FAMILIES Based on the experience of the team, and the other existing experiences, we will first make a recollection, and then provide a formal definition of MDA components. FAMILIES 5

7 Introduction Approach for structuring the work (2) Define the approach and methodology for developing MDE components Specify how MDE components can be exploited in a software development lifecycle, and how the software process is influenced Elaborate on the mechanisms related to MDE component : assembly, deployment and reuse Provide examples MDE Components (Task 4.2) 6 FAMILIES Examples will be provided as a conclusion, and will help to get a precise idea of this notion. The variety of example will demonstrate the wide application cases that can be done with MDA Components. FAMILIES 6

8 Introduction What are MDE components: questions to answer What are the elements to be defined for an MDA approach How can these elements be used in conjunction with a methodology How do we package these elements into autonomous and deployable units How can these elements be specified How can they be interpreted in a tool chain MDE Components (Task 4.2) 7 FAMILIES The MDA component notion shall provide answers to the above questions. FAMILIES 7

9 Goal to reach : A new breed of tool to support the MDA approach Build the assets Thesaurize the assets Quality Engineer Software Architect Methodology Engineer Project manager Know how MDA Modeler Institutionalization & capitalization (Re-)Use the assets MDA Components Diffusion & application Project manager Designer Developper UML Modeler Practice MDE Components (Task 4.2) FAMILIES 8 The MDA Components will be a means to reify the know how in software modeling & development within organizations. This will be supported through two tools: the MDA Modeler which defines them, and the UML modeler which will be able to run them. FAMILIES 8

10 Relationship with other tasks Task 4.1 and 4.3 provide the theoretical foundation for MDA, which is to be reused within the task 4.2. Within Task 4.2, this approach and technology will be used for: Building a MDA Modeler tool and building a CCM MDE component that will support the automated MDE generation. Task 6.2 will use the results of the MDE component definition for standardization purpose within the OMG MDE Components (Task 4.2) 9 FAMILIES FAMILIES 9

11 Chapter 2: Specification of MDE components MDE Components (Task 4.2) 10 FAMILIES This chapter will discuss: What is the purpose of a MDA component? Which data are provided by a MDA component? What is the runtime for a MDA component? FAMILIES 10

12 Chapter 2: Specification of MDE components Context & problem description The interest and importance of the notion of MDE component is clearly identified. However, a complete formal definition is required, in order to obtain a consensus on a basis that can be standardized and supported by tools. What is needed is : Definition and Description of what is a MDA component Elements constituting MDE components Metamodel of MDE Components Integration of MDE components in modelling environment (e.g. editors, repositories, interchange formats) MDE Components (Task 4.2) 11 FAMILIES A complete description of MDA component services and data is required for the standardization and support by tools. FAMILIES 11

13 Chapter 2: Specification of MDE components Objectives Define what is a MDE component As a general purpose notion As an entity that can be supported by tools in a standard and interoperable way Provide an explicit description of what should or may be contained in a MDE component Define general services for MDE components MDE Components (Task 4.2) 12 FAMILIES The main objective is to Identify concepts which compose an MDA component and roles of each one. FAMILIES 12

14 Chapter 2: Specification of MDE components Approach and expected results Find consensus on the notion of MDE component Relate this notion to the general notion of component, and to the context of MDE related artifacts Elaborate Use cases in order to discover the features that a MDE component must encompass Provide a metamodel to support a formal definition MDE Components (Task 4.2) 13 FAMILIES Identify the context, the runtime requirements for MDA component. FAMILIES 13

15 Chapter 2: Specification of MDE components Risks Reach consensus Find a notion general enough to be applicable to any MDE context Integration with current and future modelling tools Alignment to the other WP4 tasks MDE Components (Task 4.2) 14 FAMILIES The major risk is to find a notion that is applicable to every context, and that can be supported by all sorts of tools. FAMILIES 14

16 Chapter 2: Context overview Lesson learned : systems are complex! ATC Networks Simulators C3I SRWS FE Radar NCS 3500 KLO Cs Size Sim NCS FE 2500 Radar ATC Technical challenges Complexity is increasing Domain and technical life cycle mismatch Every 5 years the average size of software projects is multiplied by 5 to Year Economic challenges Competitiveness: reduce development time and maintenance cost, shorten lead time, Improve quality and predictability Size (in KLOC) Organization à Individual Distribution THALES à Small team à Large structured team à Several teams or Units à Several cooperating companies à National initiative or more Lesson: systems are more complex! MDE Components (Task 4.2) 15 FAMILIES Systems are more and more complex. Introduction of new technology is ever faster. We need assets to decrease maintenance cost and reduce development time. FAMILIES 15

17 GB3 Chapter 2: Context overview Lessons learned : No continuum from analysis to implementation! Requirements Breaks Automation: Requirement traçability SSS SSDD SRS Documentation driven process Hand mastered methodology Maintenance and consistency risky SDD Automation: Some code generation Lesson: go towards a seamless development life cycle! MDE Components (Task 4.2) 16 FAMILIES MDA Component environment will have to maintain links between each step of the development process. FAMILIES 16

18 Diapositiva 16 GB3 For some readers it will help understanding if you explain in the Notes page what the abbreviations for the specification documents mean (SSS, SSDD,...) mch0275a; 19/05/2005

19 General technical orientations Define model contents based on standards (UML & profiles) Do not (re)define a full engineering process Build upon existing best practices in the OO/Component field (UP, Y, OPEN processes, Catalysis, ) Focus on the core model engineering activities & key areas in the target MDE/MDA process. Develop the MDE/MDA components as a library of building blocks + for integration into evolutions of the BU standard processes Tailoring guidelines MDE Components (Task 4.2) 17 FAMILIES Reflexive technology: MDA Component used to develop MDA Component! FAMILIES 17

20 GB4 MDA component concept SPEM Producing model A UML OCL Modelling rules for model A Transforming a model M into a model A Generating code or document Patterns from a model A Extensible and customisable component Consistency between technology and methodology Provide guidelines and help ASL J, VB Must be tool independent to capitalise «how-know» at company level MDE Components (Task 4.2) 18 FAMILIES Content of MDA have to expressed with existing and standard language (as mush as possible). FAMILIES 18

21 Diapositiva 18 GB4 "to capitalise «how-know" - The wording is "to capitalize on"; and what is "how-know"? Do you mean "know-how"? mch0275a; 19/05/2005

22 Reusable Asset Specification: Standard OMG RAS: A standard container for reusable Assets METADATA Standard Proprietary files: - ROSE file, XMI, - Pictures (Jpeg, bmp,..) - Documentations (doc, txt, ) - code (java, c++, ) -Scripts (VB, J, Java, ) MDE Components (Task 4.2) 19 FAMILIES RAS is a solution for MDA Component packaging. It s well compromised between standard and proprietary standard. FAMILIES 19

23 MDA RAS = MDA Component GB5 METADATA Standard MDA component Process model (SPEM2) Metamodel with OCL constraints Models transformations Proprietary files MDA RAS or MDA Component has to be based on OMG standards: Tool independency MDE Components (Task 4.2) 20 FAMILIES FAMILIES 20

24 Diapositiva 20 GB5 Change in 4th box: "models transformations" to "model transformations" (delete the s). mch0275a; 19/05/2005

25 Constitution of a MDA component cmd1 cmd2 MDA Component <<P>> <<P>> Metamodels or UML profiles, constraints, model transformations, behavior cmd3 <<P>> FileC FileB FileA Resources (help, icons, executables libraries, ) Invocation points (commands, notifications ) MDE Components (Task 4.2) 21 FAMILIES See next slide FAMILIES 21

26 Elements of an MDA component Definitions of models, ( metamodel, profile); Consistency rules (implemented by e.g. Java, J,OCL, etc.); Model transformations (implemented by e.g. Java, J, QVT); Functionalities or behaviour attached to the model definitions; Predefined lifecycle interface implementation (load, run, etc.); Provided Services connected to end user interactions; Required Services: services requested from the environment; Deployment parameters: options customizing the MDA component; Resources for the execution of the MDAC (libraries, icons, etc.) Other elements such as design documentation and models, tests, etc.; Elements related to the distribution policy, such as the licensing scheme, or the protection of MDA component sources. MDE Components (Task 4.2) 22 FAMILIES MDA Component have to provide required elements to build complete and consistent models: by modelling activity or transformation. MDA Component is a standalone artifact. FAMILIES 22

27 MDA component Metamodel Model * * Specification * base Appliance * applied 0..1 MDAComponent 0..1 SourceAndTarget subject ModelSpecification * packaging * Packaged interaction * Resources&Artifacts MetaModel UMLProfile * part Service kind : ServiceKind 0..1 * support Documentation Behavior 1 invoked * implementation 1 * usageprocess 0..1 invocation * * options ProcessDescription InvocationPoint ConfigurationParameter JavaCode JCode QVT Command EventReceipt MDE Components (Task 4.2) 23 FAMILIES Here is the abstract metamodel of MDA components. MDA Component is the central notion, which aggregates all the elements that shall be packaged with it. FAMILIES 23

28 MDA Component: Can be a composite MDA Component <<MDA_C1>> UML Profile and process definitions cmd1 cmd2 Producing model A Modelling rules for model B Cmd3 <<MDA_C2>> Producing model A External interfaces (for the UML modeler, for the end user, Modelling rules for model A Transforming a model M into a model A Resources (help, icons, external executables, ) MDA components should be extensible MDE Components (Task 4.2) FAMILIES 24 MDA Component may be defined according to another MDA component by extension or use. FAMILIES 24

29 What do we expect? Process and tool teams Development teams MDE/MDA Modeler UML Modeler tool with MDE/MDA services Model Bus (EMF, XMI ) Subprocess Modelling rules Mapping Techniques MDE Components (Task 4.2) FAMILIES 25 MDA components are developed by «experts», packaged, and deployed and used by end users. FAMILIES 25

30 MDE/MDA toolsuite : two sets of tools MDE/MDA Modeler MDA ComponeAt MDA Component MDA Component MDA Component MDA Component MDA Component MDE / MDA Service s UML Modeler tool Model Bus (EMF, XMI ) Modelling rules Subprocess Mappings Generation Patterns embodies MDA Component MDE Components (Task 4.2) 26 FAMILIES This separation between expertise and usage exists at the tool level between MDAC definition tools and MDAC runtime. FAMILIES 26

31 Chapter 3: Techniques for modelling metamodels and profiles MDE Components (Task 4.2) 27 FAMILIES FAMILIES 27

32 GB6 Chapter 3 : Techniques for modelling metamodels and profiles Context & problem description This chapter summarizes the results of work package 4.1, in order to exhaustively identify the artifats and techniques that shall be encompassed by MDE components Profiles and Metamodel definition Model transformation definitions MDE Components (Task 4.2) 28 FAMILIES Model driven development uses two basic solutions to solve these problems: i) description of specialized modeling languages and ii) model transformations and mappings. Currently, the first concept (description of specialized modelling language) has been supported with two different approaches: metamodels that use modeling notations for the description of new modeling elements, and profiles that are the extension approach of UML. FAMILIES 28

33 Diapositiva 28 GB6 "This chapter should summarize ": don't write what the chapter should do; instead, write what it does! mch0275a; 19/05/2005

34 GB7 Chapter 3 - Techniques for modelling metamodels and profiles Objectives Ensure that MDE modeling is a consistent packaging mechanism that covers every necessary MDE related technique Assemble and package Metamodels, Profiles, and model transformation code. MDE Components (Task 4.2) 29 FAMILIES MDE integrates different concepts that must be maintained consistent and it provides support for packaging all these concepts. A fundamental objective of MDA component is to provide a model of MDA component that can be extended and can be support the assembly of different MDA components. FAMILIES 29

35 Diapositiva 29 GB7 The heading overlaps the Families logo mch0275a; 19/05/2005

36 Chapter 3 - Techniques for modeling metamodels and profiles Approach and expected results Do an inventory of the targeted techniques, based on task 4.1, task 4.3 and the OMG standards Sort out the techniques deemed necessary for MDE component deployment MDE Components (Task 4.2) 30 FAMILIES FAMILIES 30

37 GB8 Chapter 3 - Techniques for modeling metamodels and profiles Risks Convergence of the QVT standard Consistency of QVT, profiles and metamodels MDE Components (Task 4.2) 31 FAMILIES MDA component combines several concepts that have been developed and proposed in parallel. The integration of these standards requires some adaptations that depend on their evolution. Some basic standards such as QVT are developed in parallel to this proposal. FAMILIES 31

38 Diapositiva 31 GB8 The heading overlaps the Families logo mch0275a; 19/05/2005

39 GB9 UML: a semi-formal Language (Non-Strict Semantics) UML is a general modeling language that can be applied in very different domains, development phases, or technologies Domain extensions Methodological adaptations Technical extensions Technological extensions Each adaptation requires to extend and restrict the UML semantics for the specific domain Most of them are complex concepts that require complex notations for their description UML is a Family of Languages MDE Components (Task 4.2) 32 FAMILIES An MDA component provides support for the definition of modelling extensions and specification of transformations. Examples of types of extensions are: i) Domain extensions. Examples of domains for the application of UML modelling are: telecom, e-commerce and healthcare. These domains use specific modelling structures and methods and require specialized modelling elements to improve description domain dependent concepts. ii) Methodological adaptations: There are several practices and approaches to using UML during each development phase. For example, Use Case modelling for requirement analysis is supported by various approaches, Extreme Programming can use UML in a specific way. Each phase such as analysis, design, programming and tests can be realized using UML, and be supported by a specific methodological approach. Dedicated extensions, consistency checks, and model transformations can be provided at these stages. iii) Technical extensions. Some common techniques are used in different domains. Some examples are: real-time, fault-tolerance, transactions and security. These techniques require UML extensions to represent technical concepts not supported in UML (e.g., specific temporal properties and complex identification methods). The technical concepts have associated specific types of architectural concepts (i.e., distributed executions). iv) Technological extensions. These extensions provide support to express in UML specific programming language and middleware concepts. Some examples are the profiles to express in UML, EJB (Enterprise Java Beans) and CORBA concepts. These types of extensions and their associated transformations can include complex concepts that require a methodology for their construction. FAMILIES 32

40 Diapositiva 32 GB9 The heading overlaps the Families logo mch0275a; 19/05/2005

41 Solutions to Put In Practice MDA (1) Languages for Modeling: Meta-Modeling Frameworks for the description of modeling notations OCL as query language Support of repositories, models interchange and management Profiling: Profile Builders for the construction of Profile models Description of Stereotypes and attributes Relations of stereotypes: extension of metaclasses, stereotype inheritances, associations to metaclasses and stereotypes MDE Components (Task 4.2) 33 FAMILIES Languages for Modeling. Several research groups and companies propose meta-modeling frameworks. The facility comprises a language for defining modeling notations, a tool that checks and executes those definitions, and a method consisting of a model based approach to language definition. Mappings between language components are defined in terms of OCL constraints on associations between model elements. Profiling. Some tools such as Objecteering provide support for the description of UML profiles (Profile Builder). The profile description includes the specification of Stereotypes and Tagged Values and the UML meta-classes associated with these extensions. The profiles are supported and handled with modules. A module can include commands applied to model elements. These commands implement the transformation of models. They are scripts in a proprietary language (J language). J provides support for the creation of new diagrams and model elements. The commands support transformations from model to model, or from model to code or documents. Objecteering provides traceability support to avoid inconsistency between the model source and the model or code destination. FAMILIES 33

42 Solutions to Put In Practice MDA (2) Execution of Models: Execution of Models at Meta-Model Level Execution of UML models (e.g., ASL) OCL Evaluators: Validation of Well-Formedness Rules at Meta- Model Level Meta-Models and UML profiles have OCL constraints Verification of Meta-Model instances Specification of states of evaluation MDE Components (Task 4.2) 34 FAMILIES Execution of Models. Some tools and OMG groups looks for the definition of an UML semantic that supports the execution of models. The iuml simulator provides an execution environment in which models can be executed and supports Action Specification Language (ASL). iuml supports pre-defined mappings to platform specific implementations, and the definition of user configurable mappings from PIM to specific implementations. The mappings are specified using executable UML models that represent the source and destination meta-models. In this approach, meta-models and ASL support the mappings, and the execution of UML models at meta-model level implements the transformations. OCL Evaluators. Many academic and industrial frameworks give support for the validation of UML models and OCL constraints. These tools do not address the problems of model mappings and UML extensions but propose solutions for the validations of OCL constraints. These approaches are solutions for the validation of OCL constraints in mappings and meta-models. FAMILIES 34

43 UML Profile vs UML Meta Models: Two Different Approaches to Extend UML Profile: package that contains model elements that have been customized for a specific domain using stereotypes, tagged definitions, constraints model libraries metamodel subset that it extends MetaModel: A metamodel that extends another metamodel with new modeling elements MetaModel Standard UML Semantics Profile MDE Components (Task 4.2) 35 FAMILIES Metamodels and profiles historically have been considered alternative solutions for the description of modeling extensions. Both have advantages and disadvantages. In our approach we consider both complementary and we try to combine both. FAMILIES 35

44 Specification of Correspondence Between MetaModels and UML Profiles (1) <<QoSCapability>> NetworkQoS Meta-Model: Significant Concepts of Domain Problem ::MDA Metamodels::QoS::RTResourceModeling::CoreResourceModel::QoSValue instance * 1 type <<QoSCharacteristic>> QoSNetworkQuality QoSRate DeliverationDelay 1 QoSGuarantee 1 <<QoSCharacteristic>> <<QoSCharacteristic>> <<QoSCharacteristic>> QoSGuaranteeLevel QoSRateFlowSpec QoSLatencyS erviceprovided <<QoSValueDefinition>> +QoSLevel : QoSLevels <<QoSValueDefinition>> <<QoSValueDefinition>> {order(decremental)} +TokenRate : integer +Latency : integer {order(incremental), {order(decremental), ofunit(bytes/sec)} ofunit(microsecond)} <<QoSValueDefinition>> <<QoSValueDefinition>> +TokenBucketSize : integer +DelayVariation : integer {order(incremental), {order(decremental), ofunit(bytes)} ofunit(microsecond)} <<QoSValueDefinition>> +PeakBandwidth : integer {order(incremental), ofunit(bytes/sec)} ::MDA Metamodels::QoS::RTResourceModeling::CoreResourceModel::QoScharacteristic <<metaclass>> QoSValue <<metaclass>> QoScharacteristic Links 0..1 Type Describes 1 Describes Typed * 1..* DescribedBy Linker * 1..* Slot <<metaclass>> <<metaclass>> QoSValueDefinition * evaluate QoSValueDefinitionLink order : RelationOrder value 1 Value : undefined ofunit : string UML Profile: Modeling Language UML + Extensions MDE Components (Task 4.2) 36 FAMILIES The metamodels are good tools for the description of domain and technical concepts. This method has not a direct dependency on the base modeling language and is easier to describe the new concepts. But their integration in UML modeling frameworks is complex. FAMILIES 36

45 Phases for Modeling Extensions Construction Conceptual Models: A conceptual model is a simplified representation of new concepts that the models can include Metamodels: Abstract Syntax and Semantic. The metamodel defines a new modeling language that, often, is integrated with other metamodels Profiles: Concrete Syntax. Approach for the description of modeling notations based on UML model elements Mapping From UML+Profile to Metamodel: Integration of semantics, combination of two extension methods Transformations: the automatic transformation reuses the software development knowledge. MDE Components (Task 4.2) 37 FAMILIES In this task we have defined a set of phases useful in the construction of UML extensions and for their integration in a MDA component. The basic phases for the construction of a complex UML extension are: Conceptual Models. A conceptual model is a simplified representation of new concepts that the models can include. The concepts are extracted on the basis of an analysis of the domain, technique or technology that the extension is going to support. Metamodels. The conceptual model must be precise but it is not fully formal. Its purpose is to describe the concepts that support the new modeling language. The metamodel is formal and is described with metadata management frameworks. Profiles. A profile defines limited extensions to a reference meta-model with the purpose of adapting the meta-model to a specific platform or domain. The notion of reference metamodel (the UML metamodel in our case) is key in the profile mechanism. The metamodel describes the abstract syntax of the language that supports the extensions. The UML profile is a solution for the representation of these concepts in a concrete syntax in a UML modelling environment. Mapping for Two Languages that Represent the Same Concepts. The metamodel and the profile mechanisms establish two modelling languages that represent the same concept. The profile provides the integration of extensions into UML tools and the metamodel represents a metadata repository, and provides support for interoperability and manipulation. The mapping is a tool to resolve the inconsistencies of both languages and provides support for the transformation of concepts from two different view points: UML language and extensions, and the modelling language that defines the extension metamodel. FAMILIES 37

46 Conceptual Models A conceptual model is an analysis model to identify the concepts to be included in the new language. It includes concepts extracted on the basis of an analysis of the domain, technique or technology to be supported. Often, technological extensions (e.g. middlewares) are well specified and do not require this model. We need a conceptual model, when the concepts of the extension are imprecise. MDE Components (Task 4.2) 38 FAMILIES Sometimes this specification is not required. Often, technological extensions are based on concepts well specified in programming languages or programming supports such as middlewares. In these cases, the specification is precise, often expressed in a BNF form, and a new model would be redundant. We need a conceptual model, when the concepts of the extension are imprecise or when there are disagreements on the notions to support. When we build technical or domain extensions, we must model the concepts and the specific dependencies that the new extension supports. A conceptual model sums up the new concepts and dependencies. The conceptual model concretizes the concepts that the model represents. The conceptual model is not part of a MDA component, but it includes the analysis results for the development of MDA components. FAMILIES 38

47 MetaModels The Metamodel defines the modeling elements that represent the concepts that include the conceptual model It represents the abstract syntax of a modeling language <<metaclass>> QoSValue <<metaclass>> QoSContext Supports * <<metaclass>> QoSConstraint The metamodel includes the OCL well-formed rules The new modeling elements can make reference to other metamodels MOF models specify the metamodels * ValidValues Evaluates IncludedIn * * 0..1 Context 1..* Includes * Context * BasedOn <<metaclass>> QoSCharacteristic MDE Components (Task 4.2) 39 FAMILIES The metamodel is formal and is described with metadata management frameworks[1], which provide services to enable the development and interoperability of models. These services include the interchange and manipulation of metadata. The metamodel defines a new modelling language that, often, is integrated with other metamodels. The metamodels can be used not only for the description of modeling elements, but for the definition of metadata repositories that can be used as interchange format between tools of this domain or technique. The modelling language definition includes two main specifications: abstract syntax and semantics. The abstract syntax defines the modeling entities and their relationships. The meta-metamodeling language provides support for the description and management of abstract syntax. The well-formedness rules specify semantic concepts. The semantics concrete some meanings of abstract syntax and their consistencies. OCL (Object Constraint Language) is the UML language for the description of well-formedness rules. The specification of new languages with metadata management frameworks and OCL automate tasks of manipulation, interchange and verification of consistency. But we also need a concrete syntax to represent the modeling elements. The UML profile mechanisms reuse existing tools and avoid learning a new concrete syntax. The metamodels have important advantages, but their limitation is their integration with tools for the model edition and the definition of concrete syntax. UML profiles are a solution to this problem in the UML context. The metamodels solve the flexibility limitations of UML profiles and can be used as input specification for the profile construction. In addition, UML provides a comprehensive set of modeling techniques, which as a standard are known and shared by a vast community. If the model that we are defining reuses many aspects of already known modeling techniques (data modeling, process modeling, state modeling, component modeling, deployment modeling, etc.) then UML is a great basis to be reused that facilitates the learning and exchange of the new extensions. FAMILIES 39

48 UML Profile UML profiles represent <<metaclass>> ::UML::Classes::Kernel::Package the modeling elements included in metamodels <<metaclass>> ::UML::Classes::Kernel::Feature based on extended UML unit : string modeling elements <<metaclass>> ::UML::Classes::Kernel::Class It represents a concrete <<metaclass>> syntax of modeling ::UML::AuxiliaryConstructs::Templates::Classifier language based on UML The profile includes the OCL well-formed rules. This depends on metamodel well-formed rules and UML modeling extension Annotated Profile models specify the profiles <<stereotype>> QoSCategory <<stereotype>> QoSDimension statisticalqualifier : QoSStatisticalAttribute direction : DirectionKind <<stereotype>> QoSCharacteristic isinvariant : boolean MDE Components (Task 4.2) 40 FAMILIES The notion of reference metamodel (the UML metamodel in our case) is key in the profile mechanism. It expresses that the profile based extension cannot change the reference metamodel, and must keep its semantics. Therefore, extending UML by a profile guarantees that the extended model is still a legal UML model. It also guarantees that the extended model will be exchangeable between various UML tools, which will at least exchange the UML part of the extended model. Profile extensions can be applied, retracted and combined dynamically and at will to existing models. UML Profiles are packages that structure UML extensions. The UML provides a rich set of modelling element, which are however general purpose modeling concepts. The UML profile builtin extension mechanism enables adding new kinds of modelling elements that specialize UML for a specific purpose. The principal extension mechanism is the concept of stereotype. Stereotypes are specific metaclasses, having restrictions and the specific extension mechanism. Additional semantics can be specified using Stereotype features ( attributes in UML2.0, tagged values in UML1.x, and operations in UML2.0) and new well-formedness rules in the context of a profile. The construction of a UML profile must consider the integration of UML and the new modelling elements as a basic activity. In a profile definition we must look for: i) a subset of UML to represent the new concepts, ii) the constraints that apply to this subset according to the specific extension domain, iii) the identification of a set of stereotypes and tagged values that add extensionspecific information to the model elements, and iv) the identification of a set of predefined modelling elements to be included by any model based on this extension. A UML profile extends parts of the UML metamodel in a constrained way. All new modeling concepts must be supported by UML modelling elements. The new attributes must respect the semantic of UML modelling elements. All associations are binary associations. We cannot redefine features, but we can add new features (meta-attributes stereotypes). UML metaclasses are extended by stereotypes, using a mechanism called extension. The semantic of metaclass generalization and stereotype extension must not be confused. A stereotype cannot generalize a metaclass. It can only extend it. Extension means that at any time, an instance of an extended metaclass can be extended by an instance of the stereotype. This by essence provides Eureka Σ! the 2023 flexibility Programme, of the ITEA UML project profile ip02009, mechanism: an existing UML model can be extended by a profile FAMILIES 40 at any time; several profile extensions can be combined; and a profile extension can always be

49 GB10 Mapping From UML+Profile to Metamodel UML+Profile and Metamodel are two modeling languages that represent the same concept This mapping specifies how to express modeling elements of metamodel based on UML+profile This mapping between abstract syntax and concrete syntax is based on profiles UML Profile: Modeling Language UML + Extensions Q oscharacteristicstp /Q oscharacteristic:stereoty p e stereotype extendedelement O nec h aracteristic/:c lassifier classifier sp ecifiedend ow ner sp ecification associationend CharacteristicA sso/:a ssociationend feature extendedelement C haract eristicd efin itio ns/:a tt rib ute attribute extendedelement stereotype stereoty p e Q o SD efinit ionvaluestp /Q osd efinit ion Value:St ereot y p e V alu es /:Q o S V alu e instance type Values/:Instan ce inst an ce linkend ValueL inks/:lin ke nd slot DefinitionLinks/:A ttributelink O nec haracteristic/:q oscharacteristic Links D e s c rib e s D e s c rib e d B y D e s c rib e s Linker C h arac t eris t ics D efin it io n s /:Q o S V alu ed efin it io n evaluate value D escribedby ValuesD efinitionlinks/:q osvalued efinitionlink evaluate value C h aract eris t icd efl in k s /:Q o S V alu e D efin it io n Meta-Model: Significant Concepts of Domain Problem MDE Components (Task 4.2) 41 FAMILIES The metadata of a model defined by the metamodel is a set of instances of metaclasses included in the metamodel. The metadata of a model that uses the UML profile includes: i) a set of instances of metaclass Stereotype and the UML elements included in packages that import the profile package, ii) a set of instances of UML metaclasses that represent the specific model elements of this model, and iii) a set of association between the extension instances and the specific model elements. The definition of a mapping between both languages integrates both approaches and allows the description of the same concepts with alternative solutions. The mapping is a model transformation from UML profile to metamodel. The source modelling language is the UML metamodel plus a set of predefined modelling elements, and the target language is the new metamodel. FAMILIES 41

50 Diapositiva 41 GB10 Lower right corner: Problem -> Problems mch0275a; 19/05/2005

51 Specification of Transformations (1) PIM: EDOC Component Profile PSM: CORBA Profile <<BusinessEntity>> Account <<UniqueId>> number : integer balance : real <<CORBAInterface>> 1 AccountInstanceManager manager create_account() * <<CORBAInterface>> Account number : sort balance : float MDE Components (Task 4.2) 42 FAMILIES This is an example of model transformation. In this example we transform a specific class of a PIM model described based on EDOC into a pair of classes and their relations of PSM model, annotated with CORBA profiles. FAMILIES 42

52 Specification of Transformations (2) <<BusinessEntity>> Account <<UniqueId>> number : integer balance : real What is the Expression to represent? BusinessEntityStp/BusinessEntity:Stereotype Name=BusinessEntity stereotype extendedeelement UniqueIdStp/UniqueId:Stereotype BusinessClass/:Class Name="UniqueId" owner stereotype owner feature extendedeelement feature Id/:Attribute Others/:Attribute A collaboration of UML metamodel roles and OCL constraints type IdType/:Primitive MDE Components (Task 4.2) 43 FAMILIES UML diagrams can model this mapping. These diagrams represent the rules of transformation of models and their sequence of execution. Each rule of transformation represents the transformation of a modelling template of source language into a modelling template of target language. Composite structure diagrams that represent the templates describe the queries and constructors for the source and target languages. OCL expressions generate values for attribute values of new objects, and activity diagrams model the sequence of application of rules. We will detail this specification method in the next section. QVT will provide support for the description of these type mappings. In our current works we have used UML for the specification of these transformation and script languages that are used for implementation purposes. In the near future QVT implementations will provide a good framework for the construction of transformations directly in UML. FAMILIES 43

53 Specification of Transformations (3) GB11 And what is the Expression to represent <<CORBAInterface>> 1 * <<CORBAInterface>> Account? AccountInstanceManager manager number : sort create_account() balance : float CORBAIntStp/CORBAInterface:Stereotype Name=CORBAInterface SpecificId/:Attribute Name=context Id : Attribute inv : self.name; create/:operation Name=context BusinessClass : Class inv: "create_".concat(self.name); feature extendedeelement Manager/:Class Name=context BusinessClass : Class inv: self.name.concat("instancemanager"); ManagerAsoManager/:AssociationEnd Name="manager" owner participan specificant stereotype connection ManagerAso/:Association stereotype extendedeelement Specific/:Class Name=context BusinessClass : Class inv: self.name; connection participan owner specificant feature ManagerAsoSpecific/:AssociationEnd owner SpecificOthers/:Attribute Name=context Others : Attribute inv: self.name; feature A collaboration of UML metamodel roles + OCL expression MDE Components (Task 4.2) 44 FAMILIES Patterns and extended modeling elements can be represented as a collaboration based on UML metamodel. We can define collaborations of object instances of UML metaclasses. These objects represent model elements of applicable models. The collaborations represent patterns of modeling concepts that we want to transform. The collaborations represent the patterns that we want to transform from source models, and the new modeling elements in the target model. Sometimes we need to identify specific properties of object instances of metaclasses to distinguish the objects that are candidates for transformations (e.g. specific names of classes or attributes), and we need to represent expressions for the generation of values for the attributes in generated model elements. OCL can be used for the generation of these values and for the construction of precise queries. FAMILIES 44

54 Diapositiva 44 GB11 The text in the lower figure is very hard to read. Is there a chance to increase the font size? mch0275a; 19/05/2005

55 Chapter 4 : Methodology for modelling MDE components MDE Components (Task 4.2) 45 FAMILIES FAMILIES 45

56 Chapter 4 : Methodology for modeling MDE components Context & problem description Developing MDE components will become a more and more frequent task. That activity is very close to the usual software development activity, but is guided by the context and the result to be provided. It is expected that guidelines, dedicated lifecycles, typical deliverables (documents, MDE components) must be detailed and supported. In supporting the software development, a MDE component must itself be developed on a high quality standard level. MDE Components (Task 4.2) 46 FAMILIES By itself, the development of an MDA component can be a complex development. We have cases where several man years have been required to obtain an MDA Component.A development methodology is therefore required. FAMILIES 46

57 Chapter 4 : Methodology for modeling MDE components A component based development approach An MDA component is after all a component Its development and deployment approach shall follow the rules for developing and deploying a component In particular, the work should be structured and packaged so as to provide an autonomous component that contains all necessary material for: Using it Understanding it Maintaining it Testing it MDE Components (Task 4.2) 47 FAMILIES As every component based approach, a methodology shall be applied. The packaging of the MDA Component will be derived from the methodology. FAMILIES 47

58 Chapter 4 : Methodology for modeling MDE components STEP 1 : Do the Glossary of the domain Building the glossary is a fundamental step to freeze and clarify the terminology MDA components target specific platforms, specific development approaches. They generally have a pre-defined glossary that is worth to reuse The glossary will then be used to provide names within the MDA component model, to manage traceability between terms and the MDA component model, to measure the coverage, etc. The Glossary should be established by people who are not the developers of the MDAC, but by domain experts. MDE Components (Task 4.2) 48 FAMILIES FAMILIES 48

59 Chapter 4 : Methodology for modeling MDE components STEP 2 : Do the requirement analysis MDA components very often have to fulfill non functional requirements, and to abide by requirements related to platform coverage, GUI, provided wizards, error reports, etc. Each requirement shall be identified, documented, managed and traced to parts of the MDA component model. The requirement analysis is the major step, which must be reviewed and accepted by the project manager and external stakeholders MDE Components (Task 4.2) 49 FAMILIES FAMILIES 49

60 Chapter 4 : Methodology for modeling MDE components STEP 3 : Do the Use Case model A Use Case model shall be defined The Use case model is deduced from the requirement analysis. It also very frequently follows similar patterns between different MDA components: for example 2 code generators for different targets provide similar functionalities. The Use case model shall be reviewed by the project manager and external stakeholders MDE Components (Task 4.2) 50 FAMILIES FAMILIES 50

61 Chapter 4 : Methodology for modeling MDE components STEP 4 : Do the Conceptual Model The conceptual model is the model of the notions that will be supported by the MDA component It is made by a Class diagram Its construction is independent of the upcoming metamodeling techniques, such as building a MOF metamodel, or a UML profile The metamodel should be traced to: the dictionary, the requirements and the Use Case model. MDE Components (Task 4.2) 51 FAMILIES FAMILIES 51

62 Chapter 4 : Methodology for modeling MDE components STEP 5 : Do the Detailed Analysis Based on the use cases, the conceptual model and the requirements, the detailed analysis shall define in detail the tool support that the MDAC will provide. It will detail the GUI of the tool It will describe each functionality of the tool It will specify the mapping between the model and the target models or platforms if applicable It will provide the consistency rules that will be checked by the tool It will give the structure of the artifacts produced by the MDAC (documentation, code, etc.) MDE Components (Task 4.2) 52 FAMILIES FAMILIES 52

63 Chapter 4 : Methodology for modeling MDE components STEP 6 : Do the Design The metamodel or the profile is modeled The different techniques for implementing the MDAC are described The operations, templates, libraries, that will be realized are identified The model is structured into packages and / or profiles The MDAC packaging and deployment is modeled and specified The interaction points between the external environment and the MDAC are defined The global parameters that provide the global options and the environment specific configuration are defined. MDE Components (Task 4.2) 53 FAMILIES FAMILIES 53

64 Chapter 4 : Methodology for modeling MDE components STEP 7 : Do the Implementation The metamodel or profile implementation is directly obtained from their model The different behaviors of the model have to be implemented as operations defined on the metaclasses or stereotypes Template technique, pattern definition techniques can be combined with the operation implementations. Tests shall be conducted in parallel with the development, and shall be easily run for non regression purposes Note : the User manual should be prepared after the analysis step, and finalized during the implementation step MDE Components (Task 4.2) 54 FAMILIES FAMILIES 54

65 Chapter 4 : Methodology for modeling MDE components STEP 7 : Do the Implementation (2) The development shall be organized into predefined areas as presented below Define the metamodels or the profiles under specific packages Implement the behaviors (transformations rules, and other functionalities) in separate packages using the chosen implementation techniques Develop test models separately under dedicated packages Organize the definition of commands, parameters, into separated areas (packages) Reference explicitely the metamodel extended if any (e.g. UML2.0) MDE Components (Task 4.2) 55 FAMILIES FAMILIES 55

66 STEP 7 : Do the Implementation (3) Objecteering5.2.2 <<referencedm etamodel>> <<referencedprofile>> M DAComponent Profile Predefined areas help the development of MDA components The deployment of MDA component is modeled : referenced profiles or metamodels, MDE Components (Task 4.2) 56 FAMILIES Here is an example of MDA Component modelling: The MDA Component packages the profiles which it references. FAMILIES 56

67 Chapter 4 : Methodology for modeling MDE components STEP 8 : Do the Validation The deployed MDA component shall be completed The user manual shall be at least in a draft state The validation shall be conducted by people aware of the targeted domain (platform, methodologies, etc.) MDE Components (Task 4.2) 57 FAMILIES MDA Component is a product to be delivered. Its industrialization is a required step. Therefore, validation is an important matter. FAMILIES 57

68 GB12 Chapter 5 : Connection of MDE component definition and software development methodology MDE Components (Task 4.2) 58 FAMILIES FAMILIES 58

69 Diapositiva 58 GB12 The heading text overlaps the Families logo mch0275a; 19/05/2005

70 Families Task 4.2 CWD Extended Abstract Global software development process and MDE component for project management - Definition of a global software process based on SFE and MDE - MDE component for planning project management Jason.Mansell, Xabier Larrucea Jason.Mansell@esi.es, Xabier.Larrucea@esi.es FAMILIES 17 October, 2005 FAMILIES 59

71 Introduction & Problem Description Lack of methodology for guiding projects on model driven software development and its application to product families Software development companies are widely characterised for delivering their SW applications late, out of budget and lacking part of the initially defined functionality. No mechanisms available to provide accuracy of project management estimations for system families using a Model Driven Engineering approach MDE Components (Task 4.2) 60 FAMILIES Many methodologies for software development have been developed to guide and to improve software projects. However model driven software development is still a parentless methodology in itself and of course in its application to product families. Software companies are widely characterised for delivering their products late, out of budget and lacking part of the initially defined functionality. Establishing a Standard Software Process (SSP), organisations can manage more efficiently their software development. In addition the SSP is a key element in the set of steps necessary to achieve the first levels of CMM. The usage of SPEM (Software Process Engineering Metamodel) to describe a software process allows stakeholders to represent in a standardised way processes using a friendly nomenclature. FAMILIES 60

72 Introduction & Problem Description There is a need to move towards an industrial software development discipline Use a defined software development process which is automated as much as possible and followed by all individuals and projects Apply product family engineering to software development in order to take advantage of past experiences rather than re-inventing the wheel every new project. No mechanism available to define feasible plans (in terms of effort, cost and time required) based on good estimation data and techniques MDE Components (Task 4.2) 61 FAMILIES FAMILIES 61

73 Approach & Expected Results Define a Standard Software Process (SSP) for developing software systems using a Model Driven Engineering (MDE) and System Family Engineering (SFE) approach Model Driven Engineering (MDE) good practices Domain Engineering main view Application Engineering SFE & MDE standard software process System Family Engineering (SFE) good practices MDE Components (Task 4.2) 62 FAMILIES FAMILIES 62

74 Approach & Expected Results The purpose of the SF & MD SSP is to describe and to organise the software engineering activities necessary to produce a software product that belongs to a system family, using a Model Driven Architecture approach. The basic goals of the process are: To define the software engineering tasks that ensure the production of good quality software systems. To maximise reusability of domain assets by applying a system family engineering approach to software development. To protect business investments and increase productivity both at development and maintenance time by applying a model driven engineering approach. MDE Components (Task 4.2) 63 FAMILIES FAMILIES 63

75 Global Standard Software Process Objective How to develop a Model Driven Development (MDD) process: Activities to develop a Standard Software Process (SSP) based on a model driven approach Model Driven Software Process (MDSP) prototype to support the definition of the process. MDE Components (Task 4.2) 64 FAMILIES FAMILIES 64

76 Global Standard Software Process The objective is to describe a standard software process (SSP) that guides the execution of software projects in organizations that follow a model driven engineering and system family engineering approach for their software development activities: Process purpose and goals, which describe the objectives of the process. Process phases, which provide an overview of the main phases to execute the process. Process workflow, which describes the logical flow of work and information (work products) from phase to phase. Process work products, which provide a brief description of the process input and output work products. Process roles, which describe the roles that perform different process activities. Detailed description of process phases, which provides a decomposition of each phase in lower level tasks/activities and describes them MDE Components (Task 4.2) 65 FAMILIES The objective is to describe a standard software process (SSP) that guides the execution of software projects in organizations that follow a model driven engineering and system family engineering approach for their software development activities: Process purpose and goals, which describe the objectives of the process. Process phases, which provide an overview of the main phases to execute the process. Process workflow, which describes the logical flow of work and information (work products) from phase to phase. Process work products, which provide a brief description of the process input and output work products. Process roles, which describe the roles that perform different process activities. Detailed description of process phases, which provides a decomposition of each phase in lower level tasks/activities and describes them. FAMILIES 65

77 Global Standard Software Process Activities to develop a Standard Software Process (SSP) based on a model driven approach: Identify architectural (platform) models (layers) Identifying architectural levels (levels of abstraction) from CIM to PSM: Computational Independent Model: In this model the system structure is missed. The main functionality is to bridge the gap between domain experts and design experts. Platform Independent Model: this model contains the system functional information necessary to describe completely the system without platform details. Platform Specific Model: this model represents the PIM enriched with specific platform information. MDE Components (Task 4.2) 66 FAMILIES FAMILIES 66

78 Global Standard Software Process Identify Metamodels for each level: this task is tightly related with Identify architectural models task. Identifying which metamodel elements are described within the metamodels we are able to define and to specify the activities necessary to define the platform models. Identify UML profiles where it is necessary. Once the layers are defined and the application domain is defined, we can adapt UML for specific purpose through UML extension mechanisms (UML profiles). Identify the platform models (CIM/PIM/PSM): Identify UML profiles appropriated according to the domain and platforms. Identify reusable model assets. Once the architectural layers are established we must identify reusable models for each layer. MDE Components (Task 4.2) 67 FAMILIES FAMILIES 67

79 GB14 Global Standard Software Process Identify and Specify mapping techniques and model transformations between levels: This task implies more detailed activities to define and to perform. There are two kind of mappings (transformations): Vertical mappings must be defined to proceed with the top-down architectural development process. This kind of transformation can also be defined in a bottom-up way but in this case is not mandatory. Vertical mappings are transformations between the different architectural layers defined previously. Horizontal mappings (merge mappings). These mappings are mandatory whether different system models are going to be mixed. These mappings take place in a specific architectural layer. As result, several activities related with model transformations are derived. During the Standard Software Process execution these activities must be implicitly taken into account. Identify process lifecycle: Project leaders must define the process lifecycle applied to the software process MDE Components (Task 4.2) 68 FAMILIES FAMILIES 68

80 Diapositiva 68 GB14 Second dash: Again a strange usage of "whether". Either you mean "if" or "where". Please change accordingly. mch0275a; 19/05/2005

81 Global Standard Software Process Identify architectural models Identify Metamodels Identify and Specify mapping techniques and model transformations Identify UML profiles Phases and their related activities SSP MASTER Identify process lifecycle MDE Components (Task 4.2) 69 FAMILIES This figure shows how these previous tasks impact the standard software process (SSP) developed in the MASTER project. These tasks are defined in preliminary steps of the Global Standard Software Process development. Identify architectural models, Identify Metamodels, Identify UML profiles and Identify and Specify mapping techniques and model transformations are input for the SSP. Identify process lifecycle is a task that is applied to the software process. Mapping techniques and model transformations must be applied at least after each process phase to proceed with the transition among phases. Each phase is related with a specific metamodel and therefore we need to define transformations between two successive architectural levels. The SSP is considered as an Agile Model-Driven Development (AMDD) process because after the first iteration there is a ready to run application. AMDD is a mixture between Model Driven Development (MDD) and Agile development. The Model Driven Architecture initiative promotes the separation of concerns through modeling information systems. MDA allows the model development to generate code from models. Instead of proceeding with the code development (Agile development), the agile model driven development puts forward the model development to produce ready to run applications. FAMILIES 69

82 Global Standard Software Process The Model Driven Software Process (MDSP) is an add-in (plug-in) for Rational Rose to describe a Standard Software Process in SPEM notation based on a specific metamodel to describe management information. An add-in is a program to add and/or to enhance some capabilities of other programs. Rational Rose provides an interface to develop add-ins for specific purposes. The following slides aims to provide: A tool design overview How to use it Problems and related issues MDE Components (Task 4.2) 70 FAMILIES FAMILIES 70

83 Global Standard Software Process MDSP tool overview, design: MDSP add-in CSpem Rational Rose Enterprise Edition CRoot <<Form>> Child <<Form>> ProcessSpecification <<Form>> Task <<Form>> Work Definition MDE Components (Task 4.2) 71 FAMILIES This slide provides an overview of the required design of the Model Driven Standard Process Plug-in. The plug-in has been developed to be used within Rational Rose Enterprise Edition. FAMILIES 71

84 Global Standard Software Process How to use it This section describes the way in which the plug-in developed for Rational Rose (called MDSP) must be used to describe a Standard Software Process. The notation used in this tool is compliant with SPEM 1.0 and with the metamodel developed in MASTER project (IST ) to describe management information. The following steps must be performed to specify a process: MDE Components (Task 4.2) 72 FAMILIES FAMILIES 72

85 Global Standard Software Process 1. Define process name, process purposes and process goals: and press Apply button. MDE Components (Task 4.2) 73 FAMILIES This is used to identify the process specification by providing a short name for referring to this process, a full name identifying the process and the process & Goals in which any information required to understand the process. FAMILIES 73

86 Global Standard Software Process 2. Define the process phases. For each phase a name, a detailed description and the workproducts involved are described. Press Apply button if the changes must be taken into account MDE Components (Task 4.2) 74 FAMILIES This form is used to introduce the information for each phase that is defined within the process. FAMILIES 74

87 Global Standard Software Process The Rational Rose browser allows navigating through the model. For each new phase introduced some elements are introduced at different levels: Use case view: a new use case stereotyped as Phase is introduced in the general use case diagram. A new package is also created to gather the activities related with this phase. Logical view: a new activity is introduced in the general workflow diagram. A new package stereotyped as ProcessPackage is also added representing the phase. This new package contains a general class diagram, a roles diagram and workflow diagram representing a flow of tasks Detailed in next slide. MDE Components (Task 4.2) 75 FAMILIES The picture in the next slide provides a graphical view of what is described in this slide. FAMILIES 75

88 Global Standard Software Process Use case view Logical view MDE Components (Task 4.2) 76 FAMILIES FAMILIES 76

89 Global Standard Software Process 3. Define tasks for each Phase: In this screen process tasks are described and they are associated to phases. For each task a meaningful description could be provided. The add-in provides the way to define organisational roles and to relate those roles with specific tasks. This screen allows us to establish the relationship between tasks and the roles. MDE Components (Task 4.2) 77 FAMILIES FAMILIES 77

90 Global Standard Software Process Pressing the button Apply the specific task is added at different levels: Use case view: a use case stereotyped as task is added to the package which gathers and represents a tasks list. Logical view: an activity is added to the workflow diagram representing the task flow for each phase. MDE Components (Task 4.2) 78 FAMILIES FAMILIES 78

91 Global Standard Software Process 4. Define work products. In this section the process work products are defined. For each element the following properties can be defined: Description Format: there are 4 kinds of formats defined in SPEM: Guidance Document UML model Work Product Rational Rose browser Quality record Input/Output produce MDE Components (Task 4.2) 79 FAMILIES FAMILIES 79

92 Global Standard Software Process 5. Define organisational roles. In this screen in the next slide the organisational roles are defined. A description, a set of responsibilities and the required skills can be established. In addition inheritance between roles can be also defined. This screen allows adding tasks that are already defined. MDE Components (Task 4.2) 80 FAMILIES FAMILIES 80

93 Chapter 6 : Examples of MDE components MDE Components (Task 4.2) 81 FAMILIES FAMILIES 81

94 Chapter 6: Examples of MDE components Objectives Illustrate the notions and mechanisms elaborated in Task 4.2 by providing examples Validate on these examples, that the mechanisms are appropriate MDE Components (Task 4.2) 82 FAMILIES Several examples described in this chapter will illustrate how the MDA Component notion is pragmatically used. FAMILIES 82

95 Chapter 6: Examples of MDE components Approach and expected results Examples based on the UML profiling technique will be provided The applicability of the MDE component mechanisms will be studied based on these examples MDE Components (Task 4.2) 83 FAMILIES The focus of Task 4.2 has been set to UML Profile based MDA Component, because of the use cases employed below. FAMILIES 83

96 MDE Component for project planning MDE component 1 MDSP 2 MI Produce Project Plan 3 VPlan MDE Components (Task 4.2) 84 FAMILIES The MDE component for project planning is basically constituted by 2 Rational Rose plugins and by the VPlan tool. The following elements explain more in detail its constituents: MDSP (Model Driven Software Process): This plug-in is used to describe SSPs based on the activities of the Global Standard Software Process (GSSP). This software process is represented in Rational Rose using a SPEM notation and based on a defined SSP Metamodel to represent SSP models within the UML tool. A guide of how to use this plug-in is explained in another document. MI (Management Information): This plug-in is used to annotate the software architecture with management information. This kind of information is based on the SSP defined through the MDSP plug-in. The usage of the MDSP is not mandatory but it helps to describe and to build a well-formed software process which can be understood by the MI plug-in. VPlan: This application manages SSPs and annotated software architectures with management information in XMI format to produce project plans. VPlan treats them in XML format (XML document) representing them in a tree. In addition it allows users to fill the incomplete information necessary to produce project plans. Those project plans must be transformed into a specific format to be loaded in a project plans tool. A well-known tool is MSProject and therefore they must be transformed from XML document representing project plan into a MSProject proprietary format FAMILIES 84

97 Introduction Approach & Results MDE Component for project planning Annotate a PIM with management information Technology overview Management information metamodel UML profile Management information plug-in How to use Derive a project plan based on process assets and product family assets VPlan tool How to use MDE Components (Task 4.2) 85 FAMILIES FAMILIES 85

98 Approach & Results Develop an MDE component. The purpose of the MDE components for project management is to automate the means to produce project plans for specific products based on a SSP and project management information. The MDE component includes tool and methodological support to: Describe an SSP in a formalised way using SPEM Annotate a PIM with management information Derive a project plan based on process assets and product family assets. MDE Components (Task 4.2) 86 FAMILIES FAMILIES 86

99 Annotate a PIM with management information Define a technique to annotate software models with management information in order to have data to perform accurate estimations in project plans (Rational Rose plug-in) <<annotates >> System Family PIM Management Information Model MDE Components (Task 4.2) 87 FAMILIES FAMILIES 87

100 Technology Overview The technology consists of a language to annotate or enrich the PIM with management information; this is a language to specify the Management Information Model associated to a PIM of a software system. The following elements have been defined to create the language: A metamodel that identifies and defines the management concepts necessary to annotate a PIM. A UML profile that defines a notation for the concepts of the metamodel allowing the annotation of PIMs which are specified in UML. MDE Components (Task 4.2) 88 FAMILIES FAMILIES 88

101 Management Information Metamodel overview (1/2) Classifier (from core) Class Basic Elements of the Metamodel (1/2) MngtInfo_MIM Name : String Description : String Cost : Double divided +ManagementInformation Material_MIM Name : String Description : String Quantity : Integer UnitCost : Double 1..* +Material +Task 1..* Task_MIM Decision_MIM Name : String impact 1..* 1..* Name : String Description : String Duration : Double +FunctionalDecision Size : Integer +ManagementTask Role_MIM Name : String Description : String AverageWage : Double Dedication : Integer need 1..* perform 1..* +Performer +Task 1..* +ManagementItem composed 1..* +ManagementPhases Phase_MIM Name : String Description : String +PhaseLevel MDE Components (Task 4.2) 89 FAMILIES FAMILIES 89

102 Management Information Metamodel overview (2/2) ModelElement (from core) +suplier 1..* +supplierdependency Dependency Basic Elements of the Metamodel (2/2) +client +clientdependency 1..* Abstraction (from core) Usage (from core) Permission (from core) Impacts_MIM MDE Components (Task 4.2) 90 FAMILIES FAMILIES 90

103 Management Information UML Profile overview Management information Metamodel Management information Profile Classifier (from core) class (from core) <<stereotype>> MngtInfo represent <<stereotype>> Phase MngtInfo_MIM Phase_MIM Task_MIM Role_MIM Mat erial_mim represent represent represent represent <<stereotype>> Task <<stereotype>> Role <<stereotype>> Material BaseElement Bas eelement BaseElement Decision_MIM represent <<stereotype>> Decision BaseElement BaseElement BaseElement UML Metamodel <<metaclass>> Class MDE Components (Task 4.2) 91 FAMILIES This profile links together the management information metamodel, the profile and the UML elements that will be used for modelling the management information. FAMILIES 91

104 Icons of the UML Profile Stereotype MngtInfo Notation Phase Task Role Material Decision MDE Components (Task 4.2) 92 FAMILIES FAMILIES 92

105 Management information plug-in - How to use Select and Start the management information plug-in in Rational Rose MDE Components (Task 4.2) 93 FAMILIES FAMILIES 93

106 Management information plug-in-how to use Main screen: Select XMI file representing the Standard Software Process Provide a name and description Select a package in which the management information is going to be saved MDE Components (Task 4.2) 94 FAMILIES This step provides the context required for introducing management information within the SSP. The SSP itself and the management information. FAMILIES 94

107 Management information plug-in-how to use Select the SSP phases and the impacted package(s) MDE Components (Task 4.2) 95 FAMILIES In this interface the phases that are going to be annotated with management information are selected. FAMILIES 95

108 Management information plug-in-how to use Select tasks involved For each task size and duration must be provided MDE Components (Task 4.2) 96 FAMILIES For each phase we must select what tasks will be annotated with management information. FAMILIES 96

109 Management information plug-in-how to use Select roles For each role assign values for the following attributes: Average Wage Estimated Effort MDE Components (Task 4.2) 97 FAMILIES For each role we then annotate their average wage as well as estimated effort. FAMILIES 97

110 Management information plug-in-how to use Select the workproducts Assign values: Quantity Unit cost MDE Components (Task 4.2) 98 FAMILIES For each workproduct we identify the quantity as well as the unit cost. FAMILIES 98

111 Management information plug-in-how to use Rational Rose browser Class diagram showing an impact relationship MDE Components (Task 4.2) 99 FAMILIES This figure provides an overview of how this is shown within the Rational Rose FAMILIES 99

112 MDE Component for project planning MDE component 1 MDSP 2 MI XMI Produce Project Plan 3 VPlan MDE Components (Task 4.2) 100 FAMILIES In order to produce a project Plan, we need to have a SSP annotated with management information, as the basis to allocate persons to roles. FAMILIES 100

113 Derive a project plan based on process assets and product family assets Develop a technique to derive a project plan from the SSP and the management information that annotates the PIM. (VPlan tool) MDE Components (Task 4.2) 101 FAMILIES This section provides an overview of the tool developed based on an annotated model and SSP in order to produce a project plan. FAMILIES 101

114 VPlan tool-how to use Vplan provides a framework to produce project plans from many different sources. In this case from an annotated model with management information Select the annotated model (XMI file) and the SSP (XMI file) associated. MDE Components (Task 4.2) 102 FAMILIES FAMILIES 102

115 VPlan tool-how to use VPlan tool shows a project plan structure in a tree Phases are grouped in a set of instances (in red) within the Phases node. Each Phase contains Tasks that are grouped in its turn in a set of instances (in blue) within the Tasks node Bold tasks have predecessor(s) MDE Components (Task 4.2) 103 FAMILIES FAMILIES 103

116 VPlan tool-how to use 1. Add worker playing a specific role to carry out a specific task MDE Components (Task 4.2) 104 FAMILIES This slide shows how the V-Plan is used to assign people to roles. FAMILIES 104

117 VPlan tool-how to use Right button click over a specific Role and then select Add Role Player MDE Components (Task 4.2) 105 FAMILIES FAMILIES 105

118 VPlan tool-how to use MDE Components (Task 4.2) 106 FAMILIES A form showing personnel information is presented allowing the selection of available workers. Each worker has a set of roles that can be played by him with a special competence. Only workers playing the specific role can be selected. This kind of information is necessary to estimate tasks duration. Once a worker is selected we set up the effort assigned. FAMILIES 106

119 VPlan tool-how to use Right-button click over an assigned worker and a special menu bring it up. Some of these actions are mandatory to enable and to unlock (unbold) successors tasks. MDE Components (Task 4.2) 107 FAMILIES FAMILIES 107

120 VPlan tool-how to use Edit Assigned Effort: this action is not mandatory but it allows us to change the assigned effort that we have previously defined Delete Worker: this action is also not mandatory but it is useful to delete assigned workers Assign Dates: this action is also not mandatory but it is necessary to assign dates and to assure that they fit well with the worker availability Validate dates: this action enables (unlock and unbold) successor tasks and in addition it blocks the current task because we assume that its related information has already been established (this option takes you to next slide) MDE Components (Task 4.2) 108 FAMILIES FAMILIES 108

121 VPlan tool-how to use This screen is used to assign work for a specific worker MDE Components (Task 4.2) 109 FAMILIES FAMILIES 109

122 VPlan tool-how to use Validate all dates for all worker instances: right button click over the workers node and select validate dates. All nodes with a grey background colour are nodes locked. Validate task duration: right button click over task instance and press validate task duration. As a result this task is locked for edition. MDE Components (Task 4.2) 110 FAMILIES FAMILIES 110

123 VPlan tool-how to use Out-Put Generate in MSProject MDE Components (Task 4.2) 111 FAMILIES By finally executing the option Show project plan, the project plan is shown in Microsoft Project. FAMILIES 111

124 The SPEM MDA component Implementation of the standard SPEM profiles, based on UML1.4 Corresponds to a PIM implementation, with its adapted tooling Development of dedicated modelling wizards: model structuring, creation of model elements Development of dedicated consistency rule checkers Development of related services, such as document generation MDE Components (Task 4.2) 112 FAMILIES SPEM is a standard defined as an UML Profile. The corresponding MDA Component will contain all the necessary elements to support a SPEM dedicated tool, by customizing a UML Case tool (Objecteering). FAMILIES 112

125 The SPEM MDA component adapted UML model MDE Components (Task 4.2) 113 FAMILIES We see in this picture that SPEM is supported through a dedicated notation, dedicated entry boxes, and specific entry fields related to the SPEM Usage. UML which is underlying SPEM is mostly hidden to the end user. FAMILIES 113

126 The SPEM MDA component Dedicated services MDE Components (Task 4.2) 114 FAMILIES Dedicated services such as Creating SPEM elements, checking the model, have been set. FAMILIES 114

127 The UML/test for Java MDA component Implementation of the standard UML for test profile Extension of UML for a dedicated purpose (test modelling) Corresponds to a PSM implementation, dedicated to the Junit platform Development of dedicated modelling wizards and mode transformation tools: model structuring, creation of test from an application model Development of dedicated consistency rule checkers Development of code generation services: Junit tests Development of other related services such as test document generation MDE Components (Task 4.2) 115 FAMILIES Based on the UML Profile for test standard, the UML/Test for Java MDA Component specializes the case tool for test purposes. FAMILIES 115

128 The UML/test for Java MDA component Customized UML model Junit execution platform MDE Components (Task 4.2) 116 FAMILIES We see here that extensions have been provided (such as the tester with a hammer), and that coupling have been realized with the Junit test infrastructure. FAMILIES 116

129 Supporting the Thales Lifecycle with MDA components: 3 layers of artifacts 0 platform dependency + PIM Analysis Models PIM scope Abstraction Spectrum Platform depencency PIM Might contain implicit information related to a type of platform but no explicit information (architectural style) A PSM contains at least one explicit information related to the target platform PIM requires no change at all to be deployed on another platform PSM PSM PSM scope PSM is dedicated to a specific platform - CODE CODE No more model but code PLATFORM scope MDE Components (Task 4.2) 117 FAMILIES PIM layer : describes the system and does not take care of used technologies and solutions PSM layer: describes the system and takes care of design solutions according to high-level technologies and generic design Code layer: provides an implementation of the system FAMILIES 117

130 Supporting the Thales Lifecycle with MDA components: Engineering process : From the V approach to MDE/MDA Functional reqs spec & analysis Technical reqs spec & analysis Architectural decisions Req Validation Specif. Prelim. Integration Design & Test Detailed Unit Design Test Coding Functional Technical Realisation reqs spec & analysis PI reqs spec & analysis Architectural decisions Technical PS reqs spec & analysis The Y process : Architectural separation of domain & technical concerns PI design decisions The classical V process Realisation The Mirror MDE/MDA process : separation of domain & technical, PI & PS concerns MDE Components (Task 4.2) 118 FAMILIES Independant from development lifecycle considerations : linear (cascade) or iterative incremental / spiral FAMILIES 118

131 Technical approach : global picture Standard Domain Models PIM PIM Standard QoS Models UML Model transformation Configuration Deployment PSM PERCO specific platform models Mapping PSM EJB specific platform models PSM.NET specific platform models PSM other specific platform models Architecture style P.D.M PERCO-CCM profile EJB profile.net profile other exotic profiles Code Generator and execution PERCO/CCM Execution infrastructures.net/com EJB/J2EE Others MDE Components (Task 4.2) FAMILIES 119 With different PIMs as input a functional PIM and a QoS PIM and a model mapping for each platforms contained in the PDM component we are able to generate Different PSM. Then the code generation phase is possible. FAMILIES 119

132 GB15 Different levels of modelling PIMs Functional thread PI Technical thread Architectural decisions PS Technical thread PI design Architectural decisions <<PIM Context.abstraction level>> Context <<refine>> <<PIM Requirements.abstraction level>> Requirements <<refine>> <<PIM Analysis.abstraction level>> Analysis <<refine>> <<refine>> Objects Design <<PIM Design Compo.abstraction level>> Components Design Realisation PSMs <<refine>> <<refine>> <<refine>> <<refine>> PSM_RT PSM_CORBA PSM_EJB PSM_CCM Separation of Domain & Technical concerns, PI & PS concerns MDE Components (Task 4.2) 120 FAMILIES In the double Y process different tracks produce artefacts at different level of abstraction. FAMILIES 120

133 Diapositiva 120 GB15 Change all "modelisation" to "modelling" on all slides and notes pages mch0275a; 20/05/2005

134 Different levels of modelisation PIMs Functional thread PI Technical thread Architectural decisions PS Technical thread PI design Architectural decisions <<PIM Context.abstraction level>> Context <<refine>> <<PIM Requirements.abstraction level>> Requirements <<refine>> <<PIM Analysis.abstraction level>> Analysis <<refine>> <<refine>>? UML Objects Design <<PIM Design Compo.abstraction level>> Components Design Realisation PSMs <<refine>> <<refine>> <<refine>> <<refine>> PSM_RT PSM_CORBA PSM_EJB PSM_CCM Separation of Domain & Technical concerns, PI & PS concerns MDE Components (Task 4.2) 121 FAMILIES Depending on the level of abstraction/modelling it is possible to use different modelling languages For example UML may be suited to Requirements or maybe to all levels of modelling FAMILIES 121

135 We need rules to express What is to be represented in the model? is a meaningful (well-formed) model? is a complete model? is a model of good quality? How do you produce the model? Model production lifecycle and states Engineering roles and activities Methodological guidelines With what model manipulation techniques? To create & initialise the model To develop the model contents To exploit the model and generate documents and files Modelling rules for model M Producing model M MDE techniques (mappings, patterns & generation) MDE Components (Task 4.2) 122 FAMILIES Rules are very important for MDE. Each model need rules for restricting its possible uses, its possible content, The way it is produced and so on FAMILIES 122

136 Methodological assets for supporting a MDE approach Modelling principles and rules: Modelling rules for model M (Sub)process for producing model M Transforming a model M1 into a model M Patterns Generating files from a model M Supporting techniques for building and exploiting model M Modelling language : abstract syntax & semantics (metamodel), concrete notation (UML Profile), well-formedness rules Predefined model libraries Model recording structure and rules («model template») Model presentation rules Model assessment criteria : quality metrics, completion rules Formalism: definition of dedicated concepts and formalism, UML-based MDE Components (Task 4.2) 123 FAMILIES Most of the time these rules are defined implicitly Putting them explicitly in a methodological asset is very important for supporting a MDE FAMILIES 123

137 Methodological assets for supporting a MDE approach Model engineering subprocess: Modelling rules for model M (Sub)process for producing model M Transforming a model M1 into a model M Model production lifecycle Task structure (work decomposition into activities and steps) Roles and responsibilities Methodological guidance Patterns Generating files from a model M Supporting techniques for building and exploiting model M Roles work definition activity step Work decomposition structure Guidance Formalism: Usage of the SPEM standard for describing processes MDE Components (Task 4.2) 124 FAMILIES Another often implicit part of MDE is process and methodological issues. Making and packaging them is very useful for reuse and enhanced productivity. The SPEM language is very useful for that. FAMILIES 124

138 Methodological assets for supporting a MDE approach MDE techniques: Modelling rules for model M (Sub)process for producing model M Transforming a model M1 into a model M Model-model mappings Patterns Model-non model mappings Formalism: UML + specific concepts and formalisms Patterns Generating files from a model M Supporting techniques for building and exploiting model M MDE Components (Task 4.2) 125 FAMILIES Another kind of asset is more dedicated to model transformation and code generation techniques. They must be explicitly referenced in an MDE asset. Language used can be UML or other more suited mapping languages. FAMILIES 125

139 5 levels of modeling PIMs Subprocess Functional thread PI Technical thread Architectural decisions PS Technical thread PI design Architectural decisions <<PIM Context.abstraction level>> Context <<refine>> <<PIM Requirements.abstraction level>> Requirements <<refine>> <<PIM Analysis.abstraction level>> Analysis <<refine>> <<refine>>? Modelling rules Mapping Subprocess Subprocess UML Techniques Modelling Modelling rules rules Mapping Mapping Subprocess Techniques Modelling rules Techniques Mapping Subprocess Realisation Objects Design PSMs <<refine>> <<refine>> PSM_RT PSM_CORBA <<PIM Design Compo.abstraction level>> Components Design <<refine>> <<refine>> PSM_EJB PSM_CCM Modelling Techniques rules Mapping Subprocess Techniques Modelling rules Mapping Separation of Domain & Technical concerns, PI & PS concerns Techniques MDE Components (Task 4.2) 126 FAMILIES At each five levels of modeling defined in the Y we have a MDA component made up of Previously described assets (rules, process and transformation technique). FAMILIES 126

140 Global view Context Requirements Functional reqs spec & analysis Analysis Component Design Technical PI reqs spec & analysis Architectural decisions Technical PS reqs spec & analysis Architectural decisions PI design Realisation CCM design Corba design C++ impl. MDE Components (Task 4.2) 127 FAMILIES This global view resumes the concepts of Y process and relationships with MDE/MDA components. FAMILIES 127

141 MDA COMPONENT : Corba Component Model: Corba 3.0 MDE Components (Task 4.2) 128 FAMILIES Example of UML profile for Corba 3.0 as OMG define it FAMILIES 128

142 Contract Definition Attributes, Operations and parameters are defined with Objecteering native features MDE Components (Task 4.2) 129 FAMILIES 1st you have to define attributes, operations and parameters for your application FAMILIES 129

143 Component Definition Call the create component command Choose the names Press ok! MDE Components (Task 4.2) 130 FAMILIES Afterwards, you have to define the Corba 3.0 component you need for your applications. To do it, you can use a wizard to guide you to instantiate the component. FAMILIES 130

144 Component Edition Component Properties Edition Facilities A Component has: A Name A Set of supported Interfaces A Parent Component A Set of Attributes A Component Exposes: A set of Ports Port Management Services A Component can be Instantiated MDE Components (Task 4.2) 131 FAMILIES When components are created, you have to specify different characteristics and add ports, events, interfaces. FAMILIES 131

145 Port Definition Choose a name The Kind A Port has: A Name A kind (facet, receptacle ) A type And the Type On the Fly Diagram Definition Press ok! MDE Components (Task 4.2) 132 FAMILIES To define the port, we have developed a wizard to help the user to define operations for the port FAMILIES 132

146 Port Definition An Event Sink Must be typed by An Event On the Fly Semantic Checks The Model is Always Consistent MDE Components (Task 4.2) 133 FAMILIES When you define an event inside the port, you reuse an event already defined before, then your model is always consistent. FAMILIES 133

147 Application External View FlightManagement_fc FlightManagement All the Types MTCD FlightManagement_rc ConflictManagement_fc ConflictManagement ConflictManagement_rc NewFlight_sc NewFlight_sk NewFlight NewFlight_sk HMI FDP NewConflict_sc NewConflict_sk Only thetypes NewConflict Supervision Supervision_fc MDE Components (Task 4.2) 134 FAMILIES We have also developed a tool to setup connections between different Corba 3.0 components in the application FAMILIES 134

148 Application External View HMIInstance:HMI MTCDInstance:MTCD FDP createflight push_newflight push_newconflict getconflict Only Component Operations can be Trigger MDE Components (Task 4.2) 135 FAMILIES Also, to explain interactions between components, we have customized the UML interaction diagram in the objecteering tool. FAMILIES 135

149 Implementation View The CCM Stuff is Automatically Generated Generated Local Interfaces The CIF is always Consistent with the IDL Generated Executors Generated Event Implementation MDE Components (Task 4.2) 136 FAMILIES Also, we have developed an implementation view for the developer to put its code and to generate all required files for the application FAMILIES 136

150 Implementation View FlightManagement_fcExecutor createflight() FlightManagement_fc 1 1 component FDPMainExecutor ccm_activate() ccm_passivate() ccm_remove() get_flightmanagement_fc() 1 component 1 NewFlight_sc NewFlight_scExecutor Express the Business push_newflight_sc() MDE Components (Task 4.2) FAMILIES 137 A detail view with the class diagram of the business code of the application FAMILIES 137

151 Component Assembly Port Instances can be connected if: They have compatible types They have compatible kind They are not already used The tool gather all possible connections Single Selection Componen t Ports Only Meaningful Connections can be created MDE Components (Task 4.2) 138 FAMILIES Here we connect components to each other with possible links. The tool gives you only the possible link that you can create, if you cannot create a link it means you have made a mistake during your component definition or missed an interface declaration. FAMILIES 138

152 Component Assembly Select the Connections you Want Press ok! MDE Components (Task 4.2) 139 FAMILIES Another view of the component assembly tool FAMILIES 139

153 Logical Application Deployment MTCDInstance:MTCD FDPInstance:FDP HMIInst MTCDHomeInstance1:MTCDHome FDPHomeInstance1:FDPHome HMIHomeIn MYServer:CCMComponentServer To make the Deployment: Link the Instances! MDE Components (Task 4.2) 140 FAMILIES Here, a customisation of UML to model the logical deployment of components and their home for the application. FAMILIES 140

154 Physical System Deployment XML:CCMProcessus MYServer:CCMComponentServer Repository:CCMProcessus EventChannelManager:CCM CdmwTool:CCMApplication InterfaceRep TRT0116:Host applic ation:ccmapp lica tio n ComponentI CdmwService:CCMApplication MDE Components (Task 4.2) 141 FAMILIES Afterwards, the logical deployment done, you can deploy your application and its corba component on the real machine/hosts. Then we have customised UML to specify the physical deployment of the component. FAMILIES 141

155 System Configuration App-monitoring_application:CCMMonitoring App-monitoring_CdmwS App-monitoring_CdmwTool:CCMMonitoring a pplic ation:ccmapplication CdmwTool:CCMApplication CdmwService:C NamingAndRepositoryService:CCMService Host-monitorin XMLService:CCMService i i MDE Components (Task 4.2) 142 FAMILIES Afterwards, you can configure your components which are running on hosts. FAMILIES 142

156 File Generation Root Package File name Cardinality Role Component Assembly Descriptor Component Software Descriptor C++ IDL3 1 for each deployment 1 for each component implementation 1 for each artefact 1 for each Application Application assembly and deployment Component Software descriptor Implementation of events, homes and components. Declarative definition of the CCM application IDL2 avec des reference sur de l'idl2 generé IDL2 1 for each Application Component Server 1 for each component server Component server configuration CARDAMOM Namming and Namming and repositories 1 for each application repositories configuration CARDAMOM Platform Management Configurator 1 for each application Port and timeout definition System Definition 1 for each application Processus mapping on physical hosts Code Generation Definition 1 for each application Component Server configuration Event Channel Configurator 1 for each application Event Channel Configuration Event Channel Manager 1 for each application Event channel Manager configuration CORBA Component Descriptor 1 for each home CORBA Component Definition Component Properties File 1 for each component or To set component/home attributes home instance values Don t Worry, you Still have One file to write MDE Components (Task 4.2) 143 FAMILIES And finally, generate all corba 3.0 component files required for running the application on site. FAMILIES 143