Scribd
Upload
11 views

software construction

The document discusses software construction with a focus on design patterns, specifically the Adapter, Bridge, and Iterator patterns, which provide solutions to common design problems. It also addresses the importance of portability in software, detailing techniques for achieving it and the challenges associated with hardware and operating system incompatibilities. Additionally, the document covers planning and estimation in the software process, emphasizing the need for accurate cost estimates based on project requirements.

Uploaded by

sultany560
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
11 views

software construction

The document discusses software construction with a focus on design patterns, specifically the Adapter, Bridge, and Iterator patterns, which provide solutions to common design problems. It also addresses the importance of portability in software, detailing techniques for achieving it and the challenges associated with hardware and operating system incompatibilities. Additionally, the document covers planning and estimation in the software process, emphasizing the need for accurate cost estimates based on project requirements.

Uploaded by

sultany560
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 35

Software construction

(SWE 2202)

@2024

Maryam Abacha American University of Nigeria


Kano.
Engr. Salihu O. Yahaya
MAAUN
MODULE 4

Engr. Salihu O. Yahaya


MAAUN
DesignPatterns
 Definition

 A design pattern is a solution to a general


design problem, in the form of a set of
interacting classes that have to be
customized to create a specific design.

 What is Re-Used: relationships among


classes (usually expressed as a class
diagram)
Cont…
 What is New: details within each class
(usually a new class diagram, with the
generic classes from the previous
diagram replaced by classes tailored to
the specific problem to be solved).

 Adapter Design Pattern:


i. Premiums at Flint stock Life insurance Company (FLIC) depended on
both the age and the gender of the applicant for coverage.

iii. FLIC has recently decided that some policies will now be gender neutral.
That is, the premiums for those policies will depend solely on the age of the
applicant.
Cont…

iii. The old computation of premiums used this


class:

iv. The new computation of premiums will use this


class
Cont…
v. However there has not been enough time
to change the entire system. The situation
is displayed in the following figure

cont…

vi. Note the three interface problems with


the bottom reference in the above diagram:

(a) Insurance calls the Applicant class instead of


the Neutral Applicant class.

(b) Insurance calls the computePremiummethod instead of the


computeNeutralPremium method.

(c)The parameters passed are age and gender, instead of age


alone.
cont…
 To solve these problems, we interpose the
Wrapper class, as shown in this diagram
The Adapter Design Pattern

 Generalizing the Wrapper construction


above leads to the Adapter Design
Pattern

cont…

 An abstract class is a class which cannot


be instantiated, but which can be used as
a base class for inheritance.

 Example: Abstract Target in the Adapter


Design Pattern is an abstract class.
 Definition: An abstract method is a method which has an
interface, but
which does not have an implementation.
Cont…

 Example: In the Adapter Design Pattern,


Abstract Target class, request() is an
abstract method. Usually abstract
methods live inside of abstract classes.
 Abstract methods are implemented in sub classes of the abstract class.

 The abstract request method from Abstract Target is implemented in the


(concrete) subclass Adapter, to invoke the specific Request
cont…

 This solves the interfacing problems from


earlier. This is the raison d’ˆ etre for the
Adpaterde sign pattern.
cont…
5. But the pattern is more powerful than
that. It provides away for an object to
permit access to its internal implementation
in such away that clients are not Coupled
to the structure of that internal
implementation.
BridgeDesignPattern

i. Prototype: a device driver, e.g. a printer


driver.
ii. Key Idea: De-couple an abstraction from its implementation, so that the
two can be changed independently of one another.

iii. Technique: Construct abridge which separates the part of the


application which is not hardware-dependent from them part of the
application which is.

iv. Below is a class diagram for the Bridge Design Pattern.


cont…
Iterator Design Pattern

 Definition: An iterator is a programming


construct that allows a programmer to
traverse the elements of an aggregate
object without exposing the
implementation of the aggregate.

 Another name for an iterator is a cursor,


