Anda di halaman 1dari 34

E-Opera

Software Development Methods Project

COORDINATING TEACHERS: LUCA DAN SERBANATI ANDREI VASILATEANU

Student: Andreea Buga 1231 E Faculty of Engineering in Foreign Languages

Table of contents

Table of Contents
Table of contents ....................................................................................................................................................1 Chapter 1: Problem Statement ..............................................................................................................................3 Chapter 2: Business modeling ................................................................................................................................4 2.1. Domain Model .............................................................................................................................................4 2.2. Business components ..................................................................................................................................5 2.2.1. Business goal (purpose) ........................................................................................................................5 2.2.2. Business actors and agents...................................................................................................................5 2.2.3. Business processes ..............................................................................................................................5 2.2.4. Business rules .......................................................................................................................................5 2.3. Business Use Case Diagrams.....................................................................................................................6 2.4. Activity Diagrams .........................................................................................................................................7 2.4.1. Reserve tickets activity diagram ...........................................................................................................7 2.4.2. Buy ticket activity diagram ...................................................................................................................8 Chapter 3 ................................................................................................................................................................9 3.1. 3.2. Software Use Cases ................................................................................................................................9 Use Cases Descriptions .........................................................................................................................10 Login use case description ............................................................................................................10

3.2.1.

3.3.2 Update Shows Use Case Description ...................................................................................................11 3.3.3. Sell Tickets Use Case Description .................................................................................................12

3.3.4. Register Use Case Description ............................................................................................................13 3.3.5. Create alarm Use Case Description ....................................................................................................15 3.3.6. Reserve tickets Use Case Description .................................................................................................16 3.3.7. Offer feedback Use Case Description .................................................................................................17 3.4. 3.5. SYSTEM FUNCTIONALITIES ...................................................................................................................18 SYSTEM SEQUENCE DIAGRAM..............................................................................................................19

3.5.1. Buy ticket system sequence diagram .................................................................................................19 3.5.2. Reserve ticket system sequence diagram ..........................................................................................20 3.5.3. Register client system sequence diagram ....................................................................................21

3.3.5.4. Update show System Sequence Diagram ........................................................................................22 3.3.5.5. Login System Sequence Diagram.....................................................................................................23 3.6. OPERATION CONTRACTS ......................................................................................................................24

3.6.1. Enter client data operation contract ..................................................................................................24 3.6.2. Enter show data operation contract ..................................................................................................24 3.6.3. Sell ticket operation contract .............................................................................................................24 3.6.4. Reserve ticket operation contract ......................................................................................................25 3.6.5. Create alarm operation contract ........................................................................................................25 Chapter 4 ..............................................................................................................................................................25 4.1. Design Class Diagram.................................................................................................................................26 4.2. Sequence Diagram................................................................................................................................27 Login Sequence Diagram ..............................................................................................................27 Register Sequence Diagram..........................................................................................................28 Sell Ticket Sequence Diagram.......................................................................................................29 Reserve Sequence Diagram ..........................................................................................................30 Offer Feedback Sequence Diagram ..............................................................................................31

4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5.

4.3. Statechart Diagram....................................................................................................................................32 4.3.1. Seat statechart Diagram .....................................................................................................................33 4.3.2. Reservation statechart Diagram .........................................................................................................34 4.3.3. Representation statechart Diagram ...................................................................................................34

Chapter 1: Problem Statement

The board of the Opera decides to implement a software system in order to optimize the activities that take place in the business. First of all the system is used by the cashier at the entrance who sells tickets. The tickets have different prices depending on the placement of the seat. Students, soldiers and retirees benefit from reductions. The cashier must log in then is presented with an interface showing the placement of the seats, colored differently for the states: free, bought, reserved. The customer can purchase a monthly or yearly subscription to the shows, or can buy a membership card to have reduced prices for the tickets. The board also wants to implement an online system where potential customers can view upcoming shows. If the customer registers in the system (buys a membership card), he/she can create alerts for some representations to be notified when the representation is programmed. Also, based on earlier purchases, the recommendation system may recommend some representations to the customer. Finally, if registered, the customer can grade representations and give feedback. The system should allow the cashier to enter the details needed for the ticket, compute the total price and print the ticket. The visitors can pay either in cash or using a credit card. The system must store 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. The system should allow visitors to reserve tickets in advance. A user cannot reserve more than 5 tickets. The system also keeps tracks of the available shows allowing the administrator to add, modify or delete a show. The administrator can enter details such as distribution, dates of the representation etc.

Chapter 2: Business modeling


The main purpose of this chapter is to describe the vision of the organization in which the system will be distributed and how to apply this vision in order to outline the roles, process and responsibilities. The most important parts of this chapter are: Domain model; Identifying the actors and agents; Processes and rules; Business use cases;

2.1. Domain Model


Domain model is a representation of a real world world conceptual classes (entities). The domain model is created in order to represent the vocabulary and key concepts of the problem domain. The domain model also identifies the relationships among all the entities within the scope of the problem domain, and commonly identifies their attributes. A domain model that encapsulates methods within the entities is more properly associated with object oriented models. The domain model provides a structural view of the domain that can be complemented by other dynamic views, such as use case models.

2.2. Business components


2.2.1. Business goal (purpose) Business goals can be regarded as the things that an organization hopes to achieve during its time in operation. The main goal of developing this application is to optimize the current system of selling tickets at the opera. 2.2.2. Business actors and agents At the external level, the business behavior is assigned to and performed by a role player called business actor. Actors may be end users, other systems or hardware devices. Business Actor: Customer At the internal level, the business behavior is assigned to and performed by a role player called business agent. Business Agents: 2.2.3. Cashier (he/she sells the tickets to the show) Administrator (keeps up-to-date all the data about the shows) Business processes Buy tickets; Present a monthly summary; Reserve tickets;

2.2.4. Business rules The business behavior is governed by business rules that dictate how flows should be initiated and directed. No. BR1 BR2 BR3 BR4 BR5 BR6 BR7 BR8 BR9 Rule The cashier must log in order to be able to reach the interface in which he/she can sell tickets. In order to benefit of reductions, a customer must purchase a monthly or yearly subscription, or buy a member card. In order to create alerts or write recommendations, a user must register. A user cannot reserve more than 5 tickets. The administrator must log in before he can make the appropriate changes for a show. Students, soldiers and retirees benefit from reductions. Prices vary according to the seat. The system must store all the information about the sold tickets and present a monthly report. The recommendations must be done based on earlier purchases.

2.3. Business Use Case Diagrams


Business use cases are system descriptions of sequences of events that, taken together, lead to a system doing something useful. These descriptions are done from the users point of view. It is a description of systems behavior as it responds to a request that originates from outside the system. It is a complete series of events seen from the point of view of the actor. E opera application will contain the following business use cases:

2.4. Activity Diagrams


An activity diagram is designed to provide an accurate definition of the baseline requirements from a logical, sequential perspective. The following activity diagrams describe the most important actions that occur while working with this application: 2.4.1. Reserve tickets activity diagram

2.4.2. Buy ticket activity diagram

Chapter 3
3.1. Software Use Cases

In software and systems engineering, a use case is a list of steps, typically defining interactions between a role and a system, to achieve a goal. It may also be defined as a sequence of actions, including variants, a system can realize by interacting with the system actors.

3.2. Use Cases Descriptions


3.2.1. Login use case description Use case name: Login Use case short description: The login procedure is the same for the administrator, cashier and customer. The user must provide the username and the password in the GUI and then the inserted data should be validated by the system. Stakeholders: cashier, administrator, customer Preconditions: The system is running; the application is connected to the database (in order to see check the data inserted by the user) Postconditions: the guest will now be logged in. Main flow of events:

Alternate flow of events: A1: - Invalid data 1. Show error; 2. Go to step 1 in main flow; - User already logged in 1. Show error; 2. Go to step 1 in main flow;

10

3.2.2 Update Shows Use Case Description

Use case name: UpdateShows Use case short description: The administrator may modify data about shows: dates of representation, distribution, duration. Also the administrator may decide to delete a show, or add a new show. Stakeholders: administrator Preconditions: The system is running; the application is connected to the database (in order to apply the changes), the administrator is logged in. Postconditions: the changes will be applied in the database. Main flow of events:

