find and solve || findandsolve.com
Please wait.....

Software Engineering | Software Design Process

Software Engineering | Software Design Process

In Software Engineering software design is a process to transform user requirements into some suitable form that helps the programmer in software coding and implementation. This is the process by which an agent creates a specification of a software artifact intended to accomplish goals.

Any design problem must be tackled in three stages:

(1) Study and understand the problem understanding effective software design is impossible. The problem should be examined from several different angles or viewpoints as these provide different insights into the design requirements.

(2) Identify gross features of at least one possible solution. It is often useful to identify several solutions and evaluate them all. The choice of solution depends on the designer's experience, the availability of reusable components, and the simplicity of the derived solutions. Designers usually prefer familiar solutions even if these are not optimal, as they understand their advantages and disadvantages.

(3) Describe each abstraction used in the solution. Before creating formal documentation, the designer may write an informal design description. This may be analyzed by developing it in detail. Errors and omissions in the high-level design will probably be discovered during this analysis. These are corrected before the design is documented.


The design process


A gene L model ot..a.software-design is a directed graph. The target of the design process is the creation of such a graph without inconsistencies. Nodes in this graph represent entities in the design entities such as process functions or types. The link represents the relation between these design entities such as calls, uses, and so on. Software designers do not arrive at a finished design graph immediately but develop the design iteratively through several different versions. The design process involves adding formality and detail as the design is developed with constant backtracking to correct earlier, less formal, designs. The starting point is an informal design, which is refined by adding information to make it consistent and complete as shown in the figure below.




The given above figure shows a general model of the design process and suggests that the stages of the design process are sequential. Design process activities proceed in parallel. However, the activities shown are all part of the design process for large software systems. These design activities are:

  • Architectural designs of the sub-systems making up the system and their relationships are identified and documented.
  •  Abstract specification for each sub-system, an abstract specification of the services it provides and the constraints under which it must operate is produced.
  • 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 sub-system operation.
  •  Component design Services are allocated to different components and the interfaces of these components are designed.
  • Data structure designs the data structures used in the system implementation are designed in detail and specified.
  •   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 languages components sta such as packages, procedures, or functions


Design Methods


A more methodical approach to software design is purposed by structured methods, which are sets of notations and guidelines for software design. Budgen (1993) describes some of the most commonly used methods such as structured design, structured systems analysis, Jackson System Development, and various approaches to object-oriented design.

The use of structured methods involves producing large amounts of diagrammatic design documentation. CASE tools have been developed to support particular methods. Structured methods have been plied successfully in many large projects. They can deliver significant cost reductions because they use standard notations and ensure that standard design documentation is produced.

A mathematical method (such as the method for long division) is a strategy that will always lead to the same result irrespective of who applies the method. The term 'structured methods' suggests, therefore, that designers should normally generate similar designs from the same specification. structured method-incl s a set of activity stations, report format rules, and design guidelines. So structured methods often support some of the following modules of a system.


  • A data-flow model where the system is modeled using the data transformations, which take place as it, is processed.
  • An entity-relation model, which is used to describe the logical data structures being used.
  •  A structural model where the system components and their interactions are documented.

If the method is object-oriented it will include an inheritance model of the system, a model of how objects are composed of other objects, and, usually, an object-use model Which shows. how objects are used by other objects. 

Particular methods supplement these with other system models such as state transition diagrams, entity life histories that show how each entity is transformed as it is processed, and so on. Most methods suggest a centralized repository for system information or a data dictionary should be used. No one method is better or worse than other methods the success or otherwise of methods often depends on·their suitability for an application domain.


Design description


A software design is a model system that has many participating entities and relationships, This design is used in several different ways. It acts as a basis for detailed implementation; it serves as a 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.

Designs are documented in a set of design documents that describes the design for programmers and other designers. There are three main types of notation used in design documents 


  • Graphical notations: These are used to display the relationships between the components making up the design and to relate the d sign to the real-world system modeling. A graphical view of a design is an abstract view. It is most useful for giving an overall picture of the system.
  • 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 statements 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.
  •  Informal text much of the information that is associated with a design cannot be expressed formally. Information about design rationale or non-functional considerations may be expressed using natural language text.

ll of these different notations may be used in describing a system design.


Design strategies


The most commonly used software design strategy involved decomposing the design into functional components with system state information held in a shared data area. Since the late 1980s that this alternative, object-oriented design has been widely adopted.

Two design strategies are summarized as follows:

  • 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 centralized and shared between the functions operating in that state. Methods such as Jackson Structured Programming and the Warnier Orr method are techniques of functional decomposition where the structure of the_da!a is used to determine the functional structure used to process that date.
  • Object-oriented design: The system is viewed as a collection of objects rather than as functions. Object-oriented design is based on the idea of information hiding and has been described by Meyer; Booch. and Jacobsen. and many others. JSD is a design method that falls somewhere between function-oriented and object-oriented design.


In an object-oriented design, the System State is decentralized and each object manages its state information. Objects have a set of attributes defining their state and operations, which act on these attributes. Objects are usually members of an object class whose definition defines the attributes and operations of class members. These may be inherited from one or more super-classes so that a class definition need only set out the differences between that class and its super-classes. Objects are communicated by exchanging messages; an object calling a procedure associated with another object achieves most object communication.


There is no 'best' design strategy, which is suitable for all projects and all types of applications. Functional and object-oriented approaches are complementary rather than opposing techniques. Software engineers select the most appropriate approach for each stage in the design process. Large software systems are complex entities that different approaches might be used in the design of different parts of the system.


An object-oriented approach to software design seems to be natural at the highest. and lowest levels of system design. Using different approaches to design may require the designer to convert his or her design from one model to another. Many designers are not trained in multiple approaches so prefer to use either object-oriented or functional design.


Design quality


A good design might be a design that 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.


 A maintainable design can be adapted to modify existing functions and add new functions. The design must therefore be understandable and changes should be local in effect. The design components should be cohesive which means that all parts of the component should have a close logical relationship. They should be loosely coupled which means that they should not be tightly integrated Coupling is a measure of the independence of components. The looser the coupling, the easier it is to adapt the design as the effects of change are localized.


Quality characteristics are equally applicable to object-oriented and function­ oriented design. Because of the nature of object-oriented design, which encourages the development of independent components, it is usually easier to achieve maintainable designs as information is concealed within objects.

Mahira  khanna

Mahira khanna

I have the skills you need for you company blog, website, or other content materials

If findandsolve.com felt valuable to you, feel free to share it.

Comments



Report Response