DCE CS6511 Lab Manual

Dhanalakshmi College Of Engineering
Manimangalam, Tambaram, Chennai –601 301
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
CS6511 – CASE TOOLS LABORATORY
V SEMESTER - R 2013
LABORATORY MANUAL
Name : ______________________________________
Reg. No. : ______________________________________
Section : ______________________________________
DHANALAKSHMI COLLEGE OF ENGINEERING
VISION
Dhanalakshmi College of Engineering is committed to provide highly disciplined, conscientious and

enterprising professionals conforming to global standards through value based quality education and
training.
MISSION
 To provide competent technical manpower capable of meeting requirements of the industry
 To contribute to the promotion of Academic Excellence in pursuit of Technical Education at different levels
 To train the students to sell his brawn and brain to the highest bidder but to never put a price tag on heart
and soul
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
VISION
To strive for acquiring, applying and imparting knowledge in Computer Science and Engineering through
quality education and to provide enthusiastic professionals with commitment
MISSION
 To educate the students with the state-of-art technologies to meet the growing challenges of the electronics
industry
 To carry out research through continuous interaction with research institutes and industry, on advances in
communication systems
 To provide the students with strong ground rules to facilitate them for systematic learning, innovation and
ethical practices
PROGRAMME EDUCATIONAL OBJECTIVES (PEOs)
1. FUNDAMENTALS
To impart students with fundamental knowledge in Mathematics, Science and fundamentals of engineering
that will mould them to be successful professionals
2. CORE COMPETENCE
To provide students with sound knowledge in engineering and experimental skills to identify complex
software problems in industry and to develop practical solutions for them
3. BREADTH
To provide relevant training and experience to bridge the gap between theory and practice which enables
them to find solutions for real time problems in industry and organization, and to design products requiring
interdisciplinary skills
4. PROFESSIONAL SKILLS
To bestow students with adequate training and provide opportunities to work as team that will build up their
communication skills, individual leadership and supportive qualities, and to enable them to adapt and work in ever
changing technologies
5. LIFELONG LEARNING
To develop the ability of students to establish themselves as professionals in Computer Science and
Engineering and to create awareness about the need for lifelong learning and pursuing advanced degrees
PROGRAMME OUTCOMES (POs)
On completion of the B.E. (CSE) degree, the graduates will be able
a) To apply the basic knowledge of Mathematics, Science and engineering fundamentals in Computer Science
and Engineering field
b) To design and conduct experiments as well as to analyze and interpret and apply the same in the career
c) To design and develop innovative and creative software applications
d) To understand a complex real world problem and develop an efficient practical solution
e) To create, select and apply appropriate techniques, resources, modern engineering and IT tools
f) To understand their roles as a professionals and give the best to the society
g) To develop a system that will meet expected needs within realistic constraints such as economical,
environmental, social, political, ethical, safe and sustainable
h) To communicate effectively and make others understand exactly what they are trying to convey in both
verbal and written forms
i) To work in a team as team member or a leader and make unique contributions and work with coordination
j) To engage in lifelong learning and exhibit their technical skills
k) To develop and manage projects in multidisciplinary environment

SYLLABUS
COURSE OBJECTIVES
To learn the basics of OO analysis and design skills
To be exposed to the UML design diagrams
To learn to map design to code
To be familiar with the various testing techniques
LIST OF EXPERIMENTS:
1. To develop a mini-project by following the 9 exercises listed below.
2. To develop a problem statement.
3. Identify Use Cases and develop the Use Case model.
4. Identify the conceptual classes and develop a domain model with UML Class diagram.
5. Using the identified scenarios, find the interaction between objects and represent them using
UML Sequence diagrams.
1. Draw relevant state charts and activity diagrams.
2. Identify the User Interface, Domain objects, and Technical services. Draw the partial
layered, logical architecture diagram with UML package diagram notation.
3. Develop and test the Technical services layer.
4. Develop and test the Domain objects layer.
5. Develop and test the User interface layer.
SUGGESTED DOMAINS FOR MINI-PROJECT
1. Passport automation system

2. Book bank
3. Exam Registration
4. Stock maintenance system
5. Online course reservation system
6. E-ticketing
7. Software personnel management system
8. Credit card processing
9. e-book management system
10. Recruitment system
11. Foreign trading system
12. Conference Management System
13. BPO Management System
14. Library Management System
15. Student Information System
COURSE OUTCOMES
 Develop an IEEE standard SRS document
 Design and implement projects using OO concepts
 Identify Use Cases and develop the Use Case model, Activity diagram, State Chart diagram,
Interaction diagrams and package diagram
 Identify User Interface layer, Domain layer and technical & services layer
 Understand techniques, processes, and artifacts that can mitigate the risks
 Compare and contrast various testing techniques

INDEX
Sl. No. Name of the Experiment Page No.
CYCLE 1 – EXPERIMENTS
1 Study of UML 1
2 Passport Automation System 3
3 Online Book Banking System 5
4 Exam Registration System 7
CYCLE 2 – EXPERIMENTS
5 Stock Maintenance System 29
6 Recruitment System 33
7 Credit Card Processing System 38
8 Online Course Registration System 41

Ex. No.:1
STUDY OF UML
Aim:
General study of UML
Description:
The heart of object-oriented problem solving is the construction of a model. The model
abstracts the essential details of the underlying problem from its usually complicated real world.
Several modeling tools are wrapped under the heading of the UML, which stands for Unified
Modeling Language. The purpose of this course is to present important highlights of the UML.
At the center of the UML are its nine kinds of modeling diagrams, which we describe here.
• Use case diagrams
• Class diagrams
• Object diagrams
• Sequence diagrams
• Collaboration diagrams
• State chart diagrams
• Activity diagrams
• Component diagrams
• Deployment diagrams
The UML is applicable to object-oriented problem solving. Anyone interested in learning
UML must be familiar with the underlying tenet of object-oriented problem solving it all begins
with the construction of a model. A model is an abstraction of the underlying problem. The
domain is the actual world from which the problem comes. Models consist of objects that
interact by sending each other message. Think of an object as "alive." Objects have things they
know (attributes) and things they can do (behaviors or operations). The values of an object's
attributes determine its state.
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors
(methods or functions) into a single distinct entity. Objects are instances of classes.
An Introduction to UML Diagram:
The Unified Modeling Language is a language for specifying, constructing, visualizing,

and documenting the artifacts of a software-intensive system. Analogous to the use of
architectural blueprints in the construction industry, UML provides a common language for
describing software models, and it can be used in conjunction with a wide range of software
lifecycles and development processes.
Use Case Diagram:
Use Case diagrams identify the functionality provided by the system (use cases), the
users who interact with the system (actors), and the association between the users and the
functionality. Use Cases are used in the Analysis phase of software development to articulate the
high-level requirements of the system. The primary goals of Use Case diagrams include:
• Providing a high-level view of what the system does

• Identifying the users ("actors") of the system
• Determining areas needing human-computer interfaces.
Graphical Notation:
The basic components of Use Case diagrams are the Actor, the Use Case, and the
Association.
Actor:
An Actor, as mentioned, is a user of the system, and is depicted using a stick figure. The
role of the user is written beneath the icon. Actors are not limited to humans. If a system
communicates with another application, and expects input or delivers output, then that
application can also be considered an actor.
Use Case:
A Use Case is functionality provided by the system, typically described as verb + object
(e.g. Register Car, Delete User). Use Cases are depicted with an ellipse. The name of the use
case is written within the ellipse.
Association:
Associations are used to link Actors with Use Cases, and indicate that an Actor
participates in the Use Case in some form. Associations are depicted by a line connecting the
Actor and the Use Case.
The following image shows how these three basic elements work together to form a use
case diagram.
Use case diagrams describe what a system does from the standpoint of an external
observer. The emphasis is on what a system does rather than how.
Use case diagrams are helpful in three areas.

• Determining features (requirements). New use cases often generate new requirements
as the system is analyzed and the design takes shape.
• Communicating with clients. Their notational simplicity makes use case diagrams a
good way for developers to communicate with clients.
• Generating test cases. The collection of scenarios for a use case may suggest a suite of
test cases for those scenarios.
2. Sequence Diagram:
Sequence diagrams document the interactions between classes to achieve a result, such as
a use case. Because UML is designed for object-oriented programming, these communications
between classes are known as messages. The Sequence diagram lists objects horizontally, and
time vertically, and models these messages over time.
Notation:
In a Sequence diagram, classes and actors are listed as columns, with vertical lifelines
indicating the lifetime of the object over time.
Object:
Objects are instances of classes, and are arranged horizontally. The pictorial
representation for an Object is a class (a rectangle) with the name prefixed by the object name
(optional) and a semi-colon.
Actor:
Actors can also communicate with objects, so they too can be listed as a column. An
Actor is modeled using the ubiquitous symbol, the stick figure.
Lifeline:
The Lifeline identifies the existence of the object over time. The notation for a Lifeline is
a vertical dotted line extending from an object.
Activation:
Activations, modeled as rectangular boxes on the lifeline, indicate when the object is
performing an action.
Message:
Messages, modeled as horizontal arrows between Activations, indicate the

communications between objects.
Below is a sequence diagram for making a hotel reservation. The object initiating the
sequence of messages is a Reservation window.
The Reservation window sends a makeReservation() message to a HotelChain. The
HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available rooms,
then it makes a Reservation and a Confirmation.
Each vertical dotted line is a lifeline, representing the time that an object exists. Each
arrow is a message call. An arrow goes from the sender to the top of the activation bar of the
message on the receiver's lifeline. The activation bar represents the duration of execution of the
message.
• Activity Diagram:
Activity diagrams are used to document workflows in a system, from the business level
down to the operational level. When looking at an Activity diagram, you'll notice elements from
State diagrams. In fact, the Activity diagram is a variation of the state diagram where the "states"
represent operations, and the transitions represent the activities that happen when the operation is
complete. The general purpose of Activity diagrams is to focus on flows driven by internal
processing vs. external event.
Activity States:
Activity states mark an action by an object. The notations for these states are rounded
rectangles, the same notation as found in State chart diagrams.
Transition:
When an Activity State is completed, processing moves to another Activity State.

Transitions are used to mark this movement. Transitions are modeled using arrows.
Swim lane:
Swim lanes divide activities according to objects by arranging objects in column format
and placing activities by that object within that column. Objects are listed at the top of the
column, and vertical bars separate the columns to form the swim lanes.
Initial State:
The Initial State marks the entry point and the initial Activity State. The notation for the
Initial State is the same as in State chart diagrams, a solid circle. There can only be one Initial
State on a diagram.
Final State:
Final States mark the end of the modeled workflow. There can be multiple Final States on
a diagram, and these states are modeled using a solid circle surrounded by another circle.
Synchronization Bar:
Activities often can be done in parallel. To split processing ("fork"), or to resume

processing when multiple activities have been completed ("join"), Synchronization Bars are
used. These are modeled as solid rectangles, with multiple transitions going in and/or out.
4. Component Diagram:
Component diagrams fall under the category of an implementation diagram, a kind of

diagram that models the implementation and deployment of the system. A Component Diagram,
in particular, is used to describe the dependencies between various software components such as
the dependency between executable files and source files. This information is similar to that
within make files, which describe source code dependencies and can be used to properly compile
an application.
Component:
A component represents a software entity in a system. Examples include source code

files, programs, documents, and resource files. A component is represented using a rectangular
box, with two rectangles protruding from the left side, as seen in the image to the right.
Dependency:
A Dependency is used to model the relationship between two components. The notation
for a dependency relationship is a dotted arrow, pointing from a component to the component it
depends on.
5. Class Diagram:
A Class diagram gives an overview of a system by showing its classes and the
relationships among them. Class diagrams are static -- they display what interacts but not what
happens when they do interact.
The class diagram below models a customer order from a retail catalog. The central class
is the Order. Associated with it are the Customer making the purchase and the Payment. A
Payment is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line
items), each with its associated Item.
UML class notation is a rectangle divided into three parts: class name, attributes, and
operations. Names of abstract classes, such as Payment, are in italics. Relationships between
classes are the connecting links.
Our class diagram has three kinds of relationships.
• Association -- a relationship between instances of the two classes. There is an association
between two classes if an instance of one class must know about the other in order to
perform its work. In a diagram, an association is a link connecting two classes.
• Aggregation -- an association in which one class belongs to a collection. An aggregation
has a diamond end pointing to the part containing the whole. In our diagram, Order has a
collection of OrderDetails.
• Generalization -- an inheritance link indicating one class is a superclass of the other. A
generalization has a triangle pointing to the superclass. Payment is a superclass of Cash,
Check, and Credit.
An association has two ends. An end may have a role name to clarify the nature of the
association. For example, an OrderDetail is a line item of each Order.
A navigability arrow on an association shows which direction the association can be
traversed or queried. An OrderDetail can be queried about its Item, but not the other way around.
The arrow also lets you know who "owns" the association's implementation; in this case,
OrderDetail has an Item. Associations with no navigability arrows are bi-directional.
The multiplicity of an association end is the number of possible instances of the class
associated with a single instance of the other end. Multiplicities are single numbers or ranges of
numbers. In our example, there can be only one Customer for each Order, but a Customer can
have any number of Orders.
This table gives the most common multiplicities.
Multiplicities Meaning
0..1 zero or one instance. The notation n . . m indicates n tom instances.
0..* or * no limit on the number of instances (including none).
1 exactly one instance
1..* at least one instance
Every class diagram has classes, associations, and multiplicities. Navigability and roles
are optional items placed in a diagram to provide clarity.
6. Packages and Object Diagrams:

To simplify complex class diagrams, you can group classes into packages. A package is
a collection of logically related UML elements. The diagram below is a business model in which
the classes are grouped into packages.
Packages appear as rectangles with small tabs at the top. The package name is on the tab
or inside the rectangle. The dotted arrows are dependencies. One package depends on another if
changes in the other could possibly force changes in the first.Object diagrams show instances
instead of classes. They are useful for explaining small pieces with complicated relationships,
especially recursive relationships.
This small class diagram shows that a university Department can contain lots of other
Departments.
The object diagram below instantiates the class diagram, replacing it by a concrete example.
Each rectangle in the object diagram corresponds to a single instance. Instance names are
underlined in UML diagrams. Class or instance names may be omitted from object diagrams as
long as the diagram meaning is still clear.
7. Collaboration Diagrams:
Collaboration diagrams are also interaction diagrams. They convey the same information
as sequence diagrams, but they focus on object roles instead of the times that messages are sent.
In a sequence diagram, object roles are the vertices and messages are the connecting links.
The object-role rectangles are labeled with either class or object names (or both). Class
names are preceded by colons ( : ). Each message in a collaboration diagram has a sequence
number. The top-level message is numbered 1. Messages at the same level (sent during the same
call) have the same decimal prefix but suffixes of 1, 2, etc. according to when they occur.
8. State Chart Diagrams:
Objects have behaviors and state. The state of an object depends on its current activity or
condition. A statechart diagram shows the possible states of the object and the transitions that
cause a change in state. Our example diagram models the login part of an online banking system.
Logging in consists of entering a valid social security number and personal id number, then
submitting the information for validation.
Logging in can be factored into four non-overlapping states: Getting SSN, Getting PIN,
Validating, and Rejecting. From each state comes a complete set of transitions that determine the
subsequent state.
States are rounded rectangles. Transitions are arrows from one state to another. Events or
conditions that trigger transitions are written beside the arrows.
Our diagram has two self-transition, one on Getting SSN and another on Getting PIN.
The initial state (black circle) is a dummy to start the action. Final states are also dummy states
that terminate the action.
9. Component and deployment Diagrams:
A component is a code module. Component diagrams are physical analogs of class

diagram. Deployment diagrams show the physical configurations of software and hardware.
The following deployment diagram shows the relationships among software and
hardware components involved in real estate transactions.
The physical hardware is made up of nodes. Each component belongs on a node.
Components are shown as rectangles with two tabs at the upper left.
Logical Architecture and UML Package Diagrams:
The design of a typical OO system is based on several architectural layers, such as a UI

layer, an application logic (or "domain") layer, and so forth.
Fig: Logical architecture using a UML package diagram.
• A UML package diagram provides a way to group elements. A UML package can group
anything: classes, other packages, use cases, and so on.
• It is common to want to show dependency (a coupling) between packages so that
developers can see the large-scale coupling in the system.
• A UML package represents a namespace so that, for example, a Date class may be
defined in two packages. If you need to provide fully-qualified names, the UML notation
is, for example, java::util::Date in the case that there was an outer package named "java"
with a nested package named "util" with a Date class.
Designing with Layers:

Guidelines:
The responsibilities of the objects in a layer should be strongly related to each other and
should not be mixed with responsibilities of other layers. For example, objects in the UI layer
should focus on UI work, such as creating windows and widgets, capturing mouse and keyboard
events, and so forth. Objects in the application logic or "domain" layer should focus on
application logic, such as calculating a sales total or taxes.
UI objects should not do application logic. For example, a Java Swing JFrame (window)
object should not contain logic to calculate taxes or move a game piece. And on the other hand,
application logic classes should not trap UI mouse or keyboard events.
The Model-View Separation Principle:
The Model-View Separation principle states that model (domain) objects should not have
direct knowledge of view (UI) objects. So, for example, a Register or Sale object should not
directly send a message to a GUI window object Process Sale Frame, asking it to display
something, change color, close, and so forth.
Result:
A detailed Study of UML has been completed.
Viva-voce:
1. Define - Object Oriented Analysis

2. List out the characteristics of an object.
3. What are the three ways and perspectives to apply UML?
4. What is Software Requirement Specification (SRS) ?
5. What are the steps involved in completing a project?
6. What are different types of requirements?
7. What are functional requirements?
8. How requirements are collected?
9. What is an object?
10. What is analysis?
11. What is a design?
12. What is meant by Gantt Chart?
13. Write the problem statement for railway reservation system.
14. Draw the Gantt chart for railway reservation system.
15. Write the problem statement for passport automation system.
16. Draw the Gantt chart for passport automation system.
17. Write the problem statement for ATM system.
18. Draw the Gantt chart for ATM system.
19. List out the UML diagrams
20. Write the design part of book bank system.
21. What are the different relationships?
22. What are the advantages of creating a model?
23. Define - Unified Process
24.Identify the objects in railway reservation systems.
25.What are the reason to use unified process?
26.What are the phases of unified process?
Ex. No.: 2
PASSPORT AUTOMATION SYSTEM
Aim:
To develop a project for online passport automation system using ArgoUML
System Requirement Specification (SRS):

1. Problems Analysis and Project Planning
1. 1. Introduction
This system deals with online passport automation for the applicant .Online passport
automation system has been defined online passport automation process in their houses through
internet .Therefore, the online passport automation process can be done efficiently in advance
and without much of delay. The use case descriptions and other documents are described in such
a way that the user understand it and finds it easy to use.
1.2. Objective
The purpose of this document is to define the requirements of online passport automation
system. This system contains the details about the applicant, appointment date & time and the
date of expiry.
1.3. Scope
In the online passport automation system, the applicant should enter their details, submit
the form in the database and the applicant should attend the verification process.
1.4. Problem Statement
The online passport automation system deals about applying and renewing the passport
for submitting the applicant details to the administrator and confirming it by the police. This
system tries to use any kind of interface as simple as possible and at the same time not risking
the security of data stored in the database. The system will retain information on the entire
applicant who has necessary rights to apply for the passport. The particular applicant should have
a nationality.
If the entire process of “Issue of Passport” is done in a manual manner then it would take
several months for the passport to reach its applicant. An automatic system is essential to meet
the rising demand. For security purpose, only the administrator is allowed to maintain the
applicant details. The applicant details are stored in a highly secured database, so that it cannot
be illegally accessed. The online passport automation database administrator maintains all the
applicant and passport details. The administrator takes care of adding or deleting the applicant
details, modifying the data, renewing the passport. He should be able to monitor the overall
progress of the system. Administrator is responsible for the entire process within the system.
Online passport automation system enables us to save time, reduce the workload and process
application. This system is efficient in the way that there is no manual intervention. This system
provides instant and accurate results for applying the passport online. Finally, these systems aim
at improving the efficiency in the issue of passport and reduce the complexities involved in it to
the maximum possible extent.
2. Problem Statement (Use case) Analysis:

2.1. Identified Use cases:
2.1.1. Applicant Details: This use case allows the applicant to enter the details such as name,
gender, age, address, contact details, etc.
2.1.2. Status Enquiry: This use case includes the process of applying and renewing the passport.
2.1.3. Generate Unique Id: This use case generates and issues the unique id for each applicant.
2.1.4. Verification: This use case allows the administrator to verify the details of applicant.
2.1.5. Confirmation: This use case explains the confirmation process done by the police.
2.2. Identified Actors:

2.2.1. Applicant: The applicant is the primary actor who decides whether to apply or renew the
passport.
2.2.2. Administrator: This supporting actor is responsible for the entire process involved in the
online passport automation system.
2.2.3. Database: This offstage actor contains all the information about the applicant and passport.
2.2.4. Police: This actor will confirm the verified details.
3. Design of Passport Automation System:

3.1. Applicant details:
3.1.1. Brief Description: This use case allows the applicant to enter the details such as name,
gender, age, address, contact details, etc.
3.1.2. Flow of Events:
3.1.2.1. Basic Flow: 1. This use case starts when the applicant enter their details.
2. The Database accepts the applicant details.
3.1.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.1.3. Pre condition: Specifying the applicant details.
3.1.4. Post condition: The entered details are stored in the database.
3.2. Status Enquiry:

3.2.1. Brief Description: This use case generates the process of applying and renewing the
passport.
3.2.2. Flow of events:
3.2.2.1. Basic Flow:
1. This use case starts when the actor wishes to apply for the passport first time.
2. This use case starts when the actor wishes to renew the passport.
3.2.2.2. Alternate Flow: If the mandatory field is not filled, the prompt message is displayed.
3.2.3. Pre condition: Selecting the status.
3.2.4. Post condition: If the use case is successful then the applicant will get the new
passport or renew the old passport.
3.3. Generate Unique Id:

3.3.1. Brief Description: This use case generates and issues unique id for each applicant.
3.3.2.1. Basic Flow: When the applicant submits their details, the administrator will generate and
issue a unique id for each applicant.
3.3.2.2. Alternate Flow: Incomplete mandatory fields: If all the details are not entered by the
applicant, the administrator will not issue unique id.
3.3.3. Pre condition: The customer details are submitted to the administrator.
3.3.4. Post condition: Unique id is generated for each customer based of the details provided.
3.4. Verification:
3.4.1. Brief Description: This use case allows the administrator to verify the details of
applicant.
3.4.2.1. Basic Flow:Verification of passport is done by the admin and report is submitted to the
police for confirmation.
3.4.2.2. Alternate Flow:If the online detail entered by the applicant does not match with the proof
submitted to administrator, the further process is halted.
3.4.3Pre condition: The details are verified using the generated unique id.
3.4.4. Post condition: The reports are submitted to the police for confirmation.
3.5. Confirmation:
3.5.1. Brief Description: This use case explains the confirmation process done by the police.
3.5.2.1. Basic Flow: This use case starts when the actor finishes their verification.
3.5.2.2. Alternate Flow: This use case starts when the actor‟s details are not true.
3.5.3. Pre condition: The applicant details are verified by the police.
3.5.4. Post condition: The passport will be issued, verified details are correct.
4. Sample UML Diagrams:
4. 1.Usecase Diagram:
4.2. Class Diagram:
4.3. Sequence Diagram:
4.4. Colloboration Diagram:
4.5. Activity Diagram:
4.6. State Chart Diagram:
4.7. Component Diagram:
4.8. Deployment Diagram:

Result:
This project was carried out in a sequential manner to design and implement the
“passport automation system”. Thus the outcome of the project is efficient. The passport
automation system caters various requirements of the user to perform various options.
Viva Voce:
1. Define − Use case

2. List the relationships used in use cases.
3. What is a scenario?
4. In which phase the use case model is developed ?
5. How the actor can be represented?
6. List out the notations used in use case diagram.
7. Draw the use case diagram for hospital management system.
8. Draw the use case diagram for library management system.
9. Draw the use case diagram for ATM system.
10. What are the requirements to draw use case diagram?
11. Define − Actor
12. Differentiate include from extend relationship.
13. What is generalisation?
14. What is realisation?
15. Write the purpose of use case.
16. Define − Artifacts.
17. Identify the use cases in passport automation system.
18. List the actors involved in the passport automation system.
19. Identify the use cases in hospital management system.
20. List the actors involved in the hospital management system.
21. Identify the use cases in library management system.
22. List the actors involved in the library management system.
23. Identify the use cases in ATM system.
24. List the actors involved in the ATM system.
25. Write the problem statement for passport automation system.
Ex. No.: 3
ONLINE BOOK BANKING SYSTEM
Aim:
To analyze, design and develop code for online book banking system using ArgoUML
1. Problems Analysis and Project Planning:
1.1. Introduction
This document deals with book banking system for students. This System has been
designed for student reference purpose such as borrowing books. It is an efficient way to
improve the student‟s academic activities. Use case descriptions and other documents are
described in such a way that the student understands it and finds it easy to use.
1.2. Objective
The purpose of this document is defined to collect the requirements of book banking
system. This system contains details about displaying the books, lending books, maintaining
books, returning books, checking status, paying dues and penalties, maintaining member details,
etc.
1.3. Scope
This document for book banking system makes the students borrow books, through
internet. The system reduces power and enables the user to save his/her valuable times.
Computers play an integral role in day to day life. Due to advancement in communication
technology internet came into existence. With the help of these two all the jobs are computerized
now. So there is no exception of book banking system is done to replace the manual entering and
processing of information which are prone to error and are tedious.
The system will have window based desktop interface allow the administrator to update
the information. The administrator keeps track of member details and book details. The system
will have all the details about the book and its availability. A database is maintained by the
database administrator. The member should provide their necessary information such as course,
year etc., for registration purpose. Then the student has to login with their name and id and
proceed further. The student has options to select books, renew and return. A pupil is allowed to
take 3 books at a time. The student selects the book based on author name and edition that
will be displayed in the website. If the student delays to return or renew the book, then he/she
must pay the penalty amount at the time of returning the book.
2. Problem Statement (Use case Analysis):

2.1. Identified Use cases
2.1.1. Member Details: It helps the students to login and register themselves.
2.1.2. Book Details: Students can check the availability of the books.
2.1.3. Order Books: Student can order the books according to their need and convenience.
2.1.4. Payment Mode: Payment can be done either by cash or credit card.
2.1.5. Authentication: The administrator will authenticate the student.
2.1.6. Return Books: Students should return the books on or before the due date.
2.2. Identified Actors
2.2.1. Student: The person who wishes to retrieve books from the book bank.
2.2.2. Database: This actor stores all the information about the student and book.
2.2.3. Bank System: If the student selects the mode of payment as credit card this actor comes in.
2.2.4. Administrator: This actor manages the details of the student and books.
3. Design of Online Book Banking System:

3.1 Member Details
3.1.1. Brief Description: It helps the students to login and register themselves.
3.1.2. Flow Of Events
3.1.2.1. Basic Flow: 1.Student moves to the login page.
2. Students register their details.
3.1.2.2. Alternate Flow: If the student enters invalid login details, then error message will be
prompted.
3.1.3. Pre Condition: Entering information about the student.
3.1.4. Post Condition: Student information is stored into database.
3.2. Book Details

3.2.1. Brief Description: Students can check the availability of the books.
3.2.2.1. Basic Flow : 1.Student selects the book from the available list.
2.Book is added to student‟s account.
3.2.2.2. Alternate Flow: If the book is not available, then the prompt message will be displayed.
3.2.3. Pre Condition: Book details are entered.
3.2.4. Post Condition: Book is added to member‟s account.
3.3. Order Books

3.3.1. Brief Description: Student can order the books according to their needs and convenience.
3.3.2. Flow Of Events:
3.3.2.1. Basic Flow: Student selects and orders the books.
3.3.2.2. Alternate Flow: If any criteria like author name and edition is incorrect, then error
message will be prompted.
3.3.3. Pre Condition: Before ordering the book, the status of the book availability is checked.
3.3.4. Post Condition: The payment mode is selected and the payment is made accordingly.
3.4. Payment Mode

3.4.1. Brief Description: Payment can be done either by cash or credit card.
3.4.2.1. Basic Flow: 1.Payment mode is selected.
2. If the payment mode is credit card then account number and bank details must be given
3 The Acknowledgement or receipt is given back to the student.
3.4.2.2. Alternate Flow: If the bank details are incorrect, then error message will be prompted.
3.4.3. Pre- Condition: The payment is done by the student for the ordered books.
3.4.4. Post- Condition: The acknowledgement is received for the payment by the student.
3.5. Authentication
3.5.1. Brief Description: The administrator will authenticate the student.
3.5.2.1. Basic Flow: The administrator checks for the valid user and gives authentication to them.
3.5.2.2. Alternate Flow: If the user is not valid then error message will be prompted.
3.5.3. Pre-Condition: Valid users must be entered.
3.5.4. Post-Condition: Valid users are entered.
3.6. Return Books
3.6.1. Brief Description: Students should return the books on or before the due date.
3.6.2.1. Basic Flow: No dues or penalties, if the books are returned on or before the due date.
3.6.2.2. Alternate Flow: If the books are outdated, then penalty/fine will be collected.
3.6.3. Pre-Condition: Time limit of returning books are checked.
3.6.4. Post-Condition: Books are returned and details are updated in student‟s account.

4. 1. Use case Diagram:
4.2. Class Diagram:
4.2.1. Order Books:
4.2.2. Payment Mode:
4.3.1. Order Books:
4.4. Collaboration Diagram:
4.4.1. Order Books:
4.5. Activity Diagram:
4.5.1. Order
Books:
4.6. Statechart Diagram:

4.6.1. Order Books:

4.7. Component Diagram:
Result:
This project was carried out in a sequential manner to design & implement the “online
book banking system”. Thus, the outcome of the project is efficient. The online book banking
system caters the varied requirements of the user to perform various options.
Viva Voce:
1. What are Conceptual Classes?

2. How to Create a Domain Model?
3. How to Find Conceptual Classes?
4. What are the attributes of a class at conceptual level?
5. What is the other name of domain model?
6. What is class?
7. What is an object?
8. What is an attributes?
9. Write the problem statement for online book banking system.
10. What is cardinality?
11. What are the different cardinality ratios available in class diagram?
12. Identify the classes involved in online book banking system.
13. Identify the actors in online book banking system.
14. Identify the classes involved in passport automation system.
15. Identify the actors in passport automation system.
16. Write down the purpose of a class diagram.
17. Define - Structural diagram
18. List out the various notations in class diagram.
19. Define - Active class
20. What are the different visibility modes?
21. What is association relationship?
22. What is constraint?
23. Difference between composition and aggregation.
24. Define Generalization
25. Draw the class diagram for online book banking system.
Ex. No.: 4
EXAM REGISTRATION SYSTEM

Aim:
To analyze, design and develop code for online Exam registration system
1. Problem Analysis and Project Planning:

1.1. Introduction
This software has been developed in such a way that any applicant can register
themselves for their exams. Once an administrator builds software for the concerned
examination, any common applicant can use the software for registering themselves in the
examination.
1.2. Objective
This software enables any user or a student to view the examination conducted and also
the other details and register themselves for the desired examination provided all eligible criteria
specified are satisfied.
1.3. Scope
The main scope of this system is used for testing the applicant's individual capacity and
ability. Also the user can register him by going through the various details and particulars
regarding the exam of his/her choice. If the applicant is not eligible for a particular exam, the
software provides an option by giving a list of other available examinations.
This system gives the access rights of the software to the administrator. The admin has a
login form which asks for a valid username and password. This username and password can be
set as per the admin. The administrator is given the top priority; hence he/she has a login into the
software. Once, it has been logged in by the preset username and password, the software is
ready. Once, the software is ready, the admin creates a database and enters the examination
details required by the applicant. The details include the examinations available for a particular
field, fee structure for the exam and other particulars. The admin alone has the authority to add,
modify, and delete the various database details.
The applicant who wants to register himself for an examination can have a wide variety
of the various options, examinations offered and various eligibility criteria. The applicant having
got the full knowledge about the various examinations conducted, he/she enters his/her pass
percentage for registration of the particular examination, and he/she desires to attend. The
registration form includes the various fields like name, DOB, address and other personal details.
The eligibility criteria include fields such as year of passing, percentage of marks and so on. If
any empty value or any mismatch occurs then the error message is indicated.

2.1.1 Login:It helps the students to login.
2.1.2. Registration Form:It helps the student to register for the examination.
2.1.3. Eligibility Criteria: It helps to recognize whether the applicant is valid for the exam or
not.
2.1.4. Exam Details:It tells the details regarding the exam.
2.1.5. Fee Processing:It describes the fee structure pertaining to the exam.
2.1.6.Confirmation: It helps the applicant to confirm whether he/she is valid to write the
particular examination.
2.2. Identified Actors

2.2.1. Registration Website:
2.2.2. Database: This actor stores all the information about the student and exam.
2.2.3. Administration:This actor manages the details of applicant and exam.
2.2.4. Applicant:The person who wishes to write the exam.
2.2.5.UG: The one who register for their exam according to their UG syllabus.
2.2.6.PG: The one who register for their exam according to their PG syllabus.
2.2.7.Parent: The person who wish to check out the details of their ward‟s mark.
3. Design of Exam Registration System:
3.1. Login:
3.1.1. Brief Description: This use case describes how the administrator logs into the system, it
asks for a username and password, which is present.
3.1.2.1. Basic Flows:The system requests the actor (admin) to enter the username and password.
The actor enters the username and password and the system validates the entered name and
password and logs the actor into the system.
3.1.2.2. Alternate Flows:In the basic flow actor, if you enters an invalid name or password it
displays an error message. The actor can choose either to return to the beginning of the basic
flow or cancel the login at which it ends.
3.1.3. Pre Condition: None
3.1.4. Post Condition: If the use case was successful, the actor was logged on to the system or
the state will remain unchanged.
3.2. Registration Form:

3.2.1. Brief Description: The applicant uses this use case for registration by going through the
following flow of events involved in the registration process.
3.2.2.1. Basic Flow: This use case states that the applicant enters the registration form the
following activities takes place:
1. The registration form is displayed
2. The applicant enters the academic, technical and the personal details
3. The contents entered by the applicant is validated
4. If the contents entered are valid, a confirmation message is displayed.
3.2.2.2. Alternate Flow: If any of the content in any of the field entered by the applicant is
invalid an appropriate error message is displayed. The applicant then rectifies the error.
3.2.3. Pre Condition: The details entered by the applicant should satisfy the eligibility criteria
required for that particular course
3.2.4. Post Condition: If the registration was done successfully the applicant can come out of
the use case otherwise they can register again.
3.3. Eligibility Criteria:

3.3.1. Brief Description: In this use case, the applicant enters the criterion for eligibility such as
pass percentage, qualification, etc.
3.3.2.1. Basic Flow: This use case starts when the applicant enters their details.
The database accepts the details and checks whether the applicant is eligible.
3.3.2.2. Alternate Flow: If the mandatory field is not filled, then prompt message is displayed.
3.3.3. Pre Condition: The applicant specifies his/her details.
3.3.4 Post Condition: The admin checks whether the applicant is eligible, if so the applicant can
register for the examination.
3.4. Exam Details:

3.4.1. Brief Description: This use case describes how the applicant views the various details of
the examinations available and selects the examinations of his choice.
3.4.2.1. Basic Flow: This use case starts when the applicant checks the examinations details.
3.4.2.2. Alternate Flow: If the mandatory fields are not chosen, then prompt message is
displayed.
3.4.3. Pre Condition: The applicant views the exam details.
3.4.4. Post Condition: The applicant selects the exam dates, timings from this use case.
3.5. Fee Processing:

3.5.1. Brief Description: The applicant uses this use case for payment of fees through online
payment.
3.5.2.Flow Of Events:
3.5.2.1. Basic Flow: This use case starts when the applicant is eligible, he pays the fee.
3.5.2.2. Alternate Flow: If the fee is not paid, then the registration form will be neglected.
3.5.3. Pre Condition: The applicant pays the fees before due date.
3.5.4. Post Condition: If the fee processing is successful, then the applicant is ready to attend
the exam.
3.6. Confirmation:
3.6.1. Brief Description: This use case describes the confirmation of the applicant‟s regulation.
3.6.2.1. Basic Flow: This use case starts when the applicant finishes the registration.
3.6.2.2. Alternate Flow: If the registration was unsuccessful, the confirmation will not occur.
3.6.3. Pre Condition: The applicant verifies his/her confirmation for the registration.
3.6.4 Post Condition: If the use case is successful, then the applicant gets the confirmation
message.

4. 1.Usecase Diagram:
\
4.2. Class Diagram:
4.2.1. Registration Form:

4.2.2. Exam Details:
4.4. Collaboration Diagram:

4.5.Activity Diagram:
4.5.1.Registration Form:
4.5.2.Exam Details:
4.6.State Chart Diagram:
4.6.1.Registration Form:
4.6.2.Exam Details:
4.7.Component Diagram:

Result:
This project was carried out in a sequential manner to design & implement the “Exam
Registration system”. Thus, the outcome of the project is efficient. The exam registration system
caters the varied requirements of the user to perform various options.
Viva Voce:
1. What is meant by System Sequence Diagrams?

2. What is meant by link?
3. What is meant by Messages?
4. What is meant by interaction diagram?
5. List out the notation used in sequence diagram.
6. What is lifeline?
7. What is found message?
8. Difference synchronous message from asynchronous message.
9. What is conditional message?
10.What is self message?
11. Define - Execution
12. Write the purpose of the sequence diagram.
13. What are the two types of interaction diagram?
14. Mention the usese of communication diagram.
15. Identify the objects involved in passport automation system.
16. Identify the objects involved in exam registeration system.
17. write the sequence of exam registration form.
18. Give example for communication diagram.
19. How to represent the object in sequence diagram?
20. Draw the sequence diagram for ATM system.
21. Draw the sequence diagram for passport automation system.
22. Draw the sequence diagram for exam registeration system.
23. Draw the sequence diagram for library management system.
Ex. No.: 5
STOCK MAINTENANCE SYSTEM
Aim:
To develop a project on stock maintenance system
System Requirement Specification:

1. Problem Analysis And Project Planning:
1.1. Introduction:
The stock maintenance system is basically for the customers who access the information
about the stock and retrieves the information. Here in our project the departmental store stocks
are maintained and the profits are computed accordingly.
1.2. Objective:
The main objective of this project is to define the requirements of the stock maintenance
system. The specifications and the use case model together describe the complete set of
requirements on the system.
1.3. Scope:
Many artifacts were encountered in the previous software regarding the maintenance of
stocks. In our software all the defects are removed and it is reliable, user friendly and very
supportive.
1.4. Problem Statement:
A new stock maintenance system for a departmental store to replace the existing
maintenance system, which is inefficient. The new stock maintenance system allows the stock
maintainer to enter information about the stocks available in the departmental sore and compute
profits based on the total amount of sales.
The new system has a graphical user interface to allow the stock maintainer to enter the
information about the items and proprietor to compute the profits. Stock maintainer can only
access the information and purchase orders for security purpose.
The system retains information about all the items in the store. The system retains the
records of price of the different items, quantity and expiry date etc. The stock maintainer
maintains the information of the sale of items. The user can view the availability of all the items
in the store along with the price and can‟t make any changes of it.
2.1. Problem Statement Analysis:

2.1.1. Identified Use Case: A specific way of using the system from a user‟s perspective is
called as a use case. This is a sequence of related transactions performed by an actor and system.
2.1.2. Login: This use case describes how a user logs into a stock maintenance system.
2.1.3. View Stock: It is a transaction performed by the user when he wishes to view the items
available in the stock maintenance system.
2.1.4. Place Order And Billing: This use case is a transaction performed whenever any user
wants to place an order and also the billing details.
2.1.5. Purchase Stock: This use case is a transaction performed by the stock maintainer when he
wishes to purchase any stocks from the dealer.
2.1.6. Stock Updation: This is a use case where the stock is maintained by adding, and
modifying it from the stock maintenance system.
2.1.7. Profit Computation: This is a use case in which the profit is computed based on the total
sales with the actual price and the maximum retail price.
2.2. Identified Actors:

2.2.1. User: User can just view the items available in the system and can place orders.
2.2.2. Proprietor: The proprietor computes the profit based on the total sales and takes care of
the payment and the administrative reports.
2.2.3. Stock Maintainer: The stock maintainer can add, change and delete item information
from the system.
2.2.4. Dealer: The dealer supplies the item according to the needs of the stock maintainer.
2.2.5. Database: The database is a collection of data where the data is stored and from where the
data can be retrieved.
3. Design Of Stock Maintenance System:

3.1.Login:
3.1.1. Brief Description: This use case describes how a user logs into a stock maintenance
system.
3.1.2.1.Basic Flow: This use case starts when the user wishes to login to the stock maintenance
system.
1. The system requests that the user enters the name and password.
2. The user enters the name and password.
3. The system validates the name and password and logs the user to the system.
3.1.2.2.Alternate Flow:
1. If in the basic flow, the user enters an invalid name or pwd the system displays an
error message.
2. The user can choose to either return to the beginning of the basic flow or cancel the
login at which point the use case ends.
3.1.4. Post Condition: If the use case was successful the user is now logged into the system. If
not the system state is unchanged.
3.2. View Stock:

3.2.1. Brief Description: It is a transaction performed by the user when he wishes to view the
items available in the stock maintenance system.
3.2.2.1. Basic Flow: This use case starts when the user wishes to view the items existing in the
system.
1. The system requests the user to enter the name of the item.
2. The user enters the name of the item.
3. The system validates the item and displays it to the user.
3.2.3. Alternate Flow:

1. If in the basic flow, the user enters an invalid item then the system displays an
error message.
2. The user can either enter another item or return to the beginning of the basic
flow.
3.2.4. Pre Condition: The user logs onto the system.
3.2.5. Post Condition: If the use case was successful the user views the available stock else the
system state is unchanged.
3.3. Place Order And Billing:

3.3.1. Brief Description:
This is a transaction performed when the user needs to place an order and also the billing
details.
1. This use case starts when any user wishes to purchase any item
2. The user enters the required item
3. The system validates the item and then displays the details
3.3.2.2. Alternate Flow:
1. If the user enters an invalid item the system displays an error message
2. The user can place an order for some other item or can quit
3.3.4. Post Condition: If the use case was successful the billing details will be displayed or the
system state is unchanged.
3.4. Purchase Stock:

3.4.1. Brief Description: It is a transaction performed when the stock maintainer wants to
purchase stock from the dealer.
1. This use case starts when the stock maintainer wishes to purchase any item from the
dealer.
2. The stock maintainer gives the order according to the least quotation given by the
dealer.
If the stock maintainer is not satisfied with the quotation he can quit and can place order
later
3.4.3. Pre Condition: The stock maintainer logs onto the system
3.4.4. Post Condition: If the use case is successful then the stock maintainer places an order else
the system is unchanged.
3.5. Stock Updation:

3.5.1. Brief Description: This is the use case where the stock is maintained by adding, deleting
and modifying the items from the stock maintenance system.

3.5.2.1. Basic Flow: This use case starts when the stock maintainer wishes to record and
maintain the stock. This includes adding, deleting and modifying the stock.
1. The system request that the stock maintainer specify the function he/she would like to
perform.
2. Once the stock maintainer provides the required information, one of the sub flows is
executed.
• If the stock maintainer selected add item, it is executed.
• If the stock maintainer selected delete item, it is executed.
• If the stock maintainer selected modify item, it is executed.
3.5.2.1.1. Add Stock:
1. The system requests the stock maintainer to enter the information about the new item.
This includes name, price, and quantity of the item.
2. Once the information is provided the system generates and assigns an id to the item
3.5.2.1.2. Delete Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id, the system retrieves and displays the information
about the item.
3. The system provides the stock maintainer to confirm deletion of item.
4. The system deletes the item specified.
3.5.2.1.3. Modify Stock:
1. The system requests the stock maintainer to enter the item id.
2. The stock maintainer enters the id number, the system retrieves and displays the
information.
3. The stock maintainer makes the desired changes to the item.
4. The system modifies the information.
3.5.2.2.1. Absence Of Stock: If in the modify stock or delete stock sub flows, the stock with the
specified id does not exist, the system displays an error message. The stock maintainer can then
enter a different number or cancel the operation at which point the use case ends.
3.5.2.2.2. Delete Cancelled: If in the delete stock sub flow, the stock maintainer decides not to
delete the stock, the delete is cancelled and basic flow is started in the beginning.
3.5.3. Pre Condition: The stock maintainer logs onto the system.
3.5.4. Post Condition: If the use case is successful the stock maintainer makes the stock orders
else the system is unchanged.
3.6. Profit Computation:

3.6.1. Brief Description: This use case describes how the profit is calculated for the stock.
3.6.2.1. Basic Flow: This use case starts when the proprietor wants to compute the profit with the
actual price and the maximum retail price.
1. The proprietor gets the actual price and the maximum retail price from the
database.
2The profit is computed with the above data.
1. If the data are invalid then error message is displayed.
2. The correct data are then obtained from the database and profit is computed.
3.6.3. Pre Condition:
None
3.6.4.Post Condition: If the use case is successful then the profit is computed else the system
state is unchanged.
Result:
This project was carried out in a sequential manner to design and implement the “stock
maintenance system”. Thus, the outcome of the project is efficient. The stock maintenance
system caters various requirements of the user to perform various options.
Viva Voce:
1. What is an activity diagram?

2. What is state diagram?
3. List out the notations in UML state diagram.
4. What is events?
5. What is state?
6. What is tranition?
7. How to apply state machine diagram?
8. Difference state independent from state dependent.
9. List out common state dependent objects.
10.What is guard?
11.What is conditional guard?
12.How nested states are specified?
13.Draw the state diagram for book bank management system.
14.List out the notation used in activity diagram.
15.Write the purpose of activity diagram.
16.How to apply actrivity diagram?
17.What is meant by data flow modeling?
18.Draw data flow diagram for course registration system.
19.What is the use of rake symbol in UML activity diagram?
20.Mention the guidelines for acivity diagram.
21.Write the applications of acitivity diagram.
22.Draw the acivity diagram for library management system.
23.Draw the state chart for credit card management system.
Ex. No.: 6
RECRUITMENT SYSTEM
Aim:
To analyze, design and develop code for on-campus recruitment system using ArgoUML
Software Requirement Specification(SRS):

1. Problems Analysis and Project Planning:
1.1 .Introduction
The aim of this project is to implement the on-campus recruitment system conducted by the
FOUR SQUARES SYSTEM concern. This enables ease of allocating jobs for applicants and fills
concern vacancy positions.
1.2 Objectives
Applying for the job login, upload the resume, attend the interview online, check for the
result.
1.3. Scope
This is “RECRUITMENT SYSTEM” software, which is used to conduct on-campus

recruitment of a software company. The advantage of this software is that one can easily attend
the campus interview from their college campus itself and it filter out the eligible members for
the main interview. It saves time as well as provides an efficient recruitment system.
1.3.1Audience
The applicants who appear for this on-campus are the ones who are benefited by this
software.
1.3.2 Organization
This software is used by the software concern which conducts the online aptitude test and
interview for the recruitment of its applicants.
1.4 Problem Statement
Line managers often do not understand the whole process of recruitment. Managers
involved in the recruitment should not hire employees that should start as soon as possible. This
habit leads to poor recruitment and mis-profiling of individuals who will in turn become part of
the problems in the system. Recruitment at an officer and managerial level should be done
effectively and one should remember that once you make the mistake it takes sometime before
that mistake is corrected. It may be costly to the organization.
Many people we see in organizations today are in the wrong jobs and as a result, they are
not utilizing their full potential. This is compounded by the fact that some companies have built
a tradition of hiring people based on personal connections when the person is not qualified for
the job. This is a vivid case in most Organizations today. From the author‟s experience, most
recruitment that involves managers are done during discussions at lunch hour, at social clubs or
during the coffee break time. All the other processes that follow will only be a formality as the
decision would have been made by line managers involved in the process.
The other thing that the author observed is that, those line managers who are involved in
the recruitment are not given courses to enlighten them on the importance of the process. One
may ask, why is necessary always to be systematic in recruitment process? Certain type of
managers can make a significant impact on Organizations or Companies. Consequently, a
process or a strategy is necessary to deal effectively with equal opportunity issues, to hire the
right people, to minimize cost and most importantly, to identify marginal performers before they
are hired. Inadequate recruitment procedures will result in a number of staff not being
sufficiently qualified either for the positions they hold or their grades levels, especially in
management positions. Most formal systems are flawed in such fundamental respects that there
is a tendency to circumvent it through the application of ad hoc measures, which often rely
heavily on personal contacts.

2.1 Identified Use cases:
2.1.1 Login: This use case is used to login with the help of username and password.
2.1.2 Resume: The system receives the resume from the applicant and stores in DBA.
2.1.3 Test: The use case allows the applicant to undertake test.
2.1.4:Checking: The use case allows the system to verify the correct answers.
2.1.5 Interview: After evaluating the test when the person has been qualified then he/she can
attend the personal interview through online.
2.2 Identified Actors:

2.2.1 Applicant: This actor has user goals fulfilled through using services.
2.2.2 DBA: This kind of actor provides a service.
2.23.Government Tax Agency : This type of actor has an interest in the behavior of the use case
but is not primary or supporting actor.
3. Design Of Online Recruitment System:

3.1. Login :
3.1.1 Brief Description: User name and password
3.1.2 Flow Of Events: Enter into Login page and continue registration.
3.1.2.1 Basic Flow: Display the Login page.
3.1.2.2 Alternative Flow: If password or username is incorrect then prompt message will be
displayed
3.1.3 Pre-Condition: Enter the Username and password of the customer.
3.1.4 Post-Condition: Enter into the login page.
3.2 Resume:
3.2.1 Brief Description: The System receives the resume from the applicant and stores in DBA.
3.2.2 Flow Of Events: The Applicant enter into the login page, upload the resume and data‟s
are stored in database.
3.2.2.1 Basic Flow: upload the resume
3.2.2.2 Alternative Flow: If any details are missing then prompt message will be displayed.
3.2.3 Pre-Condition: enter into the login page.
3.2.4 Post Condition: resume is successfully loaded.
3.3 Test:
3.3.1 Brief Description: The use case allows the applicant to undertake test.
3.3.2 Flow Of Events: upload the resume, prepare for the test and undertake the test.
3.3.2.1 Basic Flow: participate in the test.
3.3.2.2 Alternative Flow: If any of the question left unanswered then display a prompt message
3.3.3 Pre-Condition: Enter into the test page.
3.3.4 Post-Condition: To finish the test.
3.4 Checking:
3.4.1 Brief Description: The use case allows the system to verify the correct answers and
updates in the database.
3.4.2 Flow Of Events: when the exam has been finished, DBA evaluates the test and produce
the level.
3.4.2.1 Basic Flow: Evaluating the test
3.4.2.2 Alternative Flow: For the wrong answers the mark will be reduced.
3.4.3 Pre-Condition: Checking the answers.
3.4.4 Post-Condition: Displaying the result.
3.5 Interview:
3.5.1 Brief Description: After evaluating the test when the person has been qualified then he/she
can attend the personal interview through online.
3.5.2 Flow Of Events: check whether qualified or not, personal interview for the applicant.
3.5.2.1. Basic Flow: Applicant should be qualified for the interview
3.5.2.2. Alternative Flow: : If not qualified then rejected for the interview.
3.5.3 Pre-Condition: check qualification
3.5.4 Post-Condition: Interviewing the candidate
3.6 Result:
3.6.1 Brief Description: The use case allows the actor to display the ids or name of the applicant
who had cleared the test
3.6.2 Flow Of Events: After the personal interview result will be produced and the applicant can
check for the result through e-mail.
3.6.2.1 Basic Flow: Displaying the result.
3.6.2.2 Alternative Flow: If not qualified it will show a message.
3.6.3 Pre-Condition: Evaluating the result of an interview.
3.6.4 Post-Condition: Display the confirmation message through e-mail.
Result:
Computerization of Recruitment System does effectively reduce the manual work

involved in recruiting applicants for the concerned firm. It saves time and gives easy access for
already stored information. It enables the administrator in providing faster services to the
applicants. The system is completely menu driven and extremely user friendly since it is
developed in an efficient front end tool Visual Basic. Appropriate error messages are also
provided to guide the user in a proper and user friendly manner. The system has effective
management of records which holds all the information about the candidates. Even if all the
details of the applicant are not sustained, reports are generated and sent to the applicant. Finally,
after passing all the confirmation requirements the unique registration number is issued to the
candidate.
Viva Voce:
1. List out some of the examples of package elements.

2. What is Package import?
3. What is the purpose of a Component Diagram?
4. Name the three general approaches for classification?
5.Name the five levels of process maturity in OOD?

6.Name the two process used by Grady BOOCH in his OO software development?
7.Name the four steps in Micro development process?
8.What are the steps followed in macro development process?
9.Short notes on OMT functional model.
10.Names the diagrams of Booch Methodology.
11.Name the models in objectory.
12.What is unified modeling language?
13. Name the available layers of the three layered approach to software development.
14.Write any two advantages of modeling?
15.What is Objectory?
16.Define − Static model?
17.Define − Dynamic model?
18.What is an association? Give one example.
19.What is a qualifier? Give one example.
20.What is a method?
Ex. No.: 7
CREDIT CARD PROCESSING SYSTEM
Aim:
The aim of this project is to implement the credit card processing system to do the
crediting and the payback transaction to help the clients by easier process.
System Requirement Specification (SRS)

1. Problem Analysis And Project Planning
1.1. Introduction
This document deals with the credit card processing system. The main purpose of this
system is crediting and doing payback transaction. Carrying of cash to each and every place is a
great load for clients in today‟s life and to reduce this, the credit card system was developed. The
user interface makes the credit card processing system to be efficient. It is such a reliable system
that it is able to process the client for their corresponding request and also perform functions for
many clients at the same time efficiently without any error occurrence.
1.2. Objective
This system tries to make transactions as simple as possible and at the same time not
risking the security of data transaction process. This minimizes the time duration in which the
consumer receives the item. The consumer should purchase an item from the shop by using
credit card payment then the merchant should give response to the consumers view while
purchasing an item from the shop and required processing of transaction should be done by the
merchant by using a credit card reader.
1.3. Scope
The credit cards are used during business transaction, and the rules are designed to
protect both the merchant and the consumer from fraud. In its simplest form, the Glossary is a
list of noteworthy terms and their definitions. It is surprisingly common that a term, often
technical or particular to the domain, will be used in slightly different ways by different
stakeholders; this needs to be resolved to reduce problems in communication and ambiguous
requirements
A problem statement is a concise description of the issues that need to be addressed by a

problem solving team and should be presented to them (or created by them) before they try to
solve the problem. When bringing together a team to achieve a particular purpose provide them
with a problem statement. The primary purpose of a problem statement is to focus the attention
of the problem solving team. However, if the focus of the problem is too narrow or the scope of
the solution too limited the creativity and innovation of the solution can be stifling. The credit
card transaction is used by the clients to do the crediting features that are available in bank and
do the payment back. The account has to be updated with the balance every time when the
crediting and the payback are done.
2. Problem Statement (Use case Analysis)

2.1.1 Make Order: The customer can make orders for the items they are going to purchase.
2.1.2. Update Order: If any items have to be changed or updated, the customers can update
their orders.
2.1.3. Cancel Order: Customers who are not interested in purchasing any items can remove or
cancel the orders that they have made.
2.1.4.Crediting Details: This involves the card holder name, card number, card expire date for
processing the amount transaction.
2.1.5. Payback Details: The customer must pay back the required amount within the given
duration time to the concerned organization.
2.2 . Identified Actors:

2.2.1. User: The customers who purchase some item from the shop by using credit card
payment are stored here.
2.2.2. Admin: All the crediting and payback transactions done by the customer are
administrated by the admin.
3. Design of Credit Card Processing System:

3.1. Make Order:
3.1.1brief Description: The customers who make orders for the item are maintained here.
3.1.2. Flow Of Events: Customers enter the order number, customer id and total orders they
have made.
3.1.2.1. Basic Flow: 1. Enter the item id, item quantity and the order id.
2. The items that are entered are ordered.
3.1.2.2. Alternate Flow: If any item id entered is not present then a prompt message will be
displayed.
3.1.3. Pre-Condition: Customers enroll their orders for purchase.
3.1.4. Post-Condition: The ordered items are purchased.
3.2: Update Order:
3.2.1. Brief Description: Customers who want to change their orders are stored here.
3.2.2. Flow Of Events: Enter the customer id, order number to update the order.
3.2.2.1. Basic Flow: 1. The item id, item quantity and order id is entered.
2. The entered items are being updated.
3.2.2.2. Alternate Flow: If the entered orders are already updated a prompt message will be
displayed.
3.2.3. Pre-Condition: The order is being updated.
3.2.4. Post-Condition: After updating the items are purchased.
3.3. Cancel Order:

3.3.1Brief Description: The cancellation orders made by customer are maintained here.
3.3.2. Flow Of Events: The order number, customer id, total orders taken are entered.
3.3.2.1. Basic Flow: 1. The item id, item quantity and order id are entered.
2. Cancelled orders are noted by admin to process the cancel request.
3.3.2.2. Alternate Flow: If the items entered are cancelled previously then a prompt message will be
displayed.
3.3.3. Pre-Condition: The items are cancelled.
3.3.4. Post-Condition: The cancelled items are restored back in the database.
3.4. Crediting Details:

