Lecture Outline:

Week 1 Object Oriented Concepts, terminology

Basic elements of Eiffel Programming

Week 2 Systematic approach to software construction

Client-Supplier relationship,

Assertions, Exceptions

Week 3 Use of Eiffel Libraries,

Inheritance, Polymorphism, Persistence

Week 4 OOSE, Inheritance, Polymorphism, Persistence (contd)

Week 5 OOSE, Open-Closed Principle, Typing and Binding,

Genericity, Deferred Classes

Week 6 OOSE, Multiple Inheritance, Use of Eiffel Libraries

Week 7 Declaration by association, Constants

and Shared Objects

Week 9-10 More aspects of Eiffel, OOSE

Week 11 Revisit Reuse

Week 12 Class Test (10%)

Week 13 Object oriented Programming System - Revision

Final Examination 40%

Laboratory Sessions:

1 Familiarise with ISE Eiffel 3: Environment

2 Object orientation. Classes and responsibilities:

Bank and Account example, pursued further in the

later tutorials; Creating Objects, SA_TOPS

Defining ADTs; Assertions and Invariants; Using

Classes; reading Class specifications.

Defining Classes; feature = attribute /function/procedure; building systems;

Introduction to Assignment, SA_TOPS

3 Using Eiffel Libraries - Collection of Objects,

Inheritance/Polymorphism, SA_TOPS

Inheritance/Polymorphism, Persistence (contd)

Delineation of tasks by group members and

signing a contract with the tutor (supervisor)

(Refer to "Notes on Deliverables"), SA_TOPS

4 Final Submission of Assessment Folder for Bank exercise

Work on Assignment

- Test strategy for scenario 1 - process/product improvement

strategy in action

5 Class Presentation by student groups -

On Testing scenario 1 of assignment

6 Work on Scenario 1 Demo & Documentation

MID SEMESTER (EASTER) BREAK 10^th Spril - 17^th April 1998

7 Student group demo to the lecturer/tutor

Scenario 1 Due - Demo & Documentation

8 -9 Feedback session

Work/ Assistance on Assignment (contd)

10 Student group demo to the lecturer/tutor

Scenario 2 Due - Demo & Documentation

11 Feedback session

( SFT2021 students do not need to attend week 12 but must

attend week 13 tutorials for their final assessment)

12 Refinements (if any) submitted for Ass.

13 Final assessment on assignments

PROGRESSIVE ASSESSMENT: Students must show their tutorial work at the end of each session or the beginning of next session and be prepared to answer questions related to the task completed. You are also required to build your assessment folder on a weekly basis. This must contain hard copies of class listings and other relevant information such as contractual responsibilities of group members, charts and test data. Tutors assess & fill in the the Student Assessment - Tutorial Ongoing Profile Sheet (SA - TOPS) before you commence the next week's work. They give you a copy of your profile, the following week. The grades in the profile reflect your understanding of the tutorial tasks and gives us feedback on learning/teaching on an ongoing basis. Make sure you file the SA - TOPS sheets in your assessment folder. Your folder submissions commence from week 3. The quality and presentation of the work submitted is taken into account in the final grade for the assignments.

Administration

Eiffel 4 in the Pentium Labs from semester 1 1998

You will be working in groups of 3 for your assignment. As compiled Eiffel programs are very large, you will have to delete the object files of completed work as you proceed through the tutorials and the assignment.

Each group must maintain a folio of work. Work completed during the "BANK" tutorial exercises will result in the creation of sets of Eiffel classes in separate directories. The completed work from tutorial 2 should be copied into a new directory to form the basis for tutorial 3, etc.

rm -r EIFFELGEN is a command you can use within a directory to clear it of all non-source code.

A Bank maintains a set of Customer Accounts. As the bank has just opened, it offers only basic 'On Call' Accounts. Customers may own many accounts. No overdrafts are allowed, and no interest paid. No transaction statements are provided at the moment, but it is intended to provide them in the future. The only customer information maintained by the bank at the moment is the name of each owner.

Design a system to implement Bank Account Processing for a Bank.

1. Identify the objects or classes in your system. It may help to think of them as entities.

2. Define the responsibilities of each class in your system.

3. Try to identify the relationships between the classes - what other classes are involved in assisting a class to carry out a particular responsibility?

4. Describe facilities or routines which will allow customers to deposit and withdraw amounts from their account, and to request an account balance.

5. Where would you place facilities for printing out:

Bank details

Customer details

Account details?

6. What does it mean to create an instance of a class?

