Modeling

What

A model is anything used in any way to represent anything else. For example, a class diagram is a model that represents a software design and is drawn using the UML modeling notation.

A model provides a simpler view of a complex entity because a model captures only a selected aspect. For example, a class diagram captures the class structure of the software design but not the runtime behavior.

Multiple models of the same entity may be needed to capture it fully. For example, in addition to the class diagram, a number of sequence diagrams may need to be created to capture various interesting interaction scenarios the software undergoes.

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 - Basic

Class diagrams model class structures in OOP solutions.

Class Diagrams - Intermediate

Class Diagrams - Advanced

Object Diagrams

Object diagrams model object structures that exist at a given moment of time.

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). When used to model the problem domain, such class diagrams are called conceptual class diagrams or OO domain models (OODMs).

Example: 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, just like a class diagram, represents the class structure of the problem domain and not their behavior. 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

Deployment diagrams show a system's physical layout, revealing which pieces of software run on which pieces of hardware.

Source: https://en.wikipedia.org/wiki/Deployment_diagram

Component Diagrams

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

Source: https://en.wikipedia.org/wiki/Component_diagram

Package Diagrams

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

Source: https://en.wikipedia.org/wiki/Package_diagram

Composite Structure Diagrams

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

Source: https://en.wikipedia.org/wiki/Composite_structure_diagram

Activity Diagrams

Activity diagrams model workflows

More…

Sequence diagrams model object interactions for specific scenarios

Sequence Diagrams - Basic

Sequence Diagrams - Intermediate

Sequence Diagrams - Advanced

Use Case Diagrams

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

More…

Timing Diagrams

Timing diagrams focus on timing constraints.

Adapted from:

Interaction Overview Diagrams

Interaction overview diagrams are a combination of activity diagrams and sequence diagrams.

Source: https://en.wikipedia.org/wiki/Interaction_overview_diagram

Communication Diagrams

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

Adapted from:

State Machine Diagrams

State Machine Diagrams model state-dependent behavior.

Consider how a CD player responds when the “eject CD” button is pushed:

• If the CD tray is already open, it does nothing.
• If the CD tray is already in the process of opening (opened half-way), it continues to open the CD tray.
• If the CD tray is closed and the CD is being played, it stops playing and opens the CD tray.
• If the CD tray is closed and CD is not being played, it simply opens the CD tray.
• If the CD tray is already in the process of closing (closed half-way), it waits until the CD tray is fully closed and opens it immediately afterwards.

What this means is that the CD player’s response to pushing the “eject CD” button depends on what it was doing at the time of the event. More generally, the CD player’s response to the event received depends on its internal state. Such a behavior is called a 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 deemed too complex 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. Given below is an example SMD for the Minesweeper game. More details on SMDs can be found in the appendix of this handout.

Example:

Review

...