<%@ Language=JavaScript %> Logical Design


<<Project Name>>

Logical Design


Customer Name


Directions for using template:

Read the Guidance (Arial blue font in brackets) to understand the information that should be placed in each section of this template. Then delete the Guidance and replace the placeholder within <<Begin text here>> with your response. There may be additional Guidance in the Appendix of some documents, which should also be deleted once it has been used.


Some templates have four levels of headings.  They are not indented, but can be differentiated by font type and size:

You may elect to indent sections for readability.




Author Position





Version: 1.0


Ó 2002 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft and Visual Basic are either registered trademarks or trademarks of Microsoft in the United States and/or other countries.



Revision & Sign-off Sheet

Change Record




Change Reference
































Version Approved
































Document Properties



Document Title

Logical Design



Creation Date


Last Updated




Table of Contents

 TOC \o "1-3" \h \z

Logical Design Summary. PAGEREF _Toc13581467 \h 3

Objects. PAGEREF _Toc13581468 \h 3

Behaviors. PAGEREF _Toc13581469 \h 3

Attributes. PAGEREF _Toc13581470 \h 3

Relationships. PAGEREF _Toc13581471 \h 3

Appendix: Creating the Logical Design. PAGEREF _Toc13581472 \h 4



[Introduction to the Template


Description: The Logical Design presents a complete and unambiguous definition of the solution’s logical elements from the user and functional point-of-view. This design is written without the encumbrances of architecture, technology, and infrastructure. A logical design identifies and defines all the objects and their behaviors, attributes, and relationships within the scope of the solution.  


The goal of the logical design is to convert the contents of the usage scenarios and conceptual design into an abstract model that identifies the cooperating logical components that support the solution.


The logical design does not identify specific technologies. The goal is to analyze and understand the solution’s functionality before making any technology commitments. If the final design includes custom components (components not provided in available solutions or products), including information about them in the logical design facilitates their translation directly into the physical design. 

Justification: Presenting a logical design to solution stakeholders early in the development process elicits user feedback on the proposed solution while minimizing the distractions of the design’s physical aspects.

The documentation of a logical design is valuable not only during development but once the solution is operational. When changes are proposed to the requirements of a deployed solution, it is easier to analyze those changes using the logical design in order to estimate the changes’ impact on the physical solution.

The development team will use the logical design to 1) prove the solution meets functional requirements and 2) recognize logical design errors. The logical design is also important input for developing test plans and test cases.

{Team Role Primary: Program Management is responsible for ensuring that the logical design document is completed. Development will have the primary responsibility for creating the document’s content.

Team Role Secondary: Product Management will review and understand the Logical Design in order to convey it to parties external to the team and to ensure that it aligns with initial project sponsor requirements. User Experience will review the design to ensure user requirements are met. Release Management will participate both in content creation and review along with development to ensure that operational, deployment, migration, interoperability and support needs are addressed within the designs. Test will review the logical design to ensure test plans are in place to validate it.}]


Logical Design Summary

[Description: Provide an overall summary of the contents of this document. This should include the criteria by which the design was established and how it was validated.

Justification: Some project participants may need to know only the document’s highlights, and summarizing creates that user view. It also enables the full reader to know the essence of the document before they examine the details.]



[Description: The Objects section identifies all objects that exist within the solution domain. See the Appendix for examples of objects.

Justification: Objects are the foundation for the logical design – all other elements are identified and defined from the set of objects.]

<<Begin text here>>



[Description: The Behaviors section identifies for each object the set of behaviors of that object. See the Appendix for examples of behaviors.

Justification: Object behaviors enable the identification of attributes, as they describe the functionality of the objects.]

<<Begin text here>>



[Description: The Attributes section identifies for each object/behavior pair, the specific attributes that must be tracked. See the Appendix for examples of attributes.

Justification: Attributes define the contents of the solutions’ databases. They define what information must be managed to satisfy the user’s activities.]

<<Begin text here>>



[Description: The Relationships section defines the relationships among the objects. See the Appendix for examples of object relationships. 

Justification: Object relationships describe the flow of activities through a solution and provide input to the design of the database and solution logic.]

<<Begin text here>>


Appendix: Creating the Logical Design


[The team uses the usage scenarios previously developed to identify these objects and their relationships, behaviors, and attributes. The team performs the following tasks:

  1. Identify the user, business, and data objects in the scenario
  1. Identify the behaviors of these objects
  1. Identify the attributes, or properties, of the objects
  1. Identify the logical relationships between the objects

Unified Modeling Language

 The Unified Modeling Language (UML) is a tool used to illustrate how solutions work. It can be very useful in describing a solution visually in order to analyze it more fully. Using UML is an easy way to diagram components, interactions, relationships, and more. Often, UML is used to facilitate the analysis of the logical design.


 When analyzing a usage scenario, the first task is to identify the objects in it. An object is generally a business entity or process that appears in the usage scenario. For example, in the following paragraph, the objects are identified in bold:

The user selects a catalog to browse. The categories and products in the root of the selected catalog are displayed. The user can then select a product to view its details or select a category and view the products and sub-categories in the selected category.

In this scenario, the following objects are used:

Below is a UML diagram that illustrates the objects identified in this example.

These five objects serve as the base objects for this scenario; however, there are situations when additional objects are needed for the scenario to function, even though these objects are not specifically listed in the scenario. You can identify these additional objects by examining behaviors that have no apparent objects associated with them. To identify these objects, you must first identify the behaviors.


After identifying the obvious set of objects, the next step is to identify their respective behaviors, also known as methods or services.

To identify object behaviors, you must first evaluate what is being done in the scenario. For example, in the following paragraph, the actions are identified in bold:

The user selects a catalog to browse. The categories and products in the root of the selected catalog are displayed. The user can then select a product to view its details or select a category and view the products and sub-categories in the selected category.

The first thing that happens is that a user selects a catalog. The figure below is a UML diagram that illustrates the User object as having the Select Catalog behavior.

Behaviors that have no apparent objects associated with them must be derived from the scenario. It follows that because the user selects a catalog, there must be some sort of mechanism that allows a catalog to be selected from a list of catalogs. You could then logically assume that a Catalogs object, which manages the collection of Catalog objects, is present. You should add this new object to the list of objects that were defined.

After you define the Catalogs object, you can define the first action as Select Catalog and this behavior belongs to the Catalogs object.

You then need to continue to evaluate each sentence of the scenario until you identify all of the requisite objects and their associated behaviors.


After identifying the behaviors, the next step is to identify the attributes (also known as the properties) of the objects that have been defined. Attributes are elements that the solution needs to track. They are placeholders in which data is retained or persisted.

Identify attributes by analyzing the behaviors in the scenario and extracting what elements have to be tracked or persisted. For example, in the previous section, the usage scenario specifies that the user is able to view a product. When a product is viewed, those elements shown to the user are attributes of the product. For example, if the business requires that the product description and price be shown, those elements become attributes that are identified on the objects. 


The figure below is a UML diagram that illustrates the User object as having the attribute Name. 


After defining the objects, their behaviors, and attributes, the next step is to identify relationships. Relationships are logical associations between objects.

To identify relationships, analyze how the objects interact with each other. For example, the Catalogs object has a relationship with the Catalog object because the Catalogs object, which manages the collection, contains Catalog objects.

Another type of relationship, inheritance, deals specifically with the situation where one object defines another. For example, if the solution being designed was going to sell food and books but the designers wanted to logically differentiate between them, then a relationship might be defined where both Book and Food objects are a type of Product object. That is, they both inherit from the Product object.]