You can use UML School to learn how to describe the concepts and relationships in your domain before you build them in MDriven Designer.

UML (Unified Modeling Language) gives you a shared visual language for describing a system. In MDriven, your model is not only documentation: it is the basis for the application that MDriven executes. Start by learning to recognize domain concepts, describe their data, and define the relationships and rules between them.

What you will learn

UML School introduces the modeling concepts you need when creating a model in MDriven Designer. You will learn to:

• Identify a class as a domain concept, such as Car, Pupil, or Book.
• Distinguish a class from an object, which is one actual instance of that class.
• Add attributes to hold data on each object, such as a car's license-plate number or a pupil's name.
• Connect classes with associations (also called relations or links).
• Read association endpoint names and cardinalities so that the model states what is allowed and required.
• Decide whether a model is useful by checking whether it represents the domain for its intended purpose.

Start with a class diagram

A class diagram is the preferred starting point for describing information in a domain. It shows classes, their attributes, and the associations between them.

For example, a school model might contain these concepts:

Model element	Example	What it expresses
Class	Pupil	Pupil is a concept in the school domain.
Attribute	Pupil.Name : String	Every pupil object can hold its own name.
Class	BookTitle	BookTitle is a concept separate from a physical book.
Association	Book to Pupil	A book can be connected to its caretaker pupil.

A class is a blueprint; an object is an instance of that blueprint. For example, Car is a class, while a particular car with license plate ABC is an object of that class. Read Documentation:Class for the class concept in MDriven.

Read associations from one endpoint to the other

An association has two endpoints. Each endpoint has a name and a cardinality. When you follow an association from one class to the other, read the name at the far endpoint.

For example, if Car has an association to Brand named BrandOfTheCar, and the opposite endpoint is named Cars, you can read the model in both directions:

• A car has a brand of the car.
• A brand has cars.

Cardinality states how many objects may occur at an endpoint. Common markings include:

Cardinality	Meaning	Example
0..1	Zero or one	A car may have zero or one assigned parking space.
1	Exactly one	Each book must have one book title.
*	An unlimited number	A brand can have many cars.

For a fuller guided explanation, read Training:Short introduction to UML– class diagram.

A practical learning path

Follow this sequence when you are new to UML and MDriven modeling.

1. Read Documentation:What is UML to understand UML as a language for visualizing and communicating a system design.
2. Work through Training:Short introduction to UML– class diagram. Practice with a small domain you know, such as a school, library, or vehicle register.
3. Review Documentation:Class diagrams for class-diagram notation and its role in a running MDriven system.
4. Open Documentation:MDriven designer overview Part 1 and create a diagram in MDriven Designer. Add classes by right-clicking inside a diagram and choosing Add a class.
5. Put each class in a package as needed. A package groups model elements and can be used to section a system or represent a namespace.
6. Return to your diagram and check that every class, attribute, association name, and cardinality expresses a fact that matters to the domain.
7. Continue with Training:UML Inheritance when you need to describe specialized forms of a common concept.

Model the domain, not the implementation

A model is always a model of something. It is a simplified description of real concepts, selected for a purpose. There is no universal model that is correct in every context.

For example, you can represent a car's brand in two different ways:

• As an attribute on Car, when you only need a text value.
• As a Brand class associated with Car, when a brand has information of its own or relates to many cars.

Choose the representation that supports what your system must do. UML helps you discuss and maintain this system gist independently of technology choices. For the reasoning behind this approach, see Training:Praise to UML.

Use diagrams as views of one model

In MDriven Designer, a diagram is a representation of model elements; it is not the model element itself. You can show the same class on more than one diagram without creating duplicate classes. This lets you make diagrams that explain different parts of the same model.

For example, you might show Pupil on a school overview diagram together with Class, then show the same Pupil class on a lending diagram together with Book. Both diagrams refer to the same class in the repository.

Next steps

Once you can describe classes and associations, extend the model only when the domain requires it:

• Use Training:UML Inheritance when one concept is a specialized form of another.
• Use state diagrams when an object's allowed behavior depends on its current state; see Documentation:MDriven designer overview Part 1.
• Keep diagrams focused on communication. Add separate diagrams to provide navigation and different views of a larger model.

See also

• Documentation:What is UML
• Documentation:Class diagrams
• Training:Short introduction to UML– class diagram
• Documentation:MDriven designer overview Part 1
• Training:UML Inheritance