Traditional Structured Systems Examination and Design

ABSTRACT:

After surveying many articles as well as the existing and popular textbooks on Systems Examination and Design such as but are not limited by those described in the references, tI have observed much talk on the use of object-oriented examination and design over the traditional structured systems examination and design. While the use of OOAD methodology is justified in many cases, occasionally it might be inappropriate and we have to consider the use of the original structured analysis methodology in the design and development of information systems. This essay makes an attempt to clarify the utilization of the methodologies, to compare the advantages and disadvantages of each and also to make referrals.

1. INTRODUCTION

The existing methodology used mainly in industry today in building computer-based applications is known as structured examination and design. This methodology had become as a result of the organized programming techniques unveiled in the 1970's. This structured systems development technique (SDM) has been fine-tuned and used for many years in the real world. However, over the last several years object-oriented languages have become increasingly more popular and more widely used in professional organizations as well as university institutions. As this pattern continued a strategy was developed to assist the programmer with the development of applications using object-oriented dialects. This methodology has become known as object-oriented research and design (OOAD). The OOAD strategy approaches the problem from an thing perspective instead of a functional perspective, which is the principal focus of the traditional structured development technique. Over the last couple of years the increasing use of OOAD over the original structured development technique has multiply significantly. As newer and more sophisticated object-oriented languages are created, there appears to be a much greater need for an object-oriented method of develop business applications. However, will this need warrant greater use of the new strategy over the traditional one? We will compare the two methodologies and their benefits and drawbacks in order to handle this problem.

2. TRADITIONAL SYSTEMS Research & DESIGN

The systems development life pattern (SDLC) or the organised systems examination & design methodology (SSAD) is a construction 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 period of the strategy flows downward in to the next phase (Wu and Wu, 1994). Subsequently, this methodology is a technique comprising various techniques, tools, paperwork and tasks that need to be included in order to formulate the machine. The SSAD is dependant on the concept of functional decomposition where in fact the analyst breaks down the system into the basic processes which make it up and then breaks these into smaller ones etc before analyst comprehends all the fundamental components of the machine being investigated (Senn, 1989). The essential ideas of the SSAD methodology can be summarized as follows:

(1)The first rule of SSAD is top down practical decomposition. Here the machine is considered in its entirety where in fact the analyst first attempts to understand the important thing features of the system, ignoring small details until later.

(2)Next the opportunity of system is described where in fact the physical details of the existing system are analyzed. The analyst targets two aims: the particular new system must do and how it will get it done.

(3)This strategy requires that an individual be involved right from the start to the end of job development. The analyst will meet the user regularly to solve problems and validate the user's needs. This also requires that the analyst own highly developed communication skills.

(4)The two principal concerns in expanding an information system are processes and data which are modeled separately with this methodology. The operations are modeled by the data circulation diagrams which demonstrate the flow of data between functions and data stores and exactly how it is modified as it moves through the system from source to destination. Data models are described by entity-relationship diagrams (ERD's) which illustrate the info (entities) and the various associations included in this.

(5)This rule of separately modeling the data and processes proceeds throughout the look phase. The schema for the conceptual data source model is identified and the database is developed, normalized and populated with data during implementation. At exactly the same time the process model is changed into modules to be developed, which phase also includes developing the comprehensive program logic. Through the structure charts and program reasoning this program modules are then developed. Finally, to validate that the machine fulfills the user's requirements, goals and targets, we subject the system to various levels of testing.

3. Thing ORIENTED ANALYSIS & DESIGN

Object-oriented analysis and design (OOAD) is a software engineering approach that models something as several interacting objects. Each object represents some entity of interest in the system being modeled, and is seen as a its class, its express (data elements), and its tendencies. Various models can be created to show the static structure, dynamic action, and run-time deployment of these collaborating objects. There are a variety of different notations for representing these models, including the Unified Modeling Vocabulary (UML).

The object-oriented method of system development views an information system as a assortment of interacting items that interact to accomplish duties. Conceptually there are no different processes or programs; there are no different data entities or files. The system functioning consists of items. An thing is a thing in the computer system that is capable of responding to emails. " Consequently, the OOAD technique can be broken up into two major areas:

(1) Object-oriented research. This is worried about growing an object-oriented model of the challenge (request) area. These identified items represent entities, and have interactions and methods that are necessary for the situation to be resolved. Object-oriented research (OOA) can be applied object-modeling techniques to analyze the useful requirements for something. Object-oriented design (OOD) elaborates the examination models to produce implementation requirements. OOA focuses on what the system does, OOD how the system will it really. Object-oriented evaluation (OOA) talks about the problem domain name, with the aim of producing a conceptual model of the info that prevails in the area being analyzed. Research models do not consider any execution constraints that might can be found, such as concurrency, syndication, persistence, or the way the system is usually to be built. Implementation constraints are dealt during object-oriented design (OOD). Research is done before the Design. The resources for the analysis can be a written requirements assertion, a formal eye-sight file, interviews with stakeholders or other interested get-togethers. Something may be divided into multiple domains, representing different business, scientific, or the areas of interest, each of which are analyzed individually. The consequence of object-oriented evaluation is a information of what the system is functionally necessary to do, by means of a conceptual model. Which will typically be shown as a couple of use cases, a number of UML course diagrams, and lots of conversation diagrams. It could also include some kind of user interface mock-up. The goal of object oriented research is to develop a model that explains software applications as it works to gratify a couple of customer defined requirements.

(2) Object-oriented design. That is concerned with producing an object-oriented style of the system essential to implement the particular requirements. The experts and programmers must think in conditions of things (things) alternatively than functions or functions. Object-oriented design (OOD) changes the conceptual model produced in object-oriented analysis to use bank account of the constraints enforced by the chosen structures and any non-functional - technical or environmental - constraints, such as business deal throughput, response time, run-time program, development environment, or program writing language. The ideas in the analysis model are mapped onto execution classes and interfaces. The effect is a style of the solution site, a detailed description of the way the system is usually to be built.

Although object-oriented technologies have existed for quite some time, the key phrase "object-oriented" has gained much reputation (along with buzzword position) in recent years. Indeed, the word is often bandied about with reckless give up on, which provides to obscure its real interpretation. To further mistake matters, it is utilized to describe from development surroundings to programming languages to directories.

So exactly what does the word object-oriented really indicate? The term appears to be thrown about indiscriminately; anything from programming languages to attracting tools might be labeled as "object-oriented". You will discover mostly three uses of object-oriented strategy: object-oriented analysis (OOA), which handles the design requirements and overall structures of a system; object-oriented design (OOD), which translates something architecture into coding constructs (such as interfaces, classes, and method information); and object-oriented development (OOP), which implements these coding constructs. So, object-oriented can be taken to mean the many methodologies, detailed briefly herein, used to create and implement software.

4. CONCLUSION

For a particular software the first task is to choose which technique is most appropriate because of its development. Sometimes we might have to modify different methodologies. Some recommendations might be that simple duties may be better attained by structured coding methods as the use of object-oriented methods might be better fitted to higher degrees of abstraction. This may also assist with module design and problem decomposition. For situations where the data is more likely to improve than its efficiency, objects would be more appropriate.

In order for companies to move from the SSAD methodology to the OOAD technique, they need to understand the product of the change and the obstacles that must definitely be overcome; in any other case moving to the new methodology may end in failure. Therefore, for analysts and programmers to embrace this new technique, they need to reorient their thinking from the efficient perspective to the object perspective. More specifically for analysts and developers with experience in the traditional technique, training should get to stress the modeling aspects of the methodology instead of learning the syntax and top features of an object-oriented language. The changeover from SSAD to OOAD can be produced easier by supervised training and the use of object-oriented tools.

Although the OOAD methodology provides benefits, it generally does not resolve all the problems associated with the traditional SSAD technique. You may still find some shortcomings and weaknesses that require to be resolved such as: the quantity of training needed, the time essential to learn the new methodology, and the amount of money to purchase it. According to Goblet (Glass, 2002) there is no warranty that the adoption of a fresh technology will bring about it being used effectively and efficiently. In addition, if the organization completely submerges itself in the new OOAD technique, there can be costly and damaging results. Consequently, to take advantage of all the positive benefits that the new technique offers, the business needs to create a carefully organized and gradual intro of the methodology to all the system developers.

Before any effort is made to use the OOAD methodology as mentioned recently, it is essential that the necessary education be provided to be able to make sure its success. The abilities, knowledge and connection with the systems analyst and developers who are indoctrinated in the original SSAD methodology can be enhanced by the new methods. Since changes to the basic structure of the OOAD technique are stressful to control, first tries to use this methodology should be applied and then small range and non critical applications. This can enable the organization to receive immediate feedback also to have period to make any necessary modifications in the use of the OOAD methodology. Consequently, the huge benefits and advantages gained from using the new OOAD methodology can be much higher and more rewarding for the business in the long term than using the original SSAD technique.

Also We Can Offer!

Other services that we offer

If you don’t see the necessary subject, paper type, or topic in our list of available services and examples, don’t worry! We have a number of other academic disciplines to suit the needs of anyone who visits this website looking for help.

How to ...

We made your life easier with putting together a big number of articles and guidelines on how to plan and write different types of assignments (Essay, Research Paper, Dissertation etc)