OOAD record1

Basic Concepts of UML Diagrams

Types of UML Diagrams

Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools include:

Use Case Diagram displays the relationship among actors and use cases.

Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others.

Interaction Diagrams

Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects).

Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages.

State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions.

Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing.

Physical Diagrams

Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time.

Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units.

Use Case Diagrams

A use case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases. The two main components of a use case diagram are use cases and actors.

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/physical.htm

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htm

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/state.htm

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/interaction.htm


http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/class.htm

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/use_case.htm

An actor is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task.

When to Use: Use Cases Diagrams

Use cases are used in almost every project. There are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible.

How to Draw: Use Cases Diagrams

Use cases are a relatively easy UML diagram to draw, but this is a very simplified example. This example is only meant as an introduction to the UML and use cases. If you would like to learn more see the Resources page for more detailed resources on UML.

Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps.

1. Browse catalog and select items. 2. Call sales representative.

3. Supply shipping information.

4. Supply payment information.

5. Receive conformation number from salesperson.

These steps would generate this simple use case diagram:

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/resources.htm

This example shows the customer as a actor because the customer is using the ordering system. The diagram takes the simple steps listed above and shows them as actions the customer might perform. The salesperson could also be included in this use case diagram because the salesperson is also interacting with the ordering system.

From this simple diagram the requirements of the ordering system can easily be derived. The system will need to be able to perform actions for all of the use cases listed. As the project progresses other use cases might appear. The customer might have a need to add an item to an order that has already been placed. This diagram can easily be expanded until a complete description of the ordering system is derived capturing all of the requirements that the system will need to perform.

Class Diagrams

Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects. Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation. These perspectives become evident as the diagram is created and help solidify the design. This example is only meant as an introduction to the UML and class diagrams. If you would like to learn more see the Resources page for more detailed resources on UML.

Classes are composed of three things: a name, attributes, and operations. Below is an example of a class.


Class diagrams also display relationships such as containment, inheritance, associations and others. Below is an example of an associative relationship:

The association relationship is the most common relationship in a class diagram. The association shows the relationship between instances of classes. For example, the class Order is associated with the class Customer. The multiplicity of the association denotes the number of objects that can participate in then relationship. For example, an Order object can be associated to only one customer, but a customer can be associated to many orders.

Another common relationship in class diagrams is a generalization. A generalization is used when two classes are similar, but have some differences. Look at the generalization below:

In this example the classes Corporate Customer and Personal Customer have some similarities such as name and address, but each class has some of its own attributes and operations. The class Customer is a general form of both the Corporate Customer and Personal Customer classes. This allows the designers to just use the Customer class for modules and do not require in-depth representation of each type of customer.

When to Use: Class Diagrams

Class diagrams are used in nearly all Object Oriented software designs. Use them to describe the Classes of the system and their relationships to each other.

How to Draw: Class Diagrams

Class diagrams are some of the most difficult UML diagrams to draw. To draw detailed and useful diagrams a person would have to study UML and Object Oriented principles for a long time. Therefore, this page will give a very high level overview of the process. To find list of where to find more information see the Resources page.

Before drawing a class diagram consider the three different perspectives of the system the diagram will present; conceptual, specification, and implementation. Try not to focus on one perspective and try seeing how they all work together.

When designing classes consider what attributes and operations it will have. Then try to determine how instances of the classes will interact with each other. These are the very first steps of many in developing a class diagram. However, using just these basic techniques one can develop a complete view of the software system.

This example is only meant as an introduction to the UML and use cases. If you would like to learn more see the Resources page for more detailed resources on UML.



Interaction Diagrams

Interaction diagrams model the behavior of use cases by describing the way groups of objects interact to complete the task. The two kinds of interaction diagrams are sequence and collaboration diagrams. This example is only meant as an introduction to the UML and interaction diagrams. If you would like to learn more see the Resources page for a list of more detailed resources on UML.

When to Use: Interaction Diagrams

Interaction diagrams are used when you want to model the behavior of several objects in a use case. They demonstrate how the objects collaborate for the behavior. Interaction diagrams do not give a in depth representation of the behavior. If you want to see what a specific object is doing for several use cases use a state diagram. To see a particular behavior over many use cases or threads use an activity diagrams.

How to Draw: Interaction Diagrams

Sequence diagrams, collaboration diagrams, or both diagrams can be used to demonstrate the interaction of objects in a use case. Sequence diagrams generally show the sequence of events that occur. Collaboration diagrams demonstrate how objects are statically connected. Both diagrams are relatively simple to draw and contain similar elements.

Sequence diagrams:

Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass. The diagrams are read left to right and descending. The example below shows an object of class 1 start the behavior by sending a message to an object of class 2. Messages pass between the different objects until the object of class 1 receives the final message.

Below is a slightly more complex example. The light blue vertical rectangles the objects activation while the green vertical dashed lines represent the life of the object. The green vertical rectangles represent when a particular object has control. The represents when the object is destroyed. This diagram also shows conditions for messages to be sent to other object. The condition is listed between brackets next to the message. For example, a [condition] has to be met before the object of class 2 can send a message () to the object of class 3.




The next diagram shows the beginning of a sequence diagram for placing an order. The object an Order Entry Window is created and sends a message to an Order object to prepare the order. Notice the the names of the objects are followed by a colon. The names of the classes the objects belong to do not have to be listed. However the colon is required to denote that it is the name of an object following the object Name: class Name naming system.

Next the Order object checks to see if the item is in stock and if the [In Stock] condition is met it sends a message to create a new Delivery Item object.

The next diagram adds another conditional message to the Order object. If the item is [OutOfStock] it sends a message back to the Order Entry Window object stating that the object is out of stack.

This simple diagram shows the sequence that messages are passed between objects to complete a use case for ordering an item.

Collaboration diagrams

Collaboration diagrams are also relatively easy to draw. They show the relationship between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them. The numbers next to the messages are called sequence numbers. As the name suggests, they show the sequence of the messages as they are passed between the objects. There are many acceptable sequence numbering schemes in UML. A simple 1, 2, 3... Format can be used, as the example below shows or for more detailed and complex diagrams a 1, 1.1, 1.2, 1.2.1... Scheme can be used.

The example below shows a simple collaboration diagram for the placing an order use case. This time the names of the objects appear after the colon, such as: Order Entry Window following the object Name: class Name naming convention. This time the class name is shown to demonstrate that all of objects of that class will behave the same way.

State Diagrams

State diagrams are used to describe the behavior of a system. State diagrams describe all of the possible states of an object as events occur. Each diagram usually represents objects of a single class and tracks the different states of its objects through the system.

When to Use: State Diagrams

Use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system. Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case. State diagrams are other combined with other diagrams such as interaction diagrams and activity diagrams.

How to Draw: State Diagrams

State diagrams have very few elements. The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state. The activity section of the state symbol depicts what activities the object will be doing while it is in that state.

All state diagrams being with an initial state of the object. This is the state of the object when it is created. After the initial state the object begins changing states. Conditions based on the activities can determine what the next state the object transitions to.




Below is an example of a state diagram might look like for an Order object. When the object enters the Checking state it performs the activity "check items." After the activity is completed the object transitions to the next state based on the conditions [all items available] or [an item is not available]. If an item is not available the order is canceled. If all items are available then the order is dispatched. When the object transitions to the Dispatching state the activity "initiate delivery" is performed. After this activity is complete the object transitions again to the Delivered state.

State diagrams can also show a super-state for the object. A super-state is used when many transitions lead to the a certain state. Instead of showing all of the transitions from each state to the redundant state a super-state can be used to show that all of the states inside of the super-state can transition to the redundant state. This helps make the state diagram easier to read.

The diagram below shows a super-state. Both the Checking and Dispatching states can transition into the Canceled state, so a transition is shown from a super-state named Active to the state Cancel. By contrast, the state Dispatching can only transition to the Delivered state, so we show an arrow only from the Dispatching state to the Delivered state.

Activity Diagrams

Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams because activities are the state of doing something. The diagrams describe the state of activities by showing the sequence of activities performed. Activity diagrams can show activities that are conditional or parallel.

When to Use: Activity Diagrams

Activity diagrams should be used in conjunction with other modeling techniques such as interaction diagrams and state diagrams. The main reason to use activity diagrams is to model the workflow behind the system being designed. Activity Diagrams are also useful for: analyzing a use case by describing what actions need to take place and when they should occur; describing a complicated sequential algorithm; and modeling applications with parallel processes.

However, activity diagrams should not take the place of interaction diagrams and state diagrams. Activity diagrams do not give detail about how objects behave or how objects collaborate.

How to Draw: Activity Diagrams

Activity diagrams show the flow of activities through the system. Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities. A fork is used when multiple activities are occurring at the same time. The diagram below shows a fork after activity1. This indicates that both activity2 and activity3 are occurring at the same time. After activity2 there is a branch. The branch describes what activities will take place based on a set of conditions. All branches at some point are followed by a merge to indicate the end of the conditional behavior started by that branch. After the merge all of the parallel activities must be combined by a join before transitioning into the final activity state.







Below is a possible activity diagram for processing an order. The diagram shows the flow of actions in the system's workflow. Once the order is received the activities split into two parallel sets of activities. One side fills and sends the order while the other handles the billing. On the Fill Order side, the method of delivery is decided conditionally. Depending on the condition either the Overnight Delivery activity or the Regular Delivery activity is performed. Finally the parallel activities combine to close the order.

COMPONENT DIAGRAM

The component diagram contains components and dependencies. Components represent the physical packaging of a module of code. The dependencies between the components show how changes made to one component may affect the other components in the system. Dependencies in a component diagram are represented by a dashed line between two or more components. Component diagrams can also show the interfaces used by the components to communicate to each other.

The combined deployment and component diagram below gives a high level physical description of the completed system. The diagram shows two nodes which represent two machines communicating through TCP/IP. Component2 is dependant on component1, so changes to component 2 could affect component1. The diagram also depicts component3 interfacing with component1. This diagram gives the reader a quick overall view of the entire system.

DEPLOYMENT DIAGRAM

A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. To describe a web site, for example, a deployment diagram would show what hardware components ("nodes") exist (e.g., a web server, an application server, and a database server), what software components ("artifacts") run on each node (e.g., web application, database), and how the different pieces are connected (e.g. JDBC, REST, RMI).

The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within the boxes. Nodes may have subnodes, which appear as nested boxes. A single node in a deployment diagram may conceptually represent multiple physical nodes, such as a cluster of database servers.

EXP.NO:

http://en.wikipedia.org/wiki/Artifact_(UML)

http://en.wikipedia.org/wiki/Unified_Modeling_Language

Date:

FOREIGN TRADING SYSTEM

AIM:

To analyze, design and develop code for Foreign Trading system using Argo UML.

1. PROBLEM STATEMENT:

To develop a Foreign Trading system that would trade between seller and buyer to maintain the details of the export and import who trading that is connected to LAN.

This should have the following details about the merchants who applied for trading such as product name, order details, agreement details.

2. PROBLEM ANALYSIS AND PLANNING:

The Problem involved in foreign trading system is analyzed using SRS (Software Requirement Specification) and the plan schedule to finish this project is given later in this section. Now SRS is given below.

2.1. SOFTWARE REQUIREMENT SPECIFICATION (SRS)

2.1.1. INTRODUCTION

2.1.1.1. PURPOSE:

The Project is developing foreign trading for trade department. The system must be accessible for the trade department.

2.1.1.2. DOCUMENT CONVENTIONS:

The headings have been written using “Heading 2” style with “Times New Roman” font and font size in “14”. The subheadings under each headings using “Heading 2” style with “Times New Roman” font and font size in “12”.The content under each headings using “Normal” style with “Times New Roman” font and font size in “12”.

2.1.1.3. INTENDED AUDIENCE AND READING SUGGESTIONS:

The different types of reader that the document is intended for developers, project, managers, users, testers and document for all readers is in the sequence as it has been given in the document.

2.1.1.4. PROJECT SCOPE:

A Foreign trading System allows officers to register the details of product name, order and agreement details. These functions make the office to function smoothly.

2.1.2. OVERALL DESCRIPTION

2.1.2.1. PRODUCT PERSPECTIVE:

The System is a new, self-contained product with its requirement and functionalities.

2.1.2.2. PRODUCT FEATURES:

The Significant features that this product performs as well as lets the user to perform are as follows.

Business partner Agreement Order Manufacturing product Payment of order and ship

2.1.2.3. OPERATING ENVIRONMENT:

HARDWARE: Pentium P4 Processor, 40GB Hard disk, 128 MB RAM. SOFTWARE: Windows Xp and earlier versions, Argo UML.

2.1.2.4. DESIGN AND IMPLEMENTATION CONSTRAINTS:

A server with high end processor is required. Time and funding are major constraints. Delivering on time with all the specifications implied to the software is a major factor.

Timing Requirements: 10 minutes per student.

Registration Timing: Morning 10AM to Evening 6PM.

2.1.2.5. USER DOCUMENTATION:

A manual describing all the features and functions of the foreign trading system is provided along the software. The foreign trading system also provides on spot help which enables the user to clear the doubts in entering the option then and there. An interactive tutorial with a demo tour also provided.

2.1.2.6. ASSUMPTION AND DEPENDENCIES:

It is assumed that the students have the basic knowledge of using a computer. The product is dependent on the database.

2.1.3. SYSTEM FEATURES

2.1.3.1. USE CASES COVERED:

Business partner Business Agreement Order Manufacture of order Payment of order Ship payment Insurance

2.1.4. EXTERNAL INTERFACE REQUIREMENTS

2.1.4.1. USER INTERFACES:

This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards and so on. The software components for which a user interface is needed in the project.

2.1.4.2. HARDWARE INTERFACES:

Disk is used for data storage. Keyboard is used for getting the input details and the monitor displays the output generated for the given input. Printer is used for printing the generated reports if necessary.

2.1.4.3. SOFTWARE INTERFACES:

The connection between this product and other specific software components (name and version), including databases, operating systems, tools, libraries and integrated commercial components are provided. The data items or messages coming into the system and going out and describe the purpose of each is identified the services needed and the nature of communications are also described. Documents that describe detailed application programming interface protocols are referred. Data that will be shared across software components are identified using Oracle.

2.1.4.4. COMMUNICATION INTERFACES:

It uses communication standards like FTP, HTTP. It also has network server communication protocols. Communication functions required by this product, includes e-mail, web browser, network server communication protocols, electronic forms and so on.

2.1.5. OTHER NONFUNCTIONAL REQUIREMENTS

2.1.5.1. PERFORMANCE REQUIREMENTS:

The turnaround time of the process is expected to be as less as possible such that the results are generated without any time delay. The performance required is Reusability, high performance and reliability.

2.1.5.2. SAFETY REQUIREMENTS:

The data must be generated from unauthorized access, system failures, malicious software codes, from hackers by using software’s like anti-Virus, Firewall, SpyWare etc.

2.1.5.3. SECURITY REQUIREMENTS:

The officer and Register user can login and access the system using the username and password. If any user without proper username and password or reference number try to login they should be blocked or stopped from doing so.

2.1.5.4. SOFTWARE QUALITY ATTRIBUTES:

The expected key attributes out of this product are

Adaptability Availability Correctness Flexibility Interoperability Maintainability Portability Reliability Reusability Robustness Testability Usability

2.1.6. OTHER REQUIREMENTS

None.

2.2. PROJECT PLAN AND GANTT CHART

ACTIVITY DURATION (IN DAYS)

Submission of brief problem statement 3 daysSRS (Final Statement of requirements) 6 daysTest Plan 4 daysSystem Design Document 5 daysState and Activity Diagram 3 daysUse Case Diagram 1 dayDescription of Use Case Diagram 2 daysSequence Diagrams and Collaboration Diagrams

10 days

Class Diagrams with Description 5 daysComponent Diagram 1 dayDeployment Diagram 1 daySoftware Testing Report 2 daysCoverage Analysis Report 2 days

3. DATA MODELING

3.1. ACTORS

Seller Authority Buyer

3.2. USECASES

Business partner Business Agreement Order Manufacture of order Payment of order Ship payment Insurance

3.3. DESCRIPTIONS

3.3.1. USE CASE DIAGRAM

Draw and drop the actors and use case from toolbox in the diagram window. Associate the Use cases and actors.

3.3.2. CLASS DIAGRAM

The class diagram shows a set of classes, interfaces and collaboration and their relationship.

Class diagram shows the attributes and operation of a class and constraints that apply to the way the object are connected.3.3.3. SEQUENCE DIAGRAM

A sequence diagram is a graphical view of a scenario that shows object interaction in a time-based sequence – what happens first, what happens next.

Sequence diagrams establish the roles of objects and help provide essential information to determine class responsibilities and interfaces. 3.3.4. COLLABARATION DIAGRAM

The collaboration diagram can be drawn from the sequential diagram. The collaboration diagram shows the overall flow of central towards each phase of the

class 3.3.5. STATECHART DIAGRAM

The State chart diagram describes the whole process doing in the project. The state chart diagram shows the control of the full project.

3.3.6. ACTIVITY DIAGRAM The activity diagram describes the sequencing of activities with support for both

conditional and parallel behavior. The various controls are placed into the diagram window to create activity diagram.

3.3.7. COMPONENT DIAGRAM It displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components,

binary code components and executable components.3.3.8. DEPLOYMENT DIAGRAM

A single node in a deployment diagram may conceptually represent multiple physical nodes, such as a cluster of database servers.

A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes.

USE CASE DIAGRAM

http://en.wikipedia.org/wiki/Node_(UML)



CLASS DIAGRAM

SEQUENCE DIAGRAM

COLLABARATION DIAGRAM

STATE CHART DIAGRAM

ACTIVITY DIAGRAM

COMPONENT DIAGRAM

DEPLOYMENT DIAGRAM

SAMPLE CODING

SELLER

public class Seller {

public String NAME ;

public String ADDRESS;

public Integer CONTACT;

public Buyer myBuyer;

public AUTHORITY myAUTHORITY;

public void Advadisement () {

}

public void Sales () {

}

public void Order () {

}

public void Payment of order () {

}

public void Payment of recepit () {

}

public void Discounts () {

}

public void Tax reducation () {

}

}

BUYER

public class Buyer {



public Integer CONTACT;

public String EMAIL-ID ;

public Seller mySeller;

public AUTHORITY myAUTHORITY;

public void Watching the advadisement () {

}

public void How much cost () {

}

public void Order a product () {

}

public void Order of payment () {

}

public void Recepit of payment () {

}

public void Any discounts () {

}

public void Any gift packs () {

}

public void Any door deleviery () {

}

}

AUTHORITY

public class AUTHORITY extends Seller, Seller {



public String VOUCHER;

public Seller mySeller;

public Buyer myBuyer;

public void Vouchers () {

}

public void Transmission () {

}

public void Receiving () {

}

public void Aknowledgement () {

}

}

4. SOFTWARE TESTING TECHNIQUES

4.1. OVERVIEW

