Propriétaire : MERSI
Méta-modèle fourni par Softeam, contenant les concepts principaux du méta-modèle UML en simplifiant sa structure
Apport de ce méta-modèle au méta-modèle MERSI
Ce méta-modèle, fourni grâcieusement par la société Softeam, résulte de la simplification que l'éditeur fait subir au méta-modèle UML pour en faire le modèle de son outil : Objecteering. Cette simplification est imposée par la complexité du méta-modèle UML, pulvérisé en micro-paquetages qui se reprennent les méta-classes les uns des autres.
Nous utilisons ce méta-modèle UML pour montrer les passerelles entre le méta-modèle MERSI et celui du langage UML.
Chaque fois qu'une telle passerelle existe, c'est une piste pour représenter rigoureusement - et graphiquement - des notions ou objets du champ d'étude.
A noter : un des sous-produits de ce méta-modèle est la documentation de l'outil. Ceci explique certaines tournures dans les commentaires, particulièrement dans l'introduction.
Commentaire sur le méta-modèle Objecteering 6.3
IntroductionWelcome to the Objecteering/Metamodel user guide! The Objecteering/UML metamodel contains the most accurate description of the information managed by the Objecteering/UML CASE tool, as well as its definition and links. This user guide constitutes the working base for all those who wish to implement new services which use the metamodel, such as model transformation, code or documentation generation, metrics calculation, requests to the model, and so on. It is a programmer's guide to users using the Objecteering/UML Profile Builder or Objecteering/MDA modeler tool. J language programmers will find in this user guide all the predefined J classes (Objecteering/UML metaclasses) which can be handled. What is a metamodel?A metamodel is the model of a model. The Objecteering/UML metamodel provides a detailed description of the model supported by Objecteering/UML. The Objecteering/UML CASE tool is built using automated model transformation and code generation techniques, based on the presented metamodel. All its elements (model dialog boxes, graphic editors, model manager, etc.) are deduced from the metamodel. The user, therefore, has here the model of the Objecteering/UML CASE tool itself.Using the metamodelEach metaclass is documented, with a description of its attributes, relationships and relationships in the opposite direction. The names provided are precisely those which must be used from the J language, in order to work with the metamodel (attribute names, names of the roles which are concatenated with the ones of the opposite classes, names of the classes). Services and consistency rules are also presented. In addition, element composition graphs are always documented, in order to present the way in which new instances are created.
Reference standard
This metamodel corresponds to the first iteration on implementing UML2.0. Objecteering will progressively entirely implement the UML2.0 semantics. The semantics of the supported models is the same. The metamodel, however, corresponds to the Objecteering's implementation of the UML model. The correspondence is generally simple and straighforward. The differences stem from historical reasons (such as backward compatibility), the single generalization constraint inside Objecteering, and a pragmatic vision of the best way to support UML.
Aim of this manual
The metamodel contains the most accurate description of the information managed by the Objecteering workshop, their definition and links. This document is addressed to advanced users who are looking for precise information. It is also addressed to the specialists of the object methods, as it provides them with a good level of coverage and accuracy. Furthermore, it constitutes the working base for all those who will implement new services that use the metamodel, such as model transformation, code or document generation, metrics calculation, request to the model, etc.
What is a metamodel ?
A metamodel is the model of a model. In this documentation, the metamodel provides a detailed description of the model supported by Objecteering. The Objecteering 6 workshop is built thanks to automated model transformation and code generation techniques on the basis of the presented metamodel. All its elements (dialog boxes, graphic editors, model manager, etc.) are deduced from the metamodel. The user therefore has here the tool's model.
Version history
The present metamodel has been defined to provide a first support ofObjecteering to the UML2.0 version, which is a major version incorporating the OMG UML 2.0 metamodel. The current metamodel mixes pieces of the UML2.0 metamodel, and pieces of the UML1.4 metamodel. The “structural" part of UML2.0 (classes, packages, ports, colaborations, etc.) is incorporated, while the dynamic part (activity, states, sequence) is still at the UML1.4 level.
Using the metamodelEach metaclass is documented, with a description of its attributes, its relations, and its relations in the opposite way. The names provided are precisely those that must be used from the J language, or from external API to the physical metamodel, to handle the metamodel (attribute names, names of the roles that are concatenated with the ones of the opposite classes, names of the classes). Services and consistency rules are presented as well. In addition, the composition graph of elements is explained, in order to know how to create new instances. (each model instance must belong to another model instance, the “Project" being the root)
Diagrammes de classes :
Paquetages :
Classes :
- Abstraction : Relationship relating two elements that represent the same concept at different levels of abstraction.
- ActionState : Description of an action that cannot be broken down further.
- ActivityGraph : Special case of a StateMachine that defines a computational process in terms of the control-flow and object-flow among its constituent actions.
- ActivityState : Execution of an atomic action, typically the invocation of an operation.
- Actor : Active element external to the system, and cooperating with it.
- Artifact : An artifact represents a physical piece of information that is used or produced by a software development process, and that can be deployed to nodes. Examples of artifacts include model files, source files, scripts, and binary executable files.
- Association : Definition of links that may exist between objects.
- AssociationEnd : Connection of an Association to one of its related classes.
- Attribute : Property of a Class.
- AttributeLink : Named slot in an instance, which holds the value of an attribute.
- Behavior : A behavior is the implementation of a behavioral feature or of a classifier
- Binding : Binds a role to the element it represents in a certain context
- Class : escription of a set of objects that share the same attributes, operations, methods, relationships, and semantics.
- ClassAssociation : Class relating other classes. It is both a Class and an Association.
- Classifier : A classifier is a classification of instances it describes a set of instances that have something in common. A classifier can have features that characterize those instances.
- Collaboration : A collaboration describes how a classifier or operation is realized by a set of classifiers used and related in a specific way.
- CollaborationMessage : Message used in the Collaboration or Object diagrams.
- CollaborationUse : A collaboration use represents a particular use of a collaboration.
- Communication : Communication link between Actors and Use Cases
- Component : A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.
- Condition : Boolean expression for making a choice.
- Constraint : A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.
- DataFlow : Circulation of information between model elements.
- DataType : A data type is a type whose values have no identity (i.e., they are pure values). Data types include primitive built-in types (such as integer and string) as well as enumeration types.
- Dependency : A Dependency states that the implementation or functioning of one or more elements requires the presence of one or more other elements.
- Diagram : Graphical representation of a model.
- Element : Atomic constituent of a model.
- ElementImport : An element import identifies an element in another package, and allows the element to be referenced using its name without a qualifier.
- ElementRealization : Specialized abstraction relationship between two sets of model elements.
- Enumeration : Special kind of DataType whose range is a list ofpredefined values, called EnumerationLiterals.
- EnumerationLiteral : Defines an atom (i.e., with no relevant substructure), represents one in the list of values that an enumerated may have
- Event : Specification of a significant occurrence that has a location in time and space.
- Feature : Property, like operation or attribute, which is encapsulated within another entity, such as an interface, a class, or a data type.
- GeneralClass : General definition of a Class
- Generalization : A generalization is a taxonomic relationship between a more general classifier and a more specific classifier.
- Instance : Representation of an instance in a modeled system, or role played by instances in a certain context.
- Interaction : Message sequencing context
- Interface : An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations.
- InternalProduct : Additional elements attached to ModelElements.
- InternalTransition : Transition that is internal to a state.
- Item : Item is a concrete class, that can be specialized for adding new elements to UML.
- Link : connection between instances.
- LinkEnd : End point of a link.
- Manifestation : A manifestation is the concrete physical rendering of one or more model elements by an artifact.
- Message : Occurrence of an operation, processed by Instances
- ModelElement : Named entity in a Model.
- ModelTree : ModelTree is the abstraction of each element organizing ModelElements using an “OwnerShip" association.
- MpGenProduct : Work product produced automatically by Objecteering.
- NameSpace : A namespace is an element in a model that contains a set of named elements that can be identified by name.
- Node : A node is computational resource upon which artifacts may be deployed for execution. Nodes can be interconnected through communication paths to define network structures.
- Note : Textual part, attached to a ModelElement.
- NoteType : Defines a specific kind of Note.
- ObjectFlowState : Defines an object flow between actions in an activity graph.
- Operation : Individual pieces of invocable behavior
- Package : Decomposition unit of a model
- PackageImport : A package import is a relationship that allows the use of unqualified names to refer to package members from other namespaces.
- PackageMerge : A package merge defines how one package extends another package by merging their contents.
- Parameter : A parameter is a specification of an argument used to pass information into or out of an invocation of a behavioral feature.
- Partition : Mechanism for dividing the states of an activity graph into groups.
- Point : Graphical point in a diagram.
- Port : Specification of an interaction point of the classifier.
- Project : Working space for a Model.
- PseudoState : Abstraction of different types of nodes in the state machine graph.
- InterfaceRealization : Implementation link between a class and its interface, or between a Component and its interface.
- SequenceMessage : Messages used for Sequence diagrams.
- Signal : Specification of an asynchronous stimulus communicated between instances.
- SignalReceipt : State representing the reception of a signal.
- SignalSending : State representing the sending of a signal.
- State : Notable situation or condition during the life of an object.
- StateMachine : Graph of states and transitions that describes the dynamic behavior of objects.
- StateVertex : Abstraction of a node in a statechart graph.
- Stereotype : Specific adaptation of ModelElement semantics.
- SubActivityState : Activities that are decomposed into sub activities.
- Substitution : Relationship between two classifiers signifying that the substitutingClassifier complies with the contract specified by the contract classifier.
- TagParameter : Parameter forTaggedValues
- TagType : Definition of allowed TaggedValues for a defined metaclass.
- TaggedValue : Attachment of a piece of information to a ModelElement.
- TemplateBinding : A template binding represents a relationship between a templateable element and a template.
- TemplateParameter : Parameter for Templated elements.
- TemplateParameterSubstitution : A template parameter substitution relates the actual parameter(s) to a formal template parameter as part of a template binding.
- Transition : Path from one State to another.
- Usage : Use dependency.
- UseCase : unit of externally-visible functionality provided by part of a system.
- UseCaseDependency : Inheritance or dependency link (Uses) between UseCases
- ViewBox : Graphical Boxes.
- ViewElement : Graphical representation of a ModelElement.
- ViewLink : Graphical link.
- ExtensionPoint