mercury post-mortem

36
Mercury Post- mortem CS 490D April 24, 2001

Upload: tertius-aric

Post on 02-Jan-2016

102 views

Category:

Documents


2 download

DESCRIPTION

Mercury Post-mortem. CS 490D April 24, 2001. Overview. Goals of post-mortem procedures Summary of problems Possible solutions & lessons learned Design review w.r.t. implemented functionality. Why do a Post-mortem?. Learn from mistakes & document for future reference - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Mercury Post-mortem

Mercury Post-mortem

CS 490D

April 24, 2001

Page 2: Mercury Post-mortem

Overview

• Goals of post-mortem procedures

• Summary of problems

• Possible solutions & lessons learned

• Design review w.r.t. implemented functionality

Page 3: Mercury Post-mortem

Why do a Post-mortem?

• Learn from mistakes & document for future reference

• Examine current state of project

• Cannibalize project for useful parts

• Extract existing value from project

Page 4: Mercury Post-mortem

Problems Encountered

• 3 scopes of problems:• Team Scope

• Project Scope

• Component Scope

Page 5: Mercury Post-mortem

Team Scope Problems• Busy schedules

• Difficult to meet & coordinate

• Large group• Miscommunication & confusion

• Strong-willed personalities• Too many chefs• Interruptions, too much debate…

• Lack of Accountability• Why should members be responsible?

• Personal Issues• Interference from the outside world

• Timelining problems• Decreases in available time, over-optimism

Page 6: Mercury Post-mortem

Possible Solutions

• Set weekly time block for entire group to meet

• Meet as sub-groups as necessary

• More strict & organized environment for meetings & development

• Peer evaluations of performance

• Rewards system for progress

Page 7: Mercury Post-mortem

Project Scope Problems• Lack of existing infrastructure

• No testing procedures

• No code repository

• No coding standards

• Not enough low-level detail in design• Classes not well-defined

• Cross-tier interfaces not in design

• GUI & Transport never broken-down

• UML & Java learning curves

Page 8: Mercury Post-mortem

Possible Solutions

• Define & implement infrastructure early using existing & familiar tools

• Build testing into design early

• Design all the way down to method names & parameters

• Design entire project in-depth to near psuedocode level

Page 9: Mercury Post-mortem

Component Issues

• Collaboration Diagram GUI Issues

• Engine• Support classes & ContactMgr AccountMgr

• ServiceMgr

• Transport

Page 10: Mercury Post-mortem

-userid-svc : Service-passwd : String

Account

+SendMessage(in Msg : Message, in Con : Contact)+ReceiveMessage(in Msg : Message, in Acc : Account, in Svc : Service)+AddContact(in Con : Contact)+RemoveContact(in Con : Contact)

-contacts-categories-sort-order

ContactList

-Msg : String-datestamp : long-sender : Contact

Message

+ConnectService()+DisconnectService()+SendMessage(in M : Message, in Cacc : ContactAccount)+ReceiveSegments()+LookupAccount(in LA : Account)+NotifyContactRemoval()+LookupContact(in Con : ContactAccount)

-protocol-service

Service

+CreateServiceConnection(in Svc : Service)+DeleteServiceConnection(in Svc : Service)+SendMessage(in Msg : Message, in Svc : Service, in Cacc : ContactAccount)+ReceiveMessage(in Msg : Message, in Svc : Service, in Cacc : ContactAccount)+LookupAccount(in LA : Account)+NotifyContactRemoval(in Con : Contact)+LookupContact(in Con : ContactAccount)

ServiceMgr

-name-status

Contact

-userid-svc : Service

ContactAccount

1

0..*

Receives

1

0..*

Sends

1

0..*

Contains

1

1

Interfaces

1

1..*

Has

1

1

Interfaces

1

0..*

Manages

1*

From/To

1

0..*

From/To

0..*

1

Transmits

+AddAccount(in Acc : Account)+RemoveAccount(in Acc : Account)+ConnectAccount(in Acc : Account)+DisconnectAccount(in Acc : Account)

AccountMgr

1

0..*

Manages

1

1

Interfaces

+GenerateConnectEvent()+GenerateDisconnectEvent()+GenerateSendMessageEvent()+GenerateReceiveMessageEvent()+GenerateAddContactEvent()+GenerateRemoveContactEvent()+GenerateAddAccountEvent()+GenerateRemoveAccountEvent()

-mercuryid : unsigned long(idl)

GUI

Page 11: Mercury Post-mortem

Key Reason I Couldn’t get GUI to Work

• Design• Didn’t spec out the actual functions and

member variables

• Didn’t fully understand the communication between layers {i.e. interfaces}

• Didn’t have any specs for the GUI. {Not sure what to put in the menu and what to make buttons for}

Page 12: Mercury Post-mortem

Key Reason …. Continued

• Coding • Didn’t start earlier

• Learning curve took longer than expected

• Borders between layers were fuzzy due to the lack of defined functions in system design.

• Java doesn’t work on every OS the same { menu bar}

Page 13: Mercury Post-mortem

Key Reason …. Continued

• Research • Swing

• Was difficult to find GOOD examples

• Wasn’t like a regular CS class where you can just ask a TA your questions!

• Forte• Little too late

Page 14: Mercury Post-mortem

Key Reason …. Continued

• Other reasons• Took on too much for one semester

• Underestimated the time• Docs

• Coding

• Personal problems interfering with work

Page 15: Mercury Post-mortem

What would I do differently

• Have class functions and member variables clearly defined in design doc.

• Have GUI layout before I start coding {i.e what buttons/menu options where}

• Read a book on interfaces

• Less lenient on others when deadlines are missed

Page 16: Mercury Post-mortem

What does work?

• GUI is 80% done

• Key Classes• Main GUI

• Add Buddy GUI

• Add Service GUI

• Message GUI

Page 17: Mercury Post-mortem

What doesn’t work

• No connection to middle end via interface• Never fully grasped the communication

between layers

• AccountMgr wasn’t completed early enough

• ServiceMgr wasn’t complete enough to send/receive messages

• Interfaces weren’t completely understood

Page 18: Mercury Post-mortem

Key features not working

• Tree Listener

• Scope issues with AddBuddy & AddService

Mercury wouldn’t be useable without these features!

Page 19: Mercury Post-mortem

Support Classes (complete)

• Exceptions

• Contact

• Account

• Message

• Status

• Interfaces

Page 20: Mercury Post-mortem

ContactMgr

• Can store contacts

• Retrieves contacts

• Creates new contacts

• Send & Receive messages implemented w/o backing from other components

• No support for the ignore list feature yet

Page 21: Mercury Post-mortem

AccountMgr - Difficulties

• Design

• Personal

• Testing

• Final Status

Page 22: Mercury Post-mortem

AccountMgr - Design

• Unclear Design• Availability of group members

• Data Members and Methods not included

• No connection to ServiceMgr explicitly included in design

Page 23: Mercury Post-mortem

AccountMgr – Design and Interactions

+AddAccount(in Acc : Account)+RemoveAccount(in Acc : Account)+ConnectAccount(in Acc : Account)

+DisconnectAccount(in Acc : Account)

AccountMgr

-userid-svc : Service

-passwd : String

Account

1

0..*

Manages

GUI

1 1

Interfaces

-Msg : String-datestamp : long-sender : Contact

Message

1 0..*

From/To

Page 24: Mercury Post-mortem

AccountMgr - Understanding

• Lack familiarity with Middle End design

• Change in responsibilities

• More knowledgeable of Front End design throughout most of project

Page 25: Mercury Post-mortem

Timeline1/10 – Assigned Web Master position

2/21 – Part of the GUI team

3/23 – Assigned to testing

4/10 – Assigned to develop AccountMgr

Start of Sem.

End of Sem.

Page 26: Mercury Post-mortem

AccountMgr - Personal

• Time Management• Heavy Courseload

• Helping with Java Swing Code

• Updating Web Page

• Attempting to learn testing procedures

Page 27: Mercury Post-mortem

AccountMgr - Testing

• Stubs not written to test interaction with other layers

• Circular Dependency• GUI waiting for AccountMgr to be developed

• AccountMgr waiting for GUI to be developed

Page 28: Mercury Post-mortem

AccountMgr - Final Status

• AccountMgr code complete according to design document

• Not tested

• Much of the unspecified but necessary interaction not implemented

Page 29: Mercury Post-mortem

Difficulties with ServiceMgr

• Unfamiliar with Java Threading Model• Difficulty integrating with Services

• Figuring out how to communicate• Dealing with ICQ’s unpredictability

• Vague Design• Passing of Account Information• Return Values• How ServiceMgr is used by other classes

Page 30: Mercury Post-mortem

ICQ Overview

• Encoding was Important

• UDP vs. TCP

• Packet Acknowledgement

• Time to Implement

• Working Features

Page 31: Mercury Post-mortem

Encoding

• Many bit-wise operations

• Running packet through a hex table and checksum key

• Scrambling key

• Without encoding packet, it wouldn’t be recognized

• It’s encoding or scrambling but not encrypting

Page 32: Mercury Post-mortem

UDP vs. TCP

• Messages to server use UDP• Login

• Logout

• Acknowledgements

• Client Lists

• Messages between clients use TCP• Messages

• Chat

• File

Page 33: Mercury Post-mortem

Packet Acknowledgement

• Use UDP, but need acknowledgement

• Session fails without acknowledgement packets

• Identification numbers need to be correct or session will fail

• Would sometimes send wrong identification numbers

Page 34: Mercury Post-mortem

Implementation Time

• Challenging work but not impossible

• Not a speedy process• Took weeks to get base operations down

• Debugging and necessary error-checking were continual

• Didn’t get to TCP process. Would take at least 20-40 man-hours to get working

Page 35: Mercury Post-mortem

Working Features

• UDP• Connect

• Disconnect

• Receiving packets from ICQ server

• Sending Acknowledgements

• Encoding

Page 36: Mercury Post-mortem

Recap

• Importance of detailed design

• Invisible & sunk costs should be estimated

• Realistic goal setting & time lining is vital