COSC3311

1
COSC3311 Software Design
Section P Vassilios Tzerpos
2
Course Details

• www.cs.yorku.ca/course/3311
• Slides and other resourceshttp//www.cs.yorku.ca
  /course/3311/sectionP/
• Case studies http//www.cs.yorku.ca/course/3311/s
  ectionM/
• Eiffel Helpwww.cs.yorku.ca/eiffel
• Office hours WF 230 330
• Read newsgroup
• Lab hours next week
• Monday, January 12 3-4
• Wednesday, January 14 3-4
• Friday, January 16 3-4

3
Grading

• Assignment 1 7
• Assignment 2 10
• Assignment 3 13
• Test 25
• Exam 45

4
Textbook

• Bertrand Meyer Object-Oriented Software
  Construction, 2nd edition. Prentice Hall, 1997.
• Suggested reading
• Pete Thomas, Ray Weedon, Object-Oriented
  Programming in Eiffel, second edition,
  Addison-Wesley, 1998.
• Kent Beck, Test-driven development by example.
  Addison-Wesley, Boston, 2003.
• J.M. Jezequel and C. Mingins. Design patterns and
  contracts. Addison-Wesley, 2000.
• Erich Gamma et al. Design Patterns.
  Addison-Wesley, 1995.

5
Advice Course strategy

• Dont fall behind First two weeks especially!
• Attend lectures material is not all in textbook
• Do the readings on time

6
Week 1 Readings

• January 5
• Software Quality Engineering -- The context for
  design what is design Eiffel programming
  classes.
• Readings Required Chapter 7
• Static Structure
• Classes
• Class POINT
• Readings Background Chapters 1, 2
• External Quality
• Internal Quality Modularity
• Read about, install and use EiffelStudio

7
The goal Software quality

• REUSABILITY
• EXTENDIBILITY
• RELIABILITY (Correctness Robustness)
• PORTABILITY
• EFFICIENCY
• Correctness
• The ability of a software system to perform
  according to specification, in cases defined by
  the specification.
• Robustness
• The ability of a software system to react in a
  reasonable manner to cases not covered by the
  specification.

SPECIFICATION
Robustness
8
Case Study 1 Bank example
Requirements Use Cases Design How? Plan-driven Identify the Classes Agile Test Driven Development EiffelStudio Clusters and Classes Tests and ETester Project Configuration/Ace files Debugger Documentation Design Constructs BON Contracts Object equality equal Genericity Agents and Tuples Design Patterns (Singleton)
9
Requirements Bank example

• Requirements
• Open an account for a customer (savings or
  chequing)
• Deposit
• Withdraw
• Display details of an account
• Change LOC
• Produce monthly statements
• Print a list of customers
• Ambiguities
• What is the difference between savings and
  chequing?
• Many others

10
Case Study 1 Bank example

• How should we go from Requirements to Code?
• Two basic approaches
• Plan-driven (waterfall type models)
• Agile (incremental approaches)

11
Requirements to Code?
12
The waterfall model of the lifecycle
FEASIBILITY STUDY
REQUIREMENTS ANALYSIS
SPECIFICATION
GLOBAL DESIGN
DETAILED DESIGN
IMPLEMENTATION
VALIDATION VERIFICATION
DISTRIBUTION
PROJECT PROGRESS
13
Problems with the waterfall

• Late appearance of actual code.
• Lack of support for requirements change and
  more generally for extendibility and reusability.
• Lack of support for the maintenance activity (70
  of software costs?).
• Division of labor hampering Total Quality
  Management.
• Impedance mismatches.
• Highly synchronous model.

14
Impedance mismatches
As Management requested it.
As the Project Leader defined it.
As Systems designed it.
As Programming developed it.
As Operations installed it.
What the user wanted.
(Pre-1970 cartoon origin unknown)
15
How to think about requirements?

• Use Cases

16
Bank Requirements Use Cases
Actors
17
Bank Use Cases

• Challenge question
• What would the Use Case diagram look like if the
  bank supplies ATMs in addition to tellers?

18
Use Case Open Account

• Actors Customer (initiator), Teller
• Overview the customer applies for and is granted
  a new bank account with some initial approved
  line of credit. The teller logs on to the system,
  selects open account , and supplies the new
  account details. The system prints a copy of the
  contents of the new account with the date, which
  the teller hands to the customer.

19
Design of Bank Identify Classes

• TELLER
• CUSTOMER
• SAVINGS_ACCOUNT
• CHEQUING_ACCOUNT
• MAIN_MENU
• BALANCE_INQUIRY
• INTEREST_RATE
• Where do we start?

20
Test Driven Development

• Write a little Test
• Test will not work initially (there is no code)
• Might not even compile
• Make the Test work quickly
• Commit whatever sins are necessary in the process
  (e.g. duplication in the code)
• Refactor
• Eliminate the duplication created in merely
  getting the test to work

21
EiffelStudio create a new project
22
Call the new project bank
23
Compile and Run
print(hello world!)
24
Compile often!

• Always start with a compiled system
• New project wizard
• Copy an existing system
• A compiled system is needed for browsing
• Compile often!

25
ETester Create a tests cluster
Click here
26
Create class ACCOUNT_TEST
Click here
27
Clusters and Classes
28
Ace file Directory Structure
29
Ace File Ace.ace
http//www.cs.yorku.ca/eiffel/precompiled

• system
• "bank
• root
• root_class make
• default
• precompiled ("C\Eiffel53\precomp\spec\windows\ba
  se")
• assertion (check)
• assertion (require)
• cluster
• root_cluster "."
• all tests ".\tests"
• library base "ISE_EIFFEL\library\base"
• exclude
• "table_eiffel3" "desc"

30
Project Configuration (Ace file)
Click here
Root Class All contracts ACCOUNT_TEST
turned on
31
Write Test

• test_create_account BOOLEAN is
• local
• c CUSTOMER
• do
• comment("test_create_account")
• create c.make("Archie Fox")
• Result equal(c.name, "Archie Fox")
• end
• Error code VTCT
• Error type is based on unknown class.
• What to do use an identifier that is the name of
  a class in the universe.
• Class ACCOUNT_TEST
• Unknown class name CUSTOMER

32
The Test specifies a Design
33
customer.e

• indexing
• description "A bank customer
• class CUSTOMER create
• set_name
• feature -- Element change
• make (a_name STRING) is
• -- Create a customer. Set name' to a_name'.
• require
• a_name_not_void a_name / Void
• do
• name a_name
• ensure
• name_assigned name a_name
• end
• feature -- Access
• name STRING

34
ETester GUI Green bar
35
Test A customer with a savings account

• test_create_customer_with_account BOOLEAN is
• local
• a1,a2 SAVINGS_ACCOUNT
• c CUSTOMER
• initial_deposit REAL
• do
• initial_deposit 500
• create a1.make(initial_deposit)
• check a1.balance initial_deposit end
• create c.make(a1, "Archie Fox")
• a2 c.account
• Result equal(c.name, "Archie Fox") and
• a2 a1 and a2.balance initial_deposit
• end

36
Red bar
37
Use debugger to find problem
38
EiffelStudio BON tool
39
Client-Supplier relationship
40
Open Account Use case (revisited)

• Actors Customer (initiator), Teller
• Overview the customer applies for and is granted
  a new bank account with some initial approved
  line of credit. The teller logs on to the system,
  selects open account , and supplies the new
  account details. The system prints a copy of the
  contents of the new account with the date, which
  the teller hands to the customer.
• We have not yet dealt with the LOC, system menu
  and the receipt. We leave this as an exercise.

41
Withdraw Use Case

• Actors Customer (initiator) and Teller
• Overview The customer provides the teller with
  an account number and a withdrawal amount. The
  teller selects withdraw-request from the system
  menu, and enters the data. The System debits the
  account by the requested withdrawal amount, and
  prints a receipt with the date and the amount,
  which the teller gives to the customer.
• Question What happens if there is not enough
  money in the account to withdraw?

42
test_withdraw

• test_withdraw BOOLEAN is
• local
• sa1, sa2 SAVINGS_ACCOUNT
• initial_deposit REAL
• do
• comment("test_withdraw")
• initial_deposit 500
• create sa1.make(initial_deposit)
• create sa2.make(200)
• sa1.withdraw(300)
• Result equal(sa1, sa2)
• end

43
Bank design (BON static diagram)
44
EiffelStudio feature tool withdraw
45
Run tests