You can use MDriven Designer to turn a UML information model into a working prototype, so this page is for Sparx Enterprise Architect users who want to validate requirements by working with modeled data rather than only drawing diagrams.

From drawing to executable information

A UML diagram can describe classes, attributes, and relationships. In MDriven Designer, you can also run the model and work with the information it defines. This makes the model a place to test whether the information structure, navigation, and business rules match the requirement.

For example, a school may have many classes, and each class may have many pupils. In a diagram, this is a hierarchy of concepts. When you prototype the same model in MDriven Designer, you can create a school, add classes, and add pupils. Working with those records exposes questions that a diagram alone may not reveal, such as:

• Should classes be shown on the school document or opened in a separate document?
• What name should the multi-valued association have in the user interface?
• Which books count toward a school's book value?
• What does a book state such as Beyond repair mean for that calculation?

Keep each modeled detail small and explicit. Complexity comes from the total set of related details, not from making an individual class, association, or rule difficult to read.

Build and run a small model

Use a small domain model to validate the approach before transferring a larger specification.

1. Create a class named School with a Name attribute.
2. Create a class named Class and associate it with School so that a school can have multiple classes.
3. Create a class named Pupil with a Name attribute and associate it with Class so that a class can have multiple pupils.
4. Set an intentional name for each multi-valued association where the generated default plural form does not express the domain clearly. For example, use Classes for the collection of classes belonging to a school.
5. Save the model.
6. Start prototype running and choose XML storage for prototype data when prompted.
7. Refresh the model and include Autoforms.

MDriven Designer generates Autoforms from the model. An Autoform is a generated user interface for finding, creating, and editing modeled information. With no manually designed views, the generated forms provide a direct way to test the model.

Test the model with Autoforms

After refreshing with Autoforms included, use the generated seeker and document forms to work with the information.

1. Open the School seeker.
2. Use the create action to create a school.
3. Enter School A in the school document, then save it. Entering the name in the seeker is not the same as setting the name on the school record.
4. Search for the school and open it from the results.
5. Add classes and pupils through the generated association navigation.

At this point, review the result with the people who know the domain. The discussion is now based on real information and behavior: users can see the school, its classes, and the pupils in each class.

Choose how an association is displayed

Autoforms can render an association in different ways. In the demonstrated school example, the Classes association initially appears as a button that opens its content in a separate form. For a school document, it may be more useful to show the class list directly in the document.

1. Select the association between School and Class.
2. Open its Autoforms settings.
3. Change the rendering from Own form to Embed in document.
4. Refresh the model with Autoforms included.
5. Reopen the school document and confirm that its classes are displayed in the document.

Use Own form when the associated information needs its own document-level workflow. Use Embed in document when users need to review or edit the associated collection while working on the parent object.

Rendering	What the user sees	Example
Own form	A navigation button that opens the association content separately.	Open a class collection from a school document when the collection needs a separate work area.
Embed in document	The association content in the current document.	Show a school's classes directly on the school document.

Make business rules readable and testable

You can express derived information with OCL (Object Constraint Language). Test a rule against prototype data, then revise the rule when the domain meaning changes.

For example, assume a school has books and you need a total value. A first rule may total every book. During review, the domain expert may state that books in the Beyond repair state must not contribute to the value. That requirement changes the rule: select the books that are not in that state before calculating the total.

books->select(b | not b.oclIsInState(BeyondRepair))

The example shows two important practices:

• Give iterator variables meaningful short names, such as b for a book.
• Use the available state diagram from the book context to identify the state name used by the rule.

After changing a rule, return to the prototype and create or update representative data. For example, assign books to a school, mark one book as beyond repair, and verify that the displayed total excludes that book. If the result does not match the requirement, revise either the rule or the requirement while both are explicit in the model.

A practical transition approach

Do not treat the transition as a diagram conversion exercise. Use the existing UML model as input to a validation cycle.

1. Choose one bounded business area, such as schools, classes, pupils, and books.
2. Model the classes, attributes, associations, and states needed for one user scenario.
3. Generate Autoforms and create representative prototype data.
4. Walk through the scenario with stakeholders.
5. Record clarified requirements as model structure, state definitions, or OCL rules.
6. Refresh and retest until the prototype reflects the agreed behavior.

This approach makes the specification easier to revisit: the information structure, generated interaction, and tested rules remain connected in the same model.

Watch the Autoforms walkthrough for the school, class, pupil, book, state, and OCL example.

See also

• EvaluationGuide
• WelcomeToMDriven
• Learn OCL