Object and Class Structuring - Software Modeling Study Notes

Overview of Object and Class Structuring

• Object structuring follows the definition of use cases and the development of a static model of the problem domain.

• The primary objective is to determine software objects that model real-world objects within the problem domain.

• Software objects are derived from use cases and the static model.

• The focus is on problem domain objects (real-world) rather than solution domain objects (design-time decisions).

• Relationship Context:

  • Static modeling (Chapter 7) identifies external classes for the software system context class diagram.

  • External classes determine software boundary classes (interfaces to the external environment).

  • Entity classes and their relationships are determined during static modeling.

  • Dynamic Modeling (Chapters 9, 10, and 11) addresses the dynamic relationships between objects.

Criteria for Object and Class Structuring

• System decomposition into objects is not a unique process; it relies on the judgment of the analyst and specific problem characteristics.

• Class definition depends on the problem nature:

  • Example: In an automobile catalog, $cars$, $vans$, and $trucks$ may belong to a single class due to needing identical information types.

  • Example: For a vehicle manufacturer, $cars$, $vans$, and $trucks$ might be distinct classes due to requiring varied, detailed information.

• The methodology involves identifying real-world objects in the problem domain and designing corresponding software objects.

• Object interactions are later depicted in dynamic models using communication or sequence diagrams.

Categorization of Application Classes and Objects

• Classes are categorized by the roles they play to group those with similar characteristics.

• Stereotypes (<>) distinguish between various application class types.

• An object, as an instance of a class, inherits the stereotype of that class.

• Classification Hierarchy (Analogy: Library systems or Animal Kingdom taxonomy):

  • The primary categories are Entity, Boundary, Control, and Application Logic.

  • These are visualised as having inheritance relationships where each specific type is a subclass of the main categories.

Main Object and Class Structuring Categories

• Entity Objects: Software objects that encapsulate information and provide access to stored data. They are often persistent. Access may occur via a service object.

• Boundary Objects: Objects that interface with and communicate with the external environment.

  • User Interaction Object: Interfaces with a human user.

  • Proxy Object: Interfaces with an external system or subsystem.

  • Device I/O Boundary Object: Receives input from or provides output to hardware I/O devices.

• Control Objects: Provide overall coordination for a collection of objects. Subtypes include coordinator, state-dependent control, and timer objects.

• Application Logic Objects: Contain specific application logic details. These are used to separate logic from the data it manipulates, often because logic is likely to change independently.

  • Business Logic Objects: Used in information systems to house business rules.

  • Algorithm Objects: Used in real-time, scientific, or engineering applications.

  • Service Objects: Provide services for client objects in service-oriented architectures.

• In instances where an object satisfies multiple criteria (e.g., both entity and algorithm), it should be allocated to the category it fits best.

• Each category has a corresponding object behavioral pattern depicted on UML communication diagrams.

External Classes and Software Boundary Classes

• External classes reside outside the system and interface with it.

• Boundary classes reside inside the system to communicate with external classes.

• Interaction Mapping (Often 1:1 association):

  • External User Class interfaces with a User Interaction Class.

  • External System Class interfaces with a Proxy Class.

  • External Device Class (Input/Output/IO) interfaces with a Device I/O Boundary Class.

  • External Timer Class signals to a Software Timer Class.

• External device classes represent device types, while objects represent specific instances (physical hardware).

Detailed Analysis of Boundary Classes and Objects

• User Interaction Objects:

  • Communicate via standard I/O (keyboard, display, mouse).

  • Can range from command-line interfaces to complex Graphical User Interfaces (GUI).

  • Can be composite objects (e.g., an $Operator Interaction$ object composed of multiple windows/widgets).

  • Behavioral pattern: Accepts operator commands, requests data from entity objects (e.g., $Sensor Data Repository$), and displays results.

• Proxy Objects:

  • Act as local representatives for external systems.

  • Encapsulate the "how" of communication (e.g., message protocols) to hide external complexity.

  • Example: Pick & Place Robot Proxy communicating with an External Pick & Place Robot system.

