- •Системный анализ и проектирование компьютерных информационных систем
- •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.3. Формализация связей
Все связи требуют описания. Описание должно обеспечивать:
идентификатор связи;
формулировку имен связи с точки зрения каждой участвующей сущности;
вид связи (множественность и условность);
формулировку того, как связь была формализована.
Цель формулировки связи состоит в том, чтобы позволить установить связь экземпляра одной сущности с экземпляром другой. Это выполняется размещением вспомогательных атрибутов в соответствующих сущностях на модели. Когда это выполнено, говорят, что связь формализована.
Д ля формализации связи "один к одному" вспомогательные атрибуты могут быть добавлены к любой сущности (но не к обоим).
Для формализации связи "один ко многим" вспомогательные атрибуты должны быть добавлены к сущности на стороне "многого", поскольку размещение такого вспомогательного атрибута на стороне "один" будет нарушать третье правило атрибутов.
Для формализации связи "многие ко многим" создают отдельную ассоциативную сущность, которая содержит ссылки на идентификаторы каждого из участвующих экземпляров.
Подобно любой другой, ассоциативная сущность может иметь дополнительные атрибуты и участвовать в связях с другими сущностями
Несколько замечаний по терминологии. По К.Дейту различают три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей - обозначения.
Стержневая сущность (стержень) - это независимая сущность.
В рассмотренных выше примерах стержни - это Муж (но не Жена),Владелец собаки, владелец дома, ранее Врач, Пациент, Анализ, Брак (из примера 1, п. 1.2.2).
Ассоциативная сущность (ассоциация) - это сущность, формализующая связь вида "многие ко многим" ("... ко многим" и т.д.) между двумя или более сущностями или связь вида "один к одному" между экземплярами сущностей.
В рассмотренных выше примерах ассоциации - это Владение, ранее Консультант, Назначенный анализ, Брак (из примера 3, п 1.2.2 - формализует связи между экземплярами одной сущности).
Ассоциации рассматриваются как полноправные сущности: они могут участвовать в других ассоциациях, как стержневые сущности; могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь (см. выше).
В расширенной ER-модели ассоциация изображается шестигранником, а на языке инфологического моделирования записывается так же, как связь (ассоциация сущности):
АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...] (атрибут1, ...,атрибут n)
Владение [дом, владелец дома] (адрес, квартира, :)
Характеристическая сущность (характеристика) - это сущность, формализующая связь вида "многие к одной" или "одна к одной". Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Xарактеристика Жена характеризует стержневую сущность Муж (характеризуемая сущность), аналогично характеристика Брак из примера 2, п 1.2.2 характеризует стержневую сущность Муж, характеристика Позиции_наряда описывает стержневую сущность Наряды, характеристика Вид_издания (исправленное, дополненное, переработанное, . . .) уточняет стержневую сущность Книга и т.д.
Существование характеристики полностью зависит от характеризуемой сущности: при удалении экземпляра характеризуемой сущности удаляется экземпляр сущности-характеристики (женщины лишаются статуса жен, если умирает их муж).
В расширенной ER-модели характеристика изображается трапецией, на языке инфологического моделирования выглядит:
ХАРАКТЕРИСТИКА(атриб1,...){СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.
Жена (Имя_жены, :) {Муж}
Обозначающая сущность или обозначение - это сущность, формализующая связь вида "многие к одной" или "одна к одной" между двумя сущностями и отличающаяся от характеристики тем, что не зависит от обозначаемой сущности.
В рассмотренных выше примерах обозначающая сущность - это сущность Собака, связанная с обозначаемой сущностью Владелец собаки и имеющая в отличии от характеристики независимое существование (если владелец лишается собаки, конкретный экземпляр собаки продолжает существовать).
Обозначаемые сущности, на которые ссылаются обозначения, как правило, используются для хранения различных "кодификаторов": изучаемых студентами дисциплин, наименований организаций и их отделов, перечней товаров и т.п.
В расширенной ER-модели обозначение изображается параллелепипедом, а на языке инфологического моделирования записывается:
ОБОЗНАЧЕНИЕ (атриб1, атриб2,...)[СПИСОК ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].
Собака(ID_собаки, :) [Владелец собаки]
Обозначения и характеристики не являются полностью независимыми сущностями, поскольку они предполагают наличие некоторой другой сущности, которая будет "обозначаться" или "характеризоваться". Однако они все же представляют собой частные случаи сущности и могут, конечно, иметь свойства, могут участвовать в ассоциациях, обозначениях и иметь свои собственные (более низкого уровня) характеристики. Первичный ключ обозначаемой или характеризуемой сущности, как правило, является внешним ключом характеристики или обозначения (иногда совместно с другими атрибутами образуют первичный ключ).
Первичный ключ ассоциативной сущности строится из первичных ключей сущностей, связи между которыми она формализует.
В заключение рассмотрим пример построения инфологической модели базы данных "Питание", где хранится информация о блюдах, их ежедневном потреблении, продуктах, из которых приготавливаются эти блюда, и поставщиках этих продуктов.
Анализ объектов позволяет выделить:
стержни Блюда, Продукты и Города;
ассоциации Состав (связывает Блюда с Продуктами) и Поставки (связывает Поставщиков с Продуктами);
обозначение Поставщики;
характеристики Рецепты и Расход.
Запись модели на языке инфологического моделирования приведена ниже:
Блюда (D_БЛ, Описание, Вид)
Продукты (ID_ПР, Описание, Калорийность)
Поставщики (ID_ПОСТ, Поставщик, Код_города) [Город]
Состав [Блюда M, Продукты N](ID_БЛ, ID_ПР, Вес)
Поставки [Поставщики M, Продукты N] (ID_ПОСТ, ID_ПР, Дата поставки, Цена, Вес)
Города (Код, Город, Страна)
Рецепты (ID_рецепта, ID_БЛ, Рецепт) {Блюда}
Расход (ID_БЛ, Дата,Число порций) {Блюда}
Расширенная инфологическая модель ER-модель:
