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) Groupware System
Milestone 3: Design Proposal (DP) 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 2 of 48

School of Computer Science and Information Technology Melbourne, 15th October, 2006
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
6 Summary of Solution......................................................................................................................13
7 Other optional solutions................................................................................................................14
7.1 To register new user ............................................................................................................14
7.2 To Deal with meeting conflicts: ........................................................................................16
8 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.3 Use Case Description – Delete Group ........................................................................23
8.2.4 Use Case Description – Create Meeting....................................................................24
8.2.5 Use Case Description – Edit Meeting..........................................................................25
8.2.6 Use Case Description – Edit Meeting..........................................................................26
8.2.7 Use Case Description – Register New User.................................................................27
8.2.8 Use Case Description – Change User Information ...................................................28
8.2.9 Use Case Description – Remove User .........................................................................29
9 Class Diagram ................................................................................................................................30
9.1 Class Diagram Description ................................................................................................31

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

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

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 Scope
2.1 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.

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.

3 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;
There is a server where MC database can be installed;
The TCP/IP is the common protocol used in LAC network;
4 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.

4.3 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 Customers of LAC, Major sector clients of LAC
5 Requirements
Following sections describe the functional requirements (see Section 5.1) and non-
functional 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.

5.1.1.9 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 Physical Environment
5.2.1.1 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.

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 according to administration: Employees information,

registration.
5.2.3 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.

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 The system must be developed with standard tools which allow it to be
maintainable.
5.4 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.

5.4.1.4 The MC must be able to handle up to 300 concurrent user sessions across LAC
intranet.
5.4.2 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 Maintainability
5.4.5.1 The system must be able to be integrated with email, WWW and customer
relationship management systems.
6 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.

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.

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.

7.2 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.

8 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

8.1.2 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

8.1.4 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

8.1.6 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

8.1.9 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 MC
Use Case ID UC-MC-001
Overview of Use Case Create a Group in MC system
Actors MC User
Relationships <includes> Add Attendee
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 created.
Constraints N/A
Frequency of Use 1-5 times per a day
8.2.1.1 Primary Flow of Events

Actor Action System Response
1. Chooses to create a new Group.
2. Populates Group Details.
3. Add Participants to the Group.
<includes> Add Attendee
4. Submit the new Group.
5. Shows the confirmation message.
6. Accept creation of the Group.
7. Create Group in the System.

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
A1. End of Use Case.
8.2.2 Use Case Description – Edit Group

Application name MC
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.
Post-Conditions The group is updated.
Constraints N/A
Frequency of Use

1. Chooses a Group in the list. Opens group.
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.

Alternative A – Step 3 – User removes a participant from the list. Submits changes
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.
B1. Check if user is a Manager User and
owner of the group.
B2. Resumes at step A3.

Alternative C – Step B1 – System finds that user is not a Manager user or is not an owner of
the group.
C1. Displays an error message.
C2. End of Use Case.
Alternative D – Step A3 – User rejects removal of a participant.
D1. End of Use Case.
Alternative E – Step 3 – User changes Details of the Group. Submits changes
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
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.
Post-Conditions The group is deleted.
Constraints The User must be an owner of the Group or Administrator of the system.
Frequency of Use

1. Chooses a Group from the group list. Open
the Group.
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.

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

8.2.4 Use Case Description – Create Meeting
Application name MC
Overview of Use The User chooses to create a meeting in the system
Case
Actors MC User
Relationships N/A
Pre-Conditions A User registered with MC system
A User logged in to the MC system
A User views a calendar
Post-Conditions The meeting has been created
Constraints N/A
Exceptions N/A
Includes Add Attendees
Browse Attendees
Check User’s availability
Send Notification
Extends Set meeting details
Validate meeting details
Update invitees’ calendar
Meeting conflict
Special N/A
Requirements
Notes and Issues N/A

1. Chooses to create a meeting
2. Introduces meeting details
3. Selects start and end time for the
meeting
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.

Alternative A – Step 8 – User changes Attendees list.
A1. Resumes at step 6.

Alternative B – Step 6 – System finds that not all attendees are available.
B1. Suggests alternative time within
upcoming week
B2. Accepts suggested time
B3. Resumes at step 8
Alternative C – Step B2 – User enters alternative time.
C1. Submits changes
C2. Resumes at step 6
8.2.5 Use Case Description – Edit Meeting
Application name MC
Overview of Use Edit a Meeting existing in MC system
Case
Actors MC User
Relationships N/A
Pre-Conditions A meeting exists in the system
A User registered with MC system
Post-Conditions The meeting is updated
Constraints The User must be an owner of the Meeting
Exceptions N/A
Includes Browse Attendees
Check User’s availability
Send Notification
Extends Update meeting details
Validate meeting details
Update invitees’ calendar
Meeting conflict
Delete Meeting
Update Attendees
Special N/A
Requirements

1. Chooses a Meeting on the calendar
2. Shows details of the Meeting
3. Changes scheduled time for the
Meeting. Submits changes
4. Checks selected users’ availability
about updated meeting

6. Updates attendees’ calendars

7. End of Use Case

Alternative A – Step 3 – User changes Attendees list.
A1. Resumes at step 4
Alternative B – Step 4 – System finds that not all attendees are available.
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.
C1. Submits changes.
C2. Resumes at step 5.
Alternative D – Step A1 – User delete meeting.
D1. User chooses to delete meeting.
D2. Resumes at step 5.
8.2.6 Use Case Description – Edit Meeting
Application name MC
Overview of Use Cancel a Meeting existing in MC system
Case
Actors MC User
Relationships N/A
Pre-Conditions A meeting exists in the system
A User registered with MC system
Post-Conditions The meeting is cancelled
Constraints The User must be an owner of the Meeting
Exceptions N/A
Includes Browse Meeting
Send Notification
Update user’s calendar
Extends N/A
Special N/A
Requirements

1. Chooses a Meeting on the calendar

2. Shows details of the Meeting

3. Deletes the Meeting
4. Displays a confirmation message box
5. Confirms deletion of the Meeting
about cancelled meeting
7. Updates attendees’ calendars
8. End of Use Case

Alternative A – Step 5 – User rejects deletion of the Meeting.
A1. Resumes at step 8
8.2.7 Use Case Description – Register New User
Application name MC
Overview of Use Allow any user of company to register new user in MC system.
Case
Actors User (Manager or Staff)
Relationships
Pre-Conditions 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.
Post-Conditions User is registered with the system.
Constraints Only an administrator can add Administrator role to a registered
user.
Frequency of Use High in new delivering, Medium in normal operation.
Exceptions N/A
Includes Create New User
Create New User Calendar
Extends System Validate UserID
Special User EmployeeID must exist in Employee table
Requirements

1. Accesses the registration interface.
2. Inputs EmployeeID as UserID, a
password structured according to the
suggestion information on screen.
3. Validates UserID against Employee
table.

4. Creates new user in the MC system

with entered userID and password.
5. End of Use Case

Alternative A – Step 3 – System finds that the userID is not in Employee table
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 MC
Overview of Use Allow any registered user to change user information.
Case
Actors User (Manager or Staff)
Relationships
Pre-Conditions User must login before change registration information.
Post-Conditions User changes own details in the system.
Constraints User cannot change UserID.
Exceptions Only an administrator can add Administrator role to a registered
user.
Includes Create New User
Create New User Calendar
Extends System Validation
Special N/A
Requirements

1. Activates Change User Detail
interface.
2. Changes user password according to
an appeared password validation
suggestion.
3. Submits changes.
4. Validates the password according to
a predefined validation rule.
5. Changes password in the system.
6. End of Use Case

Alternative A – Step 2 – User changes own details instead of changing password

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 MC
Overview of Use Allow to remove registered user from MC system.
Case
Actors Administrator
Relationships
Pre-Conditions Administrator must login before remove users.
Post-Conditions User deleted from the system.
Constraints Only administrator can remove users.
Only administrator can add an administrator role to a
registered user.
User cannot change UserID.
Exceptions
Includes Delete user’s individual Calendar
Delete groups created by the particular user.
Delete meetings created by the particular user.
Extends System Validation
Special N/A
Requirements

1. Activates Remove User interface.
2. Browse users, selects the user to
remove.
3. Submits transaction.
4. Removes user from user registration
database.
5. Deletes the individual calendar and all
the meetings and groups created by
this user.
6. End of Use Case

Alternative A – Step 3 – User cancels transaction
A1. End of Use Case

9 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

