University Institute of Engineering Department of Computer Science & Engineering
University Institute of Engineering Department of Computer Science & Engineering
University Institute of Engineering Department of Computer Science & Engineering
2
Topics covered
• Design Concepts
• Analysis VS design
• Detailed 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.
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.
• 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.
8
CHARACTERISTICS OF GOOD SOFTWARE DESIGN
• Correctness: A good design should correctly implement all the functionalities identified in the SRS document.
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.
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