SUPER MARKET ABSTRACT Super market is a fast growing organization.

It acts like a mediator between suppliers and end customers. The super market gets the items from the suppliers by raising orders at right time with required quantity. The super markets are facing the problem in getting the required report from the available system. The reports like showing the progress of sales in past few months, years etc. The market needs to be computerized in order the overcome the difficulties faced by them in placing the order. Purchase order should allow the user to modify reorder quantity if required stock is shout so details of items need to be reported whenever required. We want to know the progress of the shop so that corrective actions will be taken, for this we need sales activities of an outlet should be displayed graphically.

INTRODUCTION During the past decade, increasing attention has been focused on the technology of computer software, as computing systems become more numerous, more complex and more deeply embedded in modern society, the need for systematic approaches becomes increasingly apparent. These includes To use new information and computer technology for personal management information system development on a cost effective basis. To augment management, improve productivity and services. To enhance user/system interface. To update system reliability, availability, flexibility and grow potential. To address human assess for better end user acceptance To provide high security.

SYSTEM ANALYSIS Analysis in the first systems development life cycle phase where you begin to understand, in depth, the need for system changes. The main objective of the analyses is to capture a complete, unambiguous and consistent picture of the requirements and needs. PROBLEM DEFINITION EXISTING SYSTEM The super market is not computerized. So, the whole process is done manually. The problem is that they are facing problem in getting required report from the available system. The reports like showing the progress of sales in past few months, years, etc. The problem is that the manual maintenance of order, viewing items information is very difficult. PROPOSED SYSTEM Proposed system deals with the following activities: Automatic process of customer order. Automatic updating of item, supplier information. FUNCTIONING OF PROPOSED SYSTEM The sales boy processes the customer orders and bill is prepared and is collected by the cashier to update into the system. The owner checks the stock files and places an order to the suppliers. The suppliers supply the goods to the shop and owner updates the stock file.

SOFTWARE REQUIREMENT AND SPECIFICATION PROJECT OVERVIEW AND SUMMARY The project COMPUTERIZATION OF SUPERMARKET deals with accepting the customer orders, process it and generate the bill. It also places orders to the suppliers and updates information. DEVELOPMENT, ENVIRONMENT OPERATING AND MAINTENANCE

In this section we deal how the project is developed, operated and maintained. In this project all data pertaining to suppliers, items, bills and orders are maintained. The item stock file, new stock file, bill file and order file are updated. EXTERNAL INTERFACES USER INTERFACE The software interacts with the following users a) Project leader b) Other related employee of the shop. HARDWARE INTERFACE The software interacts with the following hardware a) The hardware device which gives the input b) The secondary storage device that contains the database that contains data stores.

UML DESCRIPTION UNIFIED MODELING LANGUAGE WHY WE MODEL A successful software organization is one that consistently deploys quality software that meets the needs of its user. An organization that can develop such software in a timely and predictable fashion with an efficient and effective use of resources is one that has a sustainable business. Modeling is a central part of all activities that lead up to the deployment of good software. We build models to communicate the desired structure and behavior of our system to visualize and control the systems architecture. A model is simplification of reality. We build model so that we can better understand the system we are developing. We cant comprehend complex system in its entities. The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. Every model may be expressed at different levels of perception. The best models are connected to reality. No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models.

INTRODUCTION TO UML The Unified Modeling Language (UML) is a standard and appropriate language for writing software blueprint and for modeling systems ranging from enterprise information system to distributed web based applications and even to hard real embedded systems. OVERVIEW The UML is a language for Visualizing Specifying Constructing Documenting The artifacts of software intensive system. A modeling language is a language whose vocabulary and roles focus on conceptual and physical representation of a system that yield an understanding of the different views of evolution of software development lifecycle. In visualizing we communicate the conceptual model to others to eradicate errors and developer who cut the code never write the models, so we visualize. Specifying means building models that are precise, unambiguous and complete. Things that are best expressed graphically are done so graphically in UML, where as things that are best expressed textually are done as in programming language, mapping permits forward engineering and constructing.

Documenting includes: Requirements Architecture Designing Source code Project plans Tests Prototype Releases

The UML address the documentation of system architecture and all of its details like expressing requirements and modeling activities of project planning and release management. UML can be effectively used for domain such as: Enterprise information systems Banking financial services Telecommunications Transportations Distributed web-based services

CONCEPTUAL MODEL The conceptual model of UML requires learning three major elements: the UMLs basic building blocks, the rules that dictate how those building blocks may be put together and some common mechanism that applying through out the UML. BUILDING BLOCKS OF THE UML: The vocabulary of the UML encompasses three kinds of building blocks: 1) Things 2) Relationships 3) Diagrams Things are the abstractions that are first class citizens in model whereas relationships tie these things together and diagrams group-interesting collection of things. THINGS IN UML : There are four kinds of things in UML. 1) 2) 3) 4) Structural things Behavioral things Grouping things Annotational things

These things are basic object-oriented building blocks of UML.

STRUCTURAL THINGS: Structural things are the norms, and the mostly static part of the model. There are seven kinds of structural things. Class: Class is a description of set of objects that share the same attributes, operations, relationships and semantics. A class implements one or more interfaces. It is graphically rendered as a rectangle.
Window Origin Size Open () Close () Move ()

Interface: It is a collection of operations that specify a service of a class or a component. It describes the externally visible behavior of the element. It describes a set of interface specification that is their signatures only. Graphically it is rendered as a circle with its name.

ISpelling Collaboration: It defines an interface and is a society of roles and other elements that work together to provide some cooperative behavior thats bigger than the sum of all the elements. Therefore, collaboration has structural, as well as behavior dimension. It is graphically rendered with dashed line.
Chain of Responsibilit y

Use case: It is a description of set of sequence of actions that system performs that yields an observable result of value to a particular actor. It is used to structure behavioral things in a model and realized collaboration. Graphically, it is rendered as an ellipse with a solid line including only its name.

Place order

Active class: It is a class whose objects own one or more process or threads and therefore initiate control activity. Its objects represent elements whose behavior is concurrent with other elements. It is rendered as a class with heavy lines.
Eventmg r Flush () Suspend(

Component: It is physical and replicable part of the system that confirms to and provides to the realization a set of interfaces eg: complex or java beans or source code files. It typically represents the physical packaging or otherwise logical element such as classes and interfaces. Graphically it is rendered as rectangle with two tabs including its name.

Order.ja va

Node: A node is a physical element that exists at runtime and represents computational resources, generally having some memory and processing capability. A set of component resides on a node and migrates from node to node. Graphically is rendered as cube including its name.

Serve r

BEHAVIORAL THINGS: There are dynamic parts of UML model. These are the verbs of the model, representing behavior over time and space. There are two kinds of behavioral things: Interaction: It is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. It is rendered as a directed line including its name. Display

State machine: It is a behavior that specifies the sequence of states an object or an interaction goes through during its lifetime in response to events with its responses to those events. It is rendered rounded rectangle.

Waiting

GROUPING THINGS: Grouping things are the organizational parts of UML. Package: Package is a general purpose mechanism for organizing elements into groups. Structural things, behavioral things and other grouping things may be placed into package. Graphically rendered as a tabbed folder.

Business Rules

ANNOTATIONAL THINGS: Annotatinal things are the explanatory parts of UML model. These are the comment we apply to describe, illuminate and remark about any elements in a model. Note: Is simply a symbol for rendering constraints and comments attached to an element or collection of elements. Graphically a note is rendered as a rectangle with a dog-eared corner, together with a graphical or textual comment.

Return copy of self

RELATIONSHIPS IN UML: There are four kinds of basic relationships in UML. 1) 2) 3) 4) Dependency Association Generalization Realization

Dependency: Is a semantic relationship between two things in which a change to one thing (the independent) may effect the semantic of the other things (dependent thing). Generally, dependency is rendered as dashed line, possibly directed and occasionally including a label.

Association: Is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association representing a structural relationship between a whole and its parts. Graphically an association is rendered as a solid line possible directed, occasionally including a label and often contains other adornment, such as multiplicity and role names. 0. 1 Employer * Employee

Generalization: Is a relationship between a general things and more specific kind of the thing. This is an is-a-kind-of relationship. It means that objects of a child may be used anywhere the parent may appear, but not the reverse.

Graphically, rendered as a solid line with a hollow arrow head pointing to the parent. Realization: Is a semantic relationship between a classifier, where in one classifier specifies a contract that another classifier guarantees to carryout between interfaces and classes or components that realize them and between them and between use cases and collaborations that realize them. Graphically, rendered a cross between generalization and dependency relationship.

DIAGRAMS IN UML A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships). We draw diagrams to visualize most trivial systems from different perspectives, so a diagram is a projection into a system. UML includes nine such diagrams: 1. 2. 3. 4. 5. 6. 7. 8. 9. Class Diagram Object Diagram Use case Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram Component Diagram Deployment Diagram

A class diagram shows a set of classes, interfaces, and collaborations and their relationships. These diagrams address the static design view of a system.

An object diagram shows a set of objects and their relationships. They represent the static design or static process view of a system. A use case diagram shows a set of use cases and actors and their relationships. These include especially diagrams important in organizing and modeling the behavior of a system.

RATIONAL ROSE What is rose? 1. Rational Rose is a powerful tool to aid in the analysis and design of object-oriented software systems. 2. Rose is a tool meant to be used by the entire project team. It is repository of scope and design information that each team member can use to get the information they need. 3. Rose will help developers by generating skeletal code. Rose can reverse engineer code and create a model based on an existing system. When a change occurs to the model, Rose can modify the code to incorporate the change. 4. They are three different versions of Rose currently available: Rose Modeler, which allows you to create a model for your system, but will not support code generation or reverse engineering. Rose Professional, which allows to generate code in one language. Rose Enterprise, which allows you to generate code in C++, Java and Visual Basic as well as Oracle 8 schema. Four Views in a Rose Model 1) Use Case View

2) Logical View 3) Component View 4) Deployment View Use Case View: The Use Case View includes all of the actors, use cases, and use case diagrams in the system. It may also include some Sequence and Collaboration diagrams. The use case view is an implementation independent. Look at the system. It focuses on a high-level picture of what the system will do, without worrying about the details of how the system will do it. The use case view also includes: Actors, which are external entities that interact with the system being built. The component view includes: Component, which are physical modules of code. Component diagrams, which show the components and their relationships to each other. Packages, which are groups of related components. As with packaging classes, reuse is one of the considerations when packaging components. The main users of the Component View are those people responsible for controlling the code, and compiling and deploying the application. Deployment View: Use cases, which are high-level pieces of functionality the system will provide. Use case documentation, which details the flow through the use case, including any error handling. Use case diagrams, which show the actors, the use case, and the interactions between them. Interaction diagrams, which display the objects or classes involved in one flow through a use case.

 Packages, which are groups of use cases and/or actors. A package is a UML mechanism that helps you to group similar items together. When the project first begins, the main audience of the use case view consists of the customers, analysis and project managers. These individuals will work with the use cases, use case diagrams, and use case documentation to agree on a high-level view of the system. Logical View: Logical view provides a detailed picture of the pieces of the system, and describes how pieces inter-relate. The logical view includes, among other things, the specific classes that will be needed, the Class diagrams and the State Transition diagrams. The Logical View includes: Classes, which are the building blocks for a system. A class consists of a little bit of information. Structural (its attributes) and a little bit of behavior (its operations), grouped together. Class diagrams, which are used to view the classes in the system, their attributes and operations, are their relationships to each other. Interaction diagrams, which are used to display the classes that participate in one flow of events through a use case. Interaction diagrams in the Use Case View tend to display objects while interaction diagram in the Logical View focus instead on classes. State Transition diagrams, which show the dynamic behavior of an object. A State Transition diagram includes all of the states in which a particular object can exists. Packages, which are groups of related classes. Packaging classes can help reduced the complexity of your model. Frequently, teams take a two-pass approach to the Logical view. In the first approach, they identify analysis classes. Analysis classes are language-independent classes. The analysis classes

 Might also appear on some Interaction diagrams in the Use Case View. Once the analysis classes have been identified, the team can change each one to design class. A design class is class that has language-specific detail. The focus of the Logical View is on the logical structure of the system. In this view, you identify the pieces of the system, examine the information and behavior of the system, and examine the relationships between the pieces. Reuse is one of the main considerations here. Everyone on the team will use information from the Logical View. Primary users will be the developers and architect. Component View: The component view contains information about the code libraries, executable files, runtime libraries, and other components in your model. A components in your model. A component is a physical module of code. In Rose, components and component diagrams are displayed in the component view. The component view of the system allows you to see the relationships between the modules of code. The deployment view is concerned with the physical deployment of the system, which may differ from the logical architecture of the system. The deployment may be two-tiered. The interface may be placed on one machine, while the business and database logic are located on another machine. Other issues such as fault tolerance, network bandwidth, disaster recovery, and response time, are also handled using the Deployment view.

RECORD ORDER PLACEMENT DETAILS

A. BRIEF DESCRIPTION: This use case allows the Purchase Manager to place the Purchase order to the supplier. B. FLOW OF EVENTS: i. BASIC FLOW: This use case starts when the Purchase Manager wishes to place purchase order information in the system. This use case triggers or takes help of Check Stock Availability to verify the order placement. The system requests the user to enter the order information Supplier Code Supplier Name Item Code Item Name Quantity

CHECK STOCK AVAILABILITY a) BRIEF DESCRIPTION This use case checks for the availability of stock of a product/all products. This use case is used by Place Order use case to initiated by purchase manager and dispatcher respectively. b) FLOW OF EVENTS i. BASIC FLOW: This use case starts when the Place Order use case is requested by the user. o Before placing the order is requested by the user stock availability. o It may check the stock of a product/all products. ii. ALTERNATIVE FLOW: a. ITEM NUMBER NOT FOUND: If, an item with specified code doesnt exist, the system displays an error message. The user can then enter a different code or cancel the operation.

b. PRE CONDITIONS: The Place Order must be initiated by the user. c. POST CONDITIONS: If the use case was successful, a message will be displayed and returns to the previous state.

PREPARE BILL This use case allows the dispatcher/clerk to prepare the bill whenever a sales transaction takes place. A bill is given to the customer and other copy is given to the cashier to maintain the system. The system requests the user to enter the bill information, Item Code, Quantity. RECORD RECEIVED STOCK This use case allows the receiver manager to enter the details of the stock arrived into the New Stock file by checking with the corresponding order. FLOW OF EVENTS: 1. The user enters the order number for the corresponding transaction. 2. The system retrieves details of the order. 3. The user enters the received goods details and asks to check. If there is any difference, the differences are highlighted. 5. Then the user updates New Stock file which includes Transaction_No

Item_Code Quantity Brand Cost MAINTAIN ITEM INFORMATION

This use case allows the stock manager to maintain item information in the system. This includes adding modifying, deleting item from the system. MAINTAIN SUPPLIER INFORMATION This use case allows the purchase manager to maintain supplier information in the system. This including adding, modifying, deleting, supplier from the system. USECASE DIAGRAMS UML DIAGRAMS OF SUPERMARKET USE CASE DIAGRAM FOR CUSTOMER GENERALIZATION

Non Regular Customer Customer

Regular Customer

Acc No

USE CASE DIAGRAM FOR CUSTOMER TRANSACTION

Transaction

Customer Boy

Sales

USE CASE DIAGRAM FOR BILL PREPARATION

Sends List System

Sales Boy Operator

USE CASE DIAGRAM FOR BILL PAYMENT

Prepare bill System Dispatch to Verifies Dispatch bill to cashier Bill 1

bill System customer Operator

Bill 2 Customer Pays amount

Pays Cashier

USE CASE DIAGRAM FOR SYSTEM UPDATION

Pays Cashier

System Shop Owner

USE CASE DIAGRAM FOR ORDERING GOODS

System availability/ received stock place order Order Goods Shop Owner Dealer check stock record

CLASS DIAGRAM CLASS DIAGRAM FOR CUSTOMER GENERALIZATION

Daily Custome r Item List Order Items () Receive Items

Customer Name Customer Type Acc No Item List Order Items ( ) Receive Item ( ) Verification ( ) Bill Paying ( ) Reporting ( )

Regular Customer Name Acc No Item List Order Item ( ) Receiver Item ( ) Pay Bill ( )

Customer CLASS DIAGRAM FOR CUSTOMER TRANSACTION Name Customer Type Acc No Item List Order Items ( ) Receive Items ( ) Verification (

Sales Boy Checks Items List Issuing ( ) Receiving ( )

CLASS DIAGRAM FOR BILL PREPARATION

Sales Boy Checks Item List Issuing () Receiving

Billing Item List Bill Amount

CLASS DIAGRAM FOR BILL PAYMENT

System Name Type Details Customer Details () Dealer Details () Other Details ()

Billing Item List Bill Amount Prepared Bill ()

Customer Name Customer Type Acc No Item List

Cashier Bill Amount Receiving Bill () Receive Cash ()

Shop Owner Calculation Item List

Order Items () CLASS DIAGRAM FOR SYSTEM UPDATION Receive System Items () Issuing () Verification Name Receiving () Type Verify Acc No () Details Verify Goods () Order Goods () Customer Recording () Details () Pay Bill () Dealer Details () Other Details ()

Cashier Bill Amount Receiving Bill () Receiving Cash ()

Shop Owner Calculation Item FOR CLASS DIAGRAMList ORDERING GOODS Issuing () Receiving () Verify Acc No () Verify Goods () Order Goods () Recording () Dealer

Transaction Dispatch Items () Receive Order ()

SEQUENCE DIAGRAMS SEQUENCE DIAGRAM FOR CUSTOMER VALIDATION

:Customer Owner :System Enter the shop

:Shop

Check the Customer type Confirm the type of Customer Checks balance if it is a Regular customer Returns the details of Customer Checks to allow/reject

Allow the customer to place the order

SEQUENCE DIAGRAM FOR CUSTOMER TRANSACTION

: Customer : Sales Boy place order

checks

delivers items

checks

SEQUENCE DIAGRAM FOR BILL PAYMENT

: Customer Sales Boy : Billing dispatches : Cashier

prepares bill

bill to customer bill to cashier

verifies

pays

SEQUENCE DIAGRAM FOR SYSTEM UPDATION

: Cashier : System : Shop Owner updates

Checks record