CS 501: Software EngineeringFall 1999

Lecture 18(a) Project Reports

(b) Object-Oriented Design III

2

Administration

Recitation session: Rational Rose

3

Project Progress

All projects are highly promising, some are exceptional.

Major concern is the time to completion.

Real life experiences:

Client representative leaves suddenlyTeam member drops courseFirst approach not adequate (performance of animation)

Start-up delays: learning, studying technical options, access to software and facilities, scheduling meetings

4

Thinking for the Long Term

Believe that your software will be in use 5 years from now.

What happens at end of semester?

Packaging and hand-overClient's technical preferences (C++, Java)

Some system decisions based on short-term considerations

Which formats, protocols, etc. do you think will last? (IIOP, RMI, SNMP, ...)

5

Network Security

SendMail

Web serverDatabase

Application

Server

Internet

Insecure components

Vulnerable information

6

Network Security: Use of Firewall

SendMail

Web server

Database

Application

Server 1

InternetRelay Relay

Server 2

Firewall

7

Privacy

Does you system collect personal data?

Does the user know that you are collecting personal data?

Who is supposed to have access to that data?Example: Dartmouth Medical School

Who actually has access to that data?Example: Personnel data files

..... the first subpoena ....

8

Requirements, Design and Implementation

Remember the definitions.

Example: Consistency between two players of a board game

The requirement is .....

The design is .....

What is a requirements specification?

9

Final Presentation: First Thoughts

Last week of classes -- 3 or 4 day period

Presentation in front of:Client(s) Bill ArmsAll CS 510 Class is invitedGuests

Time: 45 minutes Format -- you select from:

SlidesOnline demonstrationsHand outs

10

Final Deliverables

Documentation and programs

Delivered to: Client and graders

Due: Last day of classes

Project will be graded on:

Client satisfaction

Usability

Maintainability

11

Actor and Use Case

An actor is a user of a system in a particular role.

An actor can be human or an external system.

A use case is a a task that an actor needs to perform with the help of the system.

Borrow book

BookBorrower

12

Use Cases and Actors

A scenario is an instance of a use case

Actor is role, not an individual(e.g., librarian can have many roles)

Actor must be a "beneficiary" of the use case(e.g., not librarian who processes book when borrowed)

In UML, the system boundary is the set of use cases.

13

Use Cases for Borrowing Books

Borrow copy of book

BookBorrowerReturn copy

of book

Reserve book

Extend loan

14

Relationships Between Use Cases: <<uses>>

BookBorrower

Check for reservation

Extend loan

<<uses>>

<<uses>>

Borrow copy of book

15

Relationships Between Use Cases: <<extends>>

Borrow copy of bookBookBorrower

Refuse loan

<<extends>>

16

Use Cases in the Development Cycle

Use cases are a tool in requirements analysis

Intuitive -- easy to discuss with clients

Use cases are often hard to translate into class models

Scenarios are useful to validate design

17

Actions on Objects

call

return

send

create

destroy

returnCopy(c)

okToBorrow() local

status

notifyReturn(b) asynchronous signal

<<create>>

<<destroy>>stereotypes

18

Links

CopyLibraryMember

+borrowCopy()+returnCopy()

1 0..*on loan

libMem:LibraryMember c:CopyborrowCopy(c)

association

message

link

class

object

19

Sequence Diagram: Change in Cornell Program

Cornellian

:MEngStudent

1 : getName()

sequence numbers added to messages

:PhDStudent

1.1 : name

2: new PhDStudent(name)

3: <<destroy>>

20

Sequence Diagram: Borrow copy of a Book

BookBorrower

libMem: LibraryMember

theCopy:Copy

theBook:Book

borrow(theCopy)okToBorrow

borrow borrow

21

State Diagram

State diagram for class Book

not borrowable

returned()

returned()

borrowable

borrowed()[not last copy]

borrowed()[last copy]