especially in a data base context.
Genericity is the ability to parameterise
class definitions.
cont…

 Two key ingredients:


 (a) element traversal: first, next, is Done
in the example.
 (b) element access: current Item in the
example.

 Below is a class diagram for the Iterator


Design Pattern.


Cont…


cont…

1. A Client deals with only Abstract


Aggregate and Abstract Iterator (essentially
an interface).
2. The Client object asks the Abstract
Aggregate object to create an iterator for
the Concrete Aggregate object, and then
uses the returned Concrete Iterator object
to traverse the elements of the aggregate.
cont…

(a)Abstract Aggregate needs the abstract


method createIterator, as away of
returning an Iterator to the Client.
(b) The AbstractIterator (interface) needs to
define only the basic abstract traversal
methods.
(c) These four methods are implemented at
the next level of abstraction, in
ConcreteIterator.
cont…

3. Since implementation details of the


elements are hidden from the Iterator itself,
we can use an Iterator to process each
element in an aggregate, independently of
the implementation of the aggregate.
Portability

 A program, P1, is portable if it is


significantly cheaper to convert it to P2
(and run it on H/WH2, with OSO2 &
compilerC2) than tore-codeP2 from
scratch.
 Portability does not mean porting the
code only:
(a) We must port documentation &
manuals too.
(b) If S/W is changed, then all docs must
also change.
cont…

 Hardware Incompatibilities.

1. Charactercodes:
(a)American Standard Code for
Information Interchange (ASCII):
00000001
(b)Extended Binary Coded Decimal Interchange
Code (EBCDIC): 10000001
(c) S/W developed on a platform with one encoding
must be modified to work on a platform with the
other encoding.
cont…

 Operating System Incompatibilities

 Numerical System Incompatibilities


1.Wordsize:
(a) S/W developed on a 64-bit platform
will not run on a 32-bitplatform.

 Compiler Incompatibilities 1. Different compiler


versions can enforce different syntax rules.
(a)Often newer compilers are more strict.
Techniques for Achieving Portability

 Portable Operating System Software:


1. UNIX O/S was constructed for maximum
portability:

a. Platform-independent(portable):
i. 9000 LOC written in C
b. Platform-dependent(must be re-written for each
platform):
i. 1000 LOC written in Assembly
ii. 1000 LOC of C-device drivers
Portable Application Software

 Although we may not always have control


over which programming language we
must use, whenever possible we should
choose a high-level language (higher-
level=more insulated from the hardware
level).


Portable Data

 Porting large amounts of data can be very


problematic.

1. Flat files are the most portable data


format. Problems:

 A flat file is a collection of records in which the data


follows a uniform format and follows rules on value
types where applicable .
cont…

(a) Misunderstandings about file formats.


(b) Self-documenting file formats (e.g.
XML) solve problem 1a, but make files
get big.


Planning and Estimation

 Planning and the Software Process

1.When to estimate:
(a) after requirements workflow-only an informal
understanding of what is needed
i. At this point, our ranges of estimates must
be broad.
ii. Figures (a) explain some what why this is true.

iii. This is a summarized Figure (a) from the text. It displays a


model for estimating the relative range of a cost estimate for
each workflow.
cont…


cont…

iv. This is a summarized Figure (b) from the


text. It displays the range of cost estimates,
in millions of dollars, for a software product
that costs $1million to build.

v. We provide a preliminary estimate here,


so that the client can decide whether to
proceed to analysis or not.
cont…

 O\


cont…

(b) After analysis workflow-a more detailed


understanding of what is needed

 Remarks: 1. In practice, you may find yourself getting


pressured by the client to reduce your preliminary
estimates, to ensure that the project goes ahead

 Common sense says that a client can not dictate both the
requirements and the costs to satisfy them. If the client
thinks that the preliminary estimates are too high, then
they can:
cont…
(a) reduce the scope of the requirements, to reduce the
estimated cost, or
(b) increase the total budget. Giving in to pressure to reduce
estimates at this point ALWAYS leads to problems later on.


To be Cont…

You might also like