Class diagram is UML structure diagram which shows structure of the designed system at the level of classes and interfaces, shows their features, constraints and relationships
A class is a classifier which describes a set of objects that share the same
- features
- constraints
- semantics (meaning).
Class Diagrams: UML class diagrams model static class relationships that represent the fundamental architecture of the system. Note that these diagrams describe the relationships between classes, not those between specific objects instantiated from those classes. Thus the diagram applies to all the objects in the system.
A class diagram consists of the following features:
- Classes: These are titled boxes represent the classes in the system and contain information about the name of the class, fields, methods and access specifiers. Abstract roles of the class in the system can also be indicated.
- Interfaces: These are titled boxes represent interfaces in the system and contain information about the name of the interface and its methods.
A class is shown as a solid-outline rectangle containing the class name, and optionally with compartments separated by horizontal lines containing features or other members of the classifier.
Class name should be centered and in bold face, with the first letter of class name capitalized (if the character set supports upper case).
ATTRIBUTES AND OPERATIONS/METHODS
A class is shown with three compartments, the middle compartment holds a list of attributes and the bottom compartment holds a list of operations. Attributes and operations should be left justified in plain face, with the first letter of the names in lower case.
RESPONSIBILITIES OF CLASSES
- Knowing
a. knowing about private encapsulated data
b. knowing about related objects
c. knowing about things it can derive or calculate - Doing
a. doing something itself, such as creating an object or doing - Calculation
a. initiating action in other objects
b. controlling and coordinating activities in other objects
Examples a Sale is responsible for knowing its total (POS example) a Sale is responsible for creating SalesLineItems
ABSTRACT CLASS
Abstract class is defined as a class that can’t be directly instantiated. Abstract class exists only for other classes to inherit from and to support reuse of the features declared by it. No object may be a direct instance of an abstract class, although an object may be an indirect instance of one through a subclass that is non abstract.
The name of an abstract class is shown in italics.
An abstract classifier can also be shown using the keyword {abstract} after or below the name.
An abstract class is a class that contains one or more methods that do not have any implementation provided. Suppose that you have an abstract class called polygons . It is abstract because you cannot instantiate it. If you ask someone to calculate area of a polygon, the first thing they will most likely ask you is “Which polygon?” Thus, the concept of a polygon is abstract. However, if someone asks you to calculate area of a circle, this does not pose quite the same problem because a circle is a concrete concept. You know how to calculate area of a circle. You may also know how to calculate other polygons, such as square.
STANDARD CLASS STEREOTYPES
Standard class stereotypes include:
- «focus»
- «auxiliary»
- «type»
- «utility»
«focus» Focus is class that defines the core logic or control flow for one or more supporting classes. The supporting classes may be defined either explicitly (This is the manual approach to accomplishing the change you wish to have by writing out the instructions/ methods to be done) using auxiliary classes or implicitly (This refers to something that’s done for you by other code behind the scenes) by dependency relationships. Focus classes are typically used for specifying the core business logic or control flow of components during design phase.
«auxiliary» Auxiliary is a class that supports another more central or fundamental class, typically by implementing secondary logic or control flow. The class that the auxiliary supports may be defined either explicitly using a focus class or implicitly by a dependency relationship. Auxiliary classes are typically used for specifying the secondary business logic or control flow of components during design phase.
«type» Type is class that specifies a domain of objects together with the operations applicable to the objects, without defining the physical implementation of those objects. Type may have attributes and associations. Behavioral specifications for type operations may be expressed using, for example, activity diagrams. An object may have at most one implementation class, however it may conform to multiple different types.
«utility» Utility is class that has only class scoped static attributes and operations. As such, utility class usually has no instances.
Visibility of attributes and operations:
Public (+): member of class is directly accessible to other objects; part of public interface
Private (-) : member is hidden from public use; only accessible to other members within the class Protected (#): special visibility scope applicable to inheritance only
Study with Jamila 