Направление «разработка информационной системы (ис)»

6.1 Этапы процесса проектирования

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

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

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

Рисунок 6.1 – Общая схема процесса проектирования

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

В процессе проектирования строят структурную, функциональную и информационную модели информационной системы.

6.2 Структурная модель ИС

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

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

Структурную модель системы еще называют структурной схемой. На структурной схеме отражается состав системы и ее внутренние связи. Наряду с термином «связь» нередко употребляют термин «отношение».

Наглядным способом описания структурной модели системы являются графы. На рисунке 6.2 в виде ориентированного графа приведена структурная модель компьютера.

Рисунок 6.2 – Структурная модель компьютера

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

Однако, если проектировщика интересуют связи по управлению, то граф-модель компьютера будет иметь вид (рисунок 6.3).

Рисунок 6.3 – Структурная модель компьютера

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

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

6.3 Функциональная модель ИС

Функциональную модель системы составляют в соответствии с разработанной на первом этапе структурной моделью по предварительному описанию целей функционирования и тех задач, решение которых находится в компетенции соответствующих элементов

структуры. Функциональная модель являют определяющей в составлении должностных инструкций элементов системы и их групп (компонент).

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

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

Часто функциональную модель дополняют бизнес-процедурами, отражающими поведение должностных лиц в каждой конкретной ситуации при работе с системой (рисунок 6.5).

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

6.4 Информационная модель ИС

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

– хранение информации;

– возможность упорядочения данных по некоторым признакам;

– возможность создания различных критериев выбора данных;

– представление информации в удобном для пользователя виде.

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

Методика разработки информационной модели предполагает моделирование:

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

Рисунок 6.4 – Пример функциональной модели по технологии IDEF0

Рисунок 6.5 – Пример бизнес-процедуры

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

– данных информационной базы (диаграмма «сущность-связь» - инфологической модели и диаграмма взаимосвязей файлов – даталогической модели), необходимых для функционирования информационной системы.

На рисунке 6.6 приведен пример логической DFD диаграммы потоков данных

Рисунок 6.6 – Логическая DFD диаграмма потоков данных

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

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

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

Изменение состояния объекта с течением времени отражает STD-диаграмма - диаграмма жизненного цикла (рисунок 6.7).

Рисунок 6.7 – Пример диаграммы жизненного цикла

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

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

6.5 Определение архитектурных представлений

Под архитектурой программного обеспечения (ПО) понимают набор его внутренних структур, которые состоят из компонентов, их связей и возможных взаимодействий между компонентами, а также доступных извне свойств этих компонентов.

Под компонентом понимают достаточно произвольный структурный элемент ПО, который можно выделить, определив интерфейс взаимодействия между ним и всем, что его окружает. Обычно при разработке ПО термин «компонент» имеет более узкий смысл как самая маленькая часть системы, которую можно включать или не включать в ее состав. Такой компонент также имеет определенный интерфейс и удовлетворяет некоторому набору правил, называемому компонентной моделью.

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

Использование архитектуры системы необходимо для решения следующих задач:

– Анализ альтернативных проектов системы.

– Планирование модификации системы, внесения изменений в ее организацию.

– Выработка критериев приемки системы при ее сдаче в эксплуатацию.

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

– Проектирование и разработка отдельных элементов системы.

– Сопровождение, эксплуатация, управление конфигурациями и внесение изменений и поправок.

– Проведение обзоров, анализ и оценка качества системы.

На рисунке 6.8 показана архитектура авиасимулятора, который должен моделировать определенные условия полета и создавать некоторые события, а именно:

- Скоростной и высотный режим полета, запас горючего, их изменения со временем.

- Модель самолета и ее характеристики по управляемости, возможным режимам полета и скорости реакции на различные команды.

- Погода за бортом и ее изменения со временем.

- Рельеф и другие особенности местности в текущий момент, их изменения со временем.

- Исходный и конечный пункты полета, расстояние и основные характеристики рельефа между ними.

- Исправность или неисправность элементов системы контроля полета и управления самолетом, показатели системы мониторинга и их изменение со временем.

- Наличие пролетающих вблизи курса самолета других самолетов, их геометрические и скоростные характеристики.

- Чрезвычайные ситуации, например, террористы на борту, нарушение герметичности корпуса, внезапные заболевания и «смерть» отдельных членов экипажа

Рисунок 6.8 – Архитектура авиасимулятора

6.5.1 Разработка и оценка архитектуры на основе сценариев

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

1.Выделение компонентов

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

2.Определение интерфейсов компонентов

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

3.Уточнение набора компонентов

Там, где это необходимо в силу требований эффективности, надежности или удобства сопровождения, несколько компонентов можно объединить в один либо разделить на несколько.

4.Достижение нужных свойств.

На основе возможных сценариев использования системы выполняют анализ характеристик архитектуры и оценку ее пригодности для решения поставленных задач или сравнительный анализ нескольких архитектур. Это, так называемый, метод анализа архитектуры ПО (Software Architecture Analysis Method, SAAM).

Алгоритм метода:

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

– Определить архитектуру (или несколько сравниваемых архитектур).

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

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

– Выявить взаимодействие сценариев.

– Оценить архитектуру в целом (или сравнить несколько заданных архитектур), используя оценки важности сценариев и степень их поддержки архитектурой.

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

1.Выделим следующие сценарии работы или модификации программы:

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

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

– Возможность обработки индексатором текстов, подаваемых ему на вход в виде архивов.

– Размещение в индексе только слов в основной грамматической форме — существительных в единственном числе и именительном падеже, глаголов в неопределенной форме и т.д.

2.Определим две возможных архитектуры индексатора для сравнительного анализа.

В качестве первой архитектуры рассмотрим разбиение индексатора на два компонента. Один компонент принимает на свой вход входной текст, полностью прочитывает его и выдает на выходе список слов, из которых он состоит. Второй компонент принимает на вход список слов, а на выходе выдает его упорядоченный вариант без повторений. Этот вариант архитектуры построен в стиле «каналы и фильтры» (рисунок 6.9)

Рисунок 6.9 - Архитектура индексатора в стиле «каналы и фильтры»

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

В дополнение к этим данным имеются следующие компоненты:

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

– Второй компонент осуществляет ввод последнего слова — оно помещается в список перед тем местом, на которое указывает ссылка, после чего последнее слово становится пустым, а ссылка начинает указывать на первое слово в списке.

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

– Четвертый компонент выдает полученный индекс на выход.

Эта архитектура построена в стиле «репозиторий» (рисунок 6.10).

Рисунок 6.10 - Архитектура индексатора в стиле репозитория

Определим поддерживаемые сценарии из выделенного набора.

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

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

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

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

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

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

6.5.2 Унифицированный язык моделирования (Unified Modeling Language, UML)

Для представления архитектуры, удобно использовать графические языки. На настоящий момент наиболее проработанным и широко используемым из них являетсяUML. UML предлагает использовать для описания архитектуры 8 видов диаграмм.

Диаграммы классов (class diagrams) показывают классы или типы сущностей системы, характеристики классов (поля и операции) и возможные связи между ни ми. Пример диаграммы классов изображен на рисунке 6.11.

Рисунок 6.11 – Пример диаграммы классов

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

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

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

Рисунок 6.12 - Пример диаграммы объектов

Диаграммы компонентов представляют компоненты системы с точки зрения ее сборки, конфигурационного управления и развертывания. Компоненты сборки и конфигурационного управления обычно представляют собой файлы с исходным кодом, динамически подгружаемые библиотеки, HTML-странички и пр., компоненты развертывания — это компоненты JavaBeans, CORBA, COM и т.д. Компонент изображается в виде прямоугольника с несколькими прямоугольными или другой формы «зубами» на левой стороне. Связи, показывающие зависимости между компонентами, изображаются пунктирными стрелками. Один компонент зависит от другого, если он не может быть использован в отсутствии этого другого компонента в конфигурации системы. Компоненты могут также реализовывать интерфейсы. Диаграммы этого вида используются редко.

На диаграмме компонентов есть пакеты, изображаемые в виде «папок», прямоугольников с прямоугольными «наростами» над левым верхним углом. Пакеты являются пространствами имен и средством группировки диаграмм и других модельных элементов UML — классов, компонентов и пр.

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

Рисунок 6.13 - Пример диаграммы компонентов

Физические устройства, называемые узлами системы, изображают в виде кубов или параллелепипедов, а физические соединения между ними — в виде линий. Эти диаграммы используются достаточно редко.

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

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

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

Рисунок 6.14 - Пример диаграммы развертывания

Диаграммы сценариев (или диаграммы последовательности) показывают возможные сценарии обмена сообщениями или вызовами во времени между различными компонентами. Компоненты, участвующие во взаимодействии, изображают прямоугольниками вверху диаграммы. От каждого компонента вниз идет вертикальная линия, называемая его линией жизни. Считается, что ось времени направлена вертикально вниз. Интервалы времени, в которые компонент активен, то есть управление находится в одной из его операций, представлены тонким прямоугольником, для которого линия жизни компонента является осью симметрии. Передачу сообщения или вызов изображают стрелкой от компонента-источника к компоненту-приемнику. Возврат управления показан пунктирной стрелкой, обратной к соответствующему вызову. Эти диаграммы используются достаточно часто, например, при детализации сценариев, входящих в варианты использования.

Рисунок 6.15 - Пример диаграммы деятельности

Рисунок 6.16 - Пример диаграммы сценариев

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

Рисунок 6.17 - Пример диаграммы взаимодействия, соответствующей примеру диаграммы сценариев

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

Рисунок 6.18- Пример диаграммы состояний,моделирующей сайт Интернет-магазина