This page is a quick reminder about Modelio 3 concepts such as Model, Repository, Fragment…
A model is an abstract representation in the form of graphical representation and text often displayed as diagrams. It represents something (a system, a problem, a solution, concepts, procedures …) for a particular community of participants (designers, developers, business analysts, users …), and has a clearly defined objective (pedagogical example, business view, design, analysis, implementation …).
The diagrams are views of the underlying model elements which constitute a model. Model elements break a model down into elementary information, for example a class, an attribute, an attribute’s type, an operation’s parameter, an association end, and so on.
Models are composed of model elements selected for a defined goal (the model of an application, of a system architecture, of a particular problem, and so on). The important point is the defined goal driving the selection of the model elements that constitute the model.
However, handling individual model elements rarely makes sense for a user, who will usually work with a more macroscopic set of agglomerated model elements. In Modelio, these macroscopic sets are called model fragments, which are the unit of selection.
In other words, in Modelio, a model is a set of model fragments which are themselves sets of model elements. Note that model fragments exist independently of models, and can be referenced by several models.
In Modelio terminology, a repository is where the reference definitions of model elements are stored.
Reference definition means that the real existence of the model element is bound to the fact that the model element is present in the repository. Should the model element be deleted in the repository, it would simply no longer exist.
Of course, a model element can always be duplicated in some storage, its contents serialized in a file, its description written somewhere… None of these “persistent” copies of the model element are the reference definition of the element, which is stored in a repository.
The following statements are always true:
Modelio supports several repository technologies. Each technology has specific characteristics that must be understood when choosing one of them for a particular repository.
Type | Distribution | Access mode | Sharing capabilities | Usage | Comment |
---|---|---|---|---|---|
Local | Local | Read/Write | No | Work model | Single user |
SVN | Local/Network | Read/Write | Yes | Work model | Typical teamwork |
Model Component | Local/Network | Read | Yes(read) | Library | |
HTTP | Network | Read | Yes(read) | Library | |
Module | Local/Network | Read | Yes(read) | Library | Only provides MDA extensions |
Model fragments are groups of higher level model elements. Model designers attribute logical consistency to model fragments, but their primary function is to autonomously store a part of a model.
A model element of a given fragment can be linked to model elements of another model fragment, but this link must be a simple reference, and not a containment or composition link.
A model element really belongs to a fragment, but this ownership is not definitive. It can be moved to other fragments, according to the organizational needs of the designers.
Fragments are tightly coupled with repositories, since a fragment is always associated with one and only one repository. Repositories are where model elements are physically stored.
In Modelio, when a model is edited, the location of fragments is transparent. They can be locally stored on a machine, on a local company network, or published on the web depending on their repository.
Decisions on breakdown into fragments, physical location and accessibility are driven by participants’ organizational, cooperation and accessibility needs.
Because of the tight relationship between fragments and repositories, fragments are often named from the technology of their underlying repository. Therefore, expressions like “SVN fragment” or “model component fragment” have become very common when describing the composition of model.
Local fragments
Local fragments are stored directly on the end-user workstation. They are accessible only to the user working on the workstation, their contents cannot be shared between users. Local fragments are typically used to create temporary experimental models, test models or test data.
SVN fragments
The content of SVN fragments is stored in a repository managed by SVN. This means that this content can be versioned, and changes logged. The content of an SVN fragment can only be modified by a user if he/she has sufficient rights at SVN level. Similarly, traditional SVN checkout/commit operations are required before the model can be modified.
HTTP fragments
As their name suggests, HTTP fragments are hosted and stored on an http server. This means that they can be remote, only requiring a reduced infrastructure (HTTP is available everywhere). They can be read and browsed, but cannot be modified via http. Typical use of HTTP fragments involves the publication of reusable model parts in the form of libraries. The advantage of this over model components (described below) is that HTTP fragments are not stored locally on the user’s workstation, and are therefore permanently up-to-date in the user’s project. A drawback of this flexibility is that they are not versioned, unlike model components. HTTP fragments are typically used where several teams are working on separate but interdependent parts of a project, and where fast and transparent synchronization between these teams is required. This is the case during intensive development phases (much less so during maintenance phases).
Model components
Model components are used to package a set of model elements into a single archive file, along with a set of additional files. Model components are then deployed in a Modelio project, where the UML model elements they contain become available in read-only mode (ie, they cannot be modified in the project where they are deployed).
Typical use of the Modelio model component technology consists in providing model components for external libraries, such as the Java JDK. Once the JDK model component has been deployed, all the classes of the JDK become available for Java modeling.
In most cases, only a simplified and reduced part of the model is contained in a model component (ie, packages and classes but no methods and no code). Therefore, deploying a model component like the JDK preserves accurate modeling (all classes are present) while avoiding the burden of a huge model (the JDK is indeed a real piece of code!) and related potential performance issues.
Note that Modelio enables you to create and package your own model components. This can be efficiently used to organize large team activities into a reliable process, where each team can regularly deliver official revisions of the components it is responsible for to other teams. These deliveries are then based on the project schedule.Both team independence and team synchronization can be simultaneously promoted when using the Modelio model component technology.
Modules are the means of defining, implementing and deploying extensions for Modelio.
A module will typically define and contain:
* UML extensions such as profiles, stereotypes and their properties
* Model creations, transformations and navigation through the Modelio Java API
* Contextual property pages
* Menu commands in the explorer and button commands in the toolbar and property pages
* Palette tools to create elements in diagrams
Within modules:
Example of modules:
The Modelio Store web site proposes many additional modules for Modelio.
In Modelio, a project is similar to a document in Word: you open it, modify its contents and save the changes (or not) before closing it. From the end user point of view, the project is the unit of work and persistence of his/her contributions.
Once opened, the project appears to the end user as a unique model, composed of many model elements, usually organized into packages and other high level containers. The “Save” operation also appears to be applied to the unique model proposed by the opened project.
However, behind the scenes, the manipulated model elements may be provided by several model fragments and their physical repositories, and Modelio is in charge of managing these repositories transparently as a unique model.
Constellation maintains the exact configuration of each project it manages.
A project is configured by: