You use Define information to model the things your application stores and the relationships and behavior those things need, such as customers, invoices, and cars.

Model your application information

An information class is the model definition of a kind of thing. For example, you can define the classes Customer, Invoice, and Car. Each class belongs to one Package, which groups related classes in the model.

Use a class when you need to describe many objects of the same kind. A Customer class can represent many individual customers; each individual customer is an object of that class.

Build a class step by step

1. Create or select the Package that should contain the class. For example, place Customer and Invoice in a package for customer and billing information.
2. Add the class and give it a distinct, meaningful name, such as Customer.
3. Add attributes for single values that belong to the class. For example, a customer can have Name:String and Email:String?.
4. Add associations for links between classes. For example, connect Customer to Invoice when a customer can have invoices.
5. Add methods when the class needs named logic. For example, an Invoice method can calculate or update information about that invoice.
6. Add a state machine when objects need to move through defined stages, such as an invoice progressing from draft to sent to paid.
7. Validate the model before you run it or deploy it.

Choose the right class member

You need to model	Use	Example
A kind of thing with its own objects	A class	Invoice represents each invoice in the system.
One simple value on an object	An attribute	InvoiceNumber:String stores one invoice number.
A connection to objects of another class, including lists	An association	A Customer is associated with its invoices.
Logic that belongs to the class	A method	Invoice has a method that returns a value or performs an update.
A controlled lifecycle with stages	A state machine	An invoice can progress through draft, sent, and paid states.

Classes and Packages

A class must belong to one Package. Use Packages to keep the model understandable as it grows. For example, keep Customer and Invoice together when they belong to the same area of the application, rather than placing unrelated classes together.

Open Class to set the Package for a class and to define class-level settings. A class can also have a default string representation. The user interface uses this representation when it displays an object without being told which attribute to show. For a Customer, the representation would typically use a string attribute such as the customer's name.

Attributes: values on a class

An attribute holds one simple value for each object of a class. Its type must be stated. Attributes can be nullable, which means they can hold no assigned value; for an integer, no value is different from zero.

For example:

Name:String
Email:String?

Here, Name must have a string value, while Email may be empty. Do not use an attribute for a list of related objects; use an association for that relationship instead.

For attribute types and settings, see Attributes. For attribute syntax, nullable values, persistence, and derived attributes, see SingleAttribute.

Associations: links between classes

An association describes how classes relate. Use it whenever the value is another modeled object or a collection of modeled objects.

For example, model the connection between Customer and Invoice as an association. This lets a customer be related to its invoices instead of trying to store invoice information in a single customer attribute.

See Associations to add or change an association.

Methods: behavior on a class

A method defines named logic for a class. A method can be a query, meaning that it uses OCL and does not change data, or an action method, meaning that it can use action language and change data.

A method signature includes its name, arguments, and return type. For example:

MyMethod(argument1:String;argument2:Double):String

Use a query method when you need to calculate or retrieve a result without changing the model. Use an action method when the operation must update information. See Methods for method settings and signatures.

State machines: information over time

A state machine is a special kind of attribute that records how objects of a class progress over time. Use one when the permitted stages matter to the application.

For example, an Invoice can have states such as draft, sent, and paid. This makes the invoice's current stage part of its modeled information rather than an informal convention.

Check the model

The model must be coherent before it can run. Validate after you add or change classes, Packages, attributes, associations, methods, or state machines. Duplicate class names are one example of a validation error.

Validation runs when you save the model, and you can also run it manually with the Validation button. Resolve all errors before starting the Prototyper or deploying to the server. See Verify.

Continue

After defining the information structure, create diagrams to document how classes relate, define views for working with the information, and define user actions for how users interact with those views. Return to Start to choose the next task.

See also

• Class
• Attributes
• Associations
• Methods
• Verify