2016级程序设计课程设计题目安排201703
2016c 课设任务书详解
《面向对象程序设计》课程设计任务书学期：2016-2017 第一学期时间2016年12月12日开始班级：15计科本1、本2、15计应专1机电与信息工程学院教师陈小常【设计目的】本课程设计是计算机科学与技术专业重要的实践性环节之一，是在学生学习完《面向对象程序设计》课程后进行的一次全面的综合练习。
本课程设计的目的和任务：（1）巩固和加深学生对C++课程的基本知识的理解和掌握；（2）掌握C++编程和程序调试的基本技能；（3）利用C++进行简单软件设计的基本思路和方法；（4）提高运用C++解决实际问题的能力；（5）掌握书写程序设计说明文档的能力。
课设报告要求：1、封面上写明：题目、指导教师、专业、班级、姓名、学号、起止日期以及其他内容。
2、在实习报告的扉页上写明设计题目和实习报告要求。
3、系统需求与功能分析，画出功能结构图。
4、各个类的设计思路及其源代码，并适当加以注释。
5、主要功能代码的实现思路及测试过程描述。
6、程序调试正确后的运行结果显示。
7、程序设计中所遇到的问题及解决问题的办法。
8、整个应用程序还需作哪些改进。
9、课程设计的感想和体会。
【设计内容与任务】每组学生在教师提供的课程设计题目中任意选择一题，题目有难有易，学生根据自身情况选题后独立完成，每组成员限定1——4人。
题目选定后不可更换。
题目1 组合类与排序目的与要求：通过类的组合，可以将现有的若干个类合成一个新类，它反映的是对象的组合概念，由小类装成更大的类。
类组合的难点在于其构造函数（包括析构函数）设计。
本实验要求学会创建组合类对象、删除组合类对象时，如何创建（删除）其内嵌对象，这里包括参数的传递、构造的顺序等。
设计任务及过程任务：设计计算机类分解为显示器类、CPU类、硬盘类、主板类、内存类、显卡类等；然后按CPU价格排序（升序）。
过程：数据输入每台主机CPU有自己的数据如主频、频率、价格、日期等；数据存储日期类、CPU类、RAM类、一台主机类、N台主机类；数据处理即排序算法，使用算法对记录进行排序题目2拷贝构造函数与对象复制目的与要求：1、了解拷贝构造函数的含义；2、了解拷贝构造函数的相关语法规则；3、学会运用拷贝构造函数；设计任务及过程任务：以具体对象为列，讨论同类对象的赋值与复制。
2016高级语言程序设计考卷B及参考答案
二
三
四
五
六 合计
满分 28
24
18
30
100
得分
专业 班级
得分
一、单项选择题 （本大题共 14 小题，每小题 2 分，共 28 分）
在每小题列出的四个备选项中只有一个是符合题目要求的，请将所选代码填写在下面
表格中的对应位置。错选、多选或未选均无分。
1 2 3 4 5 6 7 8 9 10 11 12 13 14
A．x
B．p
C．&x
D．&*p
12．设 char s［10］，*p=s； 下列语句中错误的是
A．p=s+5；
B．*p=s[0]； C．s[2]=p[4]； D．s=p+5；
13．在 C++中，函数的形式参数是 A．局部变量 B．全局变量
C．静态变量
D．外部变量
14．有以下定义和语句
int a[3][2]={1,2,3,4,5,6,}，*p[3]；
1 --> 2 --> 3 --> 4 --> 5 --> 6。 #include <iostream.h> struct Node { int data;
Node *next; }; typedef Node * LinkList; void print(LinkList head) { Node *p; if (head==NULL) return; p=head; while (p->next) { cout<<p->data<<" --> ";
sum2+=f2(i); cout<<"S1="<<sum1<<",S2="<<sum2<<endl; return 0; }
《程序设计课程设计》指导书2016(1)
程序设计课程设计指导书软件学院计算机工程系2016年6月15日前言《程序设计课程设计》是计算机科学与技术专业的重要实践性课程。
目的在于培养学生分析问题和解决问题的能力，为学生提供了一个既动手又动脑，独立实践的机会。
将课本上的数据结构、离散数学和C语言的理论知识和实际应用问题进行有机结合，提高学生程序设计、程序调试及项目开发能力。
为后续课程：操作系统、软件工程，编译原理等课程的学习奠定必要的实践基础。
本课程设计是利用数据结构、离散数学、C语言理论和实验课中学到的编程知识和编程技巧，通过布置具有一定难度、一定编程量的课程设计题目，利用C语言作为开发工具，使学生通过课程设计掌握高级编程语言的知识和编程技术，掌握程序设计的思想和方法，初步具备利用计算机求解实际问题的能力。
通过《程序设计课程设计》课程的学习，能够帮助学生加深理解数据结构、离散数学、C语言基本概念，达到培养学生良好程序设计的习惯和运用 C 语言编写程序解决实际问题的能力。
使学生学会把书本知识用于解决实际问题，起到深化理解和灵活掌握教学内容的目的。
同时使学生在程序设计方法及上机操作等基本技能和科学作风方面受到比较系统和严格的训练。
通过该课程设计，学生应该掌握C或C++语言程序设计的方法、数据结构和离散数学理论知识，熟悉C或C++程序的开发环境及C或C++程序的调试过程，巩固和加深对理论课中知识的理解，提高学生对所学知识的综合运用能力；学生应该具有如下基本技能：①培养学生查阅参考资料、手册的自学能力，通过独立思考深入钻研问题，学会自己分析、解决问题。
②通过对所选题目方案分析比较，确立方案，编制程序与调试程序。
③能熟练调试程序，在教师的指导下，完成课题任务。
④根据个人的设计调试过程，按课程设计报告的要求撰写设计报告。
选用教材及主要参考书：1 教材呼克佑. C语言程序设计电子工业出版社,2013严蔚敏. 数据结构(C语言版) 清华大学出版社，2012目录前言 (1)一．课程设计报告要求 (1)二．课程设计报告示例——迷宫问题(参考) (2)三．设计题目（6选4） (8)1．消除类游戏 (8)2．数字统计 (9)3．画图 (10)4．构造可以使n个城市连接的最小生成树 (12)5．送货 (13)6．学生管理系统 (15)一．课程设计报告要求课程设计报告封面应给出专业、班级、姓名、学号、指导教师和完成日期，报告开头给出题目，内容包括以下几项：1．【问题描述】简要描述问题，然后说明程序设计的任务，程序要做什么。
2016c++课程设计
2016年软件学院C++课程设计课程设计目的：1、熟悉利用面向对象的方法以及C++的编程思想来完成系统的设计；2、锻炼学生在设计的过程中，建立清晰的类层次，应用继承和多态等面向对象的编程思想；3、通过本课程设计，加深对面向对象程序设计课程所学知识的理解，熟练掌握和巩固C++语言的基本知识和语法规范,深刻体会面向对象的编程思想，掌握使用面向对象程序设计语言C++，学会编写结构清晰、风格良好的C++语言程序，从而具备利用计算机编程分析解决综合性实际问题的初步能力。
课程设计题目：模拟即时通信系统实现一、题目描述基于社交的即时通信是腾*公司的主要业务，先后有QQ、微信、微博等服务，可能还将继续推出微商、微唱、微走、微笑等产品。
这些软件既可以独立提供服务，又互相辉映关联。
腾*公司希望对各系统进行整合形成统一的立体社交软件平台。
现请完成该平台的设计并实现。
要求如下：1、用户基本信息：号码ID，昵称，出生时间，T龄（号码申请时间）、所在地、好友列表、群列Id name DATE a DATE b Address // LIST_1 a(关联MonkeyQ指针) LIST b（群指针）表。
微博与QQ共享ID，微信采用独立ID，但是可以与QQ号码绑定对应。
其他微X产品也分为这两种情况。
2、好友管理（1）实现各功能好友信息的添加、修改、删除、查询的功能。
（2）可以查询微X之间各自共同好友。
如微信可以添加QQ推荐好友。
3、群管理（1）设定每个微X功能已有1001、1002、1003、1004、1005、1006等群号。
（2）加入群、退出群、挨T、查询群成员等。
（3）不同微X之间群的理念不同，比如：QQ群可以申请加入，而微信群则只能推荐加入；QQ群允许设置临时讨论组（子群），微信群则不允许；QQ群有以群主为核心的管理员制度而微信群仅有群主为特权账号。
4、开通管理用户可以选择自己开通该平台的N个微X服务。
5、登录管理各微X之间只要有一个服务登录，则其它服务简单确认后视为自动登录。
2016年软件工程课程设计题目
College of Computer Science & Technology2016 Software Engineering Practice Project2016.5.30 - 2016.6.24Course Registration RequirementsProblem StatementAs the head of information systems for Wylie College you are tasked with developing a new student registration system. The college would like a new client-server system to replace its much older system developed around mainframe technology. The new system will allow students to register for courses and view report cards from personal computers attached to the campus LAN. Professors will be able to access the system to sign up to teach courses as well as record grades.Due to a decrease in federal funding, the college cannot afford to replace the entire system at once. The college will keep the existing course catalog database where all course information is maintained. This database is an Ingres relational database running on a DEC VAX. Fortunately the college has invested in an open SQL interface that allows access to this database from college’s Unix servers. The legacy system performance is rather poor, so the new system must ensure that access to the data on the legacy system occurs in a timely manner. The new system will access course information from the legacy database but will not update it. The registrar’s office will continue to maintain course information through another system.At the beginning of each semester, students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites, will be included to help students make informed decisions.The new system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case the student cannot be assigned to a primary selection. Course offerings will have a maximum of ten students and a minimum of three students. A course offering with fewer than three students will be canceled. For each semester, there is a period of time that students can change their schedule. Students must be able to access the system during this time to add or drop courses. Once the registration process is completed for a student, the registration system sends information to the billing system so the student can be billed for the semester. If a course fills up during the actual registration process, the student must be notified of the change before submitting the schedule for processing.At the end of the semester, the student will be able to access the system to view an electronic report card. Since student grades are sensitive information, the system must employ extra security measures to prevent unauthorized access.Professors must be able to access the on-line system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offerings. In addition, the professors will be able to record the grades for the students in each class.GlossaryIntroductionThis document is used to define terminology specific to the problem domain, explaining terms, which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions andother project documents can focus on what the system must do with the information.DefinitionsThe glossary contains the working definitions for the key concepts in the Course Registration System.CourseA class offered by the university.Course OfferingA specific delivery of the course for a specific semester – you could run the same course in parallelsessions in the semester. Includes the days of the week and times it is offered.Course CatalogThe unabridged catalog of all courses offered by the university.FacultyAll the professors teaching at the university.Finance SystemThe system used for processing billing information.GradeThe evaluation of a particular student for a particular course offering.ProfessorA person teaching classes at the university.Report CardAll the grades for all courses taken by a student in a given semester.RosterAll the students enrolled in a particular course offering.StudentA person enrolled in classes at the university.ScheduleThe courses a student has selected for the current semester.TranscriptThe history of the grades for all courses, for a particular student sent to the finance system, which in turn bills the students.Supplementary SpecificationObjectivesThe purpose of this document is to define requirements of the Course Registration System. ThisSupplementary Specification lists the requirements that are not readily captured in the use cases of the use-case model. The Supplementary Specifications and the use-case model together capture a complete set of requirements on the system.ScopeThis Supplementary Specification applies to the Course Registration System, which will be developed by the OOAD students.This specification defines the non-functional requirements of the system; such as reliability, usability,performance, and supportability, as well as functional requirements that are common across a number of use cases. (The functional requirements are defined in the Use Case Specifications.)ReferencesNone.FunctionalityMultiple users must be able to perform their work concurrently.If a course offering becomes full while a student is building a schedule including that offering, the student must be notified.UsabilityThe desktop user-interface shall be Windows 95/98 compliant.ReliabilityThe system shall be available 24 hours a day 7 days a week, with no more than 10% down time.PerformanceThe system shall support up to 2000 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time.The system shall provide access to the legacy course catalog database with no more than a 10 secondlatency.Note: Risk-based prototypes have found that the legacy course catalog database cannot meet ourperformance needs without some creative use of mid-tier processing powerThe system must be able to complete 80% of all transactions within 2 minutes.SupportabilityNone.SecurityThe system must prevent students from changing any schedules other than their own, and professors from modifying assigned course offerings for other professors.Only Professors can enter grades for students.Only the Registrar is allowed to change any student information.Design ConstraintsThe system shall integrate with an existing legacy system, the Course Catalog System, which is an RDBMS database.The system shall provide a Windows-based desktop interface.Use-Case ModelCourse Registration System Use-Case Model Main DiagramClose RegistrationBilling SystemClose RegistrationBrief DescriptionThis use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering.Flow of EventsBasic FlowThis use case starts when the Registrar requests that the system close registration.1. The system checks to see if registration is in progress. If it is, then a message is displayed to the Registrar, andthe use case terminates. The Close Registration processing cannot be performed if registration is in progress. 2. For each course offering, the system checks if a professor has signed up to teach the course offering and at leastthree students have registered. If so, the system commits the course offering for each schedule that contains it.3. For each schedule, the system “levels” the schedule: if the schedule does not have the maximum number ofprimary courses selected, the system attempts to select alternates from the schedule’s list of alternates. The first available alternate course offerings will be selected. If no alternates are available, then no substitution will be made.4. For each course offering, the system closes all course offerings. If the course offerings do not have at leastthree students at this point (some may have been added as a result of leveling), then the system cancels the course offering. The system cancels the course offering for each schedule that contains it.5. The system calculates the tuition owed by each student for his current semester schedule and sends a transactionto the Billing System. The Billing System will send the bill to the students, which will include a copy of their final schedule.Alternative FlowsNo Professor for the Course OfferingIf, in the Basic Flow, there is no professor signed up to teach the course offering, the system will cancel the course offering. The system cancels the course offering for each schedule that contains it.Billing System UnavailableIf the system is unable to communicate with the Billing System, the system will attempt to re-send therequest after a specified period. The system will continue to attempt to re-send until the Billing Systembecomes available.Special RequirementsNone.Pre-ConditionsThe Registrar must be logged onto the system in order for this use case to begin.Post-ConditionsIf the use case was successful, registration is now closed. If not, the system state remains unchanged.Extension PointsNone.LoginBrief DescriptionThis use case describes how a user logs into the Course Registration System.Flow of EventsBasic FlowThis use case starts when the actor wishes to log into the Course Registration System.1. The actor enters his/her name and password.2. The system validates the entered name and password and logs the actor into the system.Alternative FlowsInvalid Name/PasswordIf, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an errormessage. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends.Special RequirementsNone.Pre-ConditionsThe system is in the login state and has the login screen displayed.Post-ConditionsIf the use case was successful, the actor is now logged into the system. If not, the system state is unchanged.Extension PointsNone.Maintain Professor InformationBrief DescriptionThis use case allows the Registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system.Flow of EventsBasic FlowThis use case starts when the Registrar wishes to add, change, and/or delete professor information in the system. 1. The system requests that the Registrar specify the function he/she would like to perform (either Add aProfessor, Update a Professor, or Delete a Professor)2. Once the Registrar provides the requested information, one of the sub flows is executed.If the Registrar selected “Add a Professor”, the Add a Professor subflow is executed.If the Registrar selected “Update a Professor”, the Update a Professor subflow is executed.If the Registrar selected “Delete a Professor”, the Delete a Professor subflow is executed.Add a ProfessorThe system requests that the Registrar enter the professor information. This includes:- name- date of birth- social security number- status- department1. Once the Registrar provides the requested information, the system generates and assigns a unique idnumber to the professor. The professor is added to the system.2. The system provides the Registrar with the new professor id.Update a Professor1. The system requests that the Registrar enter the professor id.2. The Registrar enters the professor id. The system retrieves and displays the professor information.3. The Registrar makes the desired changes to the professor information. This includes any of theinformation specified in the Add a Professor sub-flow.4. Once the Registrar updates the necessary information, the system updates the professor record.Delete a Professor1. The system requests that the Registrar enter the professor id2. The Registrar enters the professor id. The system retrieves and displays the professor information.3. The system prompts the Registrar to confirm the deletion of the professor.4. The Registrar verifies the deletion.5. The system deletes the professor from the system.Alternative FlowsProfessor Not FoundIf, in the Update a Professor or Delete a Professor sub-flows, a professor with the specified id number does not exist, the system displays an error message. The Registrar can then enter a different id number or cancel the operation, at which point the use case ends.Delete CancelledIf, in the Delete A Professor sub-flow, the Registrar decides not to delete the professor, the delete iscancelled, and the Basic Flow is re-started at the beginning.Special RequirementsNone.Pre-ConditionsThe Registrar must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, the professor information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.Extension PointsNone.Maintain Student InformationBrief DescriptionThis use case allows the Registrar to maintain student information in the registration system. This includes adding, modifying, and deleting Students from the system.Flow of EventsBasic FlowThis use case starts when the Registrar wishes to add, change, and/or delete student information in the system.1. The system requests that the Registrar specify the function he/she would like to perform (either Add a Student,Update a Student, or Delete a Student)2. Once the Registrar provides the requested information, one of the sub flows is executed.If the Registrar selected “Add a Student”, the Add a Student subflow is executed.If the Registrar selected “Update a Student”, the Update a Student subflow is executed.If the Registrar selected “Delete a Student”, the Delete a Student subflow is executed.Add a Student1. The system requests that the Registrar enter the student information. This includes:- name- date of birth- social security number- status- graduation date2. Once the Registrar provides the requested information, the system generates and assigns a unique idnumber to the student. The student is added to the system.3. The system provides the Registrar with the new student id.Update a Student1. The system requests that the Registrar enter the student id.2. The Registrar enters the student id. The system retrieves and displays the student information.3. The Registrar makes the desired changes to the student information. This includes any of theinformation specified in the Add a Student sub-flow.4. Once the Registrar updates the necessary information, the system updates the student information.Delete a Student1. The system requests that the Registrar enter the student id2. The Registrar enters the student id. The system retrieves and displays the student information.3. The system prompts the Registrar to confirm the deletion of the student.4. The Registrar verifies the deletion.5. The system deletes the student from the system.Alternative FlowsStudent Not FoundIf, in the Update a Student or Delete a Student sub-flows, a student with the specified id number does not exist, the system displays an error message. The Registrar can then enter a different id number or cancel the operation, at which point the use case ends.Delete CancelledIf, in the Delete A Student sub-flow, the Registrar decides not to delete the student, the delete is cancelled and the Basic Flow is re-started at the beginning.Special RequirementsNone.Pre-ConditionsThe Registrar must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, the student information is added, updated, or deleted from the system. Otherwise, the system state is unchanged.Extension PointsNone.Register for CoursesBrief DescriptionThis use case allows a Student to register for course offerings in the current semester. The Student can also update or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester.Flow of EventsBasic FlowThis use case starts when a Student wishes to register for course offerings, or to change his/her existing course schedule.1. The Student provides the function to perform (one of the sub flows is executed):If the Student selected “Create a Schedule”, the Create a Schedule subflow is executed.If the Student selected “Update a Schedule”, the Update a Schedule subflow is executed.If the Student selected “Delete a Schedule”, the Delete a Schedule subflow is executed.Create a Schedule1. The system retrieves a list of available course offerings from the Course Catalog System and displaysthe list to the Student.2. The Select Offerings subflow is executed.3. The Submit Schedule subflow is executed.Update a Schedule1. The system retrieves and displays the Student’s current schedule (e.g., the schedule for the currentsemester).2. The system retrieves a list of available course offerings from the Course Catalog System and displaysthe list to the Student.3. The Student may update the course selections on the current selection by deleting and adding newcourse offerings. The Student selects the course offerings to add from the list of available courseofferings. The Student also selects any course offerings to delete from the existing schedule.4. Once the student has made his/her selections, the system updates the schedule for the Student using theselected course offerings.5. The Submit Schedule subflow is executed.Delete a Schedule1. The system retrieves and displays the Student’s current schedule (e.g., the schedule for the currentsemester).2. The system prompts the Student to confirm the deletion of the schedule.3. The Student verifies the deletion.4. The system deletes the Schedule. If the schedule contains “enrolled in” course offerings, the Studentmust be removed from the course offering.Select OfferingsThe Student selects 4 primary course offerings and 2 alternate course offerings from the list of availableofferings.Once the student has made his/her selections, the system creates a schedule for the Student containing the selected course offerings.Submit ScheduleFor each selected course offering on the schedule not already marked as “enrolled in”, the system verifies that the Student has the necessary prerequisites, that the course offering is open, and that there are noschedule conflicts.The system then adds the Student to the selected course offering. The course offering is marked as“enrolled in” in the schedule.The schedule is saved in the system.Alternative FlowsSave a ScheduleAt any point, the Student may choose to save a schedule rather than submitting it. If this occurs, theSubmit Schedule step is replaced with the following:The course offerings not marked as “enrolled in” are marked as “selected” in the schedule.The schedule is saved in the system.Unfulfilled Prerequisites, Course Full, or Schedule ConflictsIf, in the Submit Schedule sub-flow, the system determines that the Student has not satisfied the necessary prerequisites, or that the selected course offering is full, or that there are schedule conflicts, an errormessage is displayed. The Student can either select a different course offering and the use case continues, save the schedule, as is (see Save a Schedule subflow), or cancel the operation, at which point the BasicFlow is re-started at the beginning.No Schedule FoundIf, in the Update a Schedule or Delete a Schedule sub-flows, the system is unable to retrieve the Student’s schedule, an error message is displayed. The Student acknowledges the error, and the Basic Flow is re-started at the beginning.Course Catalog System UnavailableIf the system is unable to communicate with the Course Catalog System, the system will display an errormessage to the Student. The Student acknowledges the error message, and the use case terminates.Course Registration ClosedWhen the use case starts, if it is determined that registration for the current semester has been closed, amessage is displayed to the Student, and the use case terminates. Students cannot register for courseofferings after registration for the current semester has been closed.Delete CancelledIf, in the Delete A Schedule sub-flow, the Student decides not to delete the schedule, the delete iscancelled, and the Basic Flow is re-started at the beginning.Special RequirementsNone.Pre-ConditionsThe Student must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, the student schedule is created, updated, or deleted. Otherwise, the system state is unchanged.Extension PointsNone.Select Courses to TeachBrief DescriptionThis use case allows a Professor to select the course offerings from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester.Flow of EventsBasic FlowThis use case starts when a Professor wishes to sign up to teach some course offerings for the upcoming semester.1. The system retrieves and displays the list of course offerings the professor is eligible to teach for the currentsemester. The system also retrieves and displays the list of courses the professor has previously selected to teach.2. The professor selects and/or de-selects the course offerings that he/she wishes to teach for the upcomingsemester.3. The system removes the professor from teaching the de-selected course offerings.4. The system verifies that the selected offerings do not conflict (i.e., have the same dates and times) with eachother or any course offerings that the professor has previously signed up to teach. If there is no conflict, the system updates the course offering information for each offering the professor selects (i.e., records the professor as the instructor for the course offering).Alternative FlowsNo Course Offerings AvailableIf, in the Basic Flow, the professor is not eligible to teach any course offerings in the upcoming semester, the system will display an error message. The professor acknowledges the message and the use case ends.Schedule ConflictIf the systems find a schedule conflict when trying to establish the course offerings the Professor shouldtake, the system will display an error message indicating that a schedule conflict has occurred. The system will also indicate which are the conflicting courses. The Professor can either resolve the schedule conflict(i.e., by canceling his selection to teach one of the course offerings), or cancel the operation, in which case,any selections will be lost, and the use case ends.Course Catalog System UnavailableIf the system is unable to communicate with the Course Catalog System, the system will display an errormessage to the Student. The Student acknowledges the error message, and the use case terminates.Course Registration ClosedWhen the use case starts, if it is determined that registration for the current semester has been closed, amessage is displayed to the Professor, and the use case terminates. Professors cannot change the courseofferings they teach after registration for the current semester has been closed. If a professor change isneeded after registration has been closed, it is handled outside the scope of this system.Special RequirementsNone.Pre-ConditionsThe Professor must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, the course offerings a Professor is scheduled to teach have been updated. Otherwise, the system state is unchanged.Extension PointsNone.Submit GradesBrief DescriptionThis use case allows a Professor to submit student grades for one or more classes completed in the previous semester.Flow of EventsBasic FlowThis use case starts when a Professor wishes to submit student grades for one or more classes completed in the previous semester.1. The system displays a list of course offerings the Professor taught in the previous semester.2. The Professor selects a course offering.3. The system retrieves a list of all students who were registered for the course offering. The system displays eachstudent and any grade that was previously assigned for the offering.4. For each student on the list, the Professor enters a grade: A, B, C, D, F, or I. The system records the student’sgrade for the course offering. If the Professor wishes to skip a particular student, the grade information can be left blank and filled in at a later time. The Professor may also change the grade for a student by entering a new grade.Alternative FlowsNo Course Offerings TaughtIf, in the Basic Flow, the Professor did not teach any course offerings in the previous semester, the system will display an error message. The Professor acknowledges the message, and the use case ends.Special RequirementsNone.Pre-ConditionsThe Professor must be logged onto the system before this use case begins.Post-ConditionsIf the use case was successful, student grades for a course offering are updated. Otherwise, the system state is unchanged.Extension PointsNone.View Report CardBrief DescriptionThis use case allows a Student to view his/her report card for the previously completed semester.Flow of EventsBasic FlowThis use case starts when a Student wishes to view his/her report card for the previously completed semester.1. The system retrieves and displays the grade information for each of the course offerings the Student completedduring the previous semester.2. When the Student indicates that he/she is done viewing the grades, the use case terminates.Alternative FlowsNo Grade Information AvailableIf, in the Basic Flow, the system cannot find any grade information from the previous semester for theStudent, a message is displayed. Once the Student acknowledges the message, the use case terminates.Special RequirementsNone.Pre-ConditionsThe Student must be logged onto the system before this use case begins.Post-ConditionsThe system state is unchanged by this use case.Extension PointsNone.。
2016级软件工程专业方向课程设计任务书(2019.1)
2016级软件工程专业方向课程设计任务书【设计目的】通过软件工程专业方向课程设计，使学生能够在软件系统开发方面得到较系统的技能训练，从而巩固和加强所学的软件工程专业理论知识，目的是培养学生的专业知识综合运用能力，使学生成为具有扎实的软件理论基础和较强的独立动手能力的复合型、应用型人才。
通过软件工程专业方向课程设计，不仅要从理论上深入理解软件系统的开发方法和步骤，并且要真正掌握如何系统化工程化实际开发一个软件系统。
软件系统开发包括可行性分析、需求分析、系统设计、系统实现和系统测试等几个阶段，产生的模型有系统用例模型、系统静态模型、系统动态模型和系统体系结构模型等，产生的软件文档资料包括可行性分析报告、需求分析规格说明书、软件设计报告、程序代码文档以及软件测试报告等。
软件工程专业方向课程设计的目的就是通过一个具体软件系统开发实践，使学生能够得到较系统的技能训练，从而巩固和加强所学的软件工程专业课程理论知识。
本专业方向课程设计将达到以下目标：1．全面掌握软件系统的工程化开发方法与步骤；2．掌握软件开发各阶段产生的文档资料的书写格式；3．掌握与运用基于设计模式的软件复用技术；4．掌握软件开发各阶段产生的系统模型；5．掌握与实践用例/场景驱动的软件开发方法；6．理解与实践软件系统过程模型，尤其是统一过程UP（Unified Process）模型；7．在需求分析、软件设计等建模结果基础上，具备使用包括用例图、类图、活动图、顺序图、构件图等在内的各种UML基本图对其进行描述的能力。
【参考题目】网上竞价系统网上竞价系统包括申购单管理（包括申购单填写、申购单修改、申购单审核、申购单发布等）、竞价单管理（包括竞价单填写、竞价单修改、竞价单审核、竞价单发布等）、用户管理（包括经销商、客户、系统用户的注册、登陆、信息修改等）、合同管理、资金管理（包括资金审核、报账、建账等）、经销商评估等。
请用文字描述系统的大致的客户需求并给出系统需求用例图；选择部分用例进行文字描述和活动图细化；对系统进行系统静态建模、系统动态建模和体系结构建模。
Java语言程序的设计(一)04747汇总(2016_2017全)
2016年10月高等教育自学考试全国统一命题考试Java语言程序设计（一）试卷(课程代码04747)本试卷共9页，满分l00分，考试时间l50分钟。
考生答题注意事项：1．本卷所有试题必须在答题卡上作答。
答在试卷上无效，试卷空白处和背面均可作草稿纸。
2．第一部分为选择题。
必须对应试卷上的题号使用2B铅笔将“答题卡”的相应代码涂黑。
3．第二部分为非选择题。
必须注明大、小题号，使用0．5毫米黑色字迹签字笔作答。
4．合理安排答题空间，超出答题区域无效。
第一部分选择题(共l0分)一、单项选择题(本大题共l0小题，每小题l分，共10分)在每小题列出的四个备选项中只有一个是符合题目要求的，请将其选出并将“答题卡”的相应代码涂黑。
错涂、多涂或未涂均无分。
淘宝店铺自考达人V信12977554291．在下述字符串中，不是Java余言关键字的是A．int B．static C．java D．try2．要作下列数据类型转换，需进行强制类型转换才能实现的是A．从int到char B．从int到longC．从lloat到double D．从byte到int3．在以下供选择的概念中，属于面向对象语言重要概念或机制的是A．方法B．模块C．线程D．继承4．在下述Java程序代码中，能正确创建数组的是A．int myA[5]={1，2，3，4，5)；B．int myA[]=new int(5)；C．int myA[]；myA[]=new int[5]；D．int[]myA={1，2，3，4，5，6}；5．某Java程序的类A需要利用Swin9创建无边框窗口，则A需要继承的类是A．JWindow B．JApplet C．JFrame D．JDialog 6．在以下供选的鼠标事件中，MouseMotionListener接口能处理的是A．按下鼠标键B．拖动鼠标C．鼠标进入D．鼠标松开7．在以下代码中，能正确创建Font对象的是A．new Font(″宋体″，斜体，20)；B．new Font(″楷体″，20，正常)；C．new Font(″楷体″,Font.BOLD，l 8)；D．new Font(″楷体″，1 8，Font．BOLD)；8．某线程正处于运行状态，则在以下选项中，不可能是它的后继状态的是A．就绪状态B．新建状态C．阻塞状态D．死亡状态9．某Java程序用类JFileChooser来实现打开和保存文件对话框。
江苏大学2016级c语言课程设计要求及题目【优质】
C语言程序课程设计C programming curriculum design课程设计大纲一、学时与学分总学时：1.5周总学分：2二、课程设计的目的“C语言课程设计”是在学习“C语言程序设计基础”课程之后进行的一个实践教学环节，课程设计的目的是：1. 针对C语言中的重点和难点内容进行训练，巩固和加深C语言程序设计的能力，独立完成有一定工作量的程序设计任务，同时强调好的程序设计风格。
2. 熟练掌握C语言的编程技巧和上机调试程序的方法3. 进一步培养学生结构化程序设计的思想，加深对高级语言基本语言要素和控制结构的理解。
4. 重点掌握：常用经典算法的程序设计、递归函数的程序设计、链表的处理方法、文件的I/O操作。
为了使学生从课程设计中尽可能取得比较大的收获，对课程设计题目分成二类，一类为基础训练题目，学生从中学习到程序设计的常用算法。
另一类为综合题目。
学生从这两类型题目中各选择部分完成。
三、课程设计的基本要求设计步骤的规范不但可以培养学生科学的工作方法和作风，而且还能有效地减少错误，提高工作效率。
因此必须严格执行良好的实验步骤规范（包括上级操作规范）。
本课程设计的基本步骤与要求是：1．问题分析及解决方案框架确定充分地分析和理解问题本身，弄清要求做什么（What to do?）。
在确定解决方案框架过程中（How to do?），考虑怎样使程序结构清晰、合理、简单和易于调试，并确定每个函数的简单功能，以及函数之间的调用关系。
2．详细设计和编码确定算法的主要流程，再此基础上进行代码设计（Coding），每个明确的功能模块程序一般不超过60行，否则要进一步划分。
3．上机前编写程序与检查上机前程序检查可有效提高调试效率，减少上机调试程序时的无谓错误。
程序检查主要有两种途径：用一组测试数据手工执行程序；通过阅读或给别人讲解自己的程序而深入全面地理解程序逻辑。
把程序中的明显错误事先排除。
4．上机调试程序5．完成课程设计报告，Microsoft Office Word 2003 创建①问题描述：题目，即要解决的问题是什么。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2015级《程序设计课程设计》安排
要求：10次上机（每次4机时）
1.从以下几类题中每类至少选择一个问题实现（正确完成 6 题以上），考核方式为程序验
收和实验报告。
2.验收时同学们自己准备好数据，写好测试流程。
3.所有程序自己完成，不允许抄袭。
4.验收时间为最后两次上机。
5.上机期间不允许打游戏或做其他与课程设计无关的的事情，违反规定者将扣分。
备选题目如下：
一、算法类
1、设计一个复数类型计算程序，输入实部和虚部生成一个复数，可进行两个复数求和、求
差、求积运算。
2、已知2016年1月1日为星期五，输入任一年的年份后，打印该年的年历。
3、假定用一个整型数组表示一个长整数，数组的每个元素存储长整数的一位数字，实际的
长整数m表示为：
m=a[k]×10k-1+a[k-1]×10k-2+….+a[2]×101+a[1] ×100
其中a[0]保存该长整数的位数。
实现长整数除普通整数。
4、根据输入的正整数N，计算N及以内每个数的数据链（下一个数字是上一个数字每位平
方和，直到该数字变成一位数。
例如：44->32 就是4*4+4*4=32 ），并统计数据链最终结果是1的数的个数。
例如：对于数44，则数字链为：44->32->13->10->1，其规则为：4*4+4*4=32，3*3+2*2=13，1*1+3*3=10，1*1+0*0=1。
最终结果是1。
而对于42，数字链为：42->20->4。
最终结果不是1。
二、文件类
1、用文件保存一段英文文本。
(1) 统计各字母在文本中出现的次数（区分大小写），并按英文字母序输出统计结果。
(2) 查找并替换文本中的某字符串，将替换后的文本存入另一个文件。
2、编写程序XMLtoTXT自动将XML文件email.xml转换为文本文件email.txt。
命令行格式：XMLtoTXT email.xml email.txt。
(a)
(b)
图(a)为文件email.xml ；图(b)为文件email.txt 3、 现有两个文本文件和。
file1中第一列为姓名，第二列为英语成绩；file2中第一列为姓名，
第二列为数学成绩。
通过程序关联file2中与file1对应的姓名生成文件。
文件第一列为姓名，第二列为英语成绩，第三列为数学成绩，第四列为平均成绩。
三、字符串类
1、 用字符数组保存一个英文句子。
(1) 删除该英文句子的前导空格、后导空格、句中多余空格（单词之间只留一个空格）。
(2) 统计句中某单词出现的次数。
(3) 查找并替换某单词。
2、 检查C 源程序的圆括号和大括号是否匹配。
正确的例子如：（{((…)(…))}()）,不正。