Проектирование информационных систем. 1. Диаграммы потоков данных

1. Диаграммы потоков данных.

Процесс – частично упорядоченная последовательность действий связанных с обработкой, получением или хранением информации.

Поток данных – означает какую-либо информацию которая либо поступает в процесс либо исходит.

Внешняя сущность – соответствует объекту внешнему по отношению к системе с которой она взаимодействует по средствам информационных потоков.

1. Моделируемая система рассматривается, как совокупность взаимодействующих процессов обработки информации.

2. Принцип абстрагирования, заключается в том, что бы не рассматривать несущественные детали.

3. Принцип черного ящика. Всякий процесс рассматривается как черный ящик, то есть определение его входов и выходов.

4. Разделяй и властвуй всякий сложный процесс должен быть разбит на несколько простых для лучшего понимания.

5. Принцип иерархии – все процессы в системе объединены в иерархическую структуру.

Правила построения DFD.

1. Сначала строится контекстная диаграмма - моделирующая систему наиболее общим образом. Она отражает интерфейс системы с внешним миром, а именно потоки между системой и внешними сущностями, с которыми она должна быть связана. Она идентифицирует эти внешние сущности, а так же, как правило, единственный процесс, отражающий главную цель или природу системы на сколько это возможно.

2. Проектируемая система изображается как один глобальный процесс связанный с внешними сущностями потоками данных контекстная диаграмма позволяет четко определить границы системы.

Далее строится диаграмма 1го уровня на которой система декомпозируется. Все потоки данных которые входили и выходили должны присутствовать на диаграмме 1го уровня и связываться с процессами которые их обрабатывают и формируют.

3. Процессы 1го уровня декомпозируют процессами низкого более уровня до тех пор пока не будут получены элементарные процессы (примерно 20строк программного кода).

4. Декомпозиции подлежат все процессы кроме элементарных которые специфицируются.

5. Декомпозиция процесса производится путем построения диаграммы более низкого уровня, на которой представлены процессы совокупно более сложный процесс и все входящие и выходящие потоки, кроме того на ней могут присутствовать хранилища данных и внутренние потоки данных которые связаны между собой, процессы или процессы с хранилищами.

6. На каждой диаграмме должно присутствовать от 3 до 7 процессов.

7. Процессы формируются иерархически.

8. Потоки данных на диаграмме не должны пересекаться.

9. Если поток данных разветвляется на несколько более элементарных потоков, то каждый из них должен быть поименован.

10. Если несколько потоков данных сходятся в один более глобальный, то он должен быть поименован.

11. Процессы на диаграмме по возможности должны располагаться каскадом.

32. Структурные методологии проектирования информационных систем

Современные структурные методологии анализа и проектирования

классифицируются по следующим признакам:

· по отношению к школам - Software Engineering (SE) и Information

· Engineering (IE);

· по порядку построения модели - процедурно-ориентированные,

· ориентированные на данные и информационно-ориентированные;

· по типу целевых систем - для систем реального времени (СРВ) и для

· информационных систем (ИС).

SE является нисходящим поэтапным подходом к разработке ПО, начинающейся с общего взгляда на его функционирование. Затем производится декомпозиция на подфункции, и процесс повторяется для подфункций до тех пор, пока они не станут достаточно малы для их реализации кодированием. В результате получается иерархическая, структурированная, модульная программа. SE является универсальной дисциплиной разработки ПО, успешно применяющейся как при разработке систем реального времени, так и при разработке информационных систем. IЕ - более новая дисциплина. С одной стороны, она имеет более широкую область применения, чем SE: IЕ является дисциплиной построения систем вообще, а не только систем ПО, и включает

этапы более высокого уровня (например, стратегическое планирование), однако на этапе проектирования систем ПО эти дисциплины аналогичны. С другой стороны, IЕ - более узкая дисциплина, чем SE, т.к. IЕ используется только для построения информационных систем, а SE - для всех типов систем.

Разработка ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонентов по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными - структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход, как часть IE-дисциплины, отличается от подхода, ориентированного на данные, тем, что позволяет работать с иерархическими структурами данных.

Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними событиями; реагирование на эти события во времени - основная и первоочередная функция таких систем. Главные отличия информационных систем от систем реального времени приведены в таблице, средствами поддержки этих особенностей и различаются соответствующие структурные методологии.

Информационные системы Системы реального времени

Управляемы данными Управляемы событиями

Сложные структуры данных Простые структуры данных

Большой объем входных данных Малое количество входных данных

Интенсивный ввод/вывод Интенсивные вычисления

Машинная независимость Машинная зависимость

Во всех перечисленных методологиях проектирования информационных систем в различных комбинациях используются техники структурных диаграмм. Необходимо отметить, что для проектирования систем реального времени используются специальные типы структурных диаграмм: диаграммы потоков управления, диаграммы переходов состояний, контекстные графы, матрицы состояний/событий, таблицы решений и др. Однако многие из них являются вариациями структурных диаграмм для проектирования информационных систем. Более того, известные методологии проектирования систем реального времени (в частности, методологии Хатли и Уорда-Меллора) базируются на перечисленных методологиях проектирования информационных систем, расширяя их соответствующими диаграммными техниками.

2. Критерии качества проекта. Связность.

Связность - это мера прочности соединения функциональных и информационных объектов внутри одного модуля. Размещение сильно связанных объектов в одном и том же модуле уменьшает межмодульные взаимосвязи и взаимовлияния. Специалисты выделяют следующие уровни связности: функциональная, последовательная, информационная, процедурная, временная, логическая и случайная. Рассмотрим эти уровни более подробно.

Функционально связный модуль содержит объекты, предназначенные для выполнения одной и только задачи, например: Расчет заработанной платы, Считывание данных кредитной карты. Каждый из этих модулей имеет одну четко определенную цель, при его вызове выполняется только одна задача (при этом она выполняется полностью без исполнения любого другого дополнительного действия).

Модуль имеет последовательную связность, если его объекты охватывают подзадачи, для которых выходные данные одной из подзадач служат входными данными для следующей, например: Открыть файл - Прочитать запись - Закрыть файл.

Информационно связный модуль содержит объекты, использующие одни и те же входные или выходные данные. Предположим, что мы хотим выяснить некоторые сведения о книге, зная ее ISBN: название книги, ее автора и цену. Эти три подзадачи являются связанными потому, что все они работают с одним и тем же входным информационным объектом - ISBN, который и делает этот модуль информационно связным.

Процедурно связный модуль является модулем, объекты которого включены в различные (и возможно несвязные) подзадачи, в которых управление переходит от каждой подзадачи к последующей (отметим, что в последовательно связном модуле данные, а не управление, переходили от одной подзадачи к последующей). В качестве примера приведем следующий перечень шагов в некотором процедурно связном модуле:

1. Сделать зарядку

2. Принять душ

3. Сварить кофе

4. Одеться

5. Отправиться на службу

Отправиться на службу - это последний шаг, внесенный в список этого "модуля". Но, например, действия Прочитать газету или Сходить в магазин могут быть в равной степени пригодными кандидатами для шага 5, поскольку шаги в этом списке связаны только тем, что они происходят в данном порядке в течение конкретного дня.

Временно связным является модуль, объекты которого включены в подзадачи, связанные временем исполнения. Представим себе картину позднего вечера:

1. Почистить зубы

2. Выключить телевизор

3. Выгнать кота в коридор

Эти действия никак не связаны друг с другом, за исключением конкретного времени их выполнения. Все они - часть установившегося режима в конце дня.

Модулем с логической связностью является модуль, объекты которого содействуют решению одной общей подзадачи, для которой эти объекты отобраны во внешнем по отношению к модулю мире. Например, собираясь в поездку, можно составить себе следующий список:

Поехать автомобилем

Поехать поездом

Поплыть на корабле

Полететь на самолете

Что связывает эти действия? Все они являются способами перемещения. Но решающий момент заключается в том, что для любой поездки человек должен выбрать конкретный способ перемещения, т.к. маловероятно, что кто-нибудь будет использовать их все для отдельной поездки.

Таким образом логически связный модуль содержит некоторое количество подзадач (действий) одного и того же общего вида. Для того, чтобы его использовать, необходимо выбрать именно ту часть (части), которые требуются. Эти различные подзадачи должны обладать одним и только одним интерфейсом с внешним миром. При этом семантика каждого параметра зависит от используемой подзадачи.

Случайно связным является модуль, объекты которого соответствуют подзадачам, незначительно связанным друг с другом:

1. Ремонтировать автомобиль

2. Пить пиво

3. Смотреть фильм

Случайно связный модуль подобен логически связному модулю, его объекты не связаны ни потоками данных, ни потоками управления. Однако, подзадачи в логически связном модуле являются по крайней мере одной категории; для случайно связного модуля даже это неверно.

Таким образом, связность является мерой функциональной зависимости объектов (исполняемых операторов, областей данных и т.д.) внутри одного модуля. В хорошем проекте связность каждого модуля является высокой (последовательность введенных выше определений уровней связности соответствует направлению от лучшей связности к худшей). Вместе со сцеплением, связность является одним из лучших критериев оценки качества проекта.

3. Критерии качества проекта. Сцепления.

Одним из способов оценки качества проекта является анализ сцепления модулей. Сцепление является мерой взаимозависимости модулей. В хорошем проекте сцепления должны быть минимизированы, т.е. модули должны быть слабозависимыми (независимыми) настолько, насколько это возможно. Слабое сцепление между модулями служит признаком хорошо спроектированной системы по следующим причинам:

уменьшение количества соединений между двумя модулями приводит к уменьшению вероятности появления “волнового эффекта” (ошибка в одном модуле влияет на работу других модулей);

минимизация риска появления “эффекта ряби” (внесение изменений, например, при исправлении ошибки, приводит к появлению новых ошибок), т.к. изменение влияет на минимальное количество модулей;

при сопровождении модуля отсутствие необходимости беспокоиться о внутренних деталях других модулей;

упрощение системы для понимания, насколько это возможно.

Слабое сцепление может быть достигнуто за счет комбинирования трех следующих способов действий:

удаления необязательных связей;

уменьшения количества необходимых связей;

упрощением необходимых связей.

Специалистами предлагаются следующие практические рекомендации для ослабления сцепления модулей:

Создавайте минимальные по количеству параметров межмодульные связи.

Создавайте прямые (а не косвенные) межмодульные связи, поскольку интерфейс между двумя модулями наиболее понятен (и, следовательно, менее сложен), если человек может постигнуть его сразу без предварительной ссылки к некоторым другим информационным объектам.

Создавайте локализованные связи (например, значения списка параметров вычисляйте непосредственно перед вызовом модуля).

Создавайте явные связи. Красноречивым примером неявной связи является взаимодействие модуля А с модулем В за счет модификации области данных из В: для того, чтобы человек, сопровождающий модуль В понял, за счет чего модифицируется эта область данных, он будет должен проделать огромную работу.

Создавайте гибкие связи для облегчения модификаций.

На практике существуют три основных типа сцепления, использумых системными проектировщиками для связи модулей: нормальное сцепление, сцепление по общей области и сцепление по содержимому. С позиций структурного проектирования эти типы являются, соответственно, приемлемым, неприемлемым и запрещенным.

Два модуля А и В являются нормально сцепленными, если А вызывает В, В возвращает управление А, вся информация, передаваемая между А и В, представляется значениями параметров при вызове.

Существует три типа нормального сцепления: сцепление по данным, сцепление по образцу, сцепление по управлению. На практике наиболее часто используемым типом сцепления является сцепление по данным (data coupling). Два модуля сцеплены по данным, если они взаимодействуют через передачу параметров и при этом каждый параметр является элементарным информационным объектом. В случае небольшого количества передаваемых параметров сцепление по данным обладает наилучшими характеристиками.

Два модуля сцеплены по образцу (stamp coupling), если один посылает другому составной информационный объект, т.е. объект, имеющий внутреннюю структуру. Примером составного объекта может быть объект Данные о клиенте, включающий в себе поля: Название организации, Почтовый адрес, Номер счета и т.п.

Два модуля сцеплены по управлению (control coupling), если один посылает другому информационный объект - флаг, предназначенный для управления его внутренней логикой.

Два модуля являются сцепленными по содержимому (content coupling), если один ссылается внутрь другого любым способом, например, если один модуль передает управление или выполняет переход в другой модуль, если один модуль ссылается (или изменяет) значения информационных объектов в другом модуле или если один модуль изменяет код другого модуля. Такое сцепление делает абсурдной концепцию модулей как черных ящиков, поскольку оно вынуждает один модуль знать о точном содержании и реализации другого модуля. Вообще говоря, только ассемблер позволяет проектировщикам применять данный вид сцепления.

Необходимо отметить, что любые два модуля могут быть сцеплены более чем одним способом. В этом случае тип их сцепления определяется худшим типом сцепления. Например, если два модуля сцеплены по образцу и общей области, то они характеризуются как сцепленные по общей области. Они по-прежнему сцеплены по образцу, но это сцепление выше, чем сцепление по общей области.

4. Рациональный унифицированный процесс.

РУП – предназначен для разработки программных систем средней и высокой сложности отличительная особенность этого процесса:

1. Оперативность

2. Масштабированность

3. Упор на анализ и проектирование

4. Упор на модели, а не на бумажные документы

5. Объектно-ориентированный подход

6. Возможность удаленной группы разработчиков

РУП – последовательность шагов направленных на внедрение программного продукта на предприятии потребителя и соблюдение ограничений по стоимости и времени.

Процесс реализации проекта делится на итерации в результате итераций должен появиться программный продукт приготовленный для коммерческого использования частично или полностью реализующий требования заказчика.

1. Начало

2. Исследования

3. Производство

4. Внедрение

На каждой из фаз выполняются определенные работы в результате этих работ реализуются артефакты.

Артефакт – некий продукт имеющий ценность для заказчика или для проектной группы.

Например: Документ, договор, анкета.

1. В фазе Начало осуществляются следующие работы

Оценка стоимости и времени выполнения итераций

Определение состава группы проекта

Глобальное планирование итерации

Диаграмма Ганта

Выработка критерия исследования

2. Фаза Исследование.

Определяется архитектура, П.О.

Определяется взаимодействие классов при решении задач (диаграмма взаимодействия)

Определение поведения классов (диаграмма состояния)

Определение алгоритмов и методов (диаграмма активности, состояния)

Выбор средств разработки и тестирования

3. Производство

Разбиение функций помодульно (диаграмма компонентов)

Генерация кода (программные модули)

Разработка сценариев тестирования.

Проведение тестирования

Формировка требований к программным средствам

4. Обучение пользователей

Разработка инструкций для пользования

Подготовка рабочих мест

Установка и β-тестирование (бета-тестирование) программ

Исправление и дополнение функций реализованных программ

Проверка осуществления критериев внедрения.

5. Структурные методологии проектирования информационных систем.

Идея структурного подхожда заключается в том, чтобы рассмотреть большую сложную систему как иерархию черных ящиков.Структурный анализ заключается в том, что изучение системы начинается с общего обзора, а затем проводится детализация, в результате которой система представляется как иерархическая структура, расширяющаяся и углубляющаяся в процессе ее изучения. Структурный подход предназначен для решения следующих проблем анализа:

1. Заказчик не обладает специальными знаниями, что бы четко сформулировать свои требования к системе и понимать что она может, а что нет.
2. На аналитика сваливается чрезвыйчано большой объем информации о предметной области, в которой ему трудноразобраться.
3. Спецификация результатов анализа либо непонятна Заказчикау, либо не имеет практической ценности для программиста.

Под черным ящиком понимается некоторая часть системы или ее функции о внутреннем строении которой ничего неизвестно. Известны лишь входы, выходы, а также ее назначение(имя функции). Разбиение системы на черные ящикик производится по следующим принципам:

1. Каждый ящик выполняет единственную функцию в системе, причем никакой другой ящик эту функцию не выполняет.
2. Фукнция черного ящика должна быть обозначена четко и ясно, вне зависимости от того насколько сложно она выполнена.
3. Черные ящики должны как можно меньше зависеть друг от друга.
4. Связи между черными ящиками должны быть как можно больше простыми.

Принципы построения иерархий черных ящиков.

1. Каждый черный ящик стоящий по иерархии ниже другого должен быть подфункцией функции выполняемой другим ящиком.
2. Каждый функцию можно разюивать на 3 – 7 подфункций.
3. Все подфункции одной функции должны соответствовать выполнению именно этой функции.
4. иерархия строится до тех пор, пока черные ящики на ее нижнем уровне не будут соответстовать элементарным функциям.

Структурный анализ выполняется на основе структурного подхода, который в свою очередь базируется на определенных принципах.

Главными счмтаются два из них:

1.Разделяй и властвуй – суть его заключается втом, что сложные системы или проблемы разбиваются на несколько менее сложных подсистем или проблем.

2.Принципы иерархичесокй организации.

Остальные принципы которым также необходдимо следовать:

1. Принцип абстрагирования – внимание уделяется только существенным деталям, все несущественные обтрасываются.
2. Принцип формализации – на каждом этапе применяется строгий методологический подход к решению проблем.
3. Принцип упрощения – раасматривается только та информация, которая необходима для решения текущей задачи, все остальное скрывается.
4. Принцип концептуальной общности – на всех этапах применяется строго один подход.
5. Принцип логической независимости – система должна быть смоделирована логически и логическая модель не должна зависеть от физических моделей.
6. Данные должны структурироваться независимо от методов их обработки.
7. Принцип свободного доступа пользователя – пользователь должен иметь возможность получать информацию из базы данных без посредничества программиста.
8. Принцип полноты и не противоречивости – присутствие элементов модели должно быть обосновано, т.е. должен осуществляться контроль лишних элементов и все элементы должны быть согласованы между собой.

Средсвто структурного анализа.

Для документирования результатов анализа рекомендуетс я использовать следующие средства:

1. Для описания системы в целом – диаграмма потоков данных (DFD), либо диаграммы в нотации IDEF1.
2. Для описания данных диаграммы сущность – связь ERD.
3. Для спецификации процессов IDEF3.
4. Для описания аспектов реального времени диаграммы состояний STD.

6. Этапы проектирования информационных систем.

Информационные системы (И.С.) – комплекс программно-аппаратных и организационных средств предназначенных для сбора, накопления и обработки практически полезной информации.

Информации – продукт получаемый в результате обработки объективных данных субъективными методами.

1. Предварительная оценка проекта – определение цели проекта, составление группы проектов, предварительная стоимостная оценка проекта, временные рамки проекта с примерной разбивкой по этапам, определяется комплекс организационных мер необходимых для начала проекта.

2. Обследование деятельности предприятия или полразделения.

выявить цель функционирования предприятия

определить основные цели деятельности

определить вспомогательные направления деятельности

определение оригинальности и топологической структуры предприятия

распределение функций по подразделениям

выявление принятых технологий, составление и обработки документаций

определение состава программных и компьютерных средств имеющихся на предприятии.

Обследование проводиться для средних предприятий не более 3х месяцев.

3. Построение моделей деятельности предприятий. Строится 2 модели.

«Как есть» - снимок текущего положения дел на предприятии

«Как должно быть»

Должны быть выработаны организационные меры по иерархии от текущего положения дел к желаемому. Должен быть разработан план реинженеринга предприятия.

4. Разработка системного проекта

Должны быть сформированы все функциональные требования к системе

Формируются требования к её техническим характеристикам

Определена архитектура системы

Системный проект предоставляет собой законченный продукт (в течении 1 месяца)

5. Разработка технического проекта

Описываются алгоритмы выполнения всех функций

Разрабатывается перечень автоматизированных рабочих мест и их функций

Детально определяется архитектура АРМов и серверных приложений

Определяется состав и аппаратно-технические требования к аппаратным средствам.

6. Подготовка предложений по автоматизации

Принятие решения об разработке собственной И.С., либо о внедрении существующей.

Разработка приложения по этапам автоматизации предприятия

Четкие критерии оценки успешности проекта.

7. Язык UML. Диаграммы взаимодействия.

Диаграммы последовательностей и кооперации (и те, и другие называются диаграммами взаимодействий) относятся к числу пяти видов диаграмм, применяемых в UML для моделирования динамических аспектов системы (остальные три вида- диаграммы деятельности, состояния и прецедентов). На диаграммах взаимодействий показывают связи, включающие множество объектов и отношений между ними" в том числе сообщения, которыми объекты обмениваются. При этом диаграмма последовательностей акцентирует внимание на временной упорядоченности сообщений, а диаграмма кооперации - на структурной организации посылающих и принимающих сообщения объектов.

Диаграммы взаимодействий используются для моделирования динамических аспектов системы. Сюда входит моделирование конкретных и прототипических экземпляров классов, интерфейсов, компонентов и узлов, а также сообщений, которыми они обмениваются, - и все это в контексте сценария, иллюстрирующего данное поведение. Диаграммы взаимодействий могут существовать автономно и служить для визуализации, специфицирования, конструирования и документирования динамики конкретного сообщества объектов, а могут использоваться для моделирования отдельного потока управления в составе прецедента.

Диаграммы взаимодействий важны не только для моделирования динамических аспектов системы, но и для создания исполняемых систем посредством прямого и обратного проектирования.

Диаграмма взаимодействий (Interaction diagram) описывает взаимодействия, состоящие из множества объектов и отношений между ними, включая сообщения, которыми они обмениваются. Диаграммой последовательностей (Sequence diagram) называется диаграмма взаимодействий, акцентирующая внимание на временной упорядоченности сообщений. Графически такая диаграмма представляет собой таблицу, объекты в которой располагаются вдоль оси X, а сообщения в порядке возрастания времени - вдоль оси Y. Диаграммой кооперации (Collaboration diagram) называется диаграмма взаимодействий, основное внимание в которой уделяется структурной организации объектов, принимающих и отправляющих сообщения. Графически такая диаграмма представляет собой граф из вершин и ребер.

Общие свойства

Поскольку диаграмма взаимодействий - это частный случай диаграммы, ей присущи общие для всех диаграмм свойства: имя и графическое содержание, являющееся одной из проекций модели. От других диаграмм ее отличает содержание.

Содержание

Как правило, диаграммы взаимодействий содержат:

· объекты;

· связи;

· сообщения.

Диаграммы взаимодействий являются, по сути, проекцией участвующих во взаимодействии элементов. К этим диаграммам применима семантика контекста взаимодействий, объектов, ролей, связей, сообщений и последовательностей. Подобно прочим диаграммам, диаграммы взаимодействий могут содержать также примечания и ограничения.

8. Язык UML. Диаграммы состояний.

Диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее — одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне.

Главное предназначение этой диаграммы — описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий.

Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Понятие автомата в контексте UML обладает довольно специфической семантикой, основанной на теории автоматов. Вершинами этого графа являются состояния и некоторые другие типы элементов автомата (псевдосостояния), которые изображаются соответствующими графическими символами. Дуги графа служат для обозначения переходов из состояния в состояние. Диаграммы состояний могут быть вложены друг в друга, образуя вложенные диаграммы более детального представления отдельных элементов модели.

Автомат в языке UML представляет собой некоторый формализм для моделирования поведения элементов модели и системы в целом. В метамодели UML автомат является пакетом, в котором определено множество понятий, необходимых для представления поведения моделируемой сущности в виде дискретного пространства с конечным числом состояний и переходов. С другой стороны, автомат описывает поведение отдельного объекта в форме последовательности состояний, которые охватывают все этапы его жизненного цикла, начиная от создания объекта и заканчивая его уничтожением. Каждая диаграмма состояний представляет некоторый автомат.

Основными понятиями, входящими в формализм автомата, являются состояние и переход. Главное различие между ними заключается в том, что длительность нахождения системы в отдельном состоянии существенно превышает время, которое затрачивается на переход из одного состояния в другое. Предполагается, что в пределе время перехода из одного состояния в другое равно нулю (если дополнительно ничего не сказано).

В общем случае автомат представляет динамические аспекты моделируемой системы в виде ориентированного графа, вершины которого соответствуют состояниям, а дуги — переходам. При этом поведение моделируется как последовательное перемещение по графу состояний от вершины к вершине по связывающим их дугам с учетом их ориентации. Для графа состояний системы можно ввести в рассмотрение специальные свойства.

9. Язык UML. Диаграммы сценариев.

В языке UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя.

Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду два аспекта взаимодействия. Во-первых, взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни (рис. 2.21). Внутри прямоугольника записываются имя объекта и имя класса, разделенные двоеточием. При этом вся запись подчеркивается, что является признаком объекта, который, как известно, представляет собой экземпляр класса. Второе измерение диаграммы последовательности — вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа "раньше-позже".

Рис. 2.21. Пример диаграммы последовательности.

Линия жизни объекта изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней.

Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены (разрушены), чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается в момент его уничтожения. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы "X".

В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления. Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона — окончание фокуса управления (окончание активности). Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни, если на всем ее протяжении он является активным.

Цель взаимодействия в контексте языка UML заключается в том, чтобы описать коммуникацию между множеством взаимодействующих объектов. Каждое взаимодействие описывается совокупностью сообщений, которыми участвующие в нем объекты обмениваются между собой. В этом смысле сообщение представляет собой законченный фрагмент информации, который отправляется одним объектом другому. При этом прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено.

Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают от принимающего объекта выполнения ожидаемых действий. Сообщения могут инициировать выполнение операций объектом соответствующего класса, а параметры этих операций передаются вместе с сообщением. На диаграмме последовательности все сообщения упорядочены по времени своего возникновения в моделируемой системе. В таком контексте каждое сообщение имеет направление от объекта, который инициирует и отправляет сообщение, к объекту, который его получает. Иногда отправителя сообщения называют клиентом, а получателя — сервером.

В языке UML могут встречаться несколько разновидностей сообщений, каждое из которых имеет свое графическое изображение (рис. 2.22).

Рис. 2.22. Графическое изображение различных видов сообщений между объектами на диаграмме последовательности.

Виды сообщений:

­ simple. Простое сообщение в одно тредовом приложении (рис 2.22, а);

­ return. Сообщение возврата из процедуры (рис 2.22, б);

­ synchronous. Клиент выполняет действия до момента посылки сообщения. Клиент ждет пока сервер примет и обработает сообщение не выполняя ни каких действия. Как только сервер вернет управление из сообщения клиент продолжает свою работу (рис 2.22, в);

­ asynchronous. Клиент посылает сообщение серверу и не ожидая окончания обработки сообщения сервером продолжает свой выполнение (рис 2.22, г);

­ procedure call. Вложенная последовательность действий завершается прежде чем выполнение продолжится на более высоком уровне. Данный тип сообщения применим как для вызовов процедур так и для взаимодействия объектов при котором клиент дожидается завершения работы всей последовательности действия сервера (рис 2.22, д);

­ balking. Клиент посылает сообщение только если сервер готов принять сообщение. Иначе сообщение не посылается (рис 2.22, е);

­ timeout. Клиент “отзывает” сообщение если сервер не может обработать сообщение в течении определенного времени (рис 2.22, ж).

Информационная безопасность и зашита информации.

1. Идентификация параметров персонального компьютера.

Идентификация параметров IBM-совместимых персональных компьютеров является определенной проблемой и обусловлена тем, что у них отсутствуют отчетливо выраженные уникальные характеристики, позволяющие однозначно отличить один компьютер от другого. Нечто подобное встречается у компьютеров фирмы AMI, которая проставляет заводской номер набора микросхем, на материнской плате (chipset). но для них на сегодняшний момент неизвестна точная процедура его определения.

Исходя из сложившейся ситуации для идентификации IВМ-
совместимых компьютеров обычно предлагается либо дооснастить их
какими-либо дополнительными устройствами типа электронного ключа,
либо выделить характеристики, которые можно посчитать за уникальные.
Дооснащение компьютеров дополнительным оборудованием приводит к
ситуации, когда объектом распространения выступает как бы не сама программа, а некоторое физическое устройство, придающее распространяемой программе вторичную роль. Наиболее очевидным недостатком такого подхода является увеличение конечной цены продажного комплекта. По­ этому подход оправдан в случае, когда стоимость элементов защиты со­ставляет единицы процентов от стоимости защищаемого программного продукта.

Более дешевым, но и менее надежным способом является идентификация компьютера по его характеристикам, которые можно подразде­лить на динамические и статические. Динамические характеристики - это скорость вращения винчестера, точная тактовая частота микропроцессора и т.д. Основным недостатком динамических характеристик является их сильная зависимость от температуры, влажности, напряжения и частоты питающей сети, степени износа отдельных частей компьютера и т.д. На­пример, известная система защиты CERBERUS в качестве одного из па­раметров среды использовала точную частоту микропроцессора, Вслед­ствие этого на некоторых типах компьютеров после их достаточного про­грева защита запрещала запуск программ, хотя несанкционированное копирование отсутствовало.

2. Классификация методов анализа безопасности программного обеспечения.

Архивирование: резервирование таблицы FAT при каждой перезагрузке компьютера, ежедневное ведение архивов измененных файлов. Это самый важный, основной метод защиты от вирусов. Остальные методы не могут заменить ежедневное архивирование, хотя и повышают общий уровень защиты.

Сегментация: использование Advanced Disk Manager (ADM) или Disk Manager для разбиения диска на "не­потопляемые отсеки" - зоны с установленным атрибутом READ ONLY. Ис­пользование для хранения ценной информации разделов, отличных от C или D. Хранение исполняемых программ и баз данных в разных разделах винче­стера. Свертка неиспользуемых каталогов в архивы, что позволяет также сэкономить значительное место на винчестере.

Ревизия: ежедневный контроль целостности исполняемых файлов и си­стемных блоков с помощью Adinf или аналогичного ревизора.

Входной контроль: проверка поступающих программ батареей детекторов и фагов, проверка соответствия длины и контрольных сумм в сертификате длинам и контрольным суммам полученных программ.

Профилактика: систематическое использование Vformat для разметки дискет; профилактическое вакцинирование поступающих дискет; работа на "чужих" компьютерах с дискетами, защищенными от записи, минимизация периодов доступности дискеты для записи, разделе­ние "общих" дискет между конкретными пользователями и разделение пере­даваемых и поступающих дискет, раздельное хранение вновь полученных программ и эксплуатировавшихся ранее, хранение неиспользуемых программ на "винчестере" в архивированном виде.

Карантин: каждая новая программа, полученная без контрольных сумм, должна проходить карантин, т.е. проверяться на известные виды компью­терных вирусов, и в течение определенного времени за ней должно быть организовано наблюдение. Использование специального раздела для хранения вновь поступивших программ в сочетании со специальным именем пользователя в ADM (Advanced Disk Manager), причем для этого пользователя все осталь­ные разделы должны быть либо невидимы, либо иметь статус READ ONLY.

Фильтрация: применение программ-сторожей для обнаружения попыток вы­полнить несанкционированные действия. Использование атрибута READ ONLY для всех исполняемых файлов в сочетании с соответствующим резидентным "усилителем" этого атрибута.

Вакцинирование: специальная обработка файлов, дисков, каталогов, за­пуск резидентных программ-вакцин, имитирующих сочетание условий, кото­рые используются данным типом вируса для определения, заражена уже программа, диск, компьютер или нет, т.е. обманывающих вирус.

Автоконтроль целостности: применение резидентных программ подсчета контрольных сумм перед запуском программ, использование в программе специальных алгоритмов, позволяющих после запуска программы опреде­лить, были внесены изменения в файл, из которого загружена программа, или нет.

Терапия: дезактивация конкретного вируса в зараженных программах специальной программой-антибиотиком или восстановление первоначального состояния программ путем "выкусывания" всех экземпляров вируса из каж­дого зараженного файла или диска с помощью программы-фага.

Методы анализа безопасности программ делятся на две категории: контрольно-испытательные и логико-аналитические. На данное время любой из этих методов имеет существенный недостаток – исследование безопасности проводится лишь относительно некоторого подмножества разрушающих программных средств (РПС) - вирусы, программные закладки и т.д. С практической точки зрения – с точки зрения обеспечения безопасности конкретной вычислительной системы контрольно-испытательные методы обладают рядом преимуществ, связанными с их привязкой к конкретной вычислительной системе и программе, а также с их надежностью в смысле отсутствия ошибок, заключающихся в объявлении безопасной программы, на самом деле являющейся РПС. Однако затраты, необходимые для организации процесса тестирования, являются преградой для их применения, за исключением тех вычислительных систем, безопасность которых особенно критична.

3. Классы защищенности автоматизированных систем согласно требованиям Гостехкомиссии РФ.

Для АС установлено девять классов защищенности. К числу определяющих признаков группировки АС в классы, относятся: - наличие в АС информации различного уровня конфиденци­альности;

- уровень полномочий субъекта доступа АС на доступ к конфиденциальной информации;

- режим обработки данных в AC - коллективный или инди­видуальный.

Классы подразделяются на три группы, отличающиеся осо­бенностями обработки информации. В пределах каждой группы соблюдается иерархия требований по защите в зависимости от ценности (конфиденциальности) информации и, следовательно, иерархия классов защищенности АС.

Третья группа включает АС, в которой работает один пользователь, допущенный ко всей информации АС, размещенной на носителях одного уровня конфиденциальности. Группа содер­жит два класса - 3Б и 3А.

Вторая группа включает AC, у которой пользователи имеют одинаковые права доступа (полномочия.) ко всей информации А, обрабатываемой и (или) хранимой на носителях различного уровня конфиденциальности. Группа содержит два класса - 2Б и 2А.

