News:

GinGly.com - Used by 85,000 Members - SMS Backed up 7,35,000 - Contacts Stored  28,850 !!

Main Menu

Analysis and Design

Started by sukishan, Jul 12, 2009, 06:07 PM

Previous topic - Next topic

sukishan

Earlier Analysis and Design
As programs got more complex, programmers realized that there might be a better way to write programs than getting a problem statement and sitting down and writing code. In other words, a little abstract planning might help. Along these lines, some abstract modeling techniques were developed. Earlier methods included flowcharts and functional specifications, functional decomposition. Later techniques involved:

data flow diagrams (functionality)
data dictionaries (functionality)
Decision trees
process specifications (structured English)
entity relationship diagrams (data -- Information modeling)
The later techniques arose from the structured programming languages, and became used in structured analysis and design. The intention of the models was to create extra levels of abstraction between the real-world problem/system and the computer implementation of the system. They served as a bridge between the real world situation, and the computer code. The problem was mapped into a verbal problem statement, and then into a requirements analysis model, which was far removed from the machine implementation. The analysis model was then mapped into a design model, which was one step closer to the machine implementation (the code). Finally, code was written from the design model. However, these earlier abstract models all ran on one premise -- there is data, and there are functions that process the data. The first models attempted only to model the functionality of the real-world systems. Later, entity relationship diagrams were added -- these modeled the data, or the static nature of the system. However, the functionality models and the data models were distinct and separate entities.

Object-oriented

In object-oriented programming programmers define not only the data type of a data structure, but also the types of operations (functions) that can be applied to the data structure. In this way, the data structure becomes an object that includes both data and functions. In addition, programmers can create relationships between one object and another. For example, objects can inherit characteristics from other objects. Objects and object interactions are the basic elements of design.

One of the principal advantages of object-oriented programming techniques over imperative programming techniques is that they enable programmers to create modules that do not need to be changed when a new type of object is added. A programmer can simply create a new object that inherits many of its features from existing objects. This makes object-oriented programs easier to modify.

The advantages of object-oriented programming do not evidence themselves when you are writing a single function for a particular purpose. Instead, the advantages arise when you are designing a large system that will do similar , but not identical, things to a variety of data objects. By specifying classes of data objects for which identical effects will occur, you can define a single generic function that embraces the similarities across object types, but permits individual implementations or methods for each defined class. As an example of languages that implements object paradigm are Smalltalk, Delphi and Java.
A good beginning makes a good ending