Мансуров Н. Н., Майлингова О. Л. - Методы формальной спецификации программ (1184226), страница 5
Текст из файла (страница 5)
Основной задачей фазы анализа системы являетсяточное определение того, какой объект выполняет какое поведение сценарияиспользования. Сказанное выше не означает, что уже на данном этапеповедение должно быть разбито на отдельные операции, хотя это ивозможно. Более адекватным является текстовое описание обязанностейкаждого объекта (ролей объектов).Рассмотрим каждый из трех типов объектов более подробно и опишемподход выделения данных объектов из сценариев использования.213.2. Интерфейсные объектыВсяфункциональностьсценарияиспользования,котораянепосредственно зависит от окружения системы, определятся винтерфейсных объектах. Внешние агенты используют объекты данного типадля взаимодействия с системой. Назначением интерфейсного объектаявляется перевод информации, получаемой от агентов в форму сигналоввнутри системы, а также для перевода сигналов системы во внешнеепредставление для передачи агентам.
Иными словами, интерфейсныеобъекты описывают двунаправленное взаимодействие между системой ивнешними агентами (окружением).Обычно, интерфейсные объекты легко выделить. Существуют, покрайней мере, три стратегии. Интерфейсные объекты могут быть выделеныиз описания внешних интерфейсов системы. Другой стратегией выделенияинтерфейсных объектов является анализ сценариев использования ивыделение функциональности, зависящей от окружения системы. Болеепрямой путь к выделению интерфейсных объектов является анализ агентов.Каждый агент должен иметь, по крайней мере, один интерфейс длявзаимодействия с системой.
Имея выделенные интерфейсные объектынесложно изменять интерфейс системы. Существует два типа интерфейсныхобъектов: объекты, описывающие интерфейс с другими системами иобъекты, поддерживающие интерфейс с пользователем. Взаимодействиемежсистемных интерфейсных объектов описывается, как правило, в формепротоколов обмена.3.3. Информационные объектыИнформационные объекты используются для моделирования данных,время жизни которых больше, чем время выполнения отдельного сценарияиспользования. Очевидно, что именно информационные объектыобеспечиваюткоординациювыполненияразличныхсценариевиспользования.Большинство информационных объектов можно выделить из моделипроблемной области. Но не все.
Информационные объекты часто бываютсвязаны с понятиями реального мира, не имеющего отношения кразрабатываемой системе. Таким образом, наиболее важной задачей являетсямоделирование только необходимых информационных объектов. Поэтомуинформационные объекты нужно выделять непосредственно из сценариевиспользования. В разрабатываемую модель надо включать только те22объекты, которые необходимы для выполнения сценария. Для храненияинформации объекты используют атрибуты.
Любой информационный объектможет иметь несколько атрибутов. Каждый атрибут имеет тип, которыйможет представлять собой как простой, так и сложный тип данных. Атрибутописывается как связь с именем и кардинальностью. Объекты всех типовмогут иметь атрибуты для описания хранимой информации.Информационные объекты и атрибуты имеют много схожих свойств.Возникает проблема, как отличить атрибут от информационного объекта.Отличие состоит в использовании информации. Информация, которая можетобрабатываться самостоятельно, представляет собой информационныйобъект. Информация, которая тесно связана с другой информацией и никогдаотдельно не используется, представляет собой атрибут некоторогоинформационного объекта. Другими словами, решающим фактором являетсяспособ обработки информации в сценарии использования.
Некотораяинформация может быть представлена информационным объектом однойсистемы и атрибутом объекта другой системы. Если она используется изразличных мест и для различных целей, то представляет собой отдельныйинформационный объект.Как правило, не представляет трудности выделить необходимыеинформационные объекты. Сложнее определить операции и атрибутыданных объектов. Определен единственный способ доступа кинформационным объектам – посредством операций над ним.
Поэтому наборопераций должен быть полным для любого возможного использованияобъекта. Подробное описание сценария использования является наиболеезначимым источником для определения операций. В сценарияхиспользования описаны все события, которые могут происходить. Выделяячасти, относящиеся к рассматриваемому информационному объекту,находим требуемый набор операций.Взаимодействие между информационными объектами осуществляется спомощью связей по взаимодействию.3.4.
Управляющие объектыВ сложных сценариях использования некоторое поведение нежелательно описывать с помощью интерфейсных и информационныхобъектов, поскольку оно напрямую не связано ни с каким из объектов вотдельности. Такое поведение определяется в управляющих объектах.Управляющие объекты обеспечивают координацию несколькихобъектов, совместно реализующих некоторый сценарий использования. Онисуществуют только во время существования сценария использования.23Как правило, управляющие объекты обнаруживаются по сценариюиспользования, например можно ввести один управляющий объект накаждый конкретный и абстрактный сценарий. По каждому сценариюиспользования,какправило,определяютсяинтерфейсныеиинформационные объекты.
Поведение, которое не было определено этимиобъектами, определяется в управляющих объектах. Некоторые отклонения отуказанного подхода могут возникать в случаях, когда в сценарии не остаетсянеопределенного поведения (и управляющий объект не нужен), или когда неопределено слишком сложное поведение (и его следует определить более чемодним управляющим объектом).
Надо стремиться связывать одинуправляющий объект с одним агентом. В таком случае упрощаетсялокализация изменений в программе, вызванных изменениями агентов.Типичными примерами функциональности управляющих объектовявляются: поведение, связанное с взаимодействием (обменом),специфические управляющие последовательности, связанные с однимили несколькими сценариями, а также любые действия по связиинтерфейсных и информационных объектов.3.5. ЗаключениеВ данной главе мы привели основные понятия архитектурных моделей.Было дано определение архитектуры, устойчивой к изменениям и показано,как можно обнаружить такие архитектуры, систематически выделяя объектытрех типов: интерфейсные, информационные и управляющие.24Глава 4.
Язык диаграмм взаимодействияЯзык диаграмм взаимодействия (Message Sequence Charts, MSC) - это языкописания поведения системы в виде последовательности событий. Событиямогут относиться к отдельным компонентам системы, к взаимодействияммежду компонентами системы либо к взаимодействию между системой иее окружением. Основное назначение диаграмм взаимодействия – описаниепоследовательностей допустимых взаимодействий между компонентамисистемы и системой и ее окружением.Разновидности диаграмм взаимодействия используются при разработкесистем реального времени с 60х годов.
Особое распространение диаграммывзаимодействия получили в области разработки телекоммуникационныхсистем. Язык диаграмм взаимодействия стандартизован в 1992 г.Международным Телекоммуникационным Союзом (Рекомендация Z.1201992). В настоящее время принята новая, значительно расширенная версиястандарта (Рекомендация Z.120 1996). В лекциях язык диаграммвзаимодействия описывается в рамках стандарта 1992 г.
Некоторыеуточнения семантики диаграмм взаимодействия предлагаются нами.4.1. Основные понятияДиаграмма взаимодействия описывает последовательности событий,происходящих с набором объектов (системой взаимосвязанныхкомпонентов). Дополнительно, каждая система рассматривается какоткрытая, т.е. подразумевается наличие некоторого окружения системы, скоторым система взаимодействует.Основным понятием диаграммы взаимодействий является трассаобъекта.
Для каждого объекта на диаграмме имеется отдельная вертикальнаяось. На этой оси откладываются события, имеющие отношение к данномуобъекту. Считается, что все объекты существуют одновременно ипоследовательности событий объектов развиваются параллельно.Основная разновидность события - это взаимодействие двух объектов,либо взаимодействие объекта и окружения системы. Взаимодействие междуобъектами (а также между объектом и окружением системы) осуществляетсятолько при помощи обмена сообщениями.4.1.1.
ДиаграммаДиаграмма описывает последовательность событий для некоторогомножества объектов и его окружения. Окружение системы представляетсярамкой диаграммы. Заметим, что иногда (в качестве некоторого соглашения)25окружение системы моделируют при помощи дополнительного объекта сименем ENV (от англ. "environment", т.е. "окружение").Графический синтаксис:<msc diagram> ::=<msc symbol> contains{<msc heading>{<instance area> | <external message area>}*}<msc symbol> ::=<frame symbol><frame symbol> ::=<msc heading> ::=msc <msc name>4.1.2. ОбъектКаждый объект на диаграмме имеет уникальное имя.
Дополнительно, длякаждого объекта может быть указано, что он является экземпляромнекоторого типа объектов.Для соотнесения диаграмм взаимодействия с языком SDL имеетсявозможность дальнейшего уточнения типа объекта: различаются типсистемы (ключевое слово system), тип блока (ключевое слово block), типпроцесса (ключевое слово process). Уточнение типа объекта имеет смыслтолько при соотнесении диаграмм взаимодействия с SDL-спецификациями.Ключевое слово decomposed используется для обозначения того, чтоимеется иерархическая декомпозиция данного объекта (диаграммадекомпозиции), на которой трасса данного объекта представлена какдиаграмма взаимодействия внутренних компонентов объекта.Графический синтаксис:<instance area> ::= <instance head area>is followed by <instance body are><instance head area> ::= <instance head symbol>is associated with <instance heading><instance heading> ::= <instance name>[:<instance kind> ][decomposed]<instance head symbol> ::=<instance name>::= <name><instance kind>::= [ <kind denominator> ] <kind name><kind denominator> ::= system | block | process<kind name>::= <name><instance body area>::= <instance axis symbol>{is followed by <instance event area>is followed by <instance axis symbol> }∗is followed by { <instance end symbol> | <stop symbol> }26<instance axis symbol> ::=<instance event area> ::= <message in area>| <message out area>| <create area>| <timer area>| <concurrent area>| <action area>| <condition area><instance end symbol> ::=Примечания1) Символ заголовка объекта описывает начало нашего наблюдениянад объектом.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
