Section 0: Module Objectives or Competencies
| Course Objective or Competency | Module Objectives or Competency |
|---|---|
| The student will be able to assess and apply Object-Oriented analysis and design methods... | The student will be able to compare and contrast Structured Systems Analysis and Design approaches with Object-Oriented Analysis and Design approaches in order to be better informed when selecting the best tool for the task at hand. |
Section 1: Overview
An online search for comparisons of structured systems development techniques versus objected-oriented development techniques yields a wealth of conflicting information.
There is no consensus, just definitive contradictions. And it seems that every "webpinion" is intent on proving the adage "often mistaken, never in doubt".
About the only shared opinions that can be found are that OOAD is better for huge projects, and "handling the many intricacies of the Unified Modeling Language might be far more complex than the development of most information systems in business."
Section 2: General Comparisons
The tables below sum up the two approaches:
| Structured | Object-Oriented | |
| Life Cycle | Sequential with iterations permitted | Iterative and incremental |
| Focus | Processes | Objects |
| Risk | Medium | Low |
| Reuse | Low | High |
| Maturity | Mature and widespread | Emerging |
| Suitability | Smaller, well-defined projects with stable user requirements | Risky large projects with changing user requirements |
| Phase | Structured | Object-Oriented |
| Analysis |
Structuring Requirements
|
Requirements Engineering
|
| Design |
DB Design
|
Design Elements
|
The tables above capture the most obvious differences, with the primary difference being the focus:
- Structured development is task-centric, that is, based around data structures and subroutines.
-
Object-oriented development is data-centric, and shifts attention to the data itself.
- Instead of asking "what do I want to do and what will I need to know to do it?", you ask "what kind of things do I want to have and what can those things do for me?".
- Instead of designing your functions first and then coming up with data structures to support them, you design types first and then come up with the operations they need to perform.
Another difference, as noted earlier, is the project size:
-
Structured development can save time and energy when designing simple systems that do not
require classes or complex functions.
- Time and energy are not wasted designing classes since an entire working system could be developed within the same time period.
- Structured development may be more appropriate for developing small to medium web-based systems.
- Structured programs are often considered to be easier to read and understand.
-
Object-oriented development is touted as being extremely suitable for sustaining huge software
and web development projects.
- Object-oriented development allows the developer to save a lot of time and energy when developing programs as the components of the programs are in the form of objects which can be plugged into the program wherever they are needed.
Complexity and speed are often overlooked:
- Object-oriented development tends to be more complex than structured development as it may require more design decisions and consequently the entire task of managing the project may be more difficult for the inexperienced developer.
- Performance differences between structured and object-oriented systems may be minimal, but in general object-oriented code can be more expensive in terms of CPU usage than procedural code. (link)
Section 3: One Comparison
| Advantages of Structured Analysis and Design |
| There are distinct milestones for SSAD which make tracking easier for project management. |
| Since SSAD is very visual, it makes it easier for users/programmers to understand. |
| SSAD makes good use of it graphical analysis and tools such as DFDs. |
| SSAD is a very well-known and established methodology in the industry. |
| SSAD has been around for a long time and consequently is a mature technique. |
| SSAD allows for a means of requirements validation. |
| SSAD is relatively simple and easy to understand. |
| Disadvantages of Structured Analysis and Design |
| Since SSAD is process-oriented, it ignores the non-functional requirements. |
| Since SSAD can be non-iterative if the analyst lacks sense, requirements changes can require restarting the entire process. |
| SSAD may have less user/analyst interaction. |
| Except for the logical design and the DFD's, SSAD provides no other tools for communication with users, and therefore it is more difficult for users to measure progress. |
| In SSAD it is more difficult to decide when to stop functional decomposition and to start building the system (unless you listen to your professor). |
| SSAD may not be completely compatible with object-oriented programming languages, as it was originally designed for structured programming languages and not object-oriented ones (Jadalowen, 2002). |
| Advantages of Object-Oriented Analysis and Design |
| OOAD significantly simplifies the development of the system compared to SSAD (ignore the 14 types of UML diagrams behind the curtain!). |
| In comparison to SSAD, the development time, the level of organization, the robustness, and the code reuse are all greatly enhanced by the OOAD methodology (Sommerville, 2000). |
| In OOAD there is no separation between the analysis and design phases, which improves communication between the users from beginning to end of project development (see contradiction later). |
| Since objects relate to entities (things) with which we commonly interact there is usually a clear mapping between the real-world entities and the corresponding objects in the system. This significantly improves understanding of the design (Sommerville, 2000). |
| In OOAD the software is resilient to change, resulting in a higher level of confidence in the correctness of the software which helps to reduce the risks in developing complex systems (Booch, 2007). Remember, however, reminders about maintainability and modifiability with SSAD. |
| In OOAD, when developing objects with complex interactions, the analyst thinks on a different level of detail than is possible with structured code. In this case the analyst thinks about which attributes the object needs to know and how it will act on those attributes (Phelan, 2002). |
| Since objects are independent encapsulations of data and methods, they are reusable and can be used in other projects in addition to the one for which they were originally created. This will reduce design, programming and validation costs. |
| OOAD improves the quality of the system if components are reused from other systems or libraries. |
| OOAD enables the standardization of objects which increases design understanding and decreases the risk associated with project development. |
| Disadvantages of Object-Oriented Analysis and Design |
| In OOAD the initial designs for the system may be too simplified to be adequate. |
| In OOAD there tends to be much more focus on code than in SSAD. |
| In OOAD it is not an easy task to determine all the necessary classes and objects needed for the system. |
| Many times object-oriented programming is used in conjunction with analyzing the various functions of the system; however, these function based methods are inappropriate in OOAD. |
| OOAD tends to overemphasize object methodology in general where, in fact, another approach might be much better to use for the design and development of a system, depending on the particular circumstances. |
| Reusability could be detrimental if there is no explicit reuse procedure in place, resulting in many of the systems developed with this methodology not contributing to successful reuse on a large scale (Hantos, 2005). |
Section 4: Overall Approach
The planning-analysis-design-implementation stages are the same in both SSAD and OOAD, but the way in which they are performed can be different.
Primary Tool
The structured approach tries to understand a problem using data flow diagrams, while the object-oriented approach uses Use Cases.
Model Varieties
There are mainly three diagrams or models used in the structured methodology: a data flow diagram, an entity-relationship diagram, and a structure chart.
The OO methodology uses about fourteen diagrams and models, namely use case diagram, activity diagram, class diagram, object diagram, sequence diagram, communication diagram, state machine diagram, package diagram, deployment diagram, component diagram, composite structure diagram, interaction overview diagram, profile diagram, and timing diagram.
- Understanding the evolution of these models and their relationships with each other is important
for the successful design and development of an information system.
Line of Demarcation
While the structured approach provides a rather blurry separation between the phases from the beginning to the end of the systems development life cycle, the OO approach is even less definitive - there are no clear-cut steps in moving from analysis to design, and from design to implementation; or the steps are so complex and time-consuming that no one attempts to clarify them.
- The same UML diagramming techniques are used throughout all phases of the SDLC, although some diagrams are more important in some phases than the others.
- As the developers move through the SDLC activities, the diagrams gradually become more detailed, blurring the separation between the analysis and design phases.
- Understanding the continuous analysis of a problem through use cases is fine, but when it comes to design, it becomes very complex because there are many models to deal with.
More Comparison Points
The following table provides additional comparison points:
Section 5: Other Opinions
Video Praise for OO
Here is a video by someone sold on the OO Analysis and Design approach:
Conclusion?
Which is better? Both are effective approaches if done correctly by an analyst with common sense.
- The consensus, such as it is, seems to be that OO approaches are better suited for large systems.
Resources
Here are some inconclusive viewpoints to consider: