Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны? |
Методы объектного анализа и построения моделей предметных областей
Альтернативой графической диаграммы перехода состояний является табличная нотация (табл. 4.1 для модели состояний на рис. 4.2).
В таблице каждое состояние представляется строкой, а каждое событие, воздействующее на объект - столбцом. Клетка таблицы перехода состояний - это состояние объекта, если соответствующее столбику событие произойдет, когда объект находился в состоянии, соответствующем строке. При этом допускается, что некоторые комбинации событие/состояние не приведут к изменению состояния экземпляра объекта, они содержат указание "событие игнорируется. При выборе формы представления - диаграмма или таблицы состояний перехода преимущество имеет диаграмма из-за наглядности и определенности действий, тогда как табличная форма служит для фиксации всех возможных комбинаций состояние/событие. Этим обеспечивается полнота и непротиворечивость заданных требований к системе.
А1 -клиент ожидает | А2 - клиент ожидает | A3 - известен клиенту | |
---|---|---|---|
1. Ожидание клиента | 2 | Событие игнорируется | Не может произойти |
2. Ожидание свободного клерка | Событие игнорируется | 3 | Не может произойти |
3. Определение клеерка клиентом | Событие игнорируется | Событие игнорируется | 1 |
Важным принципом объединения объектов и компонентов в систему является наличие у них общих событий, причем чаще всего один из них порождает событие, а другие на него реагируют. На этом принципе базируется способ объединения отдельных объектов и компонентов в систему. Взаимодействие (внешнее и внутреннее) объектов рассматривается через обмен сообщениями для задания определенных событий и данных к ним. Внешний объект посылает сообщение, которое приводит к запуску системы и образованию внешнего события. Ему направляется сообщение о наступлении или отсутствии события.
Поведение отдельного объекта представляется в модели диаграммой перехода в состояния, а поведение системы - в виде схемы взаимодействия отдельных диаграмм, каждая из которых получает название в соответствующем овале (рис. 4.4). Овалы, отображающие отдельные диаграммы перехода состояний, связаны между собою стрелками, на которых задаются сообщения для возбуждения события. На стрелке указывается метка события (например, С1, С2, , С8), а ее направление соответствует направлению передачи сообщения. Внешние объекты обозначаются прямоугольниками с названиями.
С помощью событий, указанных на стрелках данной схемы, инициируются модели состояний 1-5, каждая из которых посылает соответствующее сообщение.
Таким образом, модель состояний представляется диаграммами перехода в состояния, таблицей состояний, описанием действий и событий, изменяющих состояния объектов.
Модель процессов отражает изменения в моделях состояний. Каждое действие определяется в терминах процессов и архивов данных объектов. Т.е. процесс является фундаментальным модулем операции, а архив данных соответствует атрибутам объектов в информационной модели. Процессы действий имеют доступ к данным модели состояний, где они представлены. Для каждого действия модели состояний создается диаграмма процесса. Действия инициируют выполнение событий с помощью функций, которые реализуются в системе и отображаются в соответствующих диаграммах действий. В качестве источников данных для процессов могут выступать:
- атрибуты объектов, которые продолжают существовать после завершения работы системы;
- системные часы;
- таймер;
- данные происходящих событий;
- сообщения от внешних объектов.
Последовательность выполняемых процессов образует поток управления, а каждый процесс образует поток данных.
Для представления потоков данных используют диаграммы действий, правила построения таких диаграмм таковы:
- каждой из диаграмм перехода состояний может отвечать только одна диаграмма действий потоков данных;
- процесс изображается овалом с указанием содержания или названия процесса;
- потоки данных процессов изображаются стрелками, на которых указываются имена данных, передаваемых другому процессу;
- стрелка к овалу процесса указывает на его входные данные, направление от овала - на выходные данные;
- источники данных изображаются прямоугольниками;
- данным, имеющим своим источником архивные объекты, соответствуют потоки с названиями атрибутов объектов, которые передаются потоками;
- потоки данных отмечаются таймером или системными часами (час, минута);
- событие, сообщение о котором получает процесс, изображается стрелкой с названиями данных.
В данном методе различаются следующие процессы общего назначения:
- доступ к архивам;
- подготовка и верификация объектов;
- обработка потоков данных и генерация событий;
- накопление объектов в архиве;
- организация вычислений функций системы.
Потоки обозначаются пунктирными стрелками. Если процесс выполняет проверку определенного условия для передачи управления и входных данных другому процессу, то соответствующий поток изображается пунктирной линией с перечеркиванием. Фрагмент диаграммы действий процесса создания репозитария (типа библиотеки, архива) объектов приведен на рис. 4.5.
К диаграммам действий потоков данных добавляется неформальное описание функций процессов, которые входят в их состав. Для описания подробностей действий процессов нотация не регламентируется.
После завершения описания диаграммы действий потоков данных для всех объектов системы составляется общая таблица процессов, состоящая из следующих колонок:
- идентификатор процесса;
- тип процесса;
- название процесса;
- название состояния, для которого определен процесс;
- название действия состояния.
Таблица дает возможность проверить:
- непротиворечивость названий и идентификаторов процессов;
- полноту определенных событий и соответствующих процессов;
- генерацию события или его обработку соответствующим процессом.
К диаграммам действий потоков данных добавляется неформальное описание функций процессов, которые входят в их состав. Для описания подробностей действий процессов нотация не регламентируется.
После завершения описания диаграммы действий потоков данных для всех объектов системы составляется общая таблица процессов, состоящая из следующих колонок:
- идентификатор процесса;
- тип процесса;
- название процесса;
- название состояния, для которого определен процесс;
- название действия состояния.
Таблица дает возможность проверить:
- непротиворечивость названий и идентификаторов процессов;
- полноту определенных событий и соответствующих процессов;
- генерацию события или его обработку соответствующим процессом.
На данном этапе создается модель доступа к объектам, которая отображает взаимодействие объектов через модель состояний. Модель состояний обращается к данным экземпляра другого объекта во время выполнения действия. Этот вид взаимодействия считается синхронным. Если модель состояний получает событие после того, как действие завершилось, то это взаимодействие - асинхронное.
Результатом процесса моделирования процессов является: модель доступа к данным, диаграмма потоков данных действий, таблица процессов, содержащая процессы и действия над объектами ПрО, описание процессов путем их упорядочения по ID.
Определение архитектуры ПрО.После построения трех моделей, выполняется следующий этап метода - проектирование. На нем проводится разделение ПрО на подсистемы, определение их функций и принципов выполнения этих функций на процессах. В каждую подсистему включаются построенные модели или их фрагменты и соответственно выделенные объекты со всеми характеристиками. Между подсистемами устанавливаются соединительные связи, на которых указываются имена передаваемых данных или участвующих объектов. В результате создается графическое представление архитектуры системы. Преобразование результатов объектно-ориентированного анализа по данному осуществляется в языки С++, Ada и др.
Данный метод имеет много общего с методом Буча, реализован в ряде проектов (например, EaseCASE Plus 4.0). Применяется в различных областях (банковские операции, управление летательными аппаратами, оформление кредитных карт и др.) в США, Европе и Японии.