Meeting
-subject
-description System Notification
-location
-startTime
-endTime +sendSystemNotification()
-attendeeList
0..* -owner
UserCalendar
+addMeeting()
-owner User Notification
+updateMeeting()
-meetingList
1 +setMeetingDetails()
-busyTimes
+getMeetingDetails() +sendUserNotification()
-startTime
-endTime
1
+addCalendar()
send
+updateCalendar()
+checkAvailability() Notification
+validateTime() -notificationID
+setDateTime() -subject
1..*
-description
1 -notifyLevel
Attendee
-notificationFrom
-attendeeID
-notificationToList
-name
-attendeeType +logNotification()
+getName()
1
+setName()
+getAttendeeType()
send
User +setAttendeeType() Group
-userID
-password -groupDescription
-role -attendeeList
-groupOwner
+addUser()
+updateUser() +saveGroup()
+addToGroup() +updateGroup()
+removeFromGroup() +listAttendees()
+getGroups() +addAttendees()
+regUser() +deleteAttendees()
+getOwner()
Manager Admin
Special User Group
+sendSystemNotification() -isUserAllowedToRemove
+viewUserCalendar()
+deleteUser() +setIsUserAllowedToRemove()
+setGroupSpecialAttribute()
+deleteUserCalendar()
+deleteNotification()
+cancelUserMeetings()
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:

Meeting
Attendee
User
Group
Notification
9.1.1 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:

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

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

10.2 Sequence Diagram – Edit Group
Figure 13: Sequence Diagram Edit Group

10.3 Sequence Diagram – Create Meeting
Figure 144: Sequence Diagram Create Meeting

10.4 Sequence Diagram – Edit Meeting
Figure 15: Sequence Diagram Edit Meeting

10.5 Sequence Diagram – User Management
DB Controller Database
User
Alt regUser()
ValidateID()
Success
addUser()
addCalendar()
«inherits» regUser()
ValidateID()
Failed
chgUserPassword()
ValidatePassword()
Success
updUser()
RemoveUser()
Administrator
delUser()
delCalendar()
delGroup()
delMeeting()
Figure 16: Sequence Diagram User Management

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

11.2 Activity Diagram – Edit Group
Figure 18: Activity Diagram Edit Group

11.3 Activity Diagram – Create Meeting
Figure 19: Activity Diagram Create Meeting

11.4 Activity Diagram – Edit Meeting
Figure 20: Activity Diagram Edit Meeting

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

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.

12 Annex 1 - Gantt Chart



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.


Software Engineering Analysis and Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering Analysis and Design

Uploaded by

Copyright:

Available Formats

Meeting Calendar

Software Engineering Analysis and Design

Meeting Calendar (MC) Management System, LAC

Professor: Ed. Morris

Melbourne, October 15th,2006

Table of Figures ........................................................................................................................................5

RMIT University © 2006 2 of 48

RMIT University © 2006 3 of 48

9.1.1 Meeting Class..................................................................................................................32

RMIT University © 2006 4 of 48

Figure 1: Use Case Overview...............................................................................................................17

RMIT University © 2006 5 of 48

Meeting Calendar System

RMIT University © 2006 6 of 48

2.2 Out of Scope

2.3 Out of Scope but will be appreciated

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

RMIT University © 2006 7 of 48

3 Assumptions and Dependencies

4.1 Executives of LAC

4.2 Functional Management of LAC

4.2.2 Sales manager and other operational managers;

4.2.3 IT Support manager, Who will be in charge of the system development,

4.2.5 Procurement department, Which will be in charge of products and service

RMIT University © 2006 8 of 48

4.3 Staffs of LAC

4.3.2 Office Administrators or Secretaries,

4.3.3 IT support engineers.

4.4 Supply Chain of the system

4.4.2 System development project manager

4.4.3 Deployment project manager

4.5 Customers of LAC, Major sector clients of LAC

5.1 Functional Requirements

5.1.1.6 Only a Manager can create special groups.

RMIT University © 2006 9 of 48

5.1.2.4 Information regards to specific meetings must be maintained in MC system for as

5.2 Design Constrains

5.2.1 Physical Environment

RMIT University © 2006 10 of 48

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 according to administration: Employees information,

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

RMIT University © 2006 11 of 48

Managers, identified during registration according to company employee

5.3 Process Constrains

5.4 Non-functional Requirements

RMIT University © 2006 12 of 48

5.4.2 Interface, Usability and Human Factors

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.4 Reliability and Availability

RMIT University © 2006 13 of 48

7 Other optional solutions

7.1 To register new user

Two of the optional registration processes has been discussed as following:

RMIT University © 2006 14 of 48

RMIT University © 2006 15 of 48

7.2 To Deal with meeting conflicts: