Modeling

What

A model is anything used in any way to represent anything else.

A model provides a simpler view of a complex entity because a model captures only a selected aspect. This omission of some aspects implies models are abstractions.

Multiple models of the same entity may be needed to capture it fully.

How

In software development, models are useful in several ways:

a) To analyze a complex entity related to software development.

b) To communicate information among stakeholders. Models can be used as a visual aid in discussions and documentations.

c) As a blueprint for creating software. Models can be used as instructions for building software.

UML Models

The following diagram uses the class diagram notation to show the different types of UML diagrams.

Class Diagrams

Class diagrams model the classes and how they are connected to each other.

📦 An example class diagram:

Object Diagrams

Object Oriented Domain Models

The analysis process for identifying objects and object classes is recognized as one of the most difficult areas of object-oriented development. _{--Ian Sommerville, in the book Software Engineering}

Class diagrams can also be used to model objects in the problem domain (i.e. to model how objects actually interact in the real world, before emulating them in the solution). Class diagrams are used to model the problem domain are called conceptual class diagrams or OO domain models (OODMs).

📦 OO domain model of a snakes and ladders game is given below.

Description: Snakes and ladders game is played by two or more players using a board and a die. The board has 100 squares marked 1 to 100. Each player owns one piece. Players take turns to throw the die and advance their piece by the number of squares they earned from the die throw. The board has a number of snakes. If a player’s piece lands on a square with a snake head, the piece is automatically moved to the square containing the snake’s tail. Similarly, a piece can automatically move from a ladder foot to the ladder top. The player whose piece is the first to reach the 100th square wins.

The above OO domain model omits the ladder class for simplicity. It can be included in a similar fashion to the Snake class.

OODMs do not contain solution-specific classes (i.e. classes that are used in the solution domain but do not exist in the problem domain). For example, a class called DatabaseConnection could appear in a class diagram but not usually in an OO domain model because DatabaseConnection is something related to a software solution but not an entity in the problem domain.

OODMs represents the class structure of the problem domain and not their behavior, just like class diagrams. To show behavior, use other diagrams such as sequence diagrams.

OODM notation is similar to class diagram notation but typically omit methods and navigability.

Deployment Diagrams

A deployment diagram shows a system's physical layout, revealing which pieces of software run on which pieces of hardware.

📦 An example deployment diagram:

_{source:https://commons.wikimedia.org}

Component Diagrams

A component diagram is used to show how a system is divided into components and how they are connected to each other through interfaces.

Package Diagrams

A package diagram shows packages and their dependencies. A package is a grouping construct for grouping UML elements (classes, use cases, etc.).

Composite Structure Diagrams

A composite structure diagram hierarchically decomposes a class into its internal structure.

📦 Here is an example composite structure diagram:

_{source:https://commons.wikimedia.org}

Activity Diagrams

Activity diagrams model workflows.

Sequence Diagrams - Basic

Sequence diagrams model interactions between entities for a given scenario.

📦 Consider the code below.

class Machine {

    Unit producePrototype() {
        Unit prototype = new Unit();
        for (int i = 0; i < 5; i++) {
            prototype.stressTest();
        }
        return prototype;
    }
}

class Unit {

    public void stressTest() {

    }
}

Here is the sequence diagram to model the interactions for the method call prouducePrototype() on a Machine object.

Use Case Diagrams

Use case diagrams model the mapping between features of a system and its user roles.

📦 A simple use case diagram:

Timing Diagrams

A timing diagram focus on timing constraints.

📦 Here is an example timing diagram:

_{Adapted from: UML Distilled by Martin Fowler}

Interaction Overview Diagrams

An Interaction overview diagrams is a combination of activity diagrams and sequence diagrams.

📦 An example:

_{source:https://commons.wikimedia.org}

Communication Diagrams

A Communication diagrams are like sequence diagrams but emphasize the data links between the various participants in the interaction rather than the sequence of interactions.

📦 An example:

_{Adapted from: UML Distilled by Martin Fowler}

State Machine Diagrams

A State Machine Diagram models state-dependent behavior.

Often, state-dependent behavior displayed by an object in a system is simple enough that it needs no extra attention; such a behavior can be as simple as a conditional behavior like if x>y, then x=x-y. Occasionally, objects may exhibit state-dependent behavior that is complex enough such that it needs to be captured into a separate model. Such state-dependent behavior can be modelled using UML state machine diagrams (SMD for short, sometimes also called ‘state charts’, ‘state diagrams’ or ‘state machines’).

An SMD views the life-cycle of an object as consisting of a finite number of states where each state displays a unique behavior pattern. An SMD captures information such as the states an object can be in, during its lifetime, and how the object responds to various events while in each state and how the object transits from one state to another. In contrast to sequence diagrams that capture object behavior one scenario at a time, SMDs capture the object’s behavior over its full life cycle.

📦 An SMD for the Minesweeper game.