University Institute of Engineering Department of Computer Science & Engineering

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 19

University Institute of Engineering

DEPARTMENT OF COMPUTER SCIENCE


& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: CST-220

SOFTWARE DESIGN DISCOVER . LEARN . EMPOWER


Software Design
Course Outcome
CO Number Title Level
CO1 To have good understanding of Software Engineering concepts Remember
and design of and handling of software products.  
CO2 Defining the basic concepts and importance of Software Understand
project Management concepts like cost estimation, scheduling  
and reviewing progress. Will be covered in this
CO3
lecture
An ability to work in one or more significant application Understand
domains.
CO4 Work as an individual and as part of a multidisciplinary team to Understand
develop and deliver quality software 
CO5 Demonstrate an understanding of and apply current theories, Understand
models, and techniques that provide a basis for the software
lifecycle.

CO6 Demonstrate an ability to use the techniques and Understand


tools necessary for engineering practice.

2
Topics covered
• Design Concepts

• Analysis VS design

• Preliminary or high decision support

• Detailed design

• Characteristics of good software design

• Object oriented design approach

• Function oriented design

3
SOFTWARE DESIGN
• Software design deals with transforming the customer requirements, as described in the SRS document, into a form (a set
of documents) that is suitable for implementation in a programming language.

• A good software design is seldom arrived by using a single step procedure but rather through several iterations through a
series of steps.

• Design activities can be broadly classified into two important parts:


• Preliminary (or high-level) design and
• Detailed design.

4
DIFFERENCE BETWEEN ANALYSIS AND DESIGN

• The aim of analysis is to understand the problem with a view to eliminate any deficiencies in the requirement
specification such as incompleteness, inconsistencies, etc.

• The model which we are trying to build may be or may not be ready.

• The aim of design is to produce a model that will provide a seamless transition to the coding phase, i.e. once the
requirements are analyzed and found to be satisfactory, a design model is created which can be easily implemented.

5
PRELIMINARY OR HIGH LEVEL DESIGN
• High-level design means identification of different modules and the control relationships among them and the definition
of the interfaces among these modules.

• The outcome of high-level design is called the program structure or software architecture.

• Many different types of notations have been used to represent a high-level design.

• A popular way is to use a tree-like diagram called the structure chart to represent the control hierarchy in a high-level
design.

6
DETAILED DESIGN
• During detailed design, the data structure and the algorithms of the different modules are designed.

• The outcome of the detailed design stage is usually known as the module-specification document.

7
Items developed during the software design
• For a design to be easily implemented in a conventional programming language, the following items must be designed during the
design phase.

• Different modules required to implement the design solution.

• Control relationship among the identified modules. The relationship is also known as the call relationship or invocation
relationship among modules.

• Interface among different modules. The interface among different modules identifies the exact data items exchanged among
the modules.

• Data structures of the individual modules.

• Algorithms required to implement each individual module.

8
CHARACTERISTICS OF GOOD SOFTWARE DESIGN

• 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.

9
SRS DOCUMENT
• The SRS document is known as black-box specification:
• The system is considered as a black box whose internal details are not known.
• Only its visible external (i.e. input/output) behaviour is documented.
• SRS document concentrates on:
• What needs to be done
• Carefully avoids the solution (“how to do”) aspects.
• The SRS document serves as a contract
• Between development team and the customer.
• Should be carefully written

10
FEATURES OF A DESIGN DOCUMENT
• In order to facilitate understandability, the design should have the following features:

• It should use consistent and meaningful names for various design components.

• The design should be modular. The term modularity means that it should use a cleanly decomposed set of
modules.

• It should neatly arrange the modules in a hierarchy, e.g. in a tree-like diagram.

11
APPROACHES TO SOFTWARE DESIGN
• There are two main approaches to software analysis and design:

1) Function-Oriented Approach

2) Object-Oriented Approach. 

12
Function oriented approach
• The following are the salient features of a typical function-oriented design approach:
• 1. A system is viewed as something that performs a set of functions. Starting at this high-level view of the system, each
function is successively refined into more detailed functions.

2. The system state is centralized and shared among different functions, e.g. data such as member-records is available.

13
Object oriented approach
• In the object-oriented design approach, the system is viewed as collection of objects (i.e. entities).

• The state is decentralized among the objects and each object manages its own state information.

• For example, in a Library Automation Software, each library member may be a separate object with its own data and
functions to operate on these data.

• In fact, the functions defined for one object cannot refer or change data of other objects.

• Objects have their own internal data which define their state.

• Similar objects constitute a class. In other words, each object is a member of some class.

• Classes may inherit features from super class. Conceptually, objects communicate by message passing.

14
Function oriented VS object oriented design approach
• In OOD, state information is not represented in a centralized shared memory but is distributed among the objects of
the system.

• For example, while developing an employee pay-roll system, the employee data such as the names of the
employees, their code numbers, basic salaries, etc. are usually implemented as global data in a traditional
programming system; whereas in an object-oriented system these data are distributed among different employee
objects of the system.

• Objects communicate by message passing. Therefore, one object may discover the state information of another
object by interrogating it. Of course, somewhere or other the real-world functions must be implemented.

• In OOD, the functions are usually associated with specific real-world entities (objects); they directly access only part
of the system state information.

15
APPLICATIONS
• Managing clients requirements in industry.
• Generating software for noticing health activities with novel smart technologies.
• Content Management and to analyzing Fraud detection and Prevention
• Advertisements Targeting Platforms Managing content, posts, images and videos on social media platforms
• Analyzing customer data in real-time for improving business performance
• Public sector fields such as intelligence, defense, cyber security and scientific research

16
REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.

Text Books:
4. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and Hennessy, “Computer
Architecture” , Fifth Edition Morgaon Kauffman.
5. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.

Reference Website
6. https://www.geeksforgeeks.org/computer-organization-and-architecture-tutorials/

17
Assessment Pattern
• Element1(Assignment 1,2,3(Average)): 12 Marks
• Element2(Surprise Test): 9 Marks
• Element3(Tutorial/Optional): 9 Marks
• Element4(Quiz): 12 Marks
• MST1: 36 Marks
• MST2: 36 Marks
• Final Examination: 60 Marks

18
THANK YOU

Email: ParneetE6618@cumail.in

You might also like