3.4. 1 Brief Description: The crediting amount of the customer and its operation is maintained
over here.
3.4.2. Flow Of Events: The customer provides the details for crediting transactions.
3.4.2.1. Basic Flow: 1. The card holder name, card expire date and card number are entered by
the customer.
2. Card reader will processes the amount transaction.
3.4.2.2. Alternate Flow: If the date of card is expired or if there is low balance an error message
will be displayed.
3.4.3. Pre-Condition: The customer enters the details for making the transaction.
3.4.4. Post-Condition: Customer should put signature and give it to merchant.
3.5. Payback Details:
3.5.1. Brief Description: The amount that is paid back is maintained here.
3.5.2. Flow Of Events: The customer goes to login page for making the cash pay back
transaction.
3.5.2.1. Basic Flow: 1. Customer enters the name, account number and password for login.
2. The transaction id is entered for payment transaction.
3.5.2.2. Alternate Flow: An error message will be displayed in case of an invalid login.
3.5.3. Pre-Condition: A valid login is given by the customer for entering the transaction id.
3.5.4. Post-Condition: The pay back transaction has been made and admin stores it in the database.
Result:
Computerization of credit card management system does effectively reduce the manual
work involved in generating credit card to a citizen with unique credit card number. It saves time
and gives easy access for already stored information. It enables the administrator in providing
faster services to the applicants. The system is completely menu driven and extremely user
friendly since it is developed in an efficient front end tool Visual Basic. Appropriate error
messages are also provided too guide the user in a proper and user friendly manner. The system
has effective management of records which holds all the information of a particular citizen.
Viva Voce:
1. How to Choose the Initial Domain Object?

2. How to Connect the UI Layer to the Domain Layer?
3. Mention the Interface and Domain Layer Responsibilities.
4.What is a use case?
5.Name the three types of relationships in a use case diagram.
6.Write the two types of Implementation diagram?
7.What is an activity?
8.Write the guidelines for preparing the Documentation.
9.Define − Patterns Template
10.Every pattern must be expressed in the form
11.Define − Debugging
12. Define − Framework
13.What is a meta-model?
14. Write the differences between design patterns and frameworks

Ex. No.: 8
ONLINE COURSE REGISTRATION SYSTEM

Aim:
To analyze, design and develop code for online course registration system

1. Problem Analysis and Project Planning:
1.1. Introduction
This document is used to define terminology specific to the problem domain, explaining
terms, which may be unfamiliar to the reader of the use case description or other project
documents. Often this document can be used as an informal data directory, capturing data
definitions so that use case descriptions and other project documents can Focus on what the
system must do with the information.
1.2. Objective
The purpose of this document is to define requirements of the Course Registration

System. This Supplementary Specification lists the requirements that are not readily captured in
the use cases of the use case model. The Supplementary Specifications and the use-case model
together capture a complete set of requirements on the system.
1.3. Scope
This Supplementary Specification applies to Course Registration System, which will be

developed by the OOAD students. This Specification defines the non-functional requirements of
the system; such as reliability, usability, performance, and supportability, as well as functional
requirements that are common across a number of use cases.
1.4.Problem Statement:
As the Head of computer science & Engineering for Dhanalakshmi College of

Engineering you are tasked with developing a new student‟s registration system. The college
would like a new client-server system to replace its much older system. The new system will
allow students to register for courses and view report cards from personal computers attached to
the campus LAN. Professors will be able to access the system. To sign up to teach courses as
well as record grades. At the beginning of each semester, students may request a course
catalogue containing list course offerings for the semester. Information about each course, such
as professor, department and prerequisites, will be included to help students make information
decisions.
The new system will allow students to select four course offerings for the coming
semester. Course offerings will have a maximum of ten students and minimum of three students.
A course offering with fewer than 3 students will be cancelled. If a course is cancelled, the
students will be intimated and they will be requested to change their course choices. At the end
of the semester, the students will be able to access the system to view an electronic report card.
Since student grades are sensitive information, the system must employ extra security measures
to prevent unauthorized access. Professors must able to access the online system to indicate
which courses will be teaching. They will need to see which students signed up for their course
offerings. In addition, the professors will be able to record the Grades for the students in each
class.
2. Problem Statement (Use case Analysis)

2.1 Identified Use cases:
2.1.1. Course: A class offered by the university
2.1.2. Course Offering: A specific delivery of the course for a specific semester you could run
the same course in parallel sessions in the semester. Includes the days of the week and times it
offered.
2.1.3.Course Catalog: The unabridged catalog of all courses offered by the university.
2,1.4. Faculty: All the professors teaching at the university
2.1.5. Finance System: The system used for processing billing information.
2.1.6. Grade: The evaluation of a particular student for a particular course offering.
2.1.7. Professor: A person teaching class at the university.
2.1.8. Report Card: All The Grades For All Courses Taken By A Student In A Given Semester.
2.1.9. Roster: All the students enrolled in a particular course offering.
2.1.10 Student: A person enrolled in a class at the university.
2.2 Identified Actors:
2.2.1. Student:
2.2.2. Database: This actor stores all the information about the student.
2.2.3. Admin: Selection of course is done by student and the information stored in database are
administrated by the admin.
3. Design Of Online Course Registration:

3.1 Login:
3.1.1.Brief Description: The use case describes how a user logs into the Course Registration
System.
3.1.3.1. Basic Flow: This use case starts when the user wishes to Login to the Course
Registration System
1. The System requests that the user enter his/her name and
password
2. The user enters his/her name and password
3. The System validates the entered name and password and
logs the user into the System
3.1.3.2. Alternative Flow:
Invalid name/password. If, in the Basic flow, the user enters an invalid name and/or
password, the system displays an error message. The user chooses to either return to the
beginning of the Basic flow or cancel the login, at which point the use case ends.
3.1.3. Pre-Condition: None
3.1.4. Post-Condition: If the use case was successful, the user is now logged into the system. If
not, the System State is unchanged.
3.2. Maintain Professor Information:
3.2.1. Brief Description: This use case allows the Registrar to maintain professor information
in the registration system. This includes adding, modifying and deleting professors from the
system.
3.2.3.1. Basic Flow: This use case starts when the Registrar wishes to add, change, and /or
delete professor information in the system.
• The system requests that the Registrar specify the function he/she would like to perform
(either Add a Professor, Update a Professor, Or Delete a Professor)
• Once the Registrar provides the requested information, one of the sub flows is
executed.
• If the Registrar selected “Add a professor “, the Add a Professor sub flow is
executed.
• If the Registrar selected “Update a professor “, the Update a Professor sub flow is
executed.
• If the Registrar selected “Delete a professor “, the Delete a Professor sub flow is
executed.
3.2.3.1.1. Add A Professor: The system requests that the Registrar enter the professor
information. This includes:
• Name
• Department
• Once the Registrar provides the requested information, the system generates and
assigns a unique id number to the professor.
2.The professor is added to this system.
3.The system provides the Registrar with the new professor id
3.2.3.1.2. Update A Professor:
1. The system requests that the Registrar enter the professor id
2. The Registrar enters the professor id. The system retrieves and displays the professor
information.
3. The Registrar makes the desired changes to the professor information. This includes
any of the information specified in the Add a Professor sub-flow
4. Once the Registrar updates the necessary information, the system updates the
professor record.
3.2.3.1.3. Delete A Professor:
1. The system requires that the Registrar enter the professor.
2. The Registrar enters the professor id. The system retrieves and displays the professor
information.
3. The system prompts the Registrar to confirm the deletion of the professor.
4. The Registrar verifies the deletion.
5. The system deletes the professor from the system.
3.2.3.3. Alternative Flow:
3.2.3.3.1. Professor Not Found:
If, in the Update a Professor or Delete Professor sub-flows, a professor with the specified
id number does not exist, the system displays an error message. The Registrar can then enter a
different id number or cancel the operation, at which point the use case ends.
3.2.3.3.2 Delete Cancelled:
If, in the Delete A Professor sub-flow, the Registrar decides not to delete the professor,
the delete is cancelled, and the Basic Flow is re-started at the beginning.
The Registrar must be logged onto the system before this use case begins.
3.2.3. Post-Condition:
If the use case was successful, the professor information is added, updated, or deleted
from the system. Otherwise, the system state is unchanged.
3.3. Maintain Student Information:

3.3.1 Brief Description:
This use case allows the Registrar to maintain student information in the registration
system. This includes adding, modifying and deleting students from the system.
3.3.3.1 Basic Flow:
This use case starts when the Registrar wishes to add, change, and /or delete student
information in the system.
1. The system requests that the Registrar specify the function he/she would like to perform
(either Add a Student, Update a Student, Or Delete a Student)
2. Once the Registrar provides the requested information, one of the sub flows is executed.
3. If the Registrar selected “Add a student “, the Add a Student sub flow is executed.
4. If the Registrar selected “Update a student “, the Update a Student sub flow is executed.
5. If the Registrar selected “Delete a student “, the Delete a Student sub flow is executed.
The system requests that the Registrar enter the student information. This includes:
• name
• Department
1. Once the Registrar provides the requested information, the system generates and assigns a
unique id number to the student. The student is added to the system.
2. The system provides the Registrar with the new student id
3.3.3.1.2 Update A Student:
1. The system requests that the Registrar enter the student id
2. The Registrar enters the student id. The system retrieves and displays
3.3.3.1.3 Delete A Student:
1. The system requires that the Registrar enter the student id
2. The Registrar enters the student id. The system retrieves and displays the student information
3. The system prompts the Registrar to confirm the deletion of the student.
4. The Registrar verifies the deletion.
5. The system deletes the student from the system.
3.3.3.2. Alternative Flows:
3.3.3.3.1. Student Not Found:
If, in the Update a Student or Delete a Student sub-flows, a student with the specified
id number does not exist, the system displays an error message. The Registrar can then enter a
different id number or cancel the operation, at which point the use case ends.
3.3.3.3.2 Delete Cancelled:
If, in the Delete A Student sub-flow, the Registrar decides not to delete the student,
the delete is cancelled, and the Basic Flow is re-started at the beginning.
3.3.3. Pre-Condition:
The Registrar must be logged onto the system before this use case begins.
3.3.4. Post-Condition:
If the use case was successful, the student information is added, updated, or deleted from
the system. Otherwise, the system state is unchanged.
3.4. Register for Course:
This use case allows a student to register for course offering in the current semester. The
Student can also update or delete course selection if changes are made within the add/drop period
at the beginning of the semester. The Course Catalog System provides a list of all the Course
offerings for the current semester.
3.4.2 Flow Of Events:
3.4.3.1 Basic Flow:
This use case starts when a Students wishes to register for course offerings, or to
change his/her existing course list.
1. The system requests that the students specify the function he/she would like to perform (either
add a Course, Modify the Course list). Once the Students provide the requested information, one
of the sub flows is executed.
2. If the Student Selected “Add a Course”. The Add a Course sub flow is executed.
3. If the Student Selected “Modify the Course List”. The Modify the Course List sub flow is
executed.
3.4.3.1.1 Adding A Course:
1. The system retrieves a list of available course offering from the Course Catalog System and
displays the list to the Student.
2. The Student selects 4 primary course offering and 2 alternate course offerings from the list of
available offerings.
3. Once the student has made his/her selections, the system creates a list for the Student
containing the selected course offerings.
4. The submit Form sub flow is executed
3.4.3.1.2 Modify the Course List:
1. The system retrieves and displays the student‟s current Course list( e.g. , the course list for the
current semester)
2. The system retrieves a list of available course offering from the Course Catalog System
and displays the list to the student.
3. The Student may update the course selection on the current selection by deleting and adding
new course offerings. The students select the course offerings to add from the list of available
course offering. The students also selects any course offerings to delete from the existing
schedule
4. Once the student has made his/her selection , the system modify the schedule for the students
using the selected course offerings
5. The Submit list sub flow is executed
3.4.3.1.3 Submit List:
For each selected course offering on the list not already marked as “enrolled I „ the
system verifies that the Student has the necessary prerequisites, that the course offering is open,
and that there are no schedule conflicts. The system then adds the student to the selected course
offering. The course offering the schedule is saved in the system.
3.4.3.2 Alternative Flow:
3.4.3.3.1 No Schedule Found:
If, in the Modify the Course list sub flow, the system is unable to retrieve the student‟s
schedule, an error message is displayed. The Students acknowledges the error, and the Basic
Flow is restated at the beginning.
3.4.3.3.2 Course Catalog System Unavailable:
If the system is unable to communicate with the Course Catalogue System, the system
will display an error message to the student. The Student acknowledges the error message, and
the case terminates.
3.4.3.3.3 Course Registration Closed:
When the use case starts, if it is determined that registration for the current semester
has been closed, a message is displayed to the Student, and the use case terminates. Students
cannot register for course offerings after registration for the current semester has been closed.
3.4.3 Pre-Condition: The Student must be logged onto the system before this use case begins.
3.5. Select Course To Teach:

This use case allows selecting the course offerings from the course catalogue for the
courses that he/she is eligible for and wishes to teach in the upcoming semester.
3.5.3.1 Basic Flow: This use case starts when a professor wishes to sign up to teach some
course offerings for the upcoming semester.
1. The system retrieves and displays the list of course offerings to the professor.
2. The system also retrieves and displays the list of courses the professor has previously
selected to teach.
3. The professor selects and/or deselects the course offerings that he/she
wishes to teach for the upcoming semester.
3.5.3.2.1 No Course Offering Available:
If in the basic flow, the professor is not eligible to teach any course offerings in the
upcoming semester, the system will display an error message. The professor acknowledges the
message and the use case ends.
3.5.3.2.2 Course Catalog System Unavailable:
If the system is unable to communicate with the Course Catalog System, the system
will display an error message to the student. The student acknowledges the error message and the
use case terminates.
3.5.3. Pre-Condition: The professor must be logged on to the system before this use case
begins.
3.5.4. Post-Condition: If the use case was successful, the course offerings a professor is
scheduled to teach should have been updated.
3.6.Submit Grades:
3.6.1 Brief Description: This use case allows a professor to submit student grades for one or
more classes completed in the previous semester.
3.6.3.1 Basic Flow: This Use Case Starts When A Professor Wishes To Submit Grades For
One Or More Classes Completed In The Previous Semester.
1. The System Displays A List Of Course Offerings The Professor Taught In The Previous
Semester.
2. The Professor Selects A Course Offering
3. The System Retrieves A List Of All The Students Who Were Registered The Course Offering.
The System Displays Each Student And Any Grade That Was Previously Assigned For The
Offering.
4. For Each Student On The List, The Professor Enters The Grade: A, B, C, D, F, I. The System
Records The Student‟s Grade For The Course Offering. If The Professor Wishes To Skip A
Particular Student, The Grade Information Can Be Left Blank And Filled In At Later Time. The
Professor May Also Change Grades For A Student By Entering A New Grade.
3.6.3.2.1 No Course Offering Thought: If in the basic flow, the professor did not teach, any
course offerings in the previous semester, the system will display an error message. The
professor acknowledges the use case and the use case ends.
3.6.3 Pre-Condition: The professor must be logged on to the system before this use case begins
3.6.4. Post Condition: If the use case was successful, student grades for a course offering are
updated. Otherwise the system remains unchanged.
3.7. View Report Card:

3.7.Brief Description: This use case allows a student to view his/her report card for the
previously completed semester.
3.7.2.1. Basic Flow: This use case starts when a student wishes to view his/her
report card for the previous semester.
1. The system retrieves and displays the grade information for each of the course
offerings the student completed during the previous semester.
2. When the student indicates that he/she is done viewing the grades the use case
terminates.
3.7.3. Alternative Flow:
3.7.3.3.1. No Grade Information Available:
If in the basic flow, the system cannot find the any grade information from the previous
semester for the student, a message is displayed. Once the student acknowledges the message,
the use case terminates.
3.7.3. Pre-Condition: The student must be logged on to the system before this use case begins
3.7.4. Post-Condition: The system state is unchanged by this use case.
Result:
This project was carried out in a sequential manner to design & implement the “online
course registration system”. Thus, the outcome of the project is efficient. The course registration
system caters the varied requirements of the user to perform various options.
Viva Voce:
1. What are the elements not suitable in a domain model?

2. Define − External event
3. Define −Internal event
4.What is a use case?
5.Name the three types of relationships in a use case diagram.
6.Write the two types of Implementation diagram?
7.What is an activity?
8.Write the guidelines for preparing the Documentation.
9.Define − Patterns Template
10.Define − Debugging
11. Define − Framework
12.What is a meta-model?
13.Write the differences between design patterns and frameworks
14.What is a quality?
15.Define − Test Plan
16.What is cyclomatic complexity?
17.Define − Corollary
18.Define − Cohesion
19.What is a Façade?
20. What is database model?

DCE CS6511 Lab Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DCE CS6511 Lab Manual

Uploaded by

Copyright:

Available Formats

Dhanalakshmi College Of Engineering

Manimangalam, Tambaram, Chennai –601 301

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CS6511 – CASE TOOLS LABORATORY

Reg. No. : ______________________________________

Dhanalakshmi College of Engineering is committed to provide highly disciplined, conscientious and

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

On completion of the B.E. (CSE) degree, the graduates will be able

c) To design and develop innovative and creative software applications

j) To engage in lifelong learning and exhibit their technical skills

k) To develop and manage projects in multidisciplinary environment

To learn the basics of OO analysis and design skills

To be exposed to the UML design diagrams

To learn to map design to code

To be familiar with the various testing techniques

1. To develop a mini-project by following the 9 exercises listed below.

2. To develop a problem statement.

3. Identify Use Cases and develop the Use Case model.

UML Sequence diagrams.

1. Draw relevant state charts and activity diagrams.

3. Develop and test the Technical services layer.

4. Develop and test the Domain objects layer.

5. Develop and test the User interface layer.

SUGGESTED DOMAINS FOR MINI-PROJECT

1. Passport automation system

 Develop an IEEE standard SRS document

 Design and implement projects using OO concepts

 Compare and contrast various testing techniques

Sl. No. Name of the Experiment Page No.

7 Credit Card Processing System 38

8 Online Course Registration System 41

General study of UML

The Unified Modeling Language is a language for specifying, constructing, visualizing,

Use Case Diagram:

• Providing a high-level view of what the system does

Use case diagrams are helpful in three areas.

Messages, modeled as horizontal arrows between Activations, indicate the

When an Activity State is completed, processing moves to another Activity State.

Activities often can be done in parallel. To split processing ("fork"), or to resume

Component diagrams fall under the category of an implementation diagram, a kind of

A component represents a software entity in a system. Examples include source code

6. Packages and Object Diagrams:

8. State Chart Diagrams:

9. Component and deployment Diagrams:

A component is a code module. Component diagrams are physical analogs of class

Logical Architecture and UML Package Diagrams:

The design of a typical OO system is based on several architectural layers, such as a UI

Designing with Layers:

A detailed Study of UML has been completed.

1. Define - Object Oriented Analysis

To develop a project for online passport automation system using ArgoUML

System Requirement Specification (SRS):

1.4. Problem Statement

2. Problem Statement (Use case) Analysis:

2.2. Identified Actors:

3. Design of Passport Automation System:

3.2. Status Enquiry:

3.3. Generate Unique Id:

4. Sample UML Diagrams:

4.8. Deployment Diagram:

1. Define − Use case

System Requirement Specification (SRS):

1. Problems Analysis and Project Planning: