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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ведение элементов на следующем уровне после уровня текущего эле­ мента.

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

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

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

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

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

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

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

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

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

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

СЦЕНАРИИ ВЕРХНЕГО УРОВНЯ Производство. Эти сценарии касаются различных конфигураций,

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

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

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

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

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

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

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

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

4.2. ИНФОРМАЦИОННО-ЛОГИЧЕСКАЯ МОДЕЛЬ АСУ

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

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

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

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

Объектно-ориентированный подход основан на объектной деком­ позиции с описанием поведения системы в терминах взаимодействия объектов.

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

Декомпозиция на основе объектно-ориентированного подхода основана на выделении следующих основных понятий:

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

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

Экземпляр объекта — т о конкретный определенный элемент множества. Например, объектом может являться государственный номер автомобиля, а экземпляром этого объекта — конкретный но­ мер К 173 ПА.

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

Обобщая эти определения, можно сказать, что объект — это ти­ пичный представитель класса, а термины «экземпляр объекта» и

Рис. 4.8. Отношения между классами, объектами и предметами

«элемент класса» равнозначны. На рис. 4.8 показаны отношения ме­ жду классами, объектами и предметами реального мира.

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

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

Полиморфизм интерпретируется как способность объекта принад­ лежать более чем одному типу.

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

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

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

Основа описания модели представления — граф, отражающий ти­ пизированные связи между типизированными компонентами. Каж­ дый компонент представляется парой: <имя типа>; <имя компонен­

т а х

Каждая связь представляется пятеркой: <имя типа>; <имя ис­ ходного компонента>; <имя вида отношения>; <имя типа>; <имя свя­ занного компонента>.

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

Метаобъекты — это базовые компоненты для конструирования модели предметной области.

Виды элементов — это экземпляры конкретного метаобъекта. Модель представления конкретной предметной области есть опи­

сание совокупности видов элементов и их взаимосвязей. Элемент — это экземпляр вида элемента.

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

Используется три вида цепочек связей:

•<метаобъект>. <имя метаобъекта> — описание структуры мета­ объектов;

•<имя метаобъекта>. <имя вида элемента> — описание структуры видов элементов;

•<имя вида элементах <имя апемента> — описание связей эле­ ментов.

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

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

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

•вид элемента — определяет устойчивый для конкретной пред­ метной области набор свойств, объединяющий конкретные проекти­ руемые компоненты в группы;

Рис. 4.9. Ядро моделей представления функциональных спецификаций АСУ

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

•отношение — определяется видами элементов, вступающими во взаимосвязь и видом отношения, задающим семантику связей.

Ядро позволяет описывать требуемые виды отношений, виды эле­ ментов и отношения.

На рис. 4.9 приведена схема ядра моделей представления функ­ циональных спецификаций АСУ.

Предлагается ввести три основные модели представления для описания информации о предметной области:

•функциональная модель (ФМ);

•модель данных (МД);

•логика.

Модели представления в качестве основных используют следую­ щие виды элементов:

•действие;

•данное;

•система;

•объект;

•атрибут.

Функциональная модель ориентирована на описание систем, спо­ собных выполнять действия над данными.

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

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