Software design - Lecture 6. The main topics covered in this chapter include: software design components; traditional approach, programmers approach, system architect approach; decomposition rules; layers rule;...
1 Software Design Lecture : 6 Software Design Components Ø Principle Ø Criteria Ø Techniques Myth about Abstraction Problem Statement ü Our task is to design an management information system for a hospital, it should include patient management , management, laboratory doctors management inventory of equipment and medicines, , Traditional Approach ü Programmers Approach: Ø ‘Which Technology to use for implementation ‘ ü System Architect Approach ü Abstraction What to Do not How to do !! ü A view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information IEEE Standard 610.121990 ü Abstraction is generally used for handling and reducing complexity Abstraction continue ü Abstraction is simply removal of unnecessary details ü To design a complex system, you must identify what about that part other parts should know in order to design their part Benefits of Abstraction ü Gives the designer freedom to ignore certain details, for the time being, and to determine or design the "big picture" aspects of his design Decomposition ü Splitting one system into smaller components ü Designing the components independently ü For the outside world the components are reduced to their interfaces ü “Divide and Conquer” 10 Decomposition Rules ü Don't design components to correspond to execution steps – look for similar tasks – No Runtime binding ü Decompose so that all design decision have a 11 Decomposition continues ü Components should be specified by all information needed to use the component – nothing less and nothing more! 12 Subsystems A Subsystem is a secondary or subordinate system within a system IEEE Standard 610.121990 13 Subsystems Ø A subsystem is a functionally cohesive grouping of classes that is a major part of a larger aggregate system Ø Can be independently ordered, configured or delivered Ø Subsystems are related to each other via dependency relations, and communicate with each other via well defined interfaces 14 Subsystems Ø Decompose by functional services ie Database Subsystem, User Interface Subsystem etc 15 16 Subsystem Example Student Management Hrm and Payroll Accounts Library Management 17 Layers ü Decomposition of the system into smaller, more manageable units, that are layered hierarchically Ø Each layer supplies one level of abstraction Ø A layer only uses services of the next underlying layer ü Layers can be tested independently 18 19 20 Layers Rule ü ü Layer can request for services from exactly one layer below it Layer can respond to a request of a layer exactly one layer above it ü Total Layers = N = 3 ü Request = N1 ü Response = N+ 1 21 Layer Rule High Level Architectural Diagram Services Layers Request Operations Layers Response Student Data Management ...2 Software? ?Design Components Ø Principle Ø Criteria Ø Techniques Myth about Abstraction Problem Statement... information relevant to a particular purpose and ignores the remainder of the information IEEE Standard? ?61 0.121990 ü Abstraction is generally used for handling and reducing complexity Abstraction continue... 12 Subsystems A Subsystem is a secondary or subordinate system within a system IEEE Standard? ?61 0.121990 13 Subsystems Ø A subsystem is a functionally cohesive grouping of classes that is a major part of a larger aggregate system