Разработка системы учета успеваемости студентов на основе рейтинговой системы - подсистема "Преподаватель" - Программирование, компьютеры и кибернетика курсовая работа

Главная

Программирование, компьютеры и кибернетика
Разработка системы учета успеваемости студентов на основе рейтинговой системы - подсистема "Преподаватель"

Формирование требований к системе учета успеваемости студентов на основе рейтинговой системы. Концептуальное и логическое проектирование структуры информационного обеспечения. Реализация информационного обеспечения и тестирование программного средства.

посмотреть текст работы

скачать работу можно здесь

полная информация о работе

весь список подобных работ

Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

1 Формирование требований к системе учета успеваемости студентов на основе рейтинговой системы
1.1 Разработка диаграммы вариантов использования
1.1.2 Выявления вариантов использования
1.1.3 Диаграммы вариантов использования
3.2 Концептуальное и логическое проектирование структуры информационного обеспечения
3.3 Проектирование пользовательского интерфейса
4.2 Реализация информационного обеспечения
4.3 Реализация пользовательского интерфейса
4.5 Организация взаимодействия приложения с БД
В настоящее время практически все сферы человеческой деятельности стремятся к автоматизации. Это делается для того, чтобы сократить время на выполнение различного рода работ и сделать их более простыми, а также исключить человеческий фактор с целью избежания ошибок и субъективного подхода. На сегодняшний день все более актуальной сферой для оптимизации и автоматизации различных процессов становится образование. Именно для этого и будет служить разрабатываемая программа.
Целью системы учета успеваемости студентов на основе рейтинговой технологии является получение комплексной оценки качества учебной работы студента в процессе обучения по программам высшего профессионального образования.
Данное средство будет являться сложным программным продуктом, т.к. должно уметь анализировать успеваемость студента и его рейтинг, выставлять приоритеты студентам за соответствующие достижения и успехи, строить диаграммы и графики по различным данным и многое другое.
Объектом исследования для данной системы являются оценки студентов за все, без исключения, практикуемые в вузе виды учебной работы, входящей и невходящей в учебный план, а так же посещаемость.
Разрабатываемая программа призвана автоматизировать определенные процессы, протекающие в учебных заведениях, о некоторых из них говорилось ранее, а также многие другие. Основным местом внедрения и тестирования данной программы являются ВУЗы.
Краткое описание акторов представлено в таблице 1.
Регистрирует данные о посещаемости и успеваемости студентов по своему предмету. Просматривает, редактирует или удаляет внесенные данные. Просматривает обработанные данные. Анализирует их.
Просматривает внесенные преподавателем данные по предмету. Просматривает обработанные данные. Получает и просматривает оповещения в случае неудач.
1.1.2 Выявление вариантов использования
Выявление вариантов использования представлено в таблице 2.
Таблица 2. Выявление вариантов использования
Этот вариант использования позволяет преподавателю передавать данные о посещаемости и успеваемости студента в программу
Этот вариант использования позволяет преподавателю просматривать только что внесенные данные
Преподаватель может редактировать или удалить неправильно введенные данные
Преподаватель может просмотреть обработанные программой данные
Преподаватель анализирует данные, обработанные программой, составляет и выводит на печать отчеты
Этот вариант использования позволяет студенту просматривать внесенные преподавателем данные
Студент может просмотреть данные, обработанные программой
Программа, на основе анализа данных преподавателем, посылает оповещения о результатах студенту
1.1.3 Разработка диаграммы вариантов использования
Все варианты использования показаны на рисунке 1.
учет успеваемость студент рейтинговая система
Рис. 1. Диаграмма вариантов использования
Чтобы программное обеспечение было действительно полезным, важно, чтобы оно удовлетворяло реальные потребности людей и организаций. Для выявления этих потребностей проводится анализ предметной области или бизнес-моделирование.
Разрабатываемое ПС является многоуровневым и многопользовательским, а, следовательно, имеет строго разделенную иерархию пользователей. Т.е. каждый пользователь может использовать лишь определенные разделы ПС.
ПС подразумевает следующие типы пользователей:
Рассмотрим подробно взаимодействие типа пользователя “Преподаватель” с ПС.
Для того чтобы данный тип пользователя смог взаимодействовать с системой, ему сначала необходимо в ней зарегистрироваться. Этот процесс происходит следующим образом - пользователь вводит все необходимые регистрационные данные, запрашиваемые системой и подтверждает их ввод, после чего данные сохраняются в хранилище пользователей. Далее, уполномоченный определенными правами модератор или сомодератор рассматривает компетентность данного пользователя на указанные им регистрационные данные, и если все соответствует, то подтверждает участие данного пользователя в системе. Другими словами, модератор назначает определенные права данному пользователю на ведение конкретных предметов у конкретных учебных групп, регистрирование и редактирование информации в своем разделе. Данный процесс протекает следующим образом - модератор назначает права пользователю из хранилища ролей, а группы из хранилища групп, назначенные права хранятся в промежуточном хранилище - хранилище ПреподавательРольГруппа.
Теперь, на данном этапе, пользователь обладает конкретными правами на использование конкретных разделов программы, т.е. при следующем входе в систему, а именно ввода логина и пароля, он будет автоматически перенаправляться на необходимый ему раздел ПС. Этот процесс протекает последующему - после подтверждения ввода логина и пароля, выполняется процесс аутентификации пользователя, ПС оперируя указанными данными, предоставляет уровень доступа пользователю к системе, в соответствии с данными находящимися в хранилище ролей и хранилище ПреподавательРольГруппа.
Когда пользователь прошел аутентификацию, он может приступить к использованию определенной области ПС, а именно созданию тем по своему предмету у определенных учебных групп, отмечать посещаемость и выставлять баллы. В данном случае одновременно задействованы несколько процессов и хранилищ. Процесс “Удалить, Добавить, Редактировать Тему”, позволяет преподавателю соответственно добавить, удалить или отредактировать тему по определенному предмету у определенной группы и взаимодействует с такими хранилищами, как - хранилище тем, хранилище групп и хранилище результатов. Процесс “Занести Данные В Хранилище Результатов”, позволяет пользователю сохранить указанные им данные в хранилище результатов, данный процесс также взаимодействует с такими хранилищами данных, как хранилище тем, хранилище групп и хранилище результатов.
Далее на рисунке 2 указана диаграмма потоков данных, на которой наглядно видно, как и каким образом, какой тип пользователя оперирует определенными процессами, и какие хранилища данных при этом задействованы.
На данном этапе разработке, необходимо продумать общий набор классов, необходимых для реализации ПС, а так же решить целый ряд задач проектирования, таких как:
1) Отделить код доступа к данным от кода бизнес-логики и кода предоставления (пользовательского интерфейса), так чтобы ПС было гораздо более удобным в обслуживании и гораздо более масштабируемым. Это называется многоуровневым проектом.
2) Изолировать архитектуру доступа к данным, так чтобы она могла поддерживать различные лежащие в основе хранилища данных, не требуя внесения изменений на уровне бизнес-объектов. Подобным образом, внесение изменений в бизнес-объекты или уровни представления тоже должно быть возможным без изменения другого уровня. Это называется отделением уровней друг от друга.
3) Спроектировать архитектуру бизнес-объектов, чтобы представить данные, извлекаемые на уровне доступа к данным, в объектно-ориентированном формате. Этот процесс называется отображением реляционных данных на классы объектно-ориентированного программирования.
4) Обеспечить возможность помещения бизнес-объектов в кэш для того, чтобы данные, уже извлеченные из хранилища данных, сохранялись, и ПС не приходилось выполнять ненужные операции выборки для извлечения тех же самых данных снова и снова. Это позволит сократить требуемое количество ресурсов ЦП, ресурсов базы данных и объем сетевого трафика и, следовательно, улучшить производительность в целом.
5) Обработать и зарегистрировать исключения и другие важные события, такие как удаление записи, для того, чтобы упростить диагностику проблем в случае сбоя в работе системы и обеспечить наличие данных аудита.
6) Привязать многочисленные элементы управления пользовательского интерфейса к данным, извлекаемым на уровне бизнес логики, чтобы свести к минимуму объем работы, который должен выполнятся на уровне пользовательского интерфейса, и возложить роль управления данными на уровень бизнес-логики вместо уровня пользовательского интерфейса.
В идеале пользовательский интерфейс должен фокусироваться в основном на представлении данных, уровень бизнес-логики должен манипулировать данными и применять бизнес-правила, а уровень данных должен только обеспечивать постоянство (хранилище данных).
Уровень доступа к данным (Data Access Layer - DAL) - это код, который выполняет отправляемые в базу данных запросы на извлечение данных, их обновление, вставку или удаление. Этот код наиболее близок к базе данных и поэтому ему должны быть известны все детали базы данных, т.е., схема таблиц, имена полей, хранимых процедур, представлений и т.д.
Уровень бизнес-логики (Business Logic Layer - BLL) - получает данные возвращаемые уровнем DAL и передает их уровню пользовательского интерфейса, но кроме того он добавляет верификационную логику и вычисляемые свойства, делая некоторые из свойств персональными или доступными только для чтения, а так же методы экземпляра и статические методы для удаления, редактирования, вставки и извлечения данных.
Ниже на рисунке 3 показано отношения между пользовательским интерфейсом, уровнями бизнес-логики и доступа к данным и хранилищами данных.
Рис. 3. Отношения между пользовательским интерфейсом, уровнями бизнес-логики, доступа к данным и хранилищами данных
3.2 Концептуальное и логическое проектирование структуры информационного обеспечения
Нам необходимо создать хранилище данных, которое бы, жестко удовлетворяло всем критериям ПС. Для этого потребуется создать целый перечень таблиц и описать поля в них, некоторые из которых будут связаны
ПС подразумевается использовать в вузе, поэтому необходимо создать таблицы, в которых бы хранилась структура вуза, т.е.:
- aspnet_Fakultets (таблица для хранения факультетов),
- aspnet_Kafedraes (таблица для хранения кафедр),
- aspnet_Speciales (таблица для хранения специальностей).
Также, необходимо создать таблицы, которые бы хранили пользователей ПС - таблица aspnet_Users и роли пользователей aspnet_Roles. Для того чтобы обеспечить взаимодействие данных между двумя этими таблицами необходимо создать промежуточную таблицу aspnet_UsersInRoles, т.е. эта таблица в которой будет храниться соответствие между пользователем и ролями которыми он обладают.
Помимо всего каждая роль может иметь свой тип, для этого необходимо создать таблицу для хранения типов ролей - aspnet_Type, и таблицу, которая бы хранила соответствие между ролью и типом роли - aspnet_TypeOfRoles.
Каждый пользователь обладает индивидуальными характеристиками, которые также необходимо хранить, для этого создадим таблицу профилей пользователей - aspnet_Profile. Помимо всего пользователь может быть студентом или преподавателем, следовательно, необходимо создать таблицу, которая бы хранила учебные группы - aspnet_Grups и таблицу, которая бы непосредственно хранила студентов в конкретной учебной группе - aspnet_UsersInGrup, а так же таблицу, которая бы хранила соответствие между преподавателем, его предметом и группами, у которых он ведет конкретный предмет - aspnet_UsersRolesGrups.
Ниже на рисунке 4 представлено логическое проектирование базы данных.
Рис.4. Логическое проектирование базы данных.
Также по конкретным предметам будут существовать определенные темы, которые будут хранится в таблице - aspnet_Thems, а данные темы будут регистрироваться в определенном семестре, поэтому также понадобится таблица которая бы хранила семестры - aspnet_Semestor.
В итоге, после манипулирования с различными данными, их так же будет необходимо сохранять, для этого создадим таблицу - aspnet_Result.
По окончанию семестра данные необходимо будет копировать из таблицы aspnet_Result (в ней хранятся данные за текущий семестр), в таблицу долго хранения - aspnet_LongDataStore(в ней хранятся данные за все существующие семестры, с начала использования ПС).
3.3 Проектирование пользовательского интерфейса
Программное средство будет являться веб программой, а, следовательно, для него необходимо разработать интерфейс, который бы соответствовал веб среде.
Как показано ниже на рисунке 4, мы будем придерживаться основных принципов разработки пользовательского веб интерфейса, а именно нам потребуется поле для регистрации и аутентификации пользователя, поле, где бы располагалось меню ПС, поле с названием ПС, левый и правый колонтитулы для вывода вспомогательного текста различного содержания, нижний колонтитул для размещения информации об авторских правах, и поле для отображения основной информации запрашиваемой пользователем. Также ко всему прочему можем разместить баннер на ПС.
Каждое из описанных выше полей будет подчиняться определенному дизайну, сам дизайн будет применяться через каскадную таблицу стилей (css), где и будут описаны все его аспекты.
Т.к. ПС является веб программой, то это подразумевает наличие множества страниц, которые будут загружаться в зависимости от действий пользователя, поэтому для обеспечения быстроты работы ПС и экономии сетевого трафика, мы применим общий дизайн ко всем страницам, т.е. изменятся во время выполнения будет только основное содержимое.
Рис.4. схематический пользовательский веб интерфейс
Для реализации данного программного средства будет выбрана среда разработки MS Visual Studio 2005. Данная среда включает такие элементы разработки как: интегрированную СУБД Microsoft SQL Server 2005 Express Edition, языки программирования С++, С#, J#, Visual Basic, новейшие веб технгологии ASP.NET 2.0, Ajax, интегрированный веб сервер для тестирования веб приложений, а так же очень развитую IDE среду и многое другое. Все вышеперечисленное дает большие возможности для быстрой и надежной разработки этого программного средства, а так же его отладки, тестирования и развертывания.
Система будет разработана как приложение ASP.NET 2.0 на языке программирования Visual С# с использованием СУБД Microsoft SQL Server 2005 Express Edition.
4.2 Реализация информационного обеспечения
Ранее уже говорилось, что данное ПС является многопользовательским, а, следовательно, должно иметь очень развитую систему администрирования, именно данная подсистема, организует правильную работу всех остальных модулей ПС, поэтому детально рассмотрим именно подсистему администрирования.
Для реализации данной подсистемы, нам сперва потребуется разработать ряд таблиц, которые хранили бы в соответствии между собой, всю необходимую информацию для программного средства.
Главным объектом подсистемы администрирования, является пользователь. У пользователя в свою очередь должна быть возможность зарегистрироваться и в случае необходимости поменять свои регистрационные данные, а в случае если он их забыл, то должна быть возможность их восстановить. Для этого пользователю необходимо сообщить системе определенный набор данных, по которым система в дальнейшем могла бы отличить его от ряда других пользователей. Т.к. система является многопользовательской, и каждый пользователь может иметь определенные права по использованию системы, то должна быть возможность разделения пользователей на ранги, т.е. возможность предоставления пользователю определенной роли.
Т.к. данное ПС находится только на этапе разработки, то нельзя исключать возможности, что оно будет тесно взаимодействовать, со смежными ПС разработанными в дальнейшем, т.е. необходимо реализовать возможность хранения учетных записей пользователей, для множества ПС, в одной единственной базе данных.
Таким образом, мы получаем, что для полноценной структуры нашей ИС необходимо 4 основные сущности и 1 дополнительная.
Рассмотрим подробным образом все атрибуты описанных выше сущностей.
· ApplicationId - id ПС, необходимо для хранения учетной записи пользователя для множества ПС;
· UserId - хранит уникальный порядковый номер пользователя;
· UserName - хранит выбранное пользователем имя;
· LoweredUserName - хранит имя пользователя в нижнем регистре(пользователю, для того чтобы пройти аутентификацию, не нужно беспокоиться о регистре вводимого учетного имени);
· LastActivityDate - хранит дату, когда пользователь в последний раз регистрировался на сайте или в последний раз проходил аутентификацию.
· ApplicationId - хранит уникальный порядковый номер ПС;
· LoweredApplicationName - хранит имя приложения в нижнем регистре;
· Description - краткое описание ПС.
· ApplicationId - хранит уникальный порядковый номер ПС;
· UserId - хранит уникальный порядковый номер пользователя;
· Password - хранит пароль указанный пользователем;
· PasswordFormat - указывает формат, в котором пароль должен храниться. Возможные значения Clear, Encrypted, Hashed(В нашем ПС мы будем использовать Hashed);
· Email - хранит адрес электронной почты, указанной пользователем;
· LoweredEmail - хранит адрес электронной почты, в нижнем регистре;
· PasswordQuestion - хранит вопрос указанный пользователем, на случай восстановления пароля;
· PasswordAnswer - хранит ответ, на указанный пользователем пароль, на случай восстановления пароля;
· IsApproved - хранит пометку о том, была ли активизирована учетная запись пользователя;
· CreateDate - хранит дату регистрации пользователя.
· LastLogindate - хранит дату последний регистрации.
· ApplicationId - хранит уникальный порядковый номер ПС;
· RoleId - хранит уникальный порядковый номер роли;
· LoweredRoleName - хранит имя роли в нижнем регистре;
· Description - хранит краткое описание роли.
Пользователь\Роль(aspnet_UsersInRoles):
· UserId - хранит уникальный порядковый номер пользователя;
· RoleId - хранит уникальный порядковый номер роли.
Данная сущность выстраивает отношение между пользователем и доступными для него ролями.
На основании списка сущностей предметной области, описанного выше, и связей между ними можно сгенерировать схему базы данных. Создание нашей базы данных будет происходить в несколько этапов:
3. Связь таблиц между собой, построение диаграммы БД.
Рассмотрим каждый из этих этапов более подробно.
Осуществление этого этапа будет производить при помощи Microsoft Visual Studio 2005. При нажатии на кнопку Tools в панели меню, выпадет список команд. Нажав на команду Connect to Database появляется окно (рис. 5), в котором выбираем название сервера из выпадающего списка, затем можно выбрать уже созданную ранее БД или ввести новое имя для БД, а так же можно прикрепить файл БД, если он был создан в другом месте.
В нашем случае впишем новое название для базы ASPNETDB. На сервере в папке Data будет создана БД с таким названием. В Microsoft Visual Studio 2005, открыв Server Explorer, можно увидеть эту БД и список различных папок для работы с ней (рис. 6).
Так же можно создать БД с помощью следующей SQL команды:
Нажав правой кнопкой мыши на папку Tables, выпадает меню, где можно добавить новую таблицу к БД. Затем нужно создать все необходимые поля в этой таблице, задать их типы данных и определить ключевые поля. Задать разрешение на содержание нулевых значений в этой таблице путем установления флажка Allow null напротив выбранного поля. При помощи SQL команды можно проделать то же самое.
APPLICATIONID UNIQUEIDENTIFIER NOT NULL,
USERID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,
LOWEREDUSERNAME NVARCHAR(256) NOT NULL,
APPLICATIONID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,
APPLICATIONNAME NVARCHAR(256) NOT NULL,
LOWEREDAPPLICATIONNAME NVARCHAR(256) NOT NULL,
APPLICATIONID UNIQUEIDENTIFIER NOT NULL,
REFERENCES APPLICATIONS(APPLICATIONID),
USERID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,
PASSWORDQUESTION NVARCHAR(256) NULL,
APPLICATIONID UNIQUEIDENTIFIER NOT NULL,
REFERENCES APPLICATIONS(APPLICATIONID),
ROLEID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,
LOWEREDROLENAME NVARCHAR(256) NOT NULL,
ROLEID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,
USERID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,
После выполнения вышеописанных запросов, мы получим необходимые нам таблицы и связи между ними (рис.7).
Для проверки работоспособности полученной БД администрирования, можно реализовать несколько запросов и хранимых процедур.
Примеры использования запросов и хранимых процедур
Для совершения различных манипуляций с хранилищами данных можно использовать как sql запросы, так и хранимые процедуры.
Примеры использования запросов и хранимых процедур
Данный запрос позволяет отобразить все роли, которыми наделен пользователь “User”:
FROM aspnet_UsersInRoles INNER JOIN
aspnet_Users ON aspnet_UsersInRoles.UserId = aspnet_Users.UserId INNER JOIN
aspnet_Roles ON aspnet_UsersInRoles.RoleId = aspnet_Roles.RoleId
WHERE (aspnet_Users.UserName = 'User')
Данный запрос позволяет узнать, когда был зарегистрирован в системе пользователь “User”:
SELECT aspnet_Membership.CreateDate
FROM aspnet_UsersInRoles INNER JOIN
aspnet_Users ON aspnet_UsersInRoles.UserId = aspnet_Users.UserId INNER JOIN
aspnet_Roles ON aspnet_UsersInRoles.RoleId = aspnet_Roles.RoleId INNER JOIN
aspnet_Membership ON aspnet_UsersInRoles.UserId = aspnet_Membership.UserId
WHERE (aspnet_Users.UserName = 'User')
Данный запрос позволяет отобразить всех пользователе в системе, прошедших активизацию учетной записи:
SELECT aspnet_Users.UserName, aspnet_Membership.IsApproved
FROM aspnet_UsersInRoles INNER JOIN aspnet_Users ON aspnet_UsersInRoles.UserId = aspnet_Users.UserId INNER JOIN
aspnet_Roles ON aspnet_UsersInRoles.RoleId = aspnet_Roles.RoleId INNER JOIN
aspnet_Membership ON aspnet_UsersInRoles.UserId = aspnet_Membership.UserId
WHERE (aspnet_Membership.IsApproved = 1)
Данная хранимая процедура, позволяет получить имя пользователя, зная его Email:
ALTER PROCEDURE dbo.aspnet_Membership_GetUserByEmail
FROM dbo.aspnet_Applications a, dbo.aspnet_Users u, dbo.aspnet_Membership m
WHERE LOWER(@ApplicationName) = a.LoweredApplicationName AND
u.ApplicationId = a.ApplicationId AND u.UserId = m.UserId AND
FROM dbo.aspnet_Applications a, dbo.aspnet_Users u, dbo.aspnet_Membership m
WHERE LOWER(@ApplicationName) = a.LoweredApplicationName AND
u.ApplicationId = a.ApplicationId AND
Данная хранимая процедура позволяет создать пользователя в системе:
ALTER PROCEDURE [dbo].aspnet_Users_CreateUser
IF( EXISTS( SELECT UserId FROM dbo.aspnet_Users
INSERT dbo.aspnet_Users (ApplicationId, UserId, UserName, LoweredUserName, IsAnonymous, LastActivityDate)
VALUES (@ApplicationId, @UserId, @UserName, LOWER(@UserName), @IsUserAnonymous, @LastActivityDate)
В приложение Б детально показана структура базы данных.
4.3 Реализация пользовательского интерфейса
Для реализации пользовательского интерфейса нам сперва потребуется создать мастер страницу, т.е. основную страницу, дизайн которой будет применен ко всем остальным страницам. Для этого нам необходимо выполнить следующие шаги:
3) Открыть окно Solution Explorer, правой кнопкой мыши кликнуть по названию проекта и выбрать пункт под названием Add New Item. Далее выбрать необходимый нам элемент, а именно Master Page.
После того как мастер страница создана, в нее необходимо поместить следующий код:
<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>

Система учета успеваемости
Система учета успеваемости студентов
на основе рейтинговой системы
web: http://speedy.dyndns.info

Имя*Пароль*

БАННЕРЫ
О программеКупитьОбменник

Copyright © BigMany-Company 2007 - 2008
Server by Speedy
Дизайн и проект разработан Логачевым Ю. А. и Бондаревым Я. П.
Для того чтобы остальные страницы имели общий дизайн с мастер страницей, в заголовке их кода необходимо прописать следующее:
<%@ Page Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Система учета успеваемости :: Главная страница" %>

Далее на страницах необходимо расположить запланированные управляющие элементы и описать код, который будет вызываться в зависимости от возникновения различного рода событий.
Для того чтобы создать управляющий элемент на странице, можно прописать строку кода, а можно использовать меню инструментов.
Например, для того чтобы создать управляющий элемент “кнопка”, необходимо написать следующий код :

Рис. 10. Добавление управляющего элемента «Button»
Для того чтобы, все страницы и управляющие элементы имели общую цветовую схему, стиль, размер и т.д., необходимо в каскадной таблице стилей прописать следующий код:
font:12px Verdana, Tahoroa, sans-serif;
font:bold 18px Arial Black uppercase;
В данном пункте рассмотрим основную функциональную возможность ПС, для подсистемы преподаватель - учет посещаемости и успеваемости студентов.
Для реализации этой возможности нам потребуется спроектировать ряд классов и функций.
Сперва нам потребуется создать базовый класс, который будет наследоваться от класса System, и описать в нем набор основных функций, которые будут в большинстве случаев общими для всех остальных.
using System.Web.UI.WebControls.WebParts;
/// Summary description for BasePage
public class BasePage : System.Web.UI.Page
………………………………………………………………………………………………………………………………………………………………………………
Далее необходимо написать функции, которые непосредственно будут выполнять конкретные действия, по наступлению определенных событий.
public partial class Account : BasePage
public class ImageTemplate : ITemplate - класс унаследованный от интерфейса, при помощи которого создаются шаблоны графических изображений;
public class LabelTemplate : ITemplate - класс унаследованный от интерфейса, при помощи которого создаются шаблоны текстовых полей;
public class DropDownListTemplate : ITemplate - класс унаследованный от интерфейса, при помощи которого создаются шаблоны выпадающих списков;
public class CheckboxTemplate : ITemplate
Разработка системы учета успеваемости студентов на основе рейтинговой системы - подсистема "Преподаватель" курсовая работа. Программирование, компьютеры и кибернетика.
Доклад по теме Эрнан Кортес
Курсовая работа: Реклама в комплексе маркетинговых коммуникаций на примере туристической компании АлиВия Т
Доклад: Зарубежный опыт гос. регулирования рыночной экономики на примере Франции. Скачать бесплатно и без регистрации
Реферат На Тему Сырье
Курсовая работа по теме Історія становлення та розвитку англійської мови
Реферат Образец Плана
Реферат На Тему Влияние Физических Факторов На Организм Человека (На Примере Электромагнитных Волн)
Спасение Зайца Сочинение 2
Реферат по теме Основні поняття теорії сигналів
Мое Отношение К Праву Эссе
Реферат: Ценообразование 19
Эссе Качества Менеджера
Курсовая работа по теме Савецко-польска вайна
Курсовая работа по теме Система муниципального управления на современном этапе. Особенности организации и функционирования
Курсовая работа по теме Общие уравнения кривых и поверхностей второго порядка
Физика Спо Лабораторные Работы
Реферат: Herman Melville A Biography And Analysis Essay
Курсовая работа: Расчет сметы затрат на переоборудование цокольного этажа в магазин
Реферат: Computer Engineering Essay Research Paper Since birds
История Развития Кибернетики Реферат
Роль дидактических игр в формировании экологической культуры у учащихся 4 класса - Педагогика дипломная работа
Стратегия концентрации - Менеджмент и трудовые отношения реферат
Концепция lex petrolea в инвестиционном праве - Государство и право дипломная работа

Report Page