




















Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
An in-depth exploration of software design, focusing on the stages and processes involved in deriving a solution that satisfies software requirements. Topics include problem understanding, design phases, and modular design methods. Five criteria for evaluating modular design methods are discussed: modular decomposability, modular composability, modular understandability, modular continuity, and modular protection.
Typology: Slides
1 / 28
This page cannot be seen from the preview
Don't miss anything!





















Problem understanding Look at the problem from different angles to discover the design requirements. Identify one or more solutions Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources. Describe solution abstractions Use graphical, formal or other descriptive notations to describe the components of the design. Repeat process for each identified abstraction until the design is expressed in primitive terms.
Architectu ral design Abstract specificatio n Interface design C ompon ent design Data stru ctu re design Alg orithm design Sy stem architectu re So ftware specificatio n Interface specificatio n C ompon ent specificatio n Data stru ctu re specificatio n Alg orithm specificatio n Requ irements specificatio n Desig n activities Desig n prod ucts
In the early days, modular programming was taken to mean constructing programs out of small pieces: “subroutines” But modularity cannot bring benefits unless the modules are autonomous, coherent and robust
The most obvious design methods involve functional decomposition. This leads to programs in which procedures represent distinct logical functions in a program. Examples of such functions: “Display menu” “Get user option” This is called procedural abstraction
We can identify five criteria to help evaluate modular design methods: Modular decomposability; Modular composability; Modular understandability; Modular continuity; Modular protection.
System level Sub-system level
Modular composability - a method satisfies this criterion if it leads to the production of modules that may be freely combined to produce new systems. Composability is directly related to the issue of reusability Note that composability is often at odds with decomposability; top-down design, for example, it tends to produce modules that may not be composed in the way desired This is because top-down design leads to modules which fulfil a specific function, rather than a general one
Modular Understandability - a design method satisfies this criterion if it encourages the development of modules which are easily understandable. COUNTER EXAMPLE 1. Take a thousand lines program, containing no procedures; it’s just a long list of sequential statements. Divide it into twenty blocks, each fifty statements long; make each block a method. COUNTER EXAMPLE 2. “Go to” statements.