/
Software Engineering Software Engineering

Software Engineering - PowerPoint Presentation

briana-ranney
briana-ranney . @briana-ranney
Follow
384 views
Uploaded On 2016-08-03

Software Engineering - PPT Presentation

COMP 201 Lecturer Sebastian Coope Ashton Building Room G18 Email coopesliverpoolacuk COMP 201 webpage httpwwwcsclivacukcoopescomp201 httpwwwcsclivacukpbellcomp201html ID: 430997

software design engineering comp201 design software comp201 engineering modular systems data modules method repository component criterion system top composability

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "Software Engineering" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

Software EngineeringCOMP 201

Lecturer: Sebastian CoopeAshton Building, Room G.18E-mail: coopes@liverpool.ac.uk COMP 201 web-page:http://www.csc.liv.ac.uk/~coopes/comp201http://www.csc.liv.ac.uk/~pbell/comp201.htmlLecture 13 – Design Methodology

1

COMP201 - Software EngineeringSlide2

Software Design Deriving a solution which satisfies software requirements2

COMP201 - Software EngineeringSlide3

The Design ProblemYou have 4 developersYou have a 500 page requirements specificationHow to control break up the work?

COMP201 - Software Engineering3Requirements

Class1

Class2

Class3

Class4

Class5

Class6

Class7

Class11

Class10

Class12

Class8

Class9

Developer 1

Developer 2

Developer 3

Developer 4

Class1

Class2

Class3

Class4

Class8

Class9Slide4

Software DesignWhySoftware is produced by many peopleSoftware needs to beSimpleUnderstandableFlexible

PortableRe-usableHowComplex to simple AbstractionCOMP201 - Software Engineering4Slide5

Software Design in RealityDesign mixed with implementationDesign step 1Implement and add more designDesign step 2Implement and add more designIn effect much of software is designed while coded and the design document doesn’t reflect the final product

COMP201 - Software Engineering5Slide6

Stages of DesignProblem understandingLook at the problem from different angles to discover the

design requirements.Identify one or more solutionsEvaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources.Describe solution abstractionsUse 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.

6

COMP201 - Software EngineeringSlide7

The Design ProcessAny design may be modeled 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.7COMP201 - Software EngineeringSlide8

Phases in the Design Process

8COMP201 - Software EngineeringSlide9

Design PhasesArchitectural 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.

9

COMP201 - Software EngineeringSlide10

DesignComputer 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 do;How the modules interact with one-another10COMP201 - Software EngineeringSlide11

Modular ProgrammingIn 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 robust11COMP201 - Software EngineeringSlide12

Procedural AbstractionThe 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 abstraction12COMP201 - Software EngineeringSlide13

Programs as FunctionsAnother 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

13

COMP201 - Software EngineeringSlide14

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. Note , use of internal state against functional programming

Objects may be instances of an object class

and

communicate by exchanging

messages.

14

COMP201 - Software EngineeringSlide15

Five Criteria for Design MethodsWe can identify five criteria to help evaluate modular design methods:Modular decomposability;

Modular composability;Modular understandability;Modular continuity;Modular protection.15COMP201 - Software EngineeringSlide16

Modular DecomposabilityModular 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, this method will be repetitive: sub-problems will be divided still furtherTop-down design methods fulfil this criterion; stepwise refinement is an example of such a method 16COMP201 - Software EngineeringSlide17

Hierarchical Design Structure

17COMP201 - Software EngineeringSlide18

Top-Down DesignIn 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.

18

COMP201 - Software EngineeringSlide19

An Example of Top-Down DesignCOMP201 - Software Engineering19

Imagine designing a word processor program from scratch. What subsystems could be initially found at the top level? File I/O, printing, graphical user interface, text processing etc. For each of these components we can then decompose further, i.e., File I/O comprises of saving documents and opening documents..Slide20

Modular ComposabilityModular 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, it tends to produce modules that may not be composed in the way desiredThis is because top-down design leads to modules which fulfil a specific function, rather than a general one

20

COMP201 - Software EngineeringSlide21

ExamplesThe 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.21COMP201 - Software EngineeringSlide22

Modular Understandability Abstractionint A=21int

age_in_years = 21; print_out_document(Document d)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.

22

COMP201 - Software EngineeringSlide23

Modular UnderstandabilityRelated 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.

23

COMP201 - Software EngineeringSlide24

Modular ContinuityModular 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 usedCOUNTER EXAMPLE. Static arrays (as opposed to dynamic arrays) make this criterion harder to satisfy.24COMP201 - Software EngineeringSlide25

Modular ProtectionModular 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) modulesEXAMPLE.

Validating input at source prevents errors from propagating throughout the program (design by contract)COUNTER EXAMPLE. Using int types where subrange or short types are appropriate. 25COMP201 - Software EngineeringSlide26

A Real Life Example – Ariane 5 Flight 501The failure of an Ariane 5 space launcher is possibly the most expensive software bug in history at around $370 million.Other bugs have been even worse by causing loss of life, for example Therac-25 radiation machines.

COMP201 - Software Engineering26Slide27

The Ariane 5 Space LauncherWhile developing the Ariane 5 space launcher, the designers reused a component (the inertial reference software) which was successfully used in the Ariane 4 launcher

This component failed 37 seconds into the flight and the ground crew had to instruct the launcher to self-destruct.The error was caused by an unhandled numerical conversion exception causing a numeric overflow.Component reuse is usually a good thing but care must be taken that assumptions made when the component was developed are still valid!COMP201 - Software Engineering27Slide28

Repository ModelsSub systems making up a system must exchange and share data so they can work together effectively.There are two main approaches to this:The repository model – All shared data is held in a central database which may be accessed by all sub-systemsEach sub-system or component maintains its own database. Data is then exchanged between sub-systems via message passing.

There are advantages and disadvantages to each approach as we shall now see.COMP201 - Software Engineering28Slide29

Repository ModelThe advantages include:Databases are an efficient way to share large amounts of data and data does not have to be transformed between different sub-systems (they agree on a single data representation).Sub-systems producing data need not be concerned with how that data is used by other sub-systems.

Many standard operations such as backup, security, access control, recovery and data integrity are centralised and can be controlled by a single repository manager.The data model is visible through the repository schema.COMP201 - Software Engineering29Slide30

Repository ModelThe disadvantages include:Sub-systems must agree on the data model which means compromises must be made, for example with performance.Evolution may be difficult since a large amount of data is generated and translation may be difficult and expensive.

Different systems have different requirements for security, recovery and backup policies which may be difficult to enforce in a single database.It may be difficult to distribute the repository over a number of different machines.COMP201 - Software Engineering30Slide31

Lecture Key PointsWe have studied five criteria to help evaluate modular design methods and their advantages:Modular decomposability; modular composability; modular

understandability; modular continuity; modular protection.We have seen the advantages and the disadvantages of repository modelsCOMP201 - Software Engineering31