Смекни!
smekni.com

Software Developing Techniques Essay Research Paper Computer (стр. 1 из 2)

Software Developing Techniques Essay, Research Paper

Computer system consists of two major components.

1. Hardware

2. Software

Hardware is the name given to physical machines whereas software is the set of logical instructions that direct the hardware to achieve a particular task. Both the components are dependent on each other. One is useless in the absence of other. Vendors usually design the Hardware and conceptually it fairly matches with the Hardware of other vendors. on the other hand software designs, most of the time, are custom design and various methodology are adopted in its design. In the ongoing paragraphs the process of software design has been discussed.

GENERAL SOFTWARE DESIGN PROCESS

A general model of a software deign is a directed graph. Nodes in this graph represent enmities in the design, such as processes, functions or types, and links represent relation between these design entities. The target of the design process is the creation of such a graph without inconsistencies and where all of the relationships between design entities are legal.

Software designers do not arrive at a finished design graph immediately. The design process involves adding formality as design progresses, with constant backtracking to correct earlier, less formal, designs. The designer starts with a very informal picture of the design and refines it by adding information to make the design more formal.

-2-

The relationship between design and specification is a close one. Although the process of setting out a requirement specification as the basis of a contract is a separate activity, formalising that specification may be part of the design process. In practice, the designer iterates between specification and design.

The design process involves describing the system at a number of different levels of abstraction. As a design is decomposed, errors and omissions in earlier stages are discovered. These feed back to allow earlier design stages to be refined. It is common to begin the next stage before a stage is finished simply to get feedback from the refinement process. These stages are fairly arbitrary but make the design process visible and thus allow it to be managed.

A specification is the output of each activity. This specification may be an abstract, formal specification, which is produced to clarify the requirements, or it may be a specification of show part of the system is to be realised. As the design process continues, more and more detail is added to the specification. The ultimate outputs are specifications of algorithms and data structures, which are used as a basis for system implementation.

The design process activities go on in parallel with different design products developed to different levels of detail in the course of the design process. However, the activities shown below are all essential in the deign of large software systems:

1) Architectural design: The sub-systems making up the overall system and their relationships are identified and documented.

2) Abstract specification: For each sub-system, and abstract

specification of the services it provides and the constraints under which it must operate is produced.

-3-

3) Interface design: For each sub-system, its interface with other sub systems is designed and documented. This interface specification must be unambiguous as it allows the sub-system to be used without knowledge of the subsystem operation.

4) Component design: The services provided by a sub-system are partitioned across the components in that sub-system.

5) Data Structure design: The data structure used in the system implementation are designed in detail and specified.

6) Algorithm design: The algorithms used to provide services are designed in detail and specified.

This process is repeated for each sub-system until the components identified can be mapped directly into programming language components such as packages, procedures or functions.

A widely recommended approach to design is a top-down approach where the problem is recursively partitioned into sub-problems until tractable sub-problems are identified. The general form of the design, which usually emerges from such a design process, is approximately hierarchical. Cross-links in the graph emerge at lower levels of the design tree as designers identify possibilities for reuse.

In fact, it is unusual for large systems to be designed in manner, which is strictly top-down. Designers always use their previous design knowledge in the design process. They do not need to decompose all abstractions as they may be aware exactly how one part of the design can be built. They might therefore return to that part. Indeed, project planning may require difficult parts of the design to be tackled first so that management can make more informed estimates of the system development time.

-4-

Top-down design was proposed in conjunction with functional decomposition and it is a valid approach where design components are rightly coupled. However, when an object-oriented approach to design is adopted and many existing objects are available for reuse, top-down design so less useful. The designer uses existing objects as a design framework and builds the design out from them; there is no concept of a single ‘top’ or of all objects existing in a single object hierarchy.

Design methods

In many organisations, software design is still an ad hoc process. Given a set of requirements, usually in natural language, an informal design is prepared. Coding commences and the design is modified as the system is implemented. When the implementation stage is complete, the design has usually changed so much from its initial specification that the original design document is a totally inadequate description of the system.

