книги / Теоретические основы автоматизированного управления

Новые методы объектно-ориентированной системной инжене­ рии OOSE (Object Oriented System Engineering) расширяют методики объектно-ориентированного подхода за счет использования иерар­ хии систем, подсистем и наборов компонентов, позволяя сформиро­ вать исчерпывающую инфраструктуру для процесса, показанного на рис. 4.1, и управлять им. По своему предназначению методы OOSE охватывают всю систему, от верхнего уровня до самых мелких ее дета­ лей.

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

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

Задача OOSE — учитывать все ограничения и требования по мере их возникновения. OOSE предоставляет строгую методику практиче­ ского решения сотен новых вопросов, которые возникают в ходе раз­ работки продукта. В рамках данного унифицированного процесса выполняются процессы (см. рис. 4.1) для каждого элемента систем-

Система

Подсистема В

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

ной иерархии (см. рис. 4.2) путем систематического использования, анализа и наращивания модели, получившей название «4 + 1 пред­ ставление» (рис. 4.3).

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

Диаграмма контекста верхнего уровня. Диаграмма контекста верх­ него уровня (рис. 4.4) описывает систему, внешние интерфейсы, ог­ раничения, требования к производительности, тестовые конфигура­ ции, а также требования к разработке и ограничения на элементы. Она включает в себя и иные представления архитектуры (IEEE Std. 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE, 2000), описывающие другие струк­ турированные наборы концепций для определения систем (ISO/IEC

Процесс

развертывания

Ограничения Требования

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

JTC1/SC21/WG7 10746-1, Reference Model of Open Distributed Processing, Project 21.43,1995). Эти представления проясняют вопро­ сы, касающиеся разработки элементов, требований и ограничений; они формируют контекст для других представлений.

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

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

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

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

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

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

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

OOSE определяет требования к производительности в итоговых случаях применения для подэлементов. Аналогичный подход был предложен специалистами компании Rational Software, активного сторонника объектно-ориентированных методов. Разработчики ис­ пользуют представление архитектуры (диаграмму согласования) вме­ сте с диаграммой последовательности случаев применения, чтобы поставить и решить вопросы, касающиеся назначения функций, ин­ терфейса, производительности и взаимодействия.

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

физических элементов, которые совместно формируют поведение системы.

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

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

втой или иной степени создать с помощью механизмов, предлагаемых

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ниям системного уровня, которые не так-то просто отобразить на интерфейсы. Тем не менее разработчики могут знать, как низкоуров­ невые системные компоненты выполняют эти требования, несмотря на то, что они не проявляются на системном уровне.

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

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

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

Описания сценариев задают внешнее воздействие на элементы и их предполагаемые ответные действия. В сценарии эти ответные дей­ ствия добавляются в виде текстового описания, содержащего:

•внешнее представление поведения элемента в ответ на воздейст­ вия через эти интерфейсы;

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

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

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

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