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.

“The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system’s blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components.”

The most important thing to understand is, that UML is a language for specifying! It is not a method or procedure. With UML you define a software system -  UML is the language who writes the blueprint and does not specify itself in that methodology or process.

Following domains can be defined with notation and semantics:
- Use case model
- Communication model
- State or dynamic model
- Logical or class model
- Physical component model
- Physical deployment model

UML also offers the possibility for extending the UML for your specialized needs (for example Business Process Modeling extensions). For further information on Business Process Modeling take a look at the whitepapers BPM.