An information system is a system that lets people and other systems create, find, transform, and use information to complete defined tasks; this page is for anyone defining such a system with MDriven.
What an information system contains
An information system has two connected parts:
- An information model defines what information the system can hold.
- A ViewModel defines how a specific use case handles a selected part of that information.
For example, a fruit-handling system can model FruitBowl and Fruit. A bowl can contain many fruits. Apple, Orange, and Banana can be different kinds of Fruit. This is an example of classes, associations, inheritance, and polymorphism in an information model.
A ViewModel can then define the use case find an apple, view its comment, and update the comment. The model defines the available information; the ViewModel defines how that information is presented and changed for this task.
Model the information
Use MDriven Designer to create a model of the business concepts, their properties, and their relationships.
For example, an order system may contain these classes:
| Class | Example attributes | Example relationship |
|---|---|---|
Order
|
OrderNumber, OrderDate
|
An order has order lines. |
OrderLine
|
Quantity
|
An order line refers to one product. |
Product
|
Name, UnitPrice
|
A product can occur on many order lines. |
The model decides rules such as whether one fruit can be in only one bowl, or whether it can be associated with several bowls. If the relationship itself needs data, such as the percentage of a fruit allocated to a bowl, model that data on the association.
Use OCL (Object Constraint Language) to navigate, select, and transform information in the model. For example, a ViewModel can use an OCL expression to find apples whose comment matches text entered by a user.
Define use cases with ViewModels
A ViewModel is a collection of expressions compiled to support one use case. It defines a view or perspective of the information in the system.
For example, an Order processing ViewModel can show the current order, its lines, the selected product, and actions needed by an order handler. This avoids requiring the user to move between unrelated screens or copy information between them.
You can begin with AutoForms. AutoForms create mechanical ViewModels from the classes, attributes, and associations in your model so that users can create, show, and edit the modeled information. The result is functional, but it is driven by the model structure rather than by a specific user task.
Adopt an AutoForm when you want to change it manually. An adopted AutoForm is retained when you recreate AutoForms. Manual changes to an AutoForm that has not been adopted are discarded when it is recreated.
Build ViewModels iteratively with feedback from the people who perform the task. For example, start with an order-entry screen that lists order lines, then add the customer credit information if order handlers need it while entering an order.
Keep information access on the server
An Access Control System is the part of an information system that restricts each authenticated user to the information they are authorized to use. It must filter the complete available information to the approved subset.
With MDriven Turnkey, the ViewModel defines the information slice for a use case. The ViewModel reduction is performed on the server, using declarative OCL expressions, and the resulting slice and its changes are streamed to the client.
For example, a customer-service ViewModel can show a service agent the orders assigned to that agent's organization. The access-control rule must be enforced on the server, not only by hiding rows in a browser or desktop client.
Read Training:Information security before defining access rules for information with security requirements.
Document the enterprise context
You can document an information system in five connected axes:
| Axis | What you document | Example |
|---|---|---|
| Processes | Steps and the stakeholder motivation for the process. | A process step is approve purchase order. |
| Information | Business catalog terms, their states, and their implementation as classes or attributes. | The catalog term Purchase Order is implemented by the PurchaseOrder class.
|
| Actors | Named business roles and their process responsibilities. | A Purchaser approves purchase orders. |
| Applications | Business tools, application modules, and the information they contain. | The purchasing application contains the approval module. |
| Infrastructure | Nodes on which applications or application parts depend. | The approval module depends on a specific server. |
Process steps are the central cross-reference. Define each step's inputs, outputs, and resources. A resource is information needed by a process step that is not supplied as an input. Express inputs, outputs, and resources with catalog terms.
This documentation lets you trace an infrastructure change to affected applications, process steps, actors, and stakeholders. For example, before decommissioning a server, identify the application modules that depend on it, the process steps using those modules, and the actors affected by an outage.
When business terminology and implementation terminology differ, keep catalog terms separate from classes and define the lexicon between them. When they use the same terminology, the catalog term and class can share a name, such as Purchase Order and PurchaseOrder.