Welcome to B104 - Murdoch University



Topic 2

Object-Oriented Project Life Cycle | |

• Software life-cycle models

o Waterfall model

o Rapid prototyping model

o Spiral model

o Fountain model

A comparison

• Java Project Life cycle

o phases of development

o coding and documentation for Java projects – standard practice

o Source code version control systems

o Using build scripts for your Java projects

o Contents of a build script (or makefile)

1. Waterfall model

← inherent in every phase is testing

← products of each phase be carefully checked by SQA

← documents (specification, design, coding, database manual, user manual etc) are essential tools for maintaining the product

– client does not see the product until delivery

2. Rapid Prototyping model

• developers should endeavour to construct prototype as rapidly as possible: to determine what the client’s real needs are

← development of product is essentially linear: the feedback loops of the waterfall model are less likely to be needed

← a preliminary working model that has already been built tends to lessen the need to repair design during or after implementation

← helps reduce risks in some areas but provides partial or no answer in some other areas

3. Spiral model

• s/w developers must be skilled at pinpointing the possible risks and analysing risks accurately

• if not all major risks can be resolved at each phase then project may be terminated

← supports reuse of existing s/w

← incorporation of s/w quality as a specific objective

← maintenance is simply another cycle of the spiral

– applicable only to in-house development of large-scaled s/w

– risks analysis costs vs entire project cost – model suitable to large-scaled s/w only

[pic]

4. Object-oriented Life-cycle models

• OO life-cycle models have been proposed that explicitly reflect the need for iteration: one such model is the fountain model

➢ circles representing the various phases overlap (reflecting overlap between activities)

➢ arrows within a phase represents iteration within that phase

← maintenance is smaller, to symbolize reduced maintenance effort when the OO paradigm is used (note: at least 67% of s/w budget is devoted to maintenance)

– may lead to totally undisciplined form of s/w development (team members move randomly between phases and write code without prior analysis or design)

[pic]

Comparison of Life-cycle models

|Life-cycle model |strengths |weaknesses |

|Waterfall model |disciplined approach |delivered product may not meet client’s needs|

| |document-driven | |

|Rapid prototyping model |ensures that delivered product meets client’s|prototypes may be discarded due to |

| |needs |performance, difference in specification |

| | |between prototype and final product |

|Spiral model |incorporates risk analysis in the prototyping|can be used only for large scale, in-house |

| |model |products |

| | |developers must be competent in risk analysis|

| | |and resolution |

|Object-oriented models (eg. fountain model) |supports iteration within phases, parallelism|may degenerate into CABTAB |

| |between phases | |

(CABTAB: code a bit, test a bit)

Java project life-cycle

Java is a OOPL. Java project life-cycle can therefore be modelled as the fountain model given above.

The phases of project development

o Requirements gathering

▪ Collecting requirements is usually a multi-step process

▪ Requirements should be documented in the form of system white papers then refined to more complex documents

o Logical design, requirements development, and prototyping

▪ Partition the system into conceptual components and specify their behaviour

▪ If the system has transactional behaviour then transaction partitioning should be addressed

▪ Output a list of system requirements

▪ A prototype or proof of concept should be developed if possible

▪ UML (Universal Modelling Language) that describes relationships and interfaces of classes should be used

o Detailed design

▪ Specify a system architecture

▪ May separate the project into versions

▪ Document all design decisions that require schema changes

o Walkthroughs

▪ Review and critique (group session) a design or program – to

• disseminate knowledge about a design

• discover logical errors or design flaws

• discover incompatibilities between subsystems being developed by different team members

• verify adherence to coding or design standards

• boost morale and develop team spirit

o Testing

▪ Ensure documentation and s/w match and that both match the specs

▪ Allocate to engineers bug reports and change vehicles (CV) (meaning change notices (CN) and change requests (CR))

▪ May use a Java-based automatic testing tool (eg. See )

o Acceptance testing

▪ is performed by the client

▪ showing the client early builds of system helps prevent (or reduce) deviations from expectation of product

Coding and documentation for Java projects – standard practice

• Java packages:

▪ a package should serve a well-defined purpose (which should be clearly documented)

▪ assign one package to one single developer

▪ sub-packages can be created if necessary to allow for delegation

▪ use separate packages for reusable components (eg. the interfacing to an external service for credit card transaction and financial trading service is a reusable component)

• Java interfaces

▪ Java interfaces define roles

▪ The roles of the elements of a system are the first things that get defined

▪ using interfaces also helps to decouple the parts of a system

▪ interfaces serve as the specification that subsystems use to communicate

• Java package membership

▪ what classes and what interfaces should be in the package?

▪ which class(es) should implement which interface(s)?

▪ subclass relationship?

▪ composition of each class

▪ cardinality of each member in a class

▪ UML diagrams to outline the relationship of classes

▪ the characteristic of each class

o eg. should the class be final (ie. not extended by subclasses)? should it be abstract (may not be instantiated without subclassing), what scope or accessibility should it have (public? friendly?)

o members and methods of the class: should a specific member/method be private? protected? public? static? should a method be abstract? why? should a method be native (ie. implemented by non-Java code) for efficiency purpose?

• Use javadoc commenting convention in the java code; consider embedding diagrams via HTML tags

• Follow standard naming convention for packages, classes, interfaces, methods

• Keep source and class files in separate directories

• Use makefile (see later) and a build configuration tool

• Use a source control (versioning) system for everything that is not automatically generated

• Be consistent with indentation and where to put braces in the java files; do not mix tabs and spaces

