Domain Modeling and Activity Diagrams in Software Design

Posted on Jan 17, 2025 in Computer Engineering in Computer Engineering

Object Interaction (Continued)

Constructing a Domain Model

Shows the object relative to the other subsystems. Interconnections help to identify events your object will receive, as well as expected outputs.

Constructing State Transition Tables

Columns are Events, Rows are States. Cells represent a transition to another state in response to an event.

State Transition Table Advantages

  • Systematic construction of the state model, ensuring every state-event is accounted for
  • Automatic generation of state diagrams
  • Allows for the detection of abnormalities:
    • Dead states
    • Unreachable states
    • Neglected events
    • Impossible transitions
    • Non-deterministic transitions
    • Redundant transitions
    • Inconsistent transitions

Visualizing the State Behavior

A UML State Diagram is a behavioral diagram that shows state behavior as a hierarchy of concurrent, communicating state machines, each of which depicts the states, state transitions, and response actions associated with the state transitions. It can be generated from the State Transition table by capable tools or manually.

Activity Model

The modeling focus is on systems that perform complex information processing. It’s a way to detail use cases. Each activity is a task that will be modeled.

Characteristics of a Transformational System

  • A network of activities that transform input into output in stages
  • Controls flow, threading, synchronous/asynchronous behavior
  • Are more or less a batch process, no need for interaction between actor and process
  • Transformational Systems are usually stateless and computationally intensive

Why Use an Activity Model?

  1. Concerned with complex information processing dealing with the characteristics of a Transformational System, as opposed to Object Interaction Modeling (OIM) and Object State Modeling (OSM).
  2. Helps team members understand and communicate interaction between activities.
  3. Helps refine high-level requirements identification of use cases, concerned with complex information processing dealing with the characteristics of a transformational system.

Flowchart

Used for modeling over long periods. Nodes represent processing or decisions. Edges are directed and show control/decision structure.

Petri Net

Has two types of nodes: places (circles) and transitions (bars). Two nodes of different types can be connected by a directed edge. Models different system behaviors such as mutual exclusion and parallel threads. A transition can “fire” if all of its incoming places are active (contain a token). When the transition fires, it removes a token from each of its input places and puts a token into each of its output places.

Data Flow Diagram (DFD)

Has three types of nodes: Process – represents information processing activity, Data Store – data repository, External Entity – entity outside the system that interacts with it. Directed edges represent data flow. Can only connect two processes: process and data store or process and external entity. A process can be refined through decomposition of a process shown in the following diagram.

Producing a Preliminary Activity Diagram

Take information identified from the activity and workflow identifying stage. Use this information to create the diagram.

Refining Complex Activities

Large activities need to be decomposed into a network of smaller activities to aid in the understanding and communication of design ideas. Two ways to do this are by examining relevant documentation and summarizing how the activity is carried out.

Relationships to Other Diagrams

An activity may be a use case. This may imply that actor-system modeling may be applied to it, and object interaction modeling may be applied to it. If an activity exhibits state-dependent behavior, state modeling should be applied.

Activity Modeling Review Checklist

  • Does the activity diagram describe the correct business process?
  • Is the activity diagram overly complex?
  • Is the activity diagram syntactically correct?
  • Is each conditional branching associated with a condition that can be evaluated?
  • Are the branching conditions mutually exclusive?
  • If the activity diagram is a refinement of an activity, then does the refinement satisfy the consistency rules?

Applying Agile Principles

Use activity modeling to understand the activities and workflows. Do not use activity modeling as a form of documentation. Involve the users in activity modeling. Leave out unnecessary details, capture activities and workflows at a high level.

Domain Model

A conceptualization process that aims to identify important domain concepts, their properties, and relationships between the concepts. The result is portrayed in a diagram called a domain model.

Why Create a Domain Model?

  • Helps understand the application and the application domain
  • Lets team members communicate and improve their common perception of the application and application domain
  • Helps the development team communicate their perception to customers/users and seek feedback
  • Provides a common conceptual basis for the subsequent design, implementation, testing, and maintenance
  • Helps new members understand the relevant application and the application domain

Defining Objects in Domain Modeling

Real-world objects can be defined as classes. Classes can be defined extensionally and intentionally. Extensional definitions turn real-world objects into enumerable instances. Intentional definitions define these real-world objects in terms of properties and behaviors.

Classes and Objects in Domain Modeling

Attributes and operations of classes are called features. An object has an independent existence in a domain; an attribute does not. Attributes can be entered from an input device; objects cannot. Classes can be related by association. These associations have multiplicity (how many instances of one class may be associated with another).

Special Associations

  • Aggregations are relations that show which classes are parts of another.
  • Inheritances are relations that show which classes are generalizations of others.
  • Association classes store information and relate two associations to one another.

Steps in Domain Modeling

  1. Collecting application domain information
  2. Brainstorming
  3. Classifying brainstorm results
  4. Visualizing the domain model
  5. Reviewing the domain model

Collecting Domain Information

Collect information from the customer in order to understand the individual domains and the interaction between the domains. How to collect information:

  1. Collect Documents from the Customer
  2. Interview the Customer
  3. Learn from outside sources

Brainstorming

Filter through the information gathered for domain-specific concepts identified by the following criteria:

  1. Nouns or noun phrases
  2. “X of Y,” or “Y’s X” expressions
  3. Transitive verbs
  4. Adjectives, adverbs, and enumerations
  5. Numerics and quantities
  6. Possession expressions
  7. Constituents, part of, consist of expressions
  8. Containment or containing expressions
  9. “X is a Y” expressions, or generalized/specialized concepts

Visualizing the Domain Model

Use a class diagram to visualize the classification result. Once the classes, attributes, and relationships are identified, we can convert the result to a class diagram using aggregation and inheritance.

Reviewing the Domain Model

The development team reviews the domain model to detect and correct errors and abnormalities by using the nine domain review checklist items.