Generalizations
With a generalization you indicate inheritance. If it’s drawn from a specific classifier to a general classifier, the generalize implication is that the source inherits the target’s characteristics.

Aggregations
Aggregations are depicting elements which are made up of smaller components. This aggregation relationships will be shown by a white diamond-shaped arrowhead pointing towards the target or parent class.

Association Classes
With an association class you can construct an association connection to make operations and attributes.

Dependencies
If you need to model a wide range of dependent relationships between model elements you use dependencies. This will be done early in the design process. Later on the dependencies will be stereotyped or replaced with more specific data.

Traces
With traces yo can easily track requirements or model changes, because it is a specialization of a dependency, linking model elements or sets of elements, representing the same idea across models.

Realizations
A realization expresses traceability and completeness in a model.

Nestings
Nestings are connectors showing source elements within a target element.

Click to read part 1 of the UML 2 Class Diagram

Definitions:
Classes
Classes are elements that define the attributes and behaviors of an object . A behavior describes possible messages of the class along with operations. Within classes you can also define constraints, tagged values and stereotypes.

Class Notation
A class shows the name of the class and optionally the name of the operations and attributes. The compartments divides the class name,  attributes and operations.

Interfaces
The interface is a contract with a specification of behaviors that implementers agree to meet. In an interface, classes are guaranteed to support the required behavior. You may draw the interface in a similar style to a class, specified with operations, or you draw it as a circle with no details to explicit operations.

Tables
Tables are not a part of the base UML, it’s more an example of what can be done with stereotypes. When a table is drawn you can see a small table icon in the upper right corner.

Following in part 2 of the UML Class Diagram.

8. In a deployment model the physical architecture of the system is defined. Try to start capturing early the physical deployment chararcteristics, the hardware, operating system, network, interfaces and the support software of the new system for the need of a disaster recovering.

9. To build the system you take a discrete pieces of the model and assign it to one or more developers. Now you assign a Use Case to the development team, with their own, requiered screens, business objects, database tables, and related components.

10. In the following test phases it is very important to track all defects  against the related model elements to manage “scope creep. For example:
- System test defects against Use Cases
- Unit Test defects against classes

11. Always update and refine the model during the working procedure and assess the impact of changes and model refinements on later work.

12. Now it is time to deliver the tested software into a test then production environment. Never undertake a phased delivery! This migration of built sofware from test to production may then occur several times maybe during the whole life of the project.

If you have missed the other articles of our issue “how to use UML”:
click here for part 1
click here for part 2

4. Now you can start to construct a domain model (high level business objects), sequence diagrams, collaboration diagrams and user interface models straight from the in- and outputs of the BPM and the details of the use cases. With this describtion you describe the of the interaction and an interface for users to to execute use case scenarios.

5. Create now the Class Model out of the the domain model, the user interface model and the scenario diagrams. In this precise specification you define the objects in the system, their data or attributes and their behaviour or operations. Use inheritance to abstract domain object into class hierarchies. Scenario diagram messages map to class operations. You can also use existing framework or design pattern by importing an existing model element into  the new system. Do not forget to define tests for each unique class and all class functions.

6. Beginning with the class model you can brake it into discrete packages and components. Than each component represents a deployable chunk of software collecting its behaviour and the data of the classes. The built component model defines the logical packaging of classes. For each component define integration tests to confirm that the component’s interface meets the specifcation given it in relation to other software elements.

7. Do not forget to capture and document all additional requirements and collect them within the model;  try to keep up to date as you do with the model matures.

Keep on reading “how to use UML” here.