Inventory Management System In Vb.Net Project Report - Part 4

Get Our Latest Interview Questions: Aptitude, Reasoning, English, GD, HR-PI

ENTITY RELATIONSHIP DIAGRAM:
ER  models are tools used in analysis to describe the data requirements and assumptions in the system from a top-down perspective. They also set the stage for the design of databases later on in the SDLC.
There are three basic elements in ER models:
Entities are the "things" about which we seek information.
Attributes are the data we collect about the entities.
Relationships provide the structure needed to draw information from multiple entities.

ENTITY is a Real-world object distinguishable from other objects
    (e.g a student, car, job, subject, building ...)
    An entity is described using a set of attributes
    The same entity may have different prominence in different UoDs
    Represented by a rectangle in E-R diagrams
    Entity Type
    A collection of entities that share common properties or characteristics.
    Attribute
    A named property or characteristic of an entity that is of interest to an organization
    Attribute Types
There are different types of attributes
    – Composite Vs. Simple Attributes
    – Single-valued Vs. Multi-valued Attributes
    – Derived Vs. Stored Attributes


 INTRODUCTION TO UNIFIED MODELING LANGUAGE (UML)
Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group. It was first added to the list of OMG adopted technologies in 1997, and has since become the industry standard for modeling software-intensive systems.
UML includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems. The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development.[2] UML offers a standard way to visualize a system's architectural blueprints, including elements such as:
•    activities
•    actors
•    business processes
•    database schemas
•    (logical) components
•    programming language statements
•    reusable software components.[3]
UML combines techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies

 The Class Diagram
The class diagram is core to object-oriented design.  It describes the types of objects in the system and the static relationships between them.
Packages
Packages allow you to break up a large number of objects into related groupings.  In many object oriented languages (such as Java), packages are used to provide scope and division to classes and interfaces.  In the UML, packages serve a similar, but broader purpose.





Any UML diagram in Visual Case can have packages on them.  Each package can contain any type and any number of other UML diagrams, as well as interfaces and classes.

Classes
The core element of the class diagram is the class.  In an object oriented system, classes are used to represent entities within the system; entities that often relate to real world objects.

The Contact class above is an example of a simple class that stores location information. 
Classes are divided into three sections:
Top: The name, package and stereotype are shown in the upper section of the class.  In Visual Case, classes shown on a diagram that do not belong to the same package as the diagram are shown with their entire path name.  You can optionally assign a stereotype to a class.
Centre: The centre section contains the attributes of the class.
Bottom: In the lower section are the operations that can be performed on the class.
On any Visual Case class diagram, you can optionally shown and hide both the attribute and operations sections of all the classes or individual classes.  This is useful as often you will want your class diagrams to highlight specific constructs of your system that superfluous information only serves to clutter and confuse.
Attributes
An attribute is a property of a class.  In the example above, we are told that a Contact has an address, a city, a province, a country and a postal code.  It is generally understood that when implementing the class, functionality is provided to set and retrieve the information stored in attributes.  Methods to set and retrieve attribute data are often called accessor methods (also getting and setting methods) and need not be shown in your model as they are usually inferred.
The format for attributes is:
visibility name: type = defaultValue
The visibility is as follows:
-    Private
+    Public
#    Protected
~    Package
In object oriented design, it is generally preferred to keep most attributes private as the accessor methods allow you to control access to the data.  The most common exception to this preference are constants.
In addition to the name, visibility, datatype and default value, Visual Case allows you to specify the following properties for an attribute:
Array: you can set an attribute to be treated as an array of attributes; shown with square braces [ ] beside the name.
Static: attributes that are static only exist once for all instances of the class.  In the example above, if we set city to be static, any time we used the Contact class the city attribute would always have the same value.
Final: if an attribute is declared final, it's value cannot be changed.  The attribute is a constant.
Operations
The operations listed in a class represent the functions or tasks that can be performed on the data in the class.

In the List class above, there is one attribute (a private array of Objects) and three operations.
The format for operations is:
visibility name (parameters): type
The format is very similar to that of the attribute except with the removal of a default value and the addition of parameters.
Parameters take the format:
direction name: type = default value
The direction can be one of in, out, inout or it can be unspecified.
In Visual Case you can show and hide the parameter list for a class or all classes on a diagram.  If the list is hidden and an operation has parameters, three dots are shown (...) to indicate that parameters exist, but are hidden.  Sometimes operations have numerous parameters that need not be shown all the time.



CONCLUSION
The objective of this project was to build a program for maintaining the details of all Supply Order .The system developed is able to meet all the basic requirements. It will provide the facility to the user so that they can keep tracks of all the equipments being supplied. The management of the Inventory will be also benefited by the proposed system, as it will automate the whole supply procedure, which will reduce the workload. The security of the system is also one of the prime concerns.
There is always a room for improvement in any software, however efficient the system may be. The important thing is that the system should be flexible enough for future modifications. The system has been factored into different modules to make system adapt to the further changes. Every effort has been made to cover all user requirements and make it user friendly.
Goal achieved: The System is able provide the interface to the user so that he can replicate his desired data. .
User friendliness: Though the most part of the system is supposed to act in the background, efforts have been made to make the foreground interaction with user as smooth as possible. Also the integration of the system with Inventory Management project has been kept in mind throughout the development phase.