1 software design overview reference: software engineering, by ian sommerville, ch. 12 & 13
TRANSCRIPT
![Page 1: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/1.jpg)
1
Software Design Overview
Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13
![Page 2: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/2.jpg)
2
Topics
• What is Design?
• Design Description
• The Design Process– Architectural Design
• Design Strategies
• Design Quality– Component Cohesion– Component Coupling
![Page 3: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/3.jpg)
3
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
![Page 4: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/4.jpg)
4
Design DescriptionThree 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)
![Page 5: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/5.jpg)
5
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
![Page 6: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/6.jpg)
6
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
![Page 7: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/7.jpg)
7
Architectural DesignHow 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
![Page 8: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/8.jpg)
8
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
![Page 9: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/9.jpg)
9
Student Information Repository
CourseScheduleGenerator
TranscriptGenerator
GraduationCheckoutSystem
StudentRegistration
System
Grade ReportGenerator
A Student Information System
![Page 10: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/10.jpg)
10
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
![Page 11: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/11.jpg)
11
Film and picture library
Catalogueserver
Catalogue
Videoserver
Film clipfiles
Pictureserver
Digitizedphotographs
Hypertextserver
Hypertextweb
Client 1 Client 2 Client 3 Client 4
Wide-bandwidth network
![Page 12: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/12.jpg)
12
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
![Page 13: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/13.jpg)
13
Event and message handler
Subsystem 1 Subsystem 2 Subsystem 3 Subsystem 4
Generic Event-driven System
![Page 14: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/14.jpg)
14
Design Strategies
• Functional DesignSystem 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 DesignSystem is viewed as a collection of objects
rather than functions. The system state is decentralized. Each object manages its own information.
![Page 15: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/15.jpg)
15
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
![Page 16: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/16.jpg)
16
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
![Page 17: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/17.jpg)
17
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
![Page 18: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/18.jpg)
18
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
![Page 19: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/19.jpg)
19
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
![Page 20: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/20.jpg)
20
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?
![Page 21: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/21.jpg)
21
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
![Page 22: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/22.jpg)
22
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
![Page 23: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/23.jpg)
23
How components are coupledReferences 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
![Page 24: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/24.jpg)
24
Goal is to Minimize CouplingEnables 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
![Page 25: 1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13](https://reader030.vdocuments.net/reader030/viewer/2022032612/56649edb5503460f94beb693/html5/thumbnails/25.jpg)
25
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