ГЛАВА 3. ЭСКИЗНЫЙ ПРОЕКТ

3.1. Предварительная оценка затрат

Для каждой выделенной функции высчитано количество факторов каждого типа (Таблица 3.1) [6]:

1. Внешние входы (входы, которые по-разному влияют на выполняемую функцию);

2. Внешние выходы (отдельно считаются выходы для существенно различных алгоритмов);

3. Внешние запросы (каждый независимый внешний запрос 1);

4. Внутренние логические файлы (каждая уникальная группа пользовательских данных считается за 1);

5. Внешние логические файлы (каждая уникальная группа пользовательских данных считается за 1).

Таблица 3.1 – Сопоставление функций системы информационным характеристикам и сложности

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

Таблица 3.2 – используемые внутренние логические файлы

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

Таблица 3.4 – Информационные характеристики

Определение веса для 14 общих характеристик проекта:

1. Обмен данными – 2;

2. Распределенная обработка данных – 2;

3. Производительность – 5;

4. Ограничения по аппаратным – 3;

5. Транзакционная – 1;

6. Интенсивность взаимодействия с пользователем – 2;

7. Эргономика – 4;

8. Интенсивность изменения данных (ILF) – 4;

9. Сложность обработки – 0;

10. Повторное использование – 3;

11. Удобство инсталляции – 2;

12. Удобство администрирования – 5;

13. Портируемость – 5;

14. Гибкость – 5.

Расчет суммарного эффекта 14 системных характеристик (total degree of influence, TDI) осуществляется простым суммированием:

TDI = ∑ DI = 43, (1)

Расчет уточненного функционального размера:

VAF = (TDI *0.01) + 0.65 = (43 *0.01) + 0.65 = 1.08, (2)

Расчет количества выровненных функциональных точек (AFP):

AFP = UFP * VAF = 70*1.08=75.6, (3)

Оценка количества строк кода:

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

KLOC = (AFP*N)/1000 = (75.6* 50)/1000 = 3,780, (4)

Оценка затрат труда и продолжительности проекта:

Затраты в человеко-месяцах:

= 9.7, (5)

Количество месяцев:

= 5.93, (6)

Где a, b, c, d – коэффициенты для распространенных типов проектов (небольшие программные проекты, над которыми работает небольшая группа разработчиков с хорошим стажем работы, устанавливаются мягкие требования к проекту): a = 2,4, b = 1,05, c = 2,5, d = 0,38.

3.2. Диаграммы вариантов использования и деятельности системы в целом

Диаграмма вариантов использования (use case diagram) (или диаграмма прецедентов) описывает функциональное назначение системы, то есть то, что система должна делать исходя из цели её создания.

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

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

Диаграмма деятельности (activity diagram) представляет, по существу, блок-схему, которая показывает, как поток управления переходит от одной деятельности к другой.

Диаграммы деятельности, как правило, они применяются, чтобы промоделировать последовательные и при необходимости параллельные шаги вычислительного процесса. С помощью диаграмм деятельности можно также моделировать жизнь объекта, когда он переходит из одного состояния в другое в разных точках потока управления. Диаграмма деятельности web-сайта киноцентра приведена в приложении З.

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

Диаграмму состояний часто рассматривают в контексте конечного автомата. Тогда можем сказать, что диаграмма состояний (Statechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию.

Автомат (State machine) – это описание последовательности состояний, через которые проходит объект на протяжении всего жизненного цикла, реагируя на события, - в том числе описание реакций на эти события.

Состояние (State) – это ситуация в жизни объекта, на протяжении которой он удовлетворяет некоторому условию, осуществляет определенную деятельность или ожидает какого-то события.

Диаграмма состояний web-сайта киноцентра представлена в приложении Ж.

Диаграммы последовательности (sequence diagram) UML отражают поток событий, происходящих в рамках реализации конкретного варианта использования.

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

На диаграмме последовательности объект изображается в виде прямоугольника, от которого вниз проведена пунктирная вертикальная линия. Эта линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение представляется в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице сверху вниз. Каждое сообщение помечается как минимум именем сообщения. При желании можно добавить также аргументы и некоторую управляющую информацию. Можно показать самоделегирование (self-delegation) – сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

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

3.4. Диаграммы классов (ER-модель)

Слой данных описывает структуру таблиц, хранящихся в БД. Атрибуты классов соответствуют полям таблицы. Модель представлена в приложении И.

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

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

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

Диаграммы компонентов представлены в приложении К.

ГЛАВА 4. ЭКСПЛУТАЦИОННАЯ ДОКУМЕНТАЦИЯ

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