Файл: Архитектура информационных.pdf

41
Рис. 6. Пример сети Петри t
1
- поступила заявка на обработку; t
2
- задание начинает обрабатываться; t
3
- конец обработки задания; t
4
- передача выполненной заявки; p
1
- задание ждет освобождения станции; р
2
- задание обрабатывается; р
3
- задание ожидает очереди на выход; p
4
- рабочая станция свободна.
Позиция р4 показывает, свободна ли рабочая станция. Наличие метки в позиции указывает на то, что станция свободна. Как только задание начинает обрабатываться, срабатывает переход t2, и маркировка позиции обнуляется.
После окончания обработки запускается переход t3 и позиция р4 вновь получает метку. Таким образом, пока не сработает переход t3, новая заявка не может быть обработана.
4.9. Методология документирования процессов IDEF3
Стандарт
IDEF3
- это методология описания процессов, рассматривающая последовательность выполнения и причинно-следственные связи между ситуациями и событиями для структурного представления знаний о системе. При помощи IDEF3 описывают логику выполнения работ, очередность их запуска и завершения, т.е. IDEF3 предоставляет инструмент моделирования сценариев действий сотрудников организации, отделов, цехов и т.п., например, порядок обработки заказа или события, на которые необходимо реагировать за конечное время, выполнение действий по производству товара и т.д.
IDEF3 как инструмент моделирования фиксирует следующую информацию о процессе:

объекты, которые участвуют при выполнении сценария;

роли, которые выполняют эти объекты, например, агент, транспорт;

отношения между работами в ходе выполнения сценария процесса;

42

состояния и изменения, которым подвергаются объекты;

время выполнения и контрольные точки синхронизации работ;

ресурсы, которые необходимы для выполнения работ.
Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

документировать имеющиеся данные о технологии выполнения процесса, выявленные, например, во время опроса специалистов предметной области, ответственных за организацию рассматриваемого процесса или участвующих в нем;

анализировать существующие процессы и разрабатывать новые;

определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;

определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например, изменение конструктивных, технологических или эксплуатационных свойств конечного продукта;

содействовать принятию оптимальных решений при реорганизации процессов;

разрабатывать имитационные модели технологических процессов по принципу «как будет, если...».
Таким образом, IDEF3 - это методология, способная фиксировать и структурировать описание работы системы. При этом сбор сведений может производиться из многих источников, что позволяет зафиксировать информацию от экспертов о поведении системы.
4.10. Основные элементы IDEF3-диаграмм
Основные элементы IDEF3-диаграмм следующие:

43
Рис. 6. Элементы IDEF3-диаграмм.
Разветвление или объединение связей может быть только через перекрески. Перекрестки используются для отображения логики отношений между множеством событий и временной синхронизации активизации элементов IDEF3-диаграмм. Различают перекрестки для слияния (Fan-in
Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать его тип. Тип перекрестка определяет логику и временные параметры отношений между элементами диаграммы. Все перекрестки на диаграмме нумеруются, каждый номер имеет

44 префикс «J». Тип перекрестка обозначается внутри элемента: & - логический И;
∪ - логический ИЛИ; X - логический перекресток неэквивалентности.
Стандарт IDEF3 предусматривает разделение перекрестков типа & и
∪ на синхронные и асинхронные. Это разделение позволяет учитывать в диаграммах описания процессов синхронизацию времени активизации.
Методология IDEF3 использует пять логических типов для моделирования возможных последствий действий в сценарии.
Рис. 7. Пример использования перекрестков.
4.11. Декомпозиция описания процесса
Методология IDEF3 дает возможность представлять процесс в виде иерархически организованной совокупности диаграмм. Диаграммы состоят из нескольких элементов описания процесса IDEF3, причем каждый функциональный элемент UOB потенциально может быть детализирован на другой диаграмме. Такое разделение сложных комплексных процессов на их структурные части называется декомпозицией.

45
Рис. 8. Пример декомпозиции диаграммы IDEF3
4.12. Диаграммы потоков данных (DFD)
Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram - DFD), обеспечивающей правильное описание выходов (отклика системы в вида данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы).
Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе.
Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна-Сарсона (Gane-Sarson), представленные на рисунке (рис. 8.).
Потоки данных являются механизмами, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Назначение процесса (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса.
Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, «вычислить максимальную высоту»).
Кроме того, каждый процесс должен иметь уникальный номер для ссылок на

46 него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
Хранилище (накопитель) данных позволяет на определенных участках определять данные, которые будут сохраняться в памяти между процессами.
Фактически хранилище представляет «срезы» потоков данных во времени.
Информация, которую оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке.
Имя хранилища должно идентифицировать его содержимое и быть существительным.
Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, «склад товаров». Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
Рис. 8. Основные символы диаграммы потоков данных DFD.

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

48
Миниспецификации обработки описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы.
Для обеспечения декомпозиции данных и некоторых других сервисных возможностей к DFD добавляются следующие типы объектов:

групповой узел предназначен для расщепления и объединения потоков. В некоторых случаях может отсутствовать, то есть фактически вырождаться в точку слияния/расщепления потоков на диаграмме;

узел-предок позволяет увязывать входящие и выходящие потоки между детализируемым процессом и детализирующей DFD;

неиспользуемый узел применяется в ситуации, когда декомпозиция данных производится в групповом узле, при этом требуются не все элементы входящего в узел потока;

узел изменения имени позволяет неоднозначно именовать потоки, при этом их содержимое эквивалентно. Например, если при проектировании разных частей системы один и тот же фрагмент данных получил различные имена, то эквивалентность соответствующих потоков данных обеспечивается узлом изменения имени. При этом один из потоков данных является входным для данного узла, а другой - выходным;

текст в свободном формате в любом месте диаграммы.
Возможный способ изображения этих узлов приведен на рисунке.

49
Рис. 9. Расширения диаграммы потоков данных.
Рис. 10. Пример диаграммы DFD
5. ПАТТЕРНЫ В АРХИТЕКТУРЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Шаблон проектирования или паттерн (англ. design pattern) в разработке программного обеспечения — повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста.
Обычно шаблон не является законченным образцом, который может быть прямо преобразован в код; это лишь пример решения задачи, который можно использовать в различных ситуациях. Объектно-ориентированные шаблоны

50 показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться.
«Низкоуровневые» шаблоны, учитывающие специфику конкретного языка программирования, называются идиомами. Это хорошие решения проектирования, характерные для конкретного языка или программной платформы, и потому не универсальные.
На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой архитектуру всей программной системы.
Алгоритмы по своей сути также являются шаблонами, но не проектирования, а вычисления, так как решают вычислительные задачи.
Можно сказать, что паттерны в программировании применяются с 1987 г.
В сравнении с полностью самостоятельным проектированием, шаблоны обладают рядом преимуществ. Основная польза от использования шаблонов состоит в снижении сложности разработки за счёт готовых абстракций для решения целого класса проблем. Шаблон даёт решению своё имя, что облегчает коммуникацию между разработчиками, позволяя ссылаться на известные шаблоны. Таким образом, за счёт шаблонов производится унификация деталей решений: модулей, элементов проекта, — снижается количество ошибок.
Применение шаблонов концептуально сродни использованию готовых библиотек кода. Правильно сформулированный шаблон проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова. Набор шаблонов помогает разработчику выбрать возможный, наиболее подходящий вариант проектирования. Вместе с тем, хотя легкое изменение кода под известный шаблон может упростить понимание кода, по мнению Стива
Макконнелла, с применением шаблонов могут быть связаны две сложности.
Во-первых, слепое следование некоторому выбранному шаблону может привести к усложнению программы. Во-вторых, у разработчика может возникнуть желание попробовать некоторый шаблон в деле без особых оснований.

51
Основное отличие паттернов от компонентов состоит в том, что компонент является модулем, который после настройки можно включить в состав системы, т.е. его можно рассматривать как готовый к употреблению строительный блок, а паттерн — это только заготовка, которую еще надо обработать, т. е. добавить код, определяющий функциональность.
Известны различные подходы к классификации паттернов. Так, паттерны предлагается классифицировать с точки зрения уровня абстракции на концептуальные, проектирования и программные.
Концептуальные паттерны — это паттерны, функционирование которых описывается в терминах предметной области. Такие паттерны относятся к приложению в целом или крупным подсистемам ИС.
Паттерны проектирования — это паттерны, для описания которых используются термины, относящиеся к разработке программных систем, такие как объект, класс, модуль. Паттерны проектирования описывают решение общих проблем в конкретном контексте.
Программные паттерны — это паттерны, для описания которых используются такие относительно низкоуровневые понятия как деревья, списки и т. п.
Используется также классификация, в соответствии с которой выделяются следующие типы паттернов: архитектурные, системные, структурные, поведенческие, производящие, параллельные программирования
[15]. Кроме того, паттерны можно разделить на паттерны общего назначения и доменно-ориентированные паттерны. Паттерны общего назначения не привязаны явным образом к той или иной предметной области (домену), а доменно-ориентированные паттерны имеют такую привязку.
Архитектурный паттерн (architectural patterns) описывает структуру программной системы и определяет состав подсистем, их основные функции и допустимые способы компоновки подсистем. Архитектурные паттерны называют также архитектурными стилями. Архитектурные паттерны являются описанием, которое не зависит ни от платформы, ни от языка

52 программирования. Архитектурные паттерны можно рассматривать как паттерны высокого уровня. Архитектурные стили были рассмотрены ранее.
Системные паттерны (system patterns) представляют собой приложение на верхнем (системном) уровне. Системные паттерны могут применяться в приложении для реализации типовых процессов и даже для поддержки взаимодействия разных приложений.
Системные паттерны можно рассматривать как паттерны, использование которых позволяет получить улучшенные архитектурные решения.
Структурные паттерны с одинаковой эффективностью применяются как для разделения, так и для объединения элементов приложения.
Структурные шаблоны могут быть использованы для решения различных задач. Например, шаблон Адаптер может обеспечить возможность двум несовместимым системам обмениваться информацией, тогда как шаблон Фасад позволяет отобразить упрощенный пользовательский интерфейс, не удаляя ненужных конкретному пользователю элементов управления.
Поведенческие паттерны (behavioral patterns) применяются для передачи управления в системе. Существуют методы организации управления, применение которых позволяет добиться значительного повышения как эффективности системы, так и удобства ее эксплуатации. Поведенческие шаблоны представляют собой набор проверенных на практике методов и обеспечивают понятные и простые в применении эвристические способы организации управления.
Производящие паттерны (creational patterns) предназначены для создания объектов в системе.
В ходе работы большинства объектно-ориентированных систем, независимо от уровня их сложности, создается множество экземпля ров объектов. Производящие паттерны облегчают процесс создания объектов, предоставляя разработчику следующие возможности: