Software Design Deriving a solution which satisfies software requirements.

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Advertisements

Software Design Deriving a solution which satisfies software Speficitaion.
Software Engineering Software Design Slide 1 Software Engineering Software Design.
Software Design Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
Software Design Deriving a solution which satisfies software requirements.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
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 )
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
©Ian Sommerville 2000Software Engineering, 6/e, Chapter 71 System models l Abstract descriptions of systems whose requirements are being analysed.
Establishing the overall structure of a software system
©Ian Sommerville 2006Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Teamwork Know each other Compete Leadership Strengths and Weaknesses
Course Instructor: Aisha Azeem
©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 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
©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.
1 CS 456 Software Engineering. 2 Contents 3 Chapter 1: Introduction.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
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.
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.
Chapter 7 System models.
©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.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
CSC480 Software Engineering Lecture 11 September 30, 2002.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 11 Slide 1 Design.
©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 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Object-oriented Design Designing systems using self- contained objects and object.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Object-oriented Design Designing systems using self- contained objects and object.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
Dr D. Greer, Queens University Belfast )Chapter Six 1 Software Engineering Chapter Six Software Design Quality Learning Outcomes.
The Software Development Life Cycle: An Overview
CMSC 345 Fall 2000 OO Design. Characteristics of OOD Objects are abstractions of real-world or system entities and manage themselves Objects are independent.
©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.
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 8 Slide 1 System models.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
CompSci 280 S Introduction to Software Development
which satisfies software requirements
CS223: Software Engineering
Software Design CMSC 345, Version 1/11.
Software Engineering Software Design.
Presentation transcript:

Software Design Deriving a solution which satisfies software requirements

Topics covered The design process and design methods Design strategies including object-oriented design and functional decomposition - briefly Design quality attributes

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

Phases in the design process

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

Hierarchical design structure

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

Design methods Structured methods are sets of notations for expressing a software design and guidelines for creating a design Well-known methods include Structured Design (Yourdon), and JSD (Jackson Method) Can be applied successfully because they support standard notations and ensure designs follow a standard form Structured methods may be supported with CASE tools

Method components Many methods support comparable views of a system A data flow view (data flow diagrams) showing data transformations An entity-relation view describing the logical data structures A structural view showing system components and their interactions

Method deficiencies They are guidelines rather than methods in the mathematical sense. Different designers create quite different system designs They do not help much with the early, creative phase of design. Rather, they help the designer to structure and document his or her design ideas

Design description Graphical notations. Used to display component relationships Program description languages. Based on programming languages but with more flexibility to represent abstract concepts Informal text. Natural language description. All of these notations may be used in large systems design

Design strategies Functional design Object-oriented design The system is designed from a functional viewpoint. The system state is centralised and shared between the functions operating on that state Object-oriented design The system is viewed as a collection of interacting objects. The system state is de-centralised and each object manages its own state. Objects may be instances of an object class and communicate by exchanging methods

Functional or DFD view of a compiler Poor example, see Safe Home Alarm System instead

Object-oriented view of a compiler Notice the main difference between this and previous diagram?

Mixed-strategy design Although it is sometimes suggested that one approach to design is superior, in practice, an object-oriented and a functional-oriented approach to design are complementary Good software engineers should select the most appropriate approach for whatever sub-system is being designed

Design quality Design quality is an elusive concept. Quality depends on specific organisational priorities A 'good' design may be the most efficient, the cheapest, the most maintainable, the most reliable, etc. The attributes discussed here are concerned with the maintainability of the design Quality characteristics are equally applicable to function-oriented and object-oriented designs

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 localised in a single cohesive component Various levels of cohesion have been identified

Cohesion levels Coincidental cohesion (weak) Parts of a component are simply bundled together Logical association (weak) Components which perform similar functions are grouped For example: output text to screen output line to printer output record to file Seems ok Problem is it carries out a range of similar but different actions No single well defined action

Cohesion levels Temporal cohesion (weak) Components which are activated at the same time are grouped For example: clear screen open file Initialise total again not related solution is to make initialisation module all other specialised modules: call init_terminal call init_files call init_calculations

Cohesion levels Communicational cohesion (medium) All the elements of a component operate on the same data e.g. display and log temperature Sequential cohesion (medium) The output for one part of a component is the input to another part

Cohesion levels Functional cohesion (strong) Object cohesion (strong) optimal type of cohesion performs a single well-defined action on a single data object e.g. calculate average 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

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

Coupling 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 decentralisation (as in objects) and component communication via parameters or message passing

Tight coupling

Loose coupling

Coupling levels Altering another modules code (LISP, Assembler) Modifying data within another module fault that appears in one module may be due to another complicated understanding and debugging can be done via global variables or pointers or call be reference in C++ / Java Shared or global data

Coupling levels Procedure call with a parameter that is a switch (or a function pointer in C) io (command, device buffer, length); where command is 0,1,2 for read, write open; better to use read( device, buffer, length); Procedure call with parameters that are pure data ideal is call by value, where a small number of parameters are used and a copy of the data is passed to the procedure invoked clear what information is being communicated

Coupling levels Passing a serial data stream most ideal situation one module passes stream of data to another once passed data is outside control of process/module like piping in UNIX data can be thought of as a temporary intermediate file only possible in languages that support concurrency such as Ada and Erlang and Parallel C

Coupling and Inheritance 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. Such changes must be carefully controlled

Cohesion, Coupling & Testing High Cohesion ensures each unit provides a set of related capabilities and makes the tests of those capabilities easier to maintain Low Coupling allows each unit to be effectively tested in isolation

Understandability Related to several component characteristics Cohesion. Can the component be understood on its own? Naming. Are meaningful names used? Documentation. Is the design well-documented? Complexity. Are complex algorithms used? Informally, high complexity means many relationships between different parts of the design. hence it is hard to understand Most design quality metrics are oriented towards complexity measurement. They are of limited use

Adaptability A design is adaptable if: Its components are loosely coupled It is well-documented and the documentation is up to date There is an obvious correspondence between design levels (design visibility) Each component is a self-contained entity (tightly cohesive) To adapt a design, it must be possible to trace the links between design components so that change consequences can be analysed

Design traceability

Adaptability and inheritance Inheritance dramatically improves adaptability. Components may be adapted without change by deriving a sub-class and modifying that derived class However, as the depth of the inheritance hierarchy increases, it becomes increasingly complex. It must be periodically reviewed and restructured new trend in this area known as refactoring, associated with the lightweight process of Extreme Programming (XP)

Advantages of inheritance It is an abstraction mechanism which may be used to classify entities - polymorphism It is a reuse mechanism at both the design and the programming level - very useful in framework The inheritance graph is a source of organisational knowledge about domains and systems

Problems with inheritance Object classes are not self-contained. they cannot be understood without reference to their super-classes Designers have a tendency to reuse the inheritance graph created during analysis. Can lead to significant inefficiency The inheritance graphs of analysis, design and implementation have different functions and should be separately maintained

Inheritance and OOD There are differing views as to whether inheritance is fundamental to OOD. View 1. Identifying the inheritance hierarchy or network is a fundamental part of object-oriented design. Obviously this can only be implemented using an OOPL. View 2. Inheritance is a useful implementation concept which allows reuse of attribute and operation definitions. Identifying an inheritance hierarchy at the design stage places unnecessary restrictions on the implementation Inheritance introduces complexity and this is undesirable, especially in critical systems

UML associations Objects and object classes participate in relationships with other objects and object classes In the UML, a generalised relationship is indicated by an association Associations may be annotated with information that describes the association Associations are general but may indicate that an attribute of an object is an associated object or that a method relies on an associated object Be careful to distinguish between a UML dependemcy and an association

An association model