15527769_Assignment2_Pedro_Martins

of 42
Design Document
For Arty Farty Cinemas -AFC
2011
Pedro Martins
15527769
10/18/2011

of 42
Table of Contents
1. Introduction...................................................................................................................................6
1.1. The Purpose of The System..................................................................................................6
1.2. System Definition ..................................................................................................................7
1.3. Corrections to the Analysis ................................................................................................10
1.3.1. Class Diagram .................................................................................................................10
1.3.2. Event Table......................................................................................................................11
1.4. Quality Goals.......................................................................................................................12
2. Technical Platform......................................................................................................................13
2.1. Equipments..........................................................................................................................13
2.2. System Software..................................................................................................................14
2.3. System Interface..................................................................................................................15
2.4. Design Language.................................................................................................................15
3. Architecture.................................................................................................................................15
3.1. Component Architecture....................................................................................................15
3.2.1. Shared Resources........................................................................................................20
3.2.2. Deployment Diagram..................................................................................................21
4. Components.................................................................................................................................23
4.1.1. Log In Component ......................................................................................................24
4.1.2. Advertising Team Subsystem Component................................................................24
4.1.3. Office Manager Subsystem Component....................................................................26
4.1.4. Owner Subsystem Component...................................................................................28
4.2.1. Component Architecture Class Diagram..........................................................................30
4.2.2. Attributes & Operations Description................................................................................32
2. Recommendations.......................................................................................................................35
2.1. System Usefulness ...............................................................................................................35
2.2. Plan for Initiating Use.........................................................................................................37
2.2.1. Budgeting.........................................................................................................................37
2.3. Implementation Plan ..........................................................................................................38
References............................................................................................................................................39
Appendix..............................................................................................................................................40

of 42
List of Tables
Table 1 – Tasks performed per module...............................................................................................8
Table 2 – Modified Event Table.........................................................................................................12
Table 3 – Priority of design criteria...................................................................................................13
Table 4 – Equipments for AFC...........................................................................................................14
Table 5 – Required Software for AFC...............................................................................................14
Table 6 – Very Important criteria .....................................................................................................16
Table 7 – Attributes Description.........................................................................................................32
Table 8 – Operations Description.......................................................................................................33
Table 9 – Budget for IPA development..............................................................................................37

of 42
List of Figures
Figure 1 – Previous and modified Class Diagram.............................................................................11
Figure 2 – Component Architecture overview..................................................................................17
Figure 3 – Component Architecture for the Owner Subsystem. ....................................................18
Figure 4 – Component Architecture for the Office Manager Subsystem.......................................18
Figure 5 – Component Architecture for the Advertising Team Subsystem...................................19
Figure 6 – Deployment Diagram Overview.......................................................................................20
Figure 7 – Cooperating Objects..........................................................................................................21
Figure 8 – Deployment Diagram.........................................................................................................22
Figure 9 - Network Infrastructure for AFC. ....................................................................................23
Figure 10 –Interaction between Log In and other subsystems........................................................24
Figure11 – Advertising Team Subsystem: Interaction between UI and Function components...25
Figure 12 – Advertising Team Subsystem: Interaction between UI and Model components.......25
Figure 13 – Advertising Team Subsystem: Interaction between Function and Model components...........26
Figure 14 – Office Manager Subsystem: Interaction between UI and Model components..........26
Figure 15 – Office Manager Subsystem: Interaction between UI and Model components..........27
Figure 16 – Office Manager Subsystem: Interaction between Function and Model components..............27
Figure 17 – Owner Subsystem: Interaction between UI and Function components.....................28
Figure 18 – Owner Subsystem: Interaction between UI and Model components..........................29
Figure 19 – Owner Subsystem: Interaction between component Function and Model................29
Figure 20 – Component Architecture Class Diagram......................................................................31
Figure 21 – Component Architecture Class Diagram: Function and Model connection..............31
Figure 22 – Event Placement...............................................................................................................34
Figure 23 – System Behaviour Statechart..........................................................................................35
Figure 24 – Project Schedule...............................................................................................................38

of 42
Executive Summary
This document is an extension of the developed Analysis Document. This document highlights and
mention important aspects of an Design Document such as system’s quality goals, technical
platform, component architecture, process architecture, and so on. Moreover, it makes several
recommendations regarding to system usefulness, a plan for initiating use, and an implementation
plan.

of 42
1. Introduction
1.1.The Purpose of The System
Arty Farty Cinemas has been facing many problems in different areas due to the
lack of integration present on its processes and operations (hereafter, Arty Farty
Cinemas will be referred as AFC). Consequently, AFC has low communication level
and inefficient tracking and execution of crucial activities that are frequently done
within the company, thus negatively affecting the whole company.
Some of the major difficulties that AFC’s owners are experiencing now are:
 keeping track of all of the information and materials that they receive and use
about available films;
 providing the owners with easy access to the materials about each available
film
 tracking which owners have viewed which materials and, for each owner,
which films and materials he or she has viewed;
 ensuring that all of the owners view the available materials;
 communicating opinions and preferences about available films to the other
owners;
 scheduling films so that the different theatre resources are used efficiently and
a minimum number of copies of the film are rented;
 recording decisions about which films to purchase and when they are
scheduled to be shown;
 notifying the office manager (Richard Roxbury) of the decisions so that he can
order the films from suppliers and;
 providing the schedule and all the informational materials about films to the
cooperative’s advertising staff (Charlie and Howard).
Therefore, the priority for AFC is to implement the Integration of Processes and
Activities for Arty Farty Cinemas (IPA4AFC, also known as IPA). This system will
play an important role within AFC by managing, controlling and integrating important
areas of the company, such as:

of 42
 Tracking;
 Recording;
 Communication;
 Scheduling;
 Procurement.
Hence, develop a system that integrates all those areas can be a powerful tool to
manage many different activities, thus providing extra support to managers for taking
strategic decisions, as well as improving company’s efficiency and production.
1.2. System Definition
The system will be used to integrate and rapidly execute many different activities
done by AFC employees, such as recording documents, tracking materials, retrieving
files, scheduling films and session time for each cinema, ordering films, and
communicating internally. Additionally, it must give fast response to all potential
users, in order to improve the company’s performance and efficiency by increasing
data sharing speed between cinema owners and office staff. The system, IPA4AFC,
must be capable of updating an owner decision and send them to the interested parts,
thus improving quality and speed of the operation within Arty Farty Cinemas, as well
as information accuracy. Every operation executed by the system must be compatible
with Microsoft Windows operational system and the company’s latest softwares, such
as Microsoft Office 2010.
In order to present AFC’s new system capabilities, the FACTOR methodology
(Mathieassen, et al. 2000) is used for explaining in more details the system definition.
Functionality
The system aims to improve AFC performance and benefits, and it is divided in
five different modules (documentation, tracking, communication, scheduling, and
procurement). Therefore, the system must execute tasks that integrate all crucial
activities that demands rapid processing. Moreover, it also serves users with relevant
information that will help them to carry on with other different tasks. Table 1 shows
the major tasks that should be executed by the new system, per module.

of 42
IPA Modules Tasks Performed
Recording System  Store and allow data mining from all
film materials that have been previously
purchased.
 Allocate materials received about films
available.
 Allow data mining of all materials for
the advertisement team use.
Tracking System  Seize information from Recording
System so Cinema owner can mark as
‘Read’ the materials available.
Communication System  A channel where cinema owners and
top managers can exchange suggestions
and preferences about films.
 A tool where AFC members can share
knowledge and experience.
Scheduling System  Scheduling of films and which theatre it
will be shown.
 Allow advertising team to retrieve films
schedule.
Procurement System  Record current purchasing of films
from suppliers.
 Provide the office manager with
information about which film to
purchase
Table 1 – Tasks performed per module
Application Domain
The system is designed to be used by Arty Farty Cinema’s employees. It must be
able to execute tasks, such as:
 Log In
 Record Film Materials
 Retrieve Film Materials
 Send Opinion
 Mark Viewed Materials
 Record Schedule
 Retrieve Schedule
 Create Schedule
 Add New Film
 Mark Favourite Materials
 Record Decision
 Update Decision
 Mark Preferred Materials
 Order Film

of 42
Conditions
The system should be designed to work cooperatively with other softwares and system
that are currently used by staff, such as Microsoft Office 2010 and windows Operational
System. Furthermore, it should be easy to operate and rapidly execute tasks.
Technology
 New laptops
 Windows PC Operational System
 Equipped with Microsoft Office 2010
 Broadband Internet
 Large Hard Disks
Objects
The system must administer, monitor and control many different types of objects, such as:
 Supplier  Decision
 Cinema  Office Staff
 Order  Owner
 Film Materials  Advertisement
 Schedule  Session
 Opinion  Film
Responsibility
The new system must be designed to be easy to operate by end users and give fully support
for important tasks, for example review of materials, and tracking and reporting of viewed
materials. Therefore, it should work smoothly with other systems and software and impact
positively on the company’s performance, and not become a primary issue.

of 42
1.3. Corrections to the Analysis
Some deliverables and concepts need to be revised, in order to proceed with the
design document. Therefore, this section aims to put into evidence the changes that
were necessary to do on the analysis document.
1.3.1. Class Diagram
A few changes were made in the class diagram presented in the Analysis
Document.
Firstly, a class named Office Staff was created as a generalization for the
existing Advertising Team and Office Manager classes. This modification is done
in order to demonstrate that all office staff work with film materials, and,
consequently, a single relationship is established between the classes Film
Materials and Office Staff.
Secondly, the classes Film and Session were aggregated to the class Cinema,
since the objects from the first two classes are a decomposition of the objects of
the latter.
Finally, as presented on the previous class diagram, some classes such as
Supplier, Customer, Customer Order, Invoice and Order were discarded from the
class diagram to avoid scope creep, since they do not need to be administered,
monitored and controlled by the proposed system.
The following figure demonstrates the previous and new proposed class
diagram for the development of the IPA system.

of 42
Figure 1 – Previous and modified Class Diagram
Previous Class Diagram
Modified Class Diagram
1.3.2. Event Table
Likewise, the event table also needed to be changed, since few classes were
inserted and deleted. Also, it was identified that some events were out of scope
and did not need to be administered, monitored and controlled by the system.
Table 2 shows in details the modified version of the event table.
Advertising
Team
Office Staff
Office
Manager
Film
Materials
Advertisement
Schedule
Film
Cinema
Owner
1Assigns
1
1..*
1..*
Advertises1..* 1
1..* Makes  About 
About
0 ..*
0 ..*
1..*
1..*
Opinion  Sends
0..*
1
Session
1..*
1
0..*
Supplies
Retrieves0..*
1..*
Supplier
Decision1
1
1
Supplies
0..*
1
About
0..*
1..*
0 ..* Retrieves
0..*
Order
Places
0..*
1

of 42
Table 2 – Modified Event Table
1.4.Quality Goals
A design criteria needs to be developed for identifying which quality goals
should be taken into consideration when developing the architectural design.
Table 2 demonstrates the priority of design criteria. As it shows, the system’s
major priorities are accuracy, reliability, and maintainability. Those qualities were
acknowledged based on the system characteristics and capabilities, such as providing
all users with correct data and simple enough even for correcting system defects.
Additionally, the software must be available to be used whenever is required, and
free of bugs and inconsistencies, since the system will assist users on taking further
business decisions, such as scheduling.
In order to maintain the application running properly, the whole system needs to
be divided into three different subsystems with different user interface for each one
Office
Staff
Office
Manager
Advertising
Team Advertisement Cinema Owner Opinion Film Session
Film
Materials Schedule Supplier Decision Order
Cinema Closed Down X * * X
Cinema Inoperative X * *
Cinema Film Updated X X
Decision Made X X
Film Cancelled X * X *
Film Distributed * X X X
Film Materials Decided X X
Film Materials Received X X X X
Film Materials Recorded X X X
Film Materials Retrieved * * *
Film Ordered X X X
Film Purchased * X
Film Recorded * X
Office Staff Hired X X X
Office Staff Left X X X
Office Staff Work Interrupted * * *
Opinion Received * X *
Opinion Replied * X *
Opinion Sent * X *
Order Placed X X
Owner Contracted X
Schedule Assigned * * * * * * * X
Schedule Created X X
Schedule Decided * X *
Schedule Deleted X X
Schedule Recorded X X
Schedule Retrieved * * *
Schedule Updated * X
Session Scheduled * * X
Decision Status Updated * * * X
CLASS
EVENT

of 42
of them. This measure make easy for developers to maintain a sufficient level of
independence between the subsystems, that allows them to fix errors and bugs in one
subsystem, without having to shut down the whole system.
Criterion Very
Important
Important Less
Important
Irrelevant Easily
Fulfilled
Usable X
Secure X
Efficient X
Correct X
Reliable X
Maintainable X
Testable X
Comprehensible X
Reusable X
Interoperable X
Flexible X
Accuracy X
Table 3 – Priority of design criteria
2. Technical Platform
2.1.Equipments
Arty Farty Cinemas has fairly new laptops, which are capable of running the
latest versions of Windows. Therefore, accordingly to the current AFC’s
technological infrastructure, the design and development of the new system will be
done on Windows environment, in order to avoid any type of incompatibility that
might occur during the implementation phase, which may increase costs and extend
project’s conclusion.
Besides, the system mainly functions are storage and data mining. Therefore, the
company server will play a major role in the system functioning due to the intensive
interaction between client computers and server. However, documents and
applications that are out of the problem domain, such as individual spreadsheets, film
trailers, and Microsoft Office 2010 can be stored in the local hard disks.
Moreover, Table 4 highlights the basic equipments required for the deployment
of IPA4AFC and the current ones.

of 42
Current Equipments Required Equipments
 New laptops.
 Broadband Internet.
 Large Hard Disks.
 Database server.
 New personal computers compatible with
the latest Windows versions.
 Large Hard Disks for local data storage,
such as film trailers.
 Server for centralising data and system.
 Broadband Internet for communication,
fast access to company’s server, and
rapid data processing.
Table 4 – Equipments for AFC
Hence, there is no need to purchase further equipments to support the new
system, as Arty Farty Cinemas already have them.
2.2.System Software
AFC does not have software to handle the basic company operations. However,
employees currently have installed the latest version of Windows Operational System
in their laptops, which allows access to web browsers and other softwares, such as
Microsoft Office 2010.
Hence, the system will be developed on the most recent Windows platform, and it
will be programmed based on Visual Studio 2010, coded in C# syntax, which allows
programmers to have different classes for handling several user-interface elements.
Table 5 relates the current and required softwares required for the development
and deployment of IPA system.
Current Software Required Software
 Windows PC Operational System
 Microsoft Office 2010
 Web browser
 Latest Windows Operational System
 Visual Studio 2000
 Database Management System (DBMS)
Table 5 – Required Software for AFC

of 42
2.3.System Interface
The system’s operations and processes are based on a client-server architecture,
in which the component function and model are held within the server, and only the
user interface is handled by the client computers. Therefore, IPA4AFC is a relatively
simple system that does not need to develop any type of system interface.
2.4.Design Language
The standard modelling used for describing IPA’s design language is based on
the Unified Modelling Language (UML). It helps to, create, modify and document the
artefacts of an object-oriented system under development. Moreover, UML gives a
standard way to organise and structure elements such as:
 Activities
 Actors
 Business Processes
 Components
 Processes
UML makes use of a variety of modelling techniques and combines them in a
single modelling language. Some of the techniques adopted by UML are:
 data modelling (entity relationship diagrams);
 business modelling (work flows);
 object modelling;
 component modelling.
3. Architecture
3.1.Component Architecture
Prior to show in more details how each component interacts with each other, an
overview of the component architecture is demonstrated in this section.
Since the system is available for different types of users (advertising team, office
manager and cinema owners), who perform distinct tasks, each group of users will

of 42
require special interfaces. As a result, the system can be collapsed in three different
subsystems:
 Advertising Team Subsystem
 Office Manager Subsystem
 Owner Subsystem
Once those three types of subsystems have been identified, it is required to create
a component for each one of them, as they have different user interfaces objects that
interact with specific functions and models. Additionally, it is relevant to mention that
all the system’s functions and models are handled by the database server.
Another important step is to match the system architecture to the quality goals.
Therefore, only the criteria classified as ‘Very Important’ is justified in this section, as
follow:
Accurate In order to maintain crucial information correct and updated, all the
data should be stored in a single server, and any alteration within the
model will occur in a centralised server. This measure helps to
preserve the integrity of the data and avoid any anomalies, such as
data duplication and inconsistency, thus providing other users with
accurate information.
Reliable It is crucial that the system achieves the minimum level required of
precision in function execution. Therefore, like the Model, the
Function components for all subsystems are allocated within the
server, concentrating all the system’s function in a centralised
server.
Maintainable Maintainability is also appointed as one of the most important
features for IPA4AFC. As a result, the Client component have been
collapsed in different subsystem, which helps system developers to
locate and fix system bugs more efficiently and less costly.
Table 6 – Very Important criteria

of 42
Based on those criteria, an overview of the system’s basic components (Log In,
Client, Server, Database Management System (DBMS), and User Interface Library) is
presented in Figure 2, and how they are connected.
Each subsystem has a distinct user interface (UI), thus resulting in separate them
in different components. However, objects from different UI execute common
functions and, in some cases, interact with the same objects within the model.
Additionally, it is important to bear in mind that the Function and Model components
are handled by the server.
Figure 2 – Component Architecture overview
With the purpose of refining the figure above, each subsystem is individually
shown, with addition to the User Interface (UI), Function and Model components.
However, the details and how each component interacts with each other are discussed
later in this document.
The following figure is an overview of the Owner Subsystem, showing the
relationship between the UI, Function and Model components. As earlier discussed,
note that the only component handled in the client’s computer is the UI, while the
other two are held in the server.

of 42
Figure 3 – Component Architecture for the Owner Subsystem.
Similarly, the Office Manager’s components interact in the same way, as shown
in Figure 4. Although Office manager and Owner components are connected in the
same way, they need to be shown as two distinct items, since they present different
user interface.
Figure 4 – Component Architecture for the Office Manager Subsystem.

of 42
Differently from the other two subsystems, the UI in the Advertising Team does
not do any modification within the model, since its users are only allowed to retrieve
and send data to other employees and owners. So, for this subsystem, every event that
is triggered by an UI object must execute a function prior to retrieve information held
in the Model.
Figure 5 displays an overview of the relationship between the main components
for the Advertising Team Subsystem.
Figure 5 – Component Architecture for the Advertising Team Subsystem.
3.2.Process Architecture
Among the Centralized, Decentralized and Distributed Patterns, the former model
is selected as a solution for the system distribution problem. Despite its disadvantages,
such as low-level of robustness, server dependency, higher time to access data, and
backup difficulty, the Centralized Pattern allows client computers to deal only with
the user interface, minimizing the use of the technical platform’s facilities from the
client computers. Hence, if a client does an update or any other request, the server
executes a function that interacts with the model, and returns the required output to
the client. Essentially, the whole model and system functions are inherited in the
server, while the client computers operate like terminals.

of 42
On the other hand, this type of distribution helps to achieve the reliability
criterion, since the model is changed in a common hardware, keeping the data
consistent and without duplication.
Figure 6 demonstrates an overview of the Deployment diagram for the IPA4AFC
system.
Figure 6 – Deployment Diagram Overview
3.2.1. Shared Resources
Due to the characteristics of the proposed system, the most common and
intensive activities performed by users are recording and retrieving data.
Therefore, the Retrieve Data and Record Data are the most accessed operations,
when different users start to execute concurrently processes such as Record
Materials, Add Order, Create Schedule and Record Film.
The following figure represents how each object cooperates with each other.

of 42
Figure 7 – Cooperating Objects
3.2.2. Deployment Diagram
The following figure represents the system’s deployment diagram. This
document shows the cooperation of program components and active objects on
processors. Therefore, it was identified the server and clients computers as
processors, as suggested in Figure 8.

of 42
Figure 8 – Deployment Diagram
3.3.Standards
As beforehand mentioned in this document, the system will be developed and
implemented in Microsoft Windows environment. Therefore, error messages, buttons,
or any other graphical interface must be designed according to the Windows
Operational System standards, in order to provide users with a more familiar
interface.

of 42
4. Components
In this section, the component architecture is refined to show in details how each
component is connected to each other, and the interaction between objects. Therefore,
with the purpose of making the diagrams easier to understand, it is shown how User
Interface, Function and Model components interact individually with each other, for each
subsystem.
Additionally, it is relevant to mention that UI Library and DBMS are not highlighted
in this section, although they constantly take part in the component architecture. For an
overview of how they connect with other components, please refer to Figure 2 above.
4.1.Structures
All employees and cinema owners need to constantly share and update crucial
information for executing tasks and activities within AFC. As a result, the following
structures are based on the client-server network, in which office staff’s and cinema
owners’ computers are connected to the company’s server database. As previously
mentioned, all the function and model components for the Owner, Office Manager
and Advertising Team subsystems will be handled by the database server.
Additionally, cinema owners’ laptops are connected through a Wide Area
Network (WAN) structure, since they do not work in AFC headquarter. Besides, each
owner laptop is connected to the Internet via broadband connection, which permits
access to AFC server and allow data sharing between all client computers.
Figure 9 shows a simple network structure for Arty Farty Cinemas.
Figure 9 - Network Infrastructure for AFC.

of 42
4.1.1. Log In Component
In order to obtain access to their respective subsystems, every owner and staff
member needs to log in into the systems. In other words, after each user have
typed in username and password and send it to system, it will validate the
information prior to updated and synchronise all data that had been modified by
other users. Figure 10 shows in details how the Log In component interacts with
other subsystems.
Figure 10 –Interaction between Log In and other subsystems
4.1.2. Advertising Team Subsystem Component
In this section it is illustrated in details how the User Interface (UI), Function
and Model components are related to each other within the Advertising Team
(client) Subsystem.
Hence, Figure 11 demonstrates this relationship, but only between the UI and
Function components. It is shown the objects in the User Interface component that
take part only on the Advertising Team Subsystem, and what functions are
triggered by them.

of 42
Figure11 – Advertising Team Subsystem: Interaction between UI and Function components
On the other hand, the UI for this subsystem does not do any alterations nor
has any directly interaction with the model component, as illustrated in figure 12.
Accordingly, every action executed in the UI component must perform a function
prior to interact with the model components. Figure 13 shows the relationship
between each function and the model.
Figure 12 – Advertising Team Subsystem: Interaction between UI and Model components

of 42
Figure 13 represents functions and objects in the model that are processed and
modified in the server, when an active object on UI is used by someone.
Figure 13 – Advertising Team Subsystem: Interaction between Function and Model components
4.1.3. Office Manager Subsystem Component
This part illustrates in details how the UI, Function and Model components are
related to each other within the Office Manager (client) subsystem.
In Figure 14 it is highlighted all the objects present on the UI and how they
trigger a function within the server.
Figure 14 – Office Manager Subsystem: Interaction between UI and Model components

of 42
As an extension of the above figure, the next one shows in details how the
Model is modified by User Interface objects.
Figure 15 – Office Manager Subsystem: Interaction between UI and Model components
Finally, the last figure represents the functions that interact with the objects
from the Model component in the Office Manager Subsystem.
Figure 16 – Office Manager Subsystem: Interaction between Function and Model components

of 42
4.1.4. Owner Subsystem Component
This part illustrates in details how the UI, Function and Model components are
related to each other within the Owner (client) subsystem.
Although the system will be used by many different actors, cinema owners are
the biggest users with a variation of tasks and activities to be accomplished, such
as taking decisions, marking and reading materials, and sharing crucial
information for elaborating schedules and film orders. Therefore, out of the three
different subsystems, the Owner is the one that has more complex functions and
interaction with objects within the Model.
Figure 17 illustrates the functions that are triggered by objects present in the UI.
Figure 17 – Owner Subsystem: Interaction between UI and Function components
The next figure demonstrates in details how cinema owners can interact
directly with data stored in the Model component by using objects present in the
User Interface.

of 42
Figure 18 – Owner Subsystem: Interaction between UI and Model components
Figure 19 highlights the functions that are triggered by the objects within the
Owner’s UI, and how they are related to the objects within the Model component.
In addition, the Function and Model components are not handled on the Client,
but on the Server component instead.
Figure 19 – Owner Subsystem: Interaction between component Function and Model

of 42
4.2.Classes
The following figures represent the component architecture class diagram for
the proposed system. The connections between the classes are based on the class
diagram provided in the analysis document. However, in this section it is described
the attributes and operations for each class, and how each function is related to the
classes in the Model.
4.2.1. Component Architecture Class Diagram
In this section it is taken into consideration the centralized distribution pattern
(Mathieassen, et al. 2000), as previously proposed. The figure below possesses all
the classes present in the problem domain. Moreover, it might become apparent
that some classes such as Owner, Supplier, Office Staff, Advertising Team, and
Office Manager, which are present in figure 20, were not mentioned on the
previous sections. This is a result of how the system’s user interface interacts with
the function and the model. Essentially, it is out of the system’s scope to do any
modification on those classes, although they are fundamental for the system.

of 42
Figure 20 – Component Architecture Class Diagram
The next figure is part of the above diagram and represents the connection
between the function and model components.
Figure 21 – Component Architecture Class Diagram: Function and Model connection.

of 42
4.2.2. Attributes & Operations Description
The tables below contain brief descriptions for each of the attributes and
operations related on Figure 20 above.
Attribute - Description Data Type
Address – Entity’s Address Text
Advertisement ID – An unique number to identify an advertisement Number
Amount – Total amount Number
Audience – Target audience of the cinema. Text
Cinema Name – Name given to cinema theatres Text
Cost – Total or partial cost of something Number
Date – Relevant date Date
Date Hired – Date which an Office Staff was hired Date
Date Recorded – Date which data has been recorded to the system Date
Decision Maker – Name of the owner who does the cinema decisions. Text
Decision Status – If a material is going to be used or not Text
Department Name – Name of a department Text
E-Mail – Entity’s contact e-mail Text
Film – Name of the Film Text
Film Cost – Individual Cost for renting a film. Number
Genre – The genre classification for a film Text
Material Decision Status – Which materials have the owner recently decided on. Text
Menu Type – Reference for which menu does the decision belongs to. Text
Name – Entity’s Name Text
Order ID – An unique number to identify an order Number
Owner ID – Staff ID of an owner Number
Purchase Summary –Purchase history of films. Text
Quantity – total quantity of an object Number
Session Time – Time in which a movie is shown in a cinema. Time
Staff ID – An unique number that identifies a staff member Number
Supplier Name – Name of the distributor Text
System Password – Password for accessing the system Text
System Username – Username for accessing the system Text
Telephone/Fax – Entity’s telephone/fax number Number
Text Message – A block of text with contextual meaning Text
Ticket Price – How much it is to purchase a ticket for a film in a cinema theatre. Number
Topic – Subject of a text message Text
Type – Type of the material (i.e. Audio, video, text, picture) Text
Table 7 – Attributes Description

of 42
Operations Description
Add Order Place a new order by adding it to the model.
Assign Schedule Assign a schedule to an object.
Assign Advertisement Assign advertising materials to an object.
Assign Film Assign film to an object.
Assign Film Materials Assign Film Materials to an object.
Assign Office Manager Assign Office Manager to an object.
Assign Owner Assign an owner to an object.
Assign Receiver Assign a receiver to a text message.
Assign Sender Assign a sender to a text message.
Assign Session Time Assign film session time to cinema theatres.
Create Schedule Create schedule ID without any data (i.e. film, session time, etc.)
Delete Schedule Delete the schedule ID and its data.
Record Data Record in the model data entered from user interface.
Record Decision Record a decision into the system by checking a checkbox.
Record Film Record film after purchase.
Retrieve Data Display data (film materials, order, and schedule) from the
model (not download).
Retrieve File Import and download data from the model to the local hard disk.
Send data to all clients Send attached file from one client to another.
Update Decision Status Read all owners’ decisions and updated it into the system.
Upload Film Insert film files after purchase.
Validate Inputs Validate data and catch exceptions when inputting data.
Table 8 – Operations Description
1.1. Event Placement
According to the event table provided in this document, the events were
placed on the class diagram in order to demonstrate the single and
multiple public and private events. So, public events are marked with a
‘+’, while privates with a ‘-’.

of 42
Figure 22 – Event Placement
1.2.System Behaviour Statechart
System initiates when the executable file is opened. After that, the system waits
for user to input password and username and click on the ‘login’ button to validate the
information. If inputs are not validated, then an error message is sent and system
remains on the ‘Prompt for log in’ state. On the contrary, if inputs are validated, then
data is synchronized prior to go into the ‘Active’ state, and user gets automatically
access to his/her respective subsystem. Once system goes into ‘Active’ state, user can
perform many tasks, such as search and download for materials, make an order,
record a file, create schedule, and so on. While in this state, users can either log off or
close the application. If the first event is performed, then the application rolls back to
the ‘Prompt for log in’ state. Additionally, the application can be closed at all times,
once it is opened.

of 42
Figure 23 – System Behaviour Statechart
2. Recommendations
Once identified the system’s technical platform, architecture, and components, it is
also crucial to develop a very well structured plan for the work developed, in order to
achieve the system’s purpose. As a result, some topics need to be considered in this
section such as system’s usefulness, plan for initiating use, and implementation plan.
2.1. System Usefulness
As previously mentioned on this document, the main purpose for implementing
IPA into Arty Farty Cinemas operations are:
 Tracking;
 Recording;
 Communication;
 Scheduling;
 Procurement.
Hence, users can track and record materials, communicate with each other,
schedule and purchase desired films by interacting with the system’s user interface,
which execute specific functions that will retrieve and keep track of data on the
Model. For example, tracking materials can be performed by clicking on checkboxes,

of 42
in order to mark materials as ‘Read’, whereas recording is done by entering data to the
system and update the information to store on system’s database.
When deciding on the system’s architecture and components, it is crucial to take
into consideration what are the design criteria that the system needs to address. Not
differently, the quality goals identified for IPA were accuracy, reliability, and
maintainability.
Accuracy
Accuracy is one of the most important criteria related earlier in this document.
Therefore, every data that is used by more than one user should be recorded in the
company’s database, in order to maintain a single copy of this same data, thus
avoiding problem of data duplication and inconsistency. Additionally, the system
must be able to provide updated information to all users, since constant decisions and
scheduling are routine to AFC members’ activities.
Reliable
The system is shown to be reliable because it achieves the minimum level
required of precision in function execution. Therefore, like the Model, the Function
components for all subsystems are allocated within the server, concentrating all the
system’s functions in a centralised server.
Maintainable
Maintainability is also appointed as one of the most important features for
IPA4AFC. As a result, the Client component have been collapsed in different
subsystems, which helps system developers to locate and fix system bugs more
efficiently and less costly. Therefore, different components for each subsystem
facilitate to fixing errors in a single subsystem, without having to interrupt the
operations in other subsystems, thus maintaining productivity of other users.

of 42
2.2.Plan for Initiating Use
An installation plan will be suggested by the system developers due to their
higher level of expertise. On the other hand, AFC top managers should be responsible
for elaborate a training program, since they have a general knowledge of what type of
training should each potential user undertake.
The system developer company will maintain the system and provide any further
assistance to the technical problems related to the new software, that AFC might need.
On top of that, a user’s manual will be provided by sending it to each user’s email.
2.2.1. Budgeting
It is also important to consider the costs involving the development and
implementation of the new system. As a result, the table below is an estimative of the
major costs involved in this project.
The average annual wages were extracted from www.payscale.com. Each of them
were divided by 12 (months), giving its respective cost per month. For further
research details, please refer to the Appendix in this document.
Table 9 – Budget for IPA development
Annual Salary Monthly Cost
Programmer Annual Salary (AU$) 70,000.00$ 5,833.33$
Project Manager Annual Salary (AU$) 90,000.00$ 7,500.00$
Trainer Annual Salary (AU$) 65,000.00$ 5,416.67$
Visual Studio 2010 (AU$) 1,400.00$ 116.67$
DBMS Software Cost (AU$) 20,000.00$ 1,666.67$
TOTAL COST 246,400.00$ 20,533.33$

of 42
2.3.Implementation Plan
During implementation phase, many risks need to be controlled such as employee
resistance to technology, de-skilling of personnel, and lack of leadership and
involvement of users (Hui 2011). Consequently, in order to minimize those risks, it is
crucial to elaborate a very concise implementation plan that will involve not only the
technical part of implementation, but also the feelings of users.
Another key factor for the system success is to do a training program involving
all the system’s stakeholders. The application of training sessions is a major
contributor to increase both employees’ participation and skills towards the system.
Therefore, all employees should be taught about the system capabilities and its main
purpose.
In regards to the installation and testing, every subsystem package should be
installed and tested individually in the users’ computers for guaranteeing that the
application will run correctly and without unexpected incompatibilities. Additionally,
each package should be tested and installed within a month by two programmers.
The Figure below is a summary of the project schedule relating the main
activities and its dependencies, during the whole project development, from the
analysis document until the software installation. It gives an idea of how long the
project should take to be launched.
Figure 24 – Project Schedule
Project Duration 18.5Weeks Analysis Document Design Document Programming Testing Installing
Develop Documents 8Weeks 4Weeks
Analysis Document 4Weeks 4Weeks
Design Document 4Weeks 6Weeks
Implementation 11Weeks 3Weeks
Programming 6Weeks 2Weeks
Testing 3Weeks
Installing 2Weeks

of 42
References
Hui, Wendy (2011). “Lecture 3: Benefits Management Process.” PowerPoint lecture notes.
http://lms.curtin.edu.au/webapps/blackboard/content/listContent.jsp?course_id=_6196_1&co
ntent_id=_1977371_1
Mathieassen, Lars, Andreas Munk-Madsen, Peter Axel Nielsen, and Jan Stage. Object-Oriented
Analysis & Design. Denmark: Marko, 2000.
Wikipedia. 2011. http://en.wikipedia.org/wiki/Unified_Modeling_Language#cite_note-Foldoc01-1
(accessed October 15, 2011).

15527769_Assignment2_Pedro_Martins

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (20)

Similar to 15527769_Assignment2_Pedro_Martins

Similar to 15527769_Assignment2_Pedro_Martins (20)

15527769_Assignment2_Pedro_Martins