A more methodical approach to software design is proposed by ’structured methods’ which are sets of notations and guidelines about how to create a software design. Structured methods have been applied successfully in many large projects. They can deliver significant cost reductions because they use standard notations and ensure that designs follow a standard form. The use of structured methods normally involves producing large amounts of diagrammatic design documentation.

-5-

Although there are a large number of methods, they have much in common and usually support some or all of the following views of a system:

1) A data flow view where the system is modelled using the data transformations, which take place as it, is processed.

2) An entity relation view, which is used to describe the logical data, structures being used.

3) A structural view where the system components and their interactions are documented.

Particular methods supplement these with other system models such as state transition diagrams, entity life histories, which show how each entity is transformed as it is processed, and so on. Most methods suggest that a centralised repository for system information ( a data dictionary) would be used but this is only really feasible with automated tool support. Because of the variety of methods and the fact that no one method is demonstrably superior to another.

A mathematical method (such as the method for long division) is a strategy which, if adopted, will always lead to the same result. The term ’structured methods’ suggests, therefore, that designers should normally generate similar designs for the same specification.

In practice, the guidance given by the methods is informal so this situation is unlikely. These ‘methods’ are really standard notations and embodiments of good practice. By following these methods and applying guidelines, a reasonable design should emerge but designer creativity is still required to decide on the system

-6-

decomposition and to ensure that the design adequately captures the system specification.

Design description

A software design is a model of real-world system, which has many participating entities and relationships. Different engineers use this design in different ways. It must act as a basis for detailed implementation, it serves as communication medium between the designers of sub-systems, it provides information to system maintainers about the original intentions of the system designers, and so on. This means that it must be possible to view a design at a number of different levels of abstraction.

There are three types of notation, which are widely used for design documentation:

1) Graphical notations: These are used to display the relationships between the Components making up the design and to relate the design to the real-world system it is modelling. A graphical view of a design is an abstract view and is most useful for giving an overall picture of the system.

2) Program description languages: These languages (PDLs) use control and structuring constructs based on programming language constructs but also allow explanatory text and (sometimes) additional types of statement to be used. These allow the intention of the designer to be expressed rather than the details of how the design is to be implemented.

3) Informal Text: Much of the information that is associated with a design cannot be expressed formally. Information about design

-7-

rationale or non-functional considerations must be expressed using natural language text.

Generally, all of these different notations would be used in describing a system design. The architecture and the logical data design should be described graphically supplemented by design rationale and further informal or formal descriptive text. The interface design, the detailed data structure design and the algorithm design are best described as a PDL.

Design strategies

Until relatively recently, most software was developed according to a design strategy which involved decomposing the design into functional components with system state information held in a shared data area. It is only since the mid-1980s that this alternative, object-oriented design, has been widely adopted.

These two design strategies may be summarised as follows:

1) Functional design: The system is designed from a functional viewpoint, starting with a high level view and progressively refining this into a more detailed design. The system state is centralised and shared between the functions operating on that state. Structured design and step-wise refinement exemplify this strategy. Methods such as Jackson structured programming and the Warnier-Orr method are techniques of functional decomposition where the structure of the data is used to determine the functional structure used to process that data.

2) Object-oriented design: The system is viewed as a collection of object rather than as functions. The system is decentralised and each object manages its own state information. Objects have a set

-8-

of attributes defining their state and operations, which act on these attributes. Objects are usually members of an object class whose

definition defines attributes and operations of class members. These may be inherited from one or more super-classes so that a

class definition need merely set out the differences between that class and its super-classes. Conceptually, objects communicate by exchanging messages; in practice, most object communication is achieved by an object calling a procedure associated with another object.

Top-down functional decomposition has been widely used for both small-scale and large-scale projects in diverse application areas. Object-oriented design is a more recent development, which encourages the production of system composed in independent, interacting components.

To illustrate the difference between functional and object-oriented approaches to software design, consider the structure of a compiler. It may be viewed as a set of functional transformations with information being passed from one function to another.

An alternative, object-oriented view of the structure of compiler would be the objects manipulated by the compiler are central with transformation functions associated with object communications.

Enthusiasts for particular design techniques sometimes suggest that their favourite technique is generally applicable and that other techniques should not be used. In fact, large software systems are such complex entities that different approaches might be used at some stage in the design of different parts of the system. There is no best design strategy for large projects. Functional and object-oriented approaches are complementary stages in the design process. The pragmatic software engineer selects the most appropriate approach for each stage in the design process.

-9-

TBC

To illustrate this, consider the software systems, which might be part of a modern civil aircraft. Some of these might be:

The navigation system.

The radar system.

The external communications system.

The engine control system.

Our natural high-level view of the overall software system is as a set of objects (sub-systems) rather than as a set of functions. Thus at abstract design levels, an object-oriented approach is appropriate.

When the system is examined in more detail, its natural description is as a set of interacting functions rather than objects. For example, some of these functions might be:

Display_Track (radar sub-system).

Compensate_for _Wind_Speed (navigation sub-system).

Reduce_Power (engine control sub-system).

Indicate_Emergency (instrument sub-system).

Lock_onto_Frequency (communications sub-system).

This functional view may be taken by the requirements definition. This can be converted to an object-oriented view but system validation may be difficult because there is not a simple correspondence between design components and requirements definitions. A single logical function in the requirements definition may be implemented as a sequence of object interactions.

As the system design is further decomposed, an object-oriented view may again become the natural way to view the system. At the detailed design stage, the objects manipulated might be

-10-

The_engine_status, The aircraft_position, The_antimeter, The_radio_beacon, and so on. Thus an object-oriented approach to the lower levels of the system deign is likely to be effective.

In summary, an object-oriented approach to software design seems to be the most natural at the highest and lowest levels of system design. At these levels, an object-oriented approach leads to the production of independent components which are usually more maintainable than functional components.

TBCEND

Concurrent systems design

Many software systems, particularly embedded real-time systems, are structured as a set of parallel communicating processes. Indeed, it is sometimes suggested that this structure of parallel processes is a natural and necessary approach for real-time systems construction. Both object-oriented and function-oriented designs can be realised as sequential or concurrent programs. Indeed, structuring the design as a set of co-operating processes where each process maintains its own state is a half-way house between these two approaches to design. If no shared memory is used for process communication, the processes hide information in the same way as objects.

Embedded systems must often perform to strict time constraints and, where hardware is relatively slow, only a multiple process/multiple processor approach may be able to provide the necessary performance. However, with fast processors, it may not be necessary to implement embedded systems as parallel processes. A sequential system, which uses polling to interrogate and control hardware components, may provide adequate performance.

-11-

The advantage of avoiding a parallel systems design is that sequential programs are easier to design, implement, verify and test that parallel systems design is that sequential programs are easier to design implement, verify and test than parallel systems. Time dependencies between processes are hard to formalise, control and verify.

The deign process should therefore be considered as a two-stage

activity:

1) Identify the logical design structure, namely the component of a system and their interrelationships. Either a functional or an object-oriented view may be used.

2) Realise this structure in a form which can be executed This latter stage is sometimes considered detailed design and sometimes programming. Decisions on parallelism should be made at this stage rather than preconceived at earlier stages in the design process.

Design quality

There is no definitive way of establishing what is meant by a good design. Depending on the application and project requirements, a good design might be a design, which allows efficient code to be produced; it might be a minimal design where the implementation is as compact as possible; or it might be the most maintainable design.

This latter criterion is the criterion of goodness used here. A maintainable design can be readily adapted to modify existing functionality and add new functionality. The design should therefore be understandable and changes should be local in effect. The components of the design should be cohesive, which means

-12-

that all parts of the component should have a close logical relationship. They should be loosely coupled. Coupling is a

measure of the independence of components. The looser the coupling, the easier it is to adapt the design.