Введение в объектно-ориентированную системную инженерию

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

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

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

Рис. 1. Типичный процесс системной инженерии при определении архитектуры

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

Задачи системной инженерии

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

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

Стратегии программной инженерии

Чтобы решить эти задачи, специалисты по программной инженерии применяют различные стратегии, специальным образом предназначенные разрешить проблемы междисциплинарного взаимодействия. Они используют ряд представлений архитектуры: например, логическое, физическое, представление данных, представление процессов. Чтобы определить и выразить различные аспекты процесса разработки, применяются такие методики, как сети Петри (помогают определить параллельность и синхронизацию), машины с конечным числом состояний (состояния и режимы), структурный анализ (потоки данных) и PSL/PSA (Problem Statement Language/Problem Statement Analysis), чтобы описать работу системы.

К сожалению, для этих методик не существует единого представления; они в разной степени применимы для таких этапов цикла жизни продукта, как формулировка требований, проектирование, реализация и тестирование. В рамках разработки программ обюектно-ориентированный анализ обеспечивает инкрементальный подход к определению требований, проектированию и разработке систем, интенсивно использующих программное обеспечение. Для определения и представления этих требований служит язык Unified Modeling Language (OMG Unified Modeling Language Specification, Object Management Group, Sept. 2001). UML допускает создание спецификации продукта, не зависящей от языка программирования или конкретного процесса разработки.

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

Почему OOSE?

Новые методы обюектно-ориентированной системной инженерии (OOSE – object oriented system engineering) расширяют методики анализа обюектно-ориентированного программного обеспечения за счет использования иерархии систем, подсистем и наборов компонентов, позволяя сформировать исчерпывающую инфраструктуру для процесса, показанного на рис. 1, и управлять им. По своему предназначению методы OOSE охватывают всю систему, от верхнего уровня до самых мелких ее деталей.

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

В OOSE для обозначения компонентов иерархии продукта не используется термин «узел» (node), поскольку узлами в UML представляют вычислительное аппаратное обеспечение. Вместо этого в OOSE используют термин «элемент» (element), который может обозначать физический узел, но, как правило, под ним подразумевается логическая группировка сущностей со сходным поведением.

Процесс OOSE

Рис. 2. Представление сборки системы

Задача OOSE – учитывать все ограничения и требования по мере их возникновения. OOSE предоставляет строгую методику практического решения сотен новых вопросов, которые возникают в ходе разработки продукта. В рамках данного унифицированного процесса выполняются процессы (рис. 1) для каждого элемента системной иерархии (рис. 2) путем систематического использования, анализа и наращивания модели «4 + 1 представление» (рис. 3). Данная модель описывается ниже (см. также Philippe Kruchten, The Rational Unified Process: An Introduction, 2nd edition, Addison-Wesley, 2000).

Рис. 3. 4 + 1 представление

Два дополнительных представления

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

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

Рис. 4. Диаграмма контекста верхнего уровня

Она включает в себя и иные представления архитектуры (IEEE Std. 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE, 2000), описывающие другие структурированные наборы концепций для определения систем (ISO/IEC JTC1/SC21/WG7 10746-1, Reference Model of Open Distributed Processing, Project 21.43, 1995). Эти представления проясняют вопросы, касающиеся разработки элементов, требований и ограничений; они формируют контекст для других представлений.

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

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

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

Использование 4 + 1 представления

В 1995 году Кручтен предложил использовать модель 4 + 1 представления в разработке программного обеспечения. С тех пор данная модель была расширена; ее стали применять к разработке систем вообще(рис. 4).

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

Мюррей Кантор предложил расширить это описание и диаграмму последовательности, добавив в нее предполагаемые взаимодействия подэлементов, необходимых для реализации поведения, требуемого внешними источниками (Murray Cantor, Object Oriented Program Management with UML, John Wiley & Sons, 1998). Именно это расширение для анализа случаев применения разработчики используют в OOSE для непрерывного выявления, группировки, изменения и описания поведения элементов более низкого уровня.

OOSE определяет требования к производительности в итоговых случаях применения для подэлементов. Аналогичный подход был предложен специалистами компании Rational Software, активного сторонника обюектно-ориентированных методов («Rational Unified Process for Systems Engineering,»TP 165, Rational Corp., Aug. 2001). Разработчики используют представление архитектуры (диаграмма согласования) вместе с диаграммой последовательности случаев применения, чтобы поставить и решить вопросы, касающиеся назначения функций, интерфейса, производительности и взаимодействия.

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

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

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

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

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

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

Взаимодействие представлений

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

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

Процесс разработки

Разработка в рамках OOSE, начиная с системного анализа верхнего уровня и до определения терминальных компонентов, проистекает так, как показано на рис. 5. Проектная группа повторяет этот процесс для каждого элемента в системной иерархии. Конечный результат анализа каждого из элементов – это доведенное до совершенства представление системы, вспомогательные 4 + 1 представления, а также описания, показывающие распределение функциональности во всей системе. Эти описания проецируют функциональные требования на элементы, расположенные в системной иерархии непосредственно под ними. Также они фиксируют другие архитектурно значимые, но нефункциональные требования и ограничения, в частности те из них, которые влияют на интерфейс, работу, производительность, физическую структуру, тестирование или производство. Одновременно создается документация, описывающая задания для субподрядчиков.

Рис. 5. Типичный процесс системной инженерии применительно к OOSE

Системное представление и требования

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

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

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

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

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

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

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

Выбор возможных сценариев

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

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

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

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

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

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

OOSE в проектировании

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

Разработка сценариев

Сценарии описывают последовательность действий при выполнении задачи или транзакции в приложении (Russell Hurlbut, A Survey of Approaches For Describing and Formalizing Use Cases. Document XPT-TR-97-03, Expertech, 1997). При создании сценариев проектные группы разрабатывают требования к функциональности, интерфейсам и работе и фиксируют их для элементов следующего уровня системной иерархии.

Описания сценариев (согласно тому, как их определяет Крег Ларман в своей книге Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design, Prentice Hall, 1997) задают внешнее воздействие на элементы и их предполагаемые ответные действия. В сценарии эти ответные действия добавляются в виде текстового описания, содержащего:

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

Именно в рамках обсуждения внутреннего представления проектная группа определяет, совершенствует и меняет разделение подэлементов в системном представлении.

Описания сценариев. OOSE ограничивает описание внутреннего представления подэлементами, расположенными на уровне декомпозиции, непосредственно следующим за уровнем анализируемых элементов. Например, если разработчики изучают поведение подсистемы B, изображенной на рис. 7, то они должны рассмотреть внутреннее поведение подэлементов C, B-1, Bб-2 и D. Однако в этот момент их не интересует поведение подэлементов C-1 и C-2.

Рис. 7. Иерархическое внутреннее представление

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

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

Представления процессов (в виде диаграмм активности и диаграмм классов) фиксируют зависящие от времени взаимосвязи. На этом этапе также создаются представления развертывания, соответствующие этим представлениям процессов.

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

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

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

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

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

Вопросы анализа. OOSE оставляет нерешенными проблемы описания совместного асинхронного поведения элементов, которое независимо и непредсказуемо.

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

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

Из-за часто асинхронной и механической природы проектируемых систем описания сценариев должны фиксировать обе стороны взаимодействий. К примеру, один из пунктов внутреннего представления может утверждать, что X Б?? Y (A) (т.е. элемент X общей архитектуры управляет функцией A элемента Y). Однако многие системы являются асинхронными, и запрашивающий протокол (как правило, широковещательная рассылка UDP или сила, приложенная к конструкции) часто существенно отличается от протокола, возвращающего состояние (протокол FTP или механическое движение). Описания сценариев фиксируют дополнительные внутренние пункты, специально подчеркивающие, что элемент Y выполняет функцию A. Эта особая тщательность в описании поведения элемента гарантирует возможность обсуждения уникальных для Y(A) вопросов, протоколов, ответных действий, безопасности и тестовых требований, когда необходимо получить более детальное представление о требованиях к разработке, ограничениях и ролях компонентов.

Унификация проектных решений

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

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

Рис. 8. Результаты формирования представления системы

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

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

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

Описания элементов. На этом этапе анализируются результаты первых двух этапов с тем, чтобы определить сценарии для следующего уровня декомпозиции системы. В этот момент процесса группа «выявляет» известное или предполагаемое поведение элементов более низкого уровня, и это поведение накладывает ограничения на описания внутреннего представления текущего элемента.

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

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

Преимущества унификации. На основе этих результатов фиксируются требования и ограничения, которые применяются к элементу глобально. Здесь также фиксируются и решаются вопросы и утверждаются проектные решения (Colin Potts and Glenn Bruns, Recording the Reasons for Design Decisions, Proc. Int'l Conf. Software Eng., IEEE CS Press, 1988). Кроме того, на этом этапе формируется рабочий пакет для создания элементов и выявляются требования к функциональности, производительности, срокам, пропускной способности, размерам и так далее, которые глобально применяются к данному элементу.

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

Преимущества OOSE

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

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

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

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

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

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

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

Haig Krikorian, Introduction to Object-Oriented System Engineering, Part 1. IEEE IT Pro, March-April 2003. Haig Krikorian, Introduction to Object-Oriented System Engineering, Part 2. IEEE IT Pro, May-June 2003. IEEE Computer Society, 2003, All rights reserved. Reprinted with permission.

Сценарии верхнего уровня

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

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

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

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

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

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

Ремонт. Эти сценарии, как правило, касаются выявления и устранения аномалий в подсистемах. Они также содержат планы действий по устранению дефектов в подсистемах и учитывают их влияние на архитектуру.