B.1 Conceptual Design

Conceptual design focuses on high-level issues. It defines the scope and limits of the design. It looks at issues from different perspectives. It ensures that use cases are handled naturally and smoothly. It is completed prior to high-level design, detailed design, or implementation.

Conceptual design documentation provides an overview of a component or service (utility). It includes the following sections:

• Goal

• Responsibilities

• Architectural level

• Classes and objects, class semantics, and class relationships

• Description of features, interactions, data types, and constraints

• How the design addresses relevant use cases and requirements

Section 1 Goal

The goal is a single, simple, and complete statement that captures the purpose of a component or service (utility).

Good Example

The trash bag [component] provides people a disposable container for refuse.

Poor Example

The trash bag [component] is used both indoors and outdoors to put refuse in so it can later be picked up by a garbage truck or taken to a garbage dump.

Section 2 Conceptual Overview

The conceptual overview is a one- or two-paragraph statement supporting the goal and describing what the reader can expect from the remainder of the document.

Example (from Profile Service Conceptual Design)

In addition to information that is intrinsic to a business object (BO), it is useful to find other related information about the BO that is not part of what defines that object, but is useful nevertheless. The discovery interface available on these BOs allows one to add and retrieve such related data by means of the Metadata, Property, Ontology, and Relationship services. However, the absence of a uniform template that tells one what data can be expected from these services limits their usefulness. This template is provided by the profiling service in the form of one or more profiles for each type of business object.

Section 3 Responsibilities

Responsibilities describe what a component does or what it keeps track of. They are listed in order of priority, with more important or larger responsibilities listed first. Each responsibility must first be captured by a single, simple sentence (not compound with lots of "ands"). A description including important supporting details should follow. The description may introduce subconcepts, but not new or super concepts.

Good Example

The Boy Walking Dog [component]

• exercises the dog. He does this twice a day.

• prevents the dog from running away. He does this by keeping the dog on a leash.

• ensures doggie creates waste.

• cleans up doggie waste.

Poor Example

The Boy Walking Dog [component]

• uses a scooper. This is part of cleaning up after the dog.

• walks the dog and learns to whistle. He also picks up a gallon of milk at the store he passes along the way.

Section 4 Architectural Level

The architectural level is one of the following:

• Application. The application level encompasses application and session components, application and session utilities, and user interface classes and utilities.

• Domain. The domain level includes vertical domain-specific components and services.

• Foundation. The foundation level encompasses common services, such as workflow, naming or metadata, and core components and data types, such as EiObject and FormattedDataRep.

For application components, also note whether the component is generic to all domains or specific to either a single or a limited number of domains.

Section 5 Classes and Objects, Class Semantics, and Class Relationships

This section should contain one or more diagrams (probably not more than three or four) identifying classes and objects, class semantics, and class relationships. Diagrams should be responsibility oriented, not data oriented. They should show the relationships and interactions between classes and class semantics. They should show how classes or class groupings fulfill responsibilities listed in Section 3.

Each diagram should be accompanied by a sequence of interactions that are taken to fulfill each responsibility the diagram fulfills.

Diagrams are drawn using Visio or PowerPoint and are inserted into a conceptual design document electronically. Diagrams do not have to follow UML standards. They should be drawn relatively quickly and should have just enough detail to illustrate concepts. In other words, these diagrams should be kept simple.

Example (See Figure B.1.)

Section 6 Description of Features, Data Types, and Constraints

Features are fine-grained mechanisms for fulfilling responsibilities. There should be many more features than responsibilities, and the features should directly support responsibilities. Data types are supported formats for populating classes. Constraints are limitations imposed on classes, relationships, and interaction.

The detailed description:

• Refers to class diagrams where appropriate

• Does not address implementation details

• Relates each point back to specific classes, objects, or responsibilities

• Does not introduce new concepts

Examples

• The boy component has a watch so it knows when to walk the dog.

• The boy component can bend, allowing it to position the scooper effectively.

• The leash is made of leather to ensure that the dog can be restrained under any conditions (e.g., if the dog starts to run or jerk).

• The dog can exercise at speeds from 0 to 30 mph.

• The scooper holds 100 cm³ of waste.

• The scooper may be of type Johnson & Johnson Model B or DuPont Model 52-P412.

Section 7 How the Design Addresses Relevant Use Cases and Requirements

This section references relevant use cases and requirements and their source documents. No new design concepts are introduced. References to class diagrams and responsibilities are made where needed to clarify how the component fits in with the use case or requirements.

Example

The Boy Walking Dog component satisfies the following requirements from Use Case TCP1: Takes Care of Pet in the Family Household System Scope definition documents.

• TCP1.2.1 The dog must be exercised twice daily.

• TCP1.2.2 The dog must create waste when it exercises.

• TCP1.2.3 The dog must be cleaned up after.