Опубликован: 03.02.2016 | Доступ: свободный | Студентов: 1608 / 339 | Длительность: 07:40:00
Лекция 3:

Разработка архитектуры программного обеспечения. Аналитический синтез информации

< Лекция 2 || Лекция 3: 1234 || Лекция 4 >

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

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

Тему правил, методов, методологий, в соответствии с которыми разрабатывается архитектура программных продуктов, мы будем подробно рассматривать в лекции №4.

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

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

Из современных нотаций можно выделить следующие:

  • Блок-схемы (схемы алгоритмов)

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

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

  • DFD-диаграмма (диаграмма потоков данных)

    DFD – это нотация структурного анализа.

    В данной нотации принято описывать внешние, по отношению к разрабатываемому продукту:

    • Источники данных;
    • Адресаты данных;
    • Логические функции;
    • Потоки данных;
    • Хранилища данных.

    Диаграмма потоков данных - это один из первых и основных инструментов структурного анализа и проектирования верхнеуровневой архитектуры программных продуктов, существовавших до последующего широкого распространения UML.

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

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

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

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

  • ER-диаграмма (диаграмма сущность-связь)

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

  • EPC-диаграмма (диаграмма событийной цепочки процессов)

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

    История развития данного типа диаграмм связана с разработкой одноименного метода в рамках работ по созданию методологии ARIS (Architecture of Integrated Information Systems - Архитектура интегрированных информационных систем).

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

  • BPMN-диаграммы

    Один из самых распространенных типов нотаций на сегодняшний день – это BPMN (Business Process Model and Notation).

    EPC, ER, BPMN - это не просто нотации, а методы реализации конкретных моделей процессов. BPMN по своему назначению более уместно сравнивать c диаграммами EPC. Причина этого заключается в том, что они имеют схожую цель – функциональное моделирование бизнес процессов. Рассматриваемая диаграмма самый новый, из приведенных в обзоре, принятый стандарт моделирования бизнес процессов. Главное позиционируемое преимущество диаграммы BPMN – понятная всем стэйкхолдерам разрабатываемой архитектуры и программного продукта визуализация моделируемых процессов.

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

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

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

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

  • UML- диаграммы

    UML (Unified Modeling Language) - не просто нотация или группа нотаций, а язык графического описания для объектного моделирования.

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

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

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

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

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

  • EIP- диаграммы

    Самая специфичная и наименее распространенная нотация из всех рассматриваемых в данной лекции.

    EIP (Enterprise Integration Patterns) диаграммы - это набор из 65 шаблонов диаграмм, которые предназначены для описания специализированных процессов взаимодействия между программными продуктами. Специфика данной нотации состоит в том, что она разработана для описания конкретных процессов, обеспечивающих интеграционное взаимодействие между приложениями и функциональность программных продуктов, ориентированных на обмен сообщениями между информационными системами.

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

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

  • Модели компонентов, программных продуктов и функциональных процессов

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

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

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

  • Прототипы

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

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

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

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

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

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

  • Интерфейсы:

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

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

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

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

    На текущий момент есть множество инструментов для создания интерфейсов разной степени сложности и детальности. Мы выделим следующие Balsamiq mockup, Axure RP и пр.

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

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

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

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

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

< Лекция 2 || Лекция 3: 1234 || Лекция 4 >