STUDY ON RATIONAL ROSE AND UML DIAGRAM

AIM To prepare a study on Rational Rose and UML (Unified Modeling Language) Diagram. Introduction CASE tools known as Computer-aided software engineering tools is a kind of component-based development which allows its users to rapidly develop information systems. The main goal of case technology is the automation of the entire information systems development life cycle process using a set of integrated software tools, such as modeling, methodology and automatic code generation. Component based manufacturing has several advantages over custom development. The main advantages are the availability of high quality, defect free products at low cost and at a faster time. The prefabricated components are customized as per the requirements of the customers. The components used are pre-built, readytested and add value and differentiation by rapid customization to the targeted customers. However the products we get from case tools are only a skeleton of the final product required and a lot of programming must be done by hand to get a fully finished, good product. Characteristics of CASE: Some of the characteristics of case tools that make it better than customized development are; It is a graphic oriented tool. It supports decomposition of process. Some typical CASE tools are: Unified Modeling Language Data modeling tools, and Source code generation tools STUDY ON UML DIAGRAM The UML is a language for specifying, constructing, visualizing, and documenting the software system and its components. The UML is a graphical language with sets of rules and semantics. The rules and semantics of a model are expressed in English in a form known as OCL (Object Constraint Language). OCL uses simple logic for specifying the properties of a system. The UML is not intended to be a visual programming language. However it has a much closer mapping to object-oriented programming languages, so that the best of both can be obtained. The UML is much simpler than other methods preceding it. UML is appropriate for

modeling systems, ranging from enterprise information system to distributed web based application and even to real time embedded system. It is a very expensive language addressing all views needed to develop and then to display system even though understand to use. Learning to apply UML effectively starts forming a conceptual mode of languages which requires learning. Three major language elements: UML basic building blocks Rules that dictate how this building blocks put together Some common mechanism that apply throughout the language The primary goals in the design of UML are: 1. Provides users ready to use, expressive visual modeling language as well so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanisms to extend the core concepts. 3. Be independent of particular programming languages and development processes. 4. Provide formal basis for understanding the modeling language. 5. Encourage the growth of the OO tools market. 6. Support higher-level development concepts. 7. Integrate best practices and methodologies. Every complex system is best approached through a small set of nearly independent views of a model. Every model can be expressed at different levels of fidelity. The best models are connected to reality. The UML defines nine graphical diagrams: 1. Class diagram 2. Use-case diagram 3. Behavior diagram 3.1. Interaction diagram 3.1.1. sequence diagram 3.1.2. collaboration diagram 3.2. state chart diagram 3.3. activity diagram 4. Implementation diagram 4.1 4.2 Use Case Diagram component diagram deployment diagram

The behavior of the system under development (i.e. what functionality must be provided by the system) is documented in a use case model that illustrates the system's intended functions (use cases), its surroundings (actors), and relationships between the use cases and actors (use case diagrams). Actors Person who interact with the system. Are not part of the system they represent anyone or anything that must interact with the system. Only input information to the system. Only receive information from the system. Both input to and receive information from the system. Represented in UML as a stickman. Use Case A sequence of transactions performed by a system that yields a measurable result of values for a particular actor

A use case typically represents a major piece of functionality that is complete from beginning to end. A use case must deliver something of value to an actor.

Professor

Use Case Relationships Between actor and use case. Association / Communication. Arrow can be in either or both directions;arrow indicates who initiates communication. Between use cases (generalization): Uses

Where multiple use cases share pieces of same functionality. Extends Optional behavior. Behavior only runs under certain conditions (such as alarm). Several different flows run based on the users selection

Documenting Flow of events Background Each use case is documented with a flow of events. The flow of events for a use case is a description of the events needed to accomplish the required behavior of the use case. Activity diagrams may also be created at this stage in the life cycle. These diagrams represent the dynamics of the system. They are flow charts that are used to show the workflow of a system; that is, they show the flow of control from one activity to another in the system, Flow of Events A description of events required to accomplish the behavior of the use case, that: Show WHAT the system should do, not HOW the system does it. Written in the language of the domain, not in terms of implementation. Written from an actors point of view. A flow of events document is created for each use case: Actors are examined to determine how they interact with the system. Break down into the most atomic actions possible.

Contents of Flow of Events When and how the use case starts and ends. What interaction the use case has with the actors. What data is needed by the use case. The normal sequence of events for the use case. The description of any alternate or exceptional flows.

Template for the flow of events document Each project should use a standard template for the creation of the flow of events document. The following template seems to be useful.

X Flow of events for the <name> use case X.1 Preconditions X.2 Main flow X.3 Sub-flows (if applicable) X.4 Alternative flows where X is a number from 1 to the number of use cases. Activity Diagram Activity Diagram represents the performance of operations and the transitions are triggered by the completion of an operation. Activity diagrams are flow charts that are used to show the workflow of a system. They also: Represent the dynamics of the system. Show the flow of control from activity to activity in the system. Show what activities can be done in parallel, and any alternate paths through the flow.

Activity diagrams may be created to represent the flow across use cases or they may be created to represent the flow within a particular use case. Later in the life cycle, activity diagrams may be created to show the workflow for an operation. Activity Diagram Notation Activities- performance of some behavior in the workflow. Transition- passing the flow of control from activity to activity. Decision- show where the flow of control branches based on a decision point: o Guard condition is used to determine which path from the decision point is taken. Synchronization-what activities are done concurrently? What activities must be completed before processing may continue (join). Activity Diagram Symbols Start State: End State: State Transition: Decision:

Synchronization bar:

Class Diagram Background Classes: a description of a group of objects with common properties (attributes) common behavior (operations), common relationships to other objects and common semantics. Object-Oriented Concepts Attribute: the basic data of the class. Method (operation): an executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class. Object: when specific values are assigned to all the resources defined in a class, the result is an instance of that class. Any instance of any class is called an object.

Specifying Classes Each class is given a name, and then you need to specify: Attributes: initially those that capture interesting object states. Attributes can be public, protected, private or friendly/package. Operations: can be delayed till later analysis stages or even till design. Operations also can be public, protected, private or friendly/package. Object-Relationships: o Associations: denote relationships between classes. o An aggregation: a special case of association denoting a consists of hierarchy. o Composition: a strong form of aggregation where components cannot exist without the aggregate. o Generalization relationships: denote inheritance between classes. This will build the class diagram, which is a graphical representation of the classes (including their attributes and operations) and their relationship with other classes. Graphical Diagram: A class icon is drawn as a 3-part box, with class name in the top part, a list of attributes (with optional values) in the middle part, and a list of operations in the bottom part. Class Name Attribute Methods

Classes Categories Classes are divided into three categories: Entity: models information and associated behavior that is long-lived, independent of the surrounding, application independent, and accomplishes some responsibility Boundary: handles the communication between the system surroundings and the inside of the system, provides interface, and facilitates communication with other systems Control: model sequencing behavior specific to one or more use cases. Control classes coordinate the events needed to realize the behavior specified in the use case, and they are responsible for the flow of events in the use case.

Discovering Classes Approaches Methods of discovering classes: Noun Phrase Approach: Examine the requirements and underline each noun. Each noun is a candidate class; divide the list of candidate classes into: Relevant classes: part of the application domain; occur frequently in requirements. Irrelevant classes: outside of application domain Fuzzy classes: unable to be declared relevant with confidence; require additional analysis

Common Class Patterns: Derives candidate classes from the classification theory of objects; candidate classes and objects come from one of the following sources: Tangible things: e.g. buildings, cars. Roles: e.g. teachers, students. Events: things that happen at a given date and time, or as steps in an ordered sequence: e.g. landing, request, interrupt. Interactions: e.g. meeting, discussion. Sources, facilities: e.g. departments. Other systems: external systems with which the application interacts. Concept class: a notion shared by a large community. Organization class: a collection or group within the domain. People class: roles people can play. Places class: a physical location relevant to the system.

Use Case Driven Method: The scenarios - use cases that are fundamental to the system operation are enumerated. Going over each scenario leads to the identification of the objects, the responsibilities of each object, and how these objects collaborate with other objects. CRC (Class-Responsibility-Collaboration): Used primarily as a brainstorming tool for analysis and design. CRC identifies classes by analyzing how objects collaborate to perform business functions (use cases). A CRC card contains: name of the class, responsibilities of the class and collaborators of the class. Record name of class at the top; record responsibilities down the left-hand side; record other classes (collaborators) that may be required to fulfill each responsibility on the right-hand side. CRC cards are effective at analyzing scenarios; they force you to be concise and clear; they are cheap, portable and readily available. Mixed Approach: A mix of these approaches can be used, one possible scenario is: Use CRC for brainstorming. Identify the initial classes by domain knowledge. Use common class patterns approach to guide the identification of the classes. Use noun phrase approach to add more classes. Use the use case approach to verify the identified classes.

Class Elicitation Guidelines A class should have a single major role. A class should have defined responsibilities (use CRC cards if needed). Classes should be of a manageable size: if a class has too many attributes or operations, consider splitting it. A class should have a well-defined behavior, preferably by implementing a given requirement or an interface.

Interaction diagrams: o Sequence diagrams o Collaboration diagrams

Background Interaction diagrams describe how groups of objects collaborate in some behavior. An interaction diagram typically captures the behavior of a single use case. Interaction diagrams do not capture the complete behavior, only typical scenarios. Analyzing a Systems Behavior UML offers two diagrams to model the dynamics of the system: sequence and collaboration diagrams. These diagrams show the interactions between objects. Sequence Diagrams Sequence diagrams are a graphical way to illustrate a scenario: They are called sequence diagrams because they show the sequence of message passing between objects. Another big advantage of these diagrams is that they show when the objects are created and when they are destructed. They also show whether messages are synchronous or asynchronous A sequence diagram has two dimensions: Horizontal Dimensions: It represents different objects. Vertical Dimensions: It represents the time. Creating Sequence Diagrams You must know the scenario you want to model before diagramming sequence diagrams. After that specify the classes involved in that scenario. List the involved objects in the scenario horizontally on the top of the page. Drop a dotted line beneath every object. They are called lifelines. The scenario should start by a message pass from the first object. You must know how to place the objects so that the sequence is clear. You may start the scenario by an actor. Timing is represented vertically downward. Arrows between life lines represents message passing. Horizontal arrows may pass through the lifeline of another object, but must stop at some other object. You may add constraints to these horizontal arrows. Objects may send messages to themselves. Long, narrow rectangles can be placed over the lifeline of objects to show when the object is active. These rectangles are called activation lines.

Collaboration Diagrams They are the same as sequence diagrams but without a time axis: Notes Always keep your diagrams simple. For IF... then ... else scenarios, you may draw separate sequence diagrams for the different branches of the if statement. You may even hide them, (at least during the analysis phase) and document them by the text description accompanying the sequence diagrams. Their message arrows are numbered to show the sequence of message sending. They are less complex and less descriptive than sequence diagrams. These diagrams are very useful during design because you can figure out how objects communicate with each other.

Toggling between the sequence and collaboration diagrams When we work in either a sequence or collaboration diagram, it is possible to view the corresponding diagram by pressing F5 key. State Diagrams State diagrams show how one specific object changes state as it receives and processes messages: Since they are very specific, they are used for analyzing very specific situations if we compare them with other diagrams. A state refers to the set of values that describe an object at a specific moment in time. As messages are received, the operations associated with the objects parent class are invoked to deal with the messages. These messages change the values of these attributes. There is no need to prepare a state diagram for every class you have in the system. Creating State Transition Diagrams States are represented by rectangles with rounded corners with an attribute name with a values associated with it. The name of the state is placed within the box.

Events are shown by arrows. An event occurs when at an instant in time when a value is changed. A message is data passed from one object to another. The name of a state usually refers to the name of the attribute and the values associated to it. Example, a student object may receive a message to change its name. The state of that object changes from the first name state to the new state name. The name of the state is placed in the top compartment. State variables are placed in the next compartment. The operations associated with the state are listed in the lowest compartment of the state box. In the operations part, we usually use one of the following reserved words: o Entry: a specific action performed on the entry to the state. o Do: an ongoing action performed while in the state. o On: a specific action performed while in the state. o Exit: a specific action performed on exiting the state. There are two special states added to the state transition diagram- start state and end state. Notation of start state is a solid black circle and for the end state a bulls eye is used.

State Transition Details A state transition may have an action and/or guard condition associated with it and it may also trigger an event. An action is the behavior that occurs when the state transition occurs. An event is a message that is sent to another object in the system. A guard condition is a Boolean expression of attribute values that allows a state transition only if the condition is true. Both actions and guards are behaviors of the object and typically become operations. Also they are usually private operations (used by the object itself) Actions that accompany all state transitions into a state may be placed as an entry action within the state. Actions that accompany all state transitions out of a state may be placed as exit actions within the state A behavior that occurs within the state is called an activity. An activity starts when the state is entered and either completes or is interrupted by an outgoing state transition.

A behavior may be an action, or it may be an event sent to another object. This behavior is mapped to operations on the object.

State transition diagram notation:

State [entry: ] [do: ] Event causing transition [exit:] Action that occurs New State [entry:] [do: ] [exit:]

UML Implementation Diagrams The main implementation diagrams we have in UML are: component diagrams and deployment diagrams. UML Component Diagram Component diagrams capture the physical structure of the implementation. Remember always that when you talk about components, you are talking about the physical models of code. You can name them and show dependency between different components using arrows. A component diagram shows relationships between component packages and components. Each component diagram provides a physical view of the current model. Component diagrams contain icons representing: o Component packages. o Components. o Main programs. o Packages. o Subprograms.

o Tasks. o Dependencies. New component 1 New component 2

Deployment Diagram A deployment diagram shows processors, devices and connections. Each model contains a single deployment diagram which shows the connections between its processors and devices, and the allocation of its processes to processors. Deployment Diagrams: Processor A processor is a hardware component capable of executing programs. A processor is given a name and you should specify the processes that will run on that processor. You can also specify the scheduling of these processes on that processor. Types of scheduling are: o Pre-emptive: a higher priority process may take the process from lower priority one. o Non-preemptive: a process will own the processor until it finishes o Cyclic: control passes from one process to another. o Executive: an algorithm controls the scheduling of the processes o Manual: scheduling buy the user.

Deployment Diagrams: Device A device is a hardware component with no computing power. Each device must have a name. Device names can be generic, such as modem or terminal. Deployment diagrams: Connection A connection represents some type of hardware coupling between two entities. An entity is either a processor or a device. The hardware coupling can be direct, such as an RS232 cable, or indirect, such as satellite-to-ground communication. Connections are usually bi-directional.

CONCLUSION Thus the Rational Rose and Unified Modeling Language were studied.

PRACTICING THE RATIONAL ROSE CASE TOOL FOR ALL THE PHASES OF SOFTWARE DEVELOPMENT LIFE CYCLE

Problem statement: At the beginning of each semester students may request a course catalogue containing a list of course offerings for the semester. Information about each course such as professor, department and prerequisites will be included to help students make informed decisions. The new on-line registration system will allow students to select four course offerings for the coming semester. In addition each student will indicate two alternative choices in case a course offering becomes filled or canceled. No course offering will have more than ten students. No course offering will have fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system, so the student can be billed for the semester. Professors must be able to access the on-line system to indicate which courses, they will be teaching. They will also need to see which students signed up for their course offering. For each semester, there is a period of time that students can change their schedules. Students must be able to access the online system during this time to add or drop courses. The billing system will credit all students for courses dropped during this period of time. AIM To practice the rational rose case tool for all the different phases of software development life cycle 1. The Inception Phase Definition of Actors The following actors were defined for the problem: Studentsomeone who is registered to take courses at the university. Professorsomeone who is licensed to teach at the university. Registrarsomeone who is responsible for the maintenance of the registration system. Billing Systemexternal system that bills students each semester. Definition of Use Cases The following use cases were elaborated for each actor: Register for course

The use case is started by the student. It provides the capability to create, review, modify and delete a course schedule for a specified semester. All pertinent billing information is sent to the billing system. Request class roster This use case is started by the professor. It provides the capability to request a printed list of all students assigned to a specified course offering. Select courses to teach This use case is started by the professor. It provides the capability to select, review, modify and delete a list of courses to teach for a specified semester. Maintain professor information This use case is started by the registrar. It provides the capability to create, review, modify and delete professor information. Maintain student information This use case is started by the registrar. It provides the capability to create, review,modify and delete student information. Maintain curriculum This use case is started by the registrar. It provides the capability to create, review, modify and delete a list of course offerings for a given semester. Generate catalogue This use case is started by the registrar. It provides the capability to generate a catalogue containing a list of course offerings for a specified semester.

2. The Elaboration Phase During this phase, the focus is good class structure and architecture. Development of scenarios Scenarios are documented using Activity Diagram and Sequence Diagrams. Objects are represented as vertical lines and messages between objects are shown as directed horizontal lines. Creating business objects

Objects are discovered by examining the us cases and scenarios and grouped into classes. Classes and packages are drawn in the Logical View of the tool. The following packages and classes have been created for the registration system Software Architecture Packages and classes that carry out the architectural functionality are added to the logical view. In the Course Registration System, the following architectural decisions were made: Containers and GUI classes to be used are in the class library. A commercial relational database was chosen and classes to communicate with the database were created. A set of error classes were created to facilitate common error handling strategies.

Iteration Planning Use cases and scenarios are examined and prioritized to create the initial project plan. For Course Registration System the iteration plan is: Iteration 1 o Maintain curriculum. Iteration 2 o Maintain student info. o Maintain professor info. o Select courses to teach. o Generate catalogue. Iteration 3 o Register for courses. o Request class roster.

3. The Construction Phase During construction, all remaining scenarios will be specified and implemented. At this time, many of the secondary scenarios are addressed.

Building Iteration

For the Course Registration problem, the following design decisions are made: Controller classCurriculum Manager added. This class knows the business rules associated with the management of a curriculum. Scenario diagrams are updated to show new interactions with the Curriculum Manager. Data types and signatures are provided for all attributes and operations. Association navigation is designed.

4. The Transition Phase The system was successfully transitioned to the university community in two releasesbeta and the final system. During the beta period, bugs were discovered, reported and fixed. This requirement was successfully implemented and available in the final releases of the system.

Drawing Use case Diagram in Rational Rose

BillingSystem

Register for courses

Request class roster

Professor Professor()

Student Student()

Select courses to teach Generate Catalog Maintain Student Info

Maintain Professor Info

Maintain Curriculum

Registrar Registrar()

Sequence Diagram for the Add a course scenario

: Re g is trar
1: Enter Id

Cours eMainte nanc e Form

Sale s1 0 1

2: Verify

3: Create Course 4: Enter Course Info

5: Submit 6: Create 7: Save

8: Close Forum

Collaboration Diagram

Class Diagram for the People Package

CourseOffering RegistrationUser name phone address idNumber +register

3-10

ddays timeOfDay location

4

+for teacher

addstudent() addprofessor() isfull() CourseOffering()

StudentInfo major gradYear StudentInfo() ProfessorInfo tenureStatus ProfessorInfo()

RESULT The data model has been produced successfully and output ver

DATA MODELLING
AIM To create the database using Rational Rose software and that is converted to DDL script PROCEDURE To create a database: Step 1: Right-click the Component View and select Data Modeler > New > Database. Step 2: Right-click the new database and select Open Specification. Step 3: Enter a Name for the database, in the Database Specification. Step 4: Select a Target DBMS from the drop-down. Default is ANSI SQL92. Step 5: Click OK. To create a table: Step 1: Click Tools > Create > Table. The cursor appears as a plus sign. Step 2: Click where you want the table to appear on the Data Model Diagram. A list box appears floating above the table containing the names of existing tables and the default name of the new table. Step 3: Right-click on the new table and select Open Specification. Step 4: Click on the General tab of the Table Specification and enter the table name. Step 5: Click OK. To create a column: Step 1: Right-click on the table in the browser or in a data model diagram. Step 2: Select Data Modeler > New > Column. Step 3: Right-click on the column in the browser and select Open Specification. Step 4: On the General tab of the Column Specification, select the column name and rename it. Step 5: Save the table.

Step 6: Open the database (Oracle) connect to the data model Step 7: Browse the data file then click load script Step 8:.Finish

Database

Student
RegNo:SMALLINT Name:VARCHAR(1) Address:VARCHAR(1)

<<PK>> PK_Student0()

OUTPUT

RESULT The DDL script has been produced successfully from the database and output verified

SEMANTIC DATAMODELLING
AIM To create DDL script from class model through data model. PROCEDURE Step 1: Create a Package Step 2: Add classes to Package (Logical View - New - Package) to form the class model Step 3: Mark each class as Persistent Step 4: Add new class diagram to package (Logical View - New - Class Diagram) Step 5: Drag or drop classes to class diagram to show them diagramatically Step 6: Add class relationships in diagram (for associations/aggregations don't forget supplier roles) Step 7: Add a new Schema (Logical View - Data Modeler - New - Schema) Step 8: Optionally create a new database (Componenent View - Data Modeler - New -Database). Select database target (defaulted to ANSI SQL92) Step 9: Optionally associate the Schema with the database. Database Target cannot be changed when associated. Step 10: Create data model: Package - Data Modeler - Transform to Data Model, tables appear in Schema Step 11: Create new data model diagram: Schema - New - Data Modeler - New Data Model Diagram Step 12: Drag or drop tables in data model diagram Step 13: Create DDL Script: Schema - Data Modeler - Forward Engineer ... the DDL script is

created.

CLASS DIAGRAM

T_employee
empid : CHAR(1) name : CHAR(1) T_employee_ID : INTEGER T_department_ID : INTEGER T_department_T_department_ID : INTEGER T_computer_ID : INTEGER <<PK>> PK_T_employee0() <<FK>> FK_T_employee3() <<FK>> FK_T_employee2() <<FK>> FK_T_employee1() <<Index>> TC_T_employee7() <<Index>> TC_T_employee5() <<Index>> TC_T_employee3() 0..1 0..*

<<Non-Identifying>> 0..* 0..1

T_computer
id : CHAR(1) T_computer_ID : INTEGER <<PK>> PK_T_computer2()

<<Non-Identifying>>

0..1 0..*

T_department
dept : CHAR(1) T_department_ID : INTEGER T_employee_ID : INTEGER <<PK>> PK_T_department1() <<FK>> FK_T_department0() <<Index>> TC_T_department1()

OUTPUT CREATE TABLE T_Department ( depname VARCHAR ( 255 ) NOT NULL, T_Department_ID INTEGER NOT NULL, T_Employee_ID INTEGER NOT NULL, CONSTRAINT PK_T_Department2 PRIMARY KEY (T_Employee_ID, T_Department_ID) ); CREATE TABLE T_Employee ( empid VARCHAR ( 255 ) NOT NULL, empname VARCHAR ( 255 ) NOT NULL, T_Employee_ID INTEGER NOT NULL, CONSTRAINT PK_T_Employee0 PRIMARY KEY (T_Employee_ID) ); CREATE TABLE T_Computer ( compid VARCHAR ( 255 ) NOT NULL, T_Computer_ID INTEGER NOT NULL, T_Employee_ID INTEGER NOT NULL, CONSTRAINT PK_T_Computer1 PRIMARY KEY (T_Computer_ID) ); ALTER TABLE T_Department ADD CONSTRAINT FK_T_Department1 FOREIGN KEY (T_Employee_ID) REFERENCES T_Employee (T_Employee_ID) ON DELETE NO ACTION ON UPDATE NO ACTION;

ALTER TABLE T_Computer ADD CONSTRAINT FK_T_Computer0 FOREIGN KEY (T_Employee_ID) REFERENCES T_Employee (T_Employee_ID) ON DELETE NO ACTION ON UPDATE NO ACTION; RESULT The DDL script for the class diagram produced successfully and output verified.

E-MAIL CLIENT SYSTEM

Problem statement: The E-mail client system is designed to send, receive, delete and view mails. The client select compose mail, then insert the receiver address and type the message ant attach the file if necessary the click send button. The client is able to read the mail and search the mail. Then the client is able to delete the mail if necessary. Spam mail is also automatically deleted by server and client, reports the server about the spams which reduces the possibility to get the spam mail. AIM To create data models for the e-mail client system Software Specification Rational Rose Enterprise

System Requirement Operating System-Windows XP Processor-Intel Pentium

USE CASE DIAGRAM Description Use case diagram is defined as a set of sequence of action which are performed by software to yield the result for the user, then actor as a thing used to interact with this system. Identification of Use case and Actors Use case Send mail Insert Address Check valid id Attach files Search mail

 Actors

Delete mail View mail Spam Login

Client Server

Use case Description Login Brief Description This use case describes how a client register and login to the email system Flow of Events Basic Flow Request the username and password Enter the username and password Verify the username and password If the client login is valid, then enter to the email system.

Alternate Flow Before login should know the corresponding username and password. Send Mail This use case is used for send mail to the destination. Flow of Events Basic Flow The client select the compose or write mail option

Insert the address of receiver Type the message Attach files if necessary Click send button

Alternate Flow If the receiver address is not valid then the mail is not sent. Insert Address It is used to insert address of receiver for sending mail. Check valid ID It is used to check the receiver address for sent mail. If the receiver id is not valid the the mail is not sent. Attach File It is used for attaching the files. Search mail The purpose is to search the mail of the client mail system. Delete mail The system is allowed to delete the mail if necessary. View mail The purpose of this usecase is to read the mail and viewmal. Spam The purpose of this use case is how to detect the spam mail. The spam mail is also automatically detected by the server and client reports the server about the spam. CLASS DIAGRAM The UML class diagram also referred to as object modeling. It is the main static analysis diagram. It shows the static structure of the model. SEQUENCE DIAGRAM

It is the behavioral diagram the shows interaction emphasizing time ordering of the message. Description Send mail The client logged into the mail system. The system displays the available option The client select compose or write mail Then insert the receiver address Attach the files if necessary The client select send mail

Read mail The client logged into the mail system The system displays the available option The client select viewmail The mail system request to the server

Delete mail Spam The client logged into the mail system The system displays the available option The client select spam mail The client select Delete mail The mail system updates the mails and request to the server The server returns status to the system The system display acknowledgement to the client.

The mail system reports spam to the server

COLLABORATION DIAGRAM It represents collaboration which is a set of objects related in particular content and interaction which is a set of messages, exchange among the object. Procedure Auto generate the collaboration Open the preview project model and open the sequence diagram Press F5 to auto generate the collaboration diagram Arrange the diagram elements Run the report

ACTIVITY DIAGRAM Description The system request to enter client username and password The client enters the username and password The system validates the entered username and password into the system For the client the system request to insert address, type the message and attach the files For the client the system request to report spam, the client can view the spam mail The client is able to search and delete the mail

Use case Diagram

In s e r tAd d re s s Log in < < in clu d e > >

< < in c lu d e > >

Che c kMailId

S e n d Mail

< < in c lu d e > >

Client

Vie wMail

< < e xte n d s > >

Attac h File

< < e xte n d s > >

S e arc h Mail
< < e xte n d s > >

De le te Mail

S p am

Server

Class Diagram
Mail System
Name : char Login() Status() SendMail() InsertAddress() DeleteMail() SelectOption() WriteMail() ReadMail() ViewMail() SendMail() AttachFile() DisplayAcknowledgement() Request() SpamMail() ReportSpam()

Client (from mail system)

MailId : char username : char password : char searchmail() displaymail()

Server (from mail system)

checkmail() update()

Sequence Diagram

Send Mail
:Client 1: Login() 2: SelectOption() 3: WriteMail() 4: InsertAddress() 5: AttachFiles() 6: SendMail() 7: Update() 8: Status() :MailSystem :Server

9: DisplayAcknowledgement()

Delete Mail

:Client 1: Login() 2: SelectOption() 3: DeleteMail()

:MailSystem

:Server

4: Request() 5: Status() 6: DisplayAcknowledgement()

Read Mail

:Client 1: Login() 2: SelectOption() 3: ReadMail()

:Mail System

:Server

4: Request()

5: Status()

6: DisplayMail()

Read Mail

:Client 1: Login() 2: SelectOption() 3: ReadMail()

:Mail System

:Server

4: Request()

5: Status()

6: DisplayMail()

Spam Mail

:Client 1: Login() 2: SelectOption() 3: SpamMail()

:MailSystem

:Server

4: ReportSpam() 5: Status()

6: DisplayAcknowledgement()

Collaboration Diagram Send mail

1: Login() 3: WriteMail() 4: InsertAddress() 5: AttachFiles() 6: SendMail() :Client 2: SelectOption() 9: DisplayAcknowledgement() :MailSystem

7: Update() 8: status() :Server

Read mail

1: Login() 3: ReadMail() :Client 2: SelectOption() 6: DisplayMail() :MailSyste m

4: Request() 5: Status() :Server

Delete mail
1: Login() 3: DeleteMail() :Client 2: SelectOption() 6: DisplayAcknowledgement() :MailSystem

4: Request() 5: Status() :Server

Spam mail
1: Login() 3: SpamMail() :Client 2: SelectOption() 6: DisplayAcknowledgement() 5: Status() :MailSyste m

4: ReportSpam()

:Server

Activity Diagram

Login invalid valid

WriteMail

Remove Mail

ViewMail

SearchMail

SpamMail

InsertAddress DisplayMail EnterMessage EnterCriteria

otherwise

if necessary

AttachFiles NoReport ReportSpam

SendMail otherwise if necessary DeleteMail

RESULT The data model for Email client system has been produced successfully and output verified

SOURCE CODE GENERATORS

Problem statement The management of a garage wishes to monitor the sale of cars by their salesman and the maintenance of the cars. A database is designed, containing data about salesman, sales and maintenance of sold cars. Personal data, Employment date & the no. of cars sold the year to date are recorded for each salesman. The following data are recorded for sold cars. Recommended price, actual price, price of the exchange car, sale date, registration, make, type, the buyer and the salesman. The exchange price is valued zero if there was no exchange car. The garage is served by the number of workshops for maintenance jobs. The number of mechanics, apprentice mechanics, floor space and data on available technical equipment is recorded. The following data are recorded for sold cars., requiring maintenance at a given workshop, date mileage and repairs carried out. Each repair is identified by a description, average repair type and average type. The cost of certain quantities of materials required for repairs are recorded in database. AIM To develop and generate source code for Garage System in Java. PROCEDURE List of Entities Salesman, car, garage, workshop, maintenance, repair type, repair. Types of Definitions Type Salesman: name, town, ID, address, emp_date, sold_no. Type Car: make, type, recommended_ price, actual_price, exchange_price, sales_date, owner, salesman Type Workshop: mechanic_no, apprentice_no, floor_space, technical_equipment. Type Maintenance: car, workshop, date, mileage. Type Repair type: description, avg_price, avg_time. Type Material: description, price. Type Usage: repair, material.

 Type Repair: maintenance, repair_type, actual_time.

Source Code Generation Step 1: Open Rational Rose. Add new class diagram as In the Logical view-New-Class Diagram Step 2: Select My Computer-Properties.In the Advanced tab select Environment Variables-New. Set the variable name as Classpath and variable value as C:\jdk1.3.1\lib\tools.jar Step 3: In Rational rose select Tools-Options-Notations-Set default language as Java Step 4: In the Edit menu click Select All.In Tools menu select Java/J2EE-Generate Code Step 5: Assign class path entries-Edit-Project Specification-Select the path. In the class path window select the directory as C:\jdk1.3.1 and select all in packages. Step 6: Code will be generated successfully in the specified location

Class Diagram

u s ag e re pa ir_id m a te ria l us a g e ()

re p air m a inta in_id a c tua ltim e rr_id re pa ir()

m ate rial pric e m a te ria l_id de s cription m a te ria l()

m ain te n an c e m a inta in_id c a r_id w_id m a inte na nc e ()

re p air_type r_id de sc ription a vg_pric e a vg_tim e re pa ir_type ()

c ar m ode l_id ca r_id sa le s m a n_id pric e ca r() works h op w_id te c hnic a l_e quip works hop()

S ale s m an sa le s m a n_id na m e a ddr sold_no sa le s m a n()

CODE Maintenance //Source file: C:\\jdk1.3.1\\lib\\Maintanence.java public class Maintanence extends Repair { private int maintain_id; private int car_id; private int w_id; /** @roseuid 4F23CE9801B5 */ public Maintanence() {} /** @roseuid 4F23C696034B */ public void maintanence() { }} Repair //Source file: C:\\jdk1.3.1\\lib\\Repair.java public class Repair extends Usage { private int maintain_id; private int actualtime; private int rr_id;

/** @roseuid 4F23CE9501C5 */ public Repair() {} /** @roseuid 4F23C607032C */ public void repair() { }} Salesman //Source file: C:\\jdk1.3.1\\lib\\Salesman.java public class Salesman { private int salesman_id; private int name; private int addr; private int soldno; /** @roseuid 4F23CE9B000F */ public Salesman() {} /** @roseuid 4F23C76D0167

*/ public void salesman() { }} Workshop //Source file: C:\\jdk1.3.1\\lib\\Workshop.java public class Workshop extends Maintanence { private int w_id; private int technical_equp; /** @roseuid 4F23CE9A0290 */ public Workshop() { } /** @roseuid 4F23C72E0138 */ public void workshop() {} } Material //Source file: C:\\jdk1.3.1\\lib\\Material.java public class Material extends Usage { private int price;

private int material_id; private int description; /** @roseuid 4F23CE970138 */ public Material() {} /** @roseuid 4F23C62B033C */ public void material() { } } Repair_type //Source file: C:\\jdk1.3.1\\lib\\Repair_type.java public class Repair_type extends Repair { private int r_id; private int description; private int avg_price; private int avg_time; /** @roseuid 4F23CE990138 */ public Repair_type()

{ } /** @roseuid 4F23C6BF0167 public void repair_type() { } } Usage //Source file: C:\\jdk1.3.1\\lib\\Usage.java public class Usage { private int repair_id; private int material; /** @roseuid 4F23CE89037A */ public Usage() { } /** @roseuid 4F23C5E10203 */public void usage() { } RESULT The source code generated successfully and output verified */

LIBRARY MANAGEMENT
Problem statement: The system is designed to search the book and issue the book with an ease. The return and renewal dates are also maintained in the system. The customer logs into the library system using username and password. Then the customer search the wanted book,& request that the librarian for the books. That book is issued by the librarian. If the customer is not able to find the particular book the he/she search for some other book or leaves the library. The return and renewal dates are maintained by the system. If the book is not returned on the particular date, fine will be assigned customer for the corresponding book. All book details (Book name, author name, version, number of copies, rack no.) maintained by the system AIM To generate data models for the library management system. Software specification Rational Rose

