53
Дефект
кодДефекта
Integer
Да
Да
названиеДефекта
Text
(100)
100
Да
Узел
кодУзла
Integer
Да
Да
Наименование
Text
(100)
100
Да
описание
Text
(100)
100
Да
Полная атрибутивная модель данных предметной области управления
личными финансами представлена на рис.3.7
Рисунок 3.7 – FA – модель данных
Физическое моделирование включает в себя фактическое
проектирование базы данных в соответствии с требованиями, которые были
установлены при логическом моделировании. Логическое моделирование в
основном включает в себя сбор требований бизнеса, причем последняя часть
логического моделирования направлена на достижение целей и требований
имеет
оформляет
оформляется по
Выполняется
формируется
выявляет
содержит
Автомобиль
#
o
o
o
o
кодАвто
типКузова
марка
модель
регНомер
Integer
Text (100)
Text (100)
Text (100)
Text (100)
Сотрудник
#
o
o
o
o
кодСотрудника
Фамилия
Имя
Отчество
ТипСотрудника
...
Integer
Text (100)
Text (100)
Text (100)
Text (100)
Клиент
#
o
o
o
кодКлиента
ФИО
адрес
телефон
Integer
Text (150)
Text (100)
Text (10)
АктПриема
#
o
o
o
номерАкта
ДатаПриема
Жалобы
Примечание
...
Integer
Date
Text (255)
Text (255)
ЗаказНаряд
#
o
o
номерНаряда
ДатаНачалаРабот
ДатаОкончанияРабот
...
Integer
Date
Date
Дефектовка
#
o
кодДефектовки
сос тояние
Integer
Text (200)
Дефект
#
o
кодДефекта
названиеДефекта
Integer
Text (100)
Узлы
#
o
o
кодУзла
наименование
опис ание
...
Integer
Text (100)
Text (100)
54
базы данных. Физическое моделирование связано с преобразованием
логической или бизнес-модели в модель реляционной базы данных. Когда
происходит физическое моделирование, объекты определяются на уровне
схемы. Схема - это группа связанных объектов в базе данных. Усилия по
разработке базы данных обычно связаны с одной схемой.
Во время физического моделирования такие объекты, как таблицы и
столбцы, создаются на основе объектов и атрибутов, которые были
определены при логическом моделировании. Также определены ограничения,
включая первичные ключи, внешние ключи, другие уникальные ключи и
проверочные ограничения. Представления могут быть созданы из таблиц
базы данных, чтобы суммировать данные, или просто предоставить
пользователю другую перспективу определенных данных. Другие объекты,
такие как индексы и представления, также могут быть определены во время
физического моделирования. Физическое моделирование - это когда все
части объединяются для завершения процесса определения базы данных для
бизнеса.
Физическое моделирование - это специфическое для базы данных
программное обеспечение, означающее, что объекты, определенные во время
физического моделирования, могут варьироваться в зависимости от
используемого программного обеспечения реляционной базы данных.
Например, большинство реляционных систем баз данных имеют разные
варианты представления типов данных и способы хранения данных, хотя
базовые типы данных концептуально одинаковы для разных реализаций.
Кроме того, некоторые системы баз данных имеют объекты, которые
недоступны в других системах баз данных.
Для построения трансформационной модели необходимо определить
домены атрибутов сущностей, области их допустимых значений, а также
типы данных. Для построения трансформационной модели необходимо
определить домены атрибутов сущностей, области их допустимых значений,
55
а также типы данных. В таблице 3.8 отображены необходимые данные и
примеры значений, используемые в базе данных.
Таблица 3.8 – Домены атрибутов сущностей
Шифр
домена
Наименов
ание
Домена
Определение домена
Тип
данных
Пример
значения
D1
Порядков
ый
номер
Целое число, принимает
уникальные значения
integer
1
D2
Дата
ЧЧ.ММ.ГГГГ – дата, где
ЧЧ – две цифры, число (от
01до 31)
ММ – две цифры, месяц (от
01 до 12)
ГГГГ – четыре цифры, год
(от 0000 до 9999)
date
14.12.2015
D3
Строка
символов
переменн
ой
длины
100
символов
Множество символьных
значений переменной
длины не более 100
символов. Выбирается
одно значение из
указанного множества
text(100)
Капитонов
Игорь
Николаевич
В качестве СУБД была выбрана MS SQL Server. Физическая модель
данных для предметной области представлена на рис.3.8.
56
Рисунок 3.8 – Физическая модель данных
Представление физической реализации системы
Диаграммы компонентов
В Unified Modeling Language диаграмма компонентов показывает, как
компоненты информационной системы соединяются друг с другом для
образования более крупных компонентов или программных систем.
Диаграмма используется для иллюстрации структуры сложных систем.
Компонент описывает некоторый функционал системы. Примерами
компонентов могут быть исполняемые файлы, документы, таблицы базы
данных, файлы и файлы библиотек.
Компоненты соединяются друг с другом через интерфейсы одного
компонента с помощью прилагаемого интерфейса другого компонента. Это
можно продемонстрировать как модель отношений потребитель сервиса -
провайдер услуг.
FK_АВТОМОБИ_ИМЕЕТ_КЛИЕНТ
FK_АКТПРИЕМ_ОФОРМЛЯЕТ_СОТРУДНИ
FK_АКТПРИЕМ_ОФОРМЛЯЕТ_АВТОМОБИ
FK_ДЕФЕКТОВ_ВЫПОЛНЯЕТ_ЗАКАЗНАР
FK_ЗАКАЗНАР_ФОРМИРУЕТ_АКТПРИЕМ
FK_ДЕФЕКТОВ_ВЫЯВЛЯЕТ_ДЕФЕКТ
FK_ДЕФЕКТОВ_СОДЕРЖИТ_УЗЛЫ
Автомобиль
кодАвто
кодКлиента
типКузова
марка
модель
регНомер
int
int
text
text
text
text
<pk>
<fk>
Сотрудник
кодСотрудника
Фамилия
Имя
Отчес тво
ТипСотрудника
...
int
text
text
text
text
<pk>
Клиент
кодКлиента
ФИО
адрес
телефон
...
int
text
text
text
<pk>
АктПриема
номерАкта
кодАвто
кодСотрудника
ДатаПриема
Жалобы
Примечание
...
int
int
int
datetime
text
text
<pk>
<fk2>
<fk1>
ЗаказНаряд
номерНаряда
номерАкта
ДатаНачалаРабот
ДатаОкончанияРабот
...
int
int
datetime
datetime
<pk>
<fk>
Дефектовка
кодДефектовки
кодДефекта
кодУзла
номерНаряда
состояние
...
int
int
int
int
text
<pk>
<fk2>
<fk3>
<fk1>
Дефект
кодДефекта
названиеДефекта
int
text
<pk>
Узлы
кодУзла
наименование
описание
...
int
text
text
<pk>
57
Коннектор является "связующим звеном между двумя компонентами,
который определяет, что один компонент предоставляет услуги, которые
другой компонент требует. Коннектор является соединителем, который
определен либо при помощи интерфейса или порта через который
обеспечивается доступ к сервису." [20, 25, 26]
При использовании диаграммы компонентов, можно показать
внутреннюю структуру компонента, с описанием требуемых интерфейсов.
Коннектор делегирования является "коннектором, который соединяет
внешний контракт компонента и внутреннюю реализацию этого поведения в
компоненте." [20, 25, 26].
Диаграмма компонентов ИС показывает набор основных компонентов
и их взаимодействие между собой (рис.3.9).
Рисунок 3.9 – Диаграмма компонентов
Диаграммы классов показывают разные классы, которые составляют
систему и как они соотносятся друг с другом. Диаграммы классов
называются «статическими» диаграммами, потому что они показывают
классы вместе с их методами и атрибутами, а также статические отношения
между ними: какие классы «знают» о том, какие классы или какие классы
Мод уль авторизации
Мод уль менед жера
Мод уль механика Мод уль руковод ит еля
Регист рация клиент ов
<<art ifact>>
Регист рация ТС
<<art ifact>>
Поиск д анных
<<art ifact>>
Формирование отчет а по д иагност ике
<<art ifact>>
Формирование д иагност ической карты
<<art ifact>>
Отчет по заказам клиент ов
<<art ifact>>
Отчет по д иагност ике ТС
<<art ifact>>
Отчет по сот руд никам
<<art ifact>>
58
«являются частью» другого класса, но не показывать вызовы методов между
ними (рис.10).
Идентификация классов, участвующих в реализации потоков событий
вариантов использования. В потоках вариантов использования используются
классы трех типов [18]:
Граничные классы (Boundary) - служат посредником при
взаимодействии внешних объектов с системой.
Классы-сущности (Entity) - представляют собой ключевые абстракции
(понятия) разрабатываемой системы.
Управляющие классы (Control) - обеспечивают координацию
поведения объектов в системе.
Диаграмма развертывания
Для работы программы предлагается клиент-серверная архитектура
приложения. В такой архитектуре на сервер хранится база данных, а на
клиентских машинах установлено программное обеспечение, которое
обеспечивает графический пользовательский интерфейс и отсылку запросов
пользователя к базе данных. Пример клиент-серверной архитектуры для
программы учета и планирования деятельности СТО с использованием
«толстого клиента» представлена на рисунке 3.10.
59
Рисунок 3.10 Двухзвенная архитектура «клиент-сервер»
Диаграмма развёртывания, Deployment diagram в UML моделирует
физическое развертывание артефактов на узлах.
Существует два типа узлов:
Узел устройства
Узел среды выполнения
Узлы устройств — это физические вычислительные ресурсы со своей
памятью и сервисами для выполнения программного обеспечения, такие как
обычные ПК, мобильные телефоны. Узел среды выполнения — это
программный вычислительный ресурс, который работает внутри внешнего
узла и который предоставляет собой сервис, выполняющий другие
исполняемые программные элементы.
Размещение артефактов приложения по физическим устройствам
отображается диаграммой развертывания.
Рисунок 3.11 - Диаграмма развертывания — все артефакты
размещаются в одном компьютере
60
Рисунок 3.12 - Диаграмма развертывания — артефакты
распределены по трем компьютерам
Основными узлами на этой диаграмме являются компьютеры, в
которых размещаются артефакты приложения, основными из которых
являются физические воплощения пользовательского интерфейса, бизнес-
логики и базы данных. Все эти три артефакта можно разместить либо в
одном компьютере, либо в двух, либо в трех. Указанные варианты внешне
соответствуют одно-, двух- и трехзвенной архитектурам, хотя, конечно,
количество звеньев архитектуры определяется не размещением компонентов
по машинам, а способом организации основных частей системы и формой
взаимодействия между ними.
Изображение одномашинного размещения артефактов приложения
показано на рис. 3.11, а трехмашинного — на рис. 3.12.
61
3.4 Определение сметы затрат на проектирование и разработку
Расчет себестоимости разработки информационной системы
осуществляется по следующим экономическим элементам затрат:
1. материальные затраты;
2. затраты на оплату труда;
3. основные фонды;
4. прочие затраты.
Расчет перечисленных затрат, выраженный в денежном формате дает
ценовую характеристику разработанной ИС, что позволяет, в дальнейшем,
проанализировать период самоокупаемости системы.
Приступая к расчетам себестоимости ИС, необходимо посчитать
количество рабочих дней в году, исключая праздники и выходные дни (
),
т.к. данный показатель будет участвовать в дальнейших расчетах. Годовой
фонд рабочего времени высчитывается по следующей формуле:
потерипланнерабгодрг
ДДДФ
...
(1)
где
рг
Ф
.
- годовой фонд рабочего времени;
год
Д
- количество дней в году;
.нераб
Д
- нерабочие дни;
потериплан
Д
.
- планируемые потери.
Результат расчета
представлен в таблице 3.9
Таблица 3.9 –Годовой фонд рабочего времени
Структура фонда времени
Годовой фонд времени
Календарный фонд времени в году,
дни (
)
365
Нерабочие дни
118
1) Выходные
104
2) Праздничные
14
62
Планируемые потери, дни
потериплан
Д
.
24
1) Отпуск
20
2) Болезнь
4
Годовой фонд рабочего времени
рг
Ф
.
223
Себестоимость программного продукта рассчитывается следующим
образом:
1. заработная плата;
Необходимо найти заработную плату за весь срок работы над проектом
. Данный показатель определяется по следующей формуле (2):
????
????
, (2)
где
????
????
- средняя заработная плата в день;
– количество полных дней работы над проектом с учетом 6
часового рабочего дня.
= *84 = 79312.8 руб.
Количество полных дней работы над проектом с учетом 6 часового
рабочего дня находится по формуле (3):
(3)
где
-количество дней работы над проектом;
- количество рабочих часов в день.
=84/6 * 6 = 84
Количество дней работы над проектом находится по формуле (4):
, (4)
где
-количество рабочих дней в месяц;
– количество рабочих часов над проектом в день.
=21*4 = 84
Среднюю заработную плату в день
????????
можно найти по формуле (5):
????????
????
????
, (5)