A XML Policy-Based Approach for RSVP
Emir Toktar, Edgar Jamhour, Carlos Maziero
Pontifical Catholic University of Paraná, PUCPR, PPGIA
{toktar, jamhour, maziero}@ppgia.pucpr.br
Abstract
This work proposes a XML-based framework for distributing and enforcing RSVP access control policies, for RSVP-aware application servers. Policies are represented by extending XACML, the general purpose access control language proposed by OASIS. Because RSVP is a specific application domain, it is not directly supported by the XACML standard. Hence, this work defines the XACML extensions required for representing and transporting the RSVP access control policy information. The XACML-based framework is proposed as an alternative to the PCIM-based approach, proposed by IETF. The work shows that, while XACML is easier to understand and deploy, it lacks the flexibility offered by PCIM. However, by properly extending XACML, the paper shows that the OASIS model is suitable for defining complex access control policies for specific domains, such as RSVP.
1. Introduction
Policy based network management (PBNM) is an important trend for IP-based networks. Recent works developed by IETF have defined a standard model for representing policies on different areas of network management. The groundwork of this model is the PCIM (Policy Core Information Model), defined by RFC 3060 [5]. PCIM is a platform independent object-oriented information model. The model defines a generic strategy for representing network policies as aggregations of rules expressed in terms of conditions and actions. PCIM is an abstract model, and it does not define sufficient elements for describing policies for particular areas of network management. To address particular areas, PCIM needs to be extended. IETF itself has already introduced PCIM extensions for representing IPsec and QoS [10] policies. Outside IETF, other works explored extensions of PCIM for the area of access control [6].
Besides IETF, others organizations are proposing standard policy models for PBNM. The OASIS (Organization for the Advancement of Structured Information Standards) proposed a language for representing access control policies, on general purpose, denominated XACML (eXtensible Access Control Markup Language). There are several differences between the PCIM and the XACML approach. While PCIM is a core model for representing policies on any area of network management, XACML is dedicated to access control. Because PCIM is an abstract model, the implementation of policies models based on PCIM is a rather complex task. The XACML, by the other hand, is simpler of being implemented and deployed. However, XACML can lack the flexibility for addressing specific application domains.
Based on this argumentation, this work proposes the use of the XACML for modeling and distributing RSVP access control policies for RSVP-aware application servers. Because RSVP is a specific application domain, it is not directly supported by the XACML standard. Hence, this work defines the XACML extensions required for representing and transporting the RSVP access control policy information. The paper compares the proposed XACML-based approach with the standard PCIM-based approach with respect to implementation and deployment. By establishing the parallels with PCIM-based approach, this work defines the futures extensions required for extending this proposal to other network elements, such as routers.
This paper is structured as follows: section 2 presents a short review of the main aspects related to RSVP policy access control. Section 3 presents an analysis of the models that can be employed for describing RSVP access control policies, and the strategies for distributing and enforcing those policies. The section 4 presents a short review of the XACML model. The section 5 describes how the XACML
can be used for describing RSVP policies, and presents the required extensions for adapting XACML to the RSVP issue. The section 6 describes how to implement the framework for distributing and enforcing the RSVP policies described in XACML. Finally, the conclusion reviews the principal aspects of this study and indicates the future works.
2. RSVP Policy Control
This section introduces a brief review of the RSVP protocol, defining the concept of RSVP policy control and presenting the important terms that will be utilized in the next sections. The RSVP signalization is composed by a set of standard messages. The most important messages are PATH and RESV. The emitter always initiates the QoS negotiation by sending the message PATH to the receiver. The PATH message has double function. It defines the QoS parameters the receiver must request for the network in order to satisfy the requisites of the application. It defines, as well, the path the other RSVP messages and the flow of data will follow between the emitter and the receiver. A flow of data on RSVP is a sequence of messages with the same origin, with same expected QoS, and one or more destinations.
The receiver, on accepting the PATH message, initiates the process of flow reservation sending the RESV message to the emitter, along the reverse way defined by the PATH message. The RESV message consists of a flow descriptor, formed by the flowspec and filterspec objects. The filterspec, along with the specification of the session, defines which packets of data (RSVP flow) must benefit from the QoS reservation. The QoS specification is defined by flowspec using two data structures: Rspec(Reserve Spec), that indicates the service class expected and Tspec(Traffic Spec) that specifies what will be transmitted.
The QoS is enforced for a particular data flow by a mechanism called “traffic control”. The traffic control mechanism includes: a packet classifier and a packet scheduler. The mechanism utilizes the Token Bucket algorithm for regulating the traffic of data according to the bandwidth limits specified by the Tspec parameters. During the resource reservation setup, two local decision modules evaluate a RSVP request: the “policy control module” and the “admission control module”. The admission control module determines whether the node (host or router) has sufficient resources available for satisfying the QoS request. The policy control module determines whether the user has administrative permission for obtaining the reservation [2]. The parameters for policy and admission control are not defined and controlled by the RSVP. The protocol merely transports the parameters to the appropriate module for interpretation.
According to the RFC2205, the sender application must specify the type of service most appropriate for its requisites of transmission by passing the related information to the RSVP daemon in the host machine [2]. The RSVP daemon after being called, query the local decision modules, verifying resources and authorization and, being allowed, initiates the exchange of RSVP messages with the nearest network element in the path to the receiver.
As explained in the next sections, the purpose of the work described in this paper consists in defining and implementing a mechanism for configuring the RSVP access control policies (“policy control”) for RSVP-aware application servers by using XACML. This proposal also supply the information for defining the Tspec parameters transported in the PATH and RESV messages. The Tspec information is used for “admission control” by the network elements along the path between the transmitter and the receiver.
3. RSVP Policy Control Strategies
In this paper, the strategy for representing, distributing and enforcing RSVP access control policies follows Policy Based Network Management (PBNM) approach. The concept of PBNM is already widely adopted by organizations that propose Internet standards, such as IETF [14] and the OASIS [7]. Although the definitions for PBNM could diverge according to the organization, the main concepts are relatively universal. The basic idea for PBNM is to offer a strategy for configuring policy on different network devices using a common management framework, composed by a policy server, denominated PDP (Policy Decision Point) and various policy clients, denominated PEPs (Policy Enforcement Points) [12]. The PDP is the entity responsible for storing and distributing the policies to the diverse nodes in the network. A PEP is, usually, a network node component responsible for interpreting and applying the
policies received from the PDP. The PBNM approach can be applied in various aspects of network management. This section will explore how this approach can be applied for managing access control policies in RSVP server (sender) applications.
The IETF explores the concept of PBNM according to two strategies, denominated outsourcing and provisioning. In the outsourcing strategy, the PEP sends a request to the PDP when it needs to make a decision. For example, considering the access problem on RSVP, the PEP would represent the server application (or more precisely, the policy component embedded in the server application). On receiving a request from a client, the PEP would send a request to the PDP in order to determine if the client has the permission for asking the reservation. The PDP then would interpret the policies and would send a final decision to the PEP, informing if the solicitation is permitted or denied. In the provisioning approach, the PEP, as being initialized, would receive from the PDP the set of policies needed for its decision. The policy information received from the PDP is locally stored by the PEP according to a locally defined scheme called PIB (Policy Information Base). On receiving a reservation request, the PEP would consult its locally stored policies and would make the decision by itself. In this approach, the communication between the PEP and the PDP is required only when there is necessity of updating the policies in the PEPs (e.g., the network administrator modifies a policy in the PDP concerning the PEP).
IETF define as well a standard protocol for supporting the communication between the PEP and the PDP. This protocol is denominated COPS (Common Open Policy Service). The basic structure of the COPS protocol is described in the RFC 2748 [1]. The COPS protocol supports both models of policy control, i.e., “outsourcing” and “provisioning”. In the case of the provisioning approach, additional specifications were required and, the protocol was renamed to COPS-PR. The basic structure of the COPS-PR protocol is described in the RFC 3084 [3].
The IETF already published various works concerning the use of PBNM approach for RSVP policy control. The works cover the definition of a framework for admission control [14] and the utilization of COPS in outsourcing (COPS-RSVP) [4] and provisioning (COPS-PR) models. The provisioning approach is still under development, being necessary additional definitions for its complete specification.
The XACML proposal from OASIS also describes that its implementation could follow the approach PDP/PEP. However, OASIS does not make a distinction between the outsourcing and provisioning models, neither defines a standard protocol for supporting the communication between the PEP and the PDP. An analysis of the XACML indicates, however, that it was primarily conceived for supporting the outsourcing approach (see section 4).
An important difference between the approaches adopted by OASIS and IETF relates to how policies are represented and stored. OASIS proposes XACML as a particular model for access control, represented and stored as XML documents. On the other side, IETF defines PCIM as a generic model, independent from the way the policies will be represented and stored. The PCIM model is abstract, and needs to be extended in order to support particular areas of management, such as QoS [10]. IETF indicates strategies for mapping the information models to LDAP (Lightweight Directory Access Protocol) schemas, but this form of storage requires a supplementary effort by the developers.
A work describing the implementation and performance evaluation of a PBNM framework, using COPS in outsourcing model with RSVP (COPS-RSVP) was presented by Ponnappan [8]. The QoS policies were represented using QPIM (QoS Policy Information model), an IETF PCIM extension described by Snir [10]. The policies were represented and stored using LDAP .This work uses CORBA (Common Object Request Broker Architecture) for supporting the interaction between the application components.
4. XACML Review
The XACML (eXtensible Access Control Markup Language) is an OASIS proposal for modeling, storing and distributing descriptive access control policies [7]. XACML-based frameworks are supposed to be implemented using the PDP/PEP architecture in the outsourcing model. The XACML language is defined by two XML schemes: “xacml context” and “xacml policy”. The “xacml context” defines how to represent policy request and policy response messages exchanged between the PEP and the PDP. The “xacml policy” defines how to represent the access control policies. Figure 1 shows the UML diagram of the “xacml policy” scheme. The figure represents the classes and associations between XACML elements, but omits its attributes. According to the XACML strategy, a policy is described in terms of a
set of access permissions (or access denials) by structures denominated Targets. A Target is expressed through the syntax: “users (Subject class) can (or cannot) apply actions (Action class) upon resources (Resource class)”.
Figure 1. XACML policy scheme
Targets can be associated to a policy, to a policy set or to a rule. Targets associated to a policy or a policy set work as policy selectors, i.e., when a PEP request a decision concerning a Target, only the policies and policies sets that contain the Target elements need to be evaluated. Targets associated to rules permit to express conditional permissions (or denials). A rule is expressed by the syntax: “if the condition (Condition class) is satisfied then applies the effect (Effect class) upon the Target”. The possible values for effect are: permit or deny. The effect defines the real sense of a Target as a permission or denial. Figure 2 shows a simple policy example to illustrate the use of the XACML classes. The policy represented in the figure can be described textually as follows: “the user ana@https://www.doczj.com/doc/d83447553.html, can login on a Multimedia Server in the period between 08:00AM and 17:00PM”.
When a PEP sends a request to the PDP, it supplies the attributes permitting to identify the elements of a Target (Subject, Resource, Action). The PDP evaluates the policy rules and determines if exists a Target with those attributes, and then returns to the PEP the corresponding effect: Permit or Deny. If it fails to find a Target in its policies that satisfy the attributes supplied by the PEP, it will return “NotApplicable”.
The Obligations class, when defined, is returned to the PEP in conjunction with the decision. The Obligations class is supposed to inform a set of actions that must be performed by the PEP, concerning the decision. The XACML version (1.0) used in our study [7] does not specify the type of actions described in Obligations. The specification only defines the PEP must be capable of interpreting any information passed through the Obligations class. As will be explained further, our proposal uses the Obligations class to pass QoS parameters to a RSVP node.
As shown in figure 1, a XACML policy can include several rules. The “Rule Combining Algorithm” class determines the strategy used to evaluate the set of rules associated to the same policy. The following strategies are defined by the XACML: Deny-overrides; Permit-overrides and the First-applicable. In Deny-overrides, if the conditions of a rule with effect “Deny”are satisfied, then the decision for the policy will be to deny, regardless the other rules; Permit-overrides defines a similar approach for the effect “Allow”. In First-applicable, the first rule satisfied defines the effect of the policy. Observe, also in figure 1, that policies can be aggregated through the class PolicySet. Similarly as to the rules, the policies are interpreted according to the class “Policy Combining Algorithm”, which defines the same strategies utilized to combine rules, adding still the only-one-applicable strategy. In this case, if more than one policy is satisfied within a PolicySet, then the result of the policy set evaluation will be “Indeterminate”. In addition, XACML defines that developers can also add their own strategies for policy and rule combining.
Figure 3 illustrates how the UML model shown in figure 2 is represented in a XML document. The XML document “format” is formally described by the “xacml policy” scheme.
Though the Obligations class offers an alternative for implementing some sort of policy “provisioning”, we observe that XACML is primarily supposed to be implemented using the outsourcing approach, because the PDP basically returns decisions of type “Permit” or “Deny” to the PEPs. As it will be explained in the next section, the Obligations approach, as defined in XACML version 1.0, is rather limited, because the XACML framework offers no facilities for pre-processing Obligations before returning them to the PEPs. Other limitations of the present XACML specifications concern the lack of definitions regarding the communication protocol for supporting the exchange of messages between the PDP and the PEPs, as well as definitions about the strategy for storing the XACML documents that represent the network policies.
5. Proposal
This paper proposes a XACML-based framework for distributing and enforcing access control policies to RSVP-aware application servers. Figure 4 illustrates a typical scenario for this framework. The PEP element represents a component of the server application, responsible for requesting policy decisions to the PDP and interacting with the RSVP daemon in the host computer. The code of the PEP must be integrated with the application server, as explained in section 6. In our proposal, the PEP is responsible for all interaction with the RSVP daemon, releasing the application from the task of any QoS negotiation. This interaction includes retrieving the traffic information for building PATH messages and granting or not the reservation request on receiving the RESV message. This approach can be implemented in any system that supports the RSVP APIs described in the RFC 2205.
RSVP client
RSVP
PEP PDP
Figure 4. Policy control of RSVP with XACML
The sequence of events and messages exchanged by the elements in figure 4 during the establishment of a RSVP reservation, using the proposed framework, is described as follows:
1. A RSVP client requests a connection to a multimedia server for obtaining services with QoS.
2. In the multimedia server, the application calls the PEP for evaluating the request. Then, the PEP sends to the PDP a XACML request context message informing a “Target” containing its IP address (Resource), the IP address of the client (Subject) and the requested operation (Action).
3. The PDP evaluates the policy defined in XACML for the supplied target, and returns to the PEP a XACML response context message having, besides the result (permit or deny), the information of traffic specification (Tspec , supplied through the Obligations structure).
4. In case of positive decision, the PEP calls its RSVP daemon, informing the Tspec parameters. The RSVP daemon, then, sends a RSVP PATH message to the receiver (i.e., the RSVP client). The Tspec parameters are stored in the PEP for further analysis (see step 6).
5. The RSVP client, on receiving a RSVP PATH message, calls its RSVP daemon, which obtains the traffic parameters from the PATH message and formats a RESV RSVP message, returning it to the sender (i.e., the PEP).
6. On receiving the RESV message from the client, the RSVP daemon of the server triggers an event to the PEP forwarding the Tspec information. The PEP compares the Tspec information received from the client with the Tspec information saved in step 4. If the Tspec parameters are identical or smaller than those saved in step 4, the PEP confirms the reservation to the RSVP daemon. In this step, the RSVP daemon also verifies if it has enough resources to satisfy the request (admission control).
The steps 1 to 6 refer to a well-succeeded scenario of reservation, and exception treatment was omitted. A RSVP access solicitation differs from a conventional access solicitation (e.g., access to a file or directory) because the PDP needs to return the information necessary for the PEP building the PATH message. For this reason, extensions to XACML language were required in order to accommodate the transport of QoS information. As the complete description of the extensions in the XACML policy and context schemes is rather extensive, this paper will describe only the elements needed for understanding the main aspects of our proposal. For a complete description of work, please refer to [11].
In the XACML policy scheme, the Resource class was extended and called ResourceRsvp . The extended class accommodates the description of RSVP parameters required for building the PATH message, i.e., Tspec {r,b,p,m,M}, type of service (GS – guaranteed service or controlled load – CL) and reservation style as described in the RFC 2210 [13] and RFC 2215 [9]. Figure 5 illustrates the XACML scheme extension.
The ResourceRsvp class was defined as an optional element inside Resource, and it can be declared more than once. Several occurrences of ResourceRsvp objects for the same Resource permit to describe several modes a service can be offered by a given application. For example, a multimedia server can define various QoS modes for streaming video in order to support different resolutions. In this case, each QoS mode must receive a distinct class specification (attribute RsvpClass). Observe in figure 5, that the RSVP policy scheme does not include the Rspec parameters. In this work, we suggest the PEP could reject the proposal received on the RESV message if the Rspec parameters are much larger than those specified by Tspec, not being necessary to consult the PDP again for validating the RESV message.
Figure 6 shows an example of RSVP policy. The main elements were highlighted, and most attributes and references were suppressed. The policy describes the access to a resource called of “Multimedia Server”, with a QoS defined by the element
In our work, the
Figure 8 illustrates the answer returned from the PDP to the PEP. In the example, the policy defines only one mode of operation for the multimedia server (defined by the RsvpClass attribute with value G711, in the
7. Implementation
On important advantage of the XACML approach with respect to PCIM refers to its implementation. Because it is defined in terms of XML, a XACML implementation benefits from the existing tools for developing XML applications. There are free packages for supporting XACML in Java language (Sun XACML project) and on C++ (by Jiffy Software).
The framework described in this paper was implemented using the Java? 2 SDK, Standard Edition 1.4.2, and the Sun XACML package. The Sun XACML package includes the modules: “com.sun.xacml. PolicySchema” and “com.sun.xacml.ContextSchema”. The first module supports the interpretation of XACML policies (required for implemented a PDP) and the second, the exchange of messages between the PDP and the PEP.
The implementation permitted to evaluate if the proposed XACML schema extensions are compatible with existing implementation packages. We observed that it was not necessary to modify the package code, except in the case of treatment of the
Next, one presents some examples of utilization of the Sun XACML package for developing a PDP. The following code fragment illustrates the sequence of steps for creating a PDP instance, initialized with a policies file defined by “PolicyQoS.xml”. The “policyModule.addPolicy” method permits to validate the policy with respect to the XACML policy schema. This method was used for validating the syntax of the schema extensions proposed in this work.
FilePolicyModule policyModule = new FilePolicyModule();
policyModule.addPolicy("Path/PolicyQoS.xml");
The XACML package offers classes that, through the Hash tables, simplify the process of searching policies (PolicyFinder) and attributes (AttributeFinder). The fragment of typical code for the creation of an instance of PDP is illustrated following.
PolicyFinder polFinder = new PolicyFinder();
Seth policyModules = new HashSet();
policyModules.add(policyModule);
policyFinder.setModules(policyModules);
AttributeFinder attrFinder = new AttributeFinder();
List attrModules = new ArrayList();
attrFinder.setModules(attrModules);
PDP pdp = new PDP(new PDPConfig(attrFinder, polFinder, null));
The next fragment of code illustrates the creation of a PEP. The RequestCtx class implements a PEP requests to a PDP. The attributes passed in the class constructor refers to the Target elements
RequestCtx request = new RequestCtx(AttribSubjects, AttribResource, AttribAction, AttribEnvironment);
The ResponseCtx class is used for receiving the PDP response. A ResponseCtx object encapsulates the decision, status code and the
8. Conclusion
This paper evaluated the utilization of the XACML language for describing RSVP access control policies. The XACML is still under development and, although limited in a few aspects by lack of standardization, it can be considered a flexible model for the description of the control access policies in different application domains.
In this work, XACML use was extended beyond the access control functionalities, because the decisions generated by the PDP include the Tspec parameters necessary for building the PATH messages. The capacity of returning configuration parameters through PDP decisions is an important feature for many PBNM scenarios. This feature, easily supported in IETF PCIM-based models, is quite difficult to implement in XACML. To support the RSVP scenario, modifications in the
Our work requires some additional specifications concerning the use of the
10. References
[1] Boyle, J.; Cohen, R.; Durham, D.; Herzog, S.; Rajan, R.; Sastry, A. The COPS (Common Open Policy Service) Protocol, RFC2748, Jan. 2000.
[2] Braden, R.; Zhang, L.; Berson, S.; Herzog, S.; Jamin, S. Resource Reservation Protocol (RSVP) Version 1 Functional Specification, RFC2205, Sep. 1997.
[3] Chan K.; Seligson, J.; Durham, D.; Gai, S.; McCloghrie, K.; Herzog, S.; Reichmeyer, F.; Yavatkar, R.; Smith,
A. COPS Usage for Policy Provisioning (COPS-PR), RFC3084, Mar. 2001.
[4] Herzog, S.; Rajan, R.; Sastry, A. COPS usage for RSVP, RFC2749, Jan. 2000.
[5] Moore, B.; Ellesson, E.; Strassner, J.; Westerinen, A. Policy Core Information Model - Version 1 Specification, RFC3060, Feb. 2001.
[6] Nabhen, R., Jamhour, E., Maziero C. “Policy-Based Framework for RBAC”, Proceedings for the fourteenth IFIP/IEEE International Workshop on Distributed Systems: Operations & Management, October, Germany, Feb. 2003.
[7] OASIS, eXtensible Access Control Markup Language (XACML) Version 1.0. OASIS, Feb. 2003.
[8]Ponnappan, A.; Yang, L.; Pillai, R.; Braun, P. “A Policy Based QoS Management System for the IntServ/DiffServ Based Internet”. Proceedings of the Third International Workshop on Policies for Distributed Systems and Networks (POLICY.02). IEEE, 2002 .
[9] Shenker, S.; Wroclawski, J. General Characteri-zation Parameters for Integrated Service Network Elements, RFC 2215, Sep. 1997.
[10] Snir, Y.; Ramberg, Y.; Strassner, J.; Cohen, R. “Policy QoS Information Model, work in progress, draft-ietf-policy-qos-info-model-05.txt”. IETF, May. 2003.
[11] Toktar, E. Controle de Admiss?o de RSVP utilizando XACML. Disserta??o de Mestrado, PPGIA, PUCPR. Aug. 2003.
[12] Westerinen, A. et. al. Terminology for Policy Based Management. RFC3198, Nov. 2001.
[13] Wroclawski, J. RSVP with INTSERV, RFC 2210, Sep. 1997.
[14] Yavatkar, R., Pendarakis, D.; Guerin, R. A Framework for Policy-Based Admission Control, RFC2753, Jan. 2000.
<< endl << endl; cout << "按下1:进入学生信息管理系统." << endl; cout << "按下0:退出." << endl; cout << "-----------------------------------------------------" << endl<
管理信息系统课程设计报告 学生选课系统 班级： 学号： 姓名： 指导教师： 2014年12月20日
目录第一章：现行系统概述 第二章：系统分析 2.1需求分析 2.2可行性研究 2.3信息系统规划 2.4系统的开发方法的选择 2.5组织结构与功能分析 2.6业务流程分析 2.7数据与数据流程分析 2.8功能/数据分析 2.9新系统逻辑方案的建立 第三章系统设计 3.1系统总体结构设计 3.2数据结构与数据库设计 3.3代码设计 3.4输入/输出设计 3.5模块功能与处理过程设计 第四章系统实施 4.1系统实施 4.2系统运行调试
第五章:结束语（结论、建议、收获、体会及小组中每个成员的工作内容） 参考文献
第一章现行系统概述 本科生选课系统是个很庞大的信息系统。目前随着学校人数和课程的激增，对教务处而言，管理和维护选课系统关系到自身的效率，选课系统的繁杂，在一定程度上会相对的增加教务处的管理负担。对学生而言，在选课阶段必须面对大量课程进行仔细筛选，而所有课程聚在一起，学生无法快速定位自己想选以及在规定时间内被要求选的课程类别。 这些问题的出现表明我们的选课系统仍然存在着问题，也需要对其进行改造，由此提高学生选课效率，为学生的学习带来更大的便利。学生选课系统作为一种现代化的教学技术，越来越受到人们重视，是一个学校不可或缺的部分。学生选课系统就是为了管理好选课信息而设计的。学生选课系统将是选课管理工作规范化，系统化，程序化，避免选课管理的随意性，提高信息处理的速度和准确性，能够准确，及时，有效的查询和修改学生选课情况。
第二章系统分析 2.1需求分析 学生可以选修规定范围内的课程，查看已修学分总数，还可以修改个人信息。教师可以根据统计的人数挑选一定数量的学生，也可以直接在网上公布成绩，让学生直接在网上查询成绩。管理员可以指定每门课程的任课教师，修改课程信息，增加、修改、删除学生信息。分析一：系统应该满足以下几个方面需求： （1）某些选修课程因为前序课程或者教学管理资源的限制，要求系统能对课程选修人数、选修学生年级、专业等进行限制。 （2）选课过程需具有时效性，系统要能在短时间内响应大量学生的查询和选课要求，並及时处理。 （3）教务部门能及时掌握课程选修情况，系统界面直观，操作简单，学生不需经任何培训即可操作。 （4）系统要提供数据输出接口以供教务员作后期处理及保存。包括作为以后查询和评估使用的资料。 分析二：系统要实现的功能分为二大模块： 管理员模块: （1）负责统一管理，包括课程的查询、添加、修改和删除； （2）限制选修条件的管理，包括条件的添加、修改和删除； （3）统一管理用户，包括管理员和学生用户的管理； （4）系统公告的管理； （5）数据的管理和数据导出；
——综合性程序设计 题目：简单学生信息管理系统（序列化版）班级： ： 学号：
实验目的： 1．综合运用输入、输出的知识，用序列化方法保存、读入数组容。 2．设计实现一个简单的信息管理系统。 实验容： 编写能够满足如下条件的程序，分两次四个课时完成 1.声明Student类，该类实现Serializable接口以表明该类可 以进行序列化。该类有、学号、math、os、java用来存放 对应的成绩，在构造方法中进行、学号、课程成绩的赋值。 Override有Object继承来的tostring方法已便友好格式显 示自己的属性； 2.建立一个类，利用数组来存储多个Student，写完一个方法， 在main中写一段测试代码，运行以保证目前所做工作的 正确性，正确后再写其他代码。有以下方法： 1）add(Student stu):增加新的学生，人数满时显示人满或是new一个更长的数组，把现有的Student复制到新 数组 2）dispAll()：可以显示所有的学生信息（测试add是否正确） 3）findById(long id):可以按照学号来查找，然后显示符合条件的学生信息，查无此人的话显示错误信息。 4）findByName(string name):可以按照来查找，然后显示符合条件的学生信息，查无此人的话显示错误信息。 （判断是否相等使用string类的equalsIgnoreCase方 法） 5）delBy Id(long id): 可以按照id来删除学生信息，然后显示找到该人，若查无此人的话显示错误信息。 6）save（）：利用ObjectOutputStream 来把数组写入文件中，需要考虑在什么时候调用该方法。 7）load():利用ObjectIntputStream 来进行反序列化，得到以前保存的容，注意要考虑以前未保存容的情况， 可返回错误信息。 3.在控制台显示一个菜单，并实现相应的功能。菜单如下： 1显示所有学生信息2按学号查找 3 按查找 4 按学号删除 5 保存 6 读入7 退出 请输入数字（1-7）： 程序代码
学生选课管理系统 SANY GROUP system office room 【SANYUA16H-SANYHUASANYUA8Q8-
#include
void InitlistA(Student *stu) { stu->next=NULL; } //初始化课程信息表 void InitlistB(Course *C) { C->next=NULL; } //初始化选课信息表 void InitlistC(SC *S) { S->next=NULL; } //求选课表的深度 int Getlength(SC *S) { int i=0; SC *p; p=S->next; while(p!=NULL) { p=p->next; i ; } return(i); } //用户输入数据建立学生信息表(尾插法) void CreatelistA(Student *stu) { Student *s,*r; int m,i;
北京某企业项目关键节点计划 发展计划控制时间节点分析 1.项目可研报告，报集团批准 2.确定项目启动 3.完成项目团队组建 4.取得土地证 5.净地交付 6.提供用地红线和规划要点 7.完成《某某经营部产品定位报告》，报集团批准 8.完成《某某概念规划设计任务书》 9.完成规划及概念设计，报集团批准 10.《项目投资分析模型（概念版）》——组织概念目标成本测算确认目标成 本及财务指标(一级目标成本)，完成项目经营测算 11.完成建筑方案设计 12.示范区域确定及方案设计确认 13.完成外网配套征询 14.方案设计汇报，报集团批准 15.《项目投资分析模型（方案版）》——组织方案图目标成本测算确认目标 成本及财务指标(二级目标成本)，完成项目经营测算 16.取得建设用地规划许可证 17.完成基坑施工图 18.完成桩基及基础施工图 19.完成样板区施工图、景观、精装修设计 20.完成常规建筑结构水电施工图设计 21.完成景观施工图 22.完成综合管网图设计 23.取得施工图审 24.取得工程规划许可证 25.完成三通一平 26.完成工程策划 27.完成合约规划 28.《项目投资分析模型（目标版）》——组织施工图目标成本测算确认目标 成本及财务指标(三级目标成本)，完成项目经营测算 29.签订总包施工合同 30.取得施工许可证 31.样板区开工 32.取得项目开发贷款 33.基础（土方）工程开工 34.±0米以下结构工程开工、独立地下结构（地库）完工（基础） 35.完成裙房或转换层结构施工 36.首批主体施工达到预售条件 37.首批主体结构封顶 38.全部主体结构封顶
39.首批门窗、栏杆、幕墙等材料进场 40.样板区工程完工、开放 41.各标段取得预售许可证 42.产品定价表，报集团批准 43.销售开盘 44.销售完成30% 45.销售完成50% 46.现金流回正时间 47.销售完成75% 48.销售完成95% 49.第一批外立面落架亮相 50.最后一批外立面落架完成 51.全部单体达竣工条件 52.市政配套埋管完工 53.室外景观、绿化完工(完成项目施工) 54.专项验收结束，取得《竣工备案证明》 55.开始办理集中交房（入伙） 56.办理房产初始登记 57.工程全部结算完成 58.完成收尾及项目财务核算 59.项目后评估
简单学生信息管理系统-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
——综合性程序设计 题目：简单学生信息管理系统（序列化版）班级： 姓名： 学号：
实验目的： 1．综合运用输入、输出的知识，用序列化方法保存、读入数组内容。 2．设计实现一个简单的信息管理系统。 实验内容： 编写能够满足如下条件的程序，分两次四个课时完成 1.声明Student类，该类实现Serializable接口以表明该类可 以进行序列化。该类有姓名、学号、math、os、java用 来存放对应的成绩，在构造方法中进行姓名、学号、课 程成绩的赋值。Override有Object继承来的tostring方法 已便友好格式显示自己的属性； 2.建立一个类，利用数组来存储多个Student，写完一个方 法，在main中写一段测试代码，运行以保证目前所做工 作的正确性，正确后再写其他代码。有以下方法： 1）add(Student stu):增加新的学生，人数满时显示人满或是new一个更长的数组，把现有的Student复制 到新数组 2）dispAll()：可以显示所有的学生信息（测试add是否正确） 3）findById(long id):可以按照学号来查找，然后显示符合条件的学生信息，查无此人的话显示错误信息。 4）findByName(string name):可以按照姓名来查找，然后显示符合条件的学生信息，查无此人的话显示错误 信息。（判断姓名是否相等使用string类的 equalsIgnoreCase方法） 5）delBy Id(long id): 可以按照id来删除学生信息，然后显示找到该人，若查无此人的话显示错误信息。 6）save（）：利用ObjectOutputStream 来把数组写入文件中，需要考虑在什么时候调用该方法。 7）load():利用ObjectIntputStream 来进行反序列化，得到以前保存的内容，注意要考虑以前未保存内容的 情况，可返回错误信息。 3.在控制台显示一个菜单，并实现相应的功能。菜单如 下： 1显示所有学生信息 2按学号查找 3 按姓名查找 4 按学号删除 5 保存 6 读入 7 退出 请输入数字（1-7）：
学生选课系统需求规格说明书
目录 0. 文档介绍 (4) 0.1文档目的 (4) 0.2文档范围 (4) 0.3读者对象 (4) 0.4参考文档 (4) 1.产品介绍 (5) 2.产品面向的用户群体 (6) 3. 产品应当遵循的标准或规范 (7) 4.产品范围 (7) 5. 产品中的角色 (7) 6. 产品的功能性需求 (8) 6.0功能性需求分类 (8) 6.1后台管理功能需求 (8) 6.1.1管理员信息管理 (8) 6.1.2教师信息管理 (10) 6.1.3学生信息管理 (11) 6.1.4课程信息管理 (12) 6.1.5排课管理 (13) 6.1.6教室信息管理 (14) 6.2前台管理功能需求 (15) 6.2.1学生选课 (15) 6.2.2撰写教师反馈 (16) 6.2.3个人信息管理 (17) 6.2.4用户登录 (19) 7. 产品的非功能性需求 (20) 7.1用户界面需求 (20) 7.2软硬件环境需求 (20) 7.3产品质量需求 (20) 7.4其他需求 (21) 附录A：需求建模与分析报告 (22) A.1学生选课系统业务流程图 (22) A.1.1系统总体业务流程分析 (22) A.1.2学生管理业务流程图分析 (23)
A.1.3教师管理业务流程图分析 (24) A.1.4选课/退课子系统业务流程图分析 (25) A.1.5教师反馈子系统业务流程图分析 (26) A.1.6管理员管理业务流程图分析 (26) A.1.7管理员排课业务流程图： (27) A.1.8管理员退课业务流程图： (28) A.2学生选课管理系统数据流程图 (29) A.2.1顶层数据流程图 (30) A.2.2 O层数据流程图 (30) A.2.3后台管理数据流程图 (31) A2.4 前台管理数据流程图 (36) 附录B：需求确认....................................................................................... 错误！未定义书签。
. ——综合性程序设计 题目：简单学生信息管理系统（序列化版）班级： ： 学号：
实验目的： 1．综合运用输入、输出的知识，用序列化方法保存、读入数组内容。 2．设计实现一个简单的信息管理系统。 实验内容： 编写能够满足如下条件的程序，分两次四个课时完成 1.声明Student类，该类实现Serializable接口以表明该类可 以进行序列化。该类有姓名、学号、math、os、java用来 存放对应的成绩，在构造方法中进行姓名、学号、课程成 绩的赋值。Override有Object继承来的tostring方法已便 友好格式显示自己的属性； 2.建立一个类，利用数组来存储多个Student，写完一个方法， 在main中写一段测试代码，运行以保证目前所做工作的 正确性，正确后再写其他代码。有以下方法： 1）add(Student stu):增加新的学生，人数满时显示人满或是new一个更长的数组，把现有的Student复制到新 数组 2）dispAll()：可以显示所有的学生信息（测试add是否正确） 3）findById(long id):可以按照学号来查找，然后显示符合条件的学生信息，查无此人的话显示错误信息。 4）findByName(string name):可以按照姓名来查找，然后显示符合条件的学生信息，查无此人的话显示错误信 息。（判断姓名是否相等使用string类的 equalsIgnoreCase方法） 5）delBy Id(long id): 可以按照id来删除学生信息，然后显示找到该人，若查无此人的话显示错误信息。 6）save（）：利用ObjectOutputStream 来把数组写入文件中，需要考虑在什么时候调用该方法。 7）load():利用ObjectIntputStream 来进行反序列化，得到以前保存的内容，注意要考虑以前未保存内容的情 况，可返回错误信息。 3.在控制台显示一个菜单，并实现相应的功能。菜单如下： 1显示所有学生信息2按学号查找3 按姓名查找 4 按学号删除 5 保存 6 读入 7 退出 请输入数字（1-7）： 程序代码
数据库系统原理及其应用教程 课程设计报告 设计题目选修课程管理系统的设计与实现 指导教师
摘要 随着计算机技术的日新月异，极大的推动的各个行业的信息化进程。各大高校也急需进行信息化改革，以促进教学质量和工作效率快速提升。 本文是在对各大高校全校公开课学生选课情况进行实地调查后，进行详细分析讨论后撰写的学生选课管理系统数据库设计报告。全文从最初的系统规划，到需求分析、概念设计、逻辑设计、物理设计。每一阶段都进行了详细的分析。接下来的实现、运行与维护阶段，还
进行了对本系统的测试，最后是本次项目开发的心得和体会以及本文的参考文献。 本系统主要功能是对学生选课及相关信息进行管理。较行业同类产品而言，本系统人机界面设计更加合理、人性化，用户操作简单方便。数据库的安全性更高，对用户访问权限进行了严格控制。数据存取速度更快，使用年限更长。可以很好的满足高校公开课学生选课的要求，极大的提高了学校的工作效率。 关键字：学生选课管理系统；分析；设计 目录 一、概述 (4) 1.1 设计背景 (34) 1.2 设计目的 (36) 1.3 设计内容 (39) 二、需求分析 (19) 2.1 功能分析 (7) 2.2 工作流图 (6) 2.3 数据流图 (7)
2.4 数据字典 (16) 三、概念模型设计 (18) 3.1 实体之间的联系 (18) 3.2 E-R图 (19) 四、逻辑设计 (26) 4.1 概念模型向关系模型的转换 (26) 4.2 概念模型的优化 (27) 五、源代码及查询截图 (29) 5.1 数据库的存储结构 (29) 5.2 实现 (32) 5.3 人机界面设计 (34) 5.4 系统测试 (36) 5.5 运行维护 (39) 六、总结 (40) 参考文献 (41) 一、概述 1.1设计背景 可行性研究的目的是用最小的代价在尽可能的短的时间内确定数据库系统是否可能开发、是否值得开发、是否可以开发（在该报告中主要是考查《学生选课管理系统》是否可能开发、是否值得开发、是否可以开发）。其实质是在较高层次上以较抽象方式进行的、简化的压缩的需求分析和概要设计过程。
#include
1引言 (2) 1.1编写目的 (2) 1.2背景 (2) 1.3定义 (2) 1.4参考资料 (2) 2程序系统的结构 (3) 3程序1（标识符）设计说明 (7) 3.1程序描述 (7) 3.2功能 (8) 3.3性能 (8) 3.4输人项 (8) 3.5输出项 (9) 3.6算法 (9) 3.7流程逻辑 (9) 3.8接口 (10) 3.9存储分配 (11) 3.10注释设计 (11) 3.11限制条件 (11) 3.12测试计划 (11) 3.13尚未解决的问题 (11) 4程序2（标识符）设计说明....................................................................... 错误！未定义书签。
详细设计说明书 1引言 1.1编写目的 该详细设计说明书的目的在于根据需求说明书与概要设计说明书提出该系统的详细设计，即系统的详细架构，主要包括系统的模块划分、程序系统的结构、各个模块的流程以及各层次中每个程序的设计考虑。 1.2背景 软件系统名称：学生选课系统 软件实现计算机：方正科技 与其他系统和机构的相互管理：暂无。 1.3定义 图1 程序数据字典定义 1.4参考资料 1.《软件工程导论》（张海藩编著清华大学出版社2007年5月） 2.《数据库系统概论（第四版）》（王珊编著高等教育出版社2007年11月）
3．《Visualbasic程序设计》（吴定雪主编科学出版社） 2程序系统的结构 2.1 、管理员模块程序设计说明 ①人员管理：管理员在登录之后可以对系统内的人员（包括学生、教师等）进行管理， 包括对人员的信息进行查询、修改和删除等操作。 ②课程管理：管理员在后台添加、编辑课程的基本信息（包括授课教师、开课时间设定）， 同时可以编辑系统开放选课的时间，在适当时间开启和关闭选课系统。 ③系统信息管理：管理员可对系统的基本信息进行编辑，对系统公告进行更改或者系统 标题、系统相关链接等。 ④系统权限管理：对不同的用户要分配不同的权限，管理员可设定不同人员对不同模块 的访问权限，允许或者拒绝不同用户对模块的增删查改操作。 图2.1管理员模块图 2.2、教师模块程序设计说明 （1）基本信息管理：此模块主要实现两个分支功能： ①个人信息修改和密码修改。在教师用户登录状态下，实现这些功能，通过对自己 的注册信息的修改满足用户的个性需求，能将注册信息及时反映个人状态，另外，密码修改则是很多网站都应具备的基本功能，能有效保护用户身份和网络安全。 ②其它基功能如学生查询，教师查询和留言查询，这三个功能都是在教师在线状态
软件项目管理 学生选课管理系统 项目名称： 组长 组员 提交时间： 2015年6月15日
学生选课管理系统 项目任务书 一、目的、要求 通过软件开发的实践训练，进一步掌握软件项目管理的方法和技术，提高软件开发的实际能力，培养工程设计能力和综合分析、解决问题的能力。 具体如下： 1.学习和实践在分析和设计计算机应用系统所需要的知识,包括面向对象 的系统分析与设计,软件项目管理，编码和测试方面的知识； 2.熟悉自动化的软件开发工具Rational Rose 2003，并将其运用于软件 开发的全过程； 3.进一步加强和提高软件工程文档的编写能力； 4.培养协作能力和团队精神。 二、主要内容 1．课题题目：学生选课系统，本系统要实现学生选课的基本功能，包括学生退选课，查看自己的选课信息；教师查看选课学生的信息，提交成绩； 管理员添加学生、管理学生、管理成绩、添加教师、管理教师和管理课 程等。 2．运用面向对象技术、UML及可视化的建模工具完成系统的需求分析与设计。 3．使用Rational Rose作为需求分析与设计的建模工具，包括静态建模和
动态建模，并利用对象模型自动生成数据模型,自动建立数据库。 4．采用分层模式的应用设计模式进行系统的设计实现。 5．系统要实现四个模块功能：教师模块、学生模块、管理员模块和公用模块。 6．初步建立系统原型，实现关键的功能，并对系统进行测试。 三、任务分配
学生选课管理系统 任务分解书（WBS）一．学生选课管理系统任务分解 1.1.1 项目规划 1.1.2 计划评审 1.2 需求开发 1.2.1 用户界面设计 1.2.2 用户需求评审 1.2.3 修改需求、修改用户界面 1.2.4 需求规格说明书 1.2.5 编写需求获取方法 1.2.6 编写需求跟踪矩阵 1.3 设计 1.3.1 概要设计 1.3.2 详细设计
《软件综合设计》课程实验报告
4、实验内容 1、实验步骤及流程： 1)新建工程：新建一个单文件类型的MCF工程，在Resource之中新建并利用控件设计对话框。 2)增加控件：一个控件是能够放置在一个对话框中，提供应用程序与用户交互的某种功能。本次 实验需要添加编辑框、下拉列表控件、列表框（ListBox）控件以及按钮键。 3)设置对话框及控件等的属性：一个控件相关的属性设置决定了一个控件可操作行为和显示。修 改控件ID以及名称，对话框名称等。 4)组织和安排各部件的位置大小等：软件为我们提供了各种调整方式，如：左对齐、右对齐、宽 相等、水平居中等等。 5)设置控件的顺序：执行菜单命令Layout->Tab Order可以显示并修改Tab Order，按所想要的 访问顺序依次点击每一个控件，完成后，点击空白处就可以了。 6)为对话框成员添加变量：打开ClassWizard窗口，选择Member Variables标签页，Class name下拉列表中选择CScoreDlg类。则对话框中可以创建成员变量的控件ID出现在下方的 Control IDs列表中。单击Add Variable按钮，则弹出Add Member Variable对话框，设置 变量名即可。 7)对话框类的构造函数：双击各个控件并确定就会弹出编程界面，为各个控件添加函数程序，实 现它们所对应的功能。 8)运行程序，调试程序。 2、源程序代码： 见后：实验结果及分析
3、调试过程记录： 在调试程序的时候，我们必须使程序在某一地点停下来。即是设立断点，其次再运行程序；当程序在设立断点处停下来时，利用各种工具观察程序的状态。程序在断点停下来后，有时我们需要按我们的要求控制程序的运行，以进一步观测程序的流向，从而调试程序。 逐步完善对话框的内容，加入控件，编写程序：
生产计划一级节点标准 为进一步加强对计划落实工作的考核力度，保证生产经营工作按公司计划得到有效落实，从而促进公司快速、健康发展，特对房地产开发流程中重要工程建设节点的完成标准强调说明如下： 一、总规报批：指“拟开工项目总规手续完备，项目后续工作能够紧前进行。 （一）项目总规报批需完善的手续： 1、土地出让合同签订完成，经过确权，办理完成国有土地使用权证； 2、拟开项目市场定位报告完成公司审批； 3、项目预算通过公司审批完成； 4、规划方案通过公司及政府的批复，完成政府图审盖章，具备施工图设计的条件； 5、完成建设用地规划许可证的办理。 二、施工图纸：指“项目单体各专业施工图纸（建筑、结构、水暖、电等）设计完成，并通过分公司的内部审核及政府的图审后，施工图纸到达总部预结算部”。 该节点包含内容有： （一）项目所在地块完成地勘并出具正式地勘报告。 （二）项目各专业图纸符合施工图设计深度及标准（根据开发进度及批次划分，外线、园林图纸可适当后延，在主体封顶前完成即可）； （三）项目各专业图纸经分公司内审，并根据内审意见调整完成。 （四）项目各专业图纸完成图纸外审，并根据审核意见调整完成，取得图审合格证。 （五）完整的施工图纸到达总部预结算部，并具备施工图预算的条件。 三、预算：指“项目各专业预算工作完成，预算成果满足招标采购需求”。 该节点包含内容有： （一）根据项目标段及各专业界面划分完成预算委托并签订委托合同。
（二）根据预算委托完成项目预算，成果经公司预决算部审核并经采购部确认，满足项目招标采购需求。 四、单规：指“完成批次开发内各单体建设工程规划许可证的办理”。 该节点包含内容有： （一）根据当地政府主管部门要求，完成相应报批文件资料及费用的缴纳。 （二）单规报批完成，并取得建设工程规划许可证。 五、招标：指“在总部职能部门的监督下，在经分公司考察合格的总包供应商选择范围内，完成对拟开批次的总包供应商的选择，完成公司定标报告的审批”。 所有投标单位必须经过以分公司生产副总为第一责任人的招标小组的考察，完成相应的招标文件、定标报告。 六、项目开工：指“开工手续完备，或拟开工项目现场有实际开工动作能够保证连续生产这一系列事件的总和”。 （一）项目开工前应完备以下开工手续： 1、国有土地使用权证； 2、建设用地规划许可证； 3、建设工程规划许可证； 4、建筑工程施工许可证； （二）项目现场实际开工动作为下列情况之一： 1、破土开槽； 2、桩基施工； 3、褥垫层施工； （三）项目能够保证连续生产的条件有： 1、总包合同签订，施工单位现场管理人员已到位，主要机械、机具、施工人员已进场； 2、监理机构已进驻现场； 3、由建设单位、监理单位、施工单位和设计单位参加的图纸会审已经完成；
C++学生成绩管理系统 要求用C++语言编写学生成绩管理系统，要求能进行添加删除修改输入输出等的操作，并能使用面相对像原理对此系统进行实现。 学生成绩管理系统分析： 学生成绩管理系统分为8个模块，分别是：添加学生信息，输出学生成绩，查找学生成绩，修改学生成绩，删除学生成绩，学生成绩排序，保存数据到文件和读取文件中学生成绩的模块。 学生成绩管理系统结构：
各个子函数功能及其流程： 1.首先定义一个学生类Class Student；并定义其各个私有变量和公有函数 2.Student（）；构造函数，用于初始化学生类中的各个变量并记录 3.Add（）；函数：用于添加学生信息的函数包括学号姓名成绩等的内容 4.Output（）；函数：用于输出学生信息，包括学号姓名各科及总分平均成绩
5.Find（）；函数：用于查找学生各项信息。 6.modify();函数：用于修改学生各项信息。 7.delete();函数：用于删除学生信息。
();函数：对学生各项信息进行排序操作。 8.save()和load();函数：将学生信息保存到文件中，并在需要的时候调用该文件将 其中的学生信息显示出来
9.“=”“<<”“>>”符号的重载：在各个函数处理数据过程中对这些的调用处理 函数源代码： 此函数源代码在VisualC++环境下编译通过。具体如下: #include"" #include"" #include"" #include"" #include"" #include"" #include"" class student ame,n1)==0) { temp=stu[j]; f3=1; } } if(f3==0) cout<<"对不起，没有你要查找的学生成绩"< 学生选课系统详细设计说明书 一、编写目的 该详细设计说明书的目的在于根据需求说明书与概要设计说明书提出该系统的详细设计，即系统的详细架构，主要包括系统的模块划分、程序系统的结构、各个模块的流程以及各层次中每个程序的设计考虑。 二、背景 软件系统名称：学生选课系统 软件实现计算机：LENOVO 三、管理员模块程序设计说明 ①人员管理：管理员在登录之后可以对系统内的人员（包括学生、教师等）进行管理，包 括对人员的信息进行查询、修改和删除等操作。 ②课程管理：管理员在后台添加、编辑课程的基本信息（包括授课教师、开课时间设定）， 同时可以编辑系统开放选课的时间，在适当时间开启和关闭选课系统。 ③系统信息管理：管理员可对系统的基本信息进行编辑，对系统公告进行更改或者系统标 题、系统相关链接等。 ④系统权限管理：对不同的用户要分配不同的权限，管理员可设定不同人员对不同模块的 访问权限，允许或者拒绝不同用户对模块的增删查改操作。 四、教师模块程序设计说明 （1）基本信息管理：此模块主要实现两个分支功能： ①个人信息修改和密码修改。在教师用户登录状态下，实现这些功能，通过对自己的注 册信息的修改满足用户的个性需求，能将注册信息及时反映个人状态，另外，密码修改则是很多网站都应具备的基本功能，能有效保护用户身份和网络安全。 ②其它基功能如学生查询，教师查询和留言查询，这三个功能都是在教师在线状态下实 现的。学生查询对于教师来说非常实用，如果教师想要某个学生的基本信息，只要登录查询就可以找到目标学生，此模块目的在于让老师更方便的掌握学生的基本信息以备不时之需，用以师生交流上非常方便；教师查询对于同事间的交流和联系会显得很重要，这个分支模块主要在于促进同事之间的了解和及时沟通，以便得到共同关心的话题并进行探讨；而留言查询，此模块是则实现师生，同事以及个体之间的交流实现了一个更好的交流平台。 （2）资料管理： 随着教师办公信息化的发展，教师对网络的以来与日俱增，自己的授课计划以及出行安排都会及时更新在自己的平台上，这种平台包括个人博客，此模块的涉及就在于想把学校的办公平台向个人博客过渡，让老师的工作伴随自己的个性体现。 （3）成绩录入： 对于在本教师选课范围内的学生，教师可以查看学生的基本信息，并对学生成绩进行登记和更改。 数学与计算机学院 课程设计说明书 课程名称: JA V A数据库网络综合课程设计 课程代码: 题目: 选修课程管理系统 年级/专业/班: 2012级计科3班 学生姓名: 徐茂淋 学号: 312012********* 开始时间:2014 年12月2日完成时间:2014年12月28日课程设计成绩： 指导教师签名：年月日 数学与计算机学院 课程设计任务书 （ 2014/ 2015学年第1学期） 专业：计算机科学与技术 年级：2012 课程名称：JA V A数据库网络综合课程设计 课程代码： 一、设计题目 选修管理系统 二、主要内容 调查学校教务处，设计用于管理全校学生选修课活动的系统。主要功能有： 1.全校选修计划课程管理； 2.全校选修开课课程管理； 3.全校学生选课管理； 4.全校选修课成绩管理； 5.打印报表； 6.系统维护，如数据安全管理（含备份与恢复）、操作员管理、权限设置等； 要求： 1.设计学生选课录入界面及学生选课查询界面； 2.设计课程输入界面和学生选课表及课程选修情况查询界面； 3.根据学生库和课程库，输出学生课程表（选课冲突时按学号分配课程）； 三、具体要求 1.对系统作需求分析和数据库逻辑结构设计。 2.设计出ER模型，并完整标明每个实体型的相关属性，推荐使用Erwin实现。 3.利用前台开发工具，完成对每个实体型中实体数据的查询和编辑操作，并提 供相应的界面。 4.源代码格式规范，注释不少于三分之一. 5.提交完整程序代码、课程设计报告及相关文档；给出系统需求分析和数据库 6.逻辑结构设计；总结开发语言与后台数据库之间的连接形式；总结程序开 发过程中系统函数、存储过程、触发器等后台数据库对象在开发过程中的调用情况（如果没有使用，可不写）；设计中遇到的问题，设计的心得体会； 调试所遇到的问题等。 四、成果及应提交材料 1．源程序一份 2．课程设计报告一份 五、主要技术路线提示 后台推荐采用SQL server或Oracle；前台开发环境为JAVA。 用前台开发工具开发相应系统，学习开发工具与数据库的连接，可采用ADO，ODBC，OLE DB或JDBC连接数据库，并调用系统存储过程、自定义存储过程、函数等。 六、进度安排 第12周：数据库系统概念模型、数据模型设计，创建数据库以及相关对象； 第13周：前台程序开发，撰写报告，接受检查。 七、推荐参考资料 1.王珊、萨师煊，数据库系统概论，高等教育出版社. 2006.5 2. 李刚等，Java程序员之旅--Java数据库技术详解，化学工业出版社，2011.4 3、姜中华，刘小春，Java 数据库应用程序设计，机械工业出版社，2008.4 4、软件开发技术联盟，Java Web开发实践，清华大学出版社，2013.9 指导教师签名日期年月日 系主任审核日期年月日 江西抚州供电公司 电网建设项目里程碑节点实施办法 第一章总则 第一条依据赣电规〔2009〕37号《关于下达2009年电网建设项目里程碑节点计划的通知》，为使电网规划和投资计划有效衔接，合理科学地安排电网建设时序，协调工程前期、招标、施工、投产等各环节间的关系，明确各部门、各单位的职责，进一步强化电网建设过程控制，制定本办法。 第二条各部门、各单位要高度重视做好电网建设项目里程碑节点计划工作，按照责任划分和属地化管理原则，进一步细化项目节点计划，合理安排工程进度，落实责任，强化考核。 第三条电网建设项目里程碑节点管理的职能部门为基建（规划投资）部，里程碑节点详细计划由基建（规划投资）部在年初根据省公司的里程碑节点计划进行细化后提出，各责任部门节点计划完成时间纳入公司绩效考核。 第四条本办法适用于公司系统110kV及以上的输变电 工程。 第二章管理职责 第一条设计招标申请：由基建（规划投资）部在公司电网建设项目里程碑节点计划安排时间内，向省公司规划投资部递交设计招标申请，延期纳入公司绩效考核。 第二条设计招标：由基建（规划投资）部及时与省公司 规投部、招标中心联系、沟通，催促设计招标在节点计划安排时间内完成。 第三条可研报告完成：由基建（规划投资）部督促设计单位在规定时间内完成可研设计，报送省公司规投部，催促并协助省公司规投部组织完成可研设计审查。 设计单位未按时上报，延期按合同考核（如公司电力勘察设计院设计，延期按合同考核外，并对其进行绩效考核），由于其它原因未按时上报，对责任部门进行绩效考核。 第四条可研审批：由基建（规划投资）部及时与省公司规投部联系、沟通，催促下达可研审批。 第五条初设报告完成：由基建（规划投资）部督促设计单位在规定时间内完成初步设计，报送省公司基建部，催促并协助省公司基建部组织完成初步设计审查。 设计单位未按时上报，延期按合同考核（如公司电力勘察设计院设计，延期按合同考核外，并对其进行绩效考核），由于其它原因未按时上报，对责任部门进行绩效考核。 第六条初设审批：由基建（规划投资）部及时与省公司基建部联系、沟通，催促下达初设审批。 第七条主要设备招标：由基建（规划投资）部督促设计单位在规定时间内完成设备招标申请及设备标书的上报，物资供应中心根据省公司招标中心的招标总结表、中标通知书负责追踪、联系、签订商务合同并负责催货。 设计单位未按时上报，延期按合同考核（如公司电力勘察学生选课系统详细设计说明书
选课管理系统分析
项目里程碑节点实施办法行文稿
相关主题
文本预览