You use a class in MDriven Designer to define a kind of business object—such as a Customer, Order, or Vehicle—and the data, relationships, and behaviour shared by its instances.

Class and object

A class is a model definition. It describes a group of objects that have the same meaning, attributes, operations, and relationships.

An object is one instance of that class. The class defines what an object can contain; each object holds its own values.

For example, you can model a class named Car with attributes Make, Model, Year, and Color. A particular red 2019 Honda Civic is an object of the Car class. Its values might be:

Class definition	Value on one Car object
Make	Honda
Model	Civic
Year	2019
Color	Red

Think of a class as a classification rather than as one real-world item. Car classifies cars; every Car object is one specific car.

What a class defines

A class can define the following parts of a modelled business concept:

Part	Purpose	Example for Car
Attributes	Values that each object can hold.	Make, Year, and Color
Relationships	Connections between objects.	A Car is related to its Owner.
Behaviour	Operations available for objects of the class.	An action that records a change to a Car.

Use an attribute for a value that belongs to the object itself, such as a name, date, number, or status. Use an association when the value is another model object. For example, do not try to make an attribute whose type is Owner; the reference from a Car to an Owner is an association. See Documentation:Attribute with class type for this distinction.

You represent classes, attributes, operations, and relationships visually in class diagrams. Class diagrams are both a way to communicate the model and the structure that MDriven uses when executing the model.

Model a class deliberately

When adding a class to a model, start with the meaning of the thing you need to represent. Then define only the data and relationships needed for that meaning.

For example, to model customer orders:

1. Create an Order class for one customer order.
2. Add attributes that describe the order itself, such as an order number or order date.
3. Create an association from Order to Customer, because a customer is another object rather than a scalar value.
4. Create an OrderLine class if individual lines have their own data, such as quantity.
5. Model the relationship between Order and OrderLine rather than storing all line information in one Order attribute.

This keeps each class responsible for one clearly defined kind of object and makes relationships explicit in the model.

Inheritance

Inheritance lets a specialized class reuse the definition of a more general class. The general class is the superclass (or base class); the specialized class is the subclass (or derived class).

A subclass inherits the attributes and behaviour of its superclass and can add attributes and behaviour of its own.

For example, you can define a Vehicle superclass with Make, Model, Year, and Color. You can then define Car, Truck, and Motorcycle as subclasses:

Class	Inherited from Vehicle	Class-specific definition
Car	Make, Model, Year, Color	Number of doors; fuel efficiency
Truck	Make, Model, Year, Color	Cargo capacity
Motorcycle	Make, Model, Year, Color	Motorcycle-specific data as required by the model

Use inheritance when the specialized classes are genuinely forms of the general class and share the same core meaning. Put shared data and behaviour on the superclass. Put data that applies only to one specialization on that subclass.

MDriven uses UML (Unified Modeling Language) for modelling and is implemented using C#. When reasoning about class structure and inheritance, UML and C# concepts provide useful background.

Class behaviour and actions

In MDriven, a class action is behaviour associated with a class. Its context is an instance of that class, so self refers to that object. Class actions are globally available in views that show objects of the class.

For example, if you add an action to Order, the action operates with an Order object as its context. This makes it suitable for behaviour that belongs to an Order regardless of which view displays it.

A class action is different from a ViewModel action. A ViewModel action belongs to one view and uses view-focused variables such as vCurrent_ and vSelected_; a class action cannot use those variables. Choose a class action when the behaviour belongs to the model object itself, and choose a ViewModel action when it depends on the state or selection of a particular view.

See also

• Documentation:Class diagrams
• Documentation:Attribute with class type
• Documentation:Class actions
• Documentation:ViewModel actions
• Documentation:OCLOperators classfromstring

[[Category:Classes: definition and instances [Beginner]]