Software Engineering Software Design Slide 1 Software Engineering Software Design.

Slides:



Advertisements
Similar presentations
Lecture 6: Software Design (Part I)
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Object-Oriented Software Construction Bertrand Meyer 2nd ed., Prentice Hall, 1997.
Creating Computer Programs lesson 27. This lesson includes the following sections: What is a Computer Program? How Programs Solve Problems Two Approaches:
Software Design Deriving a solution which satisfies software Speficitaion.
Software Design Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
Software Design Deriving a solution which satisfies software requirements.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page:
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
Programming Language Paradigms: summary. Object-oriented programming Objects are the fundamental building blocks of a program. Interaction is structured.
Algorithms and Problem Solving-1 Algorithms and Problem Solving.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009.
Course Instructor: Aisha Azeem
Software Design Deriving a solution which satisfies software requirements.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
MADALINA CROITORU Software Engineering week 4 Madalina Croitoru IUT Montpellier.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
GENERAL CONCEPTS OF OOPS INTRODUCTION With rapidly changing world and highly competitive and versatile nature of industry, the operations are becoming.
1/19 Component Design On-demand Learning Series Software Engineering of Web Application - Principles of Good Component Design Hunan University, Software.
Architectural Design portions ©Ian Sommerville 1995 Establishing the overall structure of a software system.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Computer Science 240 © Ken Rodham 2006 Principles of Software 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.
Design engineering Vilnius The goal of design engineering is to produce a model that exhibits: firmness – a program should not have bugs that inhibit.
Software Design Deriving a solution which satisfies software requirements.
Software Design Process A solution to satisfy the requirements ◦ Design process and methods ◦ Design strategies including object-oriented design and functional.
1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13.
Copyright 2003 Scott/Jones Publishing Standard Version of Starting Out with C++, 4th Edition Chapter 13 Introduction to Classes.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Chapter 10 Software Engineering. Understand the software life cycle. Describe the development process models. Understand the concept of modularity in.
Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU.
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Chapter 6 – Architectural Design Lecture 1 1Chapter 6 Architectural design.
PRINCIPLES OF GOOD DESIGN 12/7/ Assignment 4 – Deadline 28 Nov.  Read an article placed in generalshare course folder  Point: Design Patterns.
Thanks for Coming l WEB. Principles of Good Design SEI, SJTU WEB APPS and SERVICES.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Dr D. Greer, Queens University Belfast )Chapter Six 1 Software Engineering Chapter Six Software Design Quality Learning Outcomes.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
The Software Development Life Cycle: An Overview
Week 6: Software Design HNDIT Software Engineering Software Design Learning Outcomes  Understand the activities involved in the Design process.
Object-Oriented Design Concepts University of Sunderland.
©Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements.
Algorithms and Problem Solving. Learn about problem solving skills Explore the algorithmic approach for problem solving Learn about algorithm development.
Basic Characteristics of Object-Oriented Systems
Slide 1 Chapter 8 Architectural Design. Slide 2 Topics covered l System structuring l Control models l Modular decomposition l Domain-specific architectures.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
7. Modular and structured design
Cmpe 589 Spring 2006.
which satisfies software requirements
Lecture 9- Design Concepts and Principles
Software Design Mr. Manoj Kumar Kar.
Software Design CMSC 345, Version 1/11.
Lecture 9- Design Concepts and Principles
Algorithms and Problem Solving
Principles of Good Design
Software Engineering Software Design.
Presentation transcript:

Software Engineering Software Design Slide 1 Software Engineering Software Design

Software Engineering Software Design Slide 2 Software Design Deriving a solution which satisfies software requirements

Software Engineering Software Design Slide 3 Stages of Design Problem understanding –Look at the problem from different angles to discover the design requirements. Identify one or more solutions –Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources. Describe solution abstractions –Use graphical, formal or other descriptive notations to describe the components of the design. Repeat process for each identified abstraction until the design is expressed in primitive terms.

Software Engineering Software Design Slide 4 The Design Process Any design may be modelled as a directed graph made up of entities with attributes which participate in relationships. The system should be described at several different levels of abstraction. Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary.

Software Engineering Software Design Slide 5 Phases in the Design Process

Software Engineering Software Design Slide 6 Design Phases Architectural design: Identify sub-systems. Abstract specification: Specify sub-systems. Interface design: Describe sub-system interfaces. Component design: Decompose sub-systems into components. Data structure design: Design data structures to hold problem data. Algorithm design: Design algorithms for problem functions.

Software Engineering Software Design Slide 7 Design Computer systems are not monolithic: they are usually composed of multiple, interacting modules. Modularity has long been seen as a key to cheap, high quality software. The goal of system design is to decode: –What the modules are; –What the modules should be; –How the modules interact with one-another

Software Engineering Software Design Slide 8 Modular programming In the early days, modular programming was taken to mean constructing programs out of small pieces: “subroutines” But modularity cannot bring benefits unless the modules are –autonomous, –coherent and –robust

Software Engineering Software Design Slide 9 Procedural Abstraction The most obvious design methods involve functional decomposition. This leads to programs in which procedures represent distinct logical functions in a program. Examples of such functions: –“Display menu” –“Get user option” This is called procedural abstraction

Software Engineering Software Design Slide 10 Programs as Functions Another view is programs as functions: input output x  f  f (x) the program is viewed as a function from a set I of legal inputs to a set O of outputs. There are programming languages (ML, Miranda, LISP) that directly support this view of programming Well-suited to certain application domains - e.g., compilers Less well-suited to distributed, non- terminating systems - e.g., process control systems, operating systems like WinNT, ATM machines

Software Engineering Software Design Slide 11 Object-oriented design – The system is viewed as a collection of interacting objects. – The system state is decentralized and each object manages its own state. – Objects may be instances of an object class and communicate by exchanging methods.

Software Engineering Software Design Slide 12 Five Criteria for Design Methods We can identify five criteria to help evaluate modular design methods: –Modular decomposability; –Modular composability; –Modular understandability; –Modular continuity; –Modular protection.

Software Engineering Software Design Slide 13 Modular Decomposability This criterion is met by a design method if the method supports the decomposition of a problem into smaller sub-problems, which can be solved independently. In general method will be repetitive: sub- problems will be divided still further Top-down design methods fulfil this criterion; stepwise refinement is an example of such method

Software Engineering Software Design Slide 14 Hierarchical Design Structure

Software Engineering Software Design Slide 15 Top-down Design In principle, top-down design involves starting at the uppermost components in the hierarchy and working down the hierarchy level by level. In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.

Software Engineering Software Design Slide 16 Modular Composability A method satisfies this criterion if it leads to the production of modules that may be freely combined to produce new systems. Composability is directly related to the issue of reusability Note that composability is often at odds with decomposability; top-down design, –for example, tends to produce modules that may not be composed in the way desired This is because top-down design leads to modules which fulfil a specific function, rather than a general one

Software Engineering Software Design Slide 17 Examples The Numerical Algorithm Group (NAG) libraries contain a wide range of routines for solving problems in linear algebra, differential equations, etc. The Unix shell provides a facility called a pipe, written “  ”, whereby –the standard output of one program may be redirected to the standard input of another; this convention favours composability.

Software Engineering Software Design Slide 18 Modular Understandability A design method satisfies this criterion if it encourages the development of modules which are easily understandable. COUNTER EXAMPLE 1. Take a thousand lines program, containing no procedures; it’s just a long list of sequential statements. Divide it into twenty blocks, each fifty statements long; make each block a method. COUNTER EXAMPLE 2. “Go to” statements.

Software Engineering Software Design Slide 19 Understandability Related to several component characteristics –Can the component be understood on its own? –Are meaningful names used? –Is the design well-documented? –Are complex algorithms used? Informally, high complexity means many relationships between different parts of the design.

Software Engineering Software Design Slide 20 Modular Continuity A method satisfies this criterion if it leads to the production of software such that a small change in the problem specification leads to a change in just one (or a small number of ) modules. EXAMPLE. Some projects enforce the rule that no numerical or textual literal should be used in programs: only symbolic constants should be used COUNTER EXAMPLE. Static arrays (as opposed to open arrays) make this criterion harder to satisfy.

