Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  
AccessAdobe photoshopAlgoritmiAutocadBaze de dateC
C sharpCalculatoareCorel drawDot netExcelFox pro
FrontpageHardwareHtmlInternetJavaLinux
MatlabMs dosPascalPhpPower pointRetele calculatoare
SqlTutorialsWebdesignWindowsWordXml

EMuseum

calculatoare



+ Font mai mare | - Font mai mic



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 :

Creates

Store

Generates

Tickets requested by Client , and activated by Cashier

All the tickets that has been generated

The ticket that the cashier activated

Reports about the created tickets

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 :

DATA

CONTROL

TEMPORAL EVENTS

Client request a subscription creation

Report for the director about the tickets created , taken from the log file

Cashier creates subscription for Client

Cashier activates other created tickets

3.4) Architecture Draft Document

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

GUI

APPLICATION LOGIC

DATA LOGIC

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.





Politica de confidentialitate | Termeni si conditii de utilizare



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 1525
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved