Final project presentation, revision 1 [383.5 KiB]

Download Report

Transcript Final project presentation, revision 1 [383.5 KiB]

Instant messenger group
Final product presentation
2016-05-24
1
Product description
•
The Recorder keeps a record of messenger chat sessions that can be later
referenced. The user can interact with the Recorder and specify actions to be taken
with each new conversation. The Recorder has the following functionality:
–
–
–
–
–
Record conversation.
Filter (Stop) recording.
Default filter settings
Can be chosen before or during conversation.
Set database information.
2016-05-24
2
Project description
• Geographically distributed software project
– Sweden and Croatia
– 4 ppl total
(and Canada during x-mas)
• Goal
– Recorder application for instant messengers
• One Recorder to rule them all
• One Recorder to find them
• One Recorder to bring them all,
and in the network bind them. ;-))
– Is the goal fulfuilled?
• Yes, at least partially…
2016-05-24
3
Communication
• There is generally no casual communication about the project,
therefore communication must be more planned
–
–
–
–
Presentations and lectures - Video conference system
Scheduled meetings - Video meetings (web cam)
Scheduled meetings - Chat
Other communication - E-mail
2016-05-24
4
Milestones
•
Checkpoints for controlling that the project
is on time!
•
7 checkpoints
–
Delayed because of startup issues
Delayed because of x-mas
System test (internal)
•
–
Comment
Finished week
Plan
Requirements def (internal)
Design description
Module test (internal)
•
–
Milestone Description
Project description
•
–
–
–
Id
M-001
Project description approved
M-002
Requirements def. approved
M-003
Design description approved
M-004
Module test passed
M-005
System test approved
M-007
Project approved
46
47
48
48
49
49
Internal
51
1
Internal
1
3
3
3
Internal
Delayed because of x-mas
Project approval
w. 46
w. 47
w. 48
w. 49
2003
2016-05-24
w. 50
w. 51
w. 52
w. 1
Actual
w. 2
w. 3
2004
5
Requirments
1.
2.
3.
4.
5.
6.
7.
8.
Build upon existing messenger tools.
Store chat sessions for later retrieval
Allow searches in a user-friendly user interface
Robust
non-intrusive
Honour privacy
Be secure
Designed for future integration in Web Project
2016-05-24
6
Design choices
• To conform to the requirements we made some design choices:
–
–
–
–
–
–
–
–
–
–
Yahoo Messenger as first case study
Plug-in
Dynamic libraries (DLLs)
Dynamic binding
Tray-icon
Recorder filters
Weak Encryption
Serverside daemon for DB connection
SQL
JDBC interface towards the database
2016-05-24
7
Conformance to Requirements
1.
Build upon existing messenger tools.
•
2.
The recorder build on an architecture that build on plug-ins. The libraries
attach them selves to the IM program, which make the architecture robust and
IM independent.
Store chat sessions for later retrieval
•
3.
Store on local HD if no connection is present. If a connection to the database
isn’t possible or corrupt, the recorder will temporarily store messages to a
local media.
Allow searches in a user-friendly user interface
•
Searches are possible in a user interface
•
4.
Keywords, User, date
Robust
•
Works even if no connection to db is present, runs even if IM crashes The
recorder program works independent of if the messenger hangs or shuts
down.
2016-05-24
8
Conformance to Requirements
5.
Non-intrusive
•
6.
The recorder requires a minimum of user intervention. A tray-icon is present
when the recorder is started. Implements easy-to-use filters.
Honour privacy
•
7.
Filter options are present to honor the privacy by letting the user decide what
sessions (conversations) should be stored.
Be secure
•
8.
Encryption is implemented to avoid abuse and corruption of the stored data.
This also enforces privacy since no-one can read or alter information stored
locally.
Designed for future integration in Web Project
•
The database used in the project can easily be merged together with the
database of the web-group.
2016-05-24
9
Technical difficulties - security firewall
• The server that runs the database used a firewall, and we were
permitted only to use one port for establishing a connection, further
on, we weren’t allowed to establish a direct connection to the
database, the DB only accepted tcp connections running from the
localhost interface.
– Solution
• The only viable solution to this problem is making a local daemon
that runs on the server and accepts tcp connections on a
designated port and routes them to the dbms
2016-05-24
10
Technical difficulties - Redundancy in messages
• What if both users decide to record the conversation?
– Solution
• The tables are created in such a manner so to support simultaneous
recording of messages from both sides
– adds to security – potential chat participators can establish a rule that only
messages that were recorded twice – from both chat participators – count
– Adds stability – if both chat partners record a single session, every message has
more chance to be recorded if networking problems occur
– Alternative solution
• A lot of code to check if messages coincide.
2016-05-24
11
Technical difficulties - serverside processing – what
language/tool to use for checking the received queries?
• How is compatability between daemon and IM handled?
– Solution
• we incorporated the message processing in our connection deamon
– Drawback - the program has lost on flexibility – the daemon accepts only
messages of a predefined type from the IM.
– Benefit - the daemon acts as a filter for the communication, other messages from
the tcp can be discarded right away before involving the dbms
– alt. solution
• a procedural language (SPL), however, using a pure java daemon seemed
to add to the general portability
2016-05-24
12
A few techincal details
•
•
•
•
Java support is required on the server side (JVM)
Java support is not required on the client side
Client is written in ANSI C and should be portable among all Win32 platforms
Databased support conforms to std. SQL
2016-05-24
13
Lessons from distributed work
•
The most interesting part of this course was getting to learn about some
new cultures
•
•
•
The geographically distributed development was harder then usual development.
Teleconferencing lectures was a very interesting part of the course.
The cours wasn't confined to academic laboratory work, it was more comercial and
realistic.
It was an exotic and very interesting course and we hope that it will be repeated in
the next year(s) for the follow-up generations.
Management and meetings requires more planning.
The importance of communication is stressed in this course.
Since there is generally no casual communication about the project, group members
have to be outgoing in their efforts, make an effort to understand the other parts of
the project.
The course was a bit short to get the best out of it…
•
•
•
•
•
2016-05-24
14
Finally
A good laughter prolongs your life
I’ll probably live ’til 200 ;-))
Thanks for a great working and social (cultural)
experiance
2016-05-24
15