3. РАЗРАБОТКА АРХИТЕКТУРНОГО ОПИСАНИЯ

3.1. Определение описания архитектуры и обзор информации по программной системе

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

Примерный план идентификации системы включает:

-дата начала и статус разработки;

–авторы, рецензенты, заказчики и контролирующие организации;

–исторический обзор и резюме;

–цели и задачи, контекст, глоссарий;

–информация о контроле версий;

–методы управления и ссылки.

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

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

-пользователи системы;

-операторы системы;

-приобретающие стороны системы;

16

-владельцы системы;

-поставщики системы;

-разработчики системы;

-строители системы;

-сопровождающие стороны системы.

Вописании архитектуры должны быть учтены и, если применимо, определены следующие интересы:

-цели системы;

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

-выполнимость конструирования и развертывания системы;

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

-сопровождаемость и развиваемость системы.

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

-какие интересы в отношении системы он имеет;

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

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

вотношении системы;

-какими инструментами он владеет;

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

Вподразделе 1.3 пояснительной записки следует представить анализ моделей домена или построение концептуальной модели системы (см. пример концептуальной модели описания архитектуры на рис. 6).

Рис. 6. - Концептуальная модель элементов и связей описания архитектуры

Для целей данного проекта достаточно представить одну или несколько моделей:

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

–концептуальной диаграммы классов;

–математических моделей;

–функциональных диаграмм;

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

17

3.2. Анализ модели домена

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

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

Примеры представления доменных моделей на рис. 7-9.

•Список старых заявлений

Рис. 7. - Контекстная диаграмма ИС Шаблонизатор заявлений студентов

18

Рис. 8. - Модель домена в виде аналитических стереотипов на диаграмме классов в Rational Software Architect

Рис. 9. - Информационная модель техники Kanban для управления проектами

Модель предметной области — это прежде всего модель данных и правила работы с ней - передача, хранение и обработка. Притом формы ввода/выводы информации, схемы обработки, абстрактные структуры массивов

19