250 likes | 264 Views
Software Design Overview. Reference: Software Engineering , by Ian Sommerville, Ch. 12 & 13. Topics. What is Design? Design Description The Design Process Architectural Design Design Strategies Design Quality Component Cohesion Component Coupling. What is Design?.
E N D
Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13
Topics • What is Design? • Design Description • The Design Process • Architectural Design • Design Strategies • Design Quality • Component Cohesion • Component Coupling
What is Design? • Where informal ideas are transformed to detailed implementation descriptions • It is a creative process • There is no design “cookbook” • It is learned by experience and study of existing systems
Design Description Three main design notations: • Graphical notations • Display relationships between components • Relate the design to the real-world system • Program Description Languages (PDLs) • Pseudocode • Informal text • For anything that can’t be described formally (e.g., design rationale, non-functional considerations)
The Design Process • Architectural Design • Subsystems and their relationships are identified and documented • Abstract Specification • Document an abstract specification of the services provided by and constraints on each subsystem • Interface Design • Document each subsystem’s interface
The Design Process (con’t) • Component Design • Break subsystems into components and document their interfaces • Data Structure Design • Specify the data structures used in the system implementation • Algorithm Design • Specify the implementation algorithms
Architectural Design How a system is decomposed into subsystems that provide some related set of services • Domain-independent architectures • Repository Model • Client-Server Model • Event-driven Model • Many others ... • Domain-specific architectures
Architectural Design -Repository Model • Systems which use large amounts of data are organized around a shared database or repository • Suited to applications where data is generated by one subsystem and used by others • Example: a management information system
A Student Information System Student Registration System Grade Report Generator Student Information Repository Transcript Generator Course Schedule Generator Graduation Checkout System
Architectural Design -Client-Server Model • A distributed system model which shows how data and processing is distributed across a range of processors • Servers offer services to other subsystems • Clients call on the services offered by the servers
Architectural Design -Event-Driven Model • Driven by externally generated events • The timing is outside the control of the process that handles that event • Examples: • spreadsheets • GUI • typically any real-time system
Generic Event-driven System Subsystem 1 Subsystem 2 Subsystem 3 Subsystem 4 Event and message handler
Design Strategies • Functional Design System is designed from a functional viewpoint, starting with a high-level view and refining this into a more detailed design. The system state is centralized and shared between the functions. • Object-oriented Design System is viewed as a collection of objects rather than functions. The system state is decentralized. Each object manages its own information.
Design Quality What is “good” design? No general agreement, but ... • Should correctly implement specification • Must be understandable • Good naming conventions • Good internal and external documentation • Minimize complex algorithms • Must be able to adapt to modification or addition of new functionality • High component cohesion • Low component coupling
Component Cohesion • A measure of the closeness of the relationships between the component’s components • Component should implement a single logical function/task (functional) or implement a single logical entity (OO) • We want strong cohesion
Component Cohesion (con’t) 7 levels of cohesion (Constantine & Yourdan), weakest to strongest: • Coincidental Cohesion • The parts of a component are not related but simply bundled into a single component • Logical Association • Components that perform similar functions such as input, error handling and so on are put together in a single component
Component Cohesion (con’t) • Temporal Association • All of the components that are activated at a single time, such as start up or shut down, are brought together • Procedural Cohesion • The elements in a component make up a single control sequence • Communicational Cohesion • All of the elements of a component operate on the same input data or produce the same output data
Component Cohesion (con’t) • Sequential Cohesion • The output from one element in the component serves as input for some other element • Functional Cohesion • Each part of the component is necessary for the execution of a single function/task
Component Cohesion (con’t) Cohesion applies to both functional and OO design approaches: • Cohesive Function • Performs a single task • Cohesive Object • A single entity is represented and all the operations on that entity are included with the object So, which promotes strong cohesion better -- functional or OO design?
Component Coupling • A measure of the strength of the interconnections between components in a design • Want components to be as independent as possible • We want low coupling
Component Coupling (con’t) • Functional Design • No/little global data • No hard-coded constants • Nothing that causes one function to require knowledge of another’s implementation • OO Design • Inheritance by nature causes coupling between base and derived classes • Multiple inheritance greatly increases coupling
How components are coupled • References from one component to another, such as invocation • Amount of data passed from one component to another • Amount of control one component has over another • Degree of complexity of interface, e.g., one entry point vs. mutual entry points
Goal is to Minimize Coupling • Enables us to change portion of system while disrupting rest of system little as possible • Very low coupling might allow pull-out, plug-in replacement of only one component • Loose coupling may require changing or replacing a few components • High coupling may require widespread perturbations in system • Low coupling reduces the number of components needing revision
Types of Coupling • Content: one component directly modifies data or control flow of another • Common: Organizing data into a common store • Control: Control flags passed as parameters between components • Stamp: Data structures passed • Data: Only primitive data passed