• Do not consume stack traces. If you make an exception, throw it from the same line

• Distinguish between

o Non-runtime exceptions (eg. caused by user input errors)

o Runtime exceptions (should be avoided!)

o Errors (eg. caused by incorrect system configuration)

• Make all reusable classes implement Serializable, unless there is a specific reason not to

• Explicitly close or dispose of resources when not in use (eg. server connection)

Source code version control systems

• S/w development is usually supported by the use of a source code repository which provides the added feature of versioning, so that historical versions or snapshots can be reconstructed in case the current version is found to be flawed

• There are many kinds of “source code control” systems: the Unix tool SCCS (Source Code Control System) was one of the first widely used source code repositories; CVS is the popular descendant of SCCS

When using a source code version control system you should

• only check in code that compiles.

• synchronise before you check-in. You can write a script to implement the check-in process. This process needs to

o briefly lock the repository when you update the repository

o compare the modification dates of all files you currently have for read-only access

o if none of the files for read-only access have changed, check in all modified files, abort otherwise

o release the repository lock

• if external teams are involved in the project and their class files (read access only and not to be changed by the on-site team) are to be integrated with the project, synchronisation with your own s/w builds is still required

• A similar situation arises when third-party products are used in the project

CVS (Concurrent Versioning System)

• To check in source files the first time (“import”), type cvs import myPackage vendorVer vendorTag

• To check out source files for modification, create a temporary working directory and change to this directory, then type cvs checkout myPackage

• To check in (“commit”) updated source files Hello.java and Greetings.java, type cvs commit Hello.java Greetings.java while in the working directory

• To roll back to the latest version of Greetings.java:

del Greetings.java # delete the version in the

# working directory

cvs update Greetings.java

• To view the difference between the latest version of a source file (say Hello.java) in the repository with the updated version, type

cvs diff Hello.java

For more details on other CVS commands, see cvs.doc

Using build scripts for your Java projects

• Any s/w product larger than a few files should have a set of automated procedures for compilation, testing, and preparation for deployment.

• A build script is a file that contains commands for compiling the source files, archiving them, etc.

• A build script is commonly referred to as a makefile.

• Build scripts are not platform-independent…

o can be solved partially by writing a file path conversion script or program.

o unfortunately arguments can be complex, eg. class paths on NT are separated by colon (:) while class paths on Unix are separated by semicolon (;).

• Program required to run a build script:

o Unix: make or gnumake

o Windows: Borland’s make.exe or Microsoft’s nmake.exe

• Standard naming convention for build scripts:

o Unix: makefile or Makefile

▪ When typing make , the system would look in the current directory for the file named makefile and then Makefile (if file makefile not found).

▪ If a non-standard file name (say A1.mak) is used then you must use the command

make -f A1.mak

o Windows: mypackage.mk or MyProgs.mk (ie. use the .mk extension)

▪ To execute the commands in the build script MyProgs.mk, type:

nmake –f MyProgs.mk or

nmake /f MyProgs.mk

(substitute nmake with make above if you use Borland’s make.exe)

• For Java projects, you should specify where to place the class files.

• You should specify file dependencies in a build script so that only those source files that have been modified need to be recompiled.

• The entire product to be deployed may consist of multiple packages. It is therefore a good practice to have a build script for the entire product being constructed as well as for each package.

• Should incorporate appropriate switches (so that they can be conveniently used for quick compilation or compilation with optimisation, for instance).

Contents of a build script (or a makefile)

A makefile consists of

• Macros: for selecting commands, defining options and environment variables, eg.

CC = gcc # select the gcc compiler

CFLAGS=-O # CFLAGS: options macro for C compiler

CPPFLAGS=-g # CPPFLAGS: options macro for CPP compiler

CXXFLAGS=-O # CXXFLAGS: options macro for CXX compiler

HOME=/home/du # define the environment variable HOME

• Description blocks: a description block is a dependency line optionally followed by a commands block. Description blocks have the following form:

targets…: dependencies …

command1…

command2…

eg. a description block for building a jar file

MyProg.jar: MyProg.class File.class

jar cvf MyProg.jar MyProg.class File.class

del MyProg.class File.class

• Commands: commands are defined within a description block and must be indented (see above). Other features such as wildcard characters (* and ?, for instance) and dynamic macros for rule inference.

|dynamic macro |meaning |

|$* |the base name of the current target, derived as if selected for use with an implicit rule |

|$< |the name of a dependency file, derived as if selected for use with an implicit rule |

|$@ |the name of the current target |

|$? |the names of dependency files that are newer than the target |

|$** |all dependent files in the dependency list |

You can also specify one or more command modifiers preceding a command, optionally separated by spaces or tabs:

|command modifier |action |

|@command |prevents display of the command |

|-[number]command |turn off error checking for command |

|!command |Executes command for each dependent file in the dependency list if the command|

| |uses $** or $?. |

• Dot directives: for defining options for commands. Dot directives should be specified outside a description block, at the start of a line. Dot directives begin with a dot (.) character and are follow by a colon (:). Dot directives are case sensitive and are in uppercase, eg.

o to list file name extension for inference-rule matching:

.SUFFIXES: .java .class .jar

o to ignore non-zero exit code of command from here onward:

.IGNORE:

o to suppresses display of executed commands:

.SILENT:

• Comments: comments are preceded by the # character

• Inline files: An inline file contains text you specify in the makefile. Its name can be used in commands as input. The file is created on disk when the command that creates the file is run. The syntax for specifying an inline file in a makefile is:

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download