Software Engineering Analysis And Design

Meeting Calendar Groupware System

Design Proposal Group Oak Software Engineering Analysis and Design Meeting Calendar (MC) Management System, LAC Milestone 3: Design Proposal (AP)

Professor: Ed. Morris Tutor: Claire Hennekam Authors: Oksana Mozhyna (3073171) Ajith Ekanayake (3147166) Nelson Shen (3146377) Wilson Castillo (3143667)

Melbourne, October 15th,2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

Table of Contents Table of Figures ........................................................................................................................................5 Meeting Calendar System.....................................................................................................................6 1 Overview ...........................................................................................................................................6 2 Scope.................................................................................................................................................6 2.1 In Scope ..................................................................................................................................6 2.2 Out of Scope..........................................................................................................................7 2.3 Out of Scope but will be appreciated .............................................................................7 3 Assumptions and Dependencies..................................................................................................8 4 List of Stakeholders ..........................................................................................................................8 4.1 Executives of LAC..................................................................................................................8 4.1.1 The CEO, Sponsor of MC system ....................................................................................8 4.1.2 The CIO, Executive of IT support department which will be in charge of review the technical proposal, system development, deployment and maintenance. ..............8 4.1.3 The CFO, Who will evaluate the system efficiency and cost curtailment for meeting organisation......................................................................................................................8 4.2 Functional Management of LAC .......................................................................................8 4.2.1 Administration (Secretary) Office; .................................................................................8 4.2.2 Sales manager and other operational managers;....................................................8 4.2.3 IT Support manager, Who will be in charge of the system development, implementation, management, user technical support, from both internal and external..............................................................................................................................................8 4.2.4 Security Office and Legal Office, Who will be concerned at user registration, content privacy and confidentiality............................................................................................8 4.2.5 Procurement department, Which will be in charge of products and service purchasing and fulfilment. .............................................................................................................8 4.3 Staffs of LAC ...........................................................................................................................9 4.3.1 Sales representatives, marketing staffs, and other employees, ..............................9 4.3.2 Office Administrators or Secretaries,.............................................................................9 4.3.3 IT support engineers. ........................................................................................................9 4.4 Supply Chain of the system.................................................................................................9 4.4.1 Software and hardware providers ................................................................................9 4.4.2 System development project manager ......................................................................9 4.4.3 Deployment project manager ......................................................................................9 4.5 Customers of LAC, Major sector clients of LAC ...............................................................9 5 Requirements....................................................................................................................................9 5.1 Functional Requirements .....................................................................................................9 5.1.1 Functionality ......................................................................................................................9 5.1.2 Data ..................................................................................................................................10 5.2 Design Constrains................................................................................................................10 5.2.1 Physical Environment .....................................................................................................10 5.2.2 Interfaces .........................................................................................................................11 5.2.3 Users...................................................................................................................................11 5.3 Process Constrains...............................................................................................................12 5.3.1 Resources .........................................................................................................................12 5.3.2 Documentation ..............................................................................................................12 5.3.3 Standards .........................................................................................................................12 5.4 Non-functional Requirements...........................................................................................12

RMIT University © 2006 School of Computer Science and Information Technology

2 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

6 7

8

9

Groupware System Group OAK

5.4.1 Performance....................................................................................................................12 5.4.2 Interface, Usability and Human Factors.....................................................................13 5.4.3 Security .............................................................................................................................13 5.4.4 Reliability and Availability .............................................................................................13 5.4.5 Maintainability.................................................................................................................13 Summary of Solution......................................................................................................................13 Other optional solutions................................................................................................................14 7.1 To register new user ............................................................................................................14 7.2 To Deal with meeting conflicts: ........................................................................................16 Use Case Model .............................................................................................................................17 8.1 Use Case Diagrams.............................................................................................................17 8.1.1 Use Case Diagram - Overview.....................................................................................17 8.1.2 Use Case Diagram – Create Group............................................................................18 8.1.3 Use Case Diagram – Edit Group ..................................................................................18 8.1.4 Use Case Diagram – Create Meeting ........................................................................19 8.1.5 Use Case Diagram – Edit meeting ..............................................................................19 8.1.6 Use Case Diagram – Delete meeting.........................................................................20 8.1.7 Use Case Diagram – Register New User .....................................................................20 8.1.8 Use Case Diagram – Change User Information........................................................20 8.1.9 Use Case Diagram – Remove User..............................................................................21 8.2 Use Case Descriptions ........................................................................................................21 8.2.1 Use Case Description – Create Group .......................................................................21 8.2.1.1 Primary Flow of Events ..........................................................................................21 8.2.1.2 Alternative Flow of Events....................................................................................22 8.2.2 Use Case Description – Edit Group..............................................................................22 8.2.2.1 Primary Flow of Events ..........................................................................................22 8.2.2.2 Alternative Flow of Events....................................................................................22 8.2.3 Use Case Description – Delete Group ........................................................................23 8.2.3.1 Primary Flow of Events ..........................................................................................23 8.2.3.2 Alternative Flow of Events....................................................................................23 8.2.4 Use Case Description – Create Meeting....................................................................24 8.2.4.1 Primary Flow of Events ..........................................................................................24 8.2.4.2 Alternative Flow of Events....................................................................................24 8.2.5 Use Case Description – Edit Meeting..........................................................................25 8.2.5.1 Primary Flow of Events ..........................................................................................25 8.2.5.2 Alternative Flow of Events....................................................................................26 8.2.6 Use Case Description – Edit Meeting..........................................................................26 8.2.6.1 Primary Flow of Events ..........................................................................................26 8.2.6.2 Alternative Flow of Events....................................................................................27 8.2.7 Use Case Description – Register New User.................................................................27 8.2.7.1 Primary Flow of Events ..........................................................................................27 8.2.7.2 Alternative Flow of Events....................................................................................28 8.2.8 Use Case Description – Change User Information ...................................................28 8.2.8.1 Primary Flow of Events ..........................................................................................28 8.2.8.2 Alternative Flow of Events....................................................................................28 8.2.9 Use Case Description – Remove User .........................................................................29 8.2.9.1 Primary Flow of Events ..........................................................................................29 8.2.9.2 Alternative Flow of Events....................................................................................29 Class Diagram ................................................................................................................................30 9.1 Class Diagram Description ................................................................................................31