Whose responsibility is it to create account and a customer objects?

Whose responsibility is it to:

perform an account withdrawal?

alter the address of a customer?

check if a withdrawal amount is within the credit limit?

7. For each object (class) you have defined, describe:

Its name, Its responsibilities

For each responsibility, collaborators - other classes it interacts with to fulfil a responsibility (if any).

1.Create a sub-directory 'bank-dir2' under your $HOME directory.

Using your favourite editor, enter the text below into a file called bank.e in directory 'bank-dir2':

class BANK

creation make

feature

make is

-- Create an instance of Bank.

do

io.putstring ("Welcome to the Bank")

end -- make

end -- Class BANK

2. Launch eiffelbench (ebench&). You will be prompted to select ACE, choose it and a new window will be created. Just fill in the ROOT line with the name bank (in lower case), and note that the UNIVERSE line lists the directories containing the Eiffel library clusters kernel, structures and support. Save the changes.

3.Click on the Melt button in the system window to produce an executable file called bank. Do not Freeze or Finalise as we will run out of diskspace. The executable is created in a subdir. two levels below the current dir.containing the source files. Change dir. to EIFFELGEN/W_code

4.Execute the program by typing bank from W_code subdir. This will display on your screen the message

Welcome to the Bank

5. Modify bank.e as shown below. Replace the comments with the appropriate requests to ACCOUNT's features.

class BANK

feature

make is

-- Create an instance of Bank

do

io.putstring("Welcome to the Bank");

io.new_line;

-- create an account object and store its reference

-- in a BANK attribute called account_1

-- open account_1

-- deposit $200 in account_1

-- if there are sufficient funds,

-- withdraw $300 from account-1

-- display account-1's details

end -- make

end -- Class BANK

6. Compile your system and test it by typing bank.

7. Add another attribute, account_2, to class BANK.

Create a new instance of class ACCOUNT and assign its reference to account_2. Test bank by asking account_2 to perform some deposits, withdrawals and to display itself.

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

1.Create a new directory, bank_dir2a.

Copy the files account.e and bank.e from directory bank_dir2 into bank_dir3.

In bank_dir2a, change class BANK to allow for user interaction in creating, setting up, depositing, withdrawing and displaying an account.

Use MY_FILES for terminal I/O and MENU for manipulating menus. Both of these classes are available for your use.

Create a simple menu interface to make processing easier:

1. Create and set up an account

2. Deposit

3. Withdraw

4. Display

5. Exit

NOTE: Run Eiffelbench in the foreground so that it can read stdin

Introduction to Assignment 1 _

Collections of Objects

1. Create a new directory, bank_dir3. Copy the files Ace, account.e and bank.e from directory bank_dir2a into bank_dir3.

2. We would like to maintain some kind of a collection or list of accounts, indexed by the account number. Browse library class HASH_TABLE to understand how this class works. Discuss how HASH_TABLE would be used to store and access a list of bank accounts. Refine class BANK to provide for access to many accounts.

3. In bank_dir3, change class BANK to allow for the creation and maintenance of many accounts, using HASH_TABLE as the container class for storing accounts.

4. Add a feature display to BANK which will display all the accounts in the hash_table. Refer to Eiffel sample code to help you code the display routines.

5. Start on Inheritance/Polymorphism exercise

. Inheritance/Polymorphism

. Persistence

1.Create a new directory, bank_dir3a.

Copy the files Ace, account.e and bank.e from directory bank_dir3 into bank_dir3a.

2.The bank has decided to provide cheque accounts with overdraft limits,

How does a Cheque account differ from an On-call account?

Define the ADT of a cheque account

What features are common to both On-call and Cheque accounts?

What features are implemented differently for On-call and Cheque accounts?

Define an abstract, deferred class ACCOUNT. Define 2 sub-classes of ACCOUNT, ON-CALL and CHEQUE.

3.Change BANK to allow the user to decide at run-time what kind of new account is to be created. Bank.e will have two local attributes (on_call_account and cheque_account) as well as an_account. Depending on the user's response, create an instance of the appropriate specialised type and assign it to an_account.

Test your code by asking the newly created account to print itself out.

4.Change class BANK so that is uses STORABLE, and as described in lectures, make BANK and all its dependents persistent.

General assistance with the Assignment .

Comparison of Banking system and the assignment.

Assignment

Refer to the Case study description for this assignment.

You are required to produce UML diagrams as part of O-O design and implement the system in Eiffel.

