Transcript ch01

Software Design
The Software Challenge
• In industry, a software product is expected to be used for
an extended period of time by someone who did not
write the program and who is not intimately familiar with
its internal design
• The person who maintains the software is not
necessarily the person who writes it
• It is important to design and document software in an
organized way so that it can be easily understood and
maintained after the initial release
The Software Challenge
• Initial specification for a software product may be
incomplete.
• Specification is clarified through extensive interaction
between users of the software and the system analyst.
• To avoid a communication gap, a requirements
specification should be generated at the beginning of
any software project. Designers and users should both
approve the document
The Software Life Cycle
• Software products go through several stages as they
mature from initial concept to finished product
• The sequence of stages is called a life cycle
Software Life Cycle Models
• Waterfall model: simplest way of organizing activities
that transform software from one stage to another
• Activities are performed in sequence and the results of
one flows into the next
Waterfall Model
Waterfall Model (continued)
Software Life Cycle Models
• Waterfall model is simple but unworkable
• Fundamental flaw is assumption that each stage can
and must be completed before the next one occurs
• Sometimes, it is not until the product is finished that the
user can fully express his or her requirements
Software Life Cycle Models (continued)
• Common themes among alternative models is to develop
software product in stages or cycles
• Each stage could be a mini waterfall with varying emphasis
on activities
• Unified Model: the cycles are called phases and
iterations and the activities are called workflows
• Four phases
• Inception
• Elaboration
• Construction
• Transition
• At the end of each phase, there is a review with users
Software Life Cycle Models (continued)
Software Life Cycle Activities (continued)
• Independently of how they are organized, certain
activities are essential for software development
• Requirements specification
• Architectural, component, and detailed designs
• Implementation
• Unit, integration, and acceptance tests
• Installation and maintenance
Software Life Cycle Activities (continued)
• Requirements Specification
• System analyst works with software users to clarify
the detailed system requirements
• Questions include format of input data, desired form
of any output screens, and data validation/potential
errors
• E.g. incomplete specification: design and implement a
telephone directory program
• that will contain a collection of names and numbers.
• We should be able to insert/delete/search
• What questions would you ask the user?
Requirements
Inputs:
• Initial phone directory: each name/number pair will be
read from separate lines of text file
• Additional entries: each entry is typed by the user at the
keyboard when requested
Outputs:
• Name and number of each person selected by the user
are displayed on separate lines
• Updated phone directory: each name/number pair on
separate line
Software Life Cycle Activities (continued)
• Analysis
• Make sure you completely understand the problem
before starting the design or program a solution
• Evaluate different approaches to the design
• Commercial software/ in-house?
• New hardware?
• Cost/feasibility
Software Life Cycle Activities (continued)
• Design
• Top-down approach: breaking a system into a set of
smaller subsystems
• Subproblems could be further refined and divided into still
smaller problems.
Software Life Cycle Activities (continued)
Software Life Cycle Activities (continued)
Software Life Cycle Activities (continued)
• Design
• Top-down design focuses on actions rather than data
structures
• Object-oriented approach: focuses on data elements
and operations to be performed on those data
elements.
• View software as a collection of objects (entities).
• In OOD, you identify a set of objects and specify their
interactions
• Looking at nouns in the problem specification can help you
identify objects, and looking at verbs can point to their
actions.
Software Life Cycle Activities (continued)
• Design
• UML diagrams are a design tool to illustrate the
interactions between
• Classes
• Classes and external entities
Software Life Cycle Activities (continued)
Actor/User: is an
external entity to
the program
Open diamond: “aggregation”
Entry is contained in a Directory, but it
is an independent entity.
OOD
• OOD takes advantage of two techniques
• Abstraction
• Encapsulation
Techniques: Abstraction
• Provides high-level model of a physical entity or activity
• Procedural abstraction:
• Specify what is to be achieved by a procedure
• Hide algorithms
• Data abstraction:
• specify the data objects for a problem
• without concern for their representation in memory
• The designer can focus on how to use the data objects and their
actions rather than low-level details of their implementation.
Techniques: Encapsulation
• Combine data elements and methods in a class and confine
information so that it is only visible/accessible through an associated
external interface (public methods in Java)
• Information hiding: Concealing the details of a class
implementation from users of the class
• If a higher-level class references a data object only through its
methods, the higher-level class will not have to be rewritten, even if
the data representation or method implementation changes.
• e.g.
• myEntry.name
• myEntry.firstName + myEntry.lastName;
• MyEnrty.getFullName();
Java language constructs support OOP
• Interface: supports procedural abstraction
• Class: supports encapsulation
Abstract Data Types
• Abstract data type (ADT): The combination of data
together with its methods
• “what” of the data structure,
• NOT “how” of the data structure
• E.g. Stack ADT?
– Data?
– Operations?
• The primary goal of this class is to teach you how to
use ADTs and how to create their implementations.
• Also, you will be introduced to Java API’s ADTs.
Interfaces
• A Java interface is a way to specify an ADT
• The interface specifies the names, parameters, and
return values of the ADT methods without specifying
how the methods perform their operations and without
specifying how the data is internally represented
• May also contain constant definitions
public interface Comparable {
public int compareTo(Object o);
}
Interfaces
• A Java interface is a contract between the interface
designer and the programmer who codes a class that
implements the interface
• Each class that implements an interface must provide
the definitions of all methods declared in the interface
public class SomeClass implements Comparable {…}
Interfaces
public interface PDUserInterface {
/** method that processes user command
@param thePhoneDirectory The PhoneDirectory object that
contains the data to be displayed and/or changed.
*/
void processCommands(PhoneDirectory thePhoneDirectory);
}
Note the Javadoc comments!
<<interface>>
PDUserInterface
PDConsoleIO
PDGUIO
processCommands()
processCommands()
Components of PDApplication
Analysis (continued)
• Refinement of class diagram
Refinement of phone Directory Application Class Diagram: revision 1
Closed diamond:
“composition”
The component
does not have
independent
existence.
At this point, two abstract data types are identified
• PDUserInterface
•PhoneDirectory
Design of an Array-Based Phone Directory
• Next, we identify all major classes and interfaces that will be part of
the problem solution and describe their interaction.
• PDApplication: Contains the main method.
• Instantiates a PhoneDirectory object and loads the initial directory.
• Creates a new PDUserInterface object
• PDUserInterface (and classes that implement this interface)
• Accepts command from the user and calls appropriate methods
from the PhoneDirectory.
• PhoneDirectory (and classes that implement this interface)
• Will need a DirectoryEntry class
• We also need classes from Java API to perform I/O
Design of an Array-Based Phone Directory
• Identify data fields for classes and design algorithms for
their methods
• In UML class diagrams
• + sign next to a method or attribute means it is public
• - sign next to a method or attribute means it is private
• Classes to design include:
• PDApplication class
• PDConsoleIO class (or PDGUIO class): implements the
PDUserInterface interface.
• ArrayBasedPD class: implements the PhoneDirectory
interface. Will contain an array of DirectoryEntrys.
• DirectoryEntry class: contains a name/number pair.
Design of an Array-Based Phone Directory
(continued)
Open diamond “aggregation” means
DirectoryEntry is a component of
ArrayBasedPD but can be associated
with other objects as well.
Design of an Array-Based Phone Directory
(continued)
Design of an Array-Based Phone Directory
(continued)
Design of an Array-Based Phone Directory
(continued)
Designing the Array-Based Phone Directory
(continued)
•
Provide algorithms (in pseudocode) for all the methods
Algorithm for addOrChangeEntry
Input: name and number
1. Call internal method find to see whether the name is in the
directory
2. if the name is in the directory
3.
Change the number using the setNumber method of the
DirectoryEntry
else
4. Add a new entry (name, number) using internal method add
5. Return null.
Designing the Array-Based Phone Directory
(continued)
Algorithm for lookUpEntry
Input: name
1. The PhoneDirectory object uses its internal find method to
locate the entry
2. if the entry is found
3.
DirectoryEntry’s getNumber method retrieves the
number, which is returned to the caller.
else
4. Return null.
Designing the Array-Based Phone Directory
(continued)
Algorithm for find
Input: name
1. for ( i=0; i< size; i++ )
2.
if theDirectory[i].getName() is equal to name
3.
Return i
else
4. Return -1
Designing the Array-Based Phone Directory
(continued)
Algorithm for add
Input: name, number
1. if (size >= capacity)
2.
allocate a new array whose capacity is twice the current array
using the internal reallocate method.
3. Create a new DirectoryEntry object with the given name and
number, and place it at index size of the array (first empty
location).
4. Increment size
Implementing and Testing the Array-Based
Phone Directory
Design of an Array-Based Phone Directory
(continued)
These are private methods used
to help the public methods.
Homework
• Carefully study section 1.6 and 1.7 (Implementation of
Array-Based PhoneDirectory and GUIs)