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