System specification * Operatingsystem- Windows XP * Processor -Intel Pentium USE CASE DIAGRAM The use case diagram is the behavioral diagram that shows the set of use case from their actors and their relationships. The use cases are shown as ellipse contains the name of the usecase.The name of the use case can be placed below or inside the ellipse. The use case diagram is a graph of actors, set of use cases enclosed by a system boundary communication association between actors and use cases and the generalization among the use cases.

Identification of use case and actors Use cases *login *Find book *Issue *Return *Renewal *Maintenance *Maintenance details Actors *Customer *Librarian

Use case Description Login Brief Description This use case describes how the customer registers to the library system. Flow of Events Basic Flow *Request the username & password *Enter the username & password *Verify username & password Alternate Flow Before login should know the corresponding username & password

Find Book Brief Description The purpose of this use case is used to find the book for customer. When the customer searching the book until available books are found. Issue Brief Description The purpose of this use case is to issue the book to the customer Flow of Events Basic flow *Customer selects the book and request to the issue *Then the book is issued Alternate Flow *If the customer not fined the available book then searching process is going on otherwise completed. Return The purpose of use case is used for return the book. The customer must returned book before the corresponding book return date. If the book is not return on the particular date fine will be assigned customer for the corresponding book.

Renewal The purpose of this use case for renewal of books. The customer must renewal the book before corresponding book renewal date. If the book is not renewal on the particular date fine will be assigned to the customer for the corresponding book. Maintenance Detail The purpose of this use case is used for maintain book detail (book name, book no, author, author name, version, number of copies, rack no).The system also maintains the return & renewal book details & customer details.

CLASS DIAGRAM The UML class diagram also referred to as object modeling is the main static analysis diagram. This diagram shows the static structure of the model. A class diagram is a collection of static modeling elements such as class and their relationships connected as graph to each other and to their contents. SEQUENCE DIAGRAM It is the behavioral diagram that shown on interaction, emphasizing the time ordering of the message. Description *The customer login to the system. * The customer find the book and system return the status. *The customer request to return /renewal the book to the status. *The customer requests to issue the book. *Return status to the customer. COLLABORATION DIAGRAM Represents a collaboration which is a set of objects related in particular content and interaction, whicha set of messages is exchanged among the objects with in the collaboration to achieve a desired outcome. Procedure *Auto generates the collaboration *Open the previous project model and open the sequence diagram. *Press F5 to auto generates the collaboration diagram. *Arrange the diagram elements. * Run the report.

ACTIVITY DIAGRAM It is a variation or special case of a state machine; in which the states are activities, representing the performance of operations and the transactions are triggered by the completion of operations.

Description *Login into the system * The customer searches the book. * If the book is available then the book is issued. * If the book is not available then the customer searches another book. * The customer wants to return/renewal process. *Check the data. * IF the data is correct then the book is return/renewal. * If the book is expire the correct date, then fine will be assigned to customer. * Update the database

Use case Diagram

Login

Find Book
<<extends>>

Customer

Issue

Librarian

Return

Renewal

Maintenance

Class Diagram

Library location : char totalBooks : Numbe r type : char No OfCopies : Number RackNum : Number Library() FindBook() Maintenance() Update() Ava ilabilityStatus()

Custom e rClass name : char address : char contactNo : Number id : number issue() status() CustomerClass()

Libraarian Bookname : char Bookno : Number AuthorName : Char Edition : Number Add() Request() Return() Renewal() Libraarian()

Sequence Diagram

CustomerClass

Libraarian

Library

1: FindBook() 2: Availability Status() 3: Request()

4: Issue()

5: Renewal() 6: Update()

7: Status() 8: Return() 9: Maintenance

10: Status()

Collaboration Diagram

Activity Diagram

NewSw...

Login

Invalid

Valid

FindBook

Re ne wal

Re turn

Alternate Book Not available

Issue

Re ne walBook

AssignFine

Re turnBook

Updated Status

RESULT The data model for Library management system has been produced successfully and output verified

REVERSE ENGINEERING
AIM To reverse process from code to class model using Reverse Engineering Model. PROCEDURE Step 1: In Component view add new component package. Add new component: Component View-select Package-New Component. Step 2: Optionally add a new component diagram. Component View- Package- New- Component Diagram. Drag or drop components in Component Diagram. Step 3: Select Component- Open Specification-General tab- Set Language (ANSI C++) Step 4: Select Component- ANSI C++-Open ANSI C++ specification-General tab-Select Root directory-Press Add Files-click Ellipe- select All Files-Open. Step 5: Select Component-ANSI C++-Reverse Engineer-OK. Step 6: Logical view- New package C++ Reverse Engineer appears-Open to view classes. Step 7: Add new Class Diagram. Select Package-New-Class Diagram. Step 8: Drag or drop all classes to class diagram.

PROGRAM #include<iostream.h> #include<conio.h> Class Person { protected: char pname[30]; int age; public: void getdata() { cout<<Enter the name:<<endl; cin>>pname; cout<<Enter the age:<<endl; cin>>age; }}; class Student:public virtual Person { protected: int regno; public: void getdata1() { cout<<Enter the register number:<<endl; cin>>regno;

}}; Class Sports:public virtial Person { protected: char sname[30]; public: void getdata2() { cout<<Enter the sports name:; cin>>sname; }}; class Exam:public Student { protected: int m1,m2,m3,m4; public: void getdata3() { cout<<Enter the mark for subjects 1,2,3,4:<<endl; cin>>m1>>m2>>m3>>m4; }}; class Result:public Exam,public Sports { public: void showdata()

{ clrscr(); cout<<Result<<endl; cout<<-----------------------------<<endl; cout<<Name:<<pname<<endl; cout<<Register Number:<<regno<<endl; cout<<Sports:<<sname<<endl; cout<<Subject 1:<<m1<<endl; cout<<Subject 2:<<m2<<endl; cout<<Subject 3:<<m3<<endl; cout<<Subject 4:<<m4<<endl; }}; void main() { Result m; clrscr(); m.getdata(); m.getdata1(); m.getdata2(); m.getdata3(); m.showdata(); getch(); }

OUTPUT

person
(from C++ Reverse Engineered) pname : char [30] age : int getdata()

student
(from C++ Reverse Engineered) regno : int getdata1()

exam sports
(from C++ Reverse Engineered) sname : char [20] getdata2() (from C++ Reverse Engineered) m1 : int m2 : int m3 : int m4 : int getdata3()

staff
name age getdata1() showdata1()

result
(from C++ Reverse Engineered) showdata()

RESULT The data model created successfully and output verified

ATM SYSTEM
Problem Statement An ATM stands for automated teller machine. The system is designed to control and simulated the ATM. The ATM will communicate with the banks compute over an appropriate communication link. A client will be required to insert an ATM card and enter the pin both of which will be sent to the bank for validation as part of each transaction. The ATM must provide the following services to a client. AIM
To design the ATM system using Rational Rose.

A client must be able to provide the cash withdraw from any suitable account linked to the card. A client must be able to make a balance enquiry of any account linked to the card. A client should be able to view transaction history of any account linked to the card. A client may be able to change the pin of account linked to the card. A client should be able to abort a transaction in progress

System requirements
Operating system Pentium processor

USE CASE DIAGRAM

