
- •Системный анализ и проектирование компьютерных информационных систем
- •1Введение в системный анализ
- •1.1Системный анализ как научная дисциплина
- •1.2Компьютерная техника и системный анализ
- •1.3Система и ее свойства
- •Свойства системы
- •1.3.1Структура и иерархия систем
- •1.3.2Модульное строение системы
- •1.3.3Состояние системы и процессы в системе
- •1.3.4Целенаправленные системы и управление
- •Управление системами
- •1.4Принципы системного подхода
- •Принцип конечной цели
- •Принцип единства и связи
- •Принцип модульного построения
- •Принцип иерархии
- •Принцип функциональности
- •Принцип развития
- •Принцип децентрализации
- •Принцип неопределенности
- •Дополнительные принципы системного подхода
- •Практическое использование принципов системного подхода
- •2Информационные системы. Жизненный цикл информационной системы
- •2.1Определение информационной системы
- •Информация, данные, знания
- •Информационная система
- •2.2Классификация информационных систем
- •Классификация по типу хранимых данных
- •Классификация по степени автоматизации информационных процессов
- •Классификация по характеру обработки данных
- •Классификация по сфере применения
- •Классификация по уровню управления
- •Классификация по способу организации
- •2.3Жизненный цикл информационной системы
- •2.3.1Системный анализ
- •Определение требований
- •Оценка осуществимости
- •Оценка риска
- •Построение логической модели
- •Построение прототипа
- •2.3.2Проектирование
- •2.3.3Реализация
- •2.3.4Тестирование
- •2.3.5Эксплуатация
- •2.4Модели жизненного цикла информационной системы
- •2.4.1Каскадная модель жизненного цикла информационной системы
- •Основные достоинства каскадной модели
- •Недостатки каскадной модели
- •2.4.2Спиральная модель жизненного цикла информационной системы
- •Преимущества спиральной модели
- •3Методологии и технологии проектирования информационных систем
- •3.1Общие требования к методологиям и технологиям
- •Технологическую операцию проектирования представим:
- •3.2Стандарты организации жизненного цикла информационных систем
- •Стандарт проектирования должен устанавливать:
- •Стандарт оформления проектной документации должен устанавливать:
- •Стандарт интерфейса пользователя должен устанавливать:
- •3.3Методология быстрой разработки приложений rad
- •Фаза анализа и планирования требований
- •Фаза проектирования
- •Фаза построения
- •Фаза внедрения
- •Особенности и ограничения применения методологии rad.
- •Основные принципы методологии rad:
- •3.4Структурный подход к проектированию информационных систем
- •Структурный подход
- •Структурный анализ
- •Средства структурного анализа
- •4Методология функционального моделирования sadt (стандарт idef0)
- •4.1Анализ предметной области и принципы функционального моделирования по методологии sadt (стандарт оформления idef0)
- •Субъект моделирования
- •Цель моделирования
- •Точка зрения на модель
- •Модели as-is и то-ве
- •Принципы моделирования
- •4.2Состав функциональной модели sadt Типы диаграмм sadt-модели
- •Контекстная диаграмма
- •Диаграммы декомпозиции
- •Диаграммы дерева узлов
- •4.3Элементы контекстной диаграммы модели sadt Работа
- •Граничные стрелки
- •Контекстная диаграмма
- •4.4Элементы диаграммы декомпозиции модели sadt Работы
- •Миграция граничных стрелок и icom-коды
- •Внутренние стрелки
- •Разветвляющиеся и сливающиеся стрелки
- •4.5Иерархия диаграмм модели и диаграмма дерева узлов Иерархия диаграмм и контроль граничных стрелок
- •Туннелирование стрелок
- •Нумерация блоков и диаграмм
- •Диаграмма дерева узлов
- •4.6Рекомендации по рисованию диаграмм
- •4.7Проверка достоверности модели sadt
- •4.8Пример моделирования информационной системы с помощью методологии sadt (стандарт idef0)
- •Определение предметной области
- •Выбор цели
- •Выбор точки зрения
- •Построение контекстной диаграммы
- •Построение диаграммы декомпозиции а0
- •Выбор блока для декомпозиции следующего уровня
- •Построение диаграммы декомпозиции а2
- •Построение диаграммы декомпозиции а1
- •Окончание декомпозиции
- •Построение диаграммы дерева узлов
- •5Методологии получения количественных оценок функциональных моделей
- •5.1Цели проведения функционально-стоимостного анализа
- •5.2Построение фса-модели на базе idef0-модели
- •5.3Пример проведения функционально-стоимостного анализа с помощью методологии фса
- •6Методология последовательного выполнения процессов workflow (стандарт idef3)
- •6.1Базовые элементы модели idef3
- •Единицы работы
- •Перекрестки
- •Объект ссылки
- •6.2Иерархия диаграмм модели idef3 Контекстная диаграмма
- •Диаграммы декомпозиции
- •Нумерация работ и диаграмм
- •6.3Временные диаграммы активизации работ
- •6.4Пример применения методологии последовательного выполнения работ idef3
- •7Методология моделирования диаграмм потоков данных dfd
- •7.1Базовые элементы модели dfd
- •Процессы
- •Внешние сущности
- •Хранилища данных
- •Потоки данных
- •7.2Иерархия диаграмм потоков данных dfd к онтекстная диаграмма
- •Диаграмма декомпозиции
- •Нумерация работ и диаграмм
- •8Моделирование данных
- •8.12.1. Управление данными как ресурсами
- •8.22.2. Концепция трех схем
- •8.32.3. Цели моделирования данных
- •8.42.4. Idef1x-подход
- •8.53. Синтаксис и семантика idef1x
- •1. Сущности
- •8.5.13.1. Сущности
- •8.5.23.2. Отношения связи
- •8.5.33.3. Отношения категоризации
- •8.5.43.4. Неспецифические отношения
- •8.5.53.5. Атрибуты
- •8.5.63.6. Первичные и альтернативные ключи
- •8.5.73.7. Внешние ключи
- •8.64. Процедуры моделирования
- •8.6.14.1. Стадия 0 - начало работы над проектом
- •4.1.1. Определение цели моделирования
- •4.1.2. Разработка плана моделирования
- •4.1.3. Организационная структура коллектива разработчиков
- •4.1.4. Сбор исходной информации
- •4.1.5. Авторские соглашения
- •8.6.24.2. Стадия 1 - определение сущностей
- •4.2.1. Идентификация сущностей
- •4.2.2. Определение сущностей
- •8.6.34.3. Стадия 2 - определение отношений
- •4.3.1. Установление связанных сущностей
- •4.3.2. Определение отношений
- •4.3.3. Построение диаграмм уровней сущностей
- •8.6.44.4. Стадия 3 - определения ключей
- •4.4.1. Разрешение неспецифических отношений
- •4.4.2. Изображение функциональных точек зрения
- •4.4.3. Определение ключевых атрибутов
- •4.4.4. Миграция ключей
- •4.4.5. Проверка правильности ключей и отношений
- •4.4.6. Определение ключевых атрибутов
- •4.4.7. Изображение результатов стадии 3
- •8.6.54.5. Стадия 4 - определение атрибутов
- •4.5.1. Идентификация неключевых атрибутов
- •4.5.2. Определение владельцев атрибутов
- •4.5.3. Определение атрибутов
- •4.5.4. Детализация модели
- •4.5.5. Представление результатов стадии 4
- •8.75. Документирование и верификация
- •8.7.15.1. Введение
- •8.7.25.2. Idef1x-папка
- •8.7.35.3. Стандартные бланки
- •8.7.45.4. Процедура сквозного анализа idef-модели
- •8.8Приложение а
- •8.9Инфологическое проектирование
- •8.9.1Сущности и атрибуты
- •1.2.2. Связи
- •1.2.3. Формализация связей
- •1.2.4.Развитые элементы er-модели
- •9Сравнение существующих методик
- •Объектно-ориентированная методика
4.4.5. Проверка правильности ключей и отношений
Идентификация и миграция ключей подчиняется следующим основным правилам:
Нельзя использовать синтаксис неспецифических отношений.
Миграция ключей от родительских (или общих) сущностей к сущностям-потомкам (или сущностям-категориям) является обязательной.
Запрещается использовать атрибуты, которые могут принимать более одного значения для данного экземпляра сущности в одно и то же время (правило неповторяемости).
Нельзя использовать атрибуты, обращающиеся в ноль (т.е. не принимающие никакого значения) для некоторого экземпляра сущности (правило необращения в ноль).
Сущности с составными ключами не могут быть разбиты на несколько сущностей с более простыми ключами (правило наименьшего ключа).
Необходимо объявлять об имеющихся между двумя сущностями двойных путях отношений.
В предыдущих разделах мы уже рассмотрели первые два правила, поэтому остановимся на оставшихся.
На рис. 4-16 приведена диаграмма, относящаяся к применению правила неповторяемости. Обратите внимание, что субъект диаграммы содержит в качестве элементов первичного ключа сущности ЗАКАЗ атрибуты НОМЕР_ЗАКАЗА и НОМЕР_ПУНКТА_ЗАКАЗА. Однако, рассмотрев использование НОМЕРА_ПУНКТА_ЗАКАЗА, мы увидим, что один и тот же экземпляр сущности ЗАКАЗ может быть ассоциирован со многими НОМЕРАМИ_ПУНКТА_ЗАКАЗА, по одному на каждый заказываемый пункт. Для правильного отражения этого факта в модели данных должна быть создана новая сущность, называющаяся ПУНКТ_ЗАКАЗА с добавлением дуги и метки отношения, синтаксиса и определения. Таким образом, начинают выясняться истинные характеристики связи между заказами на покупку и пунктами заказов на покупку.
Рис. 4-16. Детализация правила неповторяемости
На рис. 4-17 приведена диаграмма вариантов детализации, относящаяся к применению правила необращения в ноль. Заметим, что НОМЕР_ДЕТАЛИ промигрировал к ПУНКТУ_ЗАКАЗА. Эта ассоциация установилась в связи с тем, что пункты заказа связаны некоторым образом с деталями. Однако показано, что диаграмма утверждает ассоциированность каждого пункта заказа на покупку в точности, с одним номером детали. Исследование (или, возможно, комментарий рецензента) показывает, что не все пункты заказа на покупку ассоциируются с деталями. Некоторые из них могут быть связаны с услугами или другими товарами, не имеющими номеров деталей. Это запрещает миграцию НОМЕРА_ДЕТАЛИ непосредственно в сущность ПУНКТА_ЗАКАЗА и требует в нашем примере установления новой сущности ЗАКАЗАННАЯ_ДЕТАЛЬ.
Рис. 4-17. Детализация правила необращения в ноль
Как только новая сущность установлена, в соответствии с правилом миграции обязательно должна произойти миграция ключа, и разработчик будет снова проверять правильность соответствия структуры сущность-отношение правилам необращения в ноль и неповторяемости.
Каждый составной ключ должен проверяться на соответствие правилу наименьшего ключа. Это правило требует, чтобы любая сущность с составным ключом не могла разделяться на несколько сущностей с более простыми ключами (на меньшие компоненты) без потери некоторой информации. Это правило является комбинацией и расширением четвертой и пятой нормальных форм в реляционной теории. Другие правила нормализации, такие, как правило полной функциональной зависимости или правило отсутствия транзитивной зависимости, не могут применяться до тех пор, пока на стадии 4 неключевые атрибуты не будут отражены в модели.
В связи со стадией 2 упоминалась тенденция выявления избыточных отношений. Однако на стадии 2 анализ, в основном, проводится разработчиком по его усмотрению. Установив ключи, разработчик может быть более точным в анализе. Двойной путь отношений существует тогда, когда существует сущность-потомок с двумя отношениями, ведущими, в конечном итоге, обратно (через одно или несколько отношений) к общей "корневой" сущности-родителю. В случае существования двойных путей требуется утверждение пути, чтобы определить, являются ли пути равными, неравными или неопределенными. Пути равны, если для каждого экземпляра сущности-потомка оба пути отношений всегда ведут к одному и тому же экземпляру корневой родительской сущности. Пути являются неравными, если для каждого экземпляра сущности-потомка оба пути отношений всегда ведут к различным экземплярам корневой родительской сущности. Пути являются неопределенными, если они равны для некоторых экземпляров сущности-потомка и не равны для остальных экземпляров. Если один из путей состоит только из одного отношения и пути равны, то путь из одного отношения является излишним и должен быть удален.
Простейшим случаем отношения, имеющего двойственные пути является отношение, в котором оба пути состоят из единственного отношения. Пример такой структуры приведен на рис. 4-15. Поскольку каждый экземпляр сущности СХЕМА_СБОРКИ может быть связан с двумя различными экземплярами сущности ДЕТАЛЬ, избыточности нет. В этом случае утверждение пути будет требовать, чтобы пути были неравны, поскольку ДЕТАЛЬ не может быть вмонтирована в себя.
Если один из путей содержит несколько отношений, а другой путь содержит одно отношение, то такая структура называется триадой. На рис. 4-18 приведен пример триады. В этом случае СЛУЖАЩИЙ связан с ОТДЕЛЕНИЯМИ как прямо, так и косвенно, через ОТДЕЛ. Если утверждение пути состоит в том, что ОТДЕЛЕНИЕ, которому принадлежит СЛУЖАЩИЙ, содержит ОТДЕЛ, которому принадлежит СЛУЖАЩИЙ, то отношение между сущностями ОТДЕЛЕНИЯ и СЛУЖАЩИЙ является избыточным и должно быть удалено. Заметим, что если некоторые, но не все, СЛУЖАЩИЕ могут в действительности принадлежать двум различным отделениям, то должна быть добавлена еще одна сущность; такая, как ВРЕМЕННЫЙ_СЛУЖАЩИЙ, чтобы НОМЕР_ОТДЕЛЕНИЯ удовлетворял правилу необращения в ноль в качестве внешнего ключа сущности СЛУЖАЩИЙ.
Рис. 4-18. Пример триады
Утверждения могут также применяться к отношениям двойственных путей, когда оба пути раскрывают более одного отношения. В приведенном на рис. 4-19 примере между сущностями ОТДЕЛ и ИСПОЛНИТЕЛЬ_ЗАДАНИЯ существуют два пути отношений. Если СЛУЖАЩИЙ может быть приписан только к тому ПРОЕКТУ, которым руководит его ОТДЕЛ, то пути равны. Если СЛУЖАЩИЙ может быть приписан только к тому ПРОЕКТУ, которым руководит не его отдел, то пути не равны. Если СЛУЖАЩИЙ может быть приписан к ПРОЕКТУ независимо от того, руководит его ОТДЕЛ ПРОЕКТОМ или нет, то пути являются неопределенными. Обычно, пути предполагаются неопределенными, если только утверждения точно не определены. Утверждения должны быть добавлены в качестве примечаний к диаграммам стадии 3 и включены в определение сущности-потомка.
Рис. 4-19. Утверждения пути
После идентификации элементов первичного ключа производятся записи в пул атрибутов. Для идентификации распределения и использования атрибутов в модели может применяться матрица сущность/атрибут. Эта матрица обладает следующими свойствами:
Все имена сущностей изображаются с краю.
Все имена атрибутов изображаются наверху.
Использование атрибутов сущностями изображается в соответствующей строке с помощью следующей кодировки: "О" = владелец, "К" = первичный ключ, "I" = наследуемый.
Пример матрицы сущность/атрибут приведен на рис.4-20. Эта матрица является основным средством поддержки целостности модели.
СУЩНОСТИ |
* Имена соответствующих атрибутов приведены в таблице 1 |
||||||||||||||||||||||
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
||
Условия покупки |
1 |
OK |
I |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Покупатель |
2 |
|
OK |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Продавец |
3 |
|
|
OK |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Заказ |
4 |
|
I |
I |
|
|
|
|
|
|
|
|
|
|
|
|
OK |
|
|
|
|
|
|
Оформитель |
6 |
|
|
|
|
|
|
|
|
|
|
|
OK |
|
|
|
|
|
|
|
|
|
|
Деталь |
9 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Пункт заказа |
10 |
IK |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Строка заказа |
12 |
IK |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Администратор |
21 |
|
|
IK |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Поставщик |
22 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Таблица №1
№ |
АТРИБУТЫ |
№ |
АТРИБУТЫ |
1 |
Номер условий покупки |
12 |
Имя оформителя |
2 |
Код покупателя |
13 |
Код отдела |
3 |
Код продавца |
14 |
Послать через … |
4 |
Код заказа |
15 |
Имя покупателя |
5 |
Номер изменения |
16 |
Номер заказа |
6 |
Пункт назначения |
17 |
Дата пункта заказа |
7 |
Имя продавца |
18 |
Код получателя |
8 |
Адрес продавца |
19 |
Код налога |
9 |
Код подтверждения |
20 |
Код дилера |
10 |
Имя подтверждающего лица |
21 |
Номер бланка |
11 |
Код дополнительных копий |
22 |
Условия платежа |
Рис. 4-20. Матрица "Сущности/Атрибуты"