Design by TLAs: ADTs, OOD and DFDs Outline of today's lecture

advertisement
Outline of today’s lecture
Design – so far
1 Abstract data types
Design by TLAs: ADTs, OOD and DFDs
CS427: Elements of Software Engineering
2 Object-Oriented Design
To date we have looked at the following tools that may be used during
the design phase:
Design
Lecture 9.1
• Pseudocode
3 Data Flow Diagrams (DFTs)
• Finite State Machines
Data Transforms...
10am, Monday 03 March 2012
Today we’ll look at
Information flows
• Abstract Data types
Info Sources and Sinks
• Object Oriented Design
Information Stores
• Data Flow Diagrams
4 Example 1: modelling a online retail system
5 Example 2: a level-0 DFD
CS427 — Design by TLAs: ADTs, OOD and DFDs
1/17
Abstract data types
Consider piece of code opposite.
Obviously this will compile OK,
but could give very surprising
results.
The version below would be
much better.
f l o a t compute ( f l o a t A n g l e ) {
...
i f ( A n g l e == 9 0 )
...
}
...
f l o a t theta , p i =3.14159;
t h e t a = compute ( p i / 2 ) ;
typedef f l o a t Degree ;
D e g r e e compute ( D e g r e e A n g l e ) {
...
i f ( A n g l e == 9 0 )
...
}
If the programmer checks
the function header before
writing the calling function, at least he/she will
know how to call it.
CS427 — Design by TLAs: ADTs, OOD and DFDs
2/17
CS427 — Design by TLAs: ADTs, OOD and DFDs
Abstract data types
Abstract data types
To design software system that is truly modular, the interfaces of each
subsystem should be defined only in terms of the data (and data types)
passed to them and returned by them. Where possible, special data types
– and correct ranges of values – should be used and no explicit reference
made to the true underling type.
In C++ (and in C), basic ADTs can be created using enum, struct and
typedef.
3/17
• enum: create an enumerated list type. Underlying data type is
usually integer, but only the programmer who writes the type needs
to know which int corresponds to which element.
Information hiding is a mechanism for deciding how “modular” a design
is (and not for achieving that modularity). It asks “How little can one
subsystem know about another in order to correctly inter-operate with it”.
• struct: A structure allows heterogeneous data types where different
If modularity is not properly achieved then a small change to one module
will effect others in unpredictable ways.
• typedef: Give an intuitive alias to an existing type.
elements can be different types and of different dimensions. This is
like a class, but only with data elements, all of which are public.
Using an object-based language, such as C++, would give even more
opportunities for user-defined data types and information hiding.
CS427 — Design by TLAs: ADTs, OOD and DFDs
4/17
CS427 — Design by TLAs: ADTs, OOD and DFDs
5/17
CS427 — Design by TLAs: ADTs, OOD and DFDs
6/17
Abstract data types
Object-Oriented Design
Object-Oriented Design
(See Chapter 16 of The Engineering of Software).
Example: to use enum, struct and typedef to implement an ADT
called Date that stores that stores the day, month, and year as elements:
A logical progression from ADTs, and particularly the signature diagram,
is to think of the elements of a programme to be Objects.
t y p e d e f enum { Jan =1, Feb , Mar , Apr , May , Jun ,
J u l , Aug , Sep , Oct , Nov , Dec } month ;
• Object: a structure containing data, and a set of functions for
We have studied ADTs to a much greater level in the C++ part of this
course, and so skip much of the details here. If interested, see Chap 15 of
the text book.
• Subclass: a child class that inherits methods and data from its
One approach is known as Class-Responsibility-Collaboration:
manipulating that data.
• Identify classes by examining the requirements,
• Method: a function manipulating the data in an object.
• Identify responsibilities (methods) for each class by finding the
• Class: a description of the methods and data structures that
actions associated with the classes,
constitute an object. So an object is an instance (a specific member
of a class. It has actual data assigned to it.
• Identify the relationships (collaborations) between classes.
This is often done using CRC Cards. Example...
parent(s).
• Superclass: the parent from which the child inherits.
7/17
Object-Oriented Design
Class Name:
Superclasses:
Subclasses:
Responsibilities
The key design aspect of Object Oriented software engineering, is how
to distill from the requirements/specifications the list of objects the
program will need.
To recap on the terminology
typedef struct
{
i n t DayofMonth ;
month Month ;
i n t Year ;
} Date ;
CS427 — Design by TLAs: ADTs, OOD and DFDs
Design
CS427 — Design by TLAs: ADTs, OOD and DFDs
8/17
Data Flow Diagrams (DFTs)
Design
CS427 — Design by TLAs: ADTs, OOD and DFDs
9/17
Data Flow Diagrams (DFTs)
Data Transforms...
(This section summarises Chap. 17 of Hamlet and Maybee).
Traditionally, one thinks of software working procedurally:
Collaborators
Data
Data
Transform
Transforms
• First A happens, then B, then C.
or
• if X
do Y
else do Z
fi
Information
Store
Thus we are thinking about flow of control.
Instead, we could model the flow of data.
Data Flow Diagrams (DFDs) consist of
• Data transforms
• Information flows
• Information sources and sinks
• Information stores
CS427 — Design by TLAs: ADTs, OOD and DFDs
10/17
CS427 — Design by TLAs: ADTs, OOD and DFDs
...are the steps at which data is converted from one form to another. In
some notations, it’s called a Process.
Information
Source / Sink
Representation
• Circle
In
fo
r
m
at
• Name of transform
io
n
• Heritage Identifier: used for step-wise refinement of model
Fl
ow
11/17
CS427 — Design by TLAs: ADTs, OOD and DFDs
12/17
Data Flow Diagrams (DFTs)
Data Flow Diagrams (DFTs)
Information flows
Data Flow Diagrams (DFTs)
Info Sources and Sinks
Information
Source / Sink
In
fo
rm
at
Information
Stores
io
n
Fl
ow
• Information coming from outside the system is a source, e.g.,
• Entered by hand, e.g., cin or scanf()
• Read from file,
• Passed as an argument to this function.
• A sink as anywhere data is begin send to, e.g.,
...describe information being exchanged between DFD elements.
Represented as an arrow labelled with the name of the information being
exchanged.
CS427 — Design by TLAs: ADTs, OOD and DFDs
are locations that information is stored for use by (this) system at a later
time.
The data is volatile — it is lost after the (sub)system exits.
(Data which is required by other systems, or this one when it runs next
time, is sent to an information sink).
• appear on screen, e.g., cout or printf()
• stored in a file
• etc
13/17
Example 1: modelling a online retail system
CS427 — Design by TLAs: ADTs, OOD and DFDs
14/17
Example 2: a level-0 DFD
In our first example, we want to model a system for tracking online
orders.
Suppose we want to design software for a payroll system...
• Data transforms: Verify Credit Card, Ship items, validate customer
information,
(See class notes for remainder of this lecture...)
• Information flows: (see diagram)
• Info Sourse/sink: Customer,
• Information store: Account info.
CS427 — Design by TLAs: ADTs, OOD and DFDs
16/17
CS427 — Design by TLAs: ADTs, OOD and DFDs
Information Stores
17/17
CS427 — Design by TLAs: ADTs, OOD and DFDs
15/17
Download