UML Diagrams: Class, Statechart, and Activity Diagrams

Introduction to UML Diagrams

• The study of Unified Modeling Language (UML) for this session covers three primary diagram types:     - Class Diagrams     - Statechart Diagrams     - Activity Diagrams

Class Diagram Fundamentals

• A Class Diagram serves as a visual representation of classes and the specific relationships existing between them.

• Within a class diagram, each class may contain:     - Attributes: The data characteristics or properties of the class.     - Operations: The behaviors or functions the class can perform.     - Relationships: The connections the class maintains with other classes.

Components of Class Diagrams

• Associations (Relations):     - Regular Association: A standard connection between two classes.     - Aggregation (Part-of Hierarchy): Represents a relationship where one class is a component of another.     - Generalization (Kind-of Hierarchy): Represents inheritance where a subclass is a specialized version of a superclass.

• Attribute Identification:     - The detection of attributes is highly application specific.     - What is considered an attribute in one system might be classified as a separate class in another system.     - Designers may choose the process of turning attributes into classes depending on system requirements.

• Operation Identification:     - Generic Operations: Derived from general world knowledge (e.g., standard getters/setters).     - Domain Specific Operations: Derived from the Dynamic model and Functional model relative to the specific application area.

Objects vs. Classes

• Object (Instance): Refers to exactly one unique entity or thing.

• Class: A template or blueprint that describes a group of objects sharing similar properties and behavior.     - Examples provided: Author, Account, Work order.

• Class Diagram vs. Instance Diagram:     - Class Diagram: A template used for describing many instances of data. It is particularly useful for establishing taxonomies, patterns, and schemata.     - Instance Diagram: Describes a particular set of objects relating to each other. It is useful for discussing specific scenarios, test cases, and concrete examples.     - Visual Example:         - Class: Inspector.         - Instances: joe: Inspector, mary: Inspector, anonymous: Inspector.

• Attributes and Values:     - Classes define the attribute format (e.g., name: string, age: integer).     - Instances define specific values (e.g., joe: Inspector has name = "Joe" and age = $24$; mary: Inspector has name = "Mary" and age = $18$).

Class Specification and Detail

• Operation: A function or transformation applied to objects within a class. In the Analysis Phase, it is noted that all objects in a class share the same operations.

• Signature: Defined during the Object Design Phase, it specifies the number and types of arguments, as well as the type of the result value.

• Method: The actual implementation of an operation for a class, defined during the Implementation Phase.

• Example: Workorder Class:     - Attributes:         - File_name: String         - Size_in_bytes: integer         - Last_update: date         - Stickies: array[max]     - Operations:         - print()         - delete()         - open()         - close()         - write()         - read()

Detailed Associations and Multiplicity

• Association Characteristics:     - Associations establish relationships among classes.     - By default, an association between two classes is a bi-directional mapping.     - An association describes a set of links, just as a class describes a set of objects.     - In a bi-directional association, Class A can access Class B and vice versa; both classes serve as the agent role.

• Multiplicity Types:     - One-to-one ($1$ to $1$): e.g., A Country has one capital City.     - One-to-many ($1$ to $*$): e.g., A Workorder can have many StickyNotes.     - Many-to-many ($*$ to $*$): e.g., A Mechanic works on many Planes, and a Plane is worked on by many Mechanics.

• Multiplicity Notation Reference:     - $2..4$: Specified Range.     - $0..1$: Zero or One (optional scalar role).     - $1..*$: One or More.     - $0..*$ or $*$: Zero or More.     - $1$: Exactly One.     - $2, 4..6$: Multiple, Disjoint Ranges.     - (Blank): Unspecified.

Hierarchy: Aggregation, Composition, and Inheritance

• Aggregation:     - Models a "part of" hierarchy.     - Useful for the breakdown of a product into component parts.     - UML Notation: Identical to an association but includes a small diamond at the assembly (whole) end of the relationship.     - It is a whole-to-part relationship where the part element can exist without the whole.     - Navigability may be unidirectional or bidirectional.     - Example: Automobile:         - An Automobile (attributes: serial number, year, manufacturer, model, color, drive; operations: purchase) is aggregated from:             - Engine (attributes: horsepower, volume; operations: on, off).             - Wheel (attributes: diameter, number of bolts). Multiplicity noted as $2, 4$.             - Door (operations: open, close). Multiplicity noted as $*$.             - Battery (attributes: amps, volts; operations: charge, discharge).             - Brakelight (operations: on, off).

• Composition:     - A special type of aggregation where the part cannot exist independent of the whole.     - The existence of the part is dependent on the whole.

• Inheritance (Generalization):     - Models a "kind of" hierarchy.     - A notation for sharing similarities while preserving differences.     - UML Notation: An arrow with a triangle pointing to the superclass.     - Example: Cell hierarchy:         - Cell is the base class.         - Subclasses: MuscleCell, BloodCell, NerveCell.         - Further specializations: Striate/Smooth (Muscle), Red/White (Blood), Pyramidal/Cortical (Nerve).

• Aggregation vs. Inheritance Comparison:     - Both describe trees/hierarchies.     - Aggregation tree describes part-of; Inheritance tree describes kind-of.     - Aggregation relates instances (involves two or more different objects).     - Inheritance relates classes (a way to structure the description of a single object).

Specialized Relationships and Roles

• Roles in Associations:     - A role name uniquely identifies one end of an association, written near the class playing that role.     - Usage:         - Necessary for associations between two objects of the same class.         - Useful to distinguish between two different associations between the same pair of classes.     - When not to use: If there is only one association between two distinct classes, the class names function as sufficient role names.

• Dependency (Detailed Design):     - A relationship where one class uses another.     - Reasons for dependency: A message is sent to the other class, one class is part of another's data, or a class is a parameter in an operation.

• Realization (Detailed Design):     - A specialized relationship where the client implements the supplier's specification (interface).     - Example: Interface <<interface>> Shape with the operation Draw(). Classes Square, Circle, and Pentagon "realize" or implement the Draw() operation.

Statechart Diagrams

• A graph where nodes are states and directed arcs are transitions labeled by event names.

• It relates events and states for exactly one class.

• An object model with a set of objects contains a set of state diagrams.

• Types of Operations:     - Activity: An operation that takes time to complete; associated with states.     - Action: An instantaneous operation. Associated with events, or with states (Entry, Exit, Internal Action) to reduce drawing complexity.

• State Definition:     - An abstraction of the attributes of a class; the aggregation of several attributes.     - A state has a specific duration.

• Example: Incident Class States:     - Initial State     - Active     - Inactive     - Closed     - Archived (Final State)

Activity Diagrams

• Shows the flow of control within a system.

• A specific type of statechart diagram where states are activities ("functions").

• Types of States:     - Action State: Cannot be decomposed further; happens "instantaneously" relative to the abstraction level.     - Activity State: Can be decomposed further; the activity itself is modeled by another activity diagram.

• Modeling Logic:     - Decisions: Represented by branches (diamonds) with guard conditions (e.g., [fire & highPriority], [not fire & highPriority], [lowPriority]).     - Concurrency: Synchronization of multiple activities.         - Splitting: Dividing flow into multiple threads.         - Synchronization: Joining multiple threads back into one.     - Example Flow: Open Incident -> Allocate Resources -> Coordinate Resources -> Document Incident -> Archive Incident.

• Swimlanes:     - Actions are grouped into swimlanes to indicate which object or subsystem implements the actions.     - Example categories: Dispatcher, FieldOfficer.