2.2Требования к программе

Программа Корпоративный портал должен реализовывать следующие функции:

- корректировка баз данных, управления интерфейсом, изменения учетных данных пользователей, добавления событий, новостей и др.;

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

2.3Требования к программной документации

Программная документация должна быть представлена документом "Руководство пользователя".

2.4Стадии и этапы разработки

В соответствии с ГОСТ 19.102-77 должны быть выполнены следующие стадии разработки:

1) Техническое задание.

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

3) Проектирование программного комплекса.

4) Технические характеристики разработки программного обеспечения.

5) Внедрение.

3Разработка эскизного проекта Web-приложения.

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

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

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

определить общие границы и контекст моделируемой предметной области;

сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

Суть диаграммы вариантов использования состоит в следующем. Проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актеру. Диаграмма вариантов использования может дополняться пояснительным текстом, который раскрывает смысл или семантику составляющих ее компонентов.

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

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

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

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

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

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

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

Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе. На рисунке четыре действующих лица: Администратор, Менеджер по продажам, Пользователь заказчик(З), Пользователь исполнитель(И). Действующие лица представляют собой роли, а не конкретных людей или наименования работ.

Рисунок 1 – Диаграмма вариантов использования

Диаграммы последовательности

Диаграмма последовательности для основного потока событий представлена на рисунке 3.

Диаграмма последовательности для варианта использования «Закрыть программу» представлена на рисунке 4.

Диаграмма последовательности для варианта использования «Оформить продажу» представлена на рисунке 5.

Диаграмма последовательности для варианта «Присоединиться к серверу» представлена на рисунке 6.

Рисунок 2 - Диаграмма основного потока

Основной поток событий:

1. Оператор вводит данные через графический интерфейс

2. Приложение проверяет правильность введенных данных или же при обнаружении ошибки вызывает поток ошибок Е1

3. Приложение посылает запрос на подтверждение соединения MySQL

4. MySQL подтверждает соединение

5. Приложение обновляет данные

6. Приложение обновляет графические данные

Поток ошибок Е1

1. Программа сообщает об ошибке ввода данных

Осуществляется возврат на форму ввода данных

Рисунок 3 - Диаграмма последовательности для варианта использования закрытие приложения

Основной поток событий:

1. Оператор нажимает на кнопку закрытия формы

2. Форма посылает запрос на завершение соединения

3. Компонент посылает запрос MySQL на освобождение ресурсов

4. MySQL возвращает уведомление об освобождении ресурсов

5. Компонент освобождает выделенную под соединение память

6. Компонент возвращает форме уведомление о завершении соединения

7. Форма вызывает закрытие приложения

8. Приложение возвращает форме код результата закрытия приложения

9. Форма закрывается или же вызывает поток ошибок Е1

Поток ошибок Е1

1. В случае неудачи программа сообщает об ошибке

2. Вызывается отладка приложения

Рисунок 4 - Диаграмма последовательности для варианта использования оформление вакансии

1. Пользователь нажимает на кнопку Вакансии

2. Форма вакансий составляет список вакансий для пользователей

3. Форма запроса на проверку

4. Форма проверки данных на корректную информацию

5. Подтверждение информации

6. Размещение вакансии в базе данных MySQL

Рисунок 5 - Диаграмма последовательности для варианта присоединиться к веб-приложению

Основной поток событий:

1. Пользователь нажимает на кнопку войти на сайт

2. Форма ввода имени и пароля запрашивает имя пользователя

3. Форма ввода имени и пароля запрашивает пароль

4. Форма ввода имени и пароля создает запрос

5. Форма ввода имени и пароля отправляет запрос MySQL

6. MySQL обрабатывает запрос и дает пользователю доступ к веб-приложению

Диаграмма классов

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

Рисунок 6 - Диаграмма классов (VOPC)

Диаграмма компонентов

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

Каждый класс модели (или подсистема) преобразуется в компонент исходного кода. После создания они сразу добавляются к диаграмме компонентов. Между отдельными компонентами изображают зависимости, соответствующие зависимостям на этапе компиляции или выполнения

программы.

Рисунок 7 - Диаграмма компонентов