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