Perhaps one of the most common questions about the cyclic methodology is, "How detailed should I get in each stage?" For the most part, each stage should focus on accomplishing a set of tasks. The conceptual design stage defined the goals of the users. The logical stage will define the interfaces of the components needed to fulfill the user's goals. The physical stage will be used to define the way we will need to code these components.
If we go beyond defining the public properties and methods of our objects in the logical stage, we are probably going too far. If we need to test new methods or techniques and you have to define the private methods and properties in the logical stage, this is fine. Otherwise, in the logical stage it is better just to define the component's interface.
Before the logical stage, we have been viewing the project from the outside. We were not concerned with how the system would fulfill our goals or even what components would exist inside the system. During the logical stage, we take our first peek inside the system. We will not look too deep; we are only going to look at what components are needed to enable our system to accomplish its goals. In the physical stage, we will take a closer look and define how these components will look. Let us a look at an example to get a better idea of what this means.
Imagine we were designing a car with the cyclic methodology. During the envisionment phase and the conceptual stage, we would describe how we want the car to look, the features we want in the car, the way the gauges will look, how the car will drive, etc. Essentially, we would describe every detail about how the car will look and drive by the end of the conceptual stage. In the logical stage, we would lift the hood and start describing the engine and all of the mechanical components.
Every component that we need to make the car perform and function the way we described it in the envisionment phase and conceptual stage will be defined in the logical stage. We will not say how these components will work; only what they must do (what services they must perform) and what characteristics (properties) they will have. Thus, we can say that we will build an engine that will have a certain color, have a certain range of revs per minute, etc. We will need an alternator that will produce a certain voltage, turn at a given rpm, etc. Once we know what components are needed for our car, we can describe how each component will communicate with each other and with the driver.
When we have finished describing the components and how they communicate, we will move on to the physical stage, where we will actually start defining the design of the components. In the physical stage, we would make blueprints of the engine specifying every characteristic of the engine. Finally, in the development phase we would choose the metal, mold it and actually build the engine.
In summary, we will start with the most general goal for the project (the first level goal) in the envisionment phase. We will expand this first level goal into a set of detailed goals that will be used to build the use cases in the conceptual stage. The use cases will be written in the language of application design (that is, we will talk about services and information input and output). In the logical stage, we will expand the use cases into a more detailed design of our application, i.e. a description of the components, the communication between the components, the communication between the components and the user, and the framework for the application, using sequence diagrams. Once we have done this, we will expand our sequence diagrams into a set of pseudo-code instructions in activity diagrams in the physical stage.
Pseudo-code involves summarizing the code you will write in a set of descriptive sentences.
For example, the following lines illustrate how we might write pseudo-code instructions for opening a connection to a database:
Initialize ADO Connection
Open ADO Connection
Each step will become one or more lines of actual Visual Basic code.
The flow of a project from the defining of the general goals to the creating of activity diagrams can be represented as follows:
All the way through the envisionment phase, the conceptual stage and the logical stage we are just looking at the system from the outside. In the physical stage we will be looking at the inside of the system. We are doing this because we are designing an object-oriented Visual Basic project. As we will discuss in this chapter, when we are using an object, we are not concerned with how an object does something, only what services it will need to perform and what properties it will have. We will therefore only be concerned with identifying the objects of the system and the properties and services they will have all the way through the logical stage. By the end of the logical stage, we will have a detailed description of the objects we will need to build for our system. These objects can be built from any programming language as long as they can perform the required services. To design an object-oriented Visual Basic application properly, we will need to take a look at some essential properties of objects.
Was this article helpful?
Grab These Lucrative Training Guides Right Now And Unlock The Secrets To Achieving ANY Goal You Want In Life! What If You Have All The Tools And Techniques You Will Ever Need To Set All The Right Goals And Get Any Result You Want In Life? These 5 Guides Will Show You How!