Alternate flow of events: A1: - Invalid data 1. Show error; 2. Go to step 5 in main flow; - Show already existing in the database:
11

1. Show error; 2. Go to step 5 in main flow; A2: - Operation not confirmed by the administrator 1. EXIT 3.2.3. Sell Tickets Use Case Description

Use case name: Sell Tickets Use case short description: The customer will provide the details about the show he wants to see. The cashier will introduce the data into the application and he will view a set of results for his query. After choosing an available show matching the request he will choose one of the available seats. The system will compute the price corresponding to the type of client. Stakeholders: cashier, customer Preconditions: The system is running; the application is connected to the database (in order to apply the changes), the cashier is logged in. Postconditions: Tickets are printed. The information about the sold tickets are stored. Main flow of events:

12

Alternate flow of events: A1: - Invalid data 1. Show error; 2. Go to step 4 in main flow; A2: - Operation not confirmed by the customer 1. EXIT A3: - Invalid payment data 2. Show error; 3. Go to step 10 in main flow; 3.3.4. Register Use Case Description Use case name: Register customer Use case short description: The customer will provide the necessary personal data for the membership card and will choose the type of membership he/she desires. The data, that will be inserted by the cashier will be checked by the system. After computing the price and confirming the payment, the user will receive a membership card/subscription. Stakeholders: cashier, customer Preconditions: The system is running; the application is connected to the database (in order to add the new client), the cashier is logged in. Postconditions: A subscription/membership card is printed. The information about the registration are stored. Main flow of events:

13

Alternate flow of events: A1: - Invalid data 1. Show error; 2. Go to step 4 in main flow; - Subscription already existing: 1. Show error; 2. Go to step 4 in main flow; A2: - Operation not confirmed by the customer 1. EXIT; A3: - Invalid payment data 1. Show error; 2. Go to step 8 in main flow;

14

3.3.5. Create alarm Use Case Description

Use case name: Create alarm Use case short description: The customer will login, after which he can choose to create an alarm. A list of shows is displayed from which he can choose one show to set the alarm. Stakeholders: customer Preconditions: The system is running; the application is connected to the database (in order to add the new alarm), the customer is logged in. Postconditions: The new alarm request is stored in the database. Main flow of events:

Alternate flow of events: A1: - Show not existing 1. Show error; 2. Go to step 4 in main flow; - Alarm already existing: 1. Show error; 2. Go to step 4 in main flow; A2: - Operation not confirmed by the customer 2. EXIT;

15

3.3.6. Reserve tickets Use Case Description

Use case name: Reserve tickets Use case short description: The customer will login, after which he will give the information about the desired show. After choosing a date of the representation he will be able to see the available seats. After choosing the seats (maximum 5), he will be able to save his reservation Stakeholders: customer Preconditions: The system is running; the application is connected to the database (in order to add the new alarm), the customer is logged in. Postconditions: A reservation receipt is printed. The reservation is stored in the database. Main flow of events:

Alternate flow of events: A1: - Show not existing 1. Show error; 2. Go to step 4 in main flow; - Reservation already existing: 1. Show error; 2. Go to step 4 in main flow; A2: - Operation not confirmed by the customer 3. EXIT;

16

3.3.7. Offer feedback Use Case Description

Use case name: Offer feedback Use case short description: The customer will login, after which he will chose one of the shows he has already been to. After choosing the show, he will be able to give grades or leave a comment for the show. Stakeholders: customer Preconditions: The system is running; the application is connected to the database (in order to see the list of shows), the customer is logged in. Postconditions: The feedback given by the customer for the show is stored in the database. Main flow of events:

Alternate flow of events: A1: - Invalid feedback; 1. Show error; 2. Go to step 7 in main flow; - Feedback already given by this user for this show: 1. Show error; 2. Go to step 7 in main flow; A2: - Operation not confirmed by the customer 4. EXIT;

17

3.3. SYSTEM FUNCTIONALITIES


System functional requirements are mainly the software use cases presented earlier in the document: Functionalities 1. System must allow log in for cashier, admin and customer. 2. System must allow browsing of shows 3. System must allow filtering shows, seats by some filters like availability, date, category 4. System must allow creating different types of subscription 5. System must allow making a purchase 6. System must allow the customer to give a review 7. System must allow administrator to update shows 8. System stores all the information about the sales and bookings 9. System must allow ticket reservation in advance 10. System must allow computing the purchase price 11. System must allow creating alarms for shows. Grade 9 7 6 8.5 10 6 9 9.5 8 8.5 6

NON FUNCTIONAL REQUIREMENTS:


In the following part, there will be described the system non functional requirements and their importance for the whole application: Security: In order to use the system, the cashier, the customer and the admin must log in. The password is at least 6 digits long. Usability: The system can be used by a person with high school training after a two hour tutorial. Robustness: System verifies all the input data given by the client, cashier, admin. Reliability: It can work continuously for a week. Performance: It can store 500 clients and 200 purchases/bookings simultaneously. It must respond in at most 5 seconds for every query. It can store 1000 shows. It can be easily upgraded. Portability: Due to the fact it is mainly a Java application, it can be used on every operating system.

18

3.4. SYSTEM SEQUENCE DIAGRAM


A system sequence diagram is a picture that shows, for one particular scenario of a use case, the events that external actors generate, their order, and inter system events. All systems are treated as a black box. Time proceeds downward and the ordering of the events should follow their order in the scenario. The following system sequence diagrams present a certain importance for the current application:

3.5.1. Buy ticket system sequence diagram

19

3.5.2. Reserve ticket system sequence diagram

3.4.3. Register client system sequence diagram

3.3.5.4. Update show System Sequence Diagram

3.3.5.5. Login System Sequence Diagram

3.5. OPERATION CONTRACTS


3.6.1. Enter client data operation contract Operation Name: Enter client data; Use case: Register client; Preconditions: Registration was requested and a form was shown. Postconditions: New object is created: a new membership card/subscription is created. New attributes are created (attributes of the MembershipCard/Subscription) An association between a client and the new registration is created.

3.6.2. Enter show data operation contract Operation Name: Enter show data; Use case: Update Shows; Preconditions: Show update was required and a new form was displayed. Postconditions: Object of type show is modified. (its attributes will be changed). List of shows will be actualized.

3.6.3. Sell ticket operation contract Operation Name: Sell ticket; Use case: Sell ticket; Preconditions: New sale was registered and a new sale form will be displayed. Postconditions: New object is created: a new purchase object will be created. New attributes are created for the purchase object. An association between a client and the new purchase is created. An association between a purchase and tickets is created. An association between tickets and representation seats is created. List of free seats for the show representation is updated.

3.6.4. Reserve ticket operation contract Operation Name: Reserve ticket; Use case: Reserve ticket; Preconditions: New booking was registered and a new booking form will be displayed. Postconditions: New object is created: a new reservation object will be created. New attributes are created for the reservation object. An association between a client and the new reservation is created. An association between reservation and representation seats is created. List of free seats for the given representation is updated.

3.6.5. Create alarm operation contract Operation Name: Create alarm; Use case: Create alarm; Preconditions: New alarm was requested and alarm creation form was displayed. Postconditions: New object is created: a new alarm object will be created. New attributes are created for the alarm object. An association between a client and the new alarm is created. An association between a show and representation seats is created.

Chapter 4
4.1. Design Class Diagram
In software engineering, a design class diagram is a type of static structure diagram that describes the structure of a system by showing systems classes, their attributes, operations (or methods), and the relationships among classes. Class diagram is the foundation of modeling objects, the source for code generation and the target for reverse engineering.

4.2. Sequence Diagram


The main purpose of a sequence diagram is to define event sequences that result in some desired outcome. The focus is less on messages themselves and more on the order in which messages occur.
4.2.1. Login Sequence Diagram

4.2.2. Register Sequence Diagram

4.2.3. Sell Ticket Sequence Diagram

4.2.4. Reserve Sequence Diagram

4.2.5. Offer Feedback Sequence Diagram

4.3. Statechart Diagram


State machines are used for modeling discrete behavior through finite state transition systems. In addition to expressing the behavior of a part of the system, state machines can also be used to express the usage protocol of part of a system. 4.3.1. Seat statechart Diagram

4.3.2. Reservation statechart Diagram

4.3.3. Representation statechart Diagram

Anda mungkin juga menyukai