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