160 likes | 184 Views
Software Design. CS 123/CS 231. What is Design?. Design is the activity of specifying a solution to a problem Contrast this against other software engineering phases Analysis: understanding and specifying the problem (requirements)— WHAT versus HOW Implementation: system construction.
E N D
Software Design CS 123/CS 231
What is Design? • Design is the activity of specifying a solution to a problem • Contrast this against other software engineering phases • Analysis: understanding and specifying the problem (requirements)—WHAT versus HOW • Implementation: system construction
Stages in SW Design • Architectural Design • Abstract Specification • Interface Design • Component Design • Detailed Design *Reference: Sommerville, Chapter 12
Architectural Design • Identify Subsystems and Modules • Example: Program Submission System • Server • Teacher Interface • Student Interface
Architectural Design, continued • Design information provided is minimal • System is simply decomposed into interacting subsystems or modules • Depicted using a block diagram • subsystems: rectangles • arrows: represent interaction / flow of data and control / dependency between the subsystems
Abstract Specification • Identify services and constraints per subsystem • Example: Server • set up a class • set up a project • submit a program • Note: descriptions of services are informal
Interface Design • Per subsystem, specify its interface • collection of available functions/methods for use by other subsystems • Consistent with Encapsulation • Example: Server • function: set_up_class • parameters: catnum, section, list of students (id#’s and names)
Interface Specification • Services per subsystem are formally specified • Goal: provide unambiguous information regarding extent of external interaction • parameters/inputs, return values/outputs • Design and implementation details of the subsystem are still hidden
Component Design • Within a subsystem • determine components • per component, identify services/interfaces • Understand interaction between components at the level of the subsystem • OO Design: components are classes • Design models (using the UML, for example) are most useful at this level
Detailed Design • Specify data structures and algorithms (for methods) of the individual components (classes) • Generally still implementation-independent • Although though in practice, specific language features are used • Techniques: Pseudocode, flowcharts, others
Design Quality • Cohesion • Coupling • Understandability • Adaptability *Reference: Section 12.3 of Sommerville
Cohesion • Extent of relationship between parts of a component • High cohesion is desirable • Single logical t (or “theme”) • all parts should contribute to the function • Levels of cohesion (p. 218) • coincidental cohesion (weakest) • functional cohesion (strongest)
Coupling • Dependence between units of a subsystems or components • High coupling generally undesirable • units fully depend on each other • sensitive to change • convenient/necessary only for small components
Understandability • Cohesion and Coupling • understanding a component independently • Naming • reflects real-world intuition • Documentation • Complexity • algorithms
Adaptability • Sensitivity to change • are changes in design easy? • Loosely coupled components • Self-contained components