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

Рис. 10. – Моделирование потока данных для регистрации пользователя в системе

3. Проектирование структуры и компонентов программного средства

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

Это требует ответа на следующие вопросы.

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

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

Основные допущения, и как они будут проверяться?

Какие условия могут привести к реструктуризации дизайна?

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

20

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

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

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

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

-управление исключениями;

-связь, в части определения соответствующих протоколов;

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

Рис. 11. - Типовая архитектура приложения

21

3.4. Обоснование выбора архитектурного стиля

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

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

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

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

22

в зависимости от внешних воздействий (запросов клиента, действий пользователя, сигналов внешней среды).

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

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

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

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

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

3.5. Проектирование представления

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

-представляет проблемную область – значительную неизвестную область или область значительного риска;

-ссылается на существенный для архитектуры вариант использования;

-представляет взаимодействие параметров качества с функциональностью;

-составляет компромисс между параметрами качества.

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

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

23

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

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

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

Рис. 12. – Набор артефактов для представления архитектуры ИС

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

Развертывание (англ. deployment view) — состоит из программных элементов, их размещения на физических носителях и коммуникационных элементов

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

Распределение работы (англ. work assignment view) — состоит из модулей и описания того, кто ответственен за внедрение каждого из них

24