- •Системный анализ и проектирование компьютерных информационных систем
- •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Сравнение существующих методик
- •Объектно-ориентированная методика
1.2.2. Связи
Связь (Relationship) - это поименованная графически изображаемая ассоциация, устанавливаемая между сущностями и представляющая собой абстракцию набора отношений, которые систематически возникают между различными видами предметов в реальном мире. При анализе связей между сущностями могут иметь место бинарные связи (между двумя сущностями или между сущностью и ей же самой - рекурсивная связь), тренарные связи (между тремя сущностями), в общем случае - n-арные связи. В ER-диаграммах связь обозначается либо направленными ребрами с соответствующими надписями (нотация IDEF1), либо ромбом или шестигранником, связанным ребрами с каждой из сущностей (нотация Yourdona).
Среди бинарных связей существуют три фундаментальных вида связи: один к одному (1:1), один ко многим (1:M), многие ко многим (M:N). Эти фундаментальные виды связей относятся к числу безусловных связей и требующих участия каждого экземпляра сущности.
Связь один к одному (1:1) существует, когда один экземпляр одной сущности связан с единственным экземпляром другой сущности.
(Связь R1 - традиционный брак: каждый муж имеет одну жену и каждая жена имеет одного мужа).
Связь один ко многим (1:M) существует, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан только с одним экземпляром первой сущности.
(Связь R2 - владение собаками: каждый владелец может иметь одну или несколько собак, но каждая собака принадлежит только одному владельцу).
Связь многие ко многим (М:N) существует, когда один экземпляр одной сущности связан с одним или более экземпляром другой сущности и каждый экземпляр второй сущности связан с одним или более экземпляром первой сущности.
(Связь R3 - домовладение: каждый владелец может иметь один или несколько домов, и каждый дом является собственностью одного или несколько владельцев).
В условных связях, в отличие от безусловных, могут существовать экземпляры сущности, которые не принимают участия в связи. Если связь условная с обоих сторон, она называется биусловной.
(Связь R4 - биусловная, так как некоторые служащие не работают ни в одном из офисов и некоторые офисы не предназначены ни для одного из служащих).
Суммируя вышесказанное, можно выделить 10 форм для связей, включающих две сущности.
Безусловные формы (участвует каждый экземпляр)
Условные формы (с одной стороны не все экземпляры участвуют в связи)
Б иусловные формы (участвуют не все экземпляры с двух сторон)
Характер связей между сущностями не ограничивается перечисленными - существуют и более сложные связи:
1. Множество связей между одними и теми же сущностями
Пациент, имея одного лечащего врача, может иметь также несколько консультантов; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать нескольких пациентов.
2 . Тренарные связи
Представленная выше диаграмма определяет, что врач может назначить несколько пациентов на несколько анализов; анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами.
3. Связь может быть рекурсивной, если сущность (Мужчина) связывается сам с собой.
Устной трактовкой изображенной диаграммы является следующая:
каждый Мужчина является сыном одного и только одного Мужчины (отца);
каждый Мужчина может являться отцом (а может быть и нет) для одного или более Мужчин.
Замечание. В случае очень большого числа сущностей и связей между ними, применяется менее наглядный, чем язык ER-диаграмм, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и связи представляются предложениями вида:
СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)
СВЯЗЬ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...] (атрибут 1,..., атрибут n),
где S - степень связи (ср. с текстовым способом представления сущностей). ER-диаграммы в этом случае используются для иллюстрации отдельных фрагментов инфологической модели.
Так рассмотренный выше пример множества связей между сущностями может быть описан на ЯИМ следующим образом:
Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)
Пациент (Регистрационный_номер, Номер койки, Фамилия, Имя, Отчество, Адрес, Дата рождения, Пол)
Лечащий_врач [Врач 1, Пациент M] (Номер_врача, Регистрационный_номер)
Консультант [Врач M, Пациент N] (Номер_врача, Регистрационный_номер)
Для выявления связей между сущностями необходимо как минимум определить сами сущности. Но это непростая задача, так как в разных предметных областях один и тот же объект может быть сущностью, атрибутом или связью.
Пример 1. Отдел записей актов гражданского состояния (ЗАГС) имеет дело не со всеми людьми, а только с теми, кто обратился с просьбой о регистрации брака, рождения или смерти. Поэтому в странах, где допускаются лишь традиционные браки, отделы ЗАГСа могут размещать сведения о регистрируемых браках в единственной сущности:
Брак (Номер_свидетельства, Фамилия_мужа, Имя_мужа, Отчество_мужа, Дата_рожд_мужа, Фамилия_жены, ... ,Дата_регистр, Место_регистр, ...),
Пример 2. Теперь рассмотрим ситуацию, когда отдел ЗАГСа расположен в стране, допускающей многоженство. Если для регистрации браков использовать сущность Брак предыдущего примера, то в экземплярах сущности будут дублироваться сведения о мужьях, имеющих несколько жен.
Дублирование можно исключить созданием дополнительной сущности
Мужья (Код_М, Фамилия, Имя, Отчество, Дата рождения, Место рождения),
связанной с несколько измененной сущностью
Брак (Номер свидетельства, Код_М, Фамилия жены, ...,Дата регистрации, ...)
E R-диаграмма связи этих сущностей представлена ниже
Пример 3. Случай, когда какой-либо организации потребовались данные о наличии в ней семейных пар, а для хранения сведений о сотрудниках уже имеется сущность
Сотрудники (Табельный_номер, Фамилия, Имя, ...).
Использование рассмотренной в примере 1 сущности Брак нецелесообразно, так как в сущности Сотрудники уже есть фамилии, имена, отчества супругов. Поэтому достаточно определить связь
Брак [Сотрудник 1, Сотрудник 1] (Таб_номер_мужа, таб_номер_жены, ...),
связывающую между собой определенные экземпляры сущности Сотрудники.
