3.2 Выявление классов

Центральное место в объектно-ориентированном программировании занимает разработка логической модели системы в виде диаграммы классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений.

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

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

Класс связи с сервером проекта

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

Пользовательский класс

Осуществляет взаимодействие пользователя-ребёнка и браузера.

Класс управления системой

Осуществляет настройку работы приложения родителями.

Класс вывода информации

О существляет проверку сайта, согласно заданным ограничениям, и вывод его в браузере или запрет на его вывод, или вывод иконок разрешённых сайтов.

Рисунок 2 – взаимодействие классов.

4. Технико-экономическое обоснование проекта

4.1 Выбор экономической модели и типа программного проекта

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

где E – трудоемкость проекта [чел/мес.], KLOC – размер программного продукта [строки*1000];

где D – время разработки [мес.], коэффициенты a, b, c, d определяются опытным путем; они зависят от типа проектируемой системы.

Существует 3 типа программных систем:

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

2. Полунезависимый тип – средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту.

3. Встроенный тип - программный проект разрабатывается в условиях жестких аппаратных, программных и вычислительных ограничений.

Значения коэффициентов уравнения базовой модели КОМОСТ представлены в таблице 2.

Таблица 2 – коэффициентов базовой модели КОМОСТ

Тип программного продукта	a	B	c	d
Распространенный	2.4	1.05	2.5	0.38
Полунезависимый	3.0	1.12	2.5	0.35
Встроенный	3.6	1.2	2.5	0.32

Рассматриваемый проект (т.е. проектируемую систему «Детский Интернет») имеет относительно небольшую алгоритмическую сложность и невысокий уровень графики, следовательно, его можно отнести к распространенному типу. Таким образом, коэффициенты для данного проекта следующие: a = 2.4, b = 1.05, c = 2.5, d = 0.38.