Structural Diagrams

The diagrams in this chapter allow you to model the static structure of your system. PowerDesigner provides three types of diagrams for modeling your system in this way, each of which offers a different view of your objects and their relationships:

A class diagram shows the static structure of the classes that make up the system. You use a class diagram to identify the kinds of objects that will compose your system, and to define the ways in which they will be associated. For more information, see Class Diagrams.
A composite structure diagram allows you to define in greater detail the internal structure of your classes and the ways that they are associated with one another. You use a composite structure diagram in particular to model complex forms of composition that would be very cumbersome to model in a class diagram. For more information, see Composite Structure Diagrams.
An object diagram is like a class diagram, except that it shows specific object instances of the classes. You use an object diagram to represent a snapshot of the relationships between actual instances of classes. For more information, see Object Diagrams.
A package diagram shows the structure of the packages that make up your application, and the relationships between them. For more information, see Package Diagrams.

Class Diagrams
A class diagram is a UML diagram that provides a graphical view of the classes, interfaces, and packages that compose a system, and the relationships between them.
Composite Structure Diagrams
A composite structure diagram is a UML diagram that provides a graphical view of the classes, interfaces, and packages that compose a system, including the ports and parts that describe their internal structures.
Package Diagrams
A package diagram is a UML diagram that provides a high-level graphical view of the organization of your application, and helps you identify generalization and dependency links between the packages.
Object Diagrams
An object diagram is a UML diagram that provides a graphical view of the structure of a system through concrete instances of classes (objects), associations (instance links), and dependencies.
Classes (OOM)
A class is a description of a set of objects that have a similar structure and behavior, and share the same attributes, operations, relationships, and semantics.
Packages (OOM)
A package is a general purpose mechanism for organizing elements into groups. It contains model objects and is available for creation in all diagrams.
Interfaces (OOM)
An interface is similar to a class but it is used to define the specification of a behavior. It is a collection of operations specifying the externally visible behavior of a class. It has no implementation of its own.
Objects (OOM)
At the conceptual level, an object is an element defined as being part of the system described. It represents an object that has not yet been instantiated because the classes are not yet clearly defined at this stage.
Parts (OOM)
A part allows you to define a discrete area inside a class or a component. Parts can be connected to other parts or to ports, either directly or via a port on the outside of the part.
Ports (OOM)
A port is created on the outside of a classifier and specifies a distinct interaction point between the classifier and its environment or between the (behavior of the) classifier and its internal parts.
Attributes (OOM)
An attribute is a named property of a class (or an interface) describing its characteristics.
Identifiers (OOM)
An identifier is a class attribute, or a combination of class attributes, whose values uniquely identify each occurrence of the class. It is used during intermodel generation when you generate a CDM or a PDM into an OOM, the CDM identifier and the PDM primary or alternate keys become identifiers in the OOM.
Operations (OOM)
An operation is a named specification of a service that can be requested from any object of a class to affect behavior. It is a specification of a query that an object may be called to execute.
Associations (OOM)
An association represents a structural relationship between classes or between a class and an interface.
Generalizations (OOM)
A generalization is a relationship between a general element (the parent) and a more specific element (the child). The more specific element is fully consistent with the general element and contains additional information.
Dependencies (OOM)
A dependency is a semantic relationship between two objects, in which a change to one object (the influent object) may affect the semantics of the other object (the dependent object).
Realizations (OOM)
A realization is a relationship between a class or component and an interface.
Require Links (OOM)
Require links connect classifiers and interfaces. A require link can connect a class, a component, or a port on the outside of one of these classifiers to an interface.
Assembly Connectors (OOM)
Assembly connectors represent the paths of communication by which parts in your classifiers request and provide services to each other.
Delegation Connectors (OOM)
Delegation connectors represent the paths of communication by which parts inside a classifier connect to ports on the outside of that classifier and request and provide services to each other.
Annotations (OOM)
Java 5.0 and the .NET languages (C# 2.0 and VB 2005) provide methods for adding metadata to code. PowerDesigner provides full support for Java annotations and .NET custom attributes. For language-specific information, see the relevant chapter in Part Two of this book.
Instance Links (OOM)
An instance link represents a connection between two objects. It is drawn as a solid line between two objects.
Domains (OOM)
Domains define the set of values for which an attribute is valid. They are used to enforce consistent handling of data across the system. Applying domains to attributes makes it easier to standardize data characteristics for attributes in different classes.

Parent topic: Building OOMs