OOM Group Assignment

Object Oriented Methods 2011

Table of ContentsChapter-1...............................................................................................................................................2

Introduction.......................................................................................................................................2

Options identification........................................................................................................................3

System Objectives.............................................................................................................................4

Analysis and design system...............................................................................................................4

Chapter-2...............................................................................................................................................5

Businss Process Modeling..................................................................................................................5

Chaper-3................................................................................................................................................6

Usecase diagram................................................................................................................................6

Chapter-4...............................................................................................................................................7

Use Case Drawing..............................................................................................................................7

Use Case Specifications..................................................................................................................8

Chapter-5.............................................................................................................................................18

Class Diagram..................................................................................................................................18

Chapter-6.............................................................................................................................................22

Sequence Diagram...........................................................................................................................22

Chapter-7.............................................................................................................................................26

State Diagram..................................................................................................................................26

Chapter-8.............................................................................................................................................27

Description and Rational.................................................................................................................27

Reflection........................................................................................................................................28

Critical Appraisal..............................................................................................................................30

System Prototype................................................................................................................................31

Reference............................................................................................................................................36

Tuition Payment Statement Generator


Chapter-1

Introduction

This is a report to design a Tuition Payment Statement Generator system. It consists of

several Unified Modeling Languages (UML) such as Use case diagram, Class diagram and

Sequence diagram in order to achieve a proper and successful system.

There are some options available to help the developers to design the system.

Please select the following options:

1. Register new subject.

2. Register new student.

3. Generate Payment Statement.

4. Manage tuition record.

5. Exit application.

Those options stated above will first be designed into diagrams, then the actul system will

created or designed by the object orianted method (OOM) program which is VB.Net. As an

assumption another option will be added to the system to make it more automatived and gives

more options for the users to get the most benefits of the system which will be expalined in

the assumption part of the assignment. This will be an explantion of what we assume the

systems limitation is.



Options identification

Option: 1 NEW SUBJECT REGISTRATION: Please enter name of subject: Maths

Entry saved …

Option: 2 NEW STUDENT REGISTRATION: Please enter name of student: Johanes

Entry saved …

Option: 3 PAYMENT STATEMENT GENERATION Name of student: Joha Error.

Student Joha is not registered! Name of student: Johanes. Subject: Maths Begin

duration (DDMMYYYY): 06012004 End duration (DDMMYYYY): 05022004

Generating tuition payment statement ….. Written to file named:

MathsJohanes0601200405022004.txt

Option: 4 MANAGE TUTION RECORD Do you want to

ADD new tuition record

DELETE tuition record.

UPDATE tuition record.

EXIT



System Objectives

Electronic generating tuition record based system.

Develop a receipt generator.

Automate generating tuition records.

Analysis and design system

In this part of the assignment the system will be designed into several kinds of diagrams and

analysised to figure out how the system should be designed into a program.



Chapter-2

Businss Process Modeling



Chaper-3

Usecase diagram

Usecase diagram is a connection between the use cases and the actors within the system.

Use case: describes a sequence of actions that provide something of measurable value to an

actor and is drawn as a horizontal ellipse, (Hans-Gerhard Gross, 1998).

Actor: is a person, organization, or external system that plays a role in one or more

interactions with your system. Actors are drawn as stick figures.

Associations between actors and use cases are indicated in use case diagrams by solid lines.

An association exists whenever an actor is involved with an interaction described by a use

case. Associations: associations are modelled as lines connecting use cases and actors to one

another, with an optional arrowhead on one end of the line. The arrowhead is often used to

indicating the direction of the initial invocation of the relationship or to indicate the primary

actor within the use case. The arrowheads are typically confused with data flow and as a

result I avoid their use.

According to the case study given and the system requested to be done, it has around six use

cases four of them were proposed by the case study and the other two were provided an

assumptions.



Chapter-4

Use Case Drawing

Above is the Use case diagram for this system. Each use case will be explain and defined in

the Use case specifications below.



Use Case Specifications

Register new Subject

Brief Description

This use case starts when a registered student wants to add a subject to the students account.

As by the request of the students, the tuition master will register the subjects that students

want to study.

Actors

Staff

Preconditions

Staff must have proper access to system.



Basic Flow of Events

1. Tuition master access the system.

2. Tuition master access to the particular student interface

3. System validate student

4. The student is validated

5. Tuition master open register new subject interface

6. Tuition master add new subject

7. The system validate the subject

8. The subject is validated.

9. System saves the records

Alternative Flows

Student wants to change subject

1. Tution master access the system.

2. Tution master enter the student name

3. system validate student name

4. system process validation

5. Tution master access subject area

6. Tuition master modify subject area

7. Validate modification

8. System saves the record

Student wants to Delete subject

1. Tution master access the system.

2. Tution master enter the student name

3. system validate student name

4. system process validation

5. Tution master access subject area

6. Tuition master delete the subject requested

7. Validate modification

8. System saves the record



Key Scenarios

No response from system.

Post-conditions

Staff registered subject for student with no issue.



Register Student

Brief Description

This use-case starts when a new student wants to register. It ends when tuition master

complete a process of registering a new student successfully.

Actors

Staffs

Preconditions


Student has not already been registered in the system.




Information about new student is entered to the system and saved successfully.

1. Student fills out registration forms.

2. Student provides personal information.

3. Tuition master acknowledges the information.

4. Tuition master enter student’s information.

5. The system validate the student is eligible.

a. All necessary fields are filled out.

b. All information is entered in right format.

c. Student is a new student.

6. The system generates a unique ID for new student.

7. Tuition master gives student the ID.

Alternative Flows

Tuition master wants to add new student but that student has already been registered in the

system.

1. Student fills out registration forms.

2. Student provides personal information.

3. Tuition master acknowledges the information.

4. Tuition master enters student’s information.

5. The system assesses the student is not eligible to enrol because the student has

been already register into the system.

6. Tuition master cannot save the entries.

7. Tuition master cancel process.

Key Scenarios


Post-conditions

Student is registered and information is saved.



Generate Payment Statement

Brief Description

This use case starts when the students pays the feels for their registered subject.

Actors

Staff

Preconditions


Student must have paid the fees.




Student paid the fees for the registered subject and the payment statement generates

1. The tuition master access the system.

2. The tuition master access the particular student account

3. The system validate the student

4. Student validated

5. Tuition master access the payment section.

6. The tuition master updates the payment

7. The system validate the payment

8. Payment is validated

9. System generate the payment statement

Alternative Flows

Students want to check his or her fee statement

1. 2. The tuition master access system

2. The tuition master access the particular student account

3. The system validate the student

4. Student validated

5. The tuition master access the payment section

6. The system generate statement

10. System process generate payment

7. System issue receipt.

Key Scenarios


Post-conditions

Payment statement is generated.



Manage Tuition record

Brief Description

The use case starts when tuition master is going to edit the tuition record. This process

include add new record, delete new record and update new record. This use case will end

when tuition master successful edit the record and save the record.

Actors

Staff

Preconditions





Tuition master adds new tuition record and save the record.

1. Tuition master access add new record interface.

2. Tuition master enter the subject which taken by particular student.

3. Tuition master enter the student name.

4. The system validates the student name whether is registered or not.

5. Student name is validated.

6. Tuition master enter the date of the subject taught.

7. The system validates the date format.

8. Date format is validated.

9. Tuition master enter the duration of the subject taught.

10. Tuition master saves the record.

11. Record is successfully saved.

12. Tuition master logout from the interface.

Alternative Flows

Tuition master updates tuition record and save the record.

1. Tuition master access update record interface.

2. Tuition master enter particular student name.



5. All information about the student is showing up.

a) Student name.

b) Subject taken by the student.

c) Date of the particular subject taught.

d) Duration hours of the particular subject taught.



6. Tuition master selects the parts which need to update.

7. Tuition master edit the information.

8. The system validates the data whether is in correct form or not.

9. All data are validated.

10. Tuition master saves the record and successfully saved.


Tuition master selects an unwanted record and deletes it.

1. Tuition master access update record interface.

2. Tuition master enter particular student name.



5. All information about the student is showing up.

a) Student name.

b) Subject taken by the student.

c) Date of the particular subject taught.

d) Duration hours of the particular subject taught.

6. Tuition master selects the parts which need to update.

7. Tuition master edit the information.

8. The system validates the data whether is in correct form or not.

9. All data are validated.

10. Tuition master saves the record and successfully saved.


Key Scenarios


Post-conditions

Tuition record is updated.

The size of database is increase or decrease.



Chapter-5

Class Diagram

Register Subject

From the diagram, Admin class is connecting with Subject class. We make the Admin class

here because Admin has to store the subject information when a new student is going to apply

a new subject. Under subject class, it Code, Subject Name, Cost and Lecturer as attributes.

After make the registration, the system will register new subject for the student. In here, we

assume that all students have to register the subject.



Register Student

This class diagram include student, student registration. Student class here is to store the

student information. The Student class has Student ID, Student Name, Email Address, and

Phone number as the attributes. The entire attribute is considered as student tuition record.



Generate Payment Statement

This Class diagram has two classes which is Admin and Tuition Payment. The Admin has

Student ID, Name, Email address, Phone number and Address as the attributes. On the other

hand, Tuition payment has Student ID, Student Name, Subject Code, Subject Name, Subject

Cost, Begin Date and End date as the attributes.



Manage Tuition Record

According to this diagram we can realize that the Manage Tuition Record is able to Adjust

the Student Subject and Details, the admin will still have the ID, Name, Email, and etc as

Attributes.

Unlike the Manage tuition the attributes will be as the following which are Student Details,

Subject Register, and the Admin here will be able to Add, Delete, and Update any one of the

Attributes.



Chapter-6

Sequence Diagram

This is the Sequence Diagram for Register a New Subject, and we can notice how the

Business work flow goes through different procedures between the Admin / Staff and the

System within the Database according to the Diagram.



This is the Sequence Diagram for Register a New Student, and we can notice how the





This is the Sequence Diagram for General payment statement, and we can notice how the





This is the Sequence Diagram for Manage tuition record, and we can notice how the Business

work flow goes through different procedures between the Admin / Staff and the System

within the Database according to the Diagram.

And how the Master Tuition is able to Add, Delete, and Update after it makes sure that the

Member Valid, then it can start to Record the Tuition process as it shows at the end of the

Sequence Process.



Chapter-7

State Diagram



This is the State Diagram for Manage tuition record, and we can notice how the Business

work flows goes down by the Admin / Staff and how the System respond according to the

Diagram.

Chapter-8

Description and Rational

This Assignment has been done through many procedures and following process, UML the

main modelling for the process going within the Tuition Payment Generator. By the Use Case

Diagram, Use Case, Class Diagram, Sequence Diagram. We were able to justify how the

work flow was done during the process of Tuition Payment Generator System between the

Admin / Staff and the System and what are the relations and connection could be in the inner

of the System to accomplish the process.

Tuition Payment Generator passes through few Software to be done, the first one is the VB

Visual Basic to create and develop the prototype with the help of the Access to create a small

Database to help us to show how the System will be in reality handling the process of the

Tuition Payment Generator.



Reflection

This assignment has brought a lot of light to the three of us. We have learned why it is

important to understand Unified Modelling language.

First of all, it helps us to visualize a proper system. It was easy to view the way that

different components in this system communicate with each other by drawing all these

diagrams. It was very difficult and complicated if we wanted to visualize our system from the

given scenario or text. The diagram was more structure and easy to understand.

Secondly, we noted that diagrams are more accurate, brief and unambiguous. For

example, in the sequence diagram we can see what happens in the system clearly or in use

case diagram we can specify the role played by actors that will interact with the system

accurately. This is because the language used to show various relationships is short and

accurate. For example, in the use case diagram, there is a line showing the relationship of the

admin registering the student or subject. Also it was very easy to add more details to the

diagram. It is not necessary to distort or cancel the overall system design for adding more

details or new requirement. For example, new class can be added to the class diagram, new

method or attribute can be added to class very easily.

Another experience we got by doing this assignment is to understand how to use all this

different systems for one purpose. We have used Visual Basic, Ms Access and Ms Visio to

complete this assignment. Though it was challenging, we manage to overcome it an get it

done.

Finally, we found out that the diagrams in UML can be used as a good and useful

documentation in future. It can help future system developers to understand the functionality

of components of the system easily. Also, it can help managers of the company who are not

experts in IT to easily understand how the system works.



We also learn to accept the opinion from each other when we make decisions. Even

though, we come from different backgrounds and have different perspective on things, we

were still always able to make a proper conclusion of things. When having group discussions,

all of us have a different understanding so it was difficult at first to come to conclusion on

things. However, we all had the maturity to put the assignment fist and forget our differences.

We realise that the goal of us discussing is the same and we need to come to terms with it.

In a nutshell, it was a great experience doing this assignment and we think that this is a

success.



Critical Appraisal

Unified modelling tool is interesting module to study. Throughout this whole semester

we came across lot of modelling tools and diagram. This will pay a very critical role in future

when we go to job market.

First of all we learned all basic about the UML. After the basic, were able to learn more

and useful things about this language such as all the different charts we learned. We learned

how to draw Use case diagram, Class diagram, Sequence diagram, and finally State diagram.

We also learned all the functionality and purpose of all these diagrams. We have to admit that

drawing the diagrams were not so simple and we did take a lot of time doing them but we

manage to in the end.

We faced a lot of problems doing the class diagram. It was most challenging to us as we

were not able to complete it properly. The main reason for that is because we all had different

ideas on how to complete it. The attributes took a long time to decide and that actually cause

us some problems.

In short the biggest challenge for us is class diagram. But we managed to come up with

some good piece of work. And when we put more effort on studying class diagram we can

make better piece of work, hopefully next time.



System Prototype

All these Diagrams been draw above and explanation been done have been transformed to a

Prototype System to show how the System provide to the Actor an ability to access different

buttons.

This photo provide to the admin few Buttons to press and take him to different pages will

show below. Register Subject Button, Register Student Button, payment Statement button,

Tuition Record Button.



As we can see here after clicking on the Register Subject the admin is able to Record down

the details that the System need as it shown in this photo, and the extra feature to show the

Database Information in the System.

This photo shows the previous explanation about the Registration Subject, and the System

tells the admin that Registration process is done.



This photo shows how after clicking on the Database Button how it appears to the User.

This photo is for the Registration Student that the System need from the Admin to fill the

details in.



This is how the Database look after fill the Student details that need by the System through

the Admin.

This show the admin after clicking on the Fees Statement Button in the Main page of the

System, And show all the details for a specific student, with the ability for search by typing

the TP No.



This page show to Admin the Subjects that related to a specific Student after input the TP and

from that particular page can Add New Subject, Delete, and Update for any certain reason.



Reference

Hans-Gerhard Gross, 1998. Component-based software testing with UML, Springer-

Verlag Berlin Heidelberg


OOM Group Assignment

Documents

Transcript of OOM Group Assignment