Chapter 3. Modeling the Dynamics of a SystemChapter 4. Tutorial: Modeling the Discrete Dynamics of an Organization with SysML v2 (9/38)Chapter 5. Tutorial: Modeling the Continuous Dynamics of a Home with SysML v2

Chapter 4. Tutorial: Modeling the Discrete Dynamics of an Organization with SysML v2

We consider a hotel as an example of an organization, which is a kind of social system with a state structure and a dynamics. The dynamics of social systems consists of discrete processes involving discrete state changes caused by events, which primarily include the actions of the system's actors, as opposed to continuous processes, like energy flows or material flows. The discrete processes of organizations are also called business processes.

We consider a simple business process type of renting hotel rooms based on the running example of (Pesic et al 2007) for illustrating business process modeling with SysML v2. Processes of this type consist of seven types of activities: (1) "book room": enter client name, payment data, etc; (2) “check-in”: record client arrival, provide key card, etc; (3) “provide room service”: provide a room service for the client; (4) “provide restaurant service”: provide food or beverages for the client; (5) “bill”: for billing the number of nights, room services, restaurant services, etc; (6) “charge”: the client is charged the total price of the stay; and (7) “check-out”: client checks out at the reception.

The business process type of renting hotel rooms is only weakly structured since it does not imperatively sequence all types of activities. It defines the admissible sequences of activities with the help of a set of (dynamic) constraints:

  1. Every process has to start with a "book room" activity that is normally followed by a “check-in” activity, except in the case of a cancellation or a no-show.
  2. Every process must include at least one activity of type “bill”, i.e., at least a cancellation or no-show fee, or the number of nights will be billed. However, it might be the case that the bill is extended multiple times during a process (due to room services and restaurant services provided during the stay).
  3. Every activity of type “provide room service” or “provide restaurant service” must be billed.
  4. Every process must include exactly one activity of type "charge".
  5. When the client “checks-out”, the bill must either have been charged already or will be charged at, or after, check-out.

Before modeling the activity-based dynamics of a hotel, we model its state structure.

1 Modeling the State Structure of a Hotel

The business system of a hotel consists both of a physical subsystem, a hotel building with floors and rooms, and of a social subsystem, an organization with departments and positions. In this section, we only consider how to model the state structure of a hotel as an organization, and abstract away from its building.

The most important state structure modelling concepts of SysML v2 needed for modeling a hotel are:

  1. data types and attributes (or data properties), including predefined data types, such as String and Integer,
  2. part types and part properties.

Notice that in SysML v2 lingo, data types and part types are officially called "attribute definitions" and "part definitions", while attributes and part properties are officially called "attribute usages" and "part usages", but we prefer using the classical terminology of data types, attributes, part types and part properties.

Our running example describes a hotel as a system consisting of positions (representing bundles of organizational roles) and departments (or organizational units). We model a simple type of hotel consisting of a director, a front office department with a manager and receptionists, a food and beverage department with a manager, a kitchen and a restaurant, as well as a housekeeping department with a manager and housekeepers. The hotel's organizational structure is shown in the following nested list:

Each department is responsible for a number of business activities and has at least one human resource pool for each of its positions, such that suitable human resources are allocated to perform the department's business activities.

We start making a quick model sketch by not considering the ranges (or the typing) of properties, modeling the departments and positions of a hotel in the form of parts:

part def Hotel {
  attribute name;
  attribute numberOfRooms;
  ref part director;
  part frontOffice;
  part foodAndBeverage;
  part housekeeping;
}

This declaration defines a part type Hotel with two attributes and the four part properties director, frontOffice, foodAndBeverage and housekeeping, such that for a hotel h, the expression h.director denotes the director of h, while h.frontOffice, h.foodAndBeverage and h.housekeeping denote the three departments, h consists of.

In KerML and SysML v2, properties (or features) are either composite or referential. By default, attributes are referential, while part properties are composite. When a part has a value for a composite property, this value represents an occurrence, the life of which ends when the life of the part ends. In other words, the value is destroyed together with the part. Such a life cycle dependency does not hold for referential properties.

Since we want to make the assumption that when a hotel is destroyed, its departments are destroyed as well, but not its director, we model director as a referential property by prefixing it with the keyword "ref".

Notice that any system may be a subsystem (or part) of a larger system. For instance, a hotel may be a part of a city. Therefore, in SysML v2, systems are defined as part types.

Nested organizational units can be defined in SysML v2 in the form of nested part properties, resulting in the following model sketch of a hotel's organizational structure:

part def Hotel {
  attribute name;
  attribute numberOfRooms;
  ref part director;
  part frontOffice {
    ref part manager;
    ref part receptionists[*];
  }
  part foodAndBeverage {
    ref part manager;
    part kitchen {
      ref part chef;
      ref part cooks[*];
    }
    part restaurant {
      ref part waitstaff[*];
    }
  }
  part housekeeping {
    ref part manager;
    ref part housekeepers[*];
  }
}

2 Modeling the Discrete Dynamics of a Hotel

Following the terminology of SysML v2, we say "action" instead of "activity". In SysML v2 lingo, action types are officially called "action definitions", while action properties (or action steps) are officially called "action usages", but we prefer using the classical terminology of types and properties.

2.1 Modeling Actions Steps with Action Cardinality Constraints

We define the process type of renting hotel rooms in the form of a RentHotelRoom action type with seven action steps:

action def RentHotelRoom {
  action bookRoom[1];
  action checkIn[0..1];
  action provideRoomService[*];
  action provideRestaurantService[*];
  action bill[1..*];
  action charge[1];
  action checkOut[0..1];
}

Notice that this action type definition includes the following five action cardinality constraints:

  1. The actions bookRoom and charge are executed exactly once.
  2. The actions checkIn and checkOut are executed at most once.
  3. The action bill is executed at least once.

2.1 Sequencing Actions with Successions

For defining the admissible sequences of actions, we can specify a number of follow-up constraints and precedence constraints in the form of succession declarations (using the keywords first and then) with special source and target multiplicities, as shown below. Notice that successions are actually special properties the values of which are binary links instantiating the predefined association HappensBefore.

An example of a follow-up constraint is "A provide room service action must be succeeded by a bill action", while an example of a precedence constraint is "A check-in action must be preceded by a book room action".

We also need to define three combined follow-up/precedence constraints, resulting in the following eight succession declarations:

action def RentHotelRoom {
  ...
  // Follow-Up: A room service must be succeeded by a bill action
  first [*] provideRoomService then [1..*] bill;
  // Follow-Up: A restaurant service must be succeeded by a bill action
  first [*] provideRestaurantService then [1..*] bill;
  // Precedence: A check-in must be preceded by a book room action
  first [1..*] bookRoom then [*] checkIn;
  // Precedence: A room service must be preceded by a check-in.
  first [1..*] checkIn then [*] provideRoomService;
  // Precedence: A restaurant service must be preceded by a check-in.
  first [1..*] checkIn then [*] provideRestaurantService;
  // Combined: A bookRoom action must be succeeded by a bill, and
  // a bill must be preceded by a bookRoom action.
  first [1..*] bookRoom then [1..*] bill;
  // Combined: A bill action must be succeeded by a charge, and
  // a charge must be preceded by a bill action.
  first [1..*] bill then [1..*] charge;
  // Combined: A check-in must be succeeded by a check-out, and
  // a check-out must be preceded by a check-in.
  first [1..*] checkIn then [1..*] checkOut;
}

The successions expressing follow-up and precedence constraints can be visualized as in the following diagram:

???

Given the above action cardinality constraints for bookRoom, checkIn, charge and checkOut, these succession declarations could be rewritten in the following way, which is equivalent, but more informative:

action def RentHotelRoom {
  ...
  // Follow-Up: A room service must be succeeded by a bill action
  first [*] provideRoomService then [1..*] bill;
  // Follow-Up: A restaurant service must be succeeded by a bill action
  first [*] provideRestaurantService then [1..*] bill;
  // Precedence: A check-in must be preceded by exactly one book room action
  first [1] bookRoom then [0..1] checkIn;
  // Precedence: A room service must be preceded by exactly one check-in
  first [1] checkIn then [*] provideRoomService;
  // Precedence: A restaurant service must be preceded by exactly one check-in
  first [1] checkIn then [*] provideRestaurantService;
  // A book room action must be succeeded by at least one bill action, and
  // a bill must be preceded by exactly one book room action
  first [1] bookRoom then [1..*] bill;
  // A bill action must be succeeded by exactly one charge, and
  // a charge must be preceded by at least one bill action
  first [1..*] bill then [1] charge;
  // A check-in must be succeeded by exactly one check-out, and
  // a check-out must be preceded by exactly one check-in
  first [1] checkIn then [1] checkOut;
}

2.2 Allocating Actions to Organizational Units

In the model above, actions have not been allocated to the organizational units in charge. In our example, the front office would be in charge of performing actions of the types bookRoom, checkIn, bill, charge, and checkOut, while the food and beverage department would be in charge of provideRestaurantService and the housekeeping department would be in charge of provideRoomService.

Each organizational unit has a number of positions (associated with human resource pools), such that its human resources perform the types of actions it is in charge of. For instance, the housekeeping department has the positions of manager and housekeepers with one person hired as manager and several persons hired as housekeepers forming its human resources.

We can allocate action steps to specific parts of a system by declaring them within the part concerned and prefixed with the keyword perform, as shown in the following model fragment:

part housekeeping {
  ref part manager;
  ref part housekeepers[*];
  perform action provideRoomService;
}

This perform action declaration states that the housekeeping department, as a part of the Hotel system, is the performer of actions of the type provideRoomService. Allocating all action steps to their organizational unit results in the following model fragment:

part def Hotel {
  attribute name;
  attribute numberOfRooms;
  ref part director;
  part frontOffice {
    ref part manager;
    ref part receptionists[*];
    perform action bookRoom;
    perform action checkIn;
    perform action bill;
    perform action charge;
    perform action checkOut;
  }
  part foodAndBeverage {
    ref part manager;
    part kitchen {
      ref part chef;
      ref part cooks[*];
    }
    part restaurant {
      ref part waitstaff[*];
    }
    perform action provideRestaurantService;
  }
  part housekeeping {
    ref part manager;
    ref part housekeepers[*];
    perform action provideRoomService;
  }
 ...
}

We still need to add the definition of the hotel's rent hotel room business process in the form of the action property rentHotelRoom, the action steps of which are specified using the syntax of feature chains for referencing the actions defined for the hotel's parts:

part def Hotel {
  ...
  action rentHotelRoom {
    perform frontOffice.bookRoom [1];
    perform frontOffice.checkIn [0..1];
    perform foodAndBeverage.provideRestaurantService [*];
    perform housekeeping.provideRoomService [*];
    perform frontOffice.bill [1..*];
    perform frontOffice.charge [1];
    perform frontOffice.checkOut [0..1];
    // Follow-Up: A restaurant service must be succeeded by a bill action
    first [*] provideRestaurantService then [1..*] bill;
    // Follow-Up: A room service must be succeeded by a bill action
    first [*] provideRoomService then [1..*] bill;
    // Precedence: A check-in must be preceded by a book room action
    first [1..*] bookRoom then [*] checkIn;
    // Precedence: A restaurant service must be preceded by a check-in.
    first [1..*] checkIn then [*] provideRestaurantService;
    // Precedence: A room service must be preceded by a check-in.
    first [1..*] checkIn then [*] provideRoomService;
    // Combined: A bookRoom action must be succeeded by a bill, and
    // a bill must be preceded by a bookRoom action.
    first [1..*] bookRoom then [1..*] bill;
    // Combined: A bill action must be succeeded by a charge, and
    // a charge must be preceded by a bill action.
    first [1..*] bill then [1..*] charge;
    // Combined: A check-in must be succeeded by a check-out, and
    // a check-out must be preceded by a check-in.
    first [1..*] checkIn then [1..*] checkOut;
}

This improved model of the hotel's room rental business process is visualized in the following diagram:

???

Notice that the model above is still incomplete, as it does not include the typing of part properties and action properties/steps. However, for the purpose of this tutorial, we do not need to consider this.

2.3 Declarative Business Process Modeling

Unlike flowchart-based business process modeling languages like UML Activity Diagrams or BPMN, which imperatively sequence all activities, SysML v2 defines the admissible sequences of activities with the help of a set of dynamic constraints like declarative business process modeling languages, such as DECLARE (Pesic et al 2007).

In the approach of DECLARE, the meaning of dynamic constraints is defined by mapping them to formulas of Linear Temporal Logic (LTL), which includes the temporal operators ◇ standing for "eventually", □ standing for "always", and U standing for "until".

For instance, the Follow-Up constraint "a room service must be succeeded by a bill action" expressed as the succession declaration 

first [*] provideRoomService then [1..*] bill

is mapped to the LTL formula 

□( provideRoomService ⇒ ◇bill )

with the reading "it's always the case that when a provideRoomService action occurs, then eventually (some time later) a bill action occurs".

The Precedence constraint "a check-in must be preceded by a book room action" expressed as the succession declaration 

first [1..*] bookRoom then [*] checkIn

is mapped to the LTL formula

(¬checkIn U bookRoom) v □(¬checkIn)

with the reading "either no checkIn action occurs until a bookRoom action occurs, or a checkIn action never occurs".

What about Events?

A business process consists of events and actions/activities (in fact, actions/activities are events). In particular, the actions of external actors cannot be modeled as actions of the business system under consideration, but rather as events to which the system has to react. There are also events like resource failures.

In our hotel system example, booking a room is not really an action, but rather a reaction to a booking request event. Likewise, a no-show is not an action (of the hotel), but rather an event to which the hotel has to respond.

It is a major deficiency that SysML v2 does not include an event modeling concept.

Conclusions