Classes

Copyright 2008-2010 ManyDesigns srl. All rights reserved.

Contents

  1. 1 Definitions
  2. 2 Purpose
  3. 3 Fields
  4. 4 Special operations
  5. 5 Relationships

Definitions

In Portofino, and more generally in object oriented design, the term "class" refers to a class of objects. An "object" on the other hand is an instance of a class.

If you find these definitions confusing, think of classes as tables in a database and of objects as rows in those tables. Comparing an object oriented system like Portofino to a relational database is not 100% correct but often makes things clearer.

The important thing is that you, as a model/designer/developer, will be in charge of defining the classes, while the users of your application will be working with objects. Both aspects are present as the two levels of Portofino: in the "upstairs" level we work with classes, in the "downstairs" level we work with objects.

Purpose

A class represents something in the application domain. For instance, an application for a telephone company could have a "Subscription" class to represent the subscriptions the company has with its customers. You can have as many classes as you need in your application: one class for a basic application or a hundred for a complex one. Requirements management is the fundamental activity to do to establish what classes (and generally what model) is right for your application.

Fields

In the Basic information group:
  • Name: the name of the physical table used to represent this class in the database.
  • Pretty name: the singular name used to present this class and its objects in the user interface.
  • Pretty plural: the plural of 'pretty name', used in some parts of the user interface.
  • Order: the relative order of the class when the class is used in a list, such as the the tab list.
  • Tab: if checked, the class will appear in the tab list downstairs. Use this to provide a simple access to the main classes of your application.
In the Advanced information group:
  • Abstract: whether the class is abstract in an object-oriented sense. If checked, it will not be possible to create objects of this class directly, but only through its child classes.
  • Parent class: the parent class if you use inheritance.
  • Relationship: whether the class behaves as a relationship connecting other classes, rather than as a standalone class. In database terms, this marks the 'intersection tables' which are used to represent many-to-many relationships.
  • Don't link: if checked, objects of this class will be shown by their name but no link will be provided. Leave this unchecked for main classes; check it for secondary classes that represent pick-lists.
  • Read Only: if checked, all attributes of objects of this class will be not updatable,

Special operations

Permissions: this button allows you to access the class' permission page.

Relationships

In the lower part of a class' details page, you find several relationships in three groups.

First group:
  • Attributes: the class' attributes.
  • One-to-many relationships: relationship attributes that point to this class.
  • Child classes: this is the inheritance relationship (see field parent class) seen from the parent class.
Second group:
  • Visible by user groups: user groups that have visibility on the class. If empty, all users have visibility.
  • Listeners: the class's listeners.
  • Class operations: this and the following thre relationships represent various types of custom operations on the class.
  • Object operations: see above.
  • Object set operations: see above.
Third group:
  • Portlet reports: the class' portlets (lightweight graphical, interactive reports)
  • Portlets on summary page:
  • JasperReports: the class' reports (heavyweight reports, sometimes suitable for printing).

Next: Attributes