Logical Design - Wittenburg.co.uk

advertisement
LOGICAL DESIGN
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.
The paragraphs written in the “Comment” style are for the benefit of the person writing the
document and should be removed before the document is finalized.
SEPTEMBER 17, 2008
Revision Chart
This chart contains a history of this document’s revisions. The entries below are provided solely
for purposes of illustration. Entries should be deleted until the revision they refer to has actually
been created.
The document itself should be stored in revision control, and a brief description of each version
should be entered in the revision control system. That brief description can be repeated in this
section.
Version
Primary Author(s)
Description of Version
Date
Completed
Draft
TBD
Initial draft created for distribution and
review comments
TBD
Preliminary
TBD
Second draft incorporating initial review
comments, distributed for final review
TBD
Final
TBD
First complete draft, which is placed under
change control
TBD
Revision 1
TBD
Revised draft, revised according to the
change control process and maintained
under change control
TBD
etc.
TBD
TBD
TBD
Logical Design
Project Name
PREFACE
The preface contains an introduction to the document. It is optional and can be deleted if
desired.
Introduction
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
116098191 (02/12/16)
Page 1
Logical Design
Project Name
within the designs. Test will review the logical design to ensure test plans are in place to validate
it.
116098191 (02/12/16)
Page 2
Logical Design
Project Name
CONTENTS
New paragraphs formatted as Heading 1, Heading 2, and Heading 3 will be added to the table
automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the
table and press F9. If you want the table to be easy to maintain, do not change it manually.
1.
INTRODUCTION ........................................................................................................5
1.1
1.2
1.3
LOGICAL DESIGN SUMMARY .....................................................................................5
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ......................................................5
REFERENCES .............................................................................................................5
2.
OBJECTS ..................................................................................................................6
3.
BEHAVIORS ..............................................................................................................7
4.
ATTRIBUTES ............................................................................................................8
5.
RELATIONSHIPS .......................................................................................................9
6.
INDEX .....................................................................................................................10
7.
APPENDICES ...........................................................................................................11
7.1
CREATING THE LOGICAL DESIGN ............................................................................11
7.1.1
7.1.2
7.1.3
7.1.4
7.1.5
Unified Modeling Language ..................................................................................... 11
Objects ...................................................................................................................... 11
Behaviors .................................................................................................................. 12
Attributes .................................................................................................................. 12
Relationships ............................................................................................................ 13
116098191 (02/12/16)
Page 3
Logical Design
Project Name
LIST OF FIGURES
New figures that are given captions using the Caption paragraph style will be added to the table
automatically. To update this table of contents in Microsoft Word, put the cursor anywhere in the
table and press F9. If you want the table to be easy to maintain, do not change it manually.
This section can be deleted if the document contains no figures or if otherwise desired.
Error! No table of figures entries found.
116098191 (02/12/16)
Page 4
Logical Design
Project Name
1. INTRODUCTION
This section should provide an overview of the entire document. No text is necessary between the
heading above and the heading below unless otherwise desired.
1.1 Logical Design Summary
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.
Some project participants may need to know only the plan’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.
1.2 Definitions, Acronyms, and Abbreviations
Provide definitions or references to all the definitions of the special terms, acronyms and
abbreviations used within this document.
1.3 References
List all the documents and other materials referenced in this document. This section is like the
bibliography in a published book.
116098191 (02/12/16)
Page 5
Logical Design
Project Name
2. OBJECTS
The Objects section identifies all objects that exist within the solution domain. See the Appendix
for examples of objects.
Objects are the foundation for the logical design – all other elements are identified and defined
from the set of objects.
116098191 (02/12/16)
Page 6
Logical Design
Project Name
3. BEHAVIORS
The Behaviors section identifies for each object the set of behaviors of that object. See the
Appendix for examples of behaviors.
Object behaviors enable the identification of attributes, as they describe the functionality of the
objects.
116098191 (02/12/16)
Page 7
Logical Design
Project Name
4. ATTRIBUTES
The Attributes section identifies for each object/behavior pair, the specific attributes that must be
tracked. See the Appendix for examples of attributes.
Attributes define the contents of the solutions’ databases. They define what information must be
managed to satisfy the user’s activities.
116098191 (02/12/16)
Page 8
Logical Design
Project Name
5. RELATIONSHIPS
The Relationships section defines the relationships among the objects. See the Appendix for
examples of object relationships.
Object relationships describe the flow of activities through a solution and provide input to the
design of the database and solution logic.
116098191 (02/12/16)
Page 9
Logical Design
Project Name
6. INDEX
The index is optional according to the IEEE standard. If the document is made available in
electronic form, readers can search for terms electronically.
116098191 (02/12/16)
Page 10
Logical Design
Project Name
7. APPENDICES
Include supporting detail that would be too distracting to include in the main body of the
document.
7.1 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
2. Identify the behaviors of these objects
3. Identify the attributes, or properties, of the objects
4. Identify the logical relationships between the objects
7.1.1 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.
7.1.2 Objects
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:

User

Catalog

Categories

Product

Products
Below is a UML diagram that illustrates the objects identified in this example.
116098191 (02/12/16)
Page 11
Logical Design
Project Name
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.
7.1.3 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.
7.1.4 Attributes
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.
116098191 (02/12/16)
Page 12
Logical Design
Project Name
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.
7.1.5 Relationships
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.
116098191 (02/12/16)
Page 13
Download