Guide‎ > ‎Logicdoc‎ > ‎

Logicdoc Terms

Mapping Business Logic into your Analysis and Design approach

By way of introduction, we employ commonly used terminology widely accepted by various methodologies such as Rational Unified Process (TM). You can easily map a variant of this approach into your own methodology.

In this diagram:

  • Blue represents the definition of Business Requirements
  • Grey represents the (optional) PURL activities to capture these and provide Logic Traceability
  • Red represents the (required) Runtime elements
  • The numbered callouts refer to the PURL Process steps described in the next section


Business Process

Business Process are typically represented by Flow Diagrams, whether in Powerpoint, Visio, Case Tools, or Business Process software. These are also called Work Flow Diagrams, or (in UML (TM)) Activity Diagrams. You can even use presentation graphics to capture a process as shown below in Process and Use Cases.

In the diagram above, the blue objects represent the Business Users perspective as captured by such an analysis process. Referring to callout 0:

  • A system contains many Processes, such as the "Order Entry Process"
  • Each Process contains many Use Cases, such as "Place Order".
    Within the Process Diagram, Use Cases correspond to nodes representing work by a designated person (Place Order, Approve Order), connecting by lines that represent conditional flow (Approve Order is required only for orders over $1,000).

Processes are an excellent means of engaging the Business Users to discover all the Use Cases.


Use Case

A Use Case is is a description of a system's behavior as it responds to a request that originates from outside of that system. A request might be a set of screens (e.g., placing an order), or a message. It typically corresponds to a node in the Business Process Diagram.

The Use Case represents a fundamental contract between IT and Business Users. It is often said that the system is the sum of the Use Cases. This is a diplomatic way of saying that Business Users need to certify that the list of Use Cases is complete, and constitutes a proper basis for development and scheduling. Adding Use Cases incurs additional time and/or effort.


Business Logic Requirement

For Business Logic, it is important the designate the Requirements for each Use Case. These are best named (e.g., Check Credit), and accompanied by sufficient text so that developers can accept the requirement as clear: implementable with a specified cost.

In the diagram above, this is drawn in a muted color, since it is often captured rather informally.

Analogously to the above, the Use Case is the sum of the requirements. Adding Requirements incurs additional time and/or effort to be added to the schedule. Once Requirements are established, Logic is built to implement each requirement.


Business Logic

In conventional approaches, the logic design might be pseudocode:

  1. Compute the balance as the sum of the unpaid orders
  2. Raise an exception if the result exceeds the credit limit

With Business Logic, you can typically define such logic directly, eliminating the the bulk of the design/code/debug process.


Class Diagrams

As part of the development process, we strongly recommend the use of Class (Data Model) Diagrams to visualize the Domain Objects / relationships, the nouns of Business Logic specifications. While Process Diagrams make sense for Business Users, Data Model (Class) Diagrams typically do not. But they are fundamental for Developers.

Note: for complex Use Cases, you may wish to depict the Rules for a specific Use Case / Requirement on the Class Diagram, as shown in the  thumbnail.
Comments