You can use UML to capture the enduring meaning of a software domain—its system gist—so that you can discuss and evolve the system independently of changing technology and interface trends.

UML (Unified Modeling Language) is a standard language for describing software systems. In MDriven, UML is used to model the information, relationships, rules, and allowed changes that define the domain.

Why distinguish gist, modernity, and fashion?

When you discuss a system design, separate the discussion into three areas. This helps you choose the right basis for each decision and prevents implementation preferences from obscuring the domain problem.

Area	Meaning	How to make decisions	Software example
System gist	The essential information, rules, and concepts that make one system different from another.	Research the domain and agree on what must be true.	An order has a customer, order lines, and rules for when it may be confirmed.
Modernity	Current techniques, tools, and implementation strategies used to build and operate the system.	Evaluate practices in the development community, the pace of change, and the benefit of adopting them.	The selected persistence technology, deployment approach, or UI framework.
Fashion	Preferences that make a product feel familiar, attractive, or current to its audience.	Let users and the market guide the choice. Test alternatives or take a decision when there is no factual answer.	Visual styling, interaction patterns, and the presentation of controls.

These areas influence one another, but they are not the same thing. A system can use current technology and a fashionable interface while still describing its business information poorly. Conversely, a clear domain model can outlast several implementation and interface changes.

Understand the system gist

System gist is the part of the system that expresses what the domain is about. It includes the information the business needs, the relationships between that information, and the rules that protect its consistency.

For example, consider a car-related domain. The concepts Car and Brand are part of the gist. A car may have a license-plate number and be associated with a brand. Whether the application is delivered through one user-interface technology or another is a modernity decision. The visual treatment of the car-selection screen is a fashion decision.

The same distinction applies outside software:

• A car manufacturer uses design and engineering knowledge to define what the car is and how its parts work together. That is the system gist. Manufacturing equipment and supplied components are modernity choices. The appearance of the body is strongly influenced by fashion.
• A surgeon needs knowledge of anatomy, diagnosis, and treatment. That knowledge is the gist. Diagnostic equipment and surgical techniques are modernity. A new tool does not replace understanding what to examine or how to act on the result.

Software development differs because it produces systems for many different domains. Each domain has its own gist. Systems may share technologies and user-interface conventions, but the information and rules that distinguish a booking system from an order system must still be discovered and described.

Use UML to describe the domain

UML provides a common notation for making the system gist visible. Start with the information the domain creates, uses, and changes. This follows the principle described in Information design: when you understand the important information, you can identify which processes create or evolve it.

A UML class diagram describes concepts as classes, their data as attributes, and the connections between concepts as associations. For the car example, you might model:

• a Car class with a LicensePlateNumber attribute;
• a Brand class with a Name attribute; and
• an association that states which brand a car has.

Use the language that people in the domain use. Naming a class Car rather than an abstract technical name makes the model easier for domain experts and developers to discuss together. See Training:Short introduction to UML– class diagram for classes, attributes, associations, and cardinality.

UML can also describe more than static information:

• Use inheritance when a specialized concept has the properties of a more general concept. For example, Apple and Orange can be specializations of Fruit.
• Use state machines when an object has defined states and transitions. For example, an order may only move to a production state after its deposit is paid.

In MDriven, the UML model is the core definition of the model. Rules can use OCL (Object Constraint Language) to navigate that model, so the rule uses the same domain terms as the diagram.

Classify design discussions before deciding

Use the following steps whenever the team discusses a significant design choice.

1. State the decision in domain language.
2. Ask whether it changes the business concepts, information relationships, or business rules. If it does, it is a system-gist decision.
3. If it concerns how the system is built, deployed, stored, or integrated, treat it as a modernity decision.
4. If it concerns what users find appealing, familiar, or easy to adopt, treat it as a fashion decision.
5. Use evidence appropriate to the category: domain research for gist, technical evaluation for modernity, and user or market feedback for fashion.
6. Record the resulting gist in the UML model rather than leaving it only in code or in the memories of individual developers.

For example, a team may be deciding how to handle a paid deposit before production starts:

Question	Category	Appropriate evidence
Must a deposit be paid before production can start?	System gist	The business policy and the consequences of violating it.
Where is the rule implemented and how is it persisted?	Modernity	The selected implementation strategy and its operational consequences.
How should the application show that a deposit is missing?	Fashion	User feedback and the conventions users recognize.

The rule itself belongs in the model. A state machine and an OCL guard can express that production cannot start until the required information is present. The screen design and the underlying technology may change later without changing that business meaning.

Keep the gist independent of temporary choices

Technologies and interface conventions evolve quickly. They are important, but they should not become the only representation of what the system means. When the only description of the system is implementation code, the collective understanding of the domain is held mainly by the people who remember it.

A UML model gives developers, domain experts, and decision-makers a shared representation of the system. It makes it easier to ask focused questions:

• Is this a fact about the domain or an implementation preference?
• Which concepts and relationships must remain true when the implementation changes?
• Which rule protects the information from entering an invalid state?
• Does the model use the domain's own vocabulary?

A model is always a simplified representation made for a purpose. Its value comes from whether it serves that purpose, not from adding every possible detail. The class-diagram introduction explains this principle and shows why different valid models can be appropriate for different needs.

Continue learning

This chapter establishes why UML matters: it gives you a language for discussing and maintaining system gist. Next, consider what happens when a team has no shared UML representation of that knowledge in Training:What if UML was forbidden.

See also

• Training:Introduction - The MDriven Book
• Training:Information design
• Documentation:What is UML
• Training:Short introduction to UML– class diagram
• Training:What if UML was forbidden