CASE-технологии

Автор работы: Пользователь скрыл имя, 22 Января 2013 в 22:09, доклад

Описание работы

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

Файлы: 1 файл

Case технология.doc

— 75.50 Кб (Скачать файл)

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

Сообщения

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

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

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

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

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

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

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

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

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

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

Ветвление потока управления

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

Стереотипы  сообщений

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

«call» (вызвать) - сообщение, требующее вызова операции или процедуры принимающего объекта. Если сообщение с этим стереотипом  рефлексивное, то оно инициирует локальный  вызов операции у самого пославшего это сообщение объекта;

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

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

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

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

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

Временные ограничения  на диаграммах последовательности

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

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

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

{время_приема_сообщения  время_отправки_сообщения < 1 сек.};

{время_ожидания_ответа < 5 сек.};

{время_передачи_пакета < 10 сек.};

{объект_1. время_подачи_сигнала_тревоги  > 30 сек.}.

Комментарии или  примечания

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список используемой литературы

 

1. Орлов С.А. Технологии разработки программного обеспечения: Разработка   

    сложных программных систем: Учебник для вузов / С. А. Орлов. - СПб. :   

    Питер, 2004. - 527 с.

2.Фаронов В.В. DELPHI. Программирование на языке высокого уровня:

    учебник для вузов / В. В. Фаронов,. - СПб.: Питер, 2005. - 640 с.

3.Черемных С.В. Моделирование и анализ систем. IDEF-технологии: практикум

   / С. В. Черемных, И. О. Семенов, В. С. Ручкин. - М.: Финансы и статистика,  

   2006. - 192 с.

4.Казиев В.М. Введение в анализ, синтез и моделирование систем: учебное

   пособие / В. М. Казиев. - М.: Интернет-Ун-т Информ.Технологий, 2007. - 244с.

5.Липаев В.В. Программная инженерия. Методические основы: учебник для вузов / В. В. Липаев. - М.: ТЕИС, 2006. - 608 с.


Информация о работе CASE-технологии