Московский физико-технический институт
Опубликован: 24.09.2008 | Доступ: свободный | Студентов: 4507 / 2185 | Оценка: 4.52 / 4.48 | Длительность: 25:15:00
Специальности: Системный архитектор
Лекция 5:

Методы объектного анализа и построения моделей предметных областей

< Лекция 4 || Лекция 5: 12345 || Лекция 6 >

Альтернативой графической диаграммы перехода состояний является табличная нотация (табл. 4.1 для модели состояний на рис. 4.2).

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

Таблица 4.1. Таблица переходов состояний – обслуживание клиентов
А1 -клиент ожидает А2 - клиент ожидает A3 - известен клиенту
1. Ожидание клиента 2 Событие игнорируется Не может произойти
2. Ожидание свободного клерка Событие игнорируется 3 Не может произойти
3. Определение клеерка клиентом Событие игнорируется Событие игнорируется 1

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

Поведение отдельного объекта представляется в модели диаграммой перехода в состояния, а поведение системы - в виде схемы взаимодействия отдельных диаграмм, каждая из которых получает название в соответствующем овале (рис. 4.4). Овалы, отображающие отдельные диаграммы перехода состояний, связаны между собою стрелками, на которых задаются сообщения для возбуждения события. На стрелке указывается метка события (например, С1, С2, \dots, С8), а ее направление соответствует направлению передачи сообщения. Внешние объекты обозначаются прямоугольниками с названиями.

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

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

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

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

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

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

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

Для представления потоков данных используют диаграммы действий, правила построения таких диаграмм таковы:

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

В данном методе различаются следующие процессы общего назначения:

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

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

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

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

  • идентификатор процесса;
  • тип процесса;
  • название процесса;
  • название состояния, для которого определен процесс;
  • название действия состояния.

Таблица дает возможность проверить:

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

Рис. 4.5. Пример диаграммы действий процессов создания репозитария

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

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

  • идентификатор процесса;
  • тип процесса;
  • название процесса;
  • название состояния, для которого определен процесс;
  • название действия состояния.

Таблица дает возможность проверить:

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

На данном этапе создается модель доступа к объектам, которая отображает взаимодействие объектов через модель состояний. Модель состояний обращается к данным экземпляра другого объекта во время выполнения действия. Этот вид взаимодействия считается синхронным. Если модель состояний получает событие после того, как действие завершилось, то это взаимодействие - асинхронное.

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

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

Данный метод имеет много общего с методом Буча, реализован в ряде проектов (например, EaseCASE Plus 4.0). Применяется в различных областях (банковские операции, управление летательными аппаратами, оформление кредитных карт и др.) в США, Европе и Японии.

< Лекция 4 || Лекция 5: 12345 || Лекция 6 >
Александр Медов
Александр Медов

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Александр Медов
Александр Медов

Здравствуйте, прошел курс МБА Управление ИТ-проектами и направил документы на получение диплома почтой. Подскажите, сроки получения оного в бумажной форме?

: