Ultimately, the aim of the Envisioning and Planning Phases is to do what's necessary to build an effective and useful application. Part of that work is to actually "architect," or design, the application. Although it is possible to use the MSF Development Process Model with any number of design methodologies, the MSF Design Process is a thorough, effective tool that ensures that the architecture of an application reflects the needs of the users and the business. At the same time, the MSF Design Process integrates the application with the existing enterprise architecture and with other applications. The MSF Design Process is especially effective for N-tier development, and is, in fact, aimed at that type of application.
Because the task of design resides primarily in the Planning Phase, we will take some time in this chapter to examine the MSF Design Process. First we'll present an overview of the three parts of the process. Then we'll explain how this process relates to the Planning Phase and how certain deliverables of the Planning Phase are dependent on the output of the Design Process. Finally, we'll examine in detail the three parts of the process, including their own internal deliverables.
The MSF Design Process consists of three distinct types of design work: conceptual, logical, and physical. Each of these generates a model of the same name: the Conceptual Design Model, the Logical Design Model, and the Physical Design Model.
Each part of the process approaches the design task from a different perspective and defines the solution differently, as shown in Table 6.2.
Table 6.2 Design task approaches to the three parts of the MSF Design Process
|Type of design work||Perspective||Action|
|Conceptual||Views the problem from the perspective of the user and business||Defines the problem and solution in terms of scenarios|
|Logical||Views the solution from the perspective of the project team||Defines the solution as a set of cooperating services|
|Physical||Views the solution from the perspective of the developers||Defines the solution's services and technologies|
The output of each part is used as the input for the succeeding part, as Figure 6.2 illustrates.
Figure 6.2 Outputs of the three interdependent design process models
The goals of the three parts are:
The MSF Design Process moves from tangible requirements (use cases) to an abstract application design (Conceptual Design), then to a rationalized application design (Logical Design), then to a concrete application design (Physical Design), and finally, to the tangible product. Conceptual Design is the initial translation of the use cases (the language of the users) to the application design (the language of the application developers). Logical Design is the developers' perspective and serves as a translator between the high-level application concepts—the business and user requirements—and the detailed application design.
Conceptual Design does not take into account the approach or the technologies needed to build the solution. Rather, Conceptual Design corresponds to rough sketches and scenarios for building a house. These are easily understood models jointly created by the customer, the user, and the architect. It is the translation of the business and user requirements from the language of the users to the language of the developers.
Logical Design starts to get into the details of the application that the team will build to fulfill business needs and user requirements. Logical Design thus corresponds to the floor plan and elevation of a house, where elements such as spatial relationships are organized. In this part of the process, the architect's team lays out the design's relationships and communication paths.
Physical Design addresses the technology that will be used. This design adds detail to the architecture and reflects real-world implementation constraints.
Essentially, the different parts of the MSF Design Process address the needs of different "readers" while still serving as parts of a functional whole. Instead of forcing readers to digest what may be a very large and detailed document, this model allows readers to focus only on the information—the part of the whole—that is pertinent to them. The model also allows the use of formal or informal techniques as appropriate.
The design evolves as each step in the process contributes more detail to the Functional Specification. And as the design evolves, every aspect is traceable from any point back to the original business problem, for verification and testing purposes.
Although the MSF Design Process resides primarily within the Planning Phase of the MSF Development Process Model, the work of design often begins before the Planning Phase is officially started, and it continues to some extent up to the point when the code is frozen (near the end of the Developing Phase). The baselines for each of the three parts of the process are established during the Planning Phase. As shown in Figure 6.3, the three design activities occur in a staggered, parallel manner, with the early output of one activity signaling that the next activity should begin.
Figure 6.3 Overlapping, iterative, and spiral qualities of the MSF Design Process
The Conceptual Design activity begins when the team agrees upon a vision statement, which may occur before the team reaches the formal Vision Approved Milestone. The Logical Design and Physical Design activities parallel those of Conceptual Design, and all three sit squarely in, but are not limited to, the Planning Phase of the MSF Development Process Model.
It is the parallel execution of all three design activities that allows the product's conceptual, logical, and physical design to have the following three qualities:
Obviously, a minimum degree of sequencing must occur as a practical matter. Conceptual Design must start before Logical Design, which must start before Physical Design. Similarly, the baseline for Conceptual Design must be established before the baseline for Logical Design, which must be established before the baseline for Physical Design. From a bigger perspective, the baseline output of the entire process is required to complete the Functional Specification.
The first part of the MSF Design Process, Conceptual Design, is defined as the process of acquiring, documenting, validating, and optimizing business and user perspectives of the problem and the solution. Its purpose is to capture and understand business needs and user requirements in their proper context. The output of Conceptual Design is a set of information models, use cases, and usage scenarios that document the current and future states of the system.
As we've said, Conceptual Design may be likened to the first stage of designing a house, when the client and the architect collaborate on a rough sketch and on a short list of needs and requirements. Using the Conceptual Design Model facilitates the gathering of complete and accurate requirements by involving the customer, users, and other stakeholders. Without a good conceptual design, the project team may end up with a wonderful solution…to the wrong problem.
In application design and development, it is critical that products be "user-centric" or attuned to users' true requirements. User-centric means having an awareness of how users view the current environment and what they would like to see in a new product. Whereas gathering requirements has traditionally meant compiling a list of desirable features, the aim in Conceptual Design is to understand and document the relationships between the users, the application, and the business. It is vital to uncover what users truly care about.
The goals for Conceptual Design are:
Conceptual Design consists of three steps: research, analysis, and implementation. Each step ends in its own baseline, which contributes to the overall Conceptual Design baseline.
The Conceptual Design baseline includes the implementation baseline, and is the culmination of the research, analysis, and implementation steps.
Before starting the Conceptual Design process, the team must first determine the focus of its investigation. For example, the team might start by describing the core operational processes of the appropriate business area, rather than the organizational function. These descriptions might include:
More specific details can include business process maps and their interdependencies, information structure and usage, and measurements and metrics (such as revenue per unit, expenses, operational locations, forecasts, and projections). Much of this information can be obtained from the enterprise architecture documentation, if it is available. When using UML or the Unified Process Model, these activities can be related to the use case, activity, and collaboration model.
During the research step, the project team conducts a high-level evaluation of existing business processes and activities in the context of enterprise strategy, goals, and objectives in the focus area. It should identify core corporate processes that support the business's objectives and goals. These may be product, service, or managerial processes, and in most cases, they are cross-functional in nature and move horizontally across the organization rather than vertically within the business's traditional departments or "silos."
A core process:
After the team has identified and prioritized business processes and activities, it should conduct additional investigations to complete its understanding, such as tapping into the corporate culture, gathering artifacts, and so on. The point is to gain a complete, accurate picture, with the quality of information being more important than the quantity of data.
In addition to researching business processes, the team can also conduct research on users and user groups. The first step is to identify as many groups as possible, including the organization's owner, users within the organization, and users outside the organization such as suppliers and consumers. After the various constituencies have been identified, a user profile must be created for each one, detailing the group's role in the organization, as well as its department, location, and involvement in specific activities. Any background data appropriate to the scope of the project should be included. Finally, the user roles must be related to the activities and processes documented earlier.
The research step is complete when the following tasks have been performed:
The first task of the analysis step is to validate the results of the research step, usually at a group debriefing. After a data-gathering activity is completed, the interviewer's findings, which might include diagrams and notes, are presented to the team. Comments from team members help the interviewer interpret the results, and the session helps the team to better understand the user requirements.
It's important to involve as many team members as possible in the debriefing sessions, especially Development, Testing, User Education, and Logistics Management. All team members have some involvement in the design of the application, and each member needs to understand and accept a common view of the users. Team members contribute different perspectives to the sessions, and walk away from these debriefings with information that is important to their role in the project.
When the research is deemed credible, the next task is to build information models to capture context, workflow processes, and task sequences. These information models are of two types: use cases and scenarios.
A use case is defined as a behaviorally related sequence of interactions performed by an actor in a dialogue with a system to provide some measurable value to the actor.
An actor can be a person, a group of people, another system, or even a piece of equipment. The defining characteristic of an actor is a role, or set of roles, performed in relation to the business or system. Use cases serve the following purposes:
Use cases have the following benefits:
A scenario is defined as a single sequence of interactions between objects and actors.
A scenario illustrates a particular instance of a use case and can show either the current state of the process or a desired future state. Four types of information are captured within a scenario:
Scenarios document the sequence of tasks performed by a specific role. Because each scenario represents only one particular instance of the use case, many scenarios are needed to document all the tasks comprising the workflow process in a given use case.
Scenarios can be easily documented in narratives, pseudocode, and task sequence diagrams. They are also easily prototyped for verification with users.
There are positive and negative aspects to building current-state scenarios. On the positive side, current-state scenarios:
On the negative side, though, current-state scenarios:
On every project, the team must evaluate the negative and the positive aspects of the project's current-state scenarios, considering the resources required to construct them. Risk assessment brings a degree of objectivity to this process, by asking the questions "What is the risk of taking the time to create scenarios versus not doing so?" and "What is the risk of misunderstanding if we don't create scenarios?"
The analysis step is complete when the following tasks have been performed:
The scenarios at this point are current-state. We discuss how the scenarios can be changed to depict the desired future state in the next section.
In this step, the goal is to include business processes as part of the design process, and to make improvements where possible. The scope of Conceptual Design includes not only the system under evaluation, but also the broader context of business processes, information, and goals that a new system will support.
The project team will not necessarily make all the improvements alone, but may coordinate with other efforts already underway, or with consultants brought in specifically for the work. Depending on the scope of the project and the depth of the team's understanding of the business, the team may be able to optimize one or more processes without any outside help.
What should be optimized? The goal is to eliminate as many of the following as possible:
The team should begin by asking questions: "How can we improve productivity?" "Where can we optimize?" "Are there places where we can integrate entire processes?" It's not enough to simply identify weaknesses. The team must also be able to imagine and describe the desired future state. Once the desired future state has been clearly visualized and described, the team can build appropriate new scenarios.
The following design basics can be used to optimize the processes involved in the project:
After new scenarios are created, the final rationalization step is to validate the new scenarios; that is, to assure that they solve the business problem. The team accomplishes this by completing these steps:
Early in the design process, proof-of-concept systems should show only the main features, user interface design and overall structure of the system. With this proof-of-concept level, the team is open to quickly reworking the design, because it has not invested a lot of effort in one "solution." Proofs-of-concept at this stage can take some of the following forms:
As the design process progresses, prototypes are likely to become more high fidelity, allowing the team to evaluate the visual style and some details of the design, particularly the user interface.
Validation using scenarios is preferable to producing a generic requirements document, because a scenario contains the larger context of the requirements. It's much easier to validate a scenario with a walk-through, role play, or proof-of-concept. One objective of validation is to uncover, before user sign-off, any missing pieces or incorrect interpretations of the design goals. Divergent views among the users over any aspect of the solution will also become starkly apparent and should immediately raise concerns.
It's important not to try and re-engineer the entire business process with the initial releases of the applications. Later product releases can introduce more future-state scenarios that may provide additional streamlining of the modeled business processes. Often, users will be hesitant to change how they do everything with one application release, and the phasing of future states into the application can be a compromise for the user community.
The rationalization step is complete when the following tasks have been performed:
Logical Design is defined as the process of describing a solution in terms of the organization, structure, syntax, and interaction of its parts from the perspective of the project team.
The purpose of Logical Design is to apply the services-based organizing principles of the MSF Application Model, which we discussed in Chapter 2, and to lay out the structure of the solution and the relationship among its parts. The output of Logical Design is a set of business objects with corresponding services, attributes, and relationships; a high-level user interface design; and a logical database design.
Logical Design can be likened to the second stage of designing a house, during which the architect concentrates on creating the floor plan and elevation. Here, architectural elements like doors, windows, roofs, patios, rooms, and spatial relationships are organized into a harmonious whole.
Logical Design is the project team's view of the solution. The team paints a picture of the solution's behavior and logical organization, which is required for Physical Design. Logical Design helps the team refine the requirements specified in Conceptual Design and manage the complexity of the whole solution.
In the Logical Design stage, the team:
Note that Logical Design is independent of physical implementation. The primary focus is on what the system needs to do, as explained by an organized set of cooperating elements. It is important to understand the solution completely before making a commitment to specific technologies.
Logical Design has two steps: analysis and rationalization. (There is no research step, because the output of Conceptual Design is the input to Logical Design.)
The goal of the analysis step is to convert the scenarios from Conceptual Design into modules for use in Logical Design. Modules are the core use cases of the system, the services or activities that occur within them, and the paths between them. A module is a logical unit used as an abstraction for the use cases and scenarios created in Conceptual Design. For each module, the team identifies its services, objects, attributes, and relationships.
To identify services, business objects, attributes, and relationships, the team refers to the work flow and task sequence information of scenarios, focusing on its appropriate aspects, as follows:
The team can also derive useful information from the context and physical environment.
A service is a unit of application logic that implements an operation, function, or transformation. Services can be relatively straightforward and can provide algorithmically simple functions—such as Create, Read, Update, and Delete—or algorithmically complex calculations or transformations—such as Pay, Validate, and Reserve.
The capabilities and responsibilities of a service should be stated as generally as possible, using only active verbs. A service should be identified by a clear, unambiguous name. Difficulty identifying and naming a service often indicates that its functionality or purpose isn't clear and that additional Conceptual Design investigation may be necessary.
The example in Table 6.3 shows a sample task sequence and the services within it.
Table 6.3 Sample task sequence and its services
|Sample task sequence||Candidate services|
|Front desk clerk looks up guest reservation||View reservation|
|System retrieves room assigned to confirmed guest||Retrieve room |
|Front desk clerk issues a key||Issue key|
A business object is an encapsulation of services and data used to organize the solution and reduce its complexity. Business objects are the people or things that are described in the scenarios. These objects then become the "anchor points" for attributes and relationships. (Note that this definition is different than that of an object from a COM perspective, which is the instance of a class definition.)
Some business objects might not be specifically stated in a scenario, even though these objects might be necessary to complete the business activities that the scenario describes, which are often noted as non-functional requirements. To identify business objects look for structures, other systems, devices, things or events remembered but not actually physically present in the scenario, roles played, operational procedures, locations or sites, and organizational units. To identify missing objects, the team must look for behaviors that have no apparent object associated with them.
The example in Table 6.4 shows the same sample task sequence as that of Table 6.3 with its business objects.
Table 6.4 Sample task sequence and its business objects
|Sample task sequence||Candidate business objects|
|Front desk clerk looks up guest reservation||Front desk clerk |
|System retrieves room assigned to confirmed guest||System |
|Front desk clerk issues a key||Key|
Attributes (called properties in COM) are the elements of an object that the business needs to know about and keep track of. Attributes are the definitions of data values that are held by an object. Each instance of an object maintains its own set of values based on the corresponding definition. For example, an attri- bute might be First Name, and the value that the attribute takes in a certain instance might be John. Attributes can also show ownership of an object by another object. The set of values for an object's attributes at any given point is known as its state.
As the team attempts to discover attributes, it must be sure to note any attributes that are derived—that is, computed—from other attributes. The derivation of this type of attribute becomes a service of the object, and the calculation or manipu-lation is maintained as part of the interface contract for that service. For example, if the Reservation Number attribute of the Room Reservation object is derived from the Reservation System object, then a Create Reservation Number service needs to be identified within the Reservation System object.
Also, the team must look at the total set of attributes for an object. If some of an object's attributes are very different from its other attributes, a new object might need to be created.
Notice that our definition points out that attributes are properties that the business needs to know about and keep track of. Conversely, some attributes might be present but be irrelevant to the task at hand. Such attributes should be noted, in case they are later deemed relevant. (Note that attributes that are relevant today may become irrelevant in the future, as business and process needs change.)
Table 6.5 shows the same sample task sequence as that of the two preceding tables with some candidate attributes. Examples of irrelevant attributes for this sample are age, height, religion, ethnicity, and Social Security number. Note that the same object can have many states.
Table 6.5 Sample task sequence and its attributes
|Sample narrative||Candidate attributes||Values at one state|
|Guest has a name and address||First name |
|Dan Shelly |
100 Microsoft Way
|Guest must have a type of reservation||Type||Gold Club|
|Depending upon type of reservation, guest can have a company||Company||Microsoft|
|Guest can be a smoker or nonsmoker||N/smoker||Nonsmoker|
A relationship is a logical association between objects. Recognizing relationships is required for determining effective design and assembly of the system parts.
Relationships, or associations, illustrate the way in which objects are related or linked to one another. Relationships fall into one of three types: whole/part, interaction, or generalization/specialization. As the team looks for relationships, it should consider any whole/part relationships that can be identified, any interactions that must be identified to maintain context, and any generalizations or specifications that can be made.
As the example in Figure 6.4 demonstrates, the guest object might be a specialization of the more generic person object; a guest can be part of a guest list, and a guest stays at a particular hotel.
Figure 6.4 Example of identifying relationships
To summarize, the analysis step is concerned with identifying the objects, services, attributes, and relationships comprising the scenarios. The diagram in Figure 6.5 illustrates this process. Note that in some methodologies, this process is called noun-verb analysis.
Figure 6.5 Identification process
The anaysis step of Logical Design is complete when the following tasks have been performed:
The first task of the rationalization step of Logical Design is to create any needed services and objects that have not been created to this point. New services and objects are created either because their existence is implied, or because they are needed for control. The team then refines the design. Finally, the Logical Design must be verified.
Creating Implied Services and Objects
This stage consists of creating objects and services that seem to be missing from Logical Design. For example, a guest (represented by an object) has company affiliations (also represented by an object). However, the relationship might not always exist. (For example, the guest might or might not use a company credit card for discounted rates.) Creating a new type of stay object effectively handles the missing, implied object and records the relationship between a guest and his or her company if one exists.
At this point, the team should concern itself with matters of control. Control means ensuring that services are conducted in the right sequence at the right time. In distributed systems, transactions can be used as a means for determining effective sequencing and the dependency relationships of objects, such as MTS packages. Otherwise, control objects might be needed to ensure the transactional integrity of a scenario, to coordinate services across multiple objects, or to manage cross-object dependencies.
For example, the hotel check-in scenario is a business transaction, or a collection of objects, that have dependency and sequencing relationships. An object or service would need to be created that ensures those relationships are honored and that takes corrective action (such as canceling the reservation) if one of the relationships is broken.
The team must always consider the need for additional business objects to handle control, sequencing, and dependency. The team can also isolate services that are likely to change from those that are stable.
Iterating and Refining Objects
After the team has identified the objects, it needs to refine the design by:
The first attempt at specifying objects using noun-verb analysis usually requires some refinement. Not all of the nouns will be relevant for describing the solution. The remaining candidates might consist of physical entities such as customers, employees, and pieces of equipment, as well as concepts that indicate business transactions such as room assignment, payment authorization, or promotion.
As part of the refinement process, services can also be used to discover objects. For each service that was identified in the analysis step, the team might ask, "What does this service act upon?" and "Is there an entity, individual, or organization that has the responsibility of carrying out this service?" Any objects with zero services or only one service defined might need further investigation.
Verification refers to testing the functional completeness and correctness of the design at the object level. The objects are tested in both an individual and coop-erating context. Verification of independent objects makes the task of integration much easier because the independent parts have been rigorously tested prior to assembly. Verification of cooperating objects ensures that the work specified in the scenario is accomplished as a whole.
For individual objects, the team should examine the pre-conditions feeding into the object and the post-conditions coming out of the object. The question to ask is "For a given set of pre-conditions, do the post-conditions match the scenario's requirements?"
However, this testing will not uncover assembly issues. The team also needs to look at the combination of objects that can solve the higher-level problems that were captured in the scenarios. A collection of modules that are interdependent in solving a problem can be complex. A simple way to verify multi-object scenarios is to conduct a full walk-through of the scenario as shown in Figure 6.6, ensuring that all the needs of the scenario are met by some combination of objects.
Figure 6.6 Tracing the objects back to the scenario
The team can walk through a scenario and determine which object's services are required in which sequence to move through to a successful completion. From a starting trigger to an object, the team must determine what other objects' services are needed for the scenario to be complete.
The rationalization step of Logical Design is complete when the following tasks have been performed:
Physical Design is defined as the process of describing the components, services, and technologies of the solution from the perspective of Development. Its purpose is to apply real-world technology constraints to Logical Design, including implementation and performance considerations. The output of Physical Design is a set of components, a user interface design for a particular platform, and a physical database design.
Physical Design can be likened to the third and final stage of designing a house. Once the basic architectural plan is complete, the contractors, like the Development team, create their wiring plans, plumbing plans, heating and ventilation plans, and so on—as "components" of the internals of the house.
In the Physical Design stage, the team:
Physical Design provides the basis for the Functional Specification, which Development, Testing, and Logical Management can use for quality assurance. Why is this important? Because Physical Design represents the last chance to validate the design before writing the code. Once the team has begun code development, design changes can still be made, but the cost to the project in time and resources becomes much higher than in the Planning Phase.
The Physical Design baseline can be established when enough information is available to start developing or deploying. Thus development and deployment can be started before the baseline is frozen. The Physical Design baseline can be frozen well into the Developing Phase to take advantage of opportunities for refinement, but it must be frozen before the solution can be stabilized.
As the Physical Design is being completed, it provides input into other tasks of the Planning Phase by:
It is important to note that the deliverables of the Physical Design Model help to form the deliverables of the Project Plan Approved Milestone, as follows:
When developing, reviewing, and approving the Master Project Plan and the Master Project Schedule, issues will arise that require tradeoff changes to Physical Design. For example, time and resource constraints might require changes to the application's scope or features.
The Physical Design segment of the MSF Design Process consists of four steps: research, analysis, rationalization, and implementation. (The research step is required in order to identify possible technologies to be used in the application.) Each step ends with its own baseline except for the implementation step, whose baseline is included in the overall Physical Design baseline.
The Physical Design baseline includes the specification baseline and constitutes the culmination of the research, analysis, rationalization, and implementation steps.
The goals during the research step of Physical Design are twofold:
By this point, the physical requirements of the application should be well known in a general sense—the application must serve so many people, it must carry out this many transactions per day, and so on. Fairly specific research may be necessary to determine detailed physical requirements, including building proof-of-concept trial applications and testing them.
The physical constraints of the infrastructure, on the other hand, are rooted in the organization's enterprise architecture. As we pointed out in Chapter 1, the organization's enterprise architecture may not be formally documented. If it isn't, this is an opportunity to establish its baseline.
As the team endeavors to list both the requirements of the application and its matching constraints, beginning with the application will yield one list, while beginning with the infrastructure will yield a somewhat different list. Building the list from both viewpoints ensures that nothing is missed. Examples of the constraints and requirements the list might include are:
One means of examining the current physical infrastructure is through topologies, which are maps showing some aspect of the infrastructure. For purposes of planning an application at the physical level, it is helpful to produce network, data, and component topologies. Examples of these are included in the following section on analysis. Infrastructure topologies produced during the research step of Physical Design are of the current state of the infrastructure.
Once the physical constraints and requirements are listed, the next task is to manage the risks presented by any conflicts or gaps that have been identified between the three topologies. This is a five-step process:
The result of this process is a preliminary risk assessment and mitigation plan for the Physical Design of the application, which will become part of the project's Master Risk Assessment Document.
The research step of Physical Design is complete when the following tasks have been performed:
The focus in the analysis step of Physical Design is on selecting candidate technologies for the implementation, based on an understanding of the application requirements. Note that these are candidate technologies. The final choice will be made later. Once the potential technologies have been chosen, the team can draft a preliminary deployment model, taking into consideration these technologies.
In evaluating candidate technologies, the team should address business considerations first, then take into account enterprise architecture considerations, and only then address technology considerations. The technologies should not be evaluated on their technological merits until the first two steps have been completed.
Business considerations include the following:
Other points to consider include deployment, competitive advantage, time to market, and industry perception.
Enterprise architecture considerations include the following:
Technology considerations include the following:
With the candidate technologies in mind, the team can now draft a preliminary deployment model consisting of network, data, and component topologies. At this stage in Physical Design, these topologies are proposed but are not yet the selected topologies.
The network topology is an infrastructure map that indicates hardware locations and interconnections. A current-state version of the infrastructure map was developed in the research step. At this point, it might require changes to support the new Physical Design. A sample network topology diagram is shown in Figure 6.7.
Figure 6.7 Sample network topology
The data topology is a data distribution map that indicates data store locations in relation to the network topology. Again, a current-state version was constructed in the research step, but a new data distribution strategy or new data technologies might need to be considered to support the new Physical Design. Figure 6.8 shows a sample data topology.
Figure 6.8 Sample data topology
The component topology is a component distribution map that indicates the locations of components and their services in relation to the network topology. The current-state version should already exist from work in the research step. Any new components and services required by the new application should now be added, and any updating required to reflect changes in the other topologies should also be carried out. Figure 6.9 shows a diagram of a sample component topology.
Figure 6.9 Sample component topology
The analysis step of Physical Design is complete when the following tasks have been performed:
The team has done its research and has analyzed that research. At this point, it is time to begin solidifying the design. Determining a packaging and distribution strategy is part of this process.
The team might be thinking, "We can't plan for packaging and distribution when we haven't solidified the component model," and the team would be right. By the same token, the team cannot complete the component model without a firm packaging and distribution plan. The tasks involved in the rationalization step are both interactive and iterative. In some cases, it may make more sense to begin with the component model, while in others the packaging considerations will take precedence. One possible guideline is to begin with the task that seems the most complex or the most critical.
When determining the packaging and distribution strategy, the team should follow three basic steps. The first is to consider various packaging rationales, or reasons to choose a particular strategy. These could include any of the following:
The second step is to align the strategy with the programming model. Because the programming model is not firm at this point, this step is inherently interactive in nature.
The third step is to determine the design tradeoffs that impact the strategy, based on the rationales used in the first step. For example, the team might have based its strategy primarily on the performance needs of the application. In doing so, any necessary scalability might have been compromised, and if it has, the team needs to decide what it will do about this tradeoff.
The team is now ready to begin defining components. Although there are many ways to do this, we recommend that the first cut at the component model be based on the MSF Application Model's three logical service layers: user, business, and data. As shown in Figure 6.10, the services are distributed throughout the topology. The team can then package candidate components from the same logical service located in the same place in the topology.
Figure 6.10 Sample component model
When the component model is complete, the team is ready to finalize the distribution of those components. Again, the first cut at distribution should be based on the three logical service layers: user, business, and data. Note, though, that the use of three logical services does not in any way imply a distribution of three physical locations. It is entirely possible to build an N-tier application that runs on a single computer. By the same token, a distribution strategy for a multi-site, complex application may involve 10, 20, or more physical locations.
Throughout the rationalization step, the team should be validating the proposed components and their packaging and distribution. Questions to ask include "Do the components fit the packaging strategy?" "Are we meeting the design goals and application requirements we outlined earlier?" "Do the components we have derived actually match up with the logical design?" and "Are we fitting into the enterprise architecture?"
One way to validate the design is to build prototypes and proof-of-concept test applications. As the team defines more and more components, they should be included in these trial applications and the results should be observed.
Although the development team has been doing validation work throughout the rationalization step, it should carry out formal component refinement and validation at the conclusion of this step. This validation task should be done by the Development and Testing roles. In some cases, it may be worthwhile to schedule a formal Quality Assurance review of the component design, carried out by an outside expert with component design expertise.
What would such an expert be looking for? Here are some attributes of a good component plan:
Cohesion and Coupling
One of the design goals noted above is high cohesion and loose coupling. Cohesion is the relationship among different internal elements of a component, whereas coupling is the relationship of a component to other components.
A component whose internal elements—primarily its services—are closely related is said to have high cohesion. Cohesion can be both beneficial and non-beneficial, depending on the cause of the cohesion.
Beneficial types of cohesion include the following:
Non-beneficial types of cohesion include the following:
Metrics that can be used to determine the amount of coupling include the following:
Ultimately the arm's-length flexibility goal should be to have high cohesion and loose coupling. The high cohesion provides a better definition of the component's function and behavior. An example would be organizing services by business function so that each component has only the services that pertain to its function. The loose coupling provides more flexibility and independence, and leads to better-defined and simpler interfaces. An example would be organizing relationships among components by business function so that each component interfaces with the minimum number of other components for access to data.
Even though the team carries out a formal refinement process at the end of the rationalization step, it can expect refinement to continue during development and stabilization. Packaging and distribution will change as the team tests for the results of the determining criteria, such as performance. Thus, if the system fails to meet performance objectives during testing, the team may have to revisit the packaging and distribution plan that was supposed to provide the expected performance levels.
The rationalization step of Physical Design is complete when the following tasks have been performed:
The last step of Physical Design is implementation. During this step, the team specifies the programming model that Development will use, the interfaces for each component, and the internal structure of each component.
The programming model, which could also be called the programming specifications or standards, does the following:
Several aspects need to be considered when building a programming model, some of which are highlighted in Table 6.6 and discussed at length in subsequent chapters.
Table 6.6 Programming model aspects
|Implementation technologies||Programming language; API; servers and server technologies; and other technologies affecting implementation. Implementation technologies are a consideration because some technologies require a specific programming model to take full advantage of them. For example, Microsoft Transaction Server requires single-entrant, single-threaded, in-process components.|
|Stateful vs. stateless objects||A stateful object holds private state accumulated from the execution of one or more client calls. A stateless object does not hold private state. Typical questions to be addressed include where state will be kept and tradeoffs such as scalability, complexity, and performance.|
|In-process vs. out-of-process function calls||In-process is fast and direct. Out-of-process on the same machine is fast and offers secure interprocess communications. Out-of-process across machines is secure, reliable, and offers a flexible protocol based on Distributed Computing Environment, Remote Procedure Calls (DCE-RPC).|
|Connected vs. connectionless modes||In connected application/component environments, the various components participating in the service of a task must have real-time, live connections to each other to be able to function. If the connection is severed because of problems at run time, the components involved in the interaction fail. Real-time applications typically must be run in connected mode. Applica- tions/components that are written to run in a connectionless environment are able to reestablish a connection as and when needed.|
|Synchronous vs. asynchronous programming models||A synchronous programming model blocks the calling component from proceeding with other work until the called interface completes the requested service and returns control to the calling component. An asynchronous programming model allows components to send messages to other components and continue to function without waiting for a reply. A component designed to use an asynchronous programming model is harder to program, but it lends itself to more scalability. Each component isn't blocked and doesn't have to wait for a spawned process to complete before proceeding.|
|Threading model||Choosing the threading model for a component is not a simple matter because it depends on the function of the component. A component that does extensive I/O might support free-threading to provide maximum response to clients by allowing interface calls during I/O latency. On the other hand, an object that interacts with the user might support apartment threading to synchronize incoming COM calls with its window operations.|
|Error handling||Certain programming and deployment model decisions will constrain the number of error handling options available.|
|Security||A given component or service has four security options: component-based, at either the method level, the interface level, or the component level; database-based; user-context based, in either an interacive method using system security, or a fixed security within the application; or role-based, such as a night clerk or general manager.|
|Distribution||Having three logical tiers does not necessarily translate into three physical tiers. The logical tiers will be spread among the physical tiers. For example, some business services reside on the client.|
There typically is not just one programming model for all components. There may be many programming models for an application, depending on the different requirements of the different components.
Although not a part of the programming model itself, an important consideration is the skill set and experience of the technical people who will implement the programming model.
When the programming model has been outlined, the team is ready to specify the external structures of the components. These are outlined in the component interface, which:
The specification of the component interface must include all the different ways the component can be accessed and, if possible, include examples of how the component can be used for each way it is accessed. A sample is shown in Figure 6.11. Note that the interface must be documented and understandable to the developers who will be using the components.
Figure 6.11 Sample component interface specification
There are three implications to consider when creating component interfaces:
The interface contract defines the parameters, the data types, any interaction standards, and a description of the interface. The degree of specificity depends on user needs—ultimately, the degree of reuse.
Finally, the team is ready to specify the internal structure of the components. (Note that internal structure is important only when building the component itself. When assembling components, the interface is the important factor.) Many factors come into play when defining the internal structure of a component. The most significant factor is the language or tool used to implement the component. The other factors are used as criteria to determine the component's internal structure. For example, when writing the first N-tier application for a large organization that plans to develop other applications that will use many of the same services, the internal structures of the components should be designed so as to enhance their reusability.
When the internal structures have been specified, the baseline for the implementation step is established. This baseline is merged into the overall Physical Design baseline. The implementation step of Physical Design is complete when the following tasks have been performed:
The design process is now complete, having moved from the reality of user requirements, through Conceptual Design, through the abstraction of Logical Design, and back to the reality of Physical Design and the completed application design. The output of the process will become the basis for the Functional Specification, which feeds the Master Project Plan, the Master Project Schedule, and a revision of the Master Risk Assessment Document.