Change Record
|
Date |
Author |
Version |
Change Reference |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewers
|
Name |
Version Approved |
Position |
Date |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Distribution
|
Name |
Position |
|
|
|
|
|
|
|
|
|
|
|
|
Document Properties
|
Item |
Details |
|
Document Title |
Logical Design |
|
Author |
|
|
Creation Date |
|
|
Last Updated |
|
Appendix: Creating the Logical Design
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.}]
[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>>
[The team uses the usage scenarios previously developed to identify these objects and their relationships, behaviors, and attributes. The team performs the following tasks:
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.]