UML Merode Notes

Unified Modeling Language (UML) and Merode

Overview

• These notes cover concepts related to Unified Modeling Language (UML) and Merode, an object-oriented analysis method.
• The content includes dynamic system structure, event analysis, and various layers within a system architecture.

System Architecture Layers

• Workflow Layer: Consists of actions (e.g., Actie 1, Actie 2, Actie 3, Actie 4).
• Function Layer: Includes functions (e.g., Functie A, Functie B, Functie C, Functie D).
• Event Layer: Comprises events (e.g., Event 1, Event 2, Event 3, Event 4).
• Domain Layer: Contains domain objects (e.g., Object X, Object Y, Object Z).

Dynamic Domain Model

• The dynamic domain model focuses on changes and the behavior of domain objects.

Business Events

• Business events are real-world events that would occur even without software.
• They form the link between input functions and domain classes.

Input and Output Functions

• Input functions: Trigger events and modify objects (sometimes multiple objects simultaneously).
  Example: Registering a new member.
• Output functions: Report or query objects.
  Example: Generating a member list or sending notifications.

Events

• Input functions trigger events, which in turn modify objects.
• Business events are atomic (indivisible) changes to domain objects.
• They are changes from the real world that would occur independently of software.
• These are not software-specific events like clicks or timer events.

Example Scenario: Library System

• Input Functions: new member registration, Lending registration, online extension registration, registration, member deletion, print member list (notifications).

• Functions Layer Examples: CRE Lid (create member), uitlenen (borrow), verlengen (extend), END Lid (end member), END_Exemplaar (end copy).

• Events Layer Examples: CRE Lid, uitlenen, verlengen, END Lid, verliezen (lose), END_Exemplaar.

Object Model Example: Library System

• An example object model includes classes such as:
  • Lid (Member): -naam: String
  • Uitlening (Loan): -datumUitlening: Date, 0..5 -datumMoet Terug: Date
  • Boek (Book): -nr: Integer, -titel: String, -auteur: String
  • Exemplaar (Copy): -nummer: Integer, -status: Exemplaar Status, -plaatscode: Plaatscode
    Status of copies:
  • Exemplaar Status (Enumeration): nieuw (new), uitleenbaar (borrowable), uitgeleend (borrowed), afgeschreven (written off), verloren (lost)

Events vs. Input Functions

Importance of Business Event Analysis

• Business events encapsulate business rules and domain knowledge.
• They define conditions for:
  • Instantiating new domain objects.
  • Modifying domain objects.
  • Terminating domain objects.

Identifying Business Events

• Techniques include text analysis, focusing on verb phrases + object. Lifecycle:
  • Analyzing the life cycle of an object (creation, modifications, destruction).

Object Lifecycle Events

• Every object has at least two events:
  • Creation.
  • Archiving (end state, destruction).
• If an object's state (attributes) can change, there's at least one modification event.

Object Event Table (OET)

• The OET consolidates all events.
• It typically includes Create, Modify, and End events.
• Existaansafhankelijkheid (Dependency): Events of a dependent object are M-events (Modify events) of its parent object.

O.E.T. (Object Event Table) Example

• Classes: Klant (Customer), Bestelling (Order), Menu
  • CRE_Klant (Create Customer) - C
  • MOD_Klant (Modify Customer) - M
  • END_Klant (End Customer) - E
  • CRE_Bestelling (Create Order) - C
  • wijzigen_Bestelling (Modify Order) - M
  • leveren_Bestelling (Deliver Order) - M
  • annuleren_Bestelling (Cancel Order) - E
  • archiveren_Bestelling (Archive Order) - E
  • CRE_Menu (Create Menu) - C
  • END_Menu (End Menu) - E

Meaning of O.E.T.

• The O.E.T. indicates which business objects are involved in a business event because:
  • Their state changes due to the event, or
  • The occurrence of the event depends on their state (preconditions).

Pre- and Postconditions

• Precondition: A condition that must be met before an event can occur.
• Postcondition: The effect of an event.

Event Specification

• Key elements to define for an event:
  • Name of the event.
  • Involved object.
  • Inputs.
  • Preconditions.
  • Postconditions.

Event Specification Example

• context Bestelling::wijzigenBestelling (nieuw_aantal: integer)
• pre: nieuw_aantal > 0
• post: aantal = nieuw_aantal

Event Ordering

• Events must occur in a logical sequence.
  • Creation always comes first.
  • Archiving always comes last.
  • Modifications may have specific order requirements.

State Diagram

• A state diagram illustrates the sequence of events for a single object.

Example: State Diagram of Exemplaar (Copy) in a library:
* States: uitleenbaar (borrowable), uitgeleend (borrowed)
* Events: AankopenEx (Purchase Copy), ToekennenplaatscodeEx (Assign Code), terugbrengen (return), afschrijven (write off), verlengen (extend), verliezen (lose), uitlenen (borrow)

Considerations for Event Analysis

• Each domain class (except enumerations) should have a column in the OET.
• For each association, propagate all events from the dependent class to the parent class.
• A state diagram pertains to one class.
• Every class has one state diagram (focus on special signs).

Additional Considerations

• Each state change in a state diagram corresponds to one or more events from the OET.
• For each class, every own event in the OET must also be present in the state diagram of that class.