Software Design Overview Reference Software Engineering by Ian

Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13 1

Topics • What is Design? • Design Description • The Design Process – Architectural Design • Design Strategies • Design Quality – Component Cohesion – Component Coupling 2

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 3

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) 4

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 5

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 6

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 7

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 8

A Student Information System Student Registration System Grade Report Generator Student Information Repository Transcript Generator Course Schedule Generator Graduation Checkout System 9

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 10

11

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 12

Generic Event-driven System Subsystem 1 Subsystem 2 Subsystem 3 Subsystem 4 Event and message handler 13

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. 14

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 15

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 16

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 17

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 18

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 19

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? 20

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 21

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 22

How components are coupled References from one component to another, such as invocation n Amount of data passed from one component to another n Amount of control one component has over another n Degree of complexity of interface, e. g. , one entry point vs. mutual entry points n 23

Goal is to Minimize Coupling Enables us to change portion of system while disrupting rest of system little as possible n Very low coupling might allow pull-out, plug-in replacement of only one component n Loose coupling may require changing or replacing a few components n High coupling may require widespread perturbations in system n Low coupling reduces the number of components needing revision n 24

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 25