Sunteți pe pagina 1din 5

AIM: Creation of domain model for Integration of sound signature using graphical password authentication system.

THOERY: ER DIAGRAM:

It is a graphical representation of entities and their relationships to each other, typically used in computing in regard to the organization of data within databases or information systems. An entity is a piece of data-an objector concept about which data is stored. A relationship is how the data is shared between entities. There are three types of relationships between entities:

one-to-one: one instance of an entity (A) is associated with one other instance of another entity (B). For here, in a Administer and is associated with only one Log in & Registration details. one-to-many: one instance of an entity (A) is associated with zero, one or many instances of another entity (B), but for one instance of entity B there is only one instance

of entity A. For here, Log in & Registration details is associated with many different client(user).

many-to-many: one instance of an entity (A) is associated with one, zero or many instances of another entity (B), and one instance of entity B is associated with one, zero or many instances of entity A. For here, upload & download is associated with many instances of upload & download with it.

DFD DIAGRAM:

Data Flow Diagrams (DFD) helps us in identifying existing business processes. It is a technique we benefit from particularly before we go through business process re-engineering. At its simplest, a data flow diagram looks at how data flows through a system. It concerns things like where the data will come from and go to as well as where it will be stored. But you won't

find information about the processing timing .We usually begin with drawing a context diagram, a simple representation of the whole system. To elaborate further from that, we drill down to a level 1 diagram with additional information about the major functions of the system. This could continue to evolve to become a level 2 diagram when further analysis is required. Progression to level 3, 4 and so on is possible but anything beyond level 3 is not very common. FLOW CHART DIAGRAM:

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting them with arrows. This diagrammatic representation can give a step-by-step solution to a given problem. Process operations are represented in these boxes, and arrows connecting them represent flow of control. Data flows are

not typically represented in a flowchart, in contrast with data flow diagrams; rather, they are implied by the sequencing of operations. CLASS DIAGRAM:

The class diagram is the main building block of object oriented modelling. It is used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modeling.[1] The classes in a class diagram represent both the main objects, interactions in the application and the classes to be programmed. In the diagram, classes are represented with boxes which contain three parts:

The upper part holds the name of the class The middle part contains the attributes of the class The bottom part gives the methods or operations the class can take or undertake In the design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the static relations between those objects. With detailed modeling, the classes of the conceptual design are often split into a number of subclasses.

DOMAIN MODEL: A domain model in problem solving and software engineering is a conceptual model of all the topics related to a specific problem. It describes the various entities, their attributes, roles, and relationships, plus the constraints that govern the problem domain. The domain model is created in order to represent the vocabulary and key concepts of the problem domain. The domain model also identifies the relationships among all the entities within the scope of the problem domain, and commonly identifies their attributes. A domain model that encapsulates methods within the entities is more properly associated with object oriented models. The domain model provides a structural view of the domain that can be complemented by other dynamic views, such as use case models. An important advantage of a domain model is that it describes and constrains the scope of the problem domain. The domain model can be effectively used to verify and validate the understanding of the problem domain among various stakeholders. It defines a vocabulary and is helpful as a communication tool. It can add precision and focus to discussion among the business team as well as between the technical and business teams. CONCLUSION: Hence we studied domain model for Highly secured crypto iris based authentication system

S-ar putea să vă placă și