MDrivenStart:MDrivenStart Package

MDrivenStart Package

This page was created by Hans.karlsen on 2020-07-05. Last edited by Wikiadmin on 2026-07-29.

You use packages in MDriven Designer to organize information classes, establish shared class settings, and create a clear model structure as your application grows.

What a package contains

A package is a container for classes. Every information class belongs to one package. Use packages to group classes that belong to the same area of your model.

For example, a library model can use these packages:

Package	Classes it can contain	Purpose
`Library`	`Book`, `Author`, `Loan`	Groups the classes used to manage the library's catalogue and lending.
`Users`	`Member`, `Librarian`	Groups the classes that represent people using or operating the library.

Packages help you find related classes and communicate the structure of the model. They do not replace associations: associations describe how objects of classes relate to one another.

Name packages for their contents

Package names can influence default association-end names. When a package has a plural name ending in s, associations to classes in that package can receive plural default names.

For example, if Book belongs to a package named Books, an association that represents multiple books may receive the default name Books. Review the generated association-end name and change it when it does not express the role in your model. An association from Author to many Book objects may be clearer as Books, while an association from Library to books on loan may need a role name that reflects loans instead.

Apply a shared superclass

You can assign a common superclass to all classes owned by a package. This is useful when every class in a package must inherit the same common behavior or structure.

A common choice is SysSuperClass. For example, if the classes Book, Author, and Loan all belong to Library, setting the package's common superclass to SysSuperClass gives those owned classes that shared superclass.

Use this setting only when the common superclass is appropriate for every class in the package. If one class has a different inheritance need, place it in a different package or configure its class design accordingly. For details on class inheritance and class settings, see MDrivenStart:MDrivenStart Class.

Build a package hierarchy

A package can be owned by another package. Nest packages when you need to represent a larger area with smaller, related subareas.

For example:

Library
  Catalogue
    Book
    Author
  Lending
    Loan
  Users
    Member
    Librarian

In this structure, Catalogue, Lending, and Users are owned by Library. Each class still belongs to its immediate package.

Keep the hierarchy meaningful. Use nesting to describe a real division in the model, not only to create extra levels. A shallow structure is easier to navigate when the model is small.

Organize classes with packages

When defining information in Define Information, use this approach:

Identify the area of the model that a new class belongs to. For example, place Invoice and InvoiceLine in an invoicing package.
Create or select the package for that area.
Assign the class to that package. Every information class must belong to a package.
If all classes in the package share the same inheritance requirement, configure the package's common superclass.
Create associations between classes based on the relationships you need, then review their default names.
Validate the model. Validation runs when you save and can also be started manually; resolve errors before you run the Prototyper or deploy.

Package design guidelines

Group classes by a recognizable business or technical area, such as Orders, Customers, or Reporting.
Use plural package names ending in s when their default plural association names are appropriate.
Review association-end names after creating associations; defaults are a starting point, not a substitute for a meaningful role name.
Apply a common superclass only when it is valid for every class owned by the package.
Use nested packages to show a stable, understandable hierarchy.
Keep classes, their attributes, and their associations focused on the information area represented by the package.

Contents