
- •Системный анализ и проектирование компьютерных информационных систем
- •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.3.3Состояние системы и процессы в системе
Введем понятия состояния и процесса в системе. Для этого сначала рассмотрим некоторый выделенный элемент. Что с ним может произойти? Он может быть помещен в систему, исключен из системы, перемещен в ней с одного места да другое. Кроме того, могут быть изменены его связи. Все эти ситуации относятся к изменению структуры системы.
Но возможны преобразования другого рода. Любой элемент обладает рядом свойств, характеристик, которые тоже могут меняться в процессе рассмотрения системы. Вследствие этого могут измениться свойства, характеристики группы элементов, модуля и системы целиком.
Зафиксируем все значения характеристик в системе, важных для целей рассмотрения. Такую ситуацию назовем состоянием системы.
Пусть теперь хотя бы одна такая характеристика изменилась. Это будет новое состояние системы. Аналогично можно рассмотреть третье – и т.д. – состояния, т.е. их набор. Но набор состояний – это еще не процесс. Пусть выбран некоторый физический параметр (чаще всего время) – такой, что различные состояния соответствуют разным его значениям.
Процессом назовем набор состояний системы, соответствующий упорядоченному непрерывному или дискретному изменению параметра, определяющего характеристики (свойства) системы.
Процесс движения (изменения) системы во времени называют динамикой системы. Параметрами процесса могут также выступать температура, давление, другие физические величины. В качестве параметра иногда выступают линейные и угловые координаты (пример: процесс изменения атмосферы с высотой) и даже скорости. Однако более типично отнесение этих величин к характеристикам системы, которые сами зависят, например, от времени.
Процессы в системе могут играть различную роль. В системе автоматизированного проектирования процесс проектирования как движение от технического задания до рабочих чертежей является основной функцией системы. И в целом функционирование сложной системы обычно является процессом. Однако в том же проектировании необходимо учитывать целый ряд внутренних процессов: если что-то двигается, то уравнения движения; если идут химические превращения, то ход реакции. Таким образом, типичен учет процессов в системе как способ получения зависимостей выходов от входов в модулях разных иерархических уровней. При этом неважно, способствует ли в целом данный процесс выполнению системой ее функции или препятствует этому. К последнему случаю относятся, например, процессы износа, старения, а также действия противоположной стороны в игровых ситуациях.
1.3.4Целенаправленные системы и управление
Обсудим теперь понятия, связанные с постановкой перед системой некоторой сформулированной цели. Системы при этом называют целенаправленными, такими будут искусственные системы.
Понятие цели системы определим как задачу получения желаемого выходного воздействия или достижения желаемого состояния системы. Двоякая трактовка цели – через выходное воздействие или через состояние системы – очень удобна в приложениях.
Выбор глобальной цели для системы влечет необходимость:
формулировки локальных целей, стоящих перед элементами системы и группами элементов;
целенаправленного вмешательства в функционирование системы.
Обе операции тесно связаны, хотя с точки зрения практики сначала разбивают глобальную цель на ряд локальных, а потом ищут пути достижения локальных целей.
Набор локальных целей, как правило, сам имеет иерархическое многоуровневое строение и в той или иной степени соответствует общей иерархии в системе. В этом случае понятие «локальные цели» есть собирательный термин для целей всех иерархических уровней; для любой из них можно указать, в какую цель более высокого уровня она входит и (кроме целей самого низшего уровня) на что она дробится сама.
При модульном строении системы локальные цели выступают как требования к выходам модулей. Именно продуманные требования на выходы согласовывают модули так, что состоящая из них система выполняет глобальную цель. Таким образом, локальные цели выступают важным регулятором организации частей и элементов в целенаправленную систему, а их согласование направляет проводимые в системе изменения в единое русло.
Заметим, что согласование обычно является сложной, плохо формализуемой процедурой. При этом конкретная локальная цель может получаться такой, что затруднит выполнение соседней цели, и лишь компромисс между ними даст продвижение к глобальной цели.