Docstoc

CMS4

Document Sample
CMS4 Powered By Docstoc
					CMS USING RFID                                                          SYSTEM DESIGN


CHAPTER-4

                               SYSTEM DESIGN

4.1 Introduction


       Design is a meaningful engineering representation of something that is to be
built. Software gritty design is a process through which the requirements are
translated into a representation of the software. Design is the place where quality is
fostered in software engineering.
       Design is the perfect way to accurately translate a customer’s requirement in
to a finished software product. Design creates a representation or model, provides
detail about software data structure, architecture, interfaces and components that are
necessary to implement a system.
       This chapter discusses about the design part of the project. Here in this
document the various UML diagrams that are used for the implementation of the
project are discussed




4.2 Design Principles


4.2.1 Objectives of Design
System design is like a blue print for a building, it specifies all the features that are to
be in the finished product. Design states how to accomplish objectives determined in
the analysis phase.

4.2.2 Logical Design
The design of an information system produces the details that state how a system will
meet the requirements identified during systems analysis.

4.2.3 Physical Design
The process of developing program software is referred to as physical design. In this
stage the logical design elements are specified which supports the business activities.
The physical design ensures the system features to meet the user requirements.

Dept of IT/KEC, 2010-11                                                                  21
CMS USING RFID                                                    SYSTEM DESIGN




4.3 SDLC PROCESS MODEL


This document play a vital role in the development of life cycle (SDLC) as it
describes the complete requirement of the system. It means for use by developers and
will be the basic during testing phase. Any changes made to the requirements in the
future will have to go through formal change approval process.




PROCESS MODEL USED WITH JUSTIFICATION

SDLC (Spiral Model):




                             Figures 4.3: Spiral Model

SDLC is nothing but Software Development Life Cycle. It is a standard which is used
by software industry to develop good software.

       The next step is determined by remaining risks. For example, its performance
or user-interface risks are considered more important than the program development

Dept of IT/KEC, 2010-11                                                           22
CMS USING RFID                                                       SYSTEM DESIGN


risks. The next step may be evolutionary development that involves developing a
more detailed prototype for resolving the risks. On the other hand, if the program
development risks dominate and previous prototypes have resolved all the user-
interface and performance risks; the next step will follow the basic waterfall
approach.

       The risk driven nature of the spiral model allows it to accommodate any
mixture of specification-oriented, prototype-oriented, simulation-oriented or some
other approach. An important feature of the model is that each cycle of the spiral is
completed by a review, which covers all the products developed during that cycle,
including plans for the next cycle. The spiral model works for developed as well as
enhancement projects.


Spiral Model Description


The development spiral consists of four quadrants as shown in the figure above

Quadrant 1: Determine objectives, alternatives, and constraints.

Quadrant 2: Evaluate alternatives, identify, resolve risks.

Quadrant 3: Develop, verify, next-level product.

Quadrant 4: Plan next phases.

Although the spiral, as depicted, is oriented toward software development, the concept
is equally applicable to systems, hardware, and training, for example. To better
understand the scope of each spiral development quadrant, let’s briefly address each
one.


Quadrant 1: Determine Objectives, Alternatives, and Constraints


Activities performed in this quadrant include:

       1.      Establish an understanding of the system or product objectives—
       namely performance, functionality, and ability to accommodate change.

Dept of IT/KEC, 2010-11                                                              23
CMS USING RFID                                                       SYSTEM DESIGN


       2.       Investigate   implementation    alternatives—namely     design,   reuse,
       procure, and procure/ modify
       3.       Investigate   constraints   imposed    on    the   alternatives—namely
       technology, cost, schedule, support, and risk. Once the system or product’s
       objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate
       alternatives, identify, and resolve risks) is performed.


Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks


       Engineering activities performed in this quadrant select an alternative
approach that best satisfies technical, technology, cost, schedule, support, and risk
constraints. The focus here is on risk mitigation. Each alternative is investigated and
prototyped to reduce the risk associated with the development decisions. Boehm
describes these activities as follows:

. . . This may involve prototyping, simulation, benchmarking, reference checking,
administering                                                                      user
questionnaires, analytic modeling, or combinations of these and other risk resolution
techniques.

       The outcome of the evaluation determines the next course of action. If critical
operational and/or technical issues (COIs/CTIs) such as performance and
interoperability (i.e., external and internal) risks remain, more detailed prototyping
may need to be added before progressing to the next quadrant. Dr. Boehm notes that if
the alternative chosen is “operationally useful and robust enough to serve as a low-
risk base for future product evolution, the subsequent risk-driven steps would be the
evolving series of evolutionary prototypes going toward the right (hand side of the
graphic) . . . the option of writing specifications would be addressed but not
exercised.” This brings us to Quadrant 3.


Quadrant 3: Develop, Verify, Next-Level Product


If a determination is made that the previous prototyping efforts have resolved the
COIs/CTIs, activities to develop, verify, next-level product are performed. As a result,

Dept of IT/KEC, 2010-11                                                              24
CMS USING RFID                                                         SYSTEM DESIGN


the basic “waterfall” approach may be employed—meaning concept of operations,
design, development, integration, and test of the next system or product iteration. If
appropriate, incremental development approaches may also be applicable.


Quadrant 4: Plan Next Phases


The spiral development model has one characteristic that is common to all models—
the need for advanced technical planning and multidisciplinary reviews at critical
staging or control points. Each cycle of the model culminates with a technical review
that assesses the status, progress, maturity, merits, risk, of development efforts to date;
resolves critical operational and/or technical issues (COIs/CTIs); and reviews plans
and identifies COIs/CTIs to be resolved for the next iteration of the spiral.




Dept of IT/KEC, 2010-11                                                                 25
CMS USING RFID                                                                SYSTEM DESIGN


4.4 (a) Flow Chart (System Architecture)


                              Start



                         Admin Login




                      Enter username and
                           password




                              If                No
                            matche
                              d


                                   Yes




       Create              Update                         Delete



                        retrieve id from              retrieve id from
  Enter the details         the card                      the card




                             If            No              If            No
                           matche                        matche
                             d                             d

                                Yes                           Yes

                          Change
                          details                    Delete details




                         Database




                            Stop




                                         Figure 4.4 (a) System Architecture




Dept of IT/KEC, 2010-11                                                                  26
CMS USING RFID                                               SYSTEM DESIGN


4.4 (b) Card Process

              Start




           Enter card



             Click
          department




               If         No
             matche                 Display invalid
               d


                  Yes


    Display message welcome
     to the CSE department



             Stop




                              Figures 4.4 (b) Card process




Dept of IT/KEC, 2010-11                                                 27
CMS USING RFID                                                       SYSTEM DESIGN




4.5 DATA FLOW DIAGRAMS

A graphical tool used to describe and analyze the moment of data through a system
manual or automated including the process, stores of data, and delays in the system.
Data Flow Diagrams are the central tool and the basis from which other components
are developed. The transformation of data from input to output, through processes,
may be described logically and independently of the physical components associated
with the system. The DFD is also know as a data flow graph or a bubble chart.
DFDs are the model of the proposed system. They clearly should show the
requirements on which the new system should be built. Later during design activity
this is taken as the basis for drawing the system’s structure charts. The Basic Notation
used to create a DFD’s are as follows:
1. Dataflow: Data move in a specific direction from an origin to a destination.




2. Process: People, procedures, or devices that use or produce (Transform) Data.
The physical component is not identified.




3. Source: External sources or destination of data, which may be People, programs,
organizations or other entities.




4. Data Store: Here data are stored or referenced by a process in the System.




Dept of IT/KEC, 2010-11                                                              28
CMS USING RFID                                                     SYSTEM DESIGN




4.5.1 Data Flow Diagram (DFD)


1. Admin Login


                                               1
     Admin              Login
                                            Admin
                                             Page



                           1.1
                                                              1.3
                          Create
                                              1.2            Delete

                                            Update



                   Figures 4.5.1(a) Data Flow Diagram for Login


2.Admin Login:Create


                                             1.1
     Admin             Login
                                            Create




                                   Store    1.1.1
                   database                Enter the
                                            details




                  Figures 4.5.1 (b) Data Flow Diagram for Create




Dept of IT/KEC, 2010-11                                                       29
CMS USING RFID                                                         SYSTEM DESIGN


  3. Admin Login : Update



                                                       1.2
   Admin                   Login
                                                     Update




                                                     1.2.1
                                              retrieve id
                                               from the
                                                 card




                                                      1.2.2
                                   Store
                       database                      Change
                                                     details



                     Figures 4.5.1 (c): Data Flow Diagram for Update


 4. Admin Login : Delete


                                            1.3
   Admin               Login
                                           Delete




                                           1.3.1
                                      retrieve id
                                       from the
                                         card




                                           1.3.2
                     database              delete
                                           details




                     Figures 4.5.1 (d) Data Flow Diagram for Update



Dept of IT/KEC, 2010-11                                                           30
CMS USING RFID                                                       SYSTEM DESIGN




4.6 UML DIAGRAMS

       A Successful software organization is one that consistency deploys quality
software that meets the needs of its users. An organization which can deploy the
software in a timely and predictable fashion, with an effective use of resources will
have a substantial business.
       Modeling is a central part of all activities that lead up to the deployment of good
software. The UML gives us the standard way to write system’s blue prints that covers
the conceptual things
   The Unified Modeling Language (UML) is a graphical language for visualizing,
specifying, constructing and documenting the artifacts of a software intensive system.
Modeling is a central part of all the activities that lead up to the deployment of good
software. We build models to communicate the desired structure and behavior of our
system.
   Design Using UML Diagrams


               A diagram is the graphical presentation of a set of elements most often
rendered as a connected graph of vertices (things) and arcs (relationships). You draw
diagrams to visualize a system from different perspectives, so a diagram represents an
elided view of the elements that make up a system. The same element may appear in
all diagrams, only a few diagrams, or in no diagrams at all. In theory, a diagram may
contain any combination of things and relationships.       For this reason, the UML
includes nine such diagrams.

            1. Use case Diagram

            2. Class Diagram

            3. Interaction Diagram

                 3.1 Sequence Diagram

                 3.2 Collaboration Diagram

          4. State chart Diagram

Dept of IT/KEC, 2010-11                                                              31
CMS USING RFID                                                      SYSTEM DESIGN


           5. Activity Diagram

           6. Component Diagram

           7. Deployment Diagram


4.6.1. Use Case Diagram

(A) Overview of Collaboration Diagram

A Use Case Diagram shows a set of use cases and actors and their relationships. Use
case diagrams address the static use case view of a system. A Use Case Diagram is a
just a special kind of diagram and shares the same common properties as do all other
diagrams but it differs from its contents.
 Contents:
Use case diagram commonly contains the following things:
            Use Case
            Actor
            Relationships


Notations used in Use Case Diagram



                                                      Actor




                                                      Use Case



                                                      Association




Dept of IT/KEC, 2010-11                                                          32
CMS USING RFID                                                             SYSTEM DESIGN




                                Login


                                                    Verification of data
                               Create


                                                                               student
        Admin
                               Update
                                                      Correct details




                               Delete




                           Figure 4.6.1 UseCase Diagram


4.6.2 Class Diagram
(A) Overview of Collaboration Diagram

        A Class Diagram shows a set of classes, interfaces and collaborations and
their relationships. These diagrams are the most common diagram found in modeling
object-oriented systems. A Class Diagram is just like as special kind of diagram and
shares the same properties as all other diagrams. But it differs from all other diagrams
in its contents.
 Contents

    Class diagram commonly contains the following things

             Classes
             Interfaces
             Collaborations
             Dependency, generalization and association relationships.




Dept of IT/KEC, 2010-11                                                                  33
CMS USING RFID                                                    SYSTEM DESIGN




                          Figure 4.6.2: Class diagram

4.6.3. Sequence Diagram:

(A) Overview of Collaboration Diagram

      The Sequence Diagram is an interaction diagram that emphasizes the time
ordering of messages. The Sequence Diagram differs from others in its contents.
Sequence Diagram commonly contains objects, links and messages.
Notations used in Sequence Diagram

                                                Object


                                                Time Line


                                                Focus of Control




Dept of IT/KEC, 2010-11                                                      34
CMS USING RFID                                                        SYSTEM DESIGN



      Student                            Admin                          Database

                    Insert the card               Search the Database
                                                                              verify



                   Grant Permission
                   Request the form
                                                    add the details


                    Accept the form




4.6.4 Collaboration diagram

(A) Overview of Collaboration Diagram

       A Collaboration diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive messages. A Collaboration
diagram shows a set of object’s links among those objects, messages sent and received
by those objects. Collaboration diagrams are used to illustrate the Dynamic View of a
system.

Notations used in Collaboration Diagram


                                                 Object


                                                 Relation


                                                 Direction




Dept of IT/KEC, 2010-11                                                                35
CMS USING RFID                                                        SYSTEM DESIGN


                                1: Insert the card
                               5: Request the form
     Student                                                              Admin


                               4: Grant Permission
                                7: Accept the form




                                     2: Search the Database
                                        6: add the details
            3: verify




            Databas
               e




4.6.5 Component diagram


(A) Overview of Component Diagram

       In    the Unified    Modeling     Language,     a component      diagram depicts
how components are wired together to form larger components and or software
systems. They are used to illustrate the structure of arbitrarily complex systems.

Notations used in Collaboration Diagram

                                                   Component



                                                   Package



                                                   New program
                                                   specification




Dept of IT/KEC, 2010-11                                                              36
CMS USING RFID                                                          SYSTEM DESIGN



                            USER                            Staff




    Admin

                                            RFID                        Hardware
                                            Reader                      device




                          Figure 4.6.5 : Compontent Diagarm


4.7 E-R DIAGRAM


       The entity-relationship (ER) data model allows us to describe the data
involved in a real-world enterprise in terms of objects and their relationships and is
widely used to develop an initial database design. The ER model is most relevant to:
               Requirements Analysis

               Conceptual Database design

               Logical database design.

The E-R diagram mainly composed of entities, attributes and their relationships. An
entity is an object in the real world that is distinguishable from other objects. It is
often useful to identify a collection of similar entities. Such a collection is called an
entity set. An entity is described using a set of attributes. All entities in a given entity
set have the same attributes.

A relationship is an association among two or more entities. A set of similar
relationships is said to be relationship. The multiplicities in a ER-diagram can be of
many types:

               Many to many relationships

Dept of IT/KEC, 2010-11                                                                  37
CMS USING RFID                                                      SYSTEM DESIGN


              One to many relationships
              One to one relationships




                             -       Entity

                                 -    Relation Ship

                                 -    Attribute

                             -       Connection

                                 -    Primary Key




4.8 Database Tables

       Data base is an organized collection of logically related data. Databases are
used to store, manipulate and retrieve data in nearly every type of organization
including business, healthcare, education, government and libraries. Some of the
terms associated with the database tables are:

Data: Known facts of any object that can be recorded and stored on computer media.

Record: Set of inter-related data of any object

Information: Data that have been processed in such a way as to increase the
knowledge of the person who uses the data.




The following tables are used in the development of this project.



 Admin
     Login
     Create
     Update

Dept of IT/KEC, 2010-11                                                          38
CMS USING RFID                                                   SYSTEM DESIGN


             Delete

Login

Functionality             Component           Validation
Username                  Text                Editable
                                              Alphabets
                                              Numbers
                                              No special character
                                              Should not start with number
                                              Not null
                                              Should have minimum 7 characters
                                              No space
Password                  Password field      Editable
                                              Alphabets
                                              Numbers
                                              Special character
                                              Not null
                                              Minimum 6 characters
Login                     Button


                              Table 4.8 (a) Login

Create


Functionality             Component           Validation
Name                      Text Field          Editable
                                              Not null
                                              No space
                                              No special character
                                              No number
                                              Minimum 3 character
                                              Only Alphabets
Id                        Text Field          Non-Editable
Department                Text Field          Editable
                                              Not null
                                              Alphabets
                                              Numbers
Designation               Combo box           Student
                                              Non-teaching Staff
                                              Lecturer
                                              HOD

Dept of IT/KEC, 2010-11                                                          39
CMS USING RFID                                                   SYSTEM DESIGN


                                              Professor
                                              Admin
Permissions to Dept       Check box           CIVIL
                                              IT
                                              CSE
                                              ADMINISTRATION
                                              ECE
                                              MECH
                                              EEE
Assign                    Button
Exit                      Button

                              Table 4.8 (b) Create

Update

Functionality             Component           Validation
Id                        Text Field          Non-Editable
Get                       Button
Name                      Text Field          Editable
                                              Not null
                                              No space
                                              No special character
                                              No number
                                              Minimum 3 character
                                              Only Alphabets
Department                Text Field          Editable
                                              Not null
                                              Alphabets
                                              Numbers
Designation               Combo box           Student
                                              Non-teaching Staff
                                              Lecturer
                                              HOD
                                              Professor
                                              Admin
Permissions to Dept       Check box           CIVIL
                                              IT
                                              CSE
                                              ADMINISTRATION
                                              ECE
                                              MECH
                                              EEE

Dept of IT/KEC, 2010-11                                                     40
CMS USING RFID                                                     SYSTEM DESIGN


Update/Save                Button
Exit                       Button
                               Table 4.8 (c) Update

Delete

Functionality              Component            Validation
Id                         Text Field           Non-Editable
Delete                     Button
Exit                       Button

                               Table 4.8 (d) Delete

Security Officer
Card process

Functionality              Component            Validation
Id                         Text Field           Non-Editable
ADMINISTRATION             Button
CSE                        Button
IT                         Button
MECH                       Button
CIVIL                      Button
ECE                        Button
EEE                        Button
Exit                       Button


                   Table 4.8 (e) Security Officer (card Process)




Dept of IT/KEC, 2010-11                                                       41

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:4/27/2012
language:English
pages:21
Description: Campus Management System Document