INTRODUCTION

Name/ Title of the Project: - University Management System (Online Website) In University Management System, All Colleges, students, staff members and administrative staff have their own user accounts and passwords. Each can view his account information. She/he can edit only their personal information not regarding with college and student information. Rather than only management there will be some other activities also like Online Aptitude Test, General Knowledge Questions. Desired links should be on the web pages such rediffmail, yahoomail, Gmail, and many more website links for downloading and viewing book on various subjects. Backgrounds: University is having a large no of Students, Colleges and their staff, teaching as well as nonteaching. University is having a big problem for maintaining their records such that their staff attendance, their College Records, staff salary, their duties, result of exams, merit list etc. Manual Databases were the older one method to handle such these problems. But now days these types of manual databases cant be so helpful in reducing the complexity. We have to implement new technologies with the time so we can make our system better. There will be a contact us and feedback form available on the site. By filling up that form he/she may contact to administrator of website. This all information of contact us and feedback will be stored in databases that the administrator can see as weekly or daily basis.

Purpose, Scope and Applicability of the Project (Web Site):Web design presents a challenge few have mastered. We have all used web sites that provide us with what we are looking for, and many more that don't, but what makes some sites more appealing than others? Following points are the importance of having clearly defined and prioritized objectives when developing web sites. So what is the purpose, or objectives of a web site? Objective should be to help students, colleges and staff. Help them buy something they need. Help them find Information. Help them to talk to the University Mgt.

There are 4 ways for helping users, 4 web objectives, as discussed below. Help them find Information - Serve Help them to Save money and time - Save Help them to talk to the Organization - Speak Help them to enjoy a great web experience Sizzle Design priorities do vary. For example some sites focus on service, other sites focus on sales. Clarifying the key objectives, purpose or priorities helps to determine the content and structure of the site. This site will focus on services given to its users and have clear objectives. Asking "How can my web site help more to the website users?" through suggestion and feedback form. To review designed websites will: Ask how the site helps their Users. Rate their services.

And also ensures: Quality Contents Easy to Use Quick Downloads Frequent Update.

Students will be able to: Learn about the University. See Gallery Photographs Access a glossary of content area terms Link to related sites Notice Boards

Teachers will be able to access: Lesson plans, Syllabus. Find related college websites Titles for related trade literature Suggestions for lesson extensions, field trips and Notice Boards.

Hardware & Software Requirements:The first step in the system development life cycle is the identification of

the needs. This is a users request to change, improve or enhance an existing system. Because there is likely to be a stream of such requests, standard procedures

must be established to deal with them. The preliminary investigation is one way of handling this. The objective is to determine whether the request is valid and feasible before a recommendation is reached to do nothing, improve or modify the existing system or build a new one.

In my project, there are very simple requirements in the computer. To achieve my purpose my hardware and software requirements one as follows:Hardware Requirements The basic minimum hardware requirement for operating this project efficiency is: CPU Type Processor Speed RAM Memory
3

Specification Pentium 166M Hz or up 266 MHZ or more 256 MB or more Cache 512 KB or more

Peripherals Type Monitor Mouse Keyboard Printer Storage Media Type Hard Disk Floppy Disk CD -ROM Specification 1.2 GB or more 1.44MB 48x/52x Specification VGA Color Serial Standard Color/black & white

Software Requirements: The software requirements for this project are:-

Type Operating System Front End Back End

Specification Windows XP, Window Vista, Window 7 Microsoft Visual Studio 2008,Photoshop MySQL Server, Microsoft Access

SYSTEM STUDY AND ANALYSIS

ANALYSIS PHASE The analysis phase defines the requirements of the system, independent of how these requirements will be accomplished. This phase defines the problem that the customer is trying to solve. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details. The requirement document may be expressed in a formal language based on mathematical logic. Traditionally, the requirement document is written in English or another written language. The requirement document does not specify the architectural or implementation details, but specifies information at the higher level of description. The problem statement, the customer's expectations, and the criteria for success are examples of high-level descriptions. There is a fuzzy line between high-level descriptions and low-level details. Sometimes, if an exact engineering detail needs to be specified, this detail will also appear in the requirement document. This is the exception and should not be the rule. These exceptions occur for many reasons including maintaining the consistency with other established systems, availability of particular options, customer's demands, and to establish, at the requirement level, a particular architecture vision.

DRAWBACKS OF THE EXISTING SYSTEM

As we know the manual processing is quite tedious, time consuming, less accurate in comparison to computerized processing. Obviously the present system is not is exception consultant encountering all the above problems.
1. Time consuming. 2. It is very tedious. 3. All information is not placed separately. 4. Lot of paper work. 5. Slow data processing. 6. Not user-friendly environment. 7. It is difficult to found records due file management system. 5

FEASIBILTY STUDY
As feasibility study is the test of the system proposal according to its work ability, impact on the organization, ability to meet user needs and effective use of resource. It focuses on three major questions: 1. What are user's demonstrable needs and how does a candidate system meet them. 2. What resources are available for a given candidate system? Is the problem worth solving? 3. What is likely impact of the candidate system on the organization? Each of these questions revolves around investigation evaluation of the problem, identification and description of the candidates system, specification of performance and the cost of each system and final selection of the best system. The objective of the feasibility study is not to solve the problem, but to acquire a sense of its scope. During the study, the problem definition is crystallized and various aspects of the problem to be included in the system are determined. Consequently costs and benefits are estimated with greater accuracy at this stage. The feasibility study is conducted to see whether the proposed system is feasible or not, means that the company is able to beer all the expenses and affects of the proposed system that the company will have after the system is installed. There are four types of feasibility study: 1. Economical Feasibility 2. Technical Feasibility 3. Behavioral Feasibility 4. Operational Feasibility

ECONOMICAL FEASIBILITY Economical feasibility is the most frequently used method for evaluating the effectiveness of the employee system, commonly known as the cost benefit analysis, the procedure is to determine the benefit and saving that are expected from an employee system and compare them with costs. If benefits outweigh costs then the decision is made to design and implement the system. Our proposed system needs only minimum of two computers one being the actual working node other the backend MS-Access server and LAN. First we look at the benefits.

The system is to be developed will be used in the organization for employee management. The benefit list includes: Easy access for the user Security in data while access, creation and modification. Distribution of file resources

And now looking at the cost of the project, it was found that the whole project would take less effort and also the basic requirements for the system was fulfilled by the existing resources. This led to the conclusion that the project was economically feasible.

TECHNICAL FEASIBILITY Technical feasibility centres around the hardware and software required and to what extent these will support our system along with the technical expertise required. Now looking at the technical aspect of the system to be developed, it was found that at least two computers will be needed which should be in LAN. Most of these requirements are satisfied by the existing resources available in the company while other can be easily satisfied.

BEHAVIORAL FEASIBILITY Computers are known to facilitate change and people are usually resistant to change. In determining the behavioral feasibility, we make an estimate of how strong a reaction will be the user staff make towards the development of the computerized system and try to keep the user response positive. In case of airline reservation there is a strong social aspect. In the organization there is always a situation where there a need of various type of information regarding the trains, so the staff is openly ready to accept the new system without any hesitation. The system could be used to getting the promotion information, training information and personal information about the flights.

OPERATIONAL FEASIBILITY In operational feasibility, it is estimated that the system will use if it is developed and implemented. Computers are known to facilitate change and people are usually resistant to change. So an estimate is made of how strong a reaction will the user staff make towards the development of the computerized system. Our proposed system is aimed to simplify the job without bringing much change in way of working of existing system.

ADVANTAGES OF THE PROPOSED SYSTEM

In new computerized system I tried to give these facilities. 1. Manually system changes into computerized system. 2. Friendly user interface. 3. Time saving. 4. Save paper work. 5. Connecting to database so we use different type of queries, data report. 6. Give facility of different type of inquiry. 7. Formatted data. 8. Datas are easily approachable.

PROJECT PLANNING
Once the project is found to be feasible, software project managers undertake project planning. Project planning is undertaken and completed even before any development activity starts. Project planning consists of the following essential activities: 1. Estimation: The following project attributes have to be estimated. i. ii. iii. Cost How much is it going to cost to develop the software? Duration How long is it going to take to develop the product? Effort How much effort would be required to develop the product?

The effectiveness of all other planning activities such as scheduling and staffing are based on the accuracy of these estimations. 2. Scheduling: After the estimations are made, the schedules for manpower and other resources have to be developed.
8

3. Staffing: staff organization and staffing plans have to be made. 4. Risk management: Risk identification, analysis, and abatement planning have to be done. 5. Miscellaneous plans: several other plans such as quality assurance plan, configuration management plan, etc. have to be done. Size is the most fundamental parmeter based on which all other estimates are made.

SYSTEM DESIGN
DESIGN PHASE In the design phase the architecture is established. This phase starts with the requirement document delivered by the requirement phase and maps the requirements into an architecture. The architecture defines the components, their interfaces and behaviors. The deliverable design document is the architecture. The design document describes a plan to implement the requirements. This phase represents the ``how'' phase. Details on computer programming languages and environments, machines, packages, application architecture, distributed architecture layering, memory size, platform, algorithms, data structures, global type definitions, interfaces, and many other engineering details are established. The design may include the usage of existing components. The Design Phase: What are the plans? Phase Design Deliverable Architecture Document Implementation Plan Critical Priority Analysis Performance Analysis Test Plan

The architectural team can now expand upon the information established in the requirement document. Using the typical and atypical scenarios provided from the requirement document,
9

performance trade-offs can be accomplished as well as complexity of implementation tradeoffs. Obviously, if an action is done many times, it needs to be done correctly and efficiently. A seldom used action needs to be implemented correctly, but it is not obvious what level of performance is required. The requirement document must guide this decision process. An example of a seldom used action which must be done with high performance is the emergency shutdown of a nuclear reactor. Analyzing the trade-offs of necessary complexity allows for many things to remain simple which, in turn, will eventually lead to a higher quality product. The architecture team also converts the typical scenarios into a test plan.

DESIGN APPROACHES
Design is a meaningful engineering representation of something that is to be built. It can be traced to a customer's requirements and at the same time assessed for for quality against a set of predefined criteria for 'good' design. In the software engineering context, design focuses on four major areas of concern, data, architecture, interfaces, and components.

SOFTWARE DESIGN APPROACHES

Two fundamental approaches: Function-Oriented Design Object-Oriented Design

Function-Oriented Design: A system is viewed as something that performs a set of functions Example: Create-new-library Function may have Subfunction of : Assign-membership-number Create-member-record Print-bill

10

Function Oriented design approaches: Structured Analysis Top Down Decomposition approach Divide and conquer Principle Graphical representation (DFD) Structured Design Structured Charts Detailed Design

Object-Oriented Design:
A system is viewed as a collection of objects(i.e. entities) Example-Library automation system Each library member is separate object with its own data and functions The function defined for one object cannot change data of other object

FUNCTION ORIENTED VIEW OF DESIGN:

Shared Memory

F1

F2

F3

F4

F5

11

SYSTEM DESIGN
DATA FLOW DIAGRAM
A data flow diagram is a graphical representation to depict the flow of data in a computer based information system. Data flow diagrams provide only logical flow of data rather than physical data flow.

TYPES OF DATA FLOW DIAGRAM Physical data flow diagram: - Physical data flow diagram is implementation dependent. They show the actual devices, department, people etc. involved in the current system. Logical data flow diagram: - It describes the system independently of how it is actually implemented, that is , they show what takes place, rather than how an activity is accomplished.

COMPONENTS OF DATA FLOW DIAGRAM:a) Source or Destination: - The source or destination is graphically represented as a rectangle. Source or destination external entities with which the system communicates. A source or destination is a person or a group of persons that are outside the control of the system being modeled. b) Data Flow: - The flow is represented graphically by an arrow into or out of a process. The flow is used to describe the movement of chunks or packet of information from one part of the system to another part. The flow represents data in motion. c) Process: - The process shows a part of the system that transforms input into output. The process is represented graphically as a circle or bubble. d) Data Store: - The data store is used to model a collection of data packet at rest. The notation of a data store is two parallel lines. Data stores are typically implemented as files or databases in computerized system. Data stores are connected by flow to processes. Data Stores have two types of flow:Basic Symbols for Data Flow Diagram:-

1.

or

= Source or destination of data

12

2.

= Data Flow

3.

or

= Process that transforms data flow

4.

or

= Data Store

In data flow diagrams a single process node on a high level diagram expanded to show a more detailed data flow diagram. The first level DFD shows the main processes within the system. Each of these processes can be broken into further processes until we reach pseudo code. The various elements used for drawing structure chart using Smart Draw are the following: 1. Circles: Circles are used to represent the process 2. Rectangles: Rectangles are used to represent the external entity. 3. Straight Line: Straight line is formatted to arrow head to show the flow of control from one process to another and also represents the data flowing from one process to another. 4. Edit Text: To add text to various processes and to define data flowing from one process to another The logical data flow in a computer based information system is given below in following steps: 1. Data originates from source 2. Undergoes some processing 3. Terminates in a sink The processing step may require data stored elsewhere in data stores over and above what is supplied by the source. Similarly the output of processing may be an intermediate data store, which is used for subsequent processing. There are different symbols used in DFD like: 1. CIRCLE: It is used to represent processing. 2. SQUARE: It is used to represent source. 3. ARROW: It is used to denote flow of data.

13

Level 0 DFD of UMS

Data Manager
Data Entry

Routine
Routine gen_command Performance attende report

Admin

Student
Student Details

SIN/Rollno

Query

IT Enabled Acedmia 0.0

TIN Teacher Details

Teacher

14

Level 1 DFD of UMS

15

Level 2 DFD of UMS

16

Flow Chart:
A flow chart is defined as a pictorial representation describing a process being studied or even used to plan stages of a project. Flow charts tend to provide people with a common language or reference point when dealing with a project or process. The flowchart is a means of visually presenting the flow of data through an information processing systems, the operations performed within the system and the sequence in which they are performed. When dealing with a process flow chart, two separate stages of the process should be considered: the finished product and the making of the product. In order to analyze the finished product or how to operate the process, flow charts tend to use simple and easily recognizable symbols. Flowcharts are usually drawn using some standard symbols; however, some special symbols can also be developed when required. Some standard symbols, which are frequently required for flowcharting many computer programs are shown below:Symbol Name Function an action done by the program (e.g. calculate the area of a square) shows the direction and sequence of processes asks a question and then determines which route the program will take connects one part of the flowchart to another part of the flowchart on the same page using matching symbols

process

arrows

decision

connector

represents when something is input into input/output the program or output from the program

17

The following are some guidelines in flowcharting: a. In drawing a proper flowchart, all necessary requirements should be listed out in logical order. b. The flowchart should be clear, neat and easy to follow. There should not be any room for ambiguity in understanding the flowchart. c. The usual direction of the flow of a procedure or system is from left to right or top to bottom. d. Only one flow line should come out from a process symbol.

or e. Only one flow line should enter a decision symbol, but two or three flow lines, one for each possible answer, should leave the decision symbol.

f. Only one flow line is used in conjunction with terminal symbol.

g. Write within standard symbols briefly. As necessary, you can use the annotation symbol to describe data or computational steps more clearly.

h. If the flowchart becomes complex, it is better to use connector symbols to reduce the number of flow lines. Avoid the intersection of flow lines if you want to make it more effective and better way of communication. i. Ensure that the flowchart has a logical start and finish. j. It is useful to test the validity of the flowchart by passing through it with a simple test data.
18

Flow Chart for University Mgt. System

Start

Student reports for submission

Submit documents

Check availability of seats

Admission Denied

Check Criteria

Admission Denied

Issue roll card

Roll Card

Stop

19

ER DIAGRAMS
ER diagram-: In software engineering, an entity-relationship model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created by this process are called entity-relationship diagrams, ER diagrams, or ERDs. The steps involved in creating an ERD are: 1. Identify the entities. 2. Determine all significant interactions. 3. Analyze the nature of the interactions. 4. Draw the ERD.

20

APPENDIX A Introduction to Unified Modeling Language (UML)

UML stands for Unified Modeling Language In the field of software engineering, the Unified Modeling Language (UML) is a standardized visual specification language for object modeling. UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model. The Unified Modeling Language or UML is a mostly graphical modeling language that is used to express designs. It is a standardized language in which to specify the artifacts and components of a software system. It is important to understand that the UML describes a notation and not a process. It does not put forth a single method or process of design, but rather is a standardized tool that can be used in a design process. There are two broad categories of diagrams and then are again divided into sub-categories:
1. 2.

Structural Diagrams Behavioral Diagrams

1. Structural Diagrams: The structural diagrams represent the static aspect of the system. These static aspects represent those parts of a diagram which forms the main structure and therefore stable. These static parts are represents by classes, interfaces, objects, components and nodes. The four structural diagrams are: 1. Class diagram 2. Object diagram 3. Component diagram 4. Deployment diagram 2. Behavioral Diagrams: Any system can have two aspects, static and dynamic. So a model is considered as complete when both the aspects are covered fully.
21

Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be further described as the changing/moving parts of a system. UML has the following five types of behavioral diagrams: 1. Use case diagram 2. Sequence diagram 3. Collaboration diagram 4. State chart diagram 5. Activity diagram Different types of diagrams and views supported in UML:

Structural View Class diagram Object diagram State-chart diagram Users View Use case Diagram Implementation View Component View

Behavioural View Sequence diagram Colleboration diagram

Environmental View Deployment View

22

UML Diagram Types:

UML Structural Part Class Diagram Behavioural part Sequence Diagram

Object Diagram
Component Diagram Deployement Diagram

Activity Diagram
Collaboration Diagram Use Case Diagram State Chart Diagram

WHY AND WHERE UML?

A model captures the important aspects of the thing being modeled from the certain point of view and simplifies or omits the rest. Engineering, architecture, and many other creative fields use models. A model is expressed in a medium that is convenient for working. A model of software system is made in modeling language such as UML. The UML also contains organizational constructs for arranging models into packages that permit software teams to partition large system into workable pieces. It contains construct for representing implementation decisions and for organizing run-time elements into components. Well-suited to the new demands of the brave new e-world, the Unified Modeling Language (UML) was designed to be distributed, concurrent, and connected. It is based on objects. Objects are distributed -- each one maintains its own state, distinct from all others. Objects are concurrent -- each one can potentially execute in parallel with all others. Objects are connected -- each one can send messages to others through a Web of links. UML is not tied to a single platform or programming language; therefore it is well suited to bridge networks of different systems. UML was designed with extensibility in mind, so it can adapt to new issues as they arise. Let's look at the question from the point of view of the construction trade. Architects design buildings. Builders use the designs to create buildings.
23

The more complicated the building, the more critical the communication between architect and builder. Blueprints are the standard graphical language that both architects and builders must learn as part of their trade. Writing software is not unlike constructing a building. The more complicated the underlying system, the more critical the communication among everyone involved in creating and deploying the software. In the past decade, the UML has emerged as the software blueprint language for analysts, designers, and programmers alike. It is now part of the software trade. The UML gives everyone from business analyst to designer to programmer a common vocabulary to talk about software design. The UML is applicable to object-oriented problem solving. Application of UML UML is intended to be universal, general-purpose modeling language for discrete systems such as those made of software, firmware, or digital logic. The UML is an evolutionary general-purpose, broadly applicable, tool-supported, and industry-standardized modeling language. It applies to a multitude of different types of systems, domains, and methods or processes. As a general-purpose modeling language, it focuses on a core set of concepts for acquiring, sharing, and utilizing knowledge coupled with extensibility mechanisms. As a broadly applicable modeling language, it may be applied to different types of systems (software and non-software), domains (business versus software), and methods or processes. As a tool-supported modeling language, tools are readily available to support the application of the language to specify, visualize, construct, and document systems. As an industry-standardized modeling language, it is not a proprietary and closed language but an open and fully extensible industry-recognized language. The UML enables the capturing, communicating, and leveraging of strategic, tactical, and operational knowledge to facilitate increasing value by increasing quality, reducing costs, and reducing time-to-market while managing risks and being proactive in regard to everincreasing change and complexity. The UML more specialized tool, with a special language used for specialized domains, such as GUI layout, VLSI circuit design, or rule based artificial intelligence. The UML is intended primarily for software- intensive systems. It has been used effectively for such domains as Enterprise information systems Banking and financial services Telecommunication Transportation
24

Defense/aerospace Retails Medical electronics Scientific Distributed web-based services

The UML is not limited to modeling software. Infect, it is expressive enough to model nonsoftware systems, such as workflow in the legal system, the structure and behavior of a patient healthcare system, and design of hardware.

STRUCTURE OF UML
Classifiers: A classifier is a discrete concept in the model, having identity , state, behavior and relationships The UML defines 11 kinds of classifiers:

Classifier

functions

notation

Actor:

an outside user of a system

Class: Classifier role:

a concept from the modeled system a class restricted to particular usage in a collaboration

class-in-state :

a class restricted to being in a given state

component :

a physical piece of a system

data type :

a descriptor of a set of primitive values that lack identity

name

Interface:

a named set of operation that characterize behavior

node:

a computational resource

25

signal : subsystem :

an asynchronous communication among objects a package that is treated as a unit with a specification, implementation and identity a specification of behavior of an entity in its interactions with outside agents

use case:

Diagrams in UML A diagram is a graphical presentation of a set of elements . Diagrams are drawn to visualize a system from different perspectives, so diagram is a projection into a system . Diagram may contain any combination of things and relationships.

1. Use case diagrams: Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how. Use case diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system. Here is a scenario for a medical clinic. "A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. " A use case is a summary of scenarios for a single task or goal. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play. The picture below is a Make Appointment use case for the medical clinic. The actor is a Patient. The connection between actor and use case is a communication association.

Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use cases. A use case diagram is a collection of actors, use cases, and their communications. A single use case can have multiple actors. Use case diagrams are helpful in three areas.

26

Determining features (requirements). New use cases often generate new requirements as the system is analyzed and the design takes shape. Communicating with clients. Their notational simplicity makes use case diagrams a good way for developers to communicate with clients. Generating test cases. The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

Use case diagram for University Management System

Obtain Grant

Input Student marks

Grade Admistrator

Obtain Student Loan

Financial Institution

Print Teaching Schedule Instructor

Reimburse Student Pay Fees

Teach Seminar

<<extend>>

Distribute Transcripts Distribute Information <<extend>> to Students Distribute Fee Schedule

Post Office

Enroll In Seminar

Distribute Schedules

Drop seminar

Registrar

Drop out of School

Attend Seminar Apply For Grant Researcher

Finish Seminar Graduate From School

27

2. Class diagrams: A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static -- they display what interacts but not what happens when they do interact. Class notation is a rectangle divided into three parts: class name, attributes, and operations. Our class diagram has three kinds of relationships.

Association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work Aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. Generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass.

Class diagrams for University Mgt. System

28

3. Sequence diagrams: Class and object diagrams are static model views. Interaction diagrams are dynamic. They describe how objects collaborate. A sequence diagram is an interaction diagram that details how operations are carried out -what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence. Sequence Diagram for University Management System
Enroll in Seminar Basic Course of Action 1. Student indicates wish to enroll

:Main Screen Student : NewClass wish to enroll

:Enroller

:SecurityLogon

:Student

<<create>>

<<create>>

2. Student inputs name & number

name student number iseligible(student,number)

3. System Verifies Student thestudent thestudent

4. System Displays seminar List

<<create>>

:Seminarselector

selection 5. Student picks seminar <<destroy>>

.............

29

4. Collaboration diagrams: Collaboration diagrams are also interaction diagrams. They convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a sequence diagram, object roles are the vertices and messages are the connecting links. The object-role rectangles are labeled with either class or object names (or both). Class names are preceded by colons (:). Collaboration diagram of university system

<<UI>>

1: getname(): seminarname 2: getdescription() 3: getlocation() 4: getseatsleft() 5: getstudentlist()

2: getname(): string 2.1: getnumber(): string 2.2: getdescription(): string

:Seminar Details

:Seminar

:Course

3: * getInfo

Actually a series of getter invocations. enrollment :Enrollment

4: getInfo

5: getfullname()

student :student

30

5. Statechart diagrams: Objects have behaviors and state. The state of an object depends on its current activity or condition. A statechart diagram shows the possible states of the object and the transitions that cause a change in state. States are rounded rectangles. Transitions are arrows from one state to another. Events or conditions that trigger transitions are written beside the arrows.

Statechart diagram of university system

Login To System

Conduct Test

Value the Paper

NO

YES

Submit Marks

Done

31

6. Activity diagrams: An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another. Activity diagram of University Mgt. System

[otherwise] Fill Out Enrollment Form [correct] Enroll in University [incorrect] [help availble] Obtain Help to Fill Out Forms Enrolling in the University for ...

[trivial problems] Attend University Overview Presentation

Enroll In Seminar(s)

Make Initial Tution Payment

32

7. Component diagrams: A component is a code module. Component diagrams are physical analogs of class diagram. A component diagram provides a physical view of the system. Its purpose is to show the dependencies that the software has on the other software components. Component diagram of University Mgt. System

33

8. Deployment diagrams: Deployment diagrams show the physical configurations of software and hardware. The deployment diagram shows how a system will be physically deployed in the hardware environment. Its purpose is to show where the different components of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime, a system's production staff will make considerable use of this diagram. The notation in a deployment diagram includes the notation elements used in a component diagram, with a couple of additions, including the concept of a node. A node represents either a physical machine or a virtual machine node (e.g., a mainframe node). To model a node, simply draw a three-dimensional cube with the name of the node at the top of the cube. Use the naming convention used in sequence diagrams: [instance name] : [instance type].

Example: Deployement diagram of University Mgt. System

<<device>> :ApplicationServer {OS=Solaris} :EJBContainer Student Seminar <<JSP>> : Webserver Student Administration Schedule

<<Device>> :DBServer {OS=Linux} <<JDBC>> <<Database>> University DB

<<RMI>>

<<infrastructure>> Persistance

Course Mgt. Facade <<webservices>>

<<Device>> Mainframe {OS=MVS} <<message bus>> <<Legacy System>> Course Mgt.

34

9. Object diagrams: In the Unified Modeling Language (UML), an object diagram is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time. This snapshot focuses on some particular set of object instances and attributes, and the links between the instances. A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. Object diagrams are more concrete than class diagrams, and are often used to provide examples, or act as test cases for the class diagrams. Only those aspects of a model that are of current interest need be shown on an object diagram. Each object and link on an object diagram is represented by an InstanceSpecification. This can show an object's classifier (e.g. an abstract or concrete class) and instance name, as well as attributes and other structural features using slots. Each slot corresponds to a single attribute or feature, and may include a value for that entity. The name on an instance specification optionally shows an instance name, a ':' separator, and optionally one or more classifier names separated by commas. The contents of slots, if any, are included below the names, in a separate attribute compartment. A link is shown as a solid line, and represents an instance of an association.
Object Diagram of University Mgt System.

Collegestudent no.1: Student

Graduate School of Business: College Univname=University of Chicago Noofcourse: 1000 Capacity=2000 Areaname=HydePark .

Nameofstudent=Sam Sudentid=1 Age=28 .

Collegestudent no.2: Student

Nameofstudent=Nancy Sudentid=2 Age=29 .

35

APPENDIX B

Introduction to Rational Rose

Introduction
Rational Rose is the Case tool that supports the Rational Unified Process (RUP), a methodology for object oriented systems analysis and design, and based on the UML notation. The Rational Software Corporation produces a whole range of products that together form a complete CASE environment The Rational Suite. The whole suite is comprehensive and COMPLEX. It can be used for modeling business requirements, systems design, managing documentation, data modeling, automated code generation in several languages, implementation, testing, project planning and handling change requests. At this point we will be looking at a very small part of the Rational Rose part of the suite Rational Rose is a visual modeling tool, enabling the creation, analysis, design and modification of components in a software system. This guide is intended to show you how to draw the main diagrams within Rational Rose
Setting up Rational Rose for the first time

Start up the PC and logon as you would normally Using windows explorer or My Computer, go to the H: drive Create yourself a subdirectory/folder called Rational Then create a further sub directory/folder within it for your project Exit Windows Explorer

Running Rational Rose

When starting rational rose the following screen is displayed, click on cancel (unless you have already started the diagram in which case click on recent or existing and select the required project).

36

The screen should now look like this:

Parts of the screen

1. Browser

2. Toolbar

3. Diagram area

4. Documenation Window

37

The browser shows the main diagrams you can produce for a project (in this case it is untitled) and there are three main diagrams, the use case view, the logical view and the component view. In this example we wish to produce a class diagram so we need to be using the logical view. If you click on the + beside the logical view folder it will expand to show what makes up the logical view. The browser will change as you add to the diagram these extra elements correspond to what you have added.

1. Browser Window This presents a hierarchical view of the analysis and design model, including all the diagrams and all the individual elements that make up a diagram.

2. Drawing Tools This tool presents a set of icons that indicate the different elements that can be added to a diagram. The elements that can be used will change, depending on the type of diagram being created. Different diagram types have different sets of icons. If you were creating a different diagram type, you would see a different set of icons. The above example is a class diagram in logical view.

3. Diagram Window This is where the diagram is actually created. You will see that the diagram shown in the drawing window represents a high-level model of this course. Course content can be seen as a system composed of four interacting subsystems, two of which involve software. We have used the Package element to represent the subsystems, and the Note element to indicate which packages contain software. 4. Documentation Window It is strongly recommended that each element added to a diagram have documentation to accompany it. To add documentation, right click on the element, select specification, and fill in the documentation field. The documentation will then be shown in the documentation window each time the mouse is clicked on the element. Documentation can also be added directly to the documentation window.

38

39

40

CONCLUSION
All the above description is about the representation of Online Shopping Cart. After the completion of this project any developer of Online Shopping Cart will use this project as a reference to computerize the Online Shopping Cart. Though the system still containing lot of scope of improvement in it. But its overall look and feel gives rough picture of on existing automation system. When looking for solid University Management System site, you want to find a solution that gives you the easy way of maintaining account details of staff, students & colleges. Naturally, you first want to find the software that meets your needs, both now and in the future. Engineering is based on designing different projects. This project represents the whole Online Shopping Cart by using nine diagrams of UML. This representation is easily understandable to any novice user and is graphical user interface based.

41

BIBLIOGRAPHY
1. www.wikipedia.org 2. www.technopedia.com 3. Fundamentals of Software Engineering by Rajib Mall. 4. Structured System analysis and design by Awad.

42