- •Системный анализ и проектирование компьютерных информационных систем
- •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Сравнение существующих методик
- •Объектно-ориентированная методика
8.5.43.4. Неспецифические отношения
Семантика неспецифических отношений
И отношение родитель-потомок, и отношение категоризации рассматриваются как специфические отношения, поскольку они точно определяют, как экземпляры одной сущности связаны с экземплярами другой. В полностью детализированной IDEF1X-модели все связи между сущностями должны быть выражены как специфические отношения. Однако при первоначальной разработке модели часто полезно устанавливать неспецифическое отношение между двумя сущностями. Эти неспецифические отношения детализируются на более поздних стадиях построения модели. Процедура детализации неспецифических отношений рассматривается в разделе 4.4.1.
Неспецифическое отношение, называемое также отношением многого_ко_многому, - это связь между двумя сущностями, при которой каждый экземпляр первой сущности связан с произвольным (в том числе нулевым) количеством экземпляров второй сущности, а каждый экземпляр второй сущности связан с произвольным (в том числе нулевым) количеством экземпляров первой сущности. Например, если служащий может быть занят во многих проектах, а в проекте может быть занято много служащих, то отношение между сущностями СЛУЖАЩИЙ и ПРОЕКТ является неспецифическим отношением. При дальнейшей разработке модели неспецифическое отношение может быть заменено на специфическое отношение посредством введения третьей сущности, такой, как ИСПОЛНИТЕЛЬ_ПРОЕКТА, являющейся общей сущностью-потомком в определенных отношениях связи с сущностями СЛУЖАЩИЙ и ПРОЕКТ. Новые отношения будут определять, что служащий занят в произвольном количестве (в том числе нулевом) проектов и что проект обладает произвольным (в том числе нулевым) количеством исполнителей. Каждый исполнитель проекта существует только для одного служащего и только для одного проекта. Сущности, введенные для разрешения неспецифического отношения, называются иногда сущностями пересечения или ассоциативными сущностями.
Неспецифическое отношение может быть далее определено с помощью указания мощности на обоих направлениях отношения. Для определения неспецифического отношения может использоваться любая комбинация мощностей. А именно для каждого экземпляра первой сущности может быть следующее количество экземпляров второй сущности:
ноль, один или много,
один или много,
ноль или один,
точное число,
а для каждого экземпляра второй сущности может быть следующее количество экземпляров первой сущности:
ноль, один или много,
один или много,
ноль или один,
точное число.
Заметим, что если на любом из концов отношения имеется мощность "ровно один", то отношение является специфическим.
Синтаксис неспецифических отношений
Неспецифическое отношение изображается линией, соединяющей две связанные сущности и имеющей точки на обоих концах (см. рис.3-6). Мощность может указываться на обоих концах отношения, согласно тому, как показано на рис. 3-2. Рядом с точкой помещается буква Р (positive), указывающая на то, что для каждого экземпляра сущности с другого конца отношения существует один или несколько экземпляров сущности на конце с буквой Р. Рядом с точкой помещается буква Z для указания того, что для любого экземпляра сущности на другом конце отношения имеется ноль или один из экземпляров сущности на конце с буквой Z. Аналогично для указанного значения мощности рядом с точкой может размещаться положительное целое число или диапазон таких чисел. Установкой по умолчанию для мощности является "ноль, один или много".
Неспецифическому отношению дается двойное имя. Имена отношений выражаются грамматическими оборотами глаголов (глагол, дополненный, возможно, наречиями и предлогами), размещаемыми рядом с линией отношения и разделенными косой чертой.
Порядок имен отношений зависит от относительных позиций сущностей. Первое имя выражает отношение либо от левой сущности к правой (если сущности расположены горизонтально), либо от верхней сущности к нижней (если сущности расположены вертикально). Второе имя выражает отношение в противоположном направлении, т.е. в зависимости от ориентации, либо от правой сущности к левой, либо от нижней сущности к верхней. Отношение называется таким образом, чтобы при соединении имен сущности с именами отношения получались предложения. Например, из неспецифического отношения с меткой "имеет/занят" между сущностями ПРОЕКТ и ИСПОЛНИТЕЛЬ могут быть сформулированы утверждения "Проект имеет ноль, один или много служащих" и "Служащий занят ни в одном, в одном, или во многих проектах". (Эта последовательность предполагает, что сущность ПРОЕКТ появляется выше или левее сущности ИСПОЛНИТЕЛЬ.)
Рис. 3-6. Синтаксис неспецифических отношений
Правила неспецифических отношений
Неспецифическое отношение имеет место только между двумя сущностями.
Экземпляр одной из сущностей может быть связан с произвольным (в том числе нулевым) количеством экземпляров другой сущности в зависимости от указанной мощности.
Для полной разработки модели неспецифические отношения должны быть заменены специфическими.
