当前位置：文档库 › Tango - a collaborative environment for the world-wide web

Tango - a collaborative environment for the world-wide web

TANGO - a Collaborative Environment for the World-Wide Web Lukasz Beca, Gang Cheng, Geoffrey C. Fox, Tomasz Jurga, Konrad Olszewski, Marek Podgorny1,

Piotr Sokolowski, Tomasz Stachowiak, and Krzysztof Walczak2

Northeast Parallel Architectures Center, Syracuse University 111 College Place, Syracuse, New York

13244-4100, USA3

Abstract

Geographical and logical growth of the World-Wide Web is accompanied by a fast technological devel-opment. Web can be successfully used as a platform for implementation of diverse applications. Distributed and collaborative systems are among the most challenging Web applications. TANGO is an integration platform which enables implementation of Web-based collaborative environments. The system provides means for fast integration of Web- and non-Web-applications into one multi-user collaborative systems. In this paper we de-scribe the functional model, requirements, system design and certain implementation issues of the TANGO system.

Corresponding author: marek@https://www.wendangku.net/doc/7f6606535.html,

On leave of absence from EFP, Poznan, Poland

This research was supported by the U.S. Department of Defense under Rome Laboratory Collaboration & Interactive Visualization Contract No.

F 3062-95-C-0273-01 and by Polish KBN grant No. PB1173/T11/95/09

1. Introduction

During the recent years we observe a still increasing role of computer networks and technologies re-lated to them. Especially, a significant influence of the Internet is very well visible. Internet became not only a technological but also a psychological and sociological phenomenon.

Internet connects millions of computers distributed all over the world, introducing means for global computer communication. Web can now be perceived as one gigantic virtual machine, being able to serve information, computer power and all kinds of resources connected to it. Together with the geographical and logical growth of this network we observe a very fast development of the underlying technologies.

Many different methods of information exchange have been used for years, including file transport, electronic mail, and gopher, to mention a few. However it was the World-Wide Web technology that intro-duced a real revolution into computer world. Some of the reasons of Web popularity are rich information content, attractive and intuitive interface, and platform independence. Web allows presenting various types of data (text, images, links to other documents) together in a convenient hyper-text based form. The World-Wide Web gained quickly immense acceptance and over the years it has proven its stability and robustness.

At its beginnings, the World-Wide Web was little more than a simple way to publish and access elec-tronic documents. However, as its popularity continued to increase, new technologies were being developed and introduced. These techniques provided users with new capabilities. First there were techniques of pre-senting more complex and attractive kinds of data such as sound and video. Then the World-Wide Web started to be perceived as a possible platform not only for information storage and exchange, but also for the computing in general sense [1]. Users want to migrate with their software into this new, attractive net-work environment. One of the natural trends is to start using the Web as a collaboratory environment. This paper describes a methodology to turn the Web into such an environment, supporting both synchronous and asynchronous collaboration modes.

The rest of this paper is organized as follows: Section 2 discusses rationale for the presented work.

Section 3 presents functional model of the system. Section 4 compares our work with few other projects that attack theissue of a Web-based collaboratory. Section 5 provides the reader with description of system architecture and implementation. Finally, section 6 contains our concluding remarks and further work refer-ence.

2. Rationale

In spite of its wide acceptance, the traditional World Wide Web is little more than a convenient method of accessing and displaying information. Use of the stateless HTTP protocol greatly contributed to the Web success of the Web, but it also strongly limited its further development. The basic WWW model does not support any real interactions. The introduction of the CGI (Common Gateway Interface) mecha-nism enriched and extended the Web but it did not solve the interactivity problem. At this stage of the World-Wide Web development, it was still very difficult to create efficient and scaleable tools for coop-erative work on the web. The situation has changed with the introduction of several new technologies.

In 1995 Sun Microsystems introduced Java [2]. Among other well published features, Java introduces

a notion of applets. Applets are programs that can be included into HTML pages, much like an image. A

Java-compatible browser can be seen as an extensible container capable of securely executing chunks of code distributed to the clients from an HTTP server. It is interesting to note that the idea of downloadable interpreted software is hardly new: in the late 80s, Sun introduced a product called NeWS [3] which used

extended Postscript as both a programming language and a communication protocol. The idea was appar-ently too far ahead of its time - NeWS project was promptly abandoned. The combination of Java and HTTP seems to carry much greater appeal. Java gained enormous popularity among the World Wide Web users. Together with its client side script partner, JavaScript, it is now broadly used to bring interactivity into the Web environment.

The notion of interactivity for Web applications is somewhat fuzzy. Currently, an “interactive” Web application is the one that creates dynamic HTML pages dependent on user input. In this paper we are not concerned with this sort of interactivity. Rather, we describe a system that will allow human users to inter-act via their computers. Such systems are known under the newspeak term of collaboratory.

Computer mediated collaboratory systems have a relatively long history (for an extensive review, see [4]). Despite of the extensive body of research, collaboratory systems are still hardly out of the experi-mental stage. Academic implementations have been evolving together with the enabling multimedia and networking technologies: only recently the sophistication of the affordable desktop technology reached the level making multimedia collaboratory a viable prospect. The commercial collaboratory implementations are rather primitive: video teleconferencing, shared whiteboard with limited graphical capability, and a textual chat tool represent industrial state of the art, as exemplified by Insoft’s Communique!, SGI’s InPer-son, or Intel’s ProShare products. It is not very surprising that this type of collaboratory is perceived by some as an activity in search of a need [5].

Why a Web-based collaboratory system? From a sociological standpoint, we believe that today’s web is a prototype of the most common environment in which people interact with computers. If computer col-laboratory is to become a commonplace, it must be Web based per definition. The overwhelming success of the Web creates new opportunities for collaboratory. From the technological standpoint, collaboratory sys-tems critically depend on interoperability. Web is undoubtedly the most successful implementation ever of an open system. Web’s very nature creates a coherent programming environment which is conducive for collaboratory experiments. Java, with its platform independence, is an ideal language for implementation of collaboratory systems.

Another important argument for a web-based collaboratory is the vast information contents of the Web. The limited success of the traditional collaboratory tools is at least partly attributable to their poor integration with information retrieval tools. With little content, collaboratory process becomes meaningless and artificial. Web collaboratory has a potential for seamless integration of information retrieval and ex-change tools, with vast data repositories readily available.

We have designed and implemented a web-based collaboratory system, code-named TANGO, starting from the following few guiding principles that reflect our understanding of collaboratory concepts:? We do not really know how to build an efficient collaboratory. Since no truly successful collabora-tory system exists, there is no blueprint. We have to therefore allow for an extensible system with very few limitations. TANGO must not define application specific protocols, application program-ming language, or limit in whatever way functionality of collaboratory applications.

? The essence of the collaboratory function must be defined by application and by application only. It is up to application developer to specify requested collaboratory functionality for every application.

This functionality may be obvious, as for a chat or audio conferencing, or highly non-trivial, as for

a collaborative weather prediction and analysis application with real-time computational backend.

TANGO supports collaborative process for either type of application.

? The most likely collaboratory applications are the applications supporting professional work in the stand-alone mode. This implies a necessity for a simple API enabling fast and easy porting process

of the existing applications into the collaborative framework. TANGO supports such an API for

applications written in few languages. By providing such an API, TANGO fully benefits from the

following simple observations:

1. the majority of the code of existing applications may be reused while building their col-

laborative versions

2. the majority of applications working in collaborative mode may be implemented using

similar and actually simple message exchange mechanism

3. a useful distributed collaborative systems can be built by integration of slightly modified

standalone applications together with some user and session management mechanisms

3. System’s functional model

Before we turn to a technical description of the TANGO system, it is important to discuss its basic functionality. We perceive TANGO as a modest prototype of an open, extensible system that provides a technological framework for building subsequent generations of collaborative systems. It is therefore use-ful to make a distinction between the functional model and actual implementation. We tried to build a func-tional model that addresses and embraces a number of unresolved issues in the field of Computer Supported Collaborative Work (CSCW). We hope this model to be sufficiently generic to serve as a framework for ongoing implementation process. Implementation methodology is often a compromise dictated by the cur-rent state of the art of the basic Web technology we are building upon: web browsers and the Java Virtual Machine. This state of the art is often a state of misery, as it should be expected from infant technology.

However, true to our belief that an efficient collaboratory can only be built by an arduous process of getting feedback from the users, we decided to provide a working implementation of the system regardless of the evolving technology. We are confident that the new technology trends and tools will help us enrich and better the system as we incorporate them into future implementations of the basic functionality.

The functionality that the system design addresses a number of the following issues, vital to the further development of collaboratory systems:

? TANGO is aimed at creation of shareable information spaces: The basic paradigm of many tradi-tional collaboratory systems is to connect identical instances of few applications and allow them to

exchange data objects or streams. We consider this paradigm way too restrictive. There is no basic

reason to restrict collaborating people and teams to look at the same information in the same way or

using the same tools. Collaboratory system should support coordinated but independent views of

related information. Different presentation of information may be needed for different reasons: a

2D GIS display on the command and control main screen may be sufficient while a mission planner

may want to see a much higher resolution 3D representation of the same information. In other

cases, different information views my be displayed on workstation with different performance or

graphics capabilities. In TANGO, we allow different applications to exchange messages and act ac-

cordingly. The applications exchanging information can reside on either the same node or on dif-

ferent machines. This is an important feature, since, independently of supporting much richer col-

laboration model, it allows us to build complex applications from small, reusable modules. Con-

sider, as an example, a tandem of a chat and a web browser. This tandem is replicated on multiple

nodes. As the users chat, they may pass information about interesting URLs in the chat window. In

TANGO system, this information will be automatically recognized and passed to the set of brows-

ers working in the collaborative mode. Another example is a simulation system created from a

customized TANGO environment: a simulation engine sends messages to both local and remote applications of various kinds, creating a war game or a crisis management center training module.

In both examples the users of the system have full access to the enormous information resources of the entire Web. This information may be presented to them either via a standard, familiar web browser interface, or via a set of specialized filters that tailor information display to a specific task.? TANGO is very tightly integrated with the Web: This statement applies both to TANGO as a func-tional model and to its implementation. In the functional sense, tight integration with Web implies access to the entire informational potential of the Web. This is critical for the construction of the shareable information space discussed above. Further, designing TANGO functionality we have opted for the self-distributing software model for collaboratory applications. While this decision created a number of difficult software implementation issues, it also makes the system very easy to install, use, and extend. Implementation issues will be discussed later, here we wish to point out that TANGO is the first collaboratory system tapping full potential of applet download capability provided by Java.

? TANGO provides support for all synchronous collaboratory functions: Built in a stateless Web en-vironment, TANGO is a statefull system. Basic design supports all functions of a synchronous col-laboratory system, including session management, data/event distribution, flexible floor control, and multiple, configurable security levels. The system does not impose any restrictions on a num-ber of concurrent sessions, users, or collaborative applications.

? Asynchronous collaboration is supported via database back-end: Session record and playback ca-pability has been designed into the system as its fundamental component. This capability applies to both events and data streams and can be used review collaborative sessions in asynchronous fash-ion. Playback/review capability is provided also for real-time continuous data streams such as audio and video.

? Distributed visualization and manipulation of multimedia information streams: TANGO provides scaleable multimedia support. Recognizing different performance requirements of continuous mul-timedia streams, TANGO provides mechanisms for decentralized distribution of the such streams under TANGO session control.

? Language independence: While almost entire TANGO runtime and most of the applications are written in Java, there is no restriction on the language used to implement collaborative applications compatible with TANGO. This design decision appears to violate the aforementioned requirement of application downloadability. Actually, methodologies for automatic distribution of applications written in languages other than Java exist and we intend to incorporate them into our implementa-tion. We have decided however that, at least at present, restricting ourselves to Java would prevent us from extending our systems to such important domains as 3D visualization, high quality video streaming, and videoconferencing (especially multimedia encoding). In addition, TANGO provides

a truly unique support for applications written in JavaScript. Our ability to do so stems from the

earlier decision of very tight integration of TANGO with Web.

? Extensibility: As stated above, we firmly believe that ultimate success or failure of a collaboratory system depends on its application set. Video, audio, and whiteboard conferencing is just a seed of a collaboratory. Domain specific applications must be either implemented from scratch or ported from their stand-alone versions for a collaboratory to become truly useful. For this reason, TANGO APIs for Java, C/C++ and Javascript have been written and well documented.

4. Related work

TANGO is not the only web-based collaboratory system. There are multiple ongoing projects in the area of Web based collaboratory systems. The projects we are aware of represent a rather interesting variety of approaches in aspects such as focus, design methodology, and technological sophistication. A complete review of these projects is well beyond the scope of this paper, but we would like to be able to locate TANGO in the landscape of the ongoing activities.

Many of the collaboratory projects are clearly ad-hoc creations. Examples of such approaches are Stanford NRE Collaboratory System [6] and the CORE system from Environmental Molecular Sciences Laboratory (EMSL) at the Pacific Northwest National Laboratory [7]. Built by scientists to support their own work, the systems take shortcuts to build a minimal practically acceptable collaboratory functionality.

Technically, both NRE CS and CORE rely on CGI/MIME technology to start helper applications (either a set of standard tools (NRS CS) or a custom application (CORE)) on the collaborators’ desktops. Focus of these systems is to provide a quick solution for CSCW demands of the distributed research projects that cannot be satisfied by currently available commercial products. These systems exemplify first generations of the Web based collaboratory, they are already technologically obsolete, and, in absence of a scaleable system design, they probably cannot adopt new technological developments. However, both these attempts provide testimony to the necessity of building efficient CSCW systems. TANGO entirely subsumes func-tionality of such systems.

Another approach to Web collaboratory is presented by a project of Center for Information Systems Management at the University of Texas [8]. Technologically rather simple, this project is built around the informational contents of the collaboratory. Many ideas of this project are quite generic and probably can be adopted by any advanced collaboratory system with focus on providing shared access to domain specific information repositories. Our system does not address issues of this type.

We are also aware about three collaboratory systems written in Java. All of them have certain elements in common with TANGO. The Java Collaborator Toolset (hereafter referred to as JCT) of Old Dominion University [9] uses applets (at least according to the documentation; there is no operational demonstration available over Internet) as collaboratory modules. To provide event and data sharing, the AWT of the JDK is replaced by a custom collaboratory toolkit. Obvious advantage of such a system is simplicity of applica-tion porting. However, we consider this approach to be too restrictive: JCT is shared X written in Java. The only possible form of collaboration is via identical instances of application. We believe that TANGO repre-sents much more general and flexible approach without sacrificing any of the advantages of the JCT.

Two other systems are NCSA Habanero [10] and Caltech’s Infospheres [11]. Habanero is a project of great potential. The main differences as compared to TANGO are: (a) collaboratory modules are Java ap-plications, not applets, so Habanero does not support software downloadability and, hence, is not really a Web based collaboratory; (b) for now, Habanero is limited to Java applications (although there is no fun-damental reason for this restriction); ? Habanero does not offer asynchronous collaboration since there is not database support (again, there could be). We do not know why Habanero designers have chosen appli-cations over applets implementation, buy we certainly can see advantages of such approach. Habanero ar-chitecture is not dependent on ill-defined and ever changing behavior of Web browsers and does not suffer from performance limitations imposed by the browsers. The price paid for this convenience is a less power-ful system: Habanero’s affinity to Web and its ability to tap Web’s enormous informational resources do not appear to match TANGO’s

As for the Infospheres [11], the focus of this project seems to be different. In their context, collabora-tory is just an example of a distributed system. Infospheres project has a very strong theoretical component

[12] investigating compositional systems supporting peer-to-peer communications among persistent, mul-

tithreaded, distributed objects. We currently study Infospheres project to investigate how to use these ideas

to improve TANGO implementation. Our understanding is that the current implementations of the In-fospheres system is functionally more similar to Habanero than to TANGO.

5. TANGO: Architecture and Implementation

5.1. System requirements

We have based design and implementation of the TANGO system on the following formal requirements:? integrate both standalone and Web-based applications by providing a uniform interface to commu-nicate with their instances on remote machines;

? allow to execute and control collaborative application from the Internet browser environment;

? provide means for session control (user authentication, starting and ending sessions, tracing partici-pants activities, changing user privileges);

? enable integration of existing applications written in any programming language, assuming socket communication as the only necessary communication mechanism;

? provide ability to download applications across the network through the use of Java applet tech-nology, allowing main parts of the system to be automatically distributed across the Internet;

? provide logging mechanism, so all user activities may be stored in the persistent form in a database and retraced if necessary;

? support definition of compatible message and application classes to enable multiple, task oriented views of the information streams either locally or remotely

5.2 Low-level collaboratory functionality

The main functionality provided by the system consists of the following elements: (a) session management, (b) communication between collaborating applications, ? user authentication and authorization (d) event log-ging.

5.2.1. Session management

A session is a group of application instances currently working together in the collaborative mode. All ap-plications belonging to the same session exchange information and share behavior. How particular application operates in collaborative mode depends on this application characteristics. Each application belongs to a ses-sion, even if it is not currently used for collaboration. In such case the session consists of this one application only.

In all sessions there is one distinguished user which is considered to be a master. Master of the session has special privileges of controlling the application behavior and/or controlling access of other users to this session. The privileges depend on the application type.

There are three possible actions which may change state of a session:

Creating a session: Session is created when a participant launches a local application. On the beginning, the session contains only this one application instance. The participant becomes automatically the master of this session. Other participants may then join this session.

Joining an existing session: There are two possible ways of joining an existing session:

? by launching a new application and connecting it to a session, or

? by connecting to a session with already existing application instance - in this case the application performs “Leaving a session” scenario and then connects to another session;

Leaving a session: When a participant leaves a session, there are two possible cases which need consideration:? participant is not the master of the session - in this case leaving the session means only removing given application instance from the session,

? participant is the master of the session - in this case the session ends. All participants are removed from the session, the application ends, and the session is deleted.

TANGO does not restrict the number of concurrent sessions. There may be multiple independent sessions of applications of the same type. If messages from one application are compatible with application of another type and the compatible application on the TANGO node on which the first application is running, the mes-sages to compatible applications will be distributed transparently.

5.2.2. Communication

Only applications belonging to the same session can communicate. System provides means for this com-munication. It is implemented on the basis of message passing. If an application sends a message, this message will be delivered to all other compatible applications in this particular session.

There are two major types of messages: (a) control messages and (b) application messages.

Control messages are generated by the system for communication between the server, daemons, and con-trol applications. These messages serve functions such as logging users into the system, establishing sessions, launching applications, etc. Control messages are invisible for user applications.

Application messages are main means of communication between user applications. The structure of appli-cation messages depends on the application and is not interpreted by the communication system. The communi-cation system is transparent for the application messages. The application specific communication protocol is always defined by the application itself using TANGO API.

At present, TANGO messages are sent as strings. A preliminary implementation using object serialization and remote method invocation exists and will be moved into the working implementation as soon as Java ver-sion 1.1 is supported by Web browsers.

5.2.3. User authentication and authorization

System provides means of user authentication and authorization. All user data is kept in a database and is used by the main server which acts as a router of all control and application messages. If a user fails authenti-cation s/he cannot open sessions and connect to the system. It is possible to associate certain application func-tionality with certain level of privileges. If the user does not have appropriate permissions, the server will refuse

accomplishing requested action. User data can only be accessed by special application via custom system ad-ministration application. System security measures can be deactivated using TANGO server configuration tools.

5.2.4. Event logging

One of the important system capabilities is recording of the system activity. Since all system and applica-tion messages must go through the main server, all of them can be recorded in a database. Each time a control or application specific message passes the server this fact is recorded in the database together with the date, exact time, and sender information. These data can be then accessed and the whole system activity can be asyn-chronously reviewed.

During replay of the system activity the database acts as a source of information. Since it keeps application messages as well as control messages, user status, sessions configuration and applications running can be re-stored. Stored application messages enable restoring of activity inside applications.

Event logging functionality is a critical system elements designed to support asynchronous collaboration modalities.

5.3. System architecture

5.3.1. System elements

In Figure 1 the global architecture of the system is presented. The system consists of the following compo-nents:

Local daemon’s main tasks are (a) maintaining two way communication between user applications, applets and central server, (b) launching local applications, ? passing messages between applications running on the same node, and (d) providing certain system level functionality not normally available to Java applets. TANGO daemon is implemented as a plug-in to Web browsers. The daemon is the only operating system dependent core part of TANGO. At present, implementations exist for Netscape v. 3.0 on several platforms. For Microsoft’s Internet Explorer the daemon is implemented as an ActiveX control.

Central server is the main communication element. All local daemons communicate with the central col-laboratory server. Collaboratory server maintains the system state data (participants, applications, sessions, etc.). Its main tasks are keeping the state of the entire system, routing of messages between applications partici-pating in each session, and recording all events in the back-end database. Currently, TANGO system is re-stricted to only one collaboratory server. We are investigating a model for inter-server communication. This sub-project is directed towards extended functionality of a collaboratory systems such as automatic discovery of potential collaborators.

Local Applications:All user applications which run as standalone programs we call local applications. Local application may be written in any programming language. All local applications communicate with the local daemon by the use of sockets. The daemon is responsible for starting these applications and routing mes-sages to and from applications.

Java applets are also user applications but written in Java language, downloaded through the network from an HTTP server, and executed in Netscape environment. Communication between Java applets and central server is also maintained by the local daemons. Java applets communicate with local daemon by calling its method functions.

CA - Control Application

A - Java Applet

LA - Local Application

LD - Local Daemon

CS - Central Server

HTTP - HTTP Server

DB - Database

B - Web Browser

Figure 1. Global architecture of the TANGO system

Control application is a specialized application which acts as an interface to a user [13]. Control applica-tion is used to launch applications locally or remotely, to create and connect existing sessions, to exit applica-tions, etc. This application allows also logging into the system. User interface to the control application depends on his/her privileges, giving a user access to these features only he/she is allowed to use.

Control application communicates with the system by the use of the local daemon. The communication between control application and local daemon is different than in the case of standard Java applets, because control application can also generate system messages.

5.3.2. Event flow

TANGO transparently supports event distribution. However, in contrast to the approach taken in [9], the application developer is free to decide which application events need to be distributed. This decisions are im-plemented by inserting TANGO API calls into applications. How and where events are distributed depends on the session management layer.

Special sequences of events are invoked by the instances of Control Applications in response to the fol-lowing user actions:

? Entering the system

? Leaving the system

? Launching local application

? Leaving the session

? Joining a session with new application

? Joining a session with existing application

? Launching remote application

? Switching to master mode ( or, more generally, floor control events)

For detailed description of the event flow we refer the reader to TANGO documentation.

Another special case of the event flow is invoked when an application joins an existing session. For cer-tain applications it is important to initialize the new instance with the current state of existing instances (as an example, consider a shared drawing program). For applications that require complex initializations TANGO supports a special protocol extension. We expect this particular aspect of TANGO implementation to change after object serialization/Remote Method Invocation of Java 1.1 become available in the browsers.

5.3.3. TANGOsim extension

An example of TANGO architecture flexibility and extensibility is TANGOsim - an discrete event simu-lator [14] . A multithreaded simulation engine implementing virtual time can be driven by either a scripting lan-guage or interactively controlled by a user via Simulation Controller. The engine and the controller are imple-mented as a Java application and a Java applet, respectively. The simulation engine can create messages for any application compatible with TANGO system, to create and control sessions, and to realize scenarios in which the course of action depends on user input. TANGOsim is a prime example of the system capability to go be-yond the collaboratory model of “cooperating twins”.

5.3.4. Videoteleconferencing

For scaleability reasons, the real time multimedia streams are not sent via central server. Instead, a distrib-uted architecture akin to the Insoft’s (currently Netscape) OpenDVE has been implemented4 [15]. This archi-tecture supports multicast. Session control remains with the TANGO session manager. Audio/video de-code/playback capability is implemented in Java for certain supported codecs. Currently, we support two audio (GSM and ADPCM) and three video codecs: very low bit rate H.263 codec (phone line bitrate), medium bit rate H.261 (ISDN line bit rate), and the YUV9 format (LAN bit rate). Back-end database repository and playback capability for the audio/video streams is provided by a random access video server [16] and is a part of the global system session archiving/retrieval facility.

5.4 Implementation Issues

One of the most important goals while designing TANGO was its portability. The World-Wide Web is composed of a plethora of systems. Creation of software versions for each platform may be a significant effort. Java language provides means to overcome this difficulty. By using one uniform environment on each platform it resides, Java allows to run the same code everywhere.

4Our original intent was to use the announced Netscape LiveMedia architecture. LiveMedia was supposed to be a re-engineered OpenDVE from Insoft, but it never materialized except as CoolTalk, Netscape audio conferencing tool. The original Insoft OpenDVE had insufficient performance, undocumented interfaces, and a fair share of bugs. We have re-implemented entire functionality of OpenDVE from scratch. This implementation is available as NPAC Conferencing System [15].

Ideally, we would like to implement all system components using only Java. This approach turned out, however, to be not feasible for several reasons. The most important are security constraints imposed on Java. If we wanted to have our clients in form of Java applets, we could not force them to connect to the daemon resid-ing on a different host. Using pure Java model we would have to create a client-server model in which all communication and data distribution are located in one host. This idea had to be rejected because of its inflexi-bility.

5.4.1. Daemon implementation

Daemon provides a mechanism for Netscape components such as Java applets, JavaScript scripts and plug-ins to talk to each other. The daemon has been implemented as a plug-in. Using LiveConnect mechanisms [17], each applet residing in the same page with the plug-in may obtain its handle. Message passing between plug-in and an applet is achieved by calling appropriate methods of each other. In case of the local applications, the connection to the daemon is implemented with use of standard socket communication. Comparison of standa-lone applications and applets is presented in Table 1. In Figure 2 the communication schema is presented.

activity applet standalone appli-

cation

starting new pro-

gram dynamic HTML gen-

eration

system call

(platform specific)

communication with

daemon mutual method calling local socket con-

nection

Table 1 Applets vs. applications - comparison

Although plug-ins are usually written in C (the API provided by Netscape uses this language), it is possible to associate Java code with the native C code and in this way implement some parts of the code in Java. Plug-in written in Java is not treated in the same way as an applet. In TANGO, ~90% of the plug-in is written in Java. Only the part used to start standalone applications is implemented in C. Using such approach we obtain means to communicate between various applications on the client. The plug-ins must be created separately for each platform, but since the system-dependent “C part” is very small, this is a relatively easy task. At the time of this writing (February ’97) TANGO plug-ins are available for Solaris 2.4+, Irix (5.3, 6.2, 6.3), Windows ’95 and Windows NT. Linux version is expected soon.

Figure 2. TANGO communication schema

5.4.2. Server implementation

The central server was implemented as a standalone Java application. Its main part listens for incoming connections on a known port. For each new connection a separate thread is started. Server keeps all the infor-mation about connections and users in dynamic data structures and also stores them in the database. In our im-plementation we use JDBC package and Oracle database system as a back-end.

5.4.3. Control application

Control application [13] has been implemented as a Java applet. A small part of it is launched on the be-ginning giving a user a possibility to login to the system. Then the rest is downloaded from the HTTP server later, after user authentication, and depends on the user privileges.

5.4.4. Application API

Tango API [18] is used to port a standalone application into a shared application that can be collabora-tively run under the Tango system. Using the Tango API, all the message passing and event routing are com-pletely transparent to the developers. The developers only need to define when and what the application will share with all participants of the same application. This is usually done by inserting Tango API into the appli-cation code, without modifying any line of the existing code.

Tango API has two major categories:

1. Tango Core API is used for an application to communicate with other participants of the same ap-

plication under the Tango collaborative infrastructure. It is assumed that the same application will

act both as a sender (producer) and as receiver(s) (consumer) of messages/events when multiple

copies of the same application run on distributed (different) host machines over the Tango system.

Therefore, the main purpose of the Tango Core API is to allow an application to register into the

Tango runtime system, and for events to be shared among participants to send and receive them

over the Tango system, without knowing how an event is distributed over the network. More spe-

cifically, when porting a Tango application, a developer must define:

? When to share an event. Usually this occurs when the event handler of the application wants to share a significant change on the GUI of the application, for example, a button is

pressed.

? What to share. Tango system is developed to be a light-weight event-driven system that can run over a wide area network. It is assumed that only events or application-defined protocol

data (not bulk data) need to be sent that will be used to drive the application behavior. In

the current implementation, Tango Core API provides message objects to convert/pack any

event into a binary format before/after it can be sent/received. In the near future, we plan to

use Java RMI/Object serialization mechanism that will be supported in the version 1.1 of

Java JDK from SUN to simplify the current message API.

? What to do after an event is received. Because a Tango application usually runs in the sin-gle program multiple data (SPMD) mode, it is the application’s job to define the program

behavior after an event is received. Usually, the behavior has been defined in the event

handler part of the application when the event is handled by the originator.

However, when porting a Tango application, a developer does not need to define/know:

? What are the Tango runtime components and where are they running ?

? How to login/connect to the Tango runtime ?

? How to start/join a tango application/session ?

? How an message is being distributed ?

? Where and how the sessions and users information are kept in the system ?

2. Tango CA API allows an application to access the current runtime information of the Tango sys-

tem, such as sessions, participants, modes, identifications, application lists etc. This is usually used

for the applications that themselves are collaborative in nature, such as chat, whiteboard, audio con-

ferencing etc.

Currently, we provide two Tango APIs for applications written in different languages, including Tango Java/Applet API, Tango C/C++ API, and Tango JavaScript API.

JavaScript API is a rather interesting case. Using it, we are able to build client-side collaborative applica-tions. TANGO-ized JavaScript applications can be synchronized within a “collaborative browser” based on a standard browser of any vendor. Further, by combining TANGO JavaScript API with HTML pages preproc-essing using technologies found in Web spiders we are actually able to automatically turn each Web page into a collaborative entity.

6. Conclusions

We have designed, implemented, and distributed TANGO, a web based collaborative system. The system extends Web paradigm to true collaborative computing and well beyond the chat and shared whiteboard con-cept. TANGO framework is open and extensible. In it minimal version the system fully supports self-distributing software model, due to being written almost entirely in Java and completely integrated with web browser environment. In the extended version, TANGO supports collaborative applications written in any lan-guage, including JavaScript, and provides a simple and fast methodology to turn the existing applications into collaborative modules. The system supports both synchronous and asynchronous collaboration modes. TANGO

is also very portable: in the short life of the project, versions running on a number of UNIX and Wintel plat-forms have been implemented.

Our future work has two focal points. One is improvement and further development of the core TANGO runtime and APIs. Here, the project is driven by the technological advances of commercial Web tools and by academic research in distributed Internet systems, such as Caltech’s Infospheres [12]. Another is a rapid and vigorous development of the domain specific application modules and deployment of the system in the domain specific testbeds. At present, TANGO supports some two dozen of collaboratory modules, from simple chat and whiteboard applets, via advanced desktop videoteleconferencing, to complex, domain specific applications as a command and control center prototype, weather analysis and prediction system, 2D and 3D GIS visualization, or a Virtual University distance learning application. We expect to extend this list by both enriching the current application domains by adding new modules and by entering new domains, like telemedicine. Acknowledgments

One of us (Krzysztof Walczak) acknowledges financial support of NPAC during his stays in Syracuse. We also appreciate help we have received from the NPAC VoD and GIS teams: Kemal Ispirli, Greg Lewandowski, Pawel Roman, Remek Trzaska, and Bart Winnowicz.

References

[1] Fox, G.C, Furmanski, W, “Java and Web Technologies for Simulation and Modeling on Computational Science and Engineering”,

Proc. of the 8th SIAM Conf. On Parallel Processing, Minneapolis, March 1997.

[2] Gosling, B. Joy, and G. Steele. “The Java Language Specification.” Addison-Wesley Developers Press, Sunsoft Java Series, 1996

[3] Gosling,J., Rosenthal, D.S.H., Arden, M., “The NeWS Book”, Springer-Verlag New York 1989

[4] Schooler E.M. “Conferencing and Collaborative Computing.” Multimedia Systems 4: 210-225 (1996)

[5] Grudin, J. “Computer-supported cooperative work: history and focus.” IEEE Computer 27: 19 - 26 (1990)

[6] Stanford NRE Collaboratory System, https://www.wendangku.net/doc/7f6606535.html,/collab/collab.html.

[7] EMSL Collaborative Research Environment (CORE), https://www.wendangku.net/doc/7f6606535.html,:2080/docs/tour/index.html

[8] “Collaboratory in Cyberspace”, an on-line paper by Anitesh Barua, Ramnath Chellappa, and Andrew B. Whinston,

https://www.wendangku.net/doc/7f6606535.html,/ram/papers/joc/joc.htm.

[9] Java Collaborator Toolset, https://www.wendangku.net/doc/7f6606535.html,/~kvande/Projects/Collaborator/

[10] NCSA Habanero Project, https://www.wendangku.net/doc/7f6606535.html,/SDG/Software/Habanero/

[11] Caltech Infospheres Project, https://www.wendangku.net/doc/7f6606535.html,/

[12] K.M. Chandi, A. Rifkin, “Systematic Composition of Objects in Distributed Internet Applications”, Proc. of. The 30th Hawai Inter-

national Conference on System Sciences, January ’97, Maui, Hawai

[13], Jurga, T., “Control Application for Java/WWW-base Collaboratory Environment of Tango System”, Internship Report, NPAC,

Syracuse, January 1997.

[14] Beca, L., Cheng, G., Fox, G.C, Jurga, T., Olszewski, K., Podgorny, M., Walczak, K., “Web Technologies for Collaborative Visuali-

zation and Simulation”, Proc. of the 8th SIAM Conf. On Parallel Processing, Minneapolis, March 1997.

[15] NPAC Conferencing System, https://www.wendangku.net/doc/7f6606535.html,/toms/Projects/NCS/ncs-info.html; Stachowiak, T., “NPAC Conferencing

System”, Internship Report, NPAC, Syracuse, January 1997.

[16] NPAC Video on Demand project, https://www.wendangku.net/doc/7f6606535.html,/rlvod

[17]The LiveConnect / Plug-in Developer’s Guide, https://www.wendangku.net/doc/7f6606535.html,/eng/mozilla/3.0/handbook/plugins/index.html

[18] “Tango API for Developers”, https://www.wendangku.net/doc/7f6606535.html,/tango/TangoAPI.html

数据库课程设计完整版

HUNAN CITY UNIVERSITY 数据库系统课程设计设计题目：宿舍管理信息系统姓名：学号：专业：信息与计算科学指导教师：

20年 12月1日目录引言3 一、人员分配 4 二、课程设计目的和要求 4 三、课程设计过程 1.需求分析阶段 1.1应用背景 5 1.2需求分析目标5 1.3系统设计概要5 1.4软件处理对象 6 1.5系统可行性分析6 1.6系统设计目标及意义7 1.7系统业务流程及具体功能 7

1.8.1数据流程图8 2.系统的数据字典11 3.概念结构设计阶段 13 4.逻辑结构设计阶段 15 5.物理结构设计阶段 18 6.数据库实施 18 7.数据库的运行和维护 18 7.1 解决问题方法 19 7.2 系统维护 19 7.3 数据库性能评价 19 四、课程设计心得. 20参考文献 20 引言

学生宿舍管理系统对于一个学校来说是必不可少的组成部分。当前好多学校还停留在宿舍管理人员手工记录数据的最初阶段，手工记录对于规模小的学校来说还勉强能够接受，但对于学生信息量比较庞大，需要记录存档的数据比较多的高校来说，人工记录是相当麻烦的。而且当查找某条记录时，由于数据量庞大，还只能靠人工去一条一条的查找，这样不但麻烦还浪费了许多时间，效率也比较低。当今社会是飞速进步的世界，原始的记录方式已经被社会所淘汰了，计算机化管理正是适应时代的产物。信息世界永远不会是一个平静的世界，当一种技术不能满足需求时，就会有新的技术诞生并取代旧技术。21世纪的今天,信息社会占着主流地位，计算机在各行各业中的运用已经得到普及，自动化、信息化的管理越来越广泛应用于各个领域。我们针对如此，设计了一套学生宿舍管理系统。学生宿舍管理系统采用的是计算机化管理，系统做的尽量人性化，使用者会感到操作非常方便，管理人员需要做的就是将数据输入到系统的数据库中去。由于数据库存储容量相当大，而且比较稳定，适合较长时间的保存，也不容易丢失。这无疑是为信息存储量比较大的学校提供了一个方便、快捷的操作方式。本系统具有运行速度快、安全性高、稳定性好的优点，而且具备修改功能，能够快速的查询学校所需的住宿信息。面对当前学校发展的实际状况，我们经过实地调研之后，对宿舍管理系统的设计开发做了一个详细的概述。

数据库课程设计完整版

HUNAN CITY UNIVERSITY 数据库系统课程设计设计题目：宿舍管理信息系统姓名：学号：专业：信息与计算科学指导教师： 20年 12月1日目录引言 3 一、人员分配 4 二、课程设计目的和要求 4 三、课程设计过程 1.需求分析阶段 1.1应用背景 5 1.2需求分析目标5 1.3系统设计概要 5 1.4软件处理对象 6 1.5系统可行性分析 6 1.6系统设计目标及意义7

1.7系统业务流程及具体功能 7 8 2.系统的数据字典11 3.概念结构设计阶段 13 4.逻辑结构设计阶段 15 5.物理结构设计阶段 18 6.数据库实施 18 7.数据库的运行和维护 18 7.1 解决问题方法 19 7.2 系统维护 19 7.3 数据库性能评价 19 四、课程设计心得. 20 参考文献 20 引言学生宿舍管理系统对于一个学校来说是必不可少的组成部分。目前好多学校还停留在宿舍管理人员手工记录数据的最初阶段，手工记录对于规模小的学校来说还勉强可以接受，但对于学生信息量比较庞大，需要记录存档的数据比较多的高校来说，人工记录是相当麻烦的。而且当查找某条记录时，由于数据量庞大，还只能靠人工去一条一条的查找，这样不但麻烦还浪费了许多时间，效率也比较低。当今社会是飞速进步的世界，原始的记录方式已经被社会所淘汰了，计算机化管理正是适应时代的产物。信息世界永远不会是一个平静的世界，当一种技术不能满足需求时，就会有新的技术诞生并取代旧技术。21世纪的今天,信息社会占着主流地位，计算机在各行各业中的运用已经得到普及，自动化、信息化的管理越来越广泛应用于各个领域。我们针对如此，设计了一套学生宿舍管理系统。学生宿舍管理系统采用的是计算机化管理，系统做的尽量人性化，使用者会感到操作非常方便，管理人员需要做的就是将数据输入到系统的数据库中去。由于数据库存储容量相当大，而且比较稳定，适合较长时间的保存，也不容易丢失。这无疑是为信息存储量比较大的学校提供了

数据库课程设计(完整版)

HUNAN CITY UNIVERSITY 数据库系统课程设计设计题目：宿舍管理信息系统姓名：学号：专业：信息与计算科学指导教师： 20年 12月1日

目录引言 3 一、人员分配 4 二、课程设计目的和要求 4 三、课程设计过程 1.需求分析阶段 1.1应用背景 5 1.2需求分析目标5 1.3系统设计概要 5 1.4软件处理对象 6 1.5系统可行性分析 6 1.6系统设计目标及意义7 1.7系统业务流程及具体功能 7 1.8.1数据流程图8 2.系统的数据字典11 3.概念结构设计阶段 13 4.逻辑结构设计阶段 15 5.物理结构设计阶段 18 6.数据库实施 18 7.数据库的运行和维护 18 7.1 解决问题方法 19 7.2 系统维护 19 7.3 数据库性能评价 19 四、课程设计心得. 20参考文献 20

引言学生宿舍管理系统对于一个学校来说是必不可少的组成部分。目前好多学校还停留在宿舍管理人员手工记录数据的最初阶段，手工记录对于规模小的学校来说还勉强可以接受，但对于学生信息量比较庞大，需要记录存档的数据比较多的高校来说，人工记录是相当麻烦的。而且当查找某条记录时，由于数据量庞大，还只能靠人工去一条一条的查找，这样不但麻烦还浪费了许多时间，效率也比较低。当今社会是飞速进步的世界，原始的记录方式已经被社会所淘汰了，计算机化管理正是适应时代的产物。信息世界永远不会是一个平静的世界，当一种技术不能满足需求时，就会有新的技术诞生并取代旧技术。21世纪的今天,信息社会占着主流地位，计算机在各行各业中的运用已经得到普及，自动化、信息化的管理越来越广泛应用于各个领域。我们针对如此，设计了一套学生宿舍管理系统。学生宿舍管理系统采用的是计算机化管理，系统做的尽量人性化，使用者会感到操作非常方便，管理人员需要做的就是将数据输入到系统的数据库中去。由于数据库存储容量相当大，而且比较稳定，适合较长时间的保存，也不容易丢失。这无疑是为信息存储量比较大的学校提供了一个方便、快捷的操作方式。本系统具有运行速度快、安全性高、稳定性好的优点，并且具备修改功能，能够快速的查询学校所需的住宿信息。面对目前学校发展的实际状况，我们通过实地调研之后，对宿舍管理系统的设计开发做了一个详细的概述。

数据库课程设计报告户籍管理系统完整版

. 中北大学数据库课程设计说明书班级：学号：姓名：学专方向：指导教师：企业信息化软件开发与应用

成绩： 2014 年 6 月 1.需求分析随着城市人口规模的扩大和公安部门对城市及农村人口管理工作规性的逐渐增强，户籍管理工作的业务量急剧增大。传统的手工方法，存在效率低、易出错等缺点，已经难以满足当前户籍管理工作的要求。因此，结合当前日益成熟的计算机相关技术，开发一个专门针对户籍管理的系统已经非常必要了。户籍管理信息系统是公安部门不可缺少的一部分，更是适应现代户籍制度并推动户籍管理走向科学化、规化、自动化的必要条件。该管理系统能够为用户提供充足的信息和快捷的查询手段，以帮助用户了解户籍工作的情况。它大大改善了公安部门管理、查询户籍的基础工作环境，在一定程度上反映出户籍管理的现代化管理模式。因此人口户籍管理信息系统的开发迫在眉睫。该课程设计就户籍的迁入、迁出、注销，身份证的办理、领取做了简单地设计。 1.1项目开发背景近年来，随着计算机技术的发展和互联网时代的到来，我们已经进入了信息时代，随着人口的不断增长，户籍管理部门也应得到良好的发展，利用现代化管理工具使其变成半自动化必定会提高其工作效率。 1.2项目开发目的户籍管理系统是针对户籍管理部门而开发的，为其改变人口信息仍需要手动处理和查询，个人的信息在处理中丢失或者不明确等现象而设计的。通过这个户籍管理系统，可以让

户籍管理部门提高工作质量和效率，从而达到更快捷、更准确、更方便的目的。 1.3需求分析阶段的目标与任务 1.3.1划分功能模块在构造系统时，首先从需求出发构造数据库表，然后再由数据库表结合需求化分系统功能模块，这样就把一个大的系统分解为几个小的系统。经过调查分析，户籍信息管理系统应具有以下功能：（1）对户籍的变动进行处理。任何管理部门的户籍信息不会是一成不变的，总是在不断的变化：有迁出、有迁入、户口合并，也有因故注销。因此，设计系统时应考虑到这些情况，实现户籍的日常管理工作。（2）对所管辖户籍所分离出的个人信息的计算、统计。找到符合条件的个人，进行核对无误后，生成档案文件进行转存，保证数据的安全完整，以此来实现身份证的办理与领取。（3）查询统计功能。要求即可以单项查询，比如查看某个人工的户口情况等；也可以多项查询，比如同一户口特征的户口浏览，并按照所需的要求进行数据的转存。 1.3.2处理对象户籍信息:户籍号，户主姓名户籍成员信息:姓名，户主关系，性别，民族，籍贯，住址，身份证号，文化程度，职业，户籍号，迁入时间，迁出时间，迁入地，迁出地身份证：姓名，身份证号，性别，民族，地址

数据库课程设计—企业工资管理系统java版+完整代码精选

企业工资管理系统课程设计报告姓名XXX 班级XXXXX 学号XXXXXX 课程名称数据库原理及应用指导教师 201X年X月X日目录一．工资管理系统需求分析…………………………………功能需求……………………………………………………………………………………………………………………………………… 性能需求………………………………………………… 数据流图……………………………………………… 二.总体设计………………………………………………… 数据库概念设计………………………………………… 功能模块………………………………………………… 三.系统详细设计…………………………………………… 数据库逻辑设计………………………………………… 各模块功能………………………………………………………………………………… …………………………………

………………………………… 四.系统实现…………………………………………………界面截图……………………………………………………………………… ………………………………………………………………………………… ………… 设计代码…………………………………………………五.实验总结…………………………………………………

1、需求分析 1.1功能需求 (1)、员工信息表；及时反映员工的基本信息 (2)、员工津贴表，反映员工津贴 (3)、员工基本工资表功能描述 (1)、基本工资的设定 (2)、津贴的设定 (3)、计算出月工资 (4)、录入员工工资信息 (5）、添加员工工资信息（6）、更改员工工资信息性能需求此工资管理系统对工资数据精度的计算能在默认情况之下精确到小数点后3位小数，即是精确到分的计算。但在用户使用过程中，能自行根据实际情况进行小数计算精度的设定，最大能允许保留小数点后5位的精度。在时间特性上，当用户发出命令请求时的服务器的响应时间、对数据更新处理、工资数据的查询检索等上，同样要求系统响应时间不会超过秒时间。系统支持多种操作系统的运行环境，多不同操作系统，不同文件格式的磁盘上的数据均能实现信息的互通，及共享。当服务器移植到其他的系统平台，如：Linux平台下时，同样能和其他的系统进行数据存取同步，不会出现系统之间互不兼容的情况，系统支持多系统之间的互连互通，系统有巨大的强健性。本课程设计是用Java 语言编写，mysql数据库。数据流图根据工资管理要求及用户需求调查分析，得到以下数据流图图第一层数据流图

数据库课程设计报告完整版

数据库课程设计报告 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

数据库课程设计 --JIA服装销售系统指导老师：索剑系名：计算机科学系姓名：薛文科班级：11计算机1班目录第一章绪论....................................................................... (3) 课题简介........................................................................ (3) 设计目的........................................................................ (3) 设计内容........................................................................ (3) 系统实验要求........................................................................ . (3) 第二章需求分析....................................................................... .. (3)

系统基本功能........................................................................ .. (3) 权限划分........................................................................ . (4) 系统运作流程........................................................................ . (4) 数据字典........................................................................ .. (5) 第三章概念结构设计 (7) 概念结构设计的方法与步骤 (7) 3.1.1概念结构设计的方法........................................................................ . (7) 3.1.2概念结构设计的步骤........................................................................ . (7) 数据抽象与局部视图设计........................................................................ . (8) 视图的集成........................................................................ (9) 第四章逻辑结构设计 (10) E-R图向关系模型的转换........................................................................ (10) 数据模型的优化........................................................................ (11) 数据库的结构........................................................................ . (11)

数据库课程设计完整版

数据库课程设计完整版 Document number【SA80SAB-SAA9SYT-SAATC-SA6UT-SA18】

HUNAN CITY UNIVERSITY 数据库系统课程设计设计题目：宿舍管理信息系统姓名：学号：专业：信息与计算科学指导教师： 20年 12月1日目录言 3 一、人员分配4 4 、课程设计过程 5目标5

设计概要 5 理对象 6 分析 6 设计目标及意义7 系统业务流程及具体功能 7 8 2.系统的数据字典 11 13 15 18 18 库的运行和维护 18 问题方法 19 维护 19 库性能评价 19 四、课程设计心得. 20 20 引言学生宿舍管理系统对于一个学校来说是必不可少的组成部分。目前好多学校还停留在宿舍管理人员手工记录数据的最初阶段，手工记录对于规模小的学校来说还勉强可以接受，但对于学生信息量比较庞大，需要记录存档的数据比较多的高校来说，人工记录是相当麻烦的。而且当查找某条记录时，由于数据量庞大，还只能靠人工去一条一条

的查找，这样不但麻烦还浪费了许多时间，效率也比较低。当今社会是飞速进步的世界，原始的记录方式已经被社会所淘汰了，计算机化管理正是适应时代的产物。信息世界永远不会是一个平静的世界，当一种技术不能满足需求时，就会有新的技术诞生并取代旧技术。21世纪的今天,信息社会占着主流地位，计算机在各行各业中的运用已经得到普及，自动化、信息化的管理越来越广泛应用于各个领域。我们针对如此，设计了一套学生宿舍管理系统。学生宿舍管理系统采用的是计算机化管理，系统做的尽量人性化，使用者会感到操作非常方便，管理人员需要做的就是将数据输入到系统的数据库中去。由于数据库存储容量相当大，而且比较稳定，适合较长时间的保存，也不容易丢失。这无疑是为信息存储量比较大的学校提供了一个方便、快捷的操作方式。本系统具有运行速度快、安全性高、稳定性好的优点，并且具备修改功能，能够快速的查询学校所需的住宿信息。面对目前学校发展的实际状况，我们通过实地调研之后，对宿舍管理系统的设计开发做了一个详细的概述。一、人员分配组长： E-R 图：数据字典：逻辑结构设计: 二、课程设计目的和要求课程设计是为了增强学生对所学课程的理解，学会综合地、灵活地运用所学课程知识的一个重要的实践环节。本课程设计是应用java程序设计语言进行数据库应用系统的开发，用SQL SERVER 2008进行后台数据库的管理，编写出某一个小型的管理信息系统。通过本课程设计可以达成如下目标： 1、能够自觉运用数据库原理的理论知识指导软件设计； 2、学会数据库的设计，并能对设计结果的优劣进行正确的评价； 3、学会如何组织和编写信息系统软件设计文档和软件系统的操作说明； 4、具有一定的独立分析问题、解决问题的能力； 5、掌握SQL SERVER2008在信息系统开发过程中的应用。

数据库课程设计报告完整版

数据库课程设计班级物联网1202 学号3120611027 姓名杨璐指导老师年轶 2014 年 1 月

目录一、引言 (2) 1．目的 (2) 2．题目 (2) 3．要求 (2) 二、系统的分析与设计 (3) 1．概念设计 (3) 2．逻辑设计 (3) 3．系统功能结构 (4) 4．完整性设计 (5) 三、系统的实现 (6) 四、课程设计小结 (22)

一、引言 1．目的课程设计为学生提供了一个既动手又动脑，独立实践的机会，将课本上的理论知识和实际有机的结合起来，锻炼学生的分析解决实际问题的能力。提高学生适应实际，实践编程的能力。课程设计的目的： (1)加深对数据库系统、软件工程、程序设计语言的理论知识的理解和应用水平； (2)在理论和实验教学基础上进一步巩固已学基本理论及应用知识并加以综合提高； (3)学会将知识应用于实际的方法，提高分析和解决问题的能力，增强动手能力； (4)为毕业设计和以后工作打下必要基础。 2．题目题目2.设计一个大学教学数据库应用系统。该系统涉及学生、教师、课程、分组、登记。数据见附表2。因时间关系，只要求每个学生任选1个题目，如有时间﹑有兴趣，可做另外一题，酌情加分。 3．要求运用数据库基本理论与应用知识，在微机RDBMS(SQL Server)的环境上建立一个数据库应用系统。要求把现实世界的事物及事物之间的复杂关系抽象为信息世界的实体及实体之间联系的信息模型，再转换为机器世界的数据模型和数据文件，并对数据文件实施检索、更新和控制等操作。 (1)用E-R图设计选定题目的信息模型； (2)设计相应的关系模型，确定数据库结构； (3)分析关系模式各属于第几范式，阐明理由； (4)设计应用系统的系统结构图； (5)通过设计关系的主码约束、外码约束和使用CHECK实现完整性控制； (6)完成实验内容所指定的各项要求； (7)分析遇到的问题，总结并写出课程设计报告； (8)自我评价

数据库课程设计完整版

数据库课程设计完整版 This model paper was revised by the Standardization Office on December 10, 2020

大型数据库课程设计完整版

大型数据库实践报告课题：超市商品管理系统学院(系)：软件学院专业：软件工程学生：王帅指导教师：宋薇完成日期2017 年05 月

目录第一章绪论 (7) 1.1 开发背景 (7) 1.2 开发意义 (7) 第二章系统分析 (8) 2.1 系统的需求分析 (8) 2.2 系统开发设计思想 (8) 2.3系统开发步骤 (9) 2.4 系统的主要技术 (9) 2.4.1 数据库相关技术介绍 (9) 2.5 系统的运行环境和开发平台 (9) 2.5.1 硬件设备及操作系统 (10) 2.5.2 系统开发工具 (10) 2.5.3 开发工具简介 (10) 第三章系统设计 (11) 3.1系统流程 (11) 3.2 系统功能模块的划分 (11) 3.2.1用户模块 (12) 3.2.3 产品管理 (12) 3.2.4供应商管理 (12) 3.2.5 入库管理 (12) 3.2.6 出货管理 (13)

3.2.9 系统管理 (13) 3.2.10 系统监控 (13) 3.3数据库设计 (13) 3.3.1数据库需求分析 (13) 3.3.2数据库的逻辑设计 (14) 3.2.4用户设计 (15) 3.2.5 数据库表的设计 (21) 3.2.6 数据表修改 (28) 3.2.7 视图函数的使用 (31) 3.2.8 数据备份与管理 (33) 3.3.9数据库表结构 (38) 3.3.10表实现相关代码 (43) 第四章系统实现 (45) 4.1 运行截图 (45) 4.1.1 登陆界面 (45) 4.1.2 首页展示 (46) 4.1.3 添加商品信息 (46) 4.1.4 查找商品功能 (47) 4.1.5 修改商品功能 (47) 4.1.6 删除商品功能 (47) 4.1.7 查看销售信息 (48)

数据库课程设计完整版

数据库课程设计完整版 SANY标准化小组 #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#

HUNAN CITY UNIVERSITY 数据库系统课程设计设计题目：宿舍管理信息系统姓名：学号：专业：信息与计算科学指导教师： 20年 12月1日目录言 3 一、人员分配 4 4 、课程设计过程 5目标5 设计概要 5 理对象 6 分析 6

设计目标及意义7 系统业务流程及具体功能 7 8 2.系统的数据字典11 13 15 18 18 库的运行和维护 18 问题方法 19 维护 19 库性能评价 19 四、课程设计心得. 20 20 引言学生宿舍管理系统对于一个学校来说是必不可少的组成部分。目前好多学校还停留在宿舍管理人员手工记录数据的最初阶段，手工记录对于规模小的学校来说还勉强可以接受，但对于学生信息量比较庞大，需要记录存档的数据比较多的高校来说，人工记录是相当麻烦的。而且当查找某条记录时，由于数据量庞大，还只能靠人工去一条一条的查找，这样不但麻烦还浪费了许多时间，效率也比较低。当今社会是飞速进步的世界，原始的记录方式已经被社会所淘汰了，计算机化管理正是适应时代的产物。信息世界永远不会是一个平静的世界，当一种技术不能满足需求时，就会有新的技术诞生并取代旧技术。21世纪的今天,信息社会占着主流地位，计算机在各行各业中的运用已经得到普及，自动化、信息化的管理越来越广泛应用于各个领域。我们针对如此，设计了一套学生宿舍管理系统。学生宿舍管理系统采用的是计算机化管理，系统做的尽量人性化，使用者会感到操作非常方便，管理人员需要做的就是将数据输入到系统的数据库中去。由于数据库存储容量相当大，而且比较稳定，适合较长时间的保存，也不容易丢失。这无疑是为信

大数据库课程设计报告材料完整版

实用文档数据库课程设计班级物联网1202 学号 3120611027 姓名杨璐指导老师年轶 2014 年 1 月

数据库课程设计报告完整版

数据库课程设计班级物联网1202 学号 3120611027 姓名璐指导老师年轶 2014 年 1 月

一、引言 1．目的课程设计为学生提供了一个既动手又动脑，独立实践的机会，将课本上的理论知识和实际有机的结合起来，锻炼学生的分析解决实际问题的能力。提高学生适应实际，实践编程的能力。课程设计的目的： (1)加深对数据库系统、软件工程、程序设计语言的理论知识的理解和应用水平； (2)在理论和实验教学基础上进一步巩固已学基本理论及应用知识并加以综合提高； (3)学会将知识应用于实际的方法，提高分析和解决问题的能力，增强动手能力； (4)为毕业设计和以后工作打下必要基础。 2．题目题目2.设计一个大学教学数据库应用系统。该系统涉及学生、教师、课程、分组、登记。数据见附表2。因时间关系，只要求每个学生任选1个题目，如有时间﹑有兴趣，可做另外一题，酌情加分。 3．要求运用数据库基本理论与应用知识，在微机RDBMS(SQL Server)的环境上建立一个数据库应用系统。要求把现实世界的事物及事物之间的复杂关系抽象为信息世界的实体及实体之间联系的信息模型，再转换为机器世界的数据模型和数据文件，并对数据文件实施检索、更新和控制等操作。 (1)用E-R图设计选定题目的信息模型； (2)设计相应的关系模型，确定数据库结构； (3)分析关系模式各属于第几式，阐明理由； (4)设计应用系统的系统结构图； (5)通过设计关系的主码约束、外码约束和使用CHECK实现完整性控制； (6)完成实验容所指定的各项要求； (7)分析遇到的问题，总结并写出课程设计报告； (8)自我评价

(完整版)地球的圈层结构说课稿

评委老师好，我是来自教育科学系10级人文教育专业的学生龙婉玲。今天我说课的内容是《地球的圈层结构》。我说课的流程是：一、教材分析二、学生分析三、教学目标四、教学重、难点五、说教法六、说学法七、教学过程八、板书设计九、作业布置首先，我们来进行教材分析。一、教材的地位和作用《地球的圈层结构》是湘教版教材高一地理必修一第一章第四节的内容。根据新课程标准的要求、学生的认知水平，我对教材结构做了一些调整，将本课内容分为三部分：地震波、地球的内部圈层结构和外部圈层结构。本课内容在学习地理知识、分析地理自然现象、构建地理模型中具有不容忽视的重要的地位。在此之前，学生们已经学习了地球的自转运动与公转运动，这为过渡到本节内容的学习起到了铺垫的作用。同时，本课内容是整个高中地理知识学习的基础，对本教材的其它内容提供理论依据。本内容包含的地球知识，会在以后地理学习中经常运用。它在整个教材中也起到了承上启下的作用。二、学生分析：我的教学对象是高中一年级学生，下面我从三个方面分析， 1、知识基础上，他们在知识上有过初中地理的学习，具有一定知识基础，但水平参差不齐，还处于简单的认识层面，缺乏对地球圈层的透彻理解。 2、学习能力上，他们刚进入高中阶段还缺少自主分析能力，理解能力不强。本课内容抽象，语言具有专业性，图片分析涉及立体几何知识，比较难掌握。从心理上，他们自主性强，积极性高，学习兴趣浓，渴望动手学习。三、教学目标根据本教材的结构和内容分析，结合着高一年级学生的认知结构及其心理特征，我制定了以下的教学目标： 1、知识目标：能识记地球的圈层结构，分析概括出地球各部圈层结构的主要特点。能借助地震波传播速度和距离地表深度的关系表，能够说出地球内部三个圈层的主要依据和主要界面，并分析说明界面附近地震波传播速度的变化特征。学会绘制简单的地球圈层示意图。 2、能力目标：通过分析图片培养学生的读图分析能力。通过绘制简单的示意图，培养学生的动手能力。通过归纳、对比地球内部各层的特点及各圈层特点的差异，对学生进行综合归纳、分析对比等思维能力的培养与训练。

(完整版)人教版高中地理必修一《地球的圈层结构》同步练习题

人教版高中地理必修一《地球的圈层结构》同步练习题地球圈层结构分为地球外部圈层和地球内部圈层两大部分，地理地球的圈层结构同步练习题可以帮助大家掌握关于地球运动的考点，希望能帮助大家更好得掌握知识点。一、单项选择题 1．有关地震波的说法，正确的是（） A．纵波的传播速度较慢，横波的传播速度较快 B．纵波可以穿过固态、液态、气态三态物质 C．横波只能穿过气态的物质 D．纵波传播的速度随经过的物质不同而发生变化，而横波不变解析：此题考查了有关地震波的知识，地震波分为纵波和横波，纵波的传播速度快，能通过固态、液态和气态三态物质，而横波的传播速度慢，只能通过固态的物质。答案：B 2．地球内部圈层的划分依据是（） A．地震发生时的地面变化 B．通过打深井而获得的信息 C．由地震波的速度变化而形成的不连续界面 D．通过卫星遥感技术获得的信息解析：此题考查了有关地球内部圈层的划分依据。地

球内部的知识，目前主要通过对地震波的研究来获得。地震波在地球内部传播速度的变化，说明地球内部的物质组成是变化的，变化明显的地方形成了不连续界面，不连续界面成为地球内部圈层的界线。莫霍界面是地壳和地幔的界线；古登堡界面是地幔和地核的界线。答案：C 3．莫霍界面是（） A．地壳和地幔的界线 B．地幔和地核的界线 C．岩石圈和地幔的界线 D．上地幔和下地幔的界线解析：此题考查了不连续界面的位置，莫霍界面是地壳和地幔的界线，古登堡界面是地幔和地核的界线。答案：A 4．有关岩石圈的叙述，正确的是（） A．岩石圈属于地壳的一部分，是由岩石构成的 B．岩石圈属于上地幔的一部分 C．岩石圈与生物圈关系密切 D．岩石圈的上部是软流层解析：此题考查了有关岩石圈的知识。岩石圈是由岩石构成的，它包括地壳和上地幔顶部软流层的上部。它和地球的外部圈层关系密切。

Oracle数据库课程设计---在线考试系统数据库

在线考试系统需求说明书软件学院课程名称：Oracle数据库课程设计题目名称：在线考试系统学生系别：软件学院

目录一.引言 .......................................................................................................... - 3 - 1.1编写目的 ........................................................................................... - 3 - 1.2读者对象 ........................................................................................... - 3 - 1.3环境要求 ........................................................................................... - 3 - 1.4系统的基本要求 ............................................................................... - 3 - 二.任务概述 .................................................................................................. - 3 - 2.1项目背景： ..................................................................................... - 3 - 2.2项目说明： ..................................................................................... - 4 - 三.数据需求 .................................................................................................. - 4 - 3.1需求分析： ..................................................................................... - 4 - 3.2系统数据流程图 ............................................................................. - 4 - 3.3系统数据字典 ................................................... 错误！未定义书签。四.功能需求 .................................................................................................. - 7 - 4.1系统功能模块图 ............................................................................. - 7 - 4.2用户登录模块图 ............................................................................. - 8 - 4.3权限分配 ......................................................................................... - 9 - 五．数据库结构设计 ..................................................... 错误！未定义书签。 5.1概念结构设计 ................................................... 错误！未定义书签。 5.2逻辑结构设计 ................................................... 错误！未定义书签。 5.3逻辑结构设计ER图........................................ 错误！未定义书签。 5.4逻辑结构设计的表设计 ................................... 错误！未定义书签。

数据库课程设计--学生成绩管理系统

数据库原理与应用课程设计说明书题目：学生成绩管理系统院系：专业班级：学号：学生姓名：指导教师： 2008年12 月22 日

一概述 1.1目的与要求随着科技的发展，基本上所有的具有一定数量数据的机构都开始使用计算机数据库来做管理。几乎所有学校也都已经在使用计算机管理数据的机制，大大减少了学校学生成绩管理的工作量。该课程设计要求设计一个学生成绩的数据库管理系统，数据库中要求包含学生的基本信息，学科基本信息，以及学生所学课程的考试成绩。要方便学生进行成绩查询，通过该课程设计，应该达到把数据库理论知识更加的巩固加深，加强动手能力与实践能力，学以致用，与现实生活中的应用充分的结合起来。 1.2设计环境 ① Microsoft SQL Server 2000 ② Microsoft Visual C++ 6.0 二需求分析 2.1 系统功能要求设计此系统实现如下系统功能：（1）使得学生的成绩管理工作更加清晰、条理化、自动化。（2）通过用户名和密码登录系统，查询课程基本资料，学生所选课程成绩，修改用户密码等功能。容易地完成学生信息的查询操作。 (3) 设计人机友好界面，功能安排合理，操作使用方便，并且进一步考虑系统在安全性，完整性，并发控制，备份和恢复等方面的功能要求。 2.2 系统模块设计成绩管理系统大体可以分成二大模块如，一是学生的基本信息模块，里面应该包含学生的各方面的基本信息；再者便是课程管理模块，在该模块中应该包含有对学生成绩信息的查询和处理，如平均成绩、最好成绩、最差成绩以及不及格学生的统计等功能模块；再其次还有教师、课程等相关信

数据库课程设计(总9页)

数据库课程设计(总9页) -CAL-FENGHAI.-(YICAI)-Company One1 -CAL-本页仅作为文档封面，使用请直接删除

项目题目：_____ 花店管理系统 ________ 任课老师：_______ 撰写时间：____ _______

目录一、系统规划 .......................................................... 错误!未指定书签。二、用户需求分析 .................................................. 错误!未指定书签。三、功能结构设计 .................................................. 错误!未指定书签。四、数据库结构设计............................................... 错误!未指定书签。五、关键模块设计与实现....................................... 错误!未指定书签。六、缺陷与改进 ...................................................... 错误!未指定书签。七、总结与体会 ...................................................... 错误!未指定书签。

一、系统规划 1.系统开发的目标随着时代的进步和科技的发展，现在的人们越来越依赖网上购物。纯粹的实体店在现在的社会环境中，所占市场份额日益下降，并且现在所需的信息越来越多，因此我们要开发一种系统将实体店与网店结合，形成线上线下同步发展的新模式。 2.开发计划以系统开发目的为主，利用指定的系统开发工具进行开发，在完成主要系统目标的前提之下对一些需要的补充功能进行尝试设计开发，设计完成后，在系统运行的环境下对其进行测试与改良，然后进行外观的加工修改，最后提交本次设计。 3.人员安排及具体分工 4.开发工具数据库管理系统为SQL Server 2005或SQL Server 2008标准版或企业版。 5.系统运行环境操作系统为Windows 7

Tango - a collaborative environment for the world-wide web

数据库课程设计完整版

数据库课程设计完整版

数据库课程设计(完整版)

数据库课程设计报告户籍管理系统完整版

数据库课程设计—企业工资管理系统java版+完整代码精选

数据库课程设计报告完整版

数据库课程设计 完整版

数据库课程设计报告 完整版

数据库课程设计完整版

大型数据库课程设计完整版

数据库课程设计完整版

大数据库课程设计报告材料完整版

数据库课程设计报告完整版

(完整版)地球的圈层结构说课稿

(完整版)人教版高中地理必修一《地球的圈层结构》同步练习题

Oracle数据库课程设计---在线考试系统数据库

数据库课程设计--学生成绩管理系统

数据库课程设计(总9页)

数据库课程设计完整版

数据库课程设计报告完整版