Design-Software Engineering-Lecture 03 Slides-Computer Science, Slides of Software Engineering

Download Design-Software Engineering-Lecture 03 Slides-Computer Science and more Slides Software Engineering in PDF only on Docsity!

LECTURE 3: SOFTWARE DESIGN

Software Engineering

1 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 decide: - what the modules are; - what the modules should be; - how the modules interact with one-another.
• 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.

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 Win95, ATM machines.

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

2.2 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, (which we will examine shortly).
• 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 fulfill a specific function, rather than a general one.

• EXAMPLES

1. The Numerical Algorithms Group (NAG) libraries contain a wide range of routines for solving problems in linear algebra, differential equations, etc.
2. The UNIX shell (and to a lesser extent, MS-DOS) 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.

2.4 Modular Continuity

• A method satisfies this criterion if it leads to the production of software such that a small change in 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.

2.5 Modular Protection

• A method satisfied this criterion if it yields architecures in which the effect of an abnormal condition at run-time only affects one (or very few) modules.
• EXAMPLE. Validating input at source prevents errors from propogating throughout the program.
• COUNTER EXAMPLE. Using int types where subrange or short types are appropriate.

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

3.2 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 a system with n modules, there may be a minimum of n − 1 and a maximium of n(n − 1) 2 links; your system should stay closer to the minimum.

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

3.5 Information Hiding

• This principle states:

All information about a module, (and particularly how the module does what it does) shoud 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.

5 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.
• Breaking down one problem into a number of smaller ones is known as refinement.
• Including program code in refinement is extremely bad practice — this is implementation bias/

6 Object-Oriented Design

• For complex systems, stepwise refinement is inadequate.
• We use object-oriented design.
• For much of the remainder of this course, we focus on one particular OO design approach, using UML (the “unified Modelling Language”).
• We beging by introducing basic object concepts.