RMIT University © 2006 School of Computer Science and Information Technology

3 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

9.1.1 Meeting Class..................................................................................................................32 9.1.2 Attendee Class................................................................................................................32 9.1.3 User Class..........................................................................................................................32 9.1.4 Group Class .....................................................................................................................32 9.1.5 Notification Class ............................................................................................................33 10 Sequence Diagrams..................................................................................................................34 10.1 Sequence Diagram – Create Group ..............................................................................34 10.2 Sequence Diagram – Edit Group.....................................................................................35 10.3 Sequence Diagram – Create Meeting...........................................................................36 10.4 Sequence Diagram – Edit Meeting .................................................................................37 10.5 Sequence Diagram – User Management ......................................................................38 11 Activity Diagrams .......................................................................................................................39 11.1 Activity Diagram – Create Group ....................................................................................39 11.2 Activity Diagram – Edit Group ..........................................................................................40 11.3 Activity Diagram – Create Meeting ................................................................................41 11.4 Activity Diagram – Edit Meeting.......................................................................................42 11.5 Activity Diagram – Register New User .............................................................................43 11.6 Activity Diagram – Change User Information................................................................43 11.7 Activity Diagram – Remove User......................................................................................44 References..............................................................................................................................................44 12 Annex 1 - Gantt Chart...............................................................................................................45 13 Discussion of issues .....................................................................................................................48 14 The strengths and weaknesses of design ..............................................................................48

RMIT University © 2006 School of Computer Science and Information Technology

4 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

Table of Figures

Figure 1: Use Case Overview...............................................................................................................17 Figure 2: Use Case Create Group ......................................................................................................18 Figure 3: Use Case Edit Group.............................................................................................................18 Figure 4: Use Case Create Meeting...................................................................................................19 Figure 5: Use Case Edit Meeting .........................................................................................................19 Figure 6: Use Case Delete Meeting ...................................................................................................20 Figure 7: Use Case Register New User................................................................................................20 Figure 8: Use Case Change User Information ..................................................................................20 Figure 9: Use Case Remove User ........................................................................................................21 Figure 10: Packages Diagram.............................................................................................................30 Figure 11: MC Business Logic Class Diagram....................................................................................31 Figure 12: Sequence Diagram Create Group .................................................................................34 Figure 13: Sequence Diagram Edit Group........................................................................................35 Figure 14: Sequence Diagram Create Meeting..............................................................................36 Figure 15: Sequence Diagram Edit Meeting ....................................................................................37 Figure 16: Sequence Diagram User Management .........................................................................38 Figure 17: Activity Diagram Create Group.......................................................................................39 Figure 18: Activity Diagram Edit Group .............................................................................................40 Figure 19: Activity Diagram Create Meeting ...................................................................................41 Figure 20: Activity Diagram Edit Meeting .........................................................................................42 Figure 21: Activity Diagram Register New User ................................................................................43 Figure 22: Activity Diagram Change User Information...................................................................43 Figure 23: Activity Diagram Remove User Information...................................................................44

RMIT University © 2006 School of Computer Science and Information Technology

5 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

Meeting Calendar System 1

Overview

LAC is a famous national company which operates with 200 employees located in 3 major branch offices: Melbourne (head office), Sydney, and Wagga Wagga. In result of growing business collaboration there are about 40 - 50 meetings a week in Melbourne alone. The present manual meeting booking method has been a shortage to maintain an efficient meeting environment for all staff. For example, managers and staff waste time on organising and rescheduling, meeting overlaps and clashes frequently occur, and employees not turning up to meetings because they claim to have not been notified. In order to improve the situation, a meeting calendar management system was initiated by Ms. Claire Hennekam and the CEO of LAC is the direct sponsor of the project. The overall goal of the system is to stop employees from wasting time on the phone and on email trying to sort out each other’s schedules in order to organise meetings. The Meeting Calendar (MC) Management System is enabling groups of LAC employees to arrange meetings on a shared calendar. The system will be used in 3 of LAC branch offices: Sydney, Melbourne, and Wagga Wagga. Users will be allowed to register, login, create/cancel groups and meetings, invite/drop meeting attendees, confirm/adjust meeting schedules, manage clashes, and associate functions related to access control according to security and privacy policies. A Client/Server architecture was required, and a scalable infrastructure for integrating the service with future email, WWW, and customer relationship management (CRM) systems will be appreciated.

2 2.1

Scope In Scope

SAD was contracted by LAC to produce requirements analysis (RA), analysis proposal (AP) and design proposal (DP) documents for a meeting calendar software system. According to customer request, the MC system will be designed as a standalone product initially, used Client/Server architecture, deployed in Sydney, Melbourne and Wagga Wagga branch offices, and all of LAC internal employees will be system users who can only access it in the work environment.

RMIT University © 2006 School of Computer Science and Information Technology

6 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

The RA, AP and DP will consider of the following major functions being realized by MC system: Users registration, login and access control; Meeting booking management, including creation, cancellation, invitation and notification, schedule, calendar, time management; Group management.

2.2

Out of Scope

Firstly, the implementation platform for MC is beyond the scope of this contract. SAD is not required to implement its DP, nor cater for implementation in any RA or DP documentation. Project budget, IT skills for development, implementation and management are not concerned by LAC.

Secondly, the access to the system from outside the work environment (office) will not be considered. And keeping of notes / comments, meeting minutes and other meeting documentation is not required.

Finally, the design of detailed technical standards will not be required at this stage. The technical standards contains platform (server, workstation, storage and networking hardware and protocols, operating system, system management software, etc.), middleware

software

(application

servers,

database

management

systems,

communication and queue applications, etc.), and application development language or standards (Java, MS.NET, Web services, XML, etc.)

2.3

Out of Scope but will be appreciated

A scalable interface for integrating the service with future email, WWW, and customer relationship management (CRM) systems will be welcome. In present, there is no clear action plan in regards of such systems for the next 12 months.

Meeting facilities/resources management could be a helpful function, but is not required essentially.

RMIT University © 2006 School of Computer Science and Information Technology

7 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

3

Groupware System Group OAK

Assumptions and Dependencies

The assumptions and dependencies stated in following are regarding the system that are otherwise not documented in the spec, the forums or the "client interview tape" (demo recordings), which were agreed by client sponsor. It is assumed that:


All Personal Computers (PC) of large advertising company (LAC) are connected into a network;

4




There is a server where MC database can be installed;




The TCP/IP is the common protocol used in LAC network;

List of Stakeholders

The following groups or roles are directly or indirectly impacted by the system.

4.1

Executives of LAC

4.1.1

The CEO, Sponsor of MC system

4.1.2

The CIO, Executive of IT support department which will be in charge of review the technical proposal, system development, deployment and maintenance.

4.1.3

The CFO, Who will evaluate the system efficiency and cost curtailment for meeting organisation.

4.2

Functional Management of LAC

4.2.1

Administration (Secretary) Office;

4.2.2

Sales manager and other operational managers;

4.2.3

IT Support manager, Who will be in charge of the system development, implementation, management, user technical support, from both internal and external.

4.2.4

Security Office and Legal Office, Who will be concerned at user registration, content privacy and confidentiality.

4.2.5

Procurement department, Which will be in charge of products and service purchasing and fulfilment.

RMIT University © 2006 School of Computer Science and Information Technology

8 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

4.3

Groupware System Group OAK

Staffs of LAC

4.3.1

Sales representatives, marketing staffs, and other employees,

4.3.2

Office Administrators or Secretaries,

4.3.3

IT support engineers.

4.4

Supply Chain of the system

4.4.1

Software and hardware providers

4.4.2

System development project manager

4.4.3

Deployment project manager

4.5

5

Customers of LAC, Major sector clients of LAC

Requirements

Following sections describe the functional requirements (see Section 5.1) and nonfunctional requirements (see Section 5.2) for the Meeting Calendar (MC) system.

5.1

Functional Requirements

5.1.1

Functionality

5.1.1.1

The MC system must allow any user, registered with the system, to create meetings and invite other employees to attend meetings.

5.1.1.2

The MC system must allow any users to create groups and invite other employees to join groups.

5.1.1.3

The MC system must allow special users to create special groups which concerned by access limitation.

5.1.1.4

Users must be able to remove themselves from or join to normal groups.

5.1.1.5

Users must not be able to remove themselves from or join to special groups.

5.1.1.6

Only a Manager can create special groups.

5.1.1.7

The MC system must send a group creation confirmation to each group member after a group is created.

5.1.1.8

The MC system must allow any user to invite a group, an individual or both.

RMIT University © 2006 School of Computer Science and Information Technology

9 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

5.1.1.9

Groupware System Group OAK

A meeting initiator must be able to remove invitees from the meeting before the meeting has occurred.

5.1.1.10 The MC system must suggest an alternative time table within the following proposed week to meeting initiator. This is done for re-scheduling a meeting when clashes occur in invitees’ individual time-tables. 5.1.1.11 The initiator must be able to establish a meeting even if some of the invitees cannot attend. 5.1.1.12 The MC system must show individual timetables to users for scheduled meetings, including clashes. 5.1.1.13 MC system must send a notification to each user who gets added to any meeting.

5.1.2

Data

5.1.2.1

Employees’ information must be maintained in system for tracking the employees’ name, employee’s ID, job title; manager/non-manager, contact number, and hire status. This list will be maintained (generation and update) by the MC System’s Administrator.

5.1.2.2

Registration information must be maintained in system for MC users’ ID, password and user access limitations. This list must be maintained by MC system’s Administrator.

5.1.2.3

Groups information must be maintained in MC system as long as the group exists, which includes group description, initiator, members, etc.

5.1.2.4

Information regards to specific meetings must be maintained in MC system for as two months after the meeting has occurred. Information includes meeting title, holders, attendees, meeting schedule, etc.

5.1.2.5

The information related with every user will be stored in the ‘server’ database. This information includes user time-table for specific meetings,

5.2

Design Constrains

5.2.1 5.2.1.1

Physical Environment The MC system must operate in three branch offices in Melbourne, Sidney and Wagga Wagga. There must be a ‘server’ located in every LAC’s office location. MC system will operate independently in each city. Accordingly, users, groups, meetings can only be maintained in region isolated.

RMIT University © 2006 School of Computer Science and Information Technology

10 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

5.2.1.2

Users must have access to a computer connected to the office LAN in order to use MC system.

5.2.1.3

A main server must manage whole information of users, groups and meetings within a location.

5.2.2

Interfaces

5.2.2.1

Every user must have access to a computer connected to the ‘server’ database in order to be able to use the MC system.

5.2.2.2

A user must be registered into the MC system before being able to login.

5.2.2.3

An application must be installed in every LAC’s computer that is going to be used with MC system. This application will be the interface between the user and MC system.

5.2.2.4

A user friendly interface must be helpful for desktop operation; A colourful calendar for easy identifying meeting clashes, cancellation and creation of new meetings.

5.2.2.5

A user registration interface must be provided.

5.2.2.6

A group management interface must be provided.

5.2.2.7

A meeting scheduling interface must be provided for a specific meeting.

5.2.2.8

An “all” meeting scheduling interface must be provided.

5.2.2.9

A user’s individual timetable (calendar) interface must be provided.

5.2.2.10 Special interfaces registration. 5.2.3

according

to

administration:

Employees

information,

Users

5.2.3.1

The MC system will be used only for LAC’s employees.

5.2.3.2

The following user roles would be considered:


Administrator, who will be in charge of MC system management and has permissions for smoothing meeting process.




Employee, identified during registration according to company employee information.

RMIT University © 2006 School of Computer Science and Information Technology

11 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)




Groupware System Group OAK

Managers, identified during registration according to company employee information. Managers can create a kind of special groups, which a user cannot be removed by themselves.

5.2.3.3

The MC system would have two types of users: Normal users and Administrators. Both are called users. The normal users would imply Managers and Staff.

5.2.3.4

The user must have the basic knowledge to operate the system.

5.3

Process Constrains

5.3.1

Resources

5.3.1.1

The developer team must have knowledge of database and user interface based applications.

5.3.1.2

To develop the system the developer must get development tools to simulate different process of the MC system.

5.3.2

Documentation

5.3.2.1

The MC system must have a manual which can be used for any user to operate the system

5.3.2.2

The user’s manual must be available through the MC user’s interface.

5.3.3

Standards

5.3.3.1

5.4

The system must be developed with standard tools which allow it to be maintainable.

Non-functional Requirements

5.4.1

Performance

5.4.1.1

The average response time in client interface must not exceed five (5) seconds.

5.4.1.2

None of the transactions inside the Meeting Calendar Software System must take more than 30 seconds.

5.4.1.3

None of the transaction or system failure must lead to the data corruption.

RMIT University © 2006 School of Computer Science and Information Technology

12 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

5.4.1.4

5.4.2

Groupware System Group OAK

The MC must be able to handle up to 300 concurrent user sessions across LAC intranet.

Interface, Usability and Human Factors

5.4.2.1

A consistent colour scheme and a uniform navigational structure and layout must be used for all screens in the user interface of the system.

5.4.2.2

A user must be able to use MC system after a short course of four hours.

5.4.3

Security

5.4.3.1

Every user operation must be registered in the ‘server’ database.

5.4.3.2

User information must be stored in the ‘server’ database.

5.4.3.3

The system must provide user and password validation schemes.

5.4.4

Reliability and Availability

5.4.4.1

The MC system must be able to determine availability of the ‘server’ information.

5.4.4.2

The MC system must process information after it is stored in the ‘server’ database.

5.4.4.3

The MC system must create a backup of the server database daily.

5.4.4.4

The Meeting Calendar Software System must be available at least 99.8% of the time, 24 hours a day, 7 days per week.

5.4.4.5

System downtime for maintenance or system restore must not exceed 1 hour.

5.4.5 5.4.5.1

6

Maintainability The system must be able to be integrated with email, WWW and customer relationship management systems.

Summary of Solution

This section covers the summary of our design and approach. Our approach was based on a simple concept of meeting utilised almost all customer requirements while keeping the design simple and clear. We were successful in keeping that promise.

RMIT University © 2006 School of Computer Science and Information Technology

13 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

Our design is virtually based on the most popular MVC design pattern. Our class diagrams section shows this concept very clearly.

The model (M) which is closely coupled with

database related classes is shown as a package called database. The view (V) component is shown as a package called GUI. Elaboration of these two components is out of our project scope. So the presentation of the Controller (C) related classes is the major part of our goal. Basically our controller classes focus on business requirements and processing. It interacts with Model (databases) to get data and it provides View (GUI) with data.

In our class diagram, we show very clear picture of relationships among the major objects; the Meeting, the Attendee and the User Calendar. The attendee (Attendee) who attends a meeting could be a user (User) or a group (Group). Each meeting (Meeting) comprises of one or more attendees. This shows very good generalization of objects.

Each user

calendar (User Calendar) can have zero or many such meetings.

The generalization of actors we achieved in our use cases, are clearly visible in our class diagram. Normal LAC user is presented in User class. As per requirements, we derived two more user types out of this User class. They are managers (Manager Class) and the system administrator (Admin). It has given additional rights and responsibilities for these derived users.

Finally, our design is simple and clearly presented to achieve overall objectives.

7

Other optional solutions

Although the MC system has been designed carefully according to customer requirements, we still can find different ways to approach objectives, such as:

7.1

To register new user

Two of the optional registration processes has been discussed as following: Solution 1: The MC administrator must create a new user in MC system as soon as receiving a new employment notification from HR. Then the user can active the account when first using the MC system.

RMIT University © 2006 School of Computer Science and Information Technology

14 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

Process: 1. HR informs MC system administrator for a new employee who need to use MC system. 2. MC Administrator creates the user account by using the employee ID, include user name, system role. 3. Administrator sends the account information as well as an initial password to the user. 4. The use then can access and login MC system. Note: The step 1, 3 are operations out of system scope. Only step 2 and 4 are supported by MC system. Advantage: •

Reduces complication of system.

•

High level security control by administration operation rather than by system.

•

Less chance for user to wrongly create user ID, user system role, initial password and other user information.

Disadvantage: •

User must wait for administration operations before using the system.

•

Since the MC system will be maintained separately in 3 locations, the administration operation will be complicated and overlap when user transfer.

Solution 2: The MC system will provide automatically registration for any user in any place. Process: Refer the work flow in UseCase – User Management. Advantage: •

User can register new account by self, and can get account work immediately.

Disadvantage: •

Complicate in system design and development.

•

Lower security level since any people can register system by an employee ID.

Solution Selection: We decided to use solution 2 because the security level is not the key concern of customer, since there is no critical confidential information in system, and validated employee can ask administrator to delete the account registered by anyone else. Moreover, the solution-2 can provide automatically registration and commit the “easy to access” requirement which is highly concerned by customer.

RMIT University © 2006 School of Computer Science and Information Technology

15 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

7.2

Groupware System Group OAK

To Deal with meeting conflicts:

Two of the optional processes have been discussed for meeting overlap solving, which are described as following: Solution 1: The MC system must pre-alert the time conflict of each attendee to meeting owner before meeting confirmation, until meeting owner selects the duration without conflict with member’s user calendar. Process: 1. Meeting owner select a meeting duration with start time and end time. 2. MC system then check the duration with all the users’ individual calendar whose ID provided in meeting attendees. 3. MC system will stop confirm meeting until the duration being changed without any conflict. Advantage: •

Can ensure all the meeting without any conflict before confirmation.

Disadvantage: •

When there are many attendees, or attendee’s attendance is not a key concern, the process intends to waste time.

•

There is no customer requirement that need to ensure every attendee must attend a meeting.

Solution 2: The MC system will allow meeting time conflict with user calendar. Process: Refer the work flow in UseCase description – Meeting Management. Advantage: •

A meeting can still be confirmed when unimportant invitees cannot attend the meeting.

Disadvantage: •

MC system will not maintain consistency of attendees with the meeting.

Solution Selection: We decided to use solution 2 because customer only wants an easy to use system rather than unnecessary restrictions.

In addition, the solution also provides the possibility to

confirm a meeting in human judgment.

Anyway, customer will appreciate the system

provides enough information for final decision.

RMIT University © 2006 School of Computer Science and Information Technology

16 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

8

Groupware System Group OAK

Use Case Model

8.1

Use Case Diagrams

This section presents the high-level Use Case model (Figure 1) and low-level Use Case diagrams for selected cases (Figure 2, Figure 3, Figure 4 and Figure 5). These diagrams have been derived from the Requirement Analysis and Analysis Proposal done on the MC. 8.1.1

Use Case Diagram - Overview

Figure 1: Use Case Overview

RMIT University © 2006 School of Computer Science and Information Technology

17 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

8.1.2

Groupware System Group OAK

Use Case Diagram – Create Group

Figure 2: Use Case Create Group

8.1.3

Use Case Diagram – Edit Group

Figure 3: Use Case Edit Group

RMIT University © 2006 School of Computer Science and Information Technology

18 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

8.1.4

Groupware System Group OAK

Use Case Diagram – Create Meeting

Figure 4: Use Case Create Meeting

8.1.5

Use Case Diagram – Edit meeting

Figure 5: Use Case Edit Meeting

RMIT University © 2006 School of Computer Science and Information Technology

19 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

8.1.6

Groupware System Group OAK

Use Case Diagram – Delete meeting

Figure 6: Use Case Delete Meeting

8.1.7

Use Case Diagram – Register New User

Figure 7: Use Case Register New User

8.1.8

Use Case Diagram – Change User Information

Figure 8: Use Case Change User Information

RMIT University © 2006 School of Computer Science and Information Technology

20 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

8.1.9

Groupware System Group OAK

Use Case Diagram – Remove User

Figure 9: Use Case Remove User

8.2

Use Case Descriptions

Use Descriptions are provided for the following major use cases. 8.2.1

Use Case Description – Create Group

Application name Use Case ID Overview of Use Case Actors Relationships Pre-Conditions

Post-Conditions Constraints Frequency of Use 8.2.1.1

MC UC-MC-001 Create a Group in MC system MC User Add Attendee • A group exists in the system. • A User registered with MC system. • A User logged in to the MC system. • A User views a group list. The group is created. N/A 1-5 times per a day

Primary Flow of Events

Actor Action 1. Chooses to create a new Group. 2. Populates Group Details. 3. Add Participants to the Group. Add Attendee 4. Submit the new Group.

System Response

5. Shows the confirmation message. 6. Accept creation of the Group. 7. Create Group in the System.

RMIT University © 2006 School of Computer Science and Information Technology

21 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

8. Sends notification to all participants. 9. End of Use Case. 8.2.1.2

Alternative Flow of Events

Alternative A – Step 7 – User declines creation of the group Actor Action System Response A1. End of Use Case. 8.2.2 Use Case Description – Edit Group Application name MC Use Case ID UC-MC-002 Overview of Use Case Edit a Group existing in MC system Actors MC User Relationships N/A Pre-Conditions • A group exists in the system. • A User registered with MC system. • A User logged in to the MC system. • A User views a group list. Post-Conditions The group is updated. Constraints N/A Frequency of Use 8.2.2.1

Primary Flow of Events

Actor Action 1. Chooses a Group in the list. Opens group.

System Response 2. Shows the list of participants.

3. Add a participant to the Group. Submits changes. 4. Updates the Group with the changes. 5. Sends notification to an added participant. 6. End of Use Case. 8.2.2.2

Alternative Flow of Events

Alternative A – Step 3 – User removes a participant from the list. Submits changes Actor Action System Response A1. Check if group is a regular group. A2. Displays a confirmation message box. A3. Confirms removal of the participant. A4. Updates the Group with the changes. A5. Sends notification to a removed participant. A6. End of Use Case. Alternative B – Step A1 – System finds that the group is a special group. Actor Action System Response B1. Check if user is a Manager User and owner of the group. B2. Resumes at step A3.

RMIT University © 2006 School of Computer Science and Information Technology

22 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

Alternative C – Step B1 – System finds that user is not a Manager user or is not an owner of the group. Actor Action System Response C1. Displays an error message. C2. End of Use Case. Alternative D – Step A3 – User rejects removal of a participant. Actor Action System Response D1. End of Use Case. Alternative E – Step 3 – User changes Details of the Group. Submits changes Actor Action System Response E1. Displays a confirmation message box. E2. Confirms changes of the details. E3. Updates the Group with the changes. E4. End of Use Case. 8.2.3 Use Case Description – Delete Group Application name MC Use Case ID UC-MC-003 Overview of Use Case Delete a Group existing in MC system Actors MC User Relationships N/A Pre-Conditions • A Group exists in the system. • A User registered with MC system. • A User logged in to the MC system. • A User views a group list. Post-Conditions The group is deleted. Constraints The User must be an owner of the Group or Administrator of the system. Frequency of Use 8.2.3.1

Primary Flow of Events

Actor Action 1. Chooses a Group from the group list. Open the Group.

System Response

2. Shows list of group participants. 3. Deletes the Group. 4. Displays a confirmation message box. 5. Confirms deletion of the Group. 6. Sends notification to all group participants. 7. End of Use Case. 8.2.3.2

Alternative Flow of Events

Alternative A – Step 5 – User rejects deletion of the Group. Actor Action System Response A1. Resumes at step 7.

RMIT University © 2006 School of Computer Science and Information Technology

23 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

8.2.4

Use Case Description – Create Meeting

Application name Use Case ID Overview of Use Case Actors Relationships Pre-Conditions

Post-Conditions Constraints Exceptions Includes

Extends

Special Requirements Notes and Issues 8.2.4.1

Groupware System Group OAK

MC UC-MC-004 The User chooses to create a meeting in the system MC User N/A
A User registered with MC system
A User logged in to the MC system
A User views a calendar The meeting has been created N/A N/A
Add Attendees
Browse Attendees
Check User’s availability
Send Notification
Set meeting details
Validate meeting details
Update invitees’ calendar
Meeting conflict N/A N/A

Primary Flow of Events

Actor Action 1. Chooses to create a meeting 2. Introduces meeting details 3. Selects start and end time for the meeting

System Response

4. Displays list users and groups to user 5. Selects users and groups from list 6. Checks selected users’ availability 7. Displays users’ availability information 8. Submit meeting 9. Sends notification to all attendees about new meeting creation 10. Updates attendees’ calendars. 11. End of Use Case. 8.2.4.2

Alternative Flow of Events

Alternative A – Step 8 – User changes Attendees list. Actor Action System Response A1. Resumes at step 6.

RMIT University © 2006 School of Computer Science and Information Technology

24 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

Alternative B – Step 6 – System finds that not all attendees are available. Actor Action System Response B1. Suggests alternative time within upcoming week B2. Accepts suggested time B3. Resumes at step 8 Alternative C – Step B2 – User enters alternative time. Actor Action System Response C1. Submits changes C2. Resumes at step 6 8.2.5

Use Case Description – Edit Meeting

Application name Use Case ID Overview of Use Case Actors Relationships Pre-Conditions

Post-Conditions Constraints Exceptions Includes

Extends

Special Requirements Notes and Issues

8.2.5.1

MC UC-MC-005 Edit a Meeting existing in MC system MC User N/A
A meeting exists in the system
A User registered with MC system
A User logged in to the MC system
A User views a calendar The meeting is updated The User must be an owner of the Meeting N/A
Browse Attendees
Check User’s availability
Send Notification
Update meeting details
Validate meeting details
Update invitees’ calendar
Meeting conflict
Delete Meeting
Update Attendees N/A N/A

Primary Flow of Events

Actor Action 1. Chooses a Meeting on the calendar

System Response 2. Shows details of the Meeting

3. Changes scheduled time Meeting. Submits changes

for

the 4. Checks selected users’ availability 5. Sends notification to all attendees about updated meeting

RMIT University © 2006 School of Computer Science and Information Technology

25 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

6. Updates attendees’ calendars 7. End of Use Case 8.2.5.2

Alternative Flow of Events

Alternative A – Step 3 – User changes Attendees list. Actor Action System Response A1. Resumes at step 4 Alternative B – Step 4 – System finds that not all attendees are available. Actor Action System Response B1. Suggests alternative time within upcoming week B2. Accepts suggested time. Submits changes B3. Resumes at step 5 Alternative C – Step B2 – User enters alternative time. Actor Action System Response C1. Submits changes. C2. Resumes at step 5. Alternative D – Step A1 – User delete meeting. Actor Action System Response D1. User chooses to delete meeting. D2. Resumes at step 5. 8.2.6

Use Case Description – Edit Meeting

Application name Use Case ID Overview of Use Case Actors Relationships Pre-Conditions

Post-Conditions Constraints Exceptions Includes

Extends Special Requirements Notes and Issues 8.2.6.1

MC UC-MC-006 Cancel a Meeting existing in MC system MC User N/A
A meeting exists in the system
A User registered with MC system
A User logged in to the MC system
A User views a calendar The meeting is cancelled The User must be an owner of the Meeting N/A
Browse Meeting
Send Notification
Update user’s calendar N/A N/A N/A

Primary Flow of Events

Actor Action 1. Chooses a Meeting on the calendar

System Response

RMIT University © 2006 School of Computer Science and Information Technology

26 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

2. Shows details of the Meeting 3. Deletes the Meeting 4. Displays a confirmation message box 5. Confirms deletion of the Meeting 6. Sends notification to all attendees about cancelled meeting 7. Updates attendees’ calendars 8. End of Use Case 8.2.6.2

Alternative Flow of Events

Alternative A – Step 5 – User rejects deletion of the Meeting. Actor Action System Response A1. Resumes at step 8 8.2.7

Use Case Description – Register New User

Application name Use Case ID Overview of Use Case Actors Relationships Pre-Conditions

Post-Conditions Constraints Frequency of Use Exceptions Includes Extends Special Requirements Notes and Issues 8.2.7.1

MC UC-MC-007 Allow any user of company to register new user in MC system. User (Manager or Staff) User must has an EmployeeID delivered by company, and input EmployeeID as MC UserID
User must select password according to predefined validation rule.
An associated UserRole (Manager/Employee) has been predefined in system and will be assigned accordingly by UserID. User is registered with the system. Only an administrator can add Administrator role to a registered user. High in new delivering, Medium in normal operation. N/A
Create New User
Create New User Calendar
System Validate UserID User EmployeeID must exist in Employee table


N/A

Primary Flow of Events

Actor Action 1. Accesses the registration interface. 2. Inputs EmployeeID as UserID, a password structured according to the suggestion information on screen.

System Response

3.

Validates UserID against Employee table.

RMIT University © 2006 School of Computer Science and Information Technology

27 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

4. 5. 8.2.7.2

Creates new user in the MC system with entered userID and password. End of Use Case

Alternative Flow of Events

Alternative A – Step 3 – System finds that the userID is not in Employee table Actor Action System Response A1. Displays an error message advising that user is not eligible for registration. A2. End of Use Case 8.2.8

Use Case Description – Change User Information

Application name Use Case ID Overview of Use Case Actors Relationships Pre-Conditions Post-Conditions Constraints Frequency of Use Exceptions Includes Extends Special Requirements Notes and Issues 8.2.8.1

MC UC-MC-008 Allow any registered user to change user information. User (Manager or Staff) User must login before change registration information. User changes own details in the system.
User cannot change UserID. High in new delivering, Medium in normal operation. Only an administrator can add Administrator role to a registered user.
Create New User
Create New User Calendar
System Validation N/A N/A

Primary Flow of Events

Actor Action 1. Activates Change User Detail interface. 2. Changes user password according to an appeared password validation suggestion. 3. Submits changes.

System Response

4. 5. 6. 8.2.8.2

Validates the password according to a predefined validation rule. Changes password in the system. End of Use Case

Alternative Flow of Events

RMIT University © 2006 School of Computer Science and Information Technology

28 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

Alternative A – Step 2 – User changes own details instead of changing password Actor Action System Response A1. Submits changes. A2. Changes user’s details in database. A3. End of Use Case 8.2.9

Use Case Description – Remove User

Application name Use Case ID Overview of Use Case Actors Relationships Pre-Conditions Post-Conditions Constraints

Frequency of Use Exceptions Includes

Extends Special Requirements Notes and Issues 8.2.9.1

MC UC-MC-009 Allow to remove registered user from MC system. Administrator Administrator must login before remove users. User deleted from the system.
Only administrator can remove users.
Only administrator can add an administrator role to a registered user.
User cannot change UserID. High in new delivering, Medium in normal operation.
Delete user’s individual Calendar
Delete groups created by the particular user.
Delete meetings created by the particular user.
System Validation N/A N/A

Primary Flow of Events

Actor Action 1. Activates Remove User interface. 2. Browse users, selects the user to remove. 3. Submits transaction.

System Response

4. 5.

6. 8.2.9.2

Removes user from user registration database. Deletes the individual calendar and all the meetings and groups created by this user. End of Use Case

Alternative Flow of Events

Alternative A – Step 3 – User cancels transaction Actor Action System Response A1. End of Use Case

RMIT University © 2006 School of Computer Science and Information Technology

29 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

9

Groupware System Group OAK

Class Diagram

Figure 11 and Figure 11 show Packages and the Class Diagram for MC system. Class Diagram shows all the relationships between classes and attributes and methods of each class. Project system did not try to elaborate on System classes. We have assumed that some of the methods implemented in System to provide Users with functionalities like Browsing Users, Groups and Meetings.

Meeting Calendar

GUI

Database

MC Business Logic

Figure 10: Packages Diagram

RMIT University © 2006 School of Computer Science and Information Technology

30 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

UserCalendar -owner -meetingList -busyTimes -startTime -endTime +addCalendar() +updateCalendar() +checkAvailability() +validateTime() +setDateTime()

0..*

1

1

1 User

Groupware System Group OAK

Meeting -subject -description -location -startTime -endTime -attendeeList -owner +addMeeting() +updateMeeting() +setMeetingDetails() +getMeetingDetails()

System Notification +sendSystemNotification()

User Notification +sendUserNotification()

1

send

1..* Attendee -attendeeID -name -attendeeType +getName() +setName() +getAttendeeType() +setAttendeeType()

-userID -password -role +addUser() +updateUser() +addToGroup() +removeFromGroup() +getGroups() +regUser()

Manager

Admin

+viewUserCalendar() +setGroupSpecialAttribute()

+sendSystemNotification() +deleteUser() +deleteUserCalendar() +deleteNotification() +cancelUserMeetings()

Notification -notificationID -subject -description -notifyLevel -notificationFrom -notificationToList +logNotification()

send Group -groupDescription -attendeeList -groupOwner +saveGroup() +updateGroup() +listAttendees() +addAttendees() +deleteAttendees() +getOwner()

Special User Group -isUserAllowedToRemove +setIsUserAllowedToRemove()

Figure 11: MC Business Logic Class Diagram

9.1

Class Diagram Description

In order to comply with the function that it was designed for, Meeting Calendar system has the classes showed in the class diagram section. As can be seen in the diagram, the following are the main classes for the system:

RMIT University © 2006 School of Computer Science and Information Technology

31 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)






9.1.1

Groupware System Group OAK

Meeting Attendee User Group Notification Meeting Class

Meeting class is the one that holds the information related with meetings which are created by users. The following describes the class attributes and relationships with other classes. The attributes related with this class allows the system to get enough information related with the meetings; subject, description, start time, end time and attendee list. To interact with the rest of the system meeting class has the following relationships: Association: With user calendar because each user calendar could have zero or many meetings. And with notification class which is used to send notification to the users Composition: A meeting is composed by attendees, without attendees a meeting cannot be created.

9.1.2

Attendee Class

This is a super class that contains entities that belongs to a meeting (attendees). For instance, one attendee can be a user or a group. As described above, attendee class is a super class. For instance, group and user derived from attendee class. Moreover an attendee could be users, groups or both.

9.1.3

User Class

User class is another super class of the MC system. In general, user is everyone who uses the system that is why its attributes are password and user id. This class, as described above, is derived from attendee class. User class has the following relationships with other classes. Association: with user calendar. A user calendar has only one calendar. Inheritance: Manager and Admin classes inherit from user class. Composition: A group class is composed by one or many users

9.1.4

Group Class

Group class is another super class of the MC system. Groups are created to hold users that are going to be invited for meeting. The group relationships with other class are:

RMIT University © 2006 School of Computer Science and Information Technology

32 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

Inheritance: Group class inherits from attendee class. Additionally Special User Group class inherits from group class. Association: Group class uses notification class to send information to users related to group creation. Composition: Group class is composed by users. It could contain one or many users.

9.1.5

Notification Class

Notification class is used by MC system to send information to users related with meetings and groups. Notification class has the following relationships: Association: Group and Meeting use Notification Class to send information related with them. Inheritance: User notification inherits from Notification

RMIT University © 2006 School of Computer Science and Information Technology

33 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

10 Sequence Diagrams Following pages contains Sequence Diagrams for major Use Cases described in section 8. Each diagram shows the interaction and communication between objects over the time. These diagrams do not show the system object.

10.1 Sequence Diagram – Create Group

Figure 12: Sequence Diagram Create Group

RMIT University © 2006 School of Computer Science and Information Technology

34 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

10.2 Sequence Diagram – Edit Group

Figure 13: Sequence Diagram Edit Group

RMIT University © 2006 School of Computer Science and Information Technology

35 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

10.3 Sequence Diagram – Create Meeting

Figure 144: Sequence Diagram Create Meeting

RMIT University © 2006 School of Computer Science and Information Technology

36 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

10.4 Sequence Diagram – Edit Meeting

Figure 15: Sequence Diagram Edit Meeting

RMIT University © 2006 School of Computer Science and Information Technology

37 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

10.5 Sequence Diagram – User Management

DB Controller

Database

User

Alt

regUser() ValidateID() Success addUser() addCalendar()

«inherits»

regUser() ValidateID() Failed

chgUserPassword() ValidatePassword() Success updUser()

Administrator

RemoveUser() delUser() delCalendar() delGroup() delMeeting()

Figure 16: Sequence Diagram User Management

RMIT University © 2006 School of Computer Science and Information Technology

38 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

11 Activity Diagrams Following pages shows the Activity diagrams for major use cases defined in section 6. Each diagram shows different activities in the order in which they are executed.

11.1 Activity Diagram – Create Group

Figure 17: Activity Diagram Create Group

RMIT University © 2006 School of Computer Science and Information Technology

39 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

11.2 Activity Diagram – Edit Group

Figure 18: Activity Diagram Edit Group

RMIT University © 2006 School of Computer Science and Information Technology

40 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

11.3 Activity Diagram – Create Meeting

Figure 19: Activity Diagram Create Meeting

RMIT University © 2006 School of Computer Science and Information Technology

41 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

11.4 Activity Diagram – Edit Meeting

Figure 20: Activity Diagram Edit Meeting

RMIT University © 2006 School of Computer Science and Information Technology

42 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

11.5 Activity Diagram – Register New User

Figure 21: Activity Diagram Register New User

11.6 Activity Diagram – Change User Information

Figure 22: Activity Diagram Change User Information

RMIT University © 2006 School of Computer Science and Information Technology

43 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

11.7 Activity Diagram – Remove User

Figure 23: Activity Diagram Remove User Information

References Deacon, John, 2005, Object-Oriented Analysis and Design A Pragmatic Approach , Addison Wesley, Harlow. Miles, R & Hamilton, K, 2006, Learning UML 2.0, O’Reilly, Sebastopol. Morris, Ed., 2006, ISYS1117/1118 Software Engineering: Analysis and Design, course notes, RMIT University, Melbourne. Pilone, D, 2005, UML 2.0 In a Nutshell, O’Reilly, Sebastopol. Pfleeger, Shari Lawrence, 2006, Software Engineering Theory and Practice 3rd Edition, Prentice Hall, New Jersey.

RMIT University © 2006 School of Computer Science and Information Technology

44 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

12 Annex 1 - Gantt Chart

RMIT University © 2006 School of Computer Science and Information Technology

45 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

RMIT University © 2006 School of Computer Science and Information Technology

Groupware System Group OAK

46 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

RMIT University © 2006 School of Computer Science and Information Technology

Groupware System Group OAK

47 of 48 Melbourne, 15th October, 2006

Meeting Calendar System (MC) Milestone 3: Design Proposal (DP)

Groupware System Group OAK

13 Discussion of issues The major issues were caused by team work coordination, especially when 2 of team members are taking this course as part time and could not attend each meeting as planned. In order to reduce the impact of absence of meeting, we use much the team forum to discuss and update results. We highly appreciate the member who setup the platform. On the other hand, because it was impossible to attend the meeting by all of the members together, we did not get chance to discuss about the team leadership and select a team leader.

Beyond the limitation, each of us showed strong ownership during the whole

project. As soon as a suggestion raised by anyone, it will be discussed by others, and then the required action will be taken. So the team was naturally shaped to a federal structure, and took action much efficiently. Thanks for the professional knowledge and passion from every members. Except

team

work,

we

discussed

much

in

solutions selection, classes naming,

documentation structure and the other issues in particular design objectives. It’s do a difficult job to keep consistent and complete during the whole processes. The customer requirements were always brought to review for arguments.

14 The strengths and weaknesses of design The strengths: •

Thanks two of the members who has professional experiences in application development, we kept on discussed the UML models and concept in clear.

•

The comprehensive requirement analysis provided by two of the members in previous stage gave clear scope, constraint and required elements for design stage.

•

The MC system will provide necessary system automation for operation, as well as the necessary human operations according to company processes. This gives a balanced system with enough functions and keeps a simple structure, to achieve the user requirements in reasonable development cost.

Weaknesses: •

Because the user interface and data flow were not discussed in this assignment, we did not get chance to interchange the system functions and behaviour with user.

•

Because the back-end systems were not discussed in this stage, the present design may ignore the influences caused by system performance, application architecture and data storage.

RMIT University © 2006 School of Computer Science and Information Technology

48 of 48 Melbourne, 15th October, 2006