Software Engineering Software Design Slide 21 Modular Protection A method satisfied this criterion if it yields architectures in which the effect of an abnormal condition at run-time only effects one (or very few) modules EXAMPLE. Validating input at source prevents errors from propagating throughout the program. COUNTER EXAMPLE. Using int types where subrange or short types are appropriate.

Software Engineering Software Design Slide 22 Five principles for Good Design From the discussion above, we can distil five principles that should be adhered to: –Linguistic modular units; –Few interfaces; –Small interfaces –Explicit interfaces; –Information hiding.

Software Engineering Software Design Slide 23 Linguistic Modular Units A programming language (or design language) should support the principle of linguistic modular units: –Modules must correspond to linguistic units in the language used EXAMPLE. Java methods and classes COUNTER EXAMPLE. Subroutines in BASIC are called by giving a line number where execution is to proceed from; there is no way of telling, just by looking at a section of code, that it is a subroutine.

Software Engineering Software Design Slide 24 Few Interfaces This principle states that the overall number of communication channels between modules should be as small as possible: –Every module should communicate with as few others as possible. So, in the system with n modules, there may be a minimum of n-1 and a maximum of links; your system should stay closer to the minimum

Software Engineering Software Design Slide 25 Few Interfaces

Software Engineering Software Design Slide 26 Small Interfaces (Loose Coupling) This principle states: –If any two modules communicate, they should exchange as little information as possible. COUNTER EXAMPLE. Declaring all instance variables as public!

Software Engineering Software Design Slide 27 A measure of the strength of the inter-connections between system components. Loose coupling means component changes are unlikely to affect other components. –Shared variables or control information exchange lead to tight coupling. –Loose coupling can be achieved by state decentralization (as in objects) and component communication via parameters or message passing. Coupling

Software Engineering Software Design Slide 28 Tight Coupling

Software Engineering Software Design Slide 29 Loose Coupling

Software Engineering Software Design Slide 30 Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing. However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes. Coupling and Inheritance

Software Engineering Software Design Slide 31 Reusability A major obstacle to the production of cheap quality software is the intractability of the reusability issue. Why isn’t writing software more like producing hardware? Why do we start from scratch every time, coding similar problems time after time after time? Obstacles: –Economic; –Organizational; –Psychological.

Software Engineering Software Design Slide 32 Stepwise Refinement The simplest realistic design method, widely used in practice. Not appropriate for large-scale, distributed systems: mainly applicable to the design of methods. Basic idea is: –Start with a high-level spec of what a method is to achieve; –Break this down into a small number of problems (usually no more than 10) –For each of these problems do the same; –Repeat until the sub-problems may be solved immediately.

Software Engineering Software Design Slide 33 Explicit Interfaces If two modules must communicate, they must do it so that we can see it: –If modules A and B communicate, this must be obvious from the text of A or B or both. Why? If we change a module, we need to see what other modules may be affected by these changes.

Software Engineering Software Design Slide 34 Information Hiding This principle states: –All information about a module, (and particularly how the module does what it does) should be private to the module unless it is specifically declared otherwise. Thus each module should have some interface, which is how the world sees it anything beyond that interface should be hidden. The default Java rule: –Make everything private

Software Engineering Software Design Slide 35 Cohesion A measure of how well a component “fits together”. A component should implement a single logical entity or function. Cohesion is a desirable design component attribute as when a change has to be made, it is localized in a single cohesive component. Various levels of cohesion have been identified.

Software Engineering Software Design Slide 36 Cohesion Levels Coincidental cohesion (weak) –Parts of a component are simply bundled together. Logical association (weak) –Components which perform similar functions are grouped. Temporal cohesion (weak) –Components which are activated at the same time are grouped.

Software Engineering Software Design Slide 37 Cohesion Levels Communicational cohesion (medium) –All the elements of a component operate on the same input or produce the same output. Sequential cohesion (medium) –The output for one part of a component is the input to another part. Functional cohesion (strong) –Each part of a component is necessary for the execution of a single function. Object cohesion (strong) –Each operation provides functionality which allows object attributes to be modified or inspected.

Software Engineering Software Design Slide 38 Cohesion as a Design Attribute Not well-defined. Often difficult to classify cohesion. Inheriting attributes from super-classes weakens cohesion. –To understand a component, the super-classes as well as the component class must be examined. –Object class browsers assist with this process.