- •Системный анализ и проектирование компьютерных информационных систем
- •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.3.2. Определение отношений
Следующим шагом является определение выявленных отношений. Эти определения включают:
указание зависимостей;
имя отношения;
комментарии к отношениям.
В ходе определения отношений некоторые из них могут отбрасываться, а новые добавляться.
Для установления зависимости отношение между двумя сущностями должно быть проверено в обоих направлениях. Это делается посредством определения мощности на каждом конце отношения. Для определения мощности предположите существование экземпляра одной из сущностей. Затем определите, сколько различных экземпляров второй сущности может быть связано с первой. Повторите анализ, поменяв сущности ролями.
Рассмотрим отношение между сущностями ГРУППА и СТУДЕНТ. Отдельный студент может быть записан в ноль, одну или много ГРУПП. Анализируя в другом направлении, видим, что отдельная группа может иметь ноль, одного или много студентов. Поэтому между сущностями ГРУППА и СТУДЕНТ существует отношение типа "многие ко многим" с мощностью "ноль, один или много" на каждом конце отношения. (Это отношение является неспецифическим, так как на каждом конце отношения не существует мощности "ровно один". Такое неспецифическое отношение позже в процессе моделирования должно каким-то образом разрешиться.)
В качестве другого примера возьмем отношение между сущностями ПОКУПАТЕЛЬ и ЗАКАЗ_НА_ПОКУЛКУ. Отдельный ПОКУПАТЕЛЬ может сделать ноль, один или много ЗАКАЗОВ_НА_ПОКУПКУ. Отдельный ЗАКАЗ_НА_ПОКУПКУ всегда делается одним ПОКУПATEЛEM. Поэтому между сущностями ПОКУПATEЛЬ и ЗАКАЗ_НА_ПОКУПКУ существует отношение типа "один ко многим" с мощностью "один" на конце отношения у сущности ПОКУПАТЕЛЬ и с мощностью "ноль, один или много" на конце ЗАКАЗ_НА_ПОКУПКУ. (Здесь специфическое отношение, поскольку у конца ПОКУПАТЕЛЬ этого отношения имеется мощность "ровно один", т.е. ПОКУПАТЕЛЬ является родительской сущностью для сущности ЗАКАЗ_НА_ПОКУПКУ.)
Установив зависимость отношения, разработчик должен выбрать имя и начать описание отношения. Имя отношения является кратким выражением, обычно глаголом с союзом, присоединяющим вторую упомянутую сущность. Это выражение отражает смысл представляемого отношения. Часто имя отношения состоит из одного глагола, хотя наречия и предлоги также появляются в именах отношений. После выбора имени отношения разработчик должен иметь возможность, читая отношения, получать осмысленное предложение, определяющее или описывающее отношение между двумя сущностями.
При специфической форме отношения всегда имеются сущность-родитель и сущность-потомок; имя отношения интерпретируется сначала со стороны сущности-родителя, а затем от сущности-потомка к сущности-родителю. Если между этими сущностями существует отношение категоризации, то отсюда следует, что обе сущности относятся к одному и тому же объекту реального мира и мощностью на конце сущности-потомка (или сущности-категории) всегда является "ноль или один". Имя отношения в таком случае опускается, поскольку имя "может быть" подразумевается. Например, СЛУЖАЩИЙ может быть ШТАТНЫМ_СЛУЖАЩИМ.
При неспецифической форме отношения существует два имени отношения, по одному для каждой сущности, разделенные знаком "/". В этом случае имена сущностей интерпретируются сверху вниз или слева направо (в зависимости от относительных положений сущностей на диаграмме), а затем в обратном направлении.
Имена отношений должны быть осмысленными. Под их именами должна быть реальная основа. Полное значение, т.е. причина выбора разработчиком данного имени отношения, может быть отражено в определении отношения. Определение отношения - это текст, объясняющий смысл отношения. Правила для определения сущностей применяются и к определениям отношений.
Определения отношений должны быть:
специфическими,
краткими,
осмысленными.
Например, если отношение "один к нулю или к одному" определено между такими двумя сущностями, как ОПЕРАТОР и РАБОЧАЯ_СТАНЦИЯ, то имя отношения может читаться "в настоящий момент назначен для обслуживания". Это отношение может сопровождаться следующим определением:
"Каждый оператор на протяжении каждого рабочего дня может быть назначен для обслуживания нескольких рабочих станций, но это отношение указывает на ту, которую оператор обслуживает в данный момент".
