Traditional Structured Systems Analysis and Design

ABSTRACT:

After surveying many articles as well as the current and popular textbooks on Systems Analysis and Design which include but are not limited to those mentioned in the references, tI have observed much discussion on the use of object-oriented analysis and design over the traditional structured systems analysis and design. While the use of OOAD methodology is justified in many cases, in some cases it may be inappropriate and we should consider the use of the traditional structured analysis methodology in the design and development of information systems. This essay attempts to clarify the use of these methodologies, to compare the advantages and disadvantages of each and to make recommendations.

1. INTRODUCTION

The existing methodology used primarily in industry today in building computer-based applications is known as structured analysis and design. This methodology came into existence as a result of the structured programming techniques introduced in the 1970’s. This structured systems development methodology (SDM) has been fine-tuned and used for many years in the real world. However, during the last several years object-oriented languages have become increasingly more popular and more widely used in industrial organizations as well as university institutions. As this trend continued a methodology was developed to assist the programmer with the development of applications using object-oriented languages. This methodology has become known as object-oriented analysis and design (OOAD).The OOAD strategy approaches the problem from an object perspective as opposed to a functional perspective, which is the primary focus of the traditional structured development methodology. During the last few years the increasing use of OOAD over the traditional structured development methodology has spread significantly. As newer and more sophisticated object-oriented languages are created, there appears to be an even greater need for an object-oriented approach to develop business applications. However, does this need warrant greater use of this new methodology over the traditional one? We will compare the two methodologies and their advantages and disadvantages in order to address this problem.

2. TRADITIONAL SYSTEMS ANALYSIS & DESIGN

The systems development life cycle (SDLC) or the structured systems analysis & design methodology (SSAD) is a framework of activities and tasks that need to be accomplished to develop an information system. This methodology as mentioned previously is called the waterfall model as each major phase of the methodology flows downward into the next phase (Wu and Wu, 1994). Consequently, this methodology is a strategy consisting of various techniques, tools, documentation and tasks that need to be integrated in order to develop the system. The SSAD is based on the concept of functional decomposition where the analyst breaks down the system into the basic processes that make it up and then breaks these down into smaller ones and so on until the analyst understands all the essential components of the system being investigated (Senn, 1989). The basic principles of the SSAD methodology can be summarized as follows:

(1)The first principle of SSAD is top down functional decomposition. Here the system is considered in its entirety where the analyst first tries to understand the key features of the system, ignoring the smaller details until later.

(2)Next the scope of system is defined where the physical details of the existing system are analyzed. The analyst focuses on two objectives: what the new system should do and how it should do it.

(3)This methodology requires that the user be involved from the beginning to the end of project development. The analyst will meet with the user regularly to resolve problems and validate the user’s needs. This also requires that the analyst possess highly developed communication skills.

(4)The two primary concerns in developing an information system are processes and data which are modeled independently with this methodology. The processes are modeled by the data flow diagrams which illustrate the flow of data between processes and data stores and how it is altered as it moves through the system from source to destination. Data models are defined by entity-relationship diagrams (ERD’s) which describe the data (entities) and the various associations among them.

(5)This principle of independently modeling the data and processes continues throughout the design phase. The schema for the conceptual database model is defined and the database is developed, normalized and populated with data during implementation. At the same time the process model is transformed into modules to be developed, and this phase also includes developing the detailed program logic. From the structure charts and program logic the program modules are then developed. Finally, to validate that the system meets the user’s requirements, goals and objectives, we subject the system to various levels of testing.

3. OBJECT ORIENTED ANALYSIS & DESIGN

Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML).

The object-oriented approach to system development views an information system as a collection of interacting objects that work together to accomplish tasks. Conceptually there are no separate processes or programs; there are no separate data entities or files. The system in operation consists of objects. An object is a thing in the computer system that is capable of responding to messages.” Consequently, the OOAD methodology can be broken up into two major areas:

(1) Object-oriented analysis. This is concerned with developing an object-oriented model of the problem (application) domain. These identified objects represent entities, and possess relationships and methods that are necessary for the problem to be resolved. Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it. Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of the information that exists in the area being analyzed. Analysis models do not consider any implementation constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built. Implementation constraints are dealt during object-oriented design (OOD). Analysis is done before the Design.The sources for the analysis can be a written requirements statement, a formal vision document, interviews with stakeholders or other interested parties. A system may be divided into multiple domains, representing different business, technological, or other areas of interest, each of which are analyzed separately. The result of object-oriented analysis is a description of what the system is functionally required to do, in the form of a conceptual model. That will typically be presented as a set of use cases, one or more UML class diagrams, and a number of interaction diagrams. It may also include some kind of user interface mock-up. The purpose of object oriented analysis is to develop a model that describes computer software as it works to satisfy a set of customer defined requirements.

(2) Object-oriented design. This is concerned with developing an object-oriented model of the system necessary to implement the specified requirements. The analysts and programmers must think in terms of things (objects) rather than processes or functions. Object-oriented design (OOD) transforms the conceptual model produced in object-oriented analysis to take account of the constraints imposed by the chosen architecture and any non-functional – technological or environmental – constraints, such as transaction throughput, response time, run-time platform, development environment, or programming language. The concepts in the analysis model are mapped onto implementation classes and interfaces. The result is a model of the solution domain, a detailed description of how the system is to be built.

Although object-oriented technologies have existed for quite some time, the phrase “object-oriented” has gained much popularity (along with buzzword status) in recent years. Indeed, the phrase is often bandied about with reckless abandon, which serves to obscure its real meaning. To further confuse matters, it is used to describe everything from development environments to programming languages to databases.

So what does the term object-oriented really mean? The term seems to be thrown about indiscriminately; anything from programming languages to drawing tools might be labeled as “object-oriented”. There are primarily three uses of object-oriented methodology: object-oriented analysis (OOA), which deals with the design requirements and overall architecture of a system; object-oriented design (OOD), which translates a system architecture into programming constructs (such as interfaces, classes, and method descriptions); and object-oriented programming (OOP), which implements these programming constructs. So, object-oriented can be taken to mean the various methodologies, described briefly herein, used to design and implement software.

4. CONCLUSION

For a specific application the first task is to decide which methodology is most appropriate for its development. Sometimes we may have to adapt different methodologies. Some guidelines might be that simple tasks may be better achieved by structured programming methods while the use of object-oriented methods might be better suited for higher levels of abstraction. This may also help with module design and problem decomposition. For situations in which the data is more likely to change than its functionality, objects would be more appropriate.

In order for companies to transition from the SSAD methodology to the OOAD methodology, they need to understand the substance of the change and the barriers that must be overcome; otherwise moving to this new methodology may end in failure. Consequently, for analysts and programmers to embrace this new methodology, they need to reorient their thinking from the functional perspective to the object perspective. More specifically for analysts and programmers with experience in the traditional methodology, training should be given to emphasize the modeling aspects of the methodology as opposed to learning the syntax and features of an object-oriented language. The transition from SSAD to OOAD can be made easier by supervised training and the use of object-oriented tools.

Although the OOAD methodology provides many benefits, it does not resolve all the issues associated with the traditional SSAD methodology. There are still some shortcomings and weaknesses that need to be addressed which include: the amount of training needed, the time necessary to learn the new methodology, and the amount of money to invest in it. According to Glass (Glass, 2002) there is no guarantee that the adoption of a new technology will result in it being used effectively and efficiently. In addition, if the organization completely submerges itself in the new OOAD methodology, there can be costly and destructive results. Consequently, to take advantage of all the positive benefits that the new methodology offers, the organization needs to develop a carefully planned and gradual introduction of the methodology to all the system developers.

Before any effort is made to use the OOAD methodology as mentioned previously, it is imperative that the necessary education be provided in order to assure its success. The skills, knowledge and experience of the systems analyst and programmers who are indoctrinated in the traditional SSAD methodology can be enhanced by the new methods. Since changes to the basic structure of the OOAD methodology are stressful to manage, first attempts to use this methodology should be applied only to small scale and non critical applications. This will enable the company to receive immediate feedback and to have time to make any necessary modifications in the application of the OOAD methodology. Consequently, the benefits and advantages gained from using the new OOAD methodology can be much greater and more rewarding for the organization in the long term than using the traditional SSAD methodology.