software engineering comp 201 l.
Skip this Video
Download Presentation
Software Engineering COMP 201

Loading in 2 Seconds...

play fullscreen
1 / 38

Software Engineering COMP 201 - PowerPoint PPT Presentation

  • Uploaded on

Software Engineering COMP 201. Design and design methodology. Software Design . Deriving a solution which satisfies software requirements. Stages of Design. Problem understanding Look at the problem from different angles to discover the design requirements. Identify one or more solutions

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Software Engineering COMP 201' - ilario

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software engineering comp 201

Software EngineeringCOMP 201

Design and design methodology

software design
Software Design

Deriving a solution which satisfies software requirements

stages of design
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 abstractionuntil the design is expressed in primitive terms.
the design process
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.
design phases
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.

  • 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
modular programming
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
procedural abstraction
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
programs as functions
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

Less well-suited to distributed, non-terminating systems - e.g., process control systems, operating systems like WinNT, ATM machines

Well-suited to certain application domains - e.g., compilers

object oriented design
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.
five criteria for design methods
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.
modular decomposability
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
top down design
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.

modular composability
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
  • 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.
modular understandability
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.
  • 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.
modular continuity
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.
modular protection
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.
five principles for good design
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.
linguistic modular units
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.
few interfaces
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
small interfaces loose coupling
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!
  • 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 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.

  • 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.
stepwise refinement
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.
explicit interfaces
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.
information hiding
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

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.
cohesion levels
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.
cohesion levels37
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.
cohesion as a design attribute
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.