Project Deliverables

• This week– Sequence diagram(s)– User interface design (mock-up)– State machine diagram for the user interface– Revised specification

• Next week– Test plan

Implementation

Class Skeletons

Class Skeletons

• This is the start of the coding phase of system development

• Skeletons can be written in the target programming language or pseudo-code– The decision really depends on

• Knowing (or not knowing) the target language• Knowing (or not knowing) who will do the

programming

Class Skeletons

• They’re really just a formal structure for documentation purposes placed on top of the code you are writing– Written by the designer– Provide original designer’s insights/motivations– Useful when the designer isn’t the programmer– Most useful when the designer isn’t the maintainer

• Individual project managers may have their personal style preferences– Style should be consistent across all programmers

on the project

Class Skeletons

• Should consist of at least these sections:– Roles– Information maintenance– Attributes – Constructors/destructors– Methods

Roles

• Behavior of the class within a specified context

• In a particular situation, what does the class provide?– May partition the class into functionalities

that can be designed or maintained independently

Information Maintenance• Specifies when objects of a particular

class type are created and deleted– Not all classes/instances will be used

throughout the entire execution of the system

• Note that this information comes from the Sequence Diagram

– This section is especially important for resource management

Attributes• Declaration of member variables

– Brief statement of what the variable will be used for– If the variable represents a measured value, specify the units of the

measurement– If the variable stores information in a specific format, specify it– If the variable has a “legal” range of values, specify it– If the variable has dependencies on other variables, specify them

• Two explicit sections– Instance variables

• Hold data specific to an instance of the class• Non-static member variables

– Class variables • Hold data common to all instances of the class• Static member variables

– Group all variables of a given type together to improve readability

Constructors/Destructors• If multiple constructors are provided

they should be grouped together– Specify the types of initializations or default

assumptions made by each constructor

• If a destructor/finalizer is provided it should be right after the constructors– Specify any clean-up activity performed

Methods

• Three distinct groups– Public – those available to the outside world– Private – those available internally (helper methods)– Protected – language dependent– Grouping by access will make the code more

readable for anyone not involved in the original coding

• Two distinct sub-groups within each group– Non-static member functions– Static member functions– Again, grouping leads to readability

Skeleton Example (one way to do it)public class Patron{

// Class semantics and roles:// Library patrons function in two primary roles,// as researchers who use index, reference, and database// materials and as borrowers of loanable resources

// Information maintenance:// Creation: New patrons are introduced into the system// by library staff when presented with a library// membership application or from information retrieved// from a web-based application form.// Deletion: Patrons are removed from the library database// 3 years after their membership has expired

Skeleton Example (cont.)

// Private instance variables:private String name; // name of Patron in

// <last-name, first-name, MI> orderprivate long PatronID; // Patron’s library identification

// number sequentially generatedprivate long homephone; // Patron’s home phone number in

// 11 digits (xxx)yyy-zzzz stored as// xxxyyyzzzz

private Date memberDate; // date of first membership in// mmddyyyy format

private Date expireDate; //date membership expires in// mmddyyyy format

private List resourceList; // Object reference to Patron’s// list of checked out resources

private Address homeAddress; // Object reference to// patron’s home address

Skeleton Example (cont.)

// Public instance variables:

// Private class variables:private static long nextPatronID; // keeps track of the

// next patron membership ID to// be assigned

// Public class variables:

Skeleton Example (cont.)

// Constructors:public Patron(String name, long homePhone, Date memberDate,

Date expireDate, String street, String city, String state, long zip)

{ // TODO List:// PatronID = getnextPatronID()// Create an Address object initialized with street,// city, state, and zip// Create Date objects for membership data and// expiration dates initialized with memberDate and// expireDate.

Skeleton Example (cont.)

// Precondition: Library database can accept another// entry and memory allocation succeeds// Postcondition: Library database will contain another// Patron and Address entry

}

// Destructors/Finalizers:~Patron(){ // Precondition: Patron object is not null // deallocate any memory allocated by the constructor

// or other nonstatic methods}

// Public static methods:public static long getnextPatronID(){ return nextPatronID; nextPatronID++;}

Skeleton Example (cont.)

// Public static methods:public static long getnextPatronID() // controlled access { return nextPatronID; nextPatronID++;} // to patron ID

// Private static methods:

Skeleton Example (cont.)

// Public nonstatic methods:public boolean validatePatron(Date expire){ // precondition: expireDate is not null

expire = expireDate; // pass expiration date back to // calling function via parameter // list

// if expireDate <= Today return false// else return true

}

public boolean checkout(Resource resourceID){ // precondition: resourceID points to a legitimate // Resource object that is available for checkout // postcondition: if resource list is null, one is // created, otherwise a new Resource reference is added // to the patron’s List of checked out resources}

}

Goals

• Keep in mind that the goal is to provide readable code– Readable code will reduce the chance of introducing

bugs during both initial coding and maintenance phases– Readable code will make it easier to detect bugs that

find their way in

• It’s easy to skip skeleton development but someone usually pays for it later on down the road

• Might as well practice good habits

End Notes• Much of the “style” presented is my own preference – you may

or may not agree with it• The key is to develop a style and stick with it

– No matter who’s style you follow, you should (must?) provide the information

– CONSISTENCY COUNTS• IF you know the target programming language you may use it

for developing skeletons– If using Java then you may as well use javadoc style– doxygen is an open source version for various languages

• Those teams with multiple programmers have an inherent checks-and-balances system with respect to style

• Those teams with a single programmer must use other team members (non-programmers) to perform the stylistic checks-and-balances

Where Does This Get Us?• We’ve started the process of writing

code

• We’ve started the process of documenting the code

Implementation

Implementation

• It’s time to start turning out code!

• In doing so, a couple of issues arise– Configuration management– Coding

Configuration Management• Goals of configuration management (CM)

– Identify change– Control change– Ensure proper implementation of change– Report change

• In this context “change” refers to alterations in the original, agreed upon specification

• Another goal of CM is to track progress (which is another form of change)

• The two are separated because “change” is much more difficult to deal with than is “progress”

Identifying Change

• Change is going to happen– Market conditions change

• Seasonal• Competition• Timing in general

– Customer needs change• As their understanding of the product/market increases

– Team structure changes• Personnel get pulled off• Personnel get put on

– Business resources change• Budgets shrink/grow• Time lines shrink/grow

Controlling Change

• Given that change is going to happen, we’d like to make it as painless as possible

• Uncontrolled change has the potential to sink a project

• Controlling change requires both manual and automated systems working together

Controlling Change

Identify Need

Request

Evaluation

Report

Decision

Implement

Create Baseline

approved

No Action

denied

Proper Implementation

• Once the change is approved, the implementation must follow all software engineering practices– Formal design and review procedures– Formal system test procedures (regression

testing)

Report Change

• After implementation, the change procedure must be audited– Did the change request pass all proper

channels?– Were proper S/W engineering practices

adhered too?

Tracking Progress

• Status reporting

• Baseline generation

Status Reporting

• Regularly submitted reports– What happened?– Who did it?– When did it happen?– What else was/will be affected?

• Reports may be written (classical S/W engineering) or oral (agile methods)

Baseline Generation

• When you have a working (albeit incomplete) system you should make a copy and hide it away in a safe, dark corner where no one can get at it

• This way any progress or change that goes awry can be easily rolled back

Configuration Management Tools• Various semi-automated tools exist for aiding in

the performance of all of the aforementioned tasks– The provide mechanisms for– Version identification– Version control– Auditing– Reporting

• But, the tools are only useful when used properly!

Configuration Management Tools• Computer Associates AllFusion (used to be

CCC/Harvest?)• Rational (IBM) ClearCase• Open source Concurrent Versions System (CVS)• Serena ChangeMan (used to be Merant PVCS?)• SourceForge• Microsoft Visual SourceSafe• SubVersion• Perforce

