Use case diagram
A use case diagram is a graphical depiction of a user’s possible interactions with a system. A use case diagram shows various use cases and different types of users the system has and will often be accompanied by other types of diagrams as well. The use cases are represented by either circles or ellipses. The actors are often shown as stick figures.
Application
While a use case itself might drill into a lot of detail about every possibility, a use-case diagram can help provide a higher-level view of the system. It has been said before that “Use case diagrams are the blueprints for your system”.
Due to their simplistic nature, use case diagrams can be a good communication tool for stakeholders. The drawings attempt to mimic the real world and provide a view for the stakeholder to understand how the system is going to be designed. Siau and Lee conducted research to determine if there was a valid situation for use case diagrams at all or if they were unnecessary. What was found was that the use case diagrams conveyed the intent of the system in a more simplified manner to stakeholders and that they were “interpreted more completely than class diagrams”.
Class diagram
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system’s classes, their attributes, operations (or methods), and the relationships among objects.
The class diagram is the main building block of object-oriented modeling. It is used for general conceptual modeling of the structure of the application, and for detailed modeling, translating the models into programming code. Class diagrams can also be used for data modeling. The classes in a class diagram represent both the main elements, interactions in the application, and the classes to be programmed.
In the diagram, classes are represented with boxes that contain three compartments:
- The top compartment contains the name of the class. It is printed in bold and centered, and the first letter is capitalized.
- The middle compartment contains the attributes of the class. They are left-aligned and the first letter is lowercase.
- The bottom compartment contains the operations the class can execute. They are also left-aligned and the first letter is lowercase.
In the design of a system, a number of classes are identified and grouped together in a class diagram that helps to determine the static relations between them. In detailed modeling, the classes of the conceptual design are often split into subclasses.
In order to further describe the behavior of systems, these class diagrams can be complemented by a state diagram or UML state machine.
Members
UML provides mechanisms to represent class members, such as attributes and methods, and additional information about them like constructors.
Visibility
To specify the visibility of a class member (i.e. any attribute or method), these notations must be placed before the members’ name:
+ |
Public |
- |
Private |
# |
Protected |
~ |
Package |
A derived property is a property whose value (or values) is produced or computed from other information, for example, by using values of other properties.
A derived property is shown with its name preceded by a forward slash ‘/’.
Scope
The UML specifies two types of scope for members: instance and class, and the latter is represented by underlined names.
- Instance members are scoped to a specific instance.
- Attribute values may vary between instances
- Method invocation may affect the instance’s state (i.e. change instance’s attributes)
- Class members are commonly recognized as “static” in many programming languages. The scope is the class itself.
- Attribute values are equal for all instances
- Method invocation does not affect the classifier’s state
To indicate a classifier scope for a member, its name must be underlined. Otherwise, instance scope is assumed by default.