Object-oriented analysis focuses on defining the characteristics and behaviors of objects within a system. Many object-oriented methods have emerged internationally. The industry widely accepts UML (Unified Modeling Language).

UML is the standardized modeling language for object-oriented software. Its simplicity, uniformity, and ability to express both dynamic and static information in software design have made it the de facto industry standard for visual modeling languages.

UML consists of three core elements: its basic building blocks, the rules governing how these blocks are put together, and common mechanisms used throughout the language.

UML’s vocabulary includes three kinds of building blocks: things, relationships, and diagrams. Things are abstractions of the most representative components in a model; relationships connect things; and diagrams group related things.

Things

UML has four types of things: structural things, behavioral things, grouping things, and annotational things.

(1) Structural Things (Structural Thing)

Structural things are the “nouns” in a UML model. They typically represent the static parts of a model, describing conceptual or physical elements.

Structural things include:

• Class
• Interface
• Collaboration
• Use Case
• Active Class
• Component
• Artifact
• Node

(2) Behavioral Things (Behavior thing)

Behavioral things are the dynamic parts of a UML model. They are the “verbs” of the model, describing behavior across time and space.

Behavioral things include:

• Interaction
• State Machine
• Activity

(3) Grouping Things (Grouping Thing)

Grouping things are the organizational parts of a UML model, acting like “boxes” that decompose the model. Among all grouping things, the primary one is the Package. A package is a mechanism for organizing elements into groups, serving various purposes. Structural things, behavioral things, and even other grouping things can be placed within a package. Unlike components (which only exist at runtime), a package is purely conceptual (i.e., it only exists during development).

(4) Annotational Things (Annotational Thing)

Annotational things are the explanatory parts of a UML model. These annotational things describe, specify, and mark any element of the model. A Note is the primary annotational thing. A note is a simple symbol attached to an element or a group of elements, providing constraints or explanations.

Relationships

UML defines four types of relationships: dependency, association, generalization, and realization.

Dependency (Dependency)

A dependency is a semantic relationship between two things where a change in one thing (the independent thing) affects the semantics of the other (the dependent thing). Graphically, a dependency is drawn as a dashed line, which may be directed.

Association (Association)

An association is a structural relationship that describes a set of links, where a link is a connection between objects. Aggregation is a special type of association that describes a structural relationship between a whole and its parts. Associations can be labeled with multiplicity and role.

Association, Aggregation, Composition

Association: A structural relationship describing a set of links (connections between objects). Multiplicity and role can be labeled on an association. E.g., Employer and Employee.

Aggregation: The lifecycle of the part and the whole are inconsistent. If the whole disappears, the part still exists and can exist independently of the whole. E.g., Class and Student, Company and Employee.

Composition: The lifecycle of the part and the whole are consistent. If the whole disappears, the part also disappears; the part cannot exist independently of the whole. E.g., Person and Brain.

Dependency vs. Unidirectional Association

Dependency is more incidental, temporary. For instance: a person and food; dependent only when hungry, not when full.

Unidirectional association is stronger, indicated by a single-headed arrow. For instance: a person and oxygen, a fish and water.

Generalization (Generalization)

Generalization is a special/general relationship where objects of a specific element (child element) can substitute for objects of a general element (parent element). This way, child elements share the structure and behavior of parent elements. Graphically, it points to the parent element.

Realization (Realization)

Realization is a semantic relationship between classifiers, where one classifier specifies a contract that another classifier guarantees to execute. Realization relationships are used in two scenarios: between an interface and the classes or components that implement it, and between a use case and the collaborations that realize it.