Codingclass Shape {

private int xPosition; // -- (0,0) is theprivate int yPosition; // upper-left

// cornerprivate int area; // -- pixels^2private int perimeter; // -- pixels

// -- accessorspublic int GetX() {…}public int GetY() {…}

public int GetArea() {…} public int GetPerimeter() {…}

// -- mutatorspublic int SetX() {…}public int SetY() {…}public int SetArea() {…}public int SetPerimeter() {…}

// -- message handlerspublic void ComputeArea() {…} // -- sets area member to

// default, should be // overridden in derived// classes

…

+GetX() : unsigned long+SetX(in _x : unsigned long = 0)+GetY() : unsigned long+SetY(in _y : unsigned long = 0)+GetArea() : unsigned long+SetArea(in _a : unsigned long = 0)+GetPerimeter() : unsigned long+SetPerimeter(in _p : unsigned long = 0)+ComputeArea()

-xPosition : unsigned long = 0-yPosition : unsigned long = 0-area : unsigned long = 0-perimeter : unsigned long = 0

Shape

+ComputeArea()

Square

Codingclass Square extends Shape {

…// -- message handlerspublic void ComputeArea() {…} // -- overrides base class

// method…+GetX() : unsigned long

+SetX(in _x : unsigned long = 0)+GetY() : unsigned long+SetY(in _y : unsigned long = 0)+GetArea() : unsigned long+SetArea(in _a : unsigned long = 0)+GetPerimeter() : unsigned long+SetPerimeter(in _p : unsigned long = 0)+ComputeArea()

-xPosition : unsigned long = 0-yPosition : unsigned long = 0-area : unsigned long = 0-perimeter : unsigned long = 0

Shape

+ComputeArea()

Square

Big Bang Method

• Code all the modules individually

• Integration happens when all module coding is complete

• Basic recipe for disaster

• Essentially how beginning programmers do things– Because that’s how they’re taught

Top-Down Method

• Start by defining the “architecture” defining modules– Corresponds to the “product design” items we

studied– The “main” function

• Provide “stub” or “dummy” classes and methods for all other functionality

• Fill in details with a “refinement” approach• A good approach when the details of the

design are not fully worked out– Allows you to get something running while design

is ongoing

Bottom-Up Method

• Start with the detailed classes and methods• Work your way up to the architecture• A question arises…

– How do you test the detailed classes and methods?– Answer: You create test drivers for each class/module.

• A good approach when the details are critical and require a lot of testing prior to product release

• Also a good approach when you have nervous designers…like me

Top-Down/Bottom-Up Method• Top-Down and Bottom-Up are both Incremental approaches– Contrary to the Big-Bang Method

• Thus, they are compatible with one another

• In practice, a combination of the two approaches is applied

• Results in the Threads method

Threads Method

• Define a minimal set of modules required to perform a system function– May correspond to a Use Case

• As one thread is completed it can…– go to the customer for feedback– go into testing

• …while the next one is being developed

Implementation Plan

• The most important thing is to have a plan!– Plan for coding– Plan for unit testing– Plan for integration– Plan for integrated testing

Programming Style

• Very subjective topic

• Goals are– Simplicity– Readability

• General rule– Consistency– Uniformity

These will not only support implementation, but maintenance

Consistency

• Placement of “{” is not consistent

• Constant comparison format is not consistent

if (x == 10) {y = 17;

}…while (17 == y) {z = z + 5;

}

• Consider the following code fragment:

Variable Naming

• Name selection is inconsistent

• Use of upper/lower case is inconsistent

int tempA, tempb;int m, n, o;int localarea;int globalAreaInt UniversalArea;

• Consider the following declarations:

Variable Naming

• Variable names are not descriptive [unless they have some special, acceptable meaning in context]

• Variable name switched from descriptive to downright annoying after 3 words

• Consider the following declarations:

int a, b;int variableToHoldTheValueOfTheArea;

Naming Conflicts

• Use package (Java), namespace (C++), source/header file combinations (C and others) to avoid naming collisions

• Use predefined naming conventions– e.g.

• Control department: cont_<variable name>• Security department: sec_<variable name>• Image Processing dept.: ip_<variable name>

Constant Values

• Thou shall not type numbers into your code

• Instead use – final values (Java)– const values (C++)– #define values (C)

Side Effects

• If functions (methods) must modify values outside their “immediate scope” (i.e. global values), make the situation clear through documentation

• If functions (methods) modify their parameters (pass by reference) make the situation clear through documentation– This is especially important in Java (use of

Object class and type casting)

Avoid Ambiguity

• This is perfectly legal but scary public class AClassName {

public AClassName () {

}}

public class Ambiguous {

public static void main(String[] args) {Ambiguous ambiguous = new Ambiguous(42);ambiguous.AClassName();

AClassName aclassname = new AClassName();}

public Ambiguous () {

}

public void AClassName () {

}}

• Both a class name and a method name within another class

• Stuff like this can cause problems in inheritance situations

Coding Standards

• Coding standards are created to ensure consistency– Although we may feel that they’re created to make

some meddling micro-manager feel important

• Define them! (they may be defined for you)– Make sure they are

• Useful• Easily adhered to

• Stick to them!• Many IDE’s will define standards for you

– These are usually customizable

Design Patterns

Design Patterns

• Revolves around the “principle of best practices”– i.e. figure out how to do it right then continue doing it that way

• Three basic categories identified– Creational – object creation as opposed to construction

• Factory, Singleton…revolve around “getInstance()”-like methods

– Structural – groups of objects (aggregation/composition)• Adapter, Façade…revolve around wrapping objects within other

objects and interfaces

– Behavioral – flow control and communication among objects• Iterator, Visitor…revolve around traversing through sets of

objects and passing information between objects

Basic Layout

• Pattern-name– So that you can talk about it without doing a lot of hand

waving (design at a high level of abstraction)

• Problem– Describe the problem that this pattern is addressing

(solving…we hope)

• Solution– Describe how this pattern addresses (solves) the specified

problem

• Consequences– Trade-offs (pros and cons) involved in utilizing this pattern

References

References

• Various books on this topic– Effective C++– More Effective C++– Effective STL

• All by Scott Meyers

– Applying UML and Patterns – Craig Larman– Large-Scale C++ Software Design – John Lakos– The Mythical Man-Month – Frederick P. Brooks, Jr.– Design Patterns: Elements of Reusable Object-Oriented

Software – Gang of Four– etc.

Looking Forward

• This is week eight, meaning we have three more meetings– Week 9 (next week) will be open consulting– Week 10 will be formal design

review/presentation/demonstration– Week 11 final exam, project documentation turned

in