- •С.Л. Моругин Проектирование информационных систем
- •Часть 2
- •Содержание
- •5. Модели процессов
- •5.1. Состав функциональной модели
- •5.2. Иерархия диаграмм
- •5.3. Типы связей между функциями
- •5.4. Моделирование процессов по стандарту idef0
- •5.5. Модели as-is и то-ве
- •5.6. Моделирование в стандарте idef0
- •5.7. Нумерация работ и диаграмм
- •5.8. Диаграммы дерева узлов и feo
- •5.9. Каркас диаграммы
- •5.10. Рекомендации по рисованию диаграмм
- •6. Модели данных
- •6.1. Концепция баз данных
- •6.1.1. Независимость данных от обработки
- •6.1.2. Системы управления базами данных
- •6.1.3. Понятие о модели данных
- •6.1.4. Концепция трех схем
- •6.1.5. Семантические модели данных
- •6.1.6.Ограниченность реляционной модели при проектировании баз данных
- •6.1.7. Общие принципы классификации субд
- •6.1.8. Основные задачи и этапы проектирования баз данных
- •6.1.8.1. Основные задачи:
- •6.1.8.2.Основные этапы проектирования баз данных
- •6.2. Концептуальные модели предметной области
- •6.2.2. Основные понятия er-модели
- •6.2.2.1. Понятие сущности. Типы сущностей
- •6.2.2.2. Стержневая сущность
- •6.2.2.3. Ассоциация
- •6.2.2.4. Характеристика
- •6.2.2.5. Обозначение
- •6.2.2.6. Атрибут сущности
- •6.2.2.7. Ключ
- •6.2.2.8. Связь
- •6.2.3. Нотация Чена для изображения er-диаграмм
- •6.3. Логические модели данных
- •6.3.1. Получение реляционной схемы из er-модели
- •6.3.2. Построение логических реляционных моделей данных в стандарте idef1x
- •6.3.3. Создание логической реляционной модели данных в erWin
- •6.3.3.1. Ключи
- •6.3.3.2. Домены
- •6.3.3.3. Задание атрибутов модели
- •6.3.3.4. Задание связей
- •6.3.3.5. Связь многие-ко-многим
- •6.3.3.6. Типы сущностей и иерархия наследования
- •6.3.3.7. Пример создания модели
- •6.3.3.8. Денормализация в eRwin
- •6.3.3.4. Создание физической модели данных
- •6.4. Согласование моделей данных и моделей процессов
- •3. Создание сущностей и атрибутов bPwin и их экспорт в eRwin
- •7 Метрики программного обеспечения
- •7.1. Метрика
- •7.2. Размерно-ориентированные метрики
- •7.3. Функционально-ориентированные метрики
- •7.4. Метрики указателей свойств (Features Points).
- •7.5. Оценка сроков выполнения проекта и его трудоемкости
- •Обозначения и сокращения
- •Библиографический список
- •Проектирование информационных систем
- •607220, Г. Арзамас, Нижегородская обл., ул. К.Маркса, 36
- •607220, Г. Арзамас, Нижегородская обл., ул. К.Маркса, 36
7.4. Метрики указателей свойств (Features Points).
Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика — количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 7.11.
Таблица 7.10 - Определение системных параметров приложения
№ |
Системный параметр |
Описание |
1
|
Передачи данных |
Сколько средств связи требуется для передачи или обмена информацией с приложением или системой? |
2
|
Распределенная обработка данных |
Как обрабатываются распределенные данные и функции обработки? |
3
|
Производительность |
Нуждается ли пользователь в фиксации времени ответа или производительности? |
4
|
Распространенность используемой конфигурации |
Насколько распространена текущая аппаратная платформа, на которой будет выполняться приложение? |
5 |
Скорость транзакций |
Как часто выполняются транзакции? (каждый день, каждую неделю, каждый месяц) |
6 |
Оперативный ввод данных |
Какой процент информации надо вводить в режиме онлайн? |
7 |
Эффективность работы конечного пользователя |
Приложение проектировалось для обеспечения эффективной работы конечного пользователя? |
8 |
Оперативное обновление |
Как много внутренних файлов обновляется в онлайновой транзакции? |
9 |
Сложность обработки |
Выполняет ли приложение интенсивную логическую или математическую обработку? |
10 |
Повторная используемость |
Приложение разрабатывалось для удовлетворения требований одного или многих пользователей? |
11 |
Легкость инсталляции |
Насколько трудны преобразование и инсталляция приложения? |
12 |
Легкость эксплуатации |
Насколько эффективны и/или автоматизированы процедуры запуска, резервирования и восстановления? |
13 |
Разнообразные условия размещения |
Была ли спроектирована, разработана и поддержана возможность инсталляции приложения в разных местах для различных организаций? |
14 |
Простота изменений |
Была ли спроектирована, разработана и поддержана в приложении простота изменений? |
Таблица 7.11 - Исходные данные для расчета указателя свойств
№ |
Характеристика |
Количество |
Сложность |
Итого |
1 |
Вводы |
|
x 4 |
= |
2 |
Выводы |
|
х 5 |
= |
3 |
Запросы |
|
x 4 |
= |
4 |
Логические файлы |
|
x 7 |
= |
5 |
Интерфейсные файлы |
|
x 7 |
= |
6 |
Количество алгоритмов |
|
x З |
= |
Общее количество |
= |
|||
После заполнения таблицы по формуле (7.1) вычисляется значение указателя свойств. Для сложных систем реального времени это значение на 25-30% больше значения, вычисляемого по таблице для количества функциональных указателей.
Достоинства функционально-ориентированных метрик:
1) Не зависят от языка программирования.
2) Легко вычисляются на любой стадии проекта.
Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения. FP-оценки легко пересчитать в LOC-оценки. Результаты пересчета зависят от языка программирования, используемого для реализации ПО.
Сравнительные параметры двух видов моделей, основанных на функциональных точках приведены в таблицах 7.12 и 7.13
Таблица 7.12 – Основные параметры качества для анализируемых
моделей
Параметр |
FPA IFPUG |
MK II FPA |
Тип модели |
Открытая |
Открытая |
Доступность репозиториев |
Да, множество репозиториев |
Нет |
Время применения |
На протяжении всего жизненного цикла после определения требований |
На протяжении всего жизненного цикла после определения требований |
Учет факторов размера системы |
На основе репозитория |
На основе репозитория |
Непрерывная зависимость от сложности проекта |
Да |
Да |
Таблица 7.13 – Учет требований к системе в моделях
Параметр |
FPA IFPUG |
MK II FPA |
Учет функциональной сложности |
Да, на основе cкорректированного количества функциональных точек IFPUG |
Да, на основе cкорректированного количества функциональных точек MK II |
Учет нефункциональных требований к системе |
Распределенная обработка, Производительность, Загруженность конфигурации, Частота транзакций, повторная используемость, Множество инсталляций, Упрощение внесения изменений |
Распределенная обработка, Производительность, Загруженность конфигурации, Частота транзакций, повторная используемость, Множество инсталляций, Упрощение внесения изменений, защита информации, требования к документированию |