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

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

1 Software Design Introduction  The chapter will address the following questions:  How do you factor a program into manageable program modules that can.
What is Software Design?  Introduction  Software design consists of two components, modular design and packaging.  Modular design is the decomposition.
Copyright Irwin/McGraw-Hill Software Design Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Software Design Deriving a solution which satisfies software requirements.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Introduction To System Analysis and Design
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Jump to first page 1 System Design (Finalizing Design Specifications) Chapter 3d.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Establishing the overall structure of a software system
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Course Instructor: Aisha Azeem
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Chapter 6: Architectural Design
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 system design 1 what is systems design? preparation of the system’s specifications with.
The Design Discipline.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architectural Design. Recap Introduction to design Design models Characteristics of good design Design Concepts.
©Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 13Slide 1 Architectural Design u Establishing the overall structure of a software system.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 10 Architectural Design.
Architectural Design portions ©Ian Sommerville 1995 Establishing the overall structure of a software system.
Architectural Design To explain the advantages and disadvantages of different distributed systems architectures To discuss client-server and distributed.
Ch:10 Component Level Design Unit 4. What is Component? A component is a modular building block for computer software Because components reside within.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
 2004 by SEC Chapter 4 Software Design. 2  2004 by SEC Chapter 4 Software Design 4.1 Design Fundamentals 4.2 Design Method 4.3 Architecture Design
Introduction To System Analysis and Design
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition and Ch. 10, 6 th edition.
Sommerville, Mejia-Alvarez, 2009Software Engineering, Slide 1 Software Design u Deriving a solution which satisfies software requirements.
Software Design Deriving a solution which satisfies software requirements.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
Software Design Process A solution to satisfy the requirements ◦ Design process and methods ◦ Design strategies including object-oriented design and functional.
Software Architecture and Patterns
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
 Repository Model  Client-Server Model  Layered Model  Modular decomposition styles  Object Models  Function Oriented Pipelining  Control Styles.
1 6 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 6 The Traditional Approach to Requirements.
1 CMPT 275 High Level Design Phase Modularization.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 11 Slide 1 Architectural Design.
Chapter 7: Architectural Design Chapter 11 in textbook 1.
CSC480 Software Engineering Lecture 10 September 25, 2002.
CMSC 345 Fall 2000 Design Issues. Modularity and Abstraction Characteristic of all design methods Components have clearly defined inputs and outputs,
The Software Development Life Cycle: An Overview
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
©Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements.
Slide 1 Chapter 8 Architectural Design. Slide 2 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 11 Slide 1 Architectural Design.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
Further Modularization, Cohesion, and Coupling. Simple Program Design, Fourth Edition Chapter 9 2 Objectives In this chapter you will be able to: Further.
7. Modular and structured design
Coupling and Cohesion Rajni Bhalla.
Lecture 9- Design Concepts and Principles
Software Design Mr. Manoj Kumar Kar.
Part 3 Design What does design mean in different fields?
Software Design AITI GP John Paul Vergara.
CS223: Software Engineering
Software Design CMSC 345, Version 1/11.
Lecture 9- Design Concepts and Principles
Cohesion and Coupling.
Presentation transcript:

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

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

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

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

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

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

7 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

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

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

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

11

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

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

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

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

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

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

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

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

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?

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

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

23 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

24 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

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