Log In | Register
The Second article on IT for general use.
Please use this information honestly if you are on a college course. I sweated over it so you should too.
Please don't Copy and Paste for your assignment!
Ed
The different methodologies in system design have evolved in line with the different system architectures. The most common method employed in designing a new system is the Top Down method.
The Top Down Method is a method of designing something that starts with the complete item then breaks it down into smaller and smaller components
This method breaks the required system down into manageable sections. These sections are then broken down further into smaller more easily managed sections. Once the system has been taken apart to this degree then the relationships between actions taking place within the system can be determined and so more easily managed. The system can then be built up in a logical sequence which lends itself to reasonably efficient flawed/inefficient process trapping.
In programming it means breaking something down until the smallest component could be translated into a programming statement.
If you're using packages, it is broken down until the smallest component is one instruction, e.g. Print the Document.
A programming statement could be a short section of code which achieves a specific aim within the scope of the program, such as opening a new dialogue box to begin a new process.
A package could be a pre designed module or class which is used by the program. I.E. a bundled set of instructions which is inserted into the program as an 'object'.
These objects are governed by convention in most cases.
Bottom up Modelling
This method is useful for the re-design/ rebuild of an existing system. It usually entails trawling through existing systems and documents to find potential data required for a system.
This can then be normalised.
Bottom up modelling then, is the process of taking the system and looking at the smallest pieces of data within it and looking at how it was put together. Stripping out all relationships within the system allows the developer to then use other methodologies to rebuild a new system or to improve/update the existing system.
It appears to me that this system would be truly effective only in reasonably small systems, as more complex systems would generate more and more problem areas which would have a spiralling effect on work already carried out within the project.
On a very large and complicated system, this could lead to multiple errors being generated and so result in serious over budget costs being incurred.
SSADM
(Structured Systems Analysis and Design Methodology)
SSADM (in common with other structured methodologies) adopts a prescriptive approach to information systems development in that it specifies in advance the modules, stages and tasks which have to be carried out, the deliverables to be produced and furthermore the techniques used to produce the deliverables. SSADM adopts the Waterfall model of systems development, where each phase has to be completed and signed off before subsequent phases can begin.
SSADM revolves around the use of three key techniques, namely:
•Logical Data Modelling
•Data Flow Modelling
•Entity/Event Modelling.
Logical Data Modelling;
This is the process of identifying, modelling and documenting the data requirements of a business information system. A Logical Data Model consists of a Logical Data Structure (LDS - The SSADM terminology for an Entity-Relationship Model) and the associated documentation. LDS s represent Entities (things about which a business needs to record information) and Relationships (necessary associations between entities).
[Reference: University of Glamorgan Degree course research notes]
Data Flow Modelling;
This is the process of identifying, modelling and documenting how data flows around a business information system. A Data Flow Model consists of a set of integrated Data Flow Diagrams supported by appropriate documentation. DFDs represent processes (activities which transform data from one form to another), data stores (holding areas for data), external entities (things which send data into a system or receive data from a system and finally data flows (routes by which data can flow).
[Reference: University of Glamorgan Degree course research notes]
Entity Event Modelling;
This is the process of identifying, modelling and documenting the business events which affect each entity and the sequence in which these events occur.
An Entity/Event Model consists of a set of Entity Life Histories (one for each entity) and appropriate supporting documentation
[Reference: University of Glamorgan Degree course research notes]
This approach to system design has been developed over the years on a kind of trial and error basis. Large commercial entities discovered that the early practice of getting systems designed for purely 'in house' systems did not address the rapidly evolving communications revolution which was taking place outside their own sphere of operations.
Clearly a 'Structured System of Design was required. The SSADM method, as it developed, addressed some of these issues by setting out agreed conventions in working practices and method used by the system designers. Along with this development in system design, came the increasing use of Case Tools
Case Tools
The proliferation of case tools within the area of systems design helped to unify the nuts and bolts level of the design process.
CASE tools offer many benefits for developers building large-scale systems. As spiralling user requirements continue to drive system complexity to new levels, the CASE tools enable us to abstract away from the entanglement of source code, to a level where architecture and design become more apparent and easier to understand and modify. The larger a project, the more important it is to use CASE technology. As developers interact with portions of a system designed by their colleagues, they must quickly seek a subset of classes and methods and assimilate an understanding of how to interface with them. In a similar sense, management must be able, in a timely fashion and from a high level, to look at a representation of a design and understand what's going on. For these reasons, CASE tools coupled with methodologies give us a way of representing systems too complex to comprehend in their underlying source code or schema-based form
[Reference: Fred Hebbel principal consultant for Sysnetics in St. Petersburg, Florida]
Case tools can be pre-designed modules of code or recognised diagrams with are universally agreed upon to represent a real world action or a process within an application. A case tool could also be a complete application.
In recent years the proliferation of case tools has meant that most system designers use these tools for many aspects of the system design.
Data flow diagrams and ERD's though case tools in their own right, use case tools embedded within the application used to produce them. (They show a visual representation of a complicated system or an internal component of a system.)
Object-oriented CASE tools create diagrams that represent an object model using the notational elements of specific methodologies. These notations depict classes (including attributes, methods, and events), various object relationships (such as inheritance, aggregation, and friendship), and cardinality. In addition, most if not all of the tools available offer the ability to generate skeletal application code from models. This skeletal code typically includes class definitions and function prototypes.
Developers then add meaningful underlying application logic using C++, Java, or Smalltalk, to name just a few supported languages.
[Reference: Fred Hebbel principal consultant for Sysnetics in St. Petersburg, Florida]
More to come.