Первая группа включает многопользовательские АС, в которых одновременно обрабатывается и (иди) хранится информа­ция разных уровней конфиденциальности. Не все пользователи имеют право доступа ко всей информации АС. Группа содержит пять классов - 1Д, 1Г, 1В, 1Б и 1А.

Большинство АС военного назначения, как очевидно, относятся к 1 группе. Необходимо также заметить, что АС предназначенные для обработки и хранения информации отнесенной к категории сек­ретной или являющейся собственностью государства, необходимо ориентироваться на классы не ниже 3А,2А,1А,1Б,1В. Одновре­менно, при разработке АС необходимо ориентироваться на соот­ветствующий класс защищенности СВТ. Результаты такой совместимости приведены в таблице

Требования к АС первой группы
Подсистемы и требования	Классы
1В 1Б 1А
1. Подсистема управления доступом 1.1.Идентификация, проверка подлинности и контроль доступа субъектов в систему - к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ; - к программам; - к томам, каталогам, файлам, записям, полям записей 1.2.Управление потоками информации	+ + + + +   - + + + +   - + + + + - + + + + - - + + +
2. Подсистема регистрации и учета 2.1.Регистрация и учет: входа(выхода) субъектов - доступа в(из)систему (узла сети); - выдачи печатных (графических)выходных документов; - запуска (завершения) программ и процессов (заданий, задач); - допуска программ субъектов доступа к защищаемым файлам; - изменение полномочий субъектов доступа, создаваемых и защищаемых объектов доступа. 2.2.Учет носителей информации 2.3.Очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей 2.4.Сигнализация попыток нарушения защиты	+ + + - + - + + + + - + + + + - + + + + - + + + +   + + + + + - + + + +   - - + + +
3. Криптографическая подсистема 3.1.Шифрование конфиденциальной информации 3.2.Шифрование информации, принадлежащей различным субъектам доступа (группам субъектов) на разных ключах 3.3.Использование аттестованных (сертифицированных) криптографических средств
-	-	-	+	+
-	-	-	-	+
-	-	-	+	+
4. Подсистема обеспечения целостности 4.1.Обеспечение целостности программных средств и обрабатываемой информации 4.2.Физическая охрана СВТ и носители информации 4.3.Наличие администратора (службы) зашиты информации АС 4.4.Периодическое тестирование СЗИ НСД 4.5.Наличие средств восстановления СЗИ 4.6.Использование сертифицированных средств защиты
+	+	+	+	+
-	-	+	+	+
-	-	+	+	+
+ + -	+ + -	+ + +	+ + +	+ + +

4. Количественная оценка стойкости парольных систем.

В общем случае (опыт работы это подтверждает) можно рекомендовать использовать для пароля от 6 до 10 символов, и как наиболее оптимальный вариант - 7-8 символов.

В приведенной ниже таблице показано количество комбинаций, получающихся в зависимости от набора символов, используемых при формирова­нии пароля, а также время, необходимое для полного перебора всех вариантов (при условии, что в одну секунду перебирается 1,000,000 вариантов, т.е. за один год непрерывной работы можно обработать 3.15*10^13 вариантов).

Таблица зависимости времени на перебор паролей от длины и алфавита

Количество символов в пароле	Количество комбинаций из 160 символов	Время на полный перебор (лет)	Количество комбинаций из рус.букв (бол.и мал)	Время на полный перебор (лет)
	1.67*1013	0.5	8.2*1010	1 день
	2.68*1015	85 лет	5.5*1012	2 мес.
	4.29*1017	1.4*104	3.6*1014	10 лет
	6.87*1019	2.2*106	2.4*1016	750 лет
	1.1*1022	3.5*108	1.6*1018	50000 лет

Из таблицы видно, что чем больше длина пароля и шире набор используемых символов, тем сложнее его подобрать. Даже если предположить, что пароль будет найден после перебора только одного процента всех комбинаций, то пароль из 8 символов (если при его формировании можно было использовать 160 символов) дает стойкость в 100 лет, что для сохранности большинства коммерческих и банковских секретов вполне достаточно.

5. Компьютерные вирусы. Классификация. Примеры схем внедрения.

Термин «компьютерный вирус» был введен сравнительно недавно - в середине 80-х годов. Малые размеры, способность быстро распространяться, размножаясь и внедряясь в объекты (заражая их), негативное воздействие на систему - все эти признаки биологических вирусов присущи и вредительским программам, получившим по этой причине название «компьютерные вирусы». Вместе с термином «вирус» при работе с компьютерными вирусами используются и другие медицинские термины: «заражение», «среда обитания», «профилактика» и др. «Компьютерные вирусы» - это небольшие исполняемые или интерпретируемые программы, обладающие свойством распространения и самовоспроизведения (репликации) в КС. Вирусы могут выполнять изменение или уничтожение программного обеспечения или данных, хранящихся в КС. В процессе распространения вирусы могут себя модифицировать.