Business reference architecture: business to consumers
Chapter 3: Logical Design Stage
Microsoft Corporation
May 2001
Summary: This chapter describes the logical phase of the Microsoft Solution Frame (MSF) design process. At this stage, the design team should have a high-level decision based on the conceptual design and integration of components. The design team will use the application solution (developed in concept phase) to build the logical model of the application.
At this stage, the design team should have developed a logic design, which is the basis of the actual design phase of the project.
Introduction
The target of the logical phase is to convert the functions defined in the concept phase to an abstract model to determine the collaborative logic components that will be used to support the solution.
The resulting logic design does not involve specific technologies. Instead, the goal of this phase is to analyze and understand functionality before any technical work. For example, when a group is designed an e-commerce solution in a logical phase, it may be considered that the component named Users is a necessary service to track the user group accessing the application. But in the actual design phase, the design team may choose to use Microsoft® Commerce Server 2000. In this case, the MSCSProfileService component in Commerce Server provides the actual implementation of the USERS component.
If the final application design includes custom components (ie, the components that are not available in the ready-to-range solution or product), the corresponding components determined by the logical phase can be directly converted to the actual phase. For example, a UserS object is defined at a logical phase, and the design team decides to make it a custom object, then the UserS object will be repeated in the actual phase.
The rest of this chapter will outline the logical design flow used when designing consolidateDretail.com, and then detail the logical components required to meet the requirements required.
Create logic design
The first step in creating a logical application design is to determine the business object (component) that will provide the desired function. In addition to determining the desired object, the design team must also determine the behavior, attributes, and relationships of each object. The design team will use the application in the concept phase to determine these objects and their relationships, behaviors, and properties.
For example, the following is the application 3:
Users choose the directory you want to browse. Displays the various categories and products in the root of the selected directory. The user can then select the product you want to view its details, or select a category to view each product and each subcategory in the selected category.
In this way, the design team will determine all aspects of the support solution by analyzing this scheme, and perform the following tasks:
Determine the business object in this scenario. Determine the behavior of these objects. Determine the properties or features of these objects. Determine the logical relationship between these objects.
These tasks will be described in more detail in the back section of this chapter.
When these tasks of each application are completed and the archive, the design team can end the logical design phase. For a complete design example of consolidateDretail.com, please refer to the "Dixed Logic Design" section.
Unified modeling language
Unified Modeling Language (UML) is a tool for describing system operation. UML is a very useful tool in an intuitive description of the system to make more comprehensive analysis. By using UML, it is convenient to explain the components, interaction, relationships, and more.
UML is usually used to simplify design in the logical phase.
To illustrate the tasks involved in the creation logic design, the following sections will provide a simple UML diagram representation example.
Obser
When analyzing the application, the primary task is to determine the objects thereof. Objects are usually a business entity or process that appears in an application. For example, in the following paragraphs, the object will be identified in a bold:
User selects the Catalog (directory) you want to browse. Displays Categories and Products in the root location of the selected Catalog (directory). Then, USER can select the product to view the details of its details, or select a Category (category) to see the Products in the selected Category (each product) and subcategories. The above example uses the following objects:
User Catalog Categories Product Products
Figure 3-1 is a UML diagram depicting the object determined in this example:
Figure 3-1: Object
These five objects become the basic objects of this program; however, in some cases, to make the program work, other objects need to be added, even if these objects are not explicitly listed in the scenario. These additional objects can be determined by checking the acts associated with its associated behavior. To determine these objects, you must first determine its behavior.
Determine behavior
When the obvious object group is determined, the next step is to determine its respective behavior, which is also known as "method" or "service".
To determine the object behavior, you must first determine the operations executed in the scenario. For example, in the following paragraphs, the action will be identified in bold:
Users choose the directory you want to browse. Displays the various categories and products in the root of the selected directory. The user can then select the product you want to view its details, or select a category to view each product and subcategory in the selected category.
The first action is the user selection directory. Figure 3-2 is a UML diagram that describes the user object as a SELECT CATALOG behavior:
Figure 3-2 Behavior of the User object
As mentioned earlier, there must be no obvious object from the scheme with its associated behavior. We can thus think that since the user selects the directory, there is inevitable mechanism that allows you to select a directory from the directory list. This way, you can logically assume that the Catalogs object exists, which manages all Catalog objects. Then, this new object should be added to the list of defined objects.
When defining a "Catalogs" object, you can define the first action as a SELECT CATALOG (selecting a directory), which belongs to the "Catalogs" object.
You can continue to analyze each sentence in the scheme until all conscription objects and their associated behavior are determined.
Determine attribute
When the behavior is determined, the next step is to determine the properties of the defined object (also known as "characteristic"). Attributes are elements that need to be tracked. They are placeholders for retention (or "stay") data.
The property derived method is that the behavior in the analysis scheme and extracts elements that need to remain (or track). For example, in the previous section, the application specifies that the user will be able to view the product. When viewed, the elements displayed to the user will become the properties of the product. For example, if a business requires a product specifications and prices, these elements will become the properties of the object.
Figure 3-3 is a UML diagram showing a User object with an NAME attribute:
Figure 3-3: Properties of the User object
Determine relationship
After determining the object and its properties, the next step is to determine "relationship". The relationship is the logical association between objects.
To determine the relationship, you must analyze the interaction between objects. For example, the "categories" object has a relationship with the "category" object, because the "Categories" object manages the collection of "category" objects and contains the "category" object. Be sure to pay attention to another relationship called Inheritance, which deals with an object being defined by another object. For example, if the designed solution is to sell food and books, it is also necessary to distinguish between the two, then define such a relationship: "Book" and "Food" objects belong to a "product" Object. In this way, they can inherit "Product" objects.
In a business reference architecture solution, no inheritance relationship is not defined in a logical phase. But in some e-commerce solutions, these relationships may be very important.
Completed logic design
At the reference architecture, the logical design phase of consolidatedretail.com, the design team determines the following objects that form an abstract collection of components required for support solutions. (These objects are arranged in alphabetical order instead of being arranged in order.)
AUTHENTICATION
Authentication object handles users' registration and authentication.
Catalog
The Catalog object stores information about a specific directory and manages a collection of products in this directory.
Catalog Manager
The Collection of the Catalog Manager object management directory.
Category
The Category object stays information about specific categories.
Category Manager
Category Manager Object Management Category Collection.
CONFIGURATION
The Configuration object holds the application configuration information and handles the task associated with the configuration.
Data functions
The Data Functions object performs data-specific functions such as open access to the database.
E-mail objects are used to send email messages to users, such as order confirmation messages.
Error Handler
The "ERROR HANDLER" object will be called when an error occurs. It handles user-friendly error conversions and log errors.
ORDER
The ORDER object stays information about a particular order.
PRODUCT
The Product object stays information about a particular product.
Search
Search objects are used to search for directorys and return product search results.
User
User objects are used to reserve information about specific users. In addition, it manages all user orders.
User manager
User Manager object management user collection.
Figure 3-4 demonstrates the relationship between the main object and the use case described in the second chapter
Figure 3-4: Object Relationship
to sum up
This chapter illustrates four-step procedures that determine objects (ie, business components) and their properties, behavioral and interrelationships of e-commerce applications. The end result of this process is to create logic designs that will be used as technical design and standardization.
It should be noted that the generated logic design does not involve specific technologies. These technologies will be determined in the actual design phase, which is the topic discussed in the next chapter.