• Device I/O Boundary Objects:

  • Provide software interfaces for non-standard, application-specific hardware.

  • Standard I/O (managed by OS) usually does not require custom boundary objects.

  • Relevant real-world physical objects that interact with software must have a software model (e.g., vehicle motor/arm vs. non-interacting chassis/wheels).

  • Input Object: Receives data from an $external input device$ (e.g., $Temperature Sensor Interface$).

  • Output Object: Sends data to an $external output device$ (e.g., $Red Light Interface$ sending $On/Off$ commands to a $Red Light Actuator$).

  • Input/Output (I/O) Object: Performs both (e.g., $ATM Card Reader Interface$ reading cards and sending $eject/confiscate$ commands).

Entity Classes and Objects

• These store information and provide limited access through operations.

• Static modeling defines their attributes and relationships.

• Persistence Factors:

  • Information systems: Usually stored in files or databases (persistent).

  • Real-time systems: Often stored in main memory.

• Banking Example: $Account$ class with attributes $accountNumber: Integer$ and $balance: Real$. It is accessed by various use cases (withdrawals, transfers, monthly statements).

• Monitoring Example: $Sensor Data$ class with attributes $sensorName: String$, $sensorValue: Real$, $upperLimit: Real$, $lowerLimit: Real$, and $alarmStatus: Boolean$.

Control Classes and Objects

• Coordinator Objects:

  • Decision-making objects that determine sequencing for related objects.

  • Non-state-dependent; actions depend only on incoming messages, not history.

  • Example: $Bank Coordinator$ directing transactions to specific managers ($Withdrawal$, $Transfer$, $Query$, or $PIN Validation$).

• State-Dependent Control Objects:

  • Behavior changes based on the current state, often defined by a finite state machine (statechart).

  • Receive input events causing transitions and generating control outputs.

  • Example: $ATM Control$ managing coordination between $Receipt Printer$ and $Cash Dispenser$.

• Timer Objects:

  • Activated by external timers (real-time or OS clocks).

  • Perform actions or activate other objects upon receiving timer events.

  • Example: $Report Timer$ triggered by $Digital Clock$ to send a $Prepare$ message to a $Weekly Report$ object.

Application Logic Classes and Objects

• Business Logic Objects:

  • Encapsulate business rules separately from entity data to allow independent changes.

  • Guideline: Use a separate business logic object if the rule requires access to two or more entity objects.

  • Example: $Withdrawal Transaction Manager$ enforce rules:

    • Rule 1: Customer must maintain a minimum balance of $50$ after withdrawal.

    • Rule 2: Daily withdrawal limit of $250$ via debit card.

    • It accesses both $Account$ and $Debit Card$ entity objects to verify these rules.

• Algorithm Objects:

  • Encapsulate specific, complex domain algorithms likely to change independently (e.g., for accuracy/performance).

  • Example: $Cruiser$ object in a Train Control System that calculates speed adjustments for smooth acceleration/deceleration by comparing current and desired speeds.

• Service Objects:

  • Provide services upon request from client objects; they do not initiate requests.

  • Common in service-oriented, client/server, and component-based architectures.

  • Example: $Catalog Service$ provides item information to a $Customer Coordinator$ to assist with selections.

Questions & Discussion

• What is a boundary object? An object that communicates with an external object.

• What defines a control object? An object that manages or coordinates other objects.

• What is unique about state-dependent control? It executes based on a state machine, meaning the same input might produce different results depending on the current state.

• What is the function of a coordinator object? It acts as a decision-maker for sequencing without being state-dependent.

• How are boundary classes determined? By identifying software classes that directly communicate with external classes found on the context diagram.

• What is a timer object? An internal object awakened/triggered by an external timing event/clock.

• Analogies for classification: Categorizing books in a library or biological taxonomies help explain how application classes are grouped by role.

• Purpose of stereotypes: To label and categorize classes based on their structuring criteria.

• What defines a business logic object? It houses application-specific logic and rules, often managing data from multiple entity objects.

Would you like the summary of the next chapter on Dynamic Interaction Modeling?