André Leclerc informatics consultant

Business modeling artifacts

This page documents the artifacts that make up models of business domains.


Subject

This is a subject or theme of major interest or importance to an organization's business.

It can, for example, be a major function, service, business line, resource or product of that same organization.

Subjects are used to classify and group use cases and components of information systems.

The descriptive data to capture on each subject include:

  • a unique identifier;
  • a short description; and
  • a long description.

Examples of subjects:

  • The accounting function.
  • The management of employees.
  • Relationships with customers.

Back to opening page Back to background material Back to top of this page

Domain of Values

A domain of values is a list or range of acceptable values that is used to validate the values of many similar properties of business components.

It is a modeling artifact that is referred to by properties of business components to enable the reuse of simple data validation rules.

The descriptive data to capture on each domain of values include:

  • a unique identifier;
  • a short description; and
  • a specification of the list or range of acceptable values.

Examples of domains of values:

  • The range "1900 to 1990" to be used to validate birth dates of potential customers.

Back to opening page Back to background material Back to top of this page

Use Case

A use case of an information system is a typical use of that same system, in which certain actors use certain functions or capabilities of the information system to achieve a specific business goal or result.

One or many business components of the information system may be called into play at various stages of a use case.

A use case can be more or less complex depending on the number of functions invoked and on the number of business components involved.

The descriptive data to capture on each use case include:

  • a unique identifier;
  • a short description of the business goal to be achieved by using the information system in this particular use case;
  • a list of events triggering this use case;
  • a list of conditions that must prevail prior to the execution of this use case;
  • a list of the most important conditions that are tested for by this use case;
  • a list of business rules implemented by this use case;
  • a list of constraints, of a human nature, financial nature, technical nature or other nature, affecting this use case;
  • a list of other use cases that this one depends on, if any; those are use cases that are extended or included by this one, or use cases that must be executed prior to this one;
  • a list of events putting an end to this use case;
  • a list of results that are expected from the execution of this use case;
  • a list of organizational units, people or other systems participating in this use case;
  • a list of business components having some responsibility in this use case;
  • a list of business components collaborating to this use case;
  • a list of actions performed by the actors of this use case and by the information system itself;
  • the relative priority of this use case for development purposes (high, medium or low);
  • the estimated complexity of this use case for development purposes (very complex, complex, average, simple or very simple); and
  • the name or names of the software applications or modules that implement portions of this use case.

A simple list of actions may not be enough for use cases that are not simple.  It is then necessary to develop a more elaborate description, showing the actions carried out by the various participants, including the information system, and, step by step if need be, the data exchanges, the control points, the different processing paths that can be taken, and the various results that can be produced by this use case.

Examples of use cases of a system:

  • Use of an information system to process insurance claims submitted by clients.

Back to opening page Back to background material Back to top of this page

Actor in Use Cases

An actor in the context of use cases is a person, an organization, an external system or some other thing that plays a role in at least one use case.

It is a modeling artifact that is referred to by the descriptions of the use cases that the actors have a role to play.

The descriptive data to capture on each actor include:

  • a unique identifier;
  • a short description; and
  • the staff position or category of employee or organization or external system or other thing that plays a role in at least one use case.

Back to opening page Back to background material Back to top of this page

Business Component

A business component of an information system is a functional piece of that information system that manages data via its properties and methods, and via its associations with other business components.

The descriptive data to capture on each business component include:

  • a unique identifier;
  • a short description;
  • a list of other names (aliases) by which this business component is known, if any;
  • a list of properties belonging to this business component;
  • a logical expression involving one or many of this business component's properties and identifying the primary key;
  • zero, one or many logical expressions involving one or many of this business component's properties and identifying one or many secondary keys;
  • a list of methods implementing this business component's behaviours;
  • a list of the use cases in which this business component has some responsibility;
  • a specification of the processing rules to follow when adding, updating, listing or deleting instances of this business component;
  • a list of associations with other business components along with details about those associations;
  • a list of organizational units or people who are responsible for the creation or maintenance of instances of this business component;
  • a list of organizational units or people who use instances of this business component but are not responsible for their creation nor for their maintenance;
  • the relative priority of this business component for development purposes (high, medium or low);
  • the estimated complexity of this business component for development purposes (very complex, complex, average, simple or very simple); and
  • the name or names of the data repositories containing data belonging to this business component.

A business component's primary key is used to uniquely identify and locate instances of this business component.   All properties involved in the primary key's expression must be mandatory properties, i.e., properties that must have values.

Secondary keys are also used to identify and locate instances of a business component.   However, they do not necessarily contain unique values and the properties involved in any secondary key's expression may be optional properties.

Examples of business components:

  • Client, employee, invoice, sale, product, product category, visit, etc.

Back to opening page Back to background material Back to top of this page

Business Component Property

A property of a business component carries values of a certain data type for that business component.

Most properties carry simple data values such as a numeric, alphanumeric, alphabetic, text, date, logical or binary value.

Other properties are more complex and carry multiple data values of various types.

Those latter properties are typed by business components instead of one of the basic data types enumerated above.

Examples of properties follow the descriptive data below.

The descriptive data to capture on each business component property include:

  • a unique identifier;
  • a short description;
  • a list of other names (aliases) by which this property is known, if any;
  • its basic data type or a reference to its typing component, if the property is a complex one;
  • its total length in characters or bytes;
  • its number of decimals, if any;
  • any input, storage or output formats or masks used to format its values;
  • a reference to the domain of acceptable values used to validate its values, if it uses such a domain;
  • its default value or values, if any;
  • the edit or validation rules to follow, other than the domain and typing component, when accepting values for this property;
  • the calculation or derivation rules to follow when generating values for this property, if it is a calculated or derived property;
  • an indicator of whether this is a mandatory property, i.e., a property that must have values, or an optional property, i.e., a property that may or may not have values; and
  • the name or names of the data fields or attributes containing data values for this property.

Examples of properties:

  • An example of a simple property would be a property called "Product Code" belonging to a business component called "Product", which property is simply be a numeric code taken from a certain range of valid numeric values.
  • An example of a complex property would be a property called "Individual Visited" belonging to a business component called "Visit", which property is a reference to the specific individual visited during a specific visit.   The type of that property would then be given by another business component called "Individual".

Back to opening page Back to background material Back to top of this page

Business Component Method

A method of a business component is a series of logical operations that are carried out by the business component whenever it is called upon to fulfill its share of responsibilities in some of the information system's use cases.

A method can receive data values or references to data objects via its parameters, and can return a data value or object.

Just like the properties of business components, those data values or objects, passed or returned, can be simple ones or complex ones.

Some methods have parameters while others do not, and some methods return a data value or object while others return nothing.

The descriptive data to capture on each business component method include:

  • a unique identifier;
  • a short description;
  • the basic or complex data types of the method’s parameters, if it has parameters;
  • the basic or complex data type of the value or object returned by the method, if any;
  • a list of conditions that must prevail prior to the execution of this method’s operations;
  • a specification of the logic implemented by this method;
  • a list of conditions that should prevail after the execution of this method’s operations; and
  • the name or names of the software routines or units that implement portions of this method.

The logic implemented by a method may be specified in more or less detail with pseudo code, decision tables, decision trees or just plain text (see a simple methodology for specifying the logical behaviours of an information system's business components).

Examples of methods:

  • A method for calculating and returning an individual's current age.

Back to opening page Back to background material Back to top of this page

Business Component Association

An association of a business component is an association with another business component or with itself that denotes an important rule of the information system's business domain.

The descriptive data to capture on each business component association include:

  • its type;
  • a reference to the other business component, or to itself;
  • a short expression describing the nature of the association;
  • the identifiers of the properties involved in establishing the association; and
  • the minimum, average and maximum cardinalities for the association.

Examples of associations:

  • The "master-detail" association between a product and the line items from orders referring to that product.

Back to opening page Back to background material Back to top of this page