You use a Class to model one kind of information in your application, such as a Customer, Book, or Invoice, and to define the data and relationships that every object of that kind has.

A class belongs to one Package and can contain attributes, associations, and methods. For example, a Book class might have a Title attribute and an association to an Author class.

Define a class

When you create or edit a class, set the properties that describe its role in the model:

Property	What it controls	Example
Package	The container that owns the class. Every information class must belong to a package.	Put Book and Author in a package for the part of the model that manages a library.
Code comment	Background information about why the class exists and how it should be used.	Add a comment such as: Represents a book that can be listed in the library catalogue.
Default string representation	The expression used when a user interface needs to show an object but has not been told which attribute to display.	For Book, use an expression based on its string Title attribute so that an object is shown by title rather than as an unspecified object.
Abstract	Whether the class may be instantiated directly. An abstract class is intended to be a superclass for other classes.	Mark Publication abstract when users should create Book or another subclass, not a Publication object.
Transient	Whether objects of the class are short-lived in the current session rather than persistent.	Use a transient class for information that is needed temporarily during the current session and should not be saved and shared between sessions.

Choose the owning package

A package segments the classes in a model into containers. Assign each class to the package that represents its area of responsibility. Packages can also be nested, and a package can provide a common superclass for its owned classes. See Packages for package structure and naming guidance.

For example, if your model has library information, place Book in the same relevant package as the other library classes. This keeps related classes together and makes the model easier to navigate.

Document the purpose of the class

Write a code comment that records the background and purpose of the class. The comment is part of the model documentation and helps future readers understand why the class was created.

A useful comment answers what the class represents and any important boundary for its use:

Represents a book available in the library catalogue.

Avoid comments that only repeat the class name. For example, A book class adds less information than explaining what kind of book the class represents in the application.

Set a useful default string representation

A user interface sometimes needs a text representation of an object without knowing which of its attributes it should display. The default string representation provides that text.

Choose an expression that identifies the object clearly. It is commonly an expression based on one of the class's string attributes.

For a Book class with a string Title attribute, use the title as the default representation. When a UI displays a Book object without a configured display attribute, the user then sees the book title.

Make the chosen value meaningful to users. A generic or empty value makes lists and references to objects harder to understand.

Use abstract classes for shared structure

A superclass is a class that other classes inherit from. Mark a class abstract when it exists to provide shared structure for subclasses and must not be used directly. An abstract class cannot have objects created from it.

For example:

• Publication can be an abstract superclass.
• Book can inherit from Publication.
• Users create Book objects, not Publication objects.

Use a non-abstract class when the class represents something that users or application logic must be able to create directly.

Add data and relationships

Classes hold information through attributes and connect to other classes through associations. A class can also have methods that perform logic, and it can have a state machine to represent how its objects progress over time. See Define information for the role of these class features.

For example, a Book class can:

• Store its title in an attribute.
• Associate with an Author class to describe who wrote it.
• Use an association to connect a book to the other information it relates to.

See Associations to add or change relationships between classes.

Decide whether objects are persistent

Objects of a class are normally persistent: they are saved and shared between sessions. This is appropriate for business information such as customers, invoices, and books.

Set a class to transient when its objects are short-lived and exist only in memory for the current session. Do not use a transient class for information that must remain available after the session ends or be shared with other sessions.

Keep the model valid

After changing a class, validate the model. Validation also runs when you save the model. Resolve errors before you start the Prototyper or deploy the application; duplicate class names are one example of a model error. See Verify for the validation workflow.

A class can appear in any number of diagrams, and removing it from a diagram does not remove it from the model. Use diagrams to show the attributes and associations that are relevant to a particular discussion. See Diagrams.

See also

• Define information
• Package
• Associations
• Diagrams
• Verify