Разработка системы учета успеваемости студентов на основе рейтинговой системы — подсистема «Преподаватель»

Содержание Введение

1 Формирование требований к системе учета успеваемости студентов на основе рейтинговой системы

1.1 Разработка диаграммы вариантов использования

1.1.1 Выявления акторов

1.1.2 Выявления вариантов использования

1.1.3 Диаграммы вариантов использования

2 Анализ предметной области

2.1 Диаграмма потоков данных

3 Проектирование ПС

3.1 Проектирование архитектуры ПС

3.2 Концептуальное и логическое проектирование структуры информационного обеспечения

3.3 Проектирование пользовательского интерфейса

4 Реализация ПС

4.1 Выбор средств реализации

4.2 Реализация информационного обеспечения

4.3 Реализация пользовательского интерфейса

4.4 Реализация функциональности ПС

4.5 Организация взаимодействия приложения с БД

5 Тестирование ПС Заключение Список литературы Приложение, А Видение Приложение Б Архитектура БД

Введение

В настоящее время практически все сферы человеческой деятельности стремятся к автоматизации. Это делается для того, чтобы сократить время на выполнение различного рода работ и сделать их более простыми, а также исключить человеческий фактор с целью избежания ошибок и субъективного подхода. На сегодняшний день все более актуальной сферой для оптимизации и автоматизации различных процессов становится образование. Именно для этого и будет служить разрабатываемая программа.

Целью системы учета успеваемости студентов на основе рейтинговой технологии является получение комплексной оценки качества учебной работы студента в процессе обучения по программам высшего профессионального образования.

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

Объектом исследования для данной системы являются оценки студентов за все, без исключения, практикуемые в вузе виды учебной работы, входящей и невходящей в учебный план, а так же посещаемость.

Разрабатываемая программа призвана автоматизировать определенные процессы, протекающие в учебных заведениях, о некоторых из них говорилось ранее, а также многие другие. Основным местом внедрения и тестирования данной программы являются ВУЗы.

1 Формирование требований к системе учета успеваемости студентов на основе рейтинговой системы

Разработка любого ПС начинается с этапа формирования требований к этому ПС. Т. е. исходя из пожеланий заказчика, должен быть, создан документ, который будет предельно точно определять все задачи разработчиков. Такой документ называется «Видение ПС», и представлен в приложение А.

1.1 Разработка диаграммы вариантов использования

Разработка диаграммы вариантов использования производится в три этапа. Сначала выявляются акторы и производится их описание. Затем, исходя из описания, выявляются варианты использования акторов. И на третьем этапе строится диаграмма вариантов использования.

1.1.1 Выявления акторов

Краткое описание акторов представлено в таблице 1.

Таблица 1. Выявление акторов

1.1.2 Выявление вариантов использования Выявление вариантов использования представлено в таблице 2.

Таблица 2. Выявление вариантов использования

1.1.3 Разработка диаграммы вариантов использования Все варианты использования показаны на рисунке 1.

учет успеваемость студент рейтинговая система Рис. 1. Диаграмма вариантов использования

2 Анализ предметной области

Чтобы программное обеспечение было действительно полезным, важно, чтобы оно удовлетворяло реальные потребности людей и организаций. Для выявления этих потребностей проводится анализ предметной области или бизнес-моделирование.

Разрабатываемое ПС является многоуровневым и многопользовательским, а, следовательно, имеет строго разделенную иерархию пользователей. Т. е. каждый пользователь может использовать лишь определенные разделы ПС.

ПС подразумевает следующие типы пользователей:

— Студент

— Преподаватель

— Администратор

— Модератор

— СоМодератор Рассмотрим подробно взаимодействие типа пользователя «Преподаватель» с ПС.

Для того чтобы данный тип пользователя смог взаимодействовать с системой, ему сначала необходимо в ней зарегистрироваться. Этот процесс происходит следующим образом — пользователь вводит все необходимые регистрационные данные, запрашиваемые системой и подтверждает их ввод, после чего данные сохраняются в хранилище пользователей. Далее, уполномоченный определенными правами модератор или сомодератор рассматривает компетентность данного пользователя на указанные им регистрационные данные, и если все соответствует, то подтверждает участие данного пользователя в системе. Другими словами, модератор назначает определенные права данному пользователю на ведение конкретных предметов у конкретных учебных групп, регистрирование и редактирование информации в своем разделе. Данный процесс протекает следующим образом — модератор назначает права пользователю из хранилища ролей, а группы из хранилища групп, назначенные права хранятся в промежуточном хранилище — хранилище ПреподавательРольГруппа.

Теперь, на данном этапе, пользователь обладает конкретными правами на использование конкретных разделов программы, т. е. при следующем входе в систему, а именно ввода логина и пароля, он будет автоматически перенаправляться на необходимый ему раздел ПС. Этот процесс протекает последующему — после подтверждения ввода логина и пароля, выполняется процесс аутентификации пользователя, ПС оперируя указанными данными, предоставляет уровень доступа пользователю к системе, в соответствии с данными находящимися в хранилище ролей и хранилище ПреподавательРольГруппа.

