Метод анализа и построения моделей С.Шлаер и С.Меллора

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

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

– модель состояний объектов, определенных в составе информационной модели (или онтологии);

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

Ниже рассматриваются эти модели.

Информационная модель

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

– реальные предметы мира, имеющие физическое воплощение;

– абстракции физических предметов этого мира;

– абстракции или цели использования этих предметов определяются абстрактными действиями, изменяющими их состояния;

– взаимодействия - это отношение между объектами;

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

Для классов объектов выбираются уникальные имена, устанавливаются атрибуты и устанавливаются связи между объектами.

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

Для каждого из выбранных атрибутов определяются возможные значения (типы значений) одним из следующих способов:

– задание числового диапазона;

– перечисление возможных значений;

– ссылка на документ, в котором определены возможные значения;

– правила генерации значений.

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

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

– каждый экземпляр объекта обязательно имеет одно значение (значение не может быть неопределенным или отсутствующим);

– атрибут одномерен и не имеет нескольких значений одновременно;

– если идентификатор составляется из нескольких имен атрибутов, все указанные имена атрибутов, кроме первого, относятся к первому указанному имени объекта.

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

1) проект имеет исполнителей, которые заняты в проекте;

2) руководитель управляет исполнителями, т.е. исполнитель подчинен руководителю;

3) исполнитель занимает комнату, т.е. комната занята исполнителем.

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

В методе различаются три фундаментальных вида связи между объектами:

– один к одному (1:1), в связи принимают участие по одному экземпляру с каждой стороны (пример, в некоторой организации руководитель занимает отдельный кабинет и руководит лично только одним проектом);

– один ко многим (1:n), один экземпляр объекта некоторого класса может поддерживать отношения одновременно с несколькими экземплярами объектов другого или того же класса (пример, руководитель может иметь несколько подчиненных, но у каждого из них один шеф);

– много ко многим (m: n ), в связи могут принимать участие несколько экземпляров объектов с каждой стороны.

Метод С.Шлаер и С.Меллора предусматривает специальную графическую нотацию для фиксации связей, базирующихся на диаграммах метода Чена сущность - связь (entity–relations) [3] для представления информационной модели проблемной области, суть которого заключается в следующем.

Связи между объектами изображаются стрелками, указывающими направление связи. Возле рамки объекта, принимающей участие в связи, на линии стрелки указывается роль, которая этот объект поддерживает в данной связи. Связь 1:1 обозначается двунаправленной стрелкой, имеющей по одному "наконечнику" стрелки с каждой стороны, связь 1:n обозначается стрелкой, имеющей два "наконечника" со стороны объекта, для которого в связи могут принимать участие несколько экземпляров, и, наконец, по два "наконечника" с каждой стороны имеет стрелка, означающая связь вида n : m.

Над стрелкой может указываться название (имя) связи. Связи могут быть безусловными, т.е. каждый экземпляр объекта заданного класса принимает участие в связи. Условные связи, когда отдельные экземпляры объектов класса не принимают участия в связи, и обозначаются буквой "у" в конце стрелки.

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

Матрица

– тип элемента

– количество строк

– количество столбцов

Матрица с неполным

заполнением

является

Диагональная Ленточная Разреженная

Рис.4.1. Пример диаграммы класса

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

Модель состояний

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

– состояние объекта, которое определяется текущими значениями отдельных его атрибутов;

– состояние объекта изменяется в результате произошедших действий или стимулов;

– состояние домена, которое определяется совокупностью состояний его объектов;

– изменение состояния объекта сопровождается некоторыми процессами, которые определены для каждого состояния.

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

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

Для каждого из выделенных объектов определяются:

1) множество состояний, в которых объект может находиться;

2) множество инцидентов или событий, которые побуждают экземпляры класса изменять свое состояние;

3) правила перехода для каждого из зафиксированных состояний, как указание на новое состояние экземпляра данного класса, если произойдет некоторое событие из множества событий тогда, когда объект находится в данном состоянии;

4) действия или процессы для каждого из определенных состояний, которые выполняются при переходе в данное состояние.

Для представления этой информации в нотации диаграммы перехода состояний предусматривается следующее:

– каждое состояние, определенное для класса объектов, получает название и порядковый номер, уникальную метку и название;

– состояние обозначается рамкой, содержащей номер и название состояния;

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

– начальное состояние обозначается стрелкой, направленной к соответствующей рамке и является состоянием, которое экземпляр объекта приобретает после его создания (или инициализации);

– заключительное состояние задает конец жизненного цикла экземпляра объекта, если экземпляр продолжает существовать или разрушается, обозначается оно пунктирной рамкой;

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

Для изменения состояния экземпляра класса объектов выполняются действия:

– обработка информации, переданной в сообщении о событии;

– изменение определенного атрибута объекта;

– вычисления;

– генерация операции для некоторого экземпляра класса;

– генерация события, сообщение о котором должно передается внешнему по отношению к данному домену объекту (например, человеку-оператору другой системе);

– передача сообщения о событии от внешних объектов;

– взаимодействие с двумя специфическими объектами – таймером и системными часами, где таймер служит для измерения интервала времени и встроен системным образом в данный метод.

Атрибутами таймера являются:

– уникальный идентификатор экземпляра таймера;

– интервал времени, через который будет подан сигнал о наступлении некоторого события;

– метка наступающего события, при условии, что остаток времени равен нулю;

– идентификатор экземпляра объекта, для которого устанавливается таймер.

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

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

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

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

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

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

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

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

Рис. 4.2. Схема взаимодействия моделей поведения объектов

Модель процессов

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

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

В качестве источников данных могут быть:

– атрибуты объектов, которые продолжают существовать после завершения работы системы;

– системные часы, как показатель времени;

таймеры;

– данные событий;

– сообщения внешних объектов (людей, операторов и т.п.).

Правила построения диаграмм действий потоков данных:

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

– процесс изображается овалом, в середине которого указано содержание или название процесса;

– потоки данных изображены стрелками, на которых указываются идентификаторы данных, передаваемых от процесса к процессу; стрелка к овалу процесса указывает на входные данные процесса, направление от овала процесса - на выходные данные;

– источники данных изображены как прямоугольники или рамками с открытыми сторонами;

– данным, имеющим своими источниками архивные объекты, соответствуют потоки с названиями атрибутов объектов, которые передаются потоками (при этом название объекта может не указываться);

– потоки данных от таймера маркируются названием таймера;

– потоки данных от системных часов маркируются показателями времени (час, минута, и т.п.);

– событие, сообщение о котором получает процесс, изображается как стрелка, маркируемая названиями данных событий;

– процесс, породивший событие и процесс от приема сообщения о событии, относятся к одной диаграмме действий потоков данных и связывается потоком;

– если событие, созданное процессом некоторой диаграммой действий потоков данных, вызывает передачу сообщения процессу, другая диаграмма действий потоков данных, для первого из указанных выше процессов указывается стрелкой, ведущей от процесса в "никуда", а для второго - стрелкой, ведущей к процессу из "ниоткуда", причем в обоих случаях стрелки маркируется данными передаваемого события.

Различаются следующие типы процессов:

– аксессор, осуществляющий доступ к архивам;

– генератор событий;

– преобразователь данных (вычисления);

– проверки условий.

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

Рис. 4.3. Пример диаграммы действий потоков данных

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

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

– идентификатор процесса;

– тип процесса;

– название процесса;

– название состояния, для которого определен процесс;

– название действия состояния.

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

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

Результатами метода инженерии требований С.Шлаер и С.Меллора являются три модели.

1. Информационная модель системы, состоящая из:

– диаграммы сущность – связь;

– описания объектов и их атрибутов (неформальное);

– описания связей между объектами (неформальное).

2. Модель поведения объектов системы, представленная в виде:

– диаграммы переходов в состояния диаграмм перехода состояний или таблицы перехода состояний;

– неформальное описания действий диаграммами перехода состояний;

– неформальное описания событий диаграммами перехода состояний.

3. Модель процессов состояний объектов, представленная в виде:

– диаграмм действий потоков данных;

– таблицы процессов состояний;

– неформальное описание процессов.

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