The Programming assignment is divided into stages. It is strongly recommended that you also implement the project in stages. As object oriented system development allows you to 'program by refinement', you will find this involves no extra effort, and gives you achievable milestones. Each stage must be stored on separate directories. A hard copy of the code and documentation is required for each stage.

To be Handed in:

UML diagrams.

Class listings plus other documentation as specified. It is strongly recommended that you keep in separate directories the classes marking the achievement of each stage of the project.

The documentation for the system is checked progressively and the final documentation is due on week 13. More specific submission details are with the Assignment handout.

Documentation must be produced in duplicate: one for the lecturer and the other to be submitted to the tutor. Copy your documentation on to the disc to be provided by the lecturer for ongoing software engineering measurement experiments.

Assessing Group Work _

SFT3021 Assignment _

What is being assessed?

technical product ( to be handed in and demonstrated by the group)

interteam member assessment (monitored by the tutor)

group process (monitored by the tutor)

individual aspects of work (documented as set out in the

problem solving guide)

tutor assessment (ongoing assessment)

grading

Group Process

Reflection on the process of working as a team as part

of the thing assessed.

Be assertive. Community services Counselling Staff at

Monash can help in communication skills.

Group members must understand all parts but can

undertake to complete their set tasks.

It must be an ongoing group that communicate rather than meet

once at the commencement of the project and at the end.

Be aware that some members may wait for directions from

the leader of the group.

A group member may have to sacrifice individual desires for the

good of the group.

Problem solving guide

Step 1. Identify needs.

Step 2. Brainstorm creative options.

Thing up ways of meeting the needs spelt out in (1).

Write them all down (citing whose ideas they are) and

keep searching for more ideas.

Do not criticise or judge them yet.

When all the ideas have been jotted down, circle the

promising ideas.

Step 3. Evaluate solutions.

Step 4. Choose solution.

Step 5. Planning and taking actions by

Whom? What? When?

Step 6. Checking results.

Testing Object-Oriented Applications

Testing of an application is undertaken to ensure that software functions correctly and consistently. The testing procedure includes the development of a suite of test cases, each of which is intended to test a particular element of the application. The test results are analysed to check the correctness of the software.

The testing phase in a software development involves unit testing and integration testing. Unit testing is concerned with testing individual modules. It checks the correctness of the algorithms implemented in the module and conformance of return values to expected results. Integration testing deals with how well the single units integrate and work together. In O-O paradigm, we test at different levels. Although we test the individual features (methods) within a class, we are more interested in class testing, which combines some aspects of unit testing and integration testing.

Let us focus on testing classes and their features and leave acceptance testing and system testing issues for now. The developer of a class has to check the outcome of a test by comparing the results of executing a feature (method) with a set of test cases against expected results.

The test suite for a class will consist of cases chosen to satisfy specific testing requirements.

Class testing is the initial testing phase in the class life cycle. A class may be reused as a component in a variety of applications over time. It must be tested in isolation to check its validity as a unit.

The test suite for a class can be defined by first testing each of the routines (methods) in it. The suite is then extended to include test cases that provide interaction testing in which methods that call other methods in the class and those that access the same class data are tested together. Use the preconditions and postconditions in the routines to guide you in the development of test cases for the individual methods.

Class testing includes two forms of testing: specification-based and program-based testing. Specification-based testing treats the class as a black box. This is intended to determine whether the class is performing according to its specification. For example, specification-testing for a Stack Class should ensure that the LIFO policy is being enforced. Program-based testing considers the implementation of the class. The testing is intended to check the correctness in coding. For example, in the Stack class, the testing must have test cases for all the methods to check for its appropriate actions.

The specification-based testing includes class specification and method specification.

Class specification. It includes the specifications of all the methods in the class and a broader statement of the concept that the class is intended to represent. For example, a Stack class would include specifications for the method push and pop, but these specifications do not convey how these operations behave when working together in a class. The specification for push would describe how a value is added to the "top" of a stack but would not say anything about deletions. The specification for pop would not state how the deleted item had been inserted on a stack. Only in the class-level specification is the LIFO idea represented. Methods lack support for the full semantics of a class.

The specification of a class are the exported features of class. Subclasses will see an expanded interface which includes both the public and protected areas. All the features of a class (exported and secret) must be tested.

Method specification. The specification for a method is defined by its precondition and postcondition as well as by its signature. Based on the preconditions, test cases are selected to produce outputs.

The program-based testing of a class will test all its methods and will test the class as a unit. The test plan will consider the coding in individual methods in isolation and then consider the interaction between methods. Each method can be tested over its domain of inputs but the interactions between methods need to be tested before testing is adequate. The class must be exercised over a representative set of its states.

Methods in isolation. The first level of program-based testing considers each method in turn. Messages sent to other objects are ignored and replaced by stubs that return appropriate values. Test data is selected to ensure adequate coverage of the code in the class.

Methods in integration. This level of testing considers the interaction of one method calling another within the same class (intraclass) and messages from one class to another (interclass).

Testing methods in isolation checks the quality of their implementation but may not highlight any subtle problem of sequencing. Test cases that invoke these interactions are included in the test suite to enable the developer to check that the interaction is handled correctly. Exercising all major states of the class is an important adequacy criterion for this type of testing.

Integration Testing _

Testing a new class also tests the integration of those classes that participate in its definition. is-a, is-part-of, refers-to relations establish dependencies between classes which require testing. They also imply an ordering to the testing of several classes. Test basic classes first, then test classes which use them, and so on using a layered approach. Each layer uses these classes that have been defined and tested as the building block for its representation.

The current testing can be limited to domain testing when a message is sent from the class being tested to an instance of another class which has already been tested. The message is checked to make sure that the actual parameters come from the appropriate domains. Integration testing in OOPS require classes (elements) brought together that were not specifically written for use in the current application. This implies that the coordination between these classes need to be tested. Each class must be tested singly before interclass testing is done.

The structure of the application class definitions can be used to support an approach that reuses test cases from one class to another. Test the base classes which have no ancestors. Reuse existing test cases from the test suites of the parent class(es) in the test suite of a subclass. This technique incrementally develops the test suite for a class based on its hierarchical relationship with its ancestors and is thus termed hierarchical incremental testing. Remember to please consider the complications introduced by the notion of deferred methods and abstract class in not being able to test the method as the implementation is missing or the class cannot be instantiated as it is a deferred class. Another aspect to remember is the notion of secret or private features whose values need to be tested as well.

The hierarchical incremental testing algorithm allows the testing of a subclass to begin with the test cases of the ancestor classes. Develop the test suite for a subclass by noting those parts of the class that are new. Eliminate test cases from the ancestor's test suite which need not be retested. By treating specification, program-based and interaction testing separately, one has three distinct sets of test cases from which to select those that require retesting. Other test cases may be added when new features are defined, either as additions to existing classes or as redefinitions of existing features.

Student Assessment - Tutorial Ongoing Profile Sheet (SA-TOPS) will be used in assessing the project on an progressive basis by monitoring and evaluating the software process followed by the teams and the quality of the products produced for each scenario.

A Project Plan for your Assignment

What and Why

Product Objectives

Functionality (Generality, Capabilities)

Usability (Human factors, Consistency, Documentation)

Reliability (Accuracy, Recoverability)

Performance (Efficiency)

Supportability (Testability, Extensibility, Adaptability, Maintainability)

How

Process Objectives

Design Approach

BON and UML, UML diagrams deliverable,

Presentation in front of the class

Development Plan

Implement Scenarios at a time by assigning various roles to the team members. Roles could vary from scenario to scenario. Regular reviews to check the process and product quality objectives, inspections to discover & remove defects, follow the documention standard given below.

Project Standard

Adhere to design notation standards for UML, coding

standards as prescribed by Eiffel style guidelines, class names and feature names as given in the design document, testing process as outlined in the subject handbook, backup on diskettes

Implementation tactics (Program by refinement with

achievable milestones)

Sequence of deliverables, dependencies between classes,

coordination with team members

Documentation Standard

Gantt Chart for showing Schedules

Contracts to show team members, responsibilities of their

role in planning, design, implementation, reviews -

testing, documentation

For each scenario: Design diagrams, Source code, test plan

and output

Final Documentation with the above details and details of any modification stating why they were necessary

When and How Much

Scenario based Phases

Classes that are included in each phase, Number of Classes,

Class size (Non Commented Source Code lines)

Resources

Time spent by team members on various activities: planning

to documentation and debugging - Detailed breakup of time required.

Be honest as the length of time taken for an activity is not judged for

assessment purposes but for some correlation purposes.

Schedule

Gantt Chart

Issues

Organisational, technical, timing

Driving project (user) goals from a combination of product

One way to track product development is to graph size against time (NCSC versus calendar time). Another way is to track FURPS attributes against time. This graph could be used to emphasise the project (user) requirements during

development and test. An important reliability goal could be to specify how exceptions are handled.

Estimating and tracking team members' effort and schedule tasks to control the project.

Measurements in this category are more process-oriented. Document the time taken by product/activity, defects/ enhancements, counts of remaining defects, calendar time by phase and activity, class size (NCSC). Focus on areas and report where errors/defects appear more often or errors

which take a lot of time to fix. Track deliverables such as classes and operations within classes using graphs of time against number of classes or number of operations.

Project Plan Details

Presentation in Tutorial

- Refer to above sections on

Design Approach

Implementation tactics

Documentation Standards

Note that student teams must make a presentation in the tutorial and submit their initial design that abides by the prescribed process objectives.

Resubmission to any documents presented in the tutorial is possible but should include why the amendment/correction is necessary. A cluster development model which identifies critical subsystems to be developed early on is followed. This is reflected by the scenarios described in the document. Each team will work on a scenario at a time, making sure that each student participates in the coding aspect as well. Follow the development plan and document the outcomes of design/implementation review meetings and other information as suggested in the project tracking details which includes both the product and process objectives.

One of the important software engineering principle is that all the work products of a software development such as requirement models, high level design, low level design, code, test plans and others must all be reviewed using a formal procedure. Michael Fagan instituted this formal walkthru to improve the inspection process and increase the productivity of programmers in IBM in 1972. The inspection process also aimed to improve the quality of the product - software quality. Software inspection is a static testing method and can be applied to all the phases of development. The process is used to verify that the output requirements (exit criteria) of a stage have been met. The project gantt chart shows these work products as milestones and can be used as an objective measure. The exit criteria must be measurable quantitatively: for example, any of the quality criteria specified for the work product must be verified as being met as part of the inspection process and reported as a defect according to the given classification (see below) if defects are found. The defect classification types help the developers/inspectors to identify and classify the defects found during inspection. Inspections are conducted as a peer group formal review of work products at scheduled times. The inspection process must be repeatable and collect various measurement data so that the process can be used to monitor and provide feedback to the teams and encourage best quality practice. Defects were discovered once mainly during the testing phase. Inspections have proven to detect more defects in the product at lower cost than machine testing and requires less resources for rework. The developers must adhere to the inspection process that has been spelt out for a project but may fine tune it to improve the process. Any change to the process must be approved by the project manager (lecturer in our case).

Follow an inspection method during the process of software development by checking for defects at each stage of the product life cycle. Verify the products during their development with your team members to ensure that they conform to the design and are correct. Analyse the results of the inspection to feed back and control the production process and for improving the process by reducing the defect rate. Establish a well structured inspection process with check points which spells out when a product is ready to enter and exit the inspection procedure. Inspection meetings should be formal with the participants coming prepared to identify the defects with all the 3 inspectors of the team: author, moderator and the recorder being present at the meetings. The author has to fix the defects and the verification of the "fix" is conducted and controlled by the inspection process. The moderator starts the session by describing the work product for inspection, the recorder acts as the scribe for the inspection and records the defects on the inspection defect list. The moderator is the leader for the inspection process and should ensure that the time is spent efficiently and focus the effort on finding defects. The inspectors should use the meeting to read the work product, focus on error detection and not for working out solutions. The author's revisions are formally verified in a follow-up inspection process where the rework/changes are verified by checking if defects identified in the earlier inspection have been corrected and the work product meets the inspection exit criteria. An inspection meeting is arranged through email inviting team members to meet at a certain time/place for a certain duration. An inspection defect list is prepared by the recorder to classify and document the problem found during the meeting and by the author during rework. An inspection defect summary is produced by the moderator at the end of the meeting to report the number of defects produced per classification. An inspection report is produced for the tutor/lecturer/project manager to certify that inspection is complete.

Inspections provide:

. Quantitative definition of how to measure the

quality of the product

. Formal procedures for control, verification and

repeatability of inspection results

. Required entry & exit criteria for reinforcing project milestones and provide a measure of progress

. Shared responsibility of the work product quality by

the team members

. Moderator to ensure that the process is objectively

applied

. Use current and past inspection data to reduce defect

rate and help in process improvement

O-O Project tracking - track deliverables such as classes & methods(operations) of a class & defects against time

1) Graph Classes against time

2) Graph number of methods against time

3) Graph number of NCSC (class size) against time

4) No. of defects per hour of inspection time

5) No. of defects per hour of testing time

Outcomes of the O-O process measurements

. project monitoring, estimation

. evaluation of work products and feedback mechanism

. process improvement through defect analysis

. experimental validation of best quality practices