The ATM transaction use cases in our system are: 1. 2. 3. 4. 5. Login Withdraw Mini statement ATM machine status Deposit

Actors involved:
1. User 2. Bank manager

Use case Description Login

The user enters a user name and password. If it is valid, the users account becomes available. If it is invalid, an appropriate message is displayed to the user.

Withdraw
The user tries to withdraw an amount from his or her checking account. The amount is less than or equal to the checking accounts balance, the transaction is performed and the available information is displayed. The system creates a ecord of the transaction and the display confirmation message is displayed to the client.

Mini statement
The bank user requests a history of transactions for a checking account. The system displays the transaction history for the checking account. The transaction history consists of amount, date, transaction type and balance of the particular account.

ATM machine status

The bank manager enters a username and password. If it is valid, the bank manager accesses the machine status. If it is invalid, an appropriate message is displayed to the user.

Deposit
The bank user requests the system to deposit money to an account. The user accesses the account for which a deposit is going to be made and enters the amount. The system creates a record of the transaction and an appropriate confirmation message (display confirmation) is displayed to the client. The transaction must include the date, type, amount and account balance after the transaction.

CLASS DIAGRAM The class diagram, also referred to as object modeling is the main static analysis diagram. The main task of object modeling is to graphically show what each object will do in the problem domain. The problem domain describes the structure and the relationships among objects. The ATM system class diagram consists of four classes: 1. 2. 3. 4. 1) User class: User class ATM machine status Account Transaction

It consists of four attributes and two operations. The attributes are user name, password, address and DOB. The operations of this class are read (), display () and write (). 2) ATM machine status:

The attributes of this class are ATM balance, todays withdrawal, todays balance, and limitations. The operations are login verification (), ATM status () and display confirmation ().

3) Account: The attributes are account no. and balance and the operations are withdraw (), deposit () and display availability (). 4) Transaction: The attributes of this class are account no, transaction type, data, amount, balance and the operations are mini statement () and create transaction (). SEQUENCE DIAGRAM It is the behavioral diagram the shows interaction emphasizing time ordering of the message. COLLABORATION DIAGRAM It represents collaboration which is a set of objects related in particular content and interaction which is a set of messages, exchange among the object. Procedure Auto generate the collaboration Open the preview project model and open the sequence diagram Press F5 to auto generate the collaboration diagram Arrange the diagram elements Run the report

Use case Diagram

Sequence Diagram 1

ATM_machine : ATM_mc User:customer : NewClass

Account : account

Transaction : Transaction

login_verify()

confirmation

deposit()

display_avail()

ministmt()

display()

Sequence Diagram 2

Sequence Diagram 3

Sequence Diagram 4

Sequence Diagram 5

Collaboration diagram 1

Collaboration diagram 2

Collaboration diagram 3

Collaboration diagram 4

Collaboration diagram 5

Class Diagram

RESULT Thus the data model for ATM system has been produced successfully and output verified .

IMPLEMENTATION OF CASE WORK BENCHES

AIM To create an implementation of case work benches such as Business planning & modeling, Analysis and Design, User interface Development, Programming, Verification and Validation and Maintenance using Rational Rose. a) BUSINESS PLANNING AND MODELING: Objective: Business object analysis is a process of understanding the systems requirements and establishing the goals of an application. The main intent of this activity is to understand users requirements. The outcome of the business object analysis is to identify classes that make up the business layer and the relationships that play a role in achieving system goals. Advantages: 1. It is very time consuming. 2. It makes you very familiar with the system and therefore the user requirements and also aid in developing usecases. b) ANALYSIS AND DESIGN: Analysis involves a great deal of interaction with the people who will be affected by the system. The analysis is transforming problem definition into set of facts into some set of requirements. System design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. USE CASE DIAGRAM: Problem statement: The user can login by entering Username as well as password. The details of all the books and members are stored. The details of all the books that are issued as well as returned are stored and retrieved using their member code.

 The date of issue and date of return are also stored.

Identifying Actors: Customer Librarian

Identifying use cases: Login Find Book Issue Return Renewal Maintenance

USE CASE DIAGRAM:

Login

Find Book
<<extends>>

Customer

Issue

Librarian

Return

Renewal

Maintenance

ACTIVITY DIAGRAM: PROBLEM STATEMENT: In login user enters Username and password, if it is correct then continue. The details of books and members are stored. The issue details and return details of books are also stored. ACTIVITY DIAGRAM:

New Sw ...

Log in

Invalid

Valid

FindBook

Re ne wal

Re turn

Alte rnate Book Not available

Issue

Re ne walBook

Assig nFine

Re turnBook

Updated Status

SEQUENCE DIAGRAM:

CustomerClass

Libraarian

Library

1: FindBook() 2: Availability Status() 3: Request()

4: Issue()

5: Renewal() 6: Update()

7: Status() 8: Return() 9: Maintenance

10: Status()

CLASS DIAGRAM:

Library location : char totalBooks : Numbe r type : char No OfCopies : Number RackNum : Number Library() FindBook() Maintenance() Update() Ava ilabilityStatus()

Custom e rClass name : char address : char contactNo : Number id : number issue() status() CustomerClass()

Libraarian Bookname : char Bookno : Number AuthorName : Char Edition : Number Add() Request() Return() Renewal() Libraarian()

c) USER INTERFACE DEVELOPMENT:

 The user interface(UI) is everything designed into an information device with which a human being may interactincluding display screen, keyboard, mouse, light pen, the appearance of a desktop, illuminated characters, help messages, and how an application program or a website invites interaction and response to it. USER INTERFACE COMPONENT: Form 1 In this form there are two labels denoting Username and password. The user can login as well as logout from the system.

Form 2 In this form there are three menus namely Information, Details and Exit. It also contain submenus as book, exit, issue, member and return.

Form 3 In this form design there are five labels and textboxes denoting Member code, Name, Address, Fees and Date. The details of the member can be added and deleted.

Form 4 In this form there are five labels and textboxes denoting Book Code, Book name, Author, Publication and Date. The details of the book can be added as well as deleted.

Form 5 In this form there are two combo boxes for Book code and Member code and four labels denoting, Book name, , Member name, Issue date and return date. The book can be issued to the user.

Form 6 In this form there are five labels denoting Return date, Book code, Book name, Member code and member name. The book can be returned back.

d) PROGRAMMING: Computer programming (programming or coding) is the process of designing, writing, testing, debugging/trouble shooting, and maintaining the source code of computer programs CODE: Form 1 Private Sub Command1_Click() If Text1.Text = "Library" And Text2.Text = "Library" Then Form2.Show Me.Hide Else MsgBox ("Invalid login") Text1.Text = "" Text2.Text = "" End If End Sub

Private Sub Command2_Click() End End Sub

Form 2 Private Sub bk_Click() Form4.Show Me.Hide End Sub

Private Sub ext_Click() End End Sub

Private Sub iss_Click() Form5.Show Me.Hide End Sub

Private Sub mb_Click() Form3.Show Me.Hide End Sub

Private Sub rt_Click() Form6.Show Me.Hide End Sub

Form 3 Dim cn As ADODB.Connection Dim rs As ADODB.Recordset

Private Sub Command1_Click()

If Text1.Text = "" Or Text2.Text = "" Or Text3.Text = "" Or Text4.Text = "" Or Text5.Text = "" Then MsgBox ("Enter All Information") Else cn.Execute ("insert into Member values('" & Text1.Text & "','" & Text2.Text & "','" & Text3.Text & "','" & Text4.Text & "','" & Text5.Text & "')") MsgBox ("Records Inserted") clear End If End Sub Sub clear() Text1.Text = "" Text2.Text = "" Text3.Text = "" Text4.Text = "" End Sub

Private Sub Command2_Click() Set rs = cn.Execute(" select Mcode from Issue") rs.MoveFirst Do Until rs.EOF If rs("MCode") = Text1.Text Then MsgBox "Member has not returned the book", vbOKCancel, "MESSAGE" Text1.Text = "" Text1.SetFocus Exit Sub

End If rs.MoveNext Loop If Text1.Text = "" Then MsgBox ("Enter the Member code to be deleted") Else c = MsgBox("Are you sure to delete", vbOKCancel) If c = vbOK Then Set rs = cn.Execute("delete from Member where Mcode='" & Text1.Text & "'") Set rs = cn.Execute("delete from Member where Mname='" & Text1.Text & "'") Set rs = cn.Execute("delete from Member where Address='" & Text1.Text & "'") Set rs = cn.Execute("delete from Member where Fees='" & Text1.Text & "'") Set rs = cn.Execute("delete from Member where Mdate='" & Text1.Text & "'") MsgBox ("Record deleted") clear End If End If End Sub

Private Sub Command3_Click() Form2.Show Me.Hide End Sub

Private Sub Form_Load()

Set cn = New ADODB.Connection cn.Open "dsn=Library" Set rs = New ADODB.Recordset Text5.Text = Format(Now(), "dd-mm-yy") End Sub

Private Sub Text2_Validate(Cancel As Boolean) Set rs = cn.Execute(" select Mcode from Member")

Do Until rs.EOF If rs("Mcode") = Text1.Text Then MsgBox "Member Code already exist", vbOKCancel, "MESSAGE" Text1.Text = "" Text1.SetFocus Exit Sub End If rs.MoveNext Loop End Sub Private Sub Text4_GotFocus() Text4.Text = "50" End Sub Form 4 Dim cn As New ADODB.Connection Dim rs As New ADODB.Recordset

Private Sub Command1_Click() If Text1.Text = "" Or Text2.Text = "" Or Text3.Text = "" Or Text4.Text = "" Or Text5.Text = "" Then MsgBox ("Enter All Information") Else cn.Execute ("insert into Book values('" & Text1.Text & "','" & Text2.Text & "','" & Text3.Text & "','" & Text4.Text & "','" & Text5.Text & "')") MsgBox ("Records Inserted") clear End If End Sub Sub clear() Text1.Text = "" Text2.Text = "" Text3.Text = "" Text4.Text = "" End Sub Private Sub Command2_Click() If Text1.Text = "" Then MsgBox ("Enter the Book Code to be deleted") Else c = MsgBox("Are you sure to delete", vbOKCancel) End If If c = vbOK Then Set rs = cn.Execute("delete from Book where Bcode='" & Text1.Text & "'")

Set rs = cn.Execute("delete from Book where Bname='" & Text1.Text & "'") Set rs = cn.Execute("delete from Book where Author='" & Text1.Text & "'") Set rs = cn.Execute("delete from Book where Publisher='" & Text1.Text & "'") Set rs = cn.Execute("delete from Book where Bdate='" & Text1.Text & "'") MsgBox ("Record deleted") clear End If End Sub

Private Sub Command3_Click() Form2.Show Me.Hide End Sub

Private Sub Form_Load() cn.Open "dsn=Library" Text5.Text = Format(Now(), "dd-mm-yy") End Sub

Private Sub Text2_Validate(Cancel As Boolean) Set rs = cn.Execute(" select Bcode from Book") Do Until rs.EOF If rs("Bcode") = Text1.Text Then

MsgBox "Book Code already exist", vbOKCancel, "MESSAGE" Text1.Text = "" Text1.SetFocus Exit Sub End If rs.MoveNext Loop End Sub Form 5 Dim cn As New ADODB.Connection Dim rs As New ADODB.Recordset Dim NewDate As Date Dim OldDate As Date

Private Sub Combo1_Click() On Error Resume Next cn.Open "dsn=Library" Set rs = cn.Execute("select Bname from Book where Bcode='" & Combo1 & "'") Text1.Text = rs.Fields(0) cn.Close End Sub

Private Sub Combo2_Click() On Error Resume Next cn.Open "dsn=Library"

Set rs = cn.Execute("select Mname from Member where Mcode='" & Combo2 & "'") Text2.Text = rs.Fields(0) Text3.Text = Format(Now(), "dd-mm-yy") cn.Close End Sub

Private Sub Command1_Click() If Combo1 = "" Or Combo2 = "" Or Text1 = "" Or Text2 = "" Or Text3 = "" Then MsgBox "select the Book code and member code" Else cn.Open "dsn=Library" OldDate = Now() NewDate = DateAdd("d", 6, OldDate) Label7.Caption = Format(NewDate, "dd-mm-yy") MsgBox "Book issued" cn.Execute ("insert into Issue values('" & Combo1 & "','" & Text1 & "','" & Combo2 & "','" & Text2 & "','" & Label7.Caption & "')") cn.Close End If End Sub

Private Sub Command2_Click() Me.Hide Form2.Show End Sub

Private Sub Form_Activate() cn.Open "dsn=Library" Set rs = cn.Execute("select Bcode from Book") Combo1.clear While Not rs.EOF Combo1.AddItem (rs.Fields(0)) rs.MoveNext Wend Set rs = cn.Execute("select Mcode from Member") Combo2.clear While Not rs.EOF Combo2.AddItem (rs.Fields(0)) rs.MoveNext Wend cn.Close End Sub Form 6 Dim cn As New ADODB.Connection Dim rs As New ADODB.Recordset Dim NewDate As Date Dim OldDate As Date

Private Sub Command1_Click() If Text1.Text = "" Then

MsgBox "Enter the Book code" Else cn.Open "dsn=Library" MsgBox "Book Returned" cn.Execute ("delete from Issue where BCode='" & Text1 & "'") cn.Close Text1.Text = "" Text2.Text = "" Text3.Text = "" Text4.Text = "" Text5.Text = "" End If End Sub

Private Sub Command2_Click() Me.Hide Form2.Show End Sub

OUTPUT Form 1

Form 2

Form 3

Form 4

Form 5

Form 6

e) VERIFICATION AND VALIDATION: Verification and validation is the process of checking that a product, service, or system meets specifications and that it fulfills its intended purpose. Verification Are we building the product right? Its the process of determining whether or not the products of a given phase of software development fulfill the requirements established during the previous phase. Validation-Are we building the right product? Process of evaluating software at the end of its development to ensure that it is free from failures & complies with the requirements.

CONCLUSION The Implementation of Work Case Benches has been implemented successfully by performing the above process steps.