EMuseum

EMuseum

1) Problem statement

Museums are the places where history is saved , and when we save history we can learn from it , and avoid problems that might appear in our future , our application is designed to help us manage the museum system to make it easier to control the visitors and the tickets generates ..etc

We will make a software that has a friendly user interface , for the cashier and for the client ( visitor ) that will be able to generate tickets through requests given by the client or the cashier .

The application respects the online/offline content business model because it's used offline by the cashier - to compute ticket price depending on it's type, and online by the users - to reserve tickets. It's main purpose is to optimize the activities that take place in an e-museum. First of all the system is used by the cashier at the entrance who sells tickets. The application must support configurable tickets : visit hour, category (students, soldiers and retiress benefit from reductions) and rights (taking photographs, filming inside); and depending on ticket's paramaters, it calculates the ticket price. Cashier interacts directly with the client, being able to compute the total price and to print the ticket. Users can choose from different payment methods : cash or credit card. The application also stores all the information about the sold tickets and present at the end of a month a summary : how many tickets were sold, what types of tickets, total sum, etc. Clients may reserve tickets in advance, but not more then 5 tickets. The system also keeps track of all the exhibited items in the gallery, knowing thei type, short description, region of origin and others and allows the administrator to make changes : enter a new item, edit an old item and remove an item.

What I can add on my application "and this is what I mentioned in my email to you " is :

1- in the first week in of the opening people will benefit from a 15 % sale on any ticket they buy

2- the system will register all the names of people who entered the museum , and if one person entered the museum more than 1 time in 5 months he will get a 10 % discount

3- a very good idea would be to make a contract with a company of Tourism to bring its costumers to our museum and the company will get a commission of 30 % of the tickets prices that the Turists will pay . and in this case i might do that for THESE kind of tickets we raise the ticket price 10% because generaly turists PAY GOOD for museams so it will be like we paid the compay 20% and not 30% ( se compenseaza )

I can say ,this software is a friendly user interface platform that can collaborate with

1- Client ,

2- Cashier

2) Business model

Business Actors : Visitors

The action will begin when a new visitor comes and requires to have a visit in the museum's rooms

or when an Agency comes with a big number of visitors from other countries .. so they will have a bigger discount

Business Agents : Cashier

Cashier will play the rule of business agent in sense that he will get the requests, he will use the software to create tickets and he will make the tickets . for the visitors to use the ticket and visit the museum "depending on the ticket they have bought "

Value added by the system the system :

fasting the processes of making tickets for visitors , and evite any mistake could happen ,

- also the Cashier will be very attentive in case that the program blocked or didn't respond as needed , to call the technical support of this project .

Business Processes (business Scenarios)

P1.Ticket creation

A1. the client wants to reserve a ticket

A2. the program asks ticket parameters

A3. the client fills in the needed information

A4. Ticket is saved and pending to cashier to create it

P2. Cashier creates a ticket

A1. client comes to the cashier and asks him to create a ticket for him

A2. cashier looks forward for ticket requirements

A3. cashier creates a new ticket

P3. Cashier activates a created ticket

A1. client comes to the cashier and asks to create his reserved ticket

A2. cashier looks forward for reserved tickets .

A3. cashier creates a new ticket

P4. Museum virtual free tour

A1. client asks to see a "map" of the museum and what is contains

A2. Program returns images with some descriptions about the museum

P5.Reporting tickets statistics on request

A1.Cashier wants to know the ticket numbers at a time

A2.program returns the requested data

A3.Cashier reports to the Director the number of created tickets "and information about them " each month , so that they can make a statistics about the increase of the Museum visits .

Business Use Cases

UC1 Ticket creation

Main Actor : Client , Program Pre-conditions : the client wants to reserve a ticket Trigger event : Program asks client to fulfill the needed data for reserving ticket Main flow of events : Client Program Client asks for a subscription Asks for data of the ticket Client fill in the data Saves the ticket and Pends it to the cashier Exceptional flow of events : - Client and after filling the required information he changes his mind and he no more want to visit the museum Post-conditions : a new ticket is on pending to the cashier to create

UC2 Cashier creates a ticket

Main Actor : Cashier , Client , Program Pre-conditions : client comes to see the museum Trigger event : clients come to cashier to create the ticket or activate the created ticket Main flow of events : Client Program Cashier client comes to the cashier and asks to create his reserved ticket The cashier asks the client what type of ticket should he create for him Generates the ticket and prints it Client pays the ticket Enter the museum Exceptional flow of events : client and after creating the ticket he changes his mind   Post-conditions : ticket printed

UC3 Cashier activates a created ticket

Main Actor : Cashier , Client , Program Pre-conditions : client comes to see the museum Trigger event : clients come to cashier to create the ticket or activate the created ticket Main flow of events : Client Program Cashier client comes to the cashier to activate a reserved ticket Sees the ticket reserved and asks for the payment Pays the ticket Generates the ticket and prints it Visits the museum Exceptional flow of events : client and after creating the ticket he changes his mind Post-conditions : ticket printed

UC4 Museum virtual free tour

Main Actor : client , program Pre-conditions : client wants to see a plan about the museum Trigger event : client press on museum tour Main flow of events : client program Presses on the museum tour button Opens a new frame with the gallery and plan of the museum Sees Exceptional flow of events : - no exception flow of events here .. Post-conditions : clients saw the museum virtually and decides to visit it or not .

UC5 Reporting tickets statistics on request

Main Actor : cashier , program Pre-conditions : cashier is asked by director to present the number of tickets he created today Trigger event : cashier closes the application è the application will create a log with the created tickets ( emuseum.log ) Main flow of events : cashier program Cashier close the application Creates a log Opens the log and sends to director Exceptional flow of events : software error Post-conditions : a report is created

Activity Diagrams for Business Processes

UC1. Ticket creation

UC2. Cashier creates a ticket

UC3. Cashier activates a created  ticket

UC4. Museum virtual free tour

UC5. Reporting tickets statistics on request

2.3) Business Object Diagrams(Domain Model)

We extract NOUNS from text.:

Cahier , Client , ticketFactory , Reduction , Payment , Ticket , Emueum, Gallery , Room , Item )

As we can see in the that the relation between our items is 1-n , or 1 to 1 , depends on how many items can a certain item have ,

Example 1 room may have N items , and 1 gallery may have N rooms , but 1 Museum can have only 1 Gallery

* USE CASE DIAGRAM

* CONTEXT DIAGRAM

2.5) User Requirements Document

THE SYSTEM HAS TO :

3) Requirements analyses model

actor description ( Concerns + Responsibility )

Cashier

Interests

The cashier wants to create or activate as many tickets as he can in order for the director to be happy of him .

Responsibilities

creates tickets

activate tickets

report to the director

Client

Interest

To visit the museum

Take photos

Learn a new things from the museum visit

Responsibilities

-to come to the museum when he wants to see

- to ask about the ticket subscription

- to pay the ticket bills

The System Event list :

3.4) Architecture Draft Document

the project is done in java and it has three tier application (3 layers)

GUI is the way the Cashier will access the data THROUGH the APPLICATION LOGIC .

So the Cashier can't access DATA LOGIC !!

3.5) System Sequence Diagrams

4.4) Design Class Diagram

The patterns i used , and why i used them :

E-Museum, patterns used :

Observer

The MainFrame class uses the observer pattern, because it has references to all the composite objects of the application. It notices the changes and acts as needed - for example, tells the logger to save data in the log file, tells the cachier frame what users have reserved etc.. It's connected with all other modules : user frame, cashier frame, gallery frame, payment etc. The reason i choosed this pattern is obvious; each medium application needs a class manager.

Singleton - MySingleton.java

The Gallery class is represented as a singleton, because this E-Museum consists only of one gallery. The implementation is generic, it uses a static boolean variable and a type given as parameter. Also, Payment is implemented as a singleton, but, this time, the instance is an internal class.

Composite

The Room and Gallery classes are implemented with the composite pattern., because they contain a group of objects. Room contains a vector of items and Gallery contains a vector of rooms. In this way, client can treat compositions uniformly.

Builder

CachierFrame class is implemented using builder, in two steps. At first step, I build the TicketFactoryGUIInterface and then I add new elements to it, in order to obtain the desired frame.

Command - MyCommand.java

Ticket and PaidTicket classes implement the command interface. Actually, the execute method makes sense only for PaidTicket objects, because Ticket objects are saved commands, which may execute later, if the client pays it's reserved ticket.

Abstract Factory - MyAbstractFactory.java

Ticket class is implemented with this pattern, because a ticket it's defined by a lot of parameters and hard-coding the constructors isn't ok. The way I implemented abstract factory pattern is the most known : private constructor and static method newTicket returning a reference to a Ticket object.

Iterator - MyIterator.java

My iterator implementation is based on java.util.Iterator and it adds a new method for reseting the iterator. The classes implementing this interface are : Gallery and Room.

Decorator

PaidTicket class is a wrapper over the Ticket class. Ticket is decorated by adding a new boolean member : ticketPayed and a new functionally at the runtime : logging into database. This is usefull because I wanted a generic ticket implementation and a simple way to separate payed ticket from unpayed (reserved) tickets.