7.

b)Context Diagram
The top-level diagram is often called a context diagram. It contains a single process, but it plays a very important role in studying the current system. The context diagram defines the system that will be studied in the sense that it determines the boundaries. Anything that is not inside the process identified in the context diagram will not be part of the system study.

Data Flow Diagram (0 and 1 level) A graphical tool used to describe and analyze the moment of data tOBSough a system manual or automated including the process, stores of data, and delays in the system. Data Flow Diagrams are the central tool and the basis from which other components are developed. The transformation of data from input to output, tOBSough processes, may be described logically and independently of the physical components associated with the system. The DFD is also known as a data flow graph or a bubble chart. A graphical tool used to describe and analyze the moment of data through a system manual or automated including the process, stores of data, and delays in the system. Data Flow Diagrams are the central tool and the basis from which other components are developed. The transformation of data from input to output, through processes, may be described logically and independently of the physical components associated with the system. The DFD is also known as a data flow graph or a bubble chart. TYPES OF DATA FLOW DIAGRAMS: Data Flow Diagrams are of two types as follows: (a) Physical DFD (b) Logical DFD 1. PHYSICAL DFD: Structured analysis states that the current system should be first understand correctly. The physical DFD is the model of the current system and is used to ensure that the current system has been clearly understood. Physical DFDs shows actual devices, departments, and people etc., involved in the current system. 2. LOGICAL DFD: Logical DFDs are the model of the proposed system. They clearly should show the requirements on which the new system should be built. Later during design activity this is taken as the basis for drawing the systems structure charts. Data Flow Diagram(Level-0):-

2.a)Software design models

Software design problems and solutions are often complex and many aspects of software systems must be modeled. There are many kinds of modeling notations used in software designing. Types of software design models Static models: These models represent aspects of software systems that do not change during execution. Generally these models represent software components, their characteristics, and unvarying relationships between software components. Examples of static models are object and class diagrams, use case diagrams, data structure diagrams, operation specifications, and implementation diagrams. Dynamic Models: These models show what happens during software execution. Examples of dynamic models are interaction diagrams, state charts, data flow diagrams, decision trees and tables, and mini-specs. The difficulties involved in creating software-based systems have long been recognized. While apparently-related technology such as hardware design and production has raced along gaining orders of magnitude in performance, and similarly reducing price and size, software development techniques seem to have inched along in a series of relatively small steps. Brooks cites the following properties of software as major factors affecting its development. Complexity. This is seen as being an essential property of software, in which no two parts are alike and a system may possess very many states during execution. This complexity is also arbitrary, being dependent upon the designer rather than the problem. Conformity. Software, being pliable, is expected to conform to the standards imposed by other components, such as hardware, or by external bodies, or by existing software. Changeability. Software suffers constant need for change, partly because of the apparent ease of making changes (and relatively poor techniques for costing them). Invisibility. Because software is invisible, any forms of representation that are used to describe it will lack any form of visual link that can provide an easily grasped relationship between the representation and the system unlike, for example, a building plan which can be easily linked to the visible features of the building. This not only constrains our ability to conceptualize the characteristics of software, it also hinders communication among those involved with its development. Constructing a model for a proposed solution allows the designer to explore the potential limitations of the solution as well as to assess its behavior and structure. Designer compared with the models that are needed to assist with the process of software design. In this section we will try to identify some of the main features and characteristics of the models that are used in software design.
Requirement Specifications

The input to this process is provided by the Requirements Specification documents, while the outputs produced from it should consist of a set of detailed specifications that describe the form of the eventual program components.
Requirement Specification

Architectura l design decision

Logical design details

Detail design decision

Physical design details

The major phases of the software design process In practice, and especially when developing larger systems, the process of design is apt to be divided into two distinct phases 1. In the first phase, the designer develops a highly abstract model of a solution (the architectural or logical design) in which only the external properties of the model elements are included. This initial black-box partitioning of the problem is therefore largely concerned with the nature and form of the problem itself, and less strongly influenced by the eventual form that will be adopted for its solution. 2. In the second phase, the abstract chunks of the problem that were identified in the first phase are mapped on to technologically-based units (the detailed or physical design), hence turning the black box into a white box. Where design and implementation are separate responsibilities, it is the output from this phase that provides the specifications for the programmers.

Constraints

Design Process

Designer decision

Program Description

( A general model of the software design process. )

2.b) Concept of Design

Design is a meaningful representation of something that is to be built. It can be traced to a customers requirements and at the same time assessed for quality against a set of predefined criteria for good design. Software design is more creative process than analysis because it deals with the development of the actual mechanics for a new workable system. Definitions of software design are as diverse as design methods. Some important software design definitions are According to Coad and Yourdon Software Design is the practice of taking a specification of externally observable behavior and adding details needed for actual computer system implementation, including human interaction, task management, and data management details. According to Stevens Software Design is the process of inventing and selecting programs that meet the objectives for the software system. Objectives of Software Design Correctness : Good design should correctly implement the requirements of the system. The design should implement correctly both, that is all of the explicit requirements contained in the analysis model and all of the implicit requirements desired by the customer. Understandability : The design should be readable, simple, understandable guide for those who generate code and for those who test and subsequently support the software. Modularity : It is fundamental attribute to good design. It aims for decomposition of a problem into modules, which results in reduction of complexity of the design solutions. Completeness: Good design requires that all the different components of the design should be specified. Efficiency: Good design should be efficient, that is it should be properly use the scarce resources of the system. Consistency : Design should follow consistency thorugh the system. Verifiability: Design should be correct and it should be verified foe correctness. Traceability : Design should be traceable. Traceable design aid design verification. The role of the design activity As we saw in the previous section, the principal task for the designer is to specify the best solution to a problem and produce a description of how this is to be organized. This description then forms a plan that can be used by the eventual implementors of the system. Just when this concept of the design task having a distinct role in the production of an artifact first began to emerge is likely to remain largely a matter for conjecture. It is unlikely that any of the major creations of ancient times, such as the pyramids, could have been achieved without a significant degree of design planning, and so it seems reasonable to identify architecture in its broadest sense as the most probable domain where this separation from the craft-level entwining of design and construction is likely to have begun. The recognition of design as a distinct and identifiable task then introduces the question of how is a designer to learn their trade? For many centuries this was probably achieved primarily through some form of apprenticeship, whether formal or otherwise, and today there is still a strong element of this in many creative disciplines. Indeed, the concept of the design studio is considered by some to be a very valuable and effective route for teaching about software design too (Tomayko, 1996). We might also note that great engineering designers have also maintained sketchbooks (Leonardo da Vinci) or the engineers commonplace book (Isambard Kingdom Brunel) both to aid their own thinking and to provide a form of pattern book for conveying these ideas to others. The designers of pyramids and cathedrals will almost certainly have exchanged ideas with, and learned from, their peers. However, each of the resulting artifacts was a single unique creation, and only with the emergence of engineering practices were there significant new inputs to the designers learning processes. Two of these are worth noting here, not least because of their longer-term implications for software design. 1. The first of these was the knowledge gained from scientific research. As the properties of materials became better understood, and the means of predicting their behaviour became more refined and dependable, so the designer could employ this knowledge in helping to create new structures. A good example is that of bridge building in the nineteenth century, when engineers such as I K Brunel were able to create structures that were radically different from their predecessors, while also proving to be remarkably durable. 2. The second was the concept of reuse. One consequence of the industrial revolution was the idea of standardizing components.* The existence of such components extends a designers repertoire on the one hand offering speedier development of an idea (improved time-to-market) with potentially lower costs, but also introducing new constraints and trade-offs into the design process.