Scribd
Upload
26 views

SE Unit-3

Software design transforms customer requirements into a software design document suitable for implementation. It includes conceptual design to describe the system to the customer without technical details, and technical design with implementation details like hardware, software needs, and network architecture. Good design is correct, understandable, efficient, and maintainable. The design process includes architectural design to decompose software into components, and detailed design describing component behavior. Key principles are abstraction, encapsulation, coupling/cohesion, and complexity measures. Top-down and bottom-up are common approaches, while hybrid approaches leverage reusable components.

Uploaded by

2022aspire37
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
26 views

SE Unit-3

Software design transforms customer requirements into a software design document suitable for implementation. It includes conceptual design to describe the system to the customer without technical details, and technical design with implementation details like hardware, software needs, and network architecture. Good design is correct, understandable, efficient, and maintainable. The design process includes architectural design to decompose software into components, and detailed design describing component behavior. Key principles are abstraction, encapsulation, coupling/cohesion, and complexity measures. Top-down and bottom-up are common approaches, while hybrid approaches leverage reusable components.

Uploaded by

2022aspire37
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 10

Unit-3

Software Design
Software Design
• Software design deals with transforming the customer requirements, as described in the SRS document, into a
form (a set of documents) called software design document that is suitable for implementation in a
programming language.
Difference between Conceptual and Technical design

• Conceptual design describes the system in language understandable to the customer.


it does not contain any technical jargon and is independent of implementation
• By contrast the technical design describes the hardware configuration, software
needs, communication interface, input and output of the system, and network architecture that translates the
requirement into the solution to the customer's problem
Characteristics and objectives of a good software design
Good design is the key of successful product.
• Correctness: A good design should correctly implement all the
functionalities
• identified in the SRS document.
• Understandability: A good design is easily understandable.
• Efficiency: It should be efficient.
• Maintainability: It should be easily amenable to change.
Software Design process
• Architectural Design (Top Level design):- Describe how software is decomposed
and organized into components.
• Detailed Design (Low-level design):-Describe the specific behavior of these
components. The output of this process is a set of models that records the major
decision that has been taken.
Software Design Principle
• Abstraction
• It is a tool that permits a designer to consider a component at an abstract level; without
• worrying about the details of the implementation of the component.
• Encapsulation/Information hiding
• the concept of information hiding is to hide the implementation details of shared
• information and processing items by specifying modules called information hiding
• modules. Design decisions that are likely to change in the future should be identified and
• modules should be designed in such a way that those design decisions are hidden from
• other modules
• Coupling and cohesion
• Cohesion
• It is a measure of the degree to which the elements of a module are functionally related.
• Cohesion is weak if elements are bundled simply because they perform similar or related
• functions. Cohesion is weak if elements are bundled simply because they perform similar
• or related functions. Cohesion is strong if all parts are needed for the functioning of other
• parts (eg…The important design objective is to maximize module cohesion and minimize module
• coupling.
Software Design Principle
• Design Complexity
• Complexity is another design criterion used in the process of decomposition and refinement.
• A module should be simple enough to be regarded as a single unit for purposes of
• verification and modification
• a measure of complexity for a given module is proportional to the number of other
• modules calling this module (termed as fan-in), and the number of modules called by the
• given module (termed as fan-out).
Software Design Principle
• Top-down approach (is also known as step-wise design) is essentially the breaking down
• of a system to gain insight into its compositional sub-systems. In a top-down approach an
• overview of the system is formulated, specifying but not detailing any first-level
• subsystems. Each subsystem is then refined in yet greater detail, sometimes in many
• additional subsystem levels, until the entire specification is reduced to base elements. A
• top-down model is often specified with the assistance of "black boxes", these make it
• easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms
• or be detailed enough to realistically validate the model.
Software Design Principle
• Bottom-up approach is the piecing together of systems to give rise to grander systems,
• thus making the original systems sub-systems of the emergent system. In a bottom-up
• approach the individual base elements of the system are first specified in great detail.
• These elements are then linked together to form larger subsystems, which then in turn are
• linked, sometimes in many levels, until a complete top-level system is formed. This
• strategy often resembles a "seed" model, whereby the beginnings are small but eventually
• grow in complexity and completeness. However, "organic strategies" may result in a tangle
• of elements and subsystems, developed in isolation and subject to local optimization as
• opposed to meeting a global purpose. Mechanisms or be detailed enough to realistically
SOFTWARE DESIGN PRINCIPLE
• HYBRID DESIGN
• Hybrid approaches have become popular after the acceptance of the
reusability of modules. Standard libraries, Microsoft foundation
classes object-oriented concepts are steps in that direction.

You might also like