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)

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 thePhoneDirectory The PhoneDirectory object that contains the data to be displayed and/or changed. */ void processCommands(PhoneDirectory thePhoneDirectory); } Note the Javadoc comments!

> PDUserInterface PDConsoleIO processCommands() PDGUIO processCommands()

Analysis (continued) Refinement of class diagram Refinement of phone Directory Application Class Diagram: revision 1 Components of PDApplication At this point, two abstract data types are identified PDUserInterface PhoneDirectory Closed diamond: “composition” The component does not have independent existence.

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)

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)