The importance of software testing to software cannot be overemphasized. Once source code has been generated, software must be tested to allow errors to be identified and removed before delivery to the customer. While it is not possible to remove every error in a large software package, the software engineer’s goal is to remove as many as possible early in the software development cycle. It is important to remember that testing can only find errors; it cannot prove that a program is bug-free. Two basic test techniques involve testing module input/output [black-box] and exercising internal logic of software components [white-box]. Formal technical reviews by themselves cannot find allow software defects, test data must also be used. For large software projects, separate test teams may be used to develop and execute the set of test cases used in testing. Testing must be planned and designed.

4.1.1. SOFTWARE TESTING OBJECTIVES

Testing is the process of executing a program with the intend of finding errors.

A good test case is one with a high probability of finding an as-yet undiscovered error.

A successful test is one that discovers an as-yet-undiscovered error.

4.1.2. SOFTWARE TESTING PRINCIPLES

All tests should be traceable to customer requirements.

Tests should be planned long before testing begins.

Testing should begin in the small and progress to the large.

Exhaustive testing is not possible.

To be most effective, testing should be conducted by an independent third party.

4.1.3. BLACK BOX TESTING

In a black box testing, the test item is treated as “black” since its logic is unknown all that is known is what goes in and what comes out, or the input and output. In black box testing, you try various inputs and examine the resulting output: The black box testing technique also can be used for scenario-based tests where the system’s inside may not be available for inspection but the input and output are defined through use cases or other analysis information.

4.1.4. WHITE BOX TESTING

The main use of white box is in error-based testing. One form of white box testing called path testing makes certain that each path in a object method is executed at least once during testing.

Two types of path testing are statement testing coverage and branch testing coverage.

Statement testing Coverage:

The main idea of statement testing coverage is to test every statement in the objects method by executing it at least once.

Branch testing Coverage:

The main idea behind branch testing coverage is to perform enough tests to ensure that every branch alternatives has been executed at least once under some test.

4.1.5. TOP-DOWN TESTING

A top-down strategy can detect the serious design flows early in the implementations. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test.

4.1.6. BOTTOM-UP TESTING

Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fit the requirements for the system. In bottom-up testing you start with the methods and class that call or reply on no others.

RESULT

Thus the UML diagrams for foreign trading system were created and the corresponding code is generated.

EXP.NO:

Date:

E-BOOK MANAGEMENT SYSTEM

AIM:

To analyze, design and develop code for E-Book Management system using Argo UML.


To develop an E-Book Management system that would collect books from online and maintain the details of the book management who collect books that is connected to LAN.

This should have the following details about the users who search books such as create account, find books.




2.1.1. INTRODUCTION

2.1.1.1. PURPOSE:

The Project is developing e book management for e-book management department. The system must be accessible for the library department.






An E-Book management System allows users to register the details of name and book details. These functions make the office to function smoothly.






Create account Search book Find book Add to shopping cart








A manual describing all the features and functions of the E-book management system is provided along the software. The E-book management system also provides on spot help which enables the user to clear the doubts in entering the option then and there. An interactive tutorial with a demo tour also provided.





Create account Search books Find books Add books to shopping card Remove books to shopping card














The data must be generated from unauthorized access, system failures, malicious software codes, from hackers by using software’s like anti-Virus, Firewall, Spyware etc.





Adaptability Availability Correctness Flexibility Interoperability Maintainability Portability Reliability Reusability Robustness Testability Usability


None.




10 days

Class Diagrams with Description 5 daysComponent Diagram 1 dayDeployment Diagram 1 daySoftware Testing Report 2 daysCoverage Analysis Report 2 days

3. DATA MODELING

3.1. ACTORS

User Admin Registered user

3.2. USECASES

Create account Search book Browsing the books Find books Add books to shopping card Remove books to shopping card

3.3. DESCRIPTIONS







Sequence diagrams establish the roles of objects and help provide essential information to determine class responsibilities and interfaces.

3.3.4. COLLABARATION DIAGRAM The collaboration diagram can be drawn from the sequential diagram. The collaboration diagram shows the overall flow of central towards each phase of the









USE CASE DIAGRAM




CLASS DIAGRAM

SEQUENCE DIAGRAM


STATE CHART DIAGRAM

ACTIVITY DIAGRAM

COMPONENT DIAGRAM

DEPLOYMENTDIAGRAM

SAMPLE CODING

USER

public class USER {

public NAME:string;

public E-ID:string;

public ADDRESS:string;

public PH.NO:integer;

public REG USER myREG USER;

public ADMIN myADMIN;

public void Create new accout() {

}

public void collect new card() {

}

}

ADMIN

public class ADMIN extends USER

{

public NAME:string;

public E-ID:string;

public PH.NO:integer;

public WEB ADDR:string;

public DATA BASE myDATA BASE;

public USER myUSER;

public void account receive()

{

}

public void card issues()

{

}

public void book transfor() {

}

}

DATABASE

public class DATA BASE extends REG USER

{

public WEB ADDRESS:string;

public LOCATION:integer;

public MEMO SIZE:integer;

public REG USER myREG USER;

public ADMIN myADMIN;

public void information stored()

{

}

public void information retrived()

{

}

}


4.1. OVERVIEW

























RESULT

Thus the UML diagrams for an E-Book management system were created and the corresponding code is generated.

EXP.NO:

Date:

EXAM REGISTRATION SYSTEM

AIM:

To analyze, design and develop code for EXAM REGISTRATION system using Argo UML.


To develop an Exam Registration system that would collect books from online and maintain the details of the students who collect hall ticket that is connected to LAN.

This should have the following details about the students who apply for exam such as application, fee payment.




2.1.1. INTRODUCTION

2.1.1.1. PURPOSE:

The Project is developing exam registration for exam department in college. The system must be accessible for the exam department.






An Exam Registration System allows users to register the details of name and book details. These functions make the office to function smoothly.






Login Get the application Exam Fee Update database








A manual describing all the features and functions of the Exam registration system is provided along the software. The Exam registration system also provides on spot help which enables the user to clear the doubts in entering the option then and there. An interactive tutorial with a demo tour also provided.





Login Issue the application Fill the form Payment of Exam fee Verification Update database



















Adaptability

Availability Correctness Flexibility Interoperability Maintainability Portability Reliability Reusability Robustness Testability Usability


None.




10 days

Class Diagrams with Description 5 daysComponent Diagram 1 dayDeployment Diagram 1 daySoftware Testing Report 2 daysCoverage Analysis Report 2 days3. DATA MODELING

3.1. ACTORS

Student Admin Database

3.2. USECASES

Login Issue the application Fill the form Payment of Exam fee Verification Update database

3.3. DESCRIPTIONS

















USE CASE DIAGRAM




CLASS DIAGRAM

SEQUENCE DIAGRAM


STATE CHART DIAGRAM

ACTIVITY DIAGRAM

COMPONENT DIAGRAM

DEPLOYMENTDIAGRAM

SAMPLE CODING

STUDENT

public class Student

{

public Stud_Name : String;

public Stud_DOB : Integer;

public Stud_Age : Integer;

public Admin myAdmin;

public void Filling the Form()

{

}

public void Given Payment() {

}

}

ADMIN

public class Admin

{

public Emp_ID : Integer;

public Emp_Age : Integer;

public Database myDatabase;

public void Issue the Application()

{

}

public void Verification()

{

}

public void Issuing the Hallticket()

{

}}

DATABASE

public class Database

{

public Name : String;

public Student myStudent;

public void Update Database()

{

}

public void Student Database()

{

}

}


4.1. OVERVIEW

























RESULT

Thus the UML diagrams for an Exam registration system were created and the corresponding code is generated.

EXP.NO:

Date:

PAY ROLL PROCESSING SYSTEM

AIM:

To analyze, design and develop code for PAY ROLL PROCESSING system using Argo UML.


To develop a Pay Roll Processing system that would collect books from online and maintain the details of the students who collect hall ticket that is connected to LAN.

This should have the following details about the employers who getting salary from any company and their database.




2.1.1. INTRODUCTION

2.1.1.1. PURPOSE:

The Project is developing Payroll processing system for accounts department in company. The system must be accessible for the accounts department.






A Payroll System allows employers to know the details of salary and basic pay details. These functions make the accounts department to function smoothly.






Login Employee details Salary details Cashier details













Salary Employee details Cashier details Salary details Basic pay Hra,da and pf details



















Adaptability



None.




10 days


3.1. ACTORS

Employee Cashier Database

3.2. USECASES

Salary Employee details Cashier details Salary details Basic pay Hra,da and pf details

3.3. DESCRIPTIONS

















USE CASE DIAGRAM




CLASS DIAGRAM

SEQUENCE DIAGRAM


STATE CHART DIAGRAM

ACTIVITY DIAGRAM

COMPONENT DIAGRAM

DEPLOYMENTDIAGRAM

SAMPLE CODING

EMPLOYEE

public class Employee

{

public Integer emp_id;

public string emp_name;

public string emp_address;

public string emp_desig;

public Cashier myCashier;

public Database myDatabase;

public void work()

{

}

public void receive_salary()

{

}

public void w-hours()

{

}

}

CASHIER

public class Cashier

{

public integer c_id;

public string c_name;

public string c_address;

public Employee myEmployee;

public void calculation()

{

}

public void maintain()

{

}

public void submit()

{

}

public void salary()

{

}

public void assign()

{

}

}

DATABASE

public class Database

{

public string emp_details;

public string salary_details;

public string cashier_details;

public Employee myEmployee;

public void store()

{

}

public void retrive()

{

}

public void add()

{

}

public void update()

{

}

public void delete() {

}

}


4.1. OVERVIEW

























RESULT

Thus the UML diagrams for a payroll processing system were created and the corresponding code is generated.

EXP.NO:

Date:

CREDIT CARD PROCESSING SYSTEM

AIM:

To analyze, design and develop code for CREDIT CARD PROCESSING system using Argo UML.


To develop a Credit Card Processing system that would spend money through online and use at the time of purchase is connected to LAN.

This should have the following details about the customers who getting and spending money and their database.


The Problem involved in Credit card processing system is analyzed using SRS (Software Requirement Specification) and the plan schedule to finish this project is given later in this section. Now SRS is given below.


2.1.1. INTRODUCTION

2.1.1.1. PURPOSE:

The Project is developing Credit card processing system for accounts department in bank. The system must be accessible for the accounts department.






A Credit card processing System allows customers to spend money and through online purchase details. These functions make the accounts department to function smoothly.






Purchase product Swipe the card Accepted or Rejected













Purchase the product Swipe the card Collect the product Card Accepted or Rejected



















Adaptability



None.




10 days


3.1. ACTORS

Customer Salesman Admin

3.2. USECASES

Purchase the product Swipe the card Collect the product Card Accepted or Rejected

3.3. DESCRIPTIONS

















USE CASE DIAGRAM




CLASS DIAGRAM

SEQUENCE DIAGRAM


STATE CHART DIAGRAM

ACTIVITY DIAGRAM

COMPONENT DIAGRAM

DEPLOYMENTDIAGRAM

SAMPLE CODING

CUSTOMER

public class customer

{

public Integer Name;

public ph_no: String;

public salesman mysalesman;

public void Purchase()

{

}

public void give card()

{

}

}

SALESMAN

public class salesman

{


public Address: Integer;

public customer mycustomer;

public Admin myAdmin;

private void collect card()

{

}

public void Enter items()

{

}

}

ADMIN

public class Admin

{


public Address: Integer;

public salesman mysalesman;

public void Login()

{

}

public void Accept()

{

}

}


4.1. OVERVIEW

























RESULT

Thus the UML diagrams for a Credit card processing system were created and the corresponding code is generated.