Когда пользователь прошел аутентификацию, он может приступить к использованию определенной области ПС, а именно созданию тем по своему предмету у определенных учебных групп, отмечать посещаемость и выставлять баллы. В данном случае одновременно задействованы несколько процессов и хранилищ. Процесс «Удалить, Добавить, Редактировать Тему», позволяет преподавателю соответственно добавить, удалить или отредактировать тему по определенному предмету у определенной группы и взаимодействует с такими хранилищами, как — хранилище тем, хранилище групп и хранилище результатов. Процесс «Занести Данные В Хранилище Результатов», позволяет пользователю сохранить указанные им данные в хранилище результатов, данный процесс также взаимодействует с такими хранилищами данных, как хранилище тем, хранилище групп и хранилище результатов.

Далее на рисунке 2 указана диаграмма потоков данных, на которой наглядно видно, как и каким образом, какой тип пользователя оперирует определенными процессами, и какие хранилища данных при этом задействованы.

2.1 Диаграмма потоков данных Рис. 2. Диаграмма потоков данных

3 Проектирование

3.1 Проектирование архитектуры ПС На данном этапе разработке, необходимо продумать общий набор классов, необходимых для реализации ПС, а так же решить целый ряд задач проектирования, таких как:

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. схематический пользовательский веб интерфейс

4. Реализация ПС

4.1 Выбор средств реализации Для реализации данного программного средства будет выбрана среда разработки 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 дополнительная.

Основные:

· Пользователь;

· Приложение;

· Членство;

· Роль.

Дополнительные:

· ПользовательРоль.

Атрибуты сущностей Рассмотрим подробным образом все атрибуты описанных выше сущностей.

Пользователь (aspnet_Users):

· ApplicationId — id ПС, необходимо для хранения учетной записи пользователя для множества ПС;

· UserId — хранит уникальный порядковый номер пользователя;

· UserName — хранит выбранное пользователем имя;

· LoweredUserName — хранит имя пользователя в нижнем регистре (пользователю, для того чтобы пройти аутентификацию, не нужно беспокоиться о регистре вводимого учетного имени);

· LastActivityDate — хранит дату, когда пользователь в последний раз регистрировался на сайте или в последний раз проходил аутентификацию.

Приложение (aspnet_Application):

· ApplicationId — хранит уникальный порядковый номер ПС;

· ApplicationName — хранит имя ПС;

· LoweredApplicationName — хранит имя приложения в нижнем регистре;

· Description — краткое описание ПС.

Членство (aspnet_Membership):

· ApplicationId — хранит уникальный порядковый номер ПС;

· UserId — хранит уникальный порядковый номер пользователя;

· Password — хранит пароль указанный пользователем;

· PasswordFormat — указывает формат, в котором пароль должен храниться. Возможные значения Clear, Encrypted, Hashed (В нашем ПС мы будем использовать Hashed);

· Email — хранит адрес электронной почты, указанной пользователем;

· LoweredEmail — хранит адрес электронной почты, в нижнем регистре;

· PasswordQuestion — хранит вопрос указанный пользователем, на случай восстановления пароля;

· PasswordAnswer — хранит ответ, на указанный пользователем пароль, на случай восстановления пароля;

· IsApproved — хранит пометку о том, была ли активизирована учетная запись пользователя;

· CreateDate — хранит дату регистрации пользователя.

· LastLogindate — хранит дату последний регистрации.

Роль (aspnet_Roles);

· ApplicationId — хранит уникальный порядковый номер ПС;

· RoleId — хранит уникальный порядковый номер роли;

· RoleName — хранит имя роли;

· LoweredRoleName — хранит имя роли в нижнем регистре;

· Description — хранит краткое описание роли.

ПользовательРоль (aspnet_UsersInRoles):

· UserId — хранит уникальный порядковый номер пользователя;

· RoleId — хранит уникальный порядковый номер роли.

Данная сущность выстраивает отношение между пользователем и доступными для него ролями.

Генерация базы данных На основании списка сущностей предметной области, описанного выше, и связей между ними можно сгенерировать схему базы данных. Создание нашей базы данных будет происходить в несколько этапов:

1. Создание БД;

2. Создание таблиц и полей;

3. Связь таблиц между собой, построение диаграммы БД.

Рассмотрим каждый из этих этапов более подробно.

Создание БД Осуществление этого этапа будет производить при помощи Microsoft Visual Studio 2005. При нажатии на кнопку Tools в панели меню, выпадет список команд. Нажав на команду Connect to Database появляется окно (рис. 5), в котором выбираем название сервера из выпадающего списка, затем можно выбрать уже созданную ранее БД или ввести новое имя для БД, а так же можно прикрепить файл БД, если он был создан в другом месте.

Рис. 5

В нашем случае впишем новое название для базы ASPNETDB. На сервере в папке Data будет создана БД с таким названием. В Microsoft Visual Studio 2005, открыв Server Explorer, можно увидеть эту БД и список различных папок для работы с ней (рис. 6).

Рис. 6

Так же можно создать БД с помощью следующей SQL команды:

CREATE DATABASE ASPNETDB

Создание таблиц и полей Нажав правой кнопкой мыши на папку Tables, выпадает меню, где можно добавить новую таблицу к БД. Затем нужно создать все необходимые поля в этой таблице, задать их типы данных и определить ключевые поля. Задать разрешение на содержание нулевых значений в этой таблице путем установления флажка Allow null напротив выбранного поля. При помощи SQL команды можно проделать то же самое.

CREATE TABLE ASPNET_USERS (

APPLICATIONID UNIQUEIDENTIFIER NOT NULL,

USERID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

USERNAME NVARCHAR (256) NOT NULL,

LOWEREDUSERNAME NVARCHAR (256) NOT NULL,

LASTACTIVITYDATE DATETIME NOT NULL

)

CREATE TABLE ASPNET_APPLICATIONS (

APPLICATIONID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

APPLICATIONNAME NVARCHAR (256) NOT NULL,

LOWEREDAPPLICATIONNAME NVARCHAR (256) NOT NULL,

DESCRIPTION NVARCHAR (256) NULL

)

CREATE TABLE ASPNET_MEMBERSHIP (

APPLICATIONID UNIQUEIDENTIFIER NOT NULL,

REFERENCES APPLICATIONS (APPLICATIONID),

USERID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

REFERENCES USERS (USERID),

PASSWORD NVARCHAR (128) NOT NULL,

PASSWORDFORMAT INT NOT NULL,

EMAIL NVARCHAR (256) NULL,

LOWEREDEMAIL NVARCHAR (256) NULL,

PASSWORDQUESTION NVARCHAR (256) NULL,

PASSWORDANSWER NVARCHAR (128) NULL,

ISAPPROVED BIT NOT NULL,

CREATEDATE DATETIME NOT NULL,

LASTLOGINDATE DATETIME NOT NULL

)

CREATE TABLE ASPNET_ROLES (

APPLICATIONID UNIQUEIDENTIFIER NOT NULL,

REFERENCES APPLICATIONS (APPLICATIONID),

ROLEID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

ROLENAME NVARCHAR (256) NOT NULL,

LOWEREDROLENAME NVARCHAR (256) NOT NULL,

DESCRIPTION NVARCHAR (256) NULL

)

CREATE TABLE USERSINROLES (

ROLEID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

REFERENCES ROLES (ROLEID),

USERID UNIQUEIDENTIFIER NOT NULL PRIMARY KEY,

REFERENCES USERS (USERID),

)

После выполнения вышеописанных запросов, мы получим необходимые нам таблицы и связи между ними (рис.7).

Рис. 7.

Для проверки работоспособности полученной БД администрирования, можно реализовать несколько запросов и хранимых процедур.

Примеры использования запросов и хранимых процедур Для совершения различных манипуляций с хранилищами данных можно использовать как sql запросы, так и хранимые процедуры.

Примеры использования запросов и хранимых процедур Данный запрос позволяет отобразить все роли, которыми наделен пользователь «User»:

SELECT aspnet_Roles.RoleName

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

@ApplicationName nvarchar (256),

@Email nvarchar (256)

AS

BEGIN

IF (@Email IS NULL)

SELECT u. UserName

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

m.LoweredEmail IS NULL

ELSE

SELECT u. UserName

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

LOWER (@Email) = m. LoweredEmail

IF (@@rowcount = 0)

RETURN (1)

RETURN (0)

END

Данная хранимая процедура позволяет создать пользователя в системе:

ALTER PROCEDURE [dbo]. aspnet_Users_CreateUser

@ApplicationId uniqueidentifier,

@UserName nvarchar (256),

@IsUserAnonymous bit,

@LastActivityDate DATETIME,

@UserId uniqueidentifier OUTPUT

AS

BEGIN

IF (@UserId IS NULL)

SELECT @UserId = NEWID ()

ELSE

BEGIN

IF (EXISTS (SELECT UserId FROM dbo. aspnet_Users

WHERE @UserId = UserId))

RETURN -1

END

INSERT dbo. aspnet_Users (ApplicationId, UserId, UserName, LoweredUserName, IsAnonymous, LastActivityDate)

VALUES (@ApplicationId, @UserId, @UserName, LOWER (@UserName), @IsUserAnonymous, @LastActivityDate)

RETURN 0

END

В приложение Б детально показана структура базы данных.

4.3 Реализация пользовательского интерфейса Для реализации пользовательского интерфейса нам сперва потребуется создать мастер страницу, т. е. основную страницу, дизайн которой будет применен ко всем остальным страницам. Для этого нам необходимо выполнить следующие шаги:

1) Открыть MS Visual Studio 2005.

2) Выбрать разрабатываемый проект.

Рис. 8. Шаг 1 и 2

3) Открыть окно Solution Explorer, правой кнопкой мыши кликнуть по названию проекта и выбрать пункт под названием Add New Item. Далее выбрать необходимый нам элемент, а именно Master Page.

Рис. 9. Шаг 3.

После того как мастер страница создана, в нее необходимо поместить следующий код:

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs" Inherits="MasterPage" %>