Introduction to Modeling using UML

Modeling Basics

Software Modeling

Creating abstractions of a system to understand, communicate, and design it before building. Models manage complexity by focusing on relevant aspects and hiding unnecessary detail.

Unified Modeling Language (UML)

A standardized visual modeling language for specifying, visualizing, constructing, and documenting software systems. It provides a common notation across structural and behavioral diagrams.

Why Model

Models help teams visualize a system, specify its structure and behavior, provide a template for construction, and document decisions — reducing risk and improving communication.

Abstraction

Focusing on the essential characteristics of a thing relative to a purpose while ignoring irrelevant details — the fundamental technique that makes modeling useful.

Structural vs. Behavioral Models

Structural diagrams (e.g., class, component) show what the system is made of; behavioral diagrams (e.g., use case, sequence, activity, state) show how it behaves over time.

Unified Process Context

Unified Process (UP)

An iterative, incremental software engineering process spanning the full lifecycle. This course introduces UP's key concepts — use-case-driven requirements, controlled iterative development, and early architecture validation.

Four Phases of UP

Inception (scope and business case), Elaboration (architecture and most requirements), Construction (build the bulk of the system), and Transition (deploy to users), each ending in a milestone.

Nine Disciplines of UP

Business Modeling, Requirements, Analysis & Design, Implementation, Test, and Deployment (engineering) plus Configuration & Change Management, Project Management, and Environment (supporting).

Use-Case-Driven, Architecture-Centric

UP uses use cases to drive the lifecycle and establishes a stable, executable architecture early. UML is the notation used to express both throughout the process.

Controlled Iterative Development

Developing in planned iterations that confront risk early and validate the architecture with working code, with UML models evolving across iterations.

Use Case Diagrams

Use Case Diagram

A behavioral UML diagram showing actors, use cases, and their associations — giving a high-level picture of system scope and who interacts with which functions.

Actor

An external role (person, system, or device) that interacts with the system to achieve a goal. Drawn as a stick figure, an actor represents a role rather than a specific individual.

Include and Extend

Use-case relationships: include factors out shared behavior used by several use cases; extend adds optional or conditional behavior to a base use case at defined extension points.

Structure Diagrams

Class Diagram

A structural UML diagram showing classes, their attributes and operations, and the relationships among them — the cornerstone for modeling a system's static design.

Class

A blueprint defining the attributes (data) and operations (behavior) shared by a set of objects. In UML it is drawn as a three-compartment box: name, attributes, operations.

Association

A structural relationship indicating that objects of one class are connected to objects of another, often labeled with multiplicity (e.g., 1, 0..*) and a role name.

Multiplicity

A notation on an association end specifying how many instances may participate (e.g., 1, 0..1, 1..*, *), constraining the relationship between classes.

Aggregation vs. Composition

Aggregation is a whole-part relationship where parts can exist independently (hollow diamond); composition is a stronger whole-part where parts' lifecycle depends on the whole (filled diamond).

Generalization (Inheritance)

A relationship where a subclass inherits attributes and operations of a superclass, shown as a hollow triangle pointing to the more general class — modeling 'is-a' relationships.

Component Diagram

A structural diagram showing software components and their interfaces and dependencies, used to model the high-level organization and deployment-ready pieces of a system.

Behavior Diagrams

Sequence Diagram

An interaction diagram showing how objects collaborate over time through messages, with lifelines and activation bars — ideal for realizing a use-case scenario in design.

Message / Lifeline

In a sequence diagram, a lifeline represents a participant over time and a message represents a communication (call or signal) sent from one participant to another.

Activity Diagram

A behavioral diagram modeling workflow as a flow of actions, decisions, forks, and joins — useful for business processes and complex use-case logic.

State Machine Diagram

A behavioral diagram showing the states an object can be in and the transitions between them in response to events — used for objects with significant lifecycle behavior.

Realizing Use Cases in Design

Connecting requirements to design by showing how collaborating objects (often via sequence diagrams) fulfill the behavior described in a use case.

Applying UML

Best Practices of Modern Software Engineering

Develop iteratively, manage requirements, use component-based architectures, model visually with UML, verify quality continuously, and control change — practices UP and UML support together.

Architecture-Centric Modeling

Using UML to define and validate a system's architecture early, providing a robust framework that guides detailed design and reduces downstream risk.

Choosing the Right Diagram

Selecting diagrams by purpose: use case for scope, class/component for structure, sequence/activity/state for behavior — using just enough modeling to communicate effectively.

Tool Support for Modeling

Automated modeling tools help create, maintain, and share UML models and can describe process roles, activities, and artifacts — supporting consistent application of UP.

Just Enough Modeling

Modeling should add value, not ceremony. Create the models that aid understanding, communication, and design decisions, and avoid documenting detail that won't be used.