You can use this page to understand the historical transition of MDriven product operations from CapableObjects RE AB to MDriven AB.
Contents
From CapableObjects RE AB to MDriven AB
MDriven AB took over the activities concerning MDriven Designer, MDriven Turnkey, and the MDriven Framework from CapableObjects RE AB.
CapableObjects AB began operations in 2007. MDriven AB was formed in 2018 as an independent, privately held company based in Stockholm, Sweden.
Contracts and customer relationships
New and renegotiated contracts for MDriven products are handled through MDriven AB and the MDriven site. Existing contracts may remain with CapableObjects RE AB.
If you need to determine which company is party to an existing agreement, check the legal entity named in that agreement before requesting a renewal, amendment, or support related to its terms.
Product continuity
The transition covers the MDriven product activities, including:
- MDriven Designer, where you define models for an information system.
- MDriven Turnkey, used to run and deploy MDriven applications.
- MDriven Framework.
For an introduction to the modeling concepts used in MDriven, start with classes and objects. A class defines the common structure and behaviour; an object is an individual instance of that class. For example, a WorkItem class can define fields and relationships used by every work item, while one work item assigned to a specific performer is an object.
Working with MDriven models
MDriven models can support definition, prototyping, documentation, and production use. You can use the same model to describe information and its relationships, then express behaviour close to that model.
For example, a work-management model may contain projects, task groups, tasks, work items, performers, abilities, and consumables. A work item can hold its own description, date, and status while relating to the people and resources needed to complete it. This keeps the information structure explicit rather than scattering it across unrelated screens or code.
Use the following documentation when you develop such a model:
| If you need to | Start here |
|---|---|
| Define a reusable type of information and its behaviour | Classes |
| Understand an individual instance and the distinction between objects and values | Objects |
| Express rules and methods over modeled information | Certain important constructs |
| Represent information carried by a relationship between two classes | Link Objects and association classes |
| Find only objects already loaded in the current application instance | allLoadedObjects |
| Respond when an object changes | Acting on object changes |
Example: expressing a modeled rule
You can define a method on a class and implement it with OCL (Object Constraint Language). A method marked IsQuery promises that it has no intentional side effects, allowing it to be used in OCL expressions.
For example, the following expression selects Thing objects for which the query method returns true:
Thing.allinstances->select(x|x.MyMethod(x.SomeInt))
Keep rules dependent on modeled information in the model. If a rule needs external or ambient data that is not available in the model, make that data available before expecting OCL to evaluate the rule.