- •Системный анализ и проектирование компьютерных информационных систем
- •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.8Приложение а
Глоссарий IDEF1X
Авторские соглашения (author conventions)
Специальные приемы и стандарты, вырабатываемые разработчиком для улучшения представления и использования модели. Авторские соглашения должны не противоречить никаким методологическим правилам.
Альтернативный ключ (alternate key)
Ключ, не являющийся первичным ключом сущности.
Атрибут (attribute)
Характеристика или элемент данных, описывающие что-либо в сущности. Атрибуту присваивается специфическое имя, обозначающее его смысл (например, цвет волос) и значение (например, коричневый)
Булево ограничение (boolean constraint)
Условие ограничения на экземпляры сущностей-потомков в кратных отношениях с одной и той же родительской сущностью. Оператор "AND" означает, что родительская сущность должна обладать экземплярами сущности-потомка во всех отношениях. Оператор "OR" означает, что родительская сущность должна обладать экземплярами сущности-потомка хотя бы в одном из отношений. Оператор "XOR" означает, что родительская сущность может обладать экземплярами сущности-потомка не более чем в одном из отношений.
Внешний ключ (foreign key)
Атрибуты, появляющиеся в зависимой сущности и являющиеся также первичным ключом другой сущности (сущности-родителя или общей сущности).
Диаграмма сущности (entity diagramm)
Диаграмма, изображающая "основную" сущность и все сущности, прямо связанные с основной сущностью.
Зависимость от идентификатора (identifier dependency)
Ограничение между двумя сущностями, требующее, чтобы внешний ключ в зависимой сущности был ее первичным ключом (или его частью). Зависимость от идентификатора является более сильной формой зависимости существования.
Зависимость существования (existence dependency)
Ограничение между двумя сущностями, указывающее на то, что экземпляры зависимой сущности могут существовать только, если они связаны с экземплярами второй сущности. Зависимость существования - это согласованность на уровне ссылок вместе с ограничением, что внешний ключ не может принимать нулевое значение.
Значение атрибута (attribute value)
Конкретное значение, даваемое атрибуту (например, атрибут: цвет волос; значение атрибута: коричневый).
Имя роли (role name)
Имя, присваиваемое внешнему ключу, появляющемуся более одного раза в сущности.
Имя отношения (relationship name)
Определение в виде предложения, которое отражает значение отношения между двумя сущностями, показанными на той диаграмме, где приводится это имя.
Источник (source)
Члены коллектива разработчиков, ответственные за обеспечение информацией (документами, бланками , процедурами, знанием и т.п.), на основе которых будет начинаться и продолжаться разработка модели.
Сущность-категория (category entity)
Сущность, образцы которой являются подмножеством экземпляров другой сущности, представляющей тот же самый предмет реального мира. Все атрибуты общей сущности относятся также к сущности-категории. Например, "штатный служащий" является сущностью-категорией общей сущности "служащий".
Ключ (key)
Атрибут или комбинация атрибутов сущности, чьи значения однозначно идентифицируют каждый экземпляр сущности.
Комитет рецензирования и одобрения (acceptance review committee)
Элемент функциональной организации процесса создания моделей, ответственный за руководство и арбитражные решения по моделированию, а также за принятие конечного решения по завершенному продукту (т.е. за принятие модели).
Миграция ключа (key migration)
Процесс перемещения первичного ключа родительской или общей сущности в сущность-потомок или сущность-категорию из соответствующего отношения.
Мигрирующий атрибут (migrated attribute)
То же самое, что и наследуемый атрибут.
Мигрирующий ключ (key, migrated)
То же самое, что и внешний ключ.
Менеджер проекта (project manager)
Один из членов коллектива разработчиков, ответственный за административное управление процессом моделирования. В его обязанности входят: укомплектование штата разработчиков, установление области действия и целей, председательствование на заседаниях комитета рецензирования и одобрения и т.п.
Мощность отношении (relationship cardinality)
Количество экземпляров сущности, которые могут быть ассоциированы с любым из других экземпляров в отношении (см. ограничение мощности).
Наследуемый атрибут (inherited attribute)
Атрибут, являющийся первичным ключом (или частью первичного ключа) другой сущности. Он мигрирует из этой сущности через отношение между сущностями.. Называется также мигрирующим атрибутом.
Неспецифическое отношение (nonspecific relationship)
Отношение, в котором нельзя сказать определенно относительно сущности, зависит ли она от другой сущности. Примерами таких отношений являются отношения "много ко многому" и "ноль или один ко многому".
Нормализация (normalization)
Процесс детализации и перегруппировки атрибутов в сущностях в соответствии с нормальными формами, делающий смысл данных более ясным.
Нормальные формы (normal forms)
условия, отражающие степень детализации в идентификации сущностей и определяющие размещение атрибутов в сущностях модели данных. Каждая следующая нормальная форма отражает последовательно более жесткий контроль за отношениями между атрибутами сущности.
Первая нормальная форма (1NF) - каждый атрибут в экземпляре сущности обладает не более чем одним значением.
Вторая нормальная форма (2NF) - 1NF в сочетании с тем, что значение неключевого атрибута определяется всем ключом экземпляра сущности и не определяется только его частью. Сущность в 1NF с несоставным ключом автоматически включается в 2NF.
Третья нормальная форма (3NF) - 2NF в сочетании с тем, что значение неключевого атрибута не определяется значением другого неключевого атрибута. Сущность в 2NF, обладающая только одним неключевым атрибутом, автоматически включается в 3NF.
Четвертая нормальная форма (4NF) - 3 NF в сочетании с тем, что атрибут составного ключа из более чем двух атрибутов связан с одним из остальных двух или более атрибутов этого ключа не более тесно, чем с любым другим атрибутом. Сущность в 3NF с ключом, содержащим менее трех атрибутов, автоматически включается в 4NF.
Пятая нормальная форма (5NF) - 4 NF в сочетании с тем, что атрибуты не могут "отщепляться" в другую сущность без придания им нового смысла. Сущность в 4NF, ключ которой содержит менее трех атрибутов, автоматически включается в 5NF.
Ограничение (constraint)
Утверждение, целью которого является точная спецификация значений данных.
Ограничение мощности (cardinality constraint)
Ограничение числа появлений сущности-потомка, которая может быть связана с родительской сущностью.
Ограничение существования (existence constraint)
Условие, при котором одной сущности не может существовать, если не существует экземпляр другой связанной с ней сущности.
Область (domain)
Множество допустимых значений. Область может определяться типом данных (например, целое число, дата, деньги) и может включать ограничения на значения (например, больше нуля; от 2 до 12; 17 символов; одно из чисел 2, 5, 10, 16). Одна и та же область может быть областью определения для нескольких атрибутов.
Отношения (relationship)
Логическая ассоциация между сущностями.
Принадлежащий атрибут (owned attribute)
Атрибут, который не наследуется. Принадлежность определяется относительно сущности. Атрибут может принадлежать только одной сущности.
Проверка правильности (validation)
Мероприятие, приводящее к консенсусу экспертов, обладающих данными о модели. Модель считается "верной", если большинство экспертов согласилось с тем, что модель правильно и полностью представляет интересующую сферу.
План сбора данных (data collection plan)
План установления объектов (например, функций, отделов, персонала), которые являются источниками материала, используемого для разработки модели.
Первичный ключ (primary key)
Ключ сущности, выбранный для миграции через все отношения, в которых данная сущность участвует в качестве родительской или общей сущности.
Популяция атрибута (attribute population)
То, чем определяется принадлежность классов атрибутов.
Разработчик (автор) (modeler (author))
Один из членов коллектива, разрабатывающего модель, который отвечает за выбор данных, обучение и тренинг, запись модели и управление моделью в процессе ее разработки. Разработчик является экспертом по IDEF1X-методологии моделирования.
Роль атрибута (attribute role)
Описывает функцию, выполняемую атрибутом в описании сущности, включая функции наследуемости (мигрируемости), принадлежности первичного ключа, альтернативного ключа.
Семантика (semantics)
Смысл слов и предложений в языке или в конструкциях модели. Сравните с синтаксисом.
Сложный ключ (compound кеу)
То же самое, что и составной ключ.
Синтаксис (syntax)
Грамматика. Множество правил для формирования осмысленных фраз и предложений из словарных слов. Сравните с семантикой.
Специфическое отношение (specific relationship)
Отношение, в котором существование одной сущности зависит от существования другой.
Составной ключ (кеу, composite)
Ключ, состоящий из более чем одного атрибута.
Стадия 0 (Phase Zero)
Начальные действия при моделировании, во время которых устанавливается контекст, т.е. определение проекта, план сбора данных, авторские соглашения, стандарты и т.п.
Стадия 1 (Phase One)
Второй этап моделирования, во время которого идентифицируются и определяются сущности.
Стадия 2 (Phase Two)
Третий этап моделирования, во время которого идентифицируются и определяются отношения.
Стадия 3 (Phase Three)
Четвертый этап разработки модели, во время которого идентифицируются и определяются ключи.
Стадия 4 (Phase Four)
Пятый этап разработки модели, во время которого идентифицируются и определяются "неключевые" атрибуты.
Схема (schema)
Определение структуры данных.
Концептуальная схема: нейтральное определение интегрированных и совместно используемых данных на предприятии. Представляется семантической моделью данных, согласованной с правилами детализации и находящейся в пятой нормальной форме.
Внешняя схема: описывает перспективы дальнейшего применения совместно используемых данных.
Внутренняя схема: описывает физическое представление совместно используемых данных СУБД.
Сущность (entity)
Совокупность похожих объектов/экземпляров (людей, мест, предметов, событий), которая именуется общим существительным, обладает ключом (однозначно идентифицирующим каждый экземпляр) и имеет один или несколько атрибутов (описывающих каждый экземпляр).
Утверждение (assertion)
Утверждение, устанавливающее условие, которое должно быть истинным.
Функциональная зависимость (functional dependency)
Ограничение между двумя атрибутами, указывающее на то, что значение одного атрибута определяется значением второго.
Цикл IDEF-папки (IDEF kit cycle)
Регулярный обмен частями модели во время ее разработки между разработчиком и читателями/экспертами/рецензентами, целью которого является определение и исправление ошибок, пропусков и искажений.
Экземпляр сущности (entity instance)
Проявление именованной сущности. Может быть специфически идентифицирован значением своего ключа. После определения экземпляра сущности значения всех других атрибутов этого экземпляра являются также известными.
Эксперт - рецензент (комментатор) (expert reviewer, commenter)
Один из членов коллектива разработчиков, специализирующийся на анализе некоторой конкретной функции промышленного предприятия и ответственный за обеспечение критических комментариев относительно разрабатываемой модели.
Элемент ключа (member key)
Атрибут, являющийся частью составного ключа.
FEO
Акроним, означающий "только для экспозиции" (For Exposition Only). Это средство, с помощью которого модель обеспечивается сопроводительной и пояснительной информацией с использованием некоторого набора чертежей, текстов и т.п.
IDEF1X-модель (IDEF1X model)
Графическое представление данных в среде. Отражает основную структуру и отношения данных. Результат применения расширенного языка определений ICAM к моделированию информации/данных (IDEF1X).
