In this lesson, the logical and physical model of a systems architecture is discussed. Also, a comparison between the logical and the physical model is provided. Finally, the stages involved in developing conceptual and logical designs and deriving the physical design is also explained.
Be familiar with the similarities and differences between conceptual, logical, and physical design.
Be familiar with the stages involved in the creation of conceptual, logical, and physical designs.
The ANSI standard defines three levels of system architecture. They are also called the three data models of the system: the external model (or view), the conceptual model, and the physical model.
In this lecture we describe the logical model of the system in some detail.
13.2 systems Architecture Fundamentals - Conceptual, Logical, Physical Designs
Responsibilities of the systems architect is to create, review, and update the designs or blueprints to provide an overall direction for the system to be developed. These developed blueprints are used as a roadmap to the system developers.
System design is involved in all stages of the development cycle, from the beginning to the end. This plan is used as a guide to system implementation. At each stage a model/blueprint/roadmap is developed. Each stage uses the output of the previous stage in order to design its outcomes.
There are different types of designs and stages in the life cycle of the system development. A data model may be one of three types according to ANSI in 1975.
These types are the conceptual design, the logical design and the physical design. The significance of this ANSI is that allows the three data models to function independently from one another. For example, the storage technology that is needed at the physical model can be modified without having an effect on the logical/conceptual model. Another example is the table/column structure which can change without necessarily affecting the conceptual model. However, in each example, the structures in each model must remain consistent with the other models. The table/column structure can be different from the entity attributes but it has to fulfill the purpose of the conceptual entity class structure.
At the early phases of software development projects the developers pay close attention to the design of a conceptual data model. This conceptual model can be transformed into a logical model and at a later stage can also be changed into a physical data model. Additionally, a conceptual data model can be applied directly.
The three data models are described in more detail as follows:
Conceptual Design: A conceptual design is a high level design that abstracts the system. It only illustrates the more important components and entities of the system. The conceptual design provides an understandable model/picture of the overall purpose of the proposed solution. The conceptual design describes the semantics of a domain, and the scope of the modeled system.
A conceptual design indicates the information and detail that can be communicated using the model. Components and entities of the system at the conceptual level may include external systems that need to be integrated with the system in question in order for it to function correctly, high level data flow, system functionality, entity classes as well as representing how these entity classes are linked to one another.
The conceptual model could be thought of as the black box diagram of the system to be developed. For instance, parts of the diagram could be a simple representation of an external technology/system that is needed with only its role and purpose are identified at this stage, not its name.
Logical Design: A logical design is a more detailed and thorough representation of the system that includes the main parts of the system, the main entities and their interactions. At this stage logical design describes the structure of some domain of information. This consists of descriptions of tables and columns, object oriented classes, and XML tags, among other things.
The data flows and connections between components are detailed in this stage. At this stage, the logical design will be targeted and used by the developers and system architects. However, it can also be used by business managers for example as it is good practice to get them involved in the design process in order for them to fully understand the system and how it works. Logical designs do not detail or include physical components such as server names or addresses in case of the design of Internet-based systems, but they do include the business services involved, the applications used and their names and any related additional information.
Physical Design: A physical design, similar to the logical design, has all the main components and entities of the system indicated. However, in addition to this, a physical design allows the representation of these main components and entities in relation to their physical components such as servers, databases, storage locations, etc. For example, in case of developing a software system the physical design would represent the physical components such as the operating system, the CPU, physical memory locations and so on. Physical design when used to develop a software system illustrates how the data is stored physically, for example using partitions and Central Processing Units (CPUs).
Any physical restraints or inadequacies should also be identified within the physical components, data flows, or connections between them. Physical design is usually used by the development and implementation team to develop an implementation design.
13.3 Comparison between Logical and Physical Design
There are significant differences between the logical design and physical design. These differences are listed in Table 1.
Logical components illustrate "what" the system will do.
Physical components illustrate "how" the system will be executed.
Most basic form of information. Focused on data and process components of the system.
Focus is on the physical components of the system such as the hardware components (servers, databases, CPU, operating systems, etc.)
How often the design changes
Logical design is closely related to the business side of things. In other words, if the business process is changed, then the logical design has to be altered in order to accommodate this change.
The physical design is linked to the available physical technology.
Logical design always comes before the physical design. The physical design is dependent on the logical design.
The physical design always comes after the logical design and is directly dependent on it. A common mistake amongst developers is the "cart before the horse" phenomenon in which they focus on the physical design and neglect the more important logical side of things.
13.4 Logical Model Overview
In order to build and develop a software system, developers first develop a complete logical design of the system. Then the physical design is developed.
The focus on the physical design of a system is a common phenomenon amongst developers. This is due to the fact that the physical design allows the developers to work with 'physical' objects that can be touched and seen, unlike the logical design where they are dealing with intangible aspects of the system.
Because people are more attracted to the physical design model, and not the logical model, they find it easier to describe screen or report layouts that are components of the physical model as opposed to business requirements that are described in the logical design phase.
Developing an incorrect/flawed logical design has a negative effect on the whole design process as it causes problems in the physical design. For example, the wrong hardware may be used as a result of a mistake in the logical design. Developing a correct logical design saves a lot of cost and time since the logical model is much cheaper than the physical model. We could test the logical model at early stages of the system development. Before building a physical design, it is hugely important to first build the system logically, in order to gain a better/more clearer understanding of the system and see if it actually works.
The advantages of developing the logic model of the system include:
Builds a common understanding of the system and expectations for its performance
The logical model is good for sharing ideas, identifying assumptions, team building, and communication
Helpful for system design or improvement
The logical model is stable. However, it changes depending on the changes that occur at the business level, for example if the business merged with another business and the processes needed to be changed accordingly. On the other hand, the physical model is more flexible as it can change many times according to the changes in technology. For example if a new, more advanced hardware is purchased by the business, it can easily replace the old one.
During logical design stage the developers define the following:
Logical model of the business (functions)
Logical model of a system (sub-systems)
Logical data base model for a system
Logical data base model for the enterprise
Today the majority of developers are more technology oriented. They concentrate their efforts toward the physical model but it is much more beneficial to focus on the logical model as it is very closely related to business objectives.
The logical design model review is used to confirm that the logical model of the system is sufficiently complete, correct, and stable to allow for the physical design to begin. During the model's review deficiencies are identified in the logical model. These deficiencies must be resolved, and changes generated by the review must be incorporated into the logical design as directed by the technical review team. The high level architecture (logical model) must be reviewed to verify its ability to satisfy the approved functional, data, and support requirements. Components of the logical model and other requirements shall be allocated to components of the technical architecture. Logical design model must count for all allocated requirements. Issues governing the possibility of future change in the business or information technology infrastructure and the ability of the information and technical architectures to endure those changes shall be identified and appropriately addressed.
The logical design review must be conducted in accordance with quality assurance. The approved logical design model and approved products of detailed requirements analysis shall be used to develop the physical model.
13.5 Developing Conceptual & Logical Design & Deriving the Physical Design
Given a conceptual design of the system, the principles of modular design are applied to derive the components and services of the logical design. Conceptual design reflects a user-based vision of the system physical design. There are some concepts that are needed to be known by the system design engineer. These include:
The designer is expected to know how conceptual design relates to logical design. Logical design identifies the business objects and underlying services required by the conceptual design.
The designer is expected to assess the potential impact of the logical design on performance, maintainability, extensibility, scalability, availability, and security.
The designer is expected to know how the logical design that he derives from the conceptual design will have consequences for the final product. The logical design affects many of the desired qualities of a good software solution, such as those listed in this objective.
The designer is expected to design the properties, methods, and events of components of the logical design model. The components that he designs will be implemented as objects with their own members (properties, methods, and events).
Building and constructing the Logic Model/design is done in five stages as follows:
Stage 1 (Collecting the Relevant Information): In this stage the relevant information about the system is collected. Whether designing a new system or describing an existing system, it is essential that the manager or a work group collects information relevant to the system from multiple sources. The information will come in the form of system documentation, as well as interviews with key stakeholders both internal and external to the system. While strategic plans, annual performance plans, previous system evaluations, pertinent legislation and regulations and the results of targeted interviews should be available to the manager before the logic model is constructed, as with any project, this will be an iterative process requiring the ongoing collection of information.
Stage 2 (Defining the problem that the system solves and its context): Defining the need for the system is the basis for all that follows in the development of the Logic Model. The system should be grounded in an understanding of the problem that drives the need for the system. This understanding includes understanding the problems customers face and what factors cause the problems. It is these factors that the system will address to achieve the longer term goal - working through customers to solve the problem.
One of the greatest challenges faced by work groups developing Logic Models is describing where their system ends and others start. For the process of building a specific system logic model, the system's performance ends with the problem it is designed to solve with the resources it has acquired, including the external forces that could influence its success in solving that problem.
Stage 3 (Defining the Elements of the Logic Model): This is defining the elements of the logic model in a table. Building a logic model usually begins with categorizing the information collected into columns in a table. Using the categories the manager goes through the information and tags it as a resource, activity, output, short term outcome, intermediate outcome, long term outcome or external factor. Since we are building a model of how the system works, not every system detail has to be identified and cataloged, just those that are key to enhancing system staff and stakeholder understanding of how the system works.
Stage 4 (Drawing the Logic Model): In this stage the logic model is constructed. The logic model captures the logical flow and linkages that exist in any performance story. Using the system elements in the table, the logic model organizes the information, enabling the audience to understand and evaluate the hypothesized linkages. Where the resources, activities and outcomes are listed within their respective columns in the story, they are specifically linked in the model, so that the audience can see exactly which activities lead to what intermediate outcomes and which intermediate outcomes lead to what longer term outcomes or impacts.
The logic model is usually set forth as a diagram with columns and rows, with the abbreviated text put in a box and linkages shown with connecting one-way arrows. We place inputs or resources to the system in the first column at the left of the model and the longer term outcomes and problem to be solved on the far right column. In the second column, the major system activities are boxed. In the columns following activities, the intended outputs and outcomes from each activity are shown, listing the intended customer for each output or outcome.
The rows are created according to activities or activity groupings. If there is a rough sequential order to the activities, as there often is, the rows will reflect that order reading from top to bottom of the diagram. This is the case if the accomplishments of the system come in stages. When the outcomes from one activity serve as a resource for another activity chain, an arrow is drawn from that outcome to the next activity chain. The last in the sequence of activity chains could describe the efforts of external partners. Rather than a sequence, there could be a multi-faceted approach with several concurrent strategies that tackle a problem.
Stage 5 (Verifying the Logic Model): In this stage the logical model is verified with Stakeholders. As the logic model process unfolds, the work group responsible for producing the model should continuously evaluate the model with respect to its goal of representing the system logic, how the program works under what conditions to achieve its short, intermediate, and long term aims. The verification process followed with the table of program logic elements is continued with appropriate stakeholders engaged in the review process. The work group will use the logic model diagram(s) and the supporting table and text. During this time, the work group also can address what critical information they need about performance, setting the stage for a measurement plan.
In this lesson, the logical and physical model of a system's architecture is discussed. Also, a comparison between the logical and the physical model is provided. Finally, the stages involved in developing conceptual and logical designs and deriving the physical design is also explained.