Активные субъекты в системе учета университетских курсов


akida-salyafov-i-imamov-hadisa.html
akimov-vadim-mbudo-detskaya-hudozhestvennaya-shkola-imeni-nvovechkina-gnovoshahtinskrostovskaya-oblast-rukovoditel-algurkovskaya.html

В контексте системы учета университетских курсов могут быть получены следую­щие ответы на поставленные выше вопросы.

• Каждому студенту полагается выбрать курсы для изучения.

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

• Служащие деканата обязаны создать каталог курсов и составить индивидуаль­ные расписания работы студентов.

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

• Система учета курсов должна передавать информацию во внешнюю систему
учета студентов.

На основании перечисленных ответов легко выделить следующие категории ак­тивных субъектов, взаимодействующих с системой учета университетских курсов: "студент", "профессор", "сотрудник деканата" и "система учета студентов".

Как создать активный субъект

1.Расположить курсор мыши над элементом Use Case View окна броузера (Browser) и щелкнуть правой кнопкой, чтобы активизировать контекст­ное меню.

2. Выбрать элемент меню New→Actor; дерево,
отображаемое в окне Browser, пополнится элементом New Class, соответствующим но­вому активному субъекту.

3. Выбрать элемент New Class и изменить его
название, введя требуемое имя активного
субъекта.

Документирование активных субъектов

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

• Студент — лицо, зарегистрированное в качестве слушателя университетских курсов;

• Профессор — лицо, наделенное полномочиями вести занятия в университете;

• Сотрудник деканата—служащий, ответственный за функционирование системы учета университетских курсов;

• Система учета студентов — внешняя система, обеспечивающая хранение ин­формации о студентах.

Как документировать активный субъект

Если окно документирования (Documentation) не отображается, открыть его, активизировав элемент меню View →Documentation.

В окне Browser выбрать элемент дерева, соответствующий требуемому активному субъекту.

Разместить курсор в окне Documentation и ввести текстовое описание активного субъекта.

Варианты использования

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



Помощь в выборе вариантов использования системы окажут ответы на следую­щие вопросы.

• Какие задачи решает каждый активный субъект?

• Способен ли тот или иной субъект создавать, сохранять, изменять, удалять или
считывать фрагменты данных в контексте системы?

• Какие варианты использования гарантируют выполнение указанных выше функций обработки данных?

• Должны ли активные субъекты сообщать системе о каких либо - непредвиденных внешних обстоятельствах?

• Имеет ли субъект право получать информацию об определенных событиях, происходящих в системе?

• Какие варианты использования связаны с поддержкой и администрированием системы?

• Удовлетворяются ли вариантами использования все функциональные требова­ния, предъявляемые к системе?

В языке UML вариант использования представляется символом, показанным на рис. 3.4.


Рис.3.4 Обозначение варианта использования в UML

Выбор вариантов использования

В течение длительного времени продолжается дискуссия о том, какие именно ва­рианты использования следует считать "хорошими". Одна из проблем связана с при­емлемостью уровня детализации вариантов использования, т.е. с тем, насколько об­ширными (или узкими) они должны быть. Однозначного ответа, однако, не существу­ет. Мне по нраву следующее правило:

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

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

Еще одна проблема состоит в том, что делать с функциями, которые являются различ­ными, но выглядят как родственные. Например, в обязанность сотрудника деканата входит добавление, модификация и удаление данных о курсах. Что это, три варианта исполь­зования системы или все-таки один? И вновь я остановила бы выбор на одном варианте, ведение каталога курсов", поскольку все функции выполняются одним активным субъек­том "сотрудник деканата" и затрагивают одни и те же системные сущности (курсы).

Варианты использования системы учета университетских курсов

Система обязана удовлетворять следующим требованиям.

• Активный субъект "студент" регистрирует курсы, которые он намеревается прослушать.

• По завершении регистрации информация о студенте передается во внешнюю систему учета студентов.

• Субъект "профессор" использует систему для выбора курсов, которые он хо­тел бы преподавать в течение семестра, и для получения реестров студентов по каждому курсу.

• Субъект "сотрудник деканата" несет ответственность за ведение и опубликование каталога курсов на семестр и сохранение всей информации о расписаниях, студентах и профессорах.

Варианты использования системы, идентифицированные на основе названных требований, перечислены ниже:

Þ регистрация курсов студентом;

Þ выбор курсов профессором;

Þ получение реестра студентов по курсу;

Þ сохранение информации о курсах;

Þ сохранение информации о профессорах;

Þ сохранение информации о студентах;

Þ ведение каталога курсов.

Поток событий для варианта использования

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

• Как и когда вариант использования инициируется и завершается?

• Каким образом активные субъекты взаимодействуют с системой?

• Какие данные затрагиваются вариантом использования?

• Что представляет собой нормальная последовательность событий, предусмат­риваемых вариантом использования?

• Существуют ли альтернативные потоки событий для нештатных ситуаций?

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

Описание потока событий для варианта использования системы содержится в до­кументе вида Use Case Specification ("спецификация варианта использования"). Для создания подобного документа в каждом проекте должен применяться некий стандартный шаблон. Мы прибегнем к помощи шаблона, заимствованного из регламента Rational Unified Process.

1.0. Наименование варианта использования

1.1. Краткое описание

2.0.Потоки событий

2.1.Основной поток

2.2.Альтернативные потоки
2.2.x. Альтернативный поток х>
3.0. Специальные требования
З.х.
4.0. Предусловия

4.x

5.0. Постусловия

5.x

6.0. Дополнительные замечания

6.x Дополнительное замечание х>

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

Спецификация варианта использования "выбор курсов профессором"

1.0 Наименование варианта использования: "выбор курсов профессором".

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

Потоки событий

Основной поток

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

Если выбрана опция "добавление", система отображает окно с палями ввода наименования и номера курса. Профессор вводит наименование и номер курса (при задании неверной информации выполняется поток 2.2.3). Система воспроизводит текст с предложением на ведение курса (или на­именование курса не может быть отображено, выполняется поток 2.2.4), и профессор подтверждает свой выбор. Система связывает текущий субъект "профессор" с указанным курсом (если связь не может быть создана, выполняется поток 2.2.5). Вариант использования активизируется сначала.

Если выбрана опция "удаление", система отображает окно с полями ввода наименования и номера ранее предложенного профессором курса. Профессор вводит наименование и номер кур­са (при задании неверной информации выполняется поток 2.2.3). Система удаляет связь между курсом и текущим субъектом "профессор" (если связь удалить нельзя, выполняется поток 2.2.6). Вариант использования активизируется сначала.

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

Если выбрана опция "печать", система посылает на принтер расписание занятий, прово­димых текущим субъектом "профессор" (если расписание не может быть распечатано, выпол­няется поток 2.2.8). Вариант использования активизируется сначала.

Если выбрана опция "выход", выполнение функций, предусмотренных вариантом использо­вания системы, завершается.

Альтернативные потоки

2.2.1.Неверный пароль: введен неверный пароль; субъекту предоставляется возможность
повторить ввод или завершить вариант использования.

2.2.2.Неверный семестр: система сообщает субъекту о неверном вводе информации о семе­стре и предлагает повторить операцию или завершить вариант использования.

2.2.3.Неверная комбинация наименования и номера курса: система сообщает субъекту
о неверном вводе информации о наименовании и номере курса и предлагает повторить опера­цию или завершить вариант использования.

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

2.2.5. Ошибка создания связи между субъектом и выбранным им курсом:информация сохранена, система создаст связь позже; вариант использования активизируется сначала.

2.2.6. Ошибка удаления связи между субъектом и выбранным им курсом:информация сохранена, система удалить связь позже; вариант использования активизируется сначала.

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

2.2.8. Ошибка печати расписания занятий:система сообщает субъекту о том, что в данный момент функция не доступна; вариант использования активизируется сначала.

3.0 Специальные требования:специальные требования не определены.

Предусловия

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

5.0. Постусловия: постусловия не определены.

6.0. Дополнительные значения: дополнительных замечаний нет.

Текст спецификации сохраняется в документе, внешнем по отношению к инструментальной системе Rational Rose, и ассоциируется с вариантом использования посредством связи.

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

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

2. Выбрать элемент меню Open Specification.

3. Перейти на вкладку Files диалогового окна Use Case Specification.

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

5. Выбрать элемент меню Insert file.

6. С помощью средств навигации диалогового окна Открытие файла проследовать к нужной папке и выбрать требуемый файл.

7. Щелкнуть на кнопке Открыть.

8. Щелкнуть на кнопке ОК окна Use Case Specification.

Результат связывания документа спецификации с вариантом использования отображается в окне Browser.

Документ вида Use Case Specification может быть создан также в рамках проекта форма Rational Requisite Pro, а затем связан с вариантом использования в модели Rational Rose. Чтобы присоединить документ Requisite Pro к варианту использования, первым делом надлежит ассоциировать модель Rational Rose с проектом Requisite Pro.

СВЯЗИ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

Варианты использования могут соединяться связями зависимости (dependency relationships) двух типов –включающими (inclusive) и расширяющими (extensive). Многими вариантами использования нередко охватывается одно и то же подмножество функций системы, которое уместно вынести в отдельный вариант, а не включать в каждый базовый вариант. Включающей связью соединяются определенный вариант использования и любой другой вариант, который предполагает выполнение тех же функций. Например, каждый из вариантов использования системы учета университетских курсов предусматривает процедуру регистрации пользователя. Подобные функции целесообразно представить в виде отдельного одноименного варианта использования, к которому следует обращаться в модели с помощью стрелки, направленной от базового варианта к «включаемому».

Расширяющие связи применяются для описания

Þ множеств необязательных функций;

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

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

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

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

ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

Диаграмма вариантов использования (use case diagram) –это графическое представление подмножеств активных субъектов, взаимодействующих с системой посредством тех или иных вариантов ее использования. При проектировании любой системы обычно конструируется основная диаграмма (Main Use Case Diagram), представляющая множество пользователей (активных субъектов) и ключевые функции (варианты использования) системы. При необходимости создаются и дополнительные диаграммы. Вот некоторые типичные примеры:

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

Þ диаграмма, изображающая варианты использования, подлежащие последовательной реализации;

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

Диаграммы действий

На рассматриваемой стадии процесса разработки системы нередко создаются и диаграммы действий(activities diagrams), отображающие динамические характери­стики системы. Диаграммы действий воспроизводят поток функций управления, по­казывают, какие ветви процесса могут выполняться параллельно, и определяют аль­тернативные пути достижения целей. Диаграммы действий, конструируемые на на­чальных фазах жизненного цикла системы, представляют потоки, которые охватывают несколько вариантов использования или протекают на уровне опреде­ленного варианта. Позже, по мере детализации проекта, создаются и диаграммы дей­ствий, иллюстрирующие особенности реализации отдельных операций.

Элементами диаграммы действий служат собственно действия (activities), переходи (transitions) от одного действия к другому, точки принятия решений (decision points) и полосы синхронизации (synchronization bars). В UML для описания действия, перехода, точ­ки принятия решения и полосы синхронизации применяются соответственно прямо­угольник с округленными углами, направленная стрелка, ромб и отрезок утолщенной прямой (горизонтальный или вертикальный).

Действия

Действие (activity) описывает некоторый фрагмент поведения системы в контексте потока функций управления.

Переходы

Элемент перехода (transition) применяется в диаграмме действий с целью обозна­чения направления передачи управления от одного действия к другому. Функция пе­рехода обычно активизируется по завершении действия-источника.

Точки принятия решений

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

Полосы синхронизации.

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

Зоны

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

Исходные и завершающее действия.

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

РЕЗЮМЕ

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

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

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

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

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

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

Лекция №2

Что такое объект

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

Объект — это понятие, абстракция или нечто с явно оговоренными границами, смыслом и назначением контексте программного приложения. Каждый объект сис­темы обладает тремя характеристиками — состоянием, поведением и идентификаци­онным признаком.

Характеристики объекта

Состояние (state) объекта— это одно из возможных сочетаний условий его сущест­вования. Состояние объекта определяется набором свойств-атрибутов (attributes) и связей c другими объектами и со временем обычно способно изменяться. Напри­мер, объект, представляющий предложение на ведение курса, поданное определен­ным активным субъектом "профессор" системы учета университетских курсов, может пребывать в одном из двух состояний — "открыт" и "закрыт". Пока количество студен­тов, выбравших курс, меньше 10, объект остается в состоянии "открыт". Как только на курс регистрируется десятый студент, объект "закрывается".

Характеристика поведения (behavior) охватывает функциональную сторону жизни объ­екта, определяет его реакцию на запросы со стороны других объектов и реализуется в виде набора операций. В системе учета университетских курсов поведение объекта предложе­ния на ведение курса определяется двумя основными функциями — "зарегистрировать сту­дента" и "отменить регистрацию студента".

Идентификационный признак (identity) задает свойство уни­кальности объекта— даже в том случае, если состояние по­следнего идентично состоянию других объектов. В системе учета курсов, например, могут существовать два объекта -"алгебра 101, раздел!" и "алгебра 101, раздел 2". Хотя оба

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

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

Понятие класса

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

• атрибуты — "место проведения занятий", "время проведения занятий",
"наименование курса", "номер курса", "номер предложения";

• функции — "назначить место проведения занятий", "назначить время проведет
занятий", "зарегистрировать студента", "отменить регистрацию студента".

На роль экземпляров класса "предложение курса" могли бы претендовать такие объ­екты, как, скажем, "алгебра 101, раздел 1" и "алгебра 101, раздел 2", — каждому из них со­ответствуют определенный набор атрибутов и общие функциональные характеристики. Правильно сконструированный класс должен представлять одну и только одну аб­стракцию. Например, класс, предлагающий возможности сохранения информации о студенте наряду с функциями регистрации курсов, пройденных студентом на про­тяжении всего времени обучения, нельзя считать удачным, поскольку он охватывает две различные группы операций. Поэтому уместно было бы "расщепить" такой класс на два — "студент" и "курсы, пройденные студентом".

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

Зачастую бывает сложно провести черту между объектами и классами. Почему "алгебра 101, раздел!"— это объект, а не класс? Что отличает его от сущности "алгебра 101, раздел 2"? Ответы на подобные вопросы, как правило, довольно субъек­тивны. Впрочем, достаточно небольшого интеллектуального усилия, чтобы понять — структура и поведение указанных сущностей одинаковы. Речь идет о различных пред­ложениях на ведение курсов. Помимо того, нетрудно предугадать, что в системе учета университетских курсов могут существовать и другие схожие объекты вида "музыка 101, раздел 1", "история 101, раздел 1", "история 101, раздел 2" и т.п. Все это естественным образом подводит нас к решению о создании класса Предложение Курса.

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

Как создать класс

1. Расположить курсор мыши над элементом Logical View окна Browser
и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.

2. Выбрать элемент меню New=>Class; дерево, отображаемое в окне Browser,
пополнится элементом NewClass, соответствующим новому классу.

3. Выбрать элемент NewClass и изменить его название, введя требуемое
имя класса.

Стереотипы и классы

Прежде мы уже говорили о применении стереотипов при создании связей в диа­граммах вариантов использования. Классам также отвечают определенные стереоти­пы, позволяющие создавать новые разновидности элементов моделируемой системы. К числу наиболее употребительных "стандартных" стереотипов классов относятся entity ("сущность"), boundary ("граница"), control ("управление"), utility("прикладной класс") и exception ("исключение").

На диаграммах названия стереотипов заключаются в угловые кавычки («») и рас­полагаются над именами классов. Система Rational Rose позволяет ассоциировать со стереотипом определенную пиктограмму или выделять его тем или иным цветом. Примеры пиктограмм, предусмотренных в регламенте Rational Unified Process для обозначения стереотипов entity, boundary и control, показаны на рис. 4.4. Здесь же со­держится образец символа класса, соответствующего стереотипу exception.

Как "находить" классы

Строгой инструкции, которая предписывала бы способы отыскания абстракций, под­ходящих на роль классов, просто нет. Гради Буч (Grady Booch) по этому поводу однажды воскликнул: "Гм–м, трудное дельце!" В Rational Unified Process для разработки классов мо­делируемой системы предлагается обращать внимание на стереотипы классов сущностей, границ и управления. Указанное множество стереотипов позволяет аналитику и дизай­неру размежевать уровни предметной области, представления и управления системой.

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

Классы сущностей

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

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

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

Классы границ

Классы границ (boundary classes) обслуживают процессы взаимодействия между системой и ее окружением, обеспечивая интерфейсы для пользователей и сторонних систем (т.е. активных субъектов). Такие классы образуют часть системы, которая не­посредственно "общается" с внешним миром.

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

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

Классы управления

Классы управления (control classes) находят применение при реализации характери­стик поведения системы, присущих одному или нескольким вариантам использова­ния, и координируют события, возникающие по мере функционирования системы в рамках этих вариантов. Класс управления можно воспринимать как абстракцию, отображающую динамику варианта использования системы. Классы управления обычно тесно "привязаны" к особенностям конкретного приложения.

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

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




aktualnie-problemi-nauki-administrativnogo-prava.html
aktualnie-problemi-postroeniya-v-rossii-informacionnogo-obshestva.html
aktualnie-problemi-povisheniya-effektivnosti-gosudarstvennogo-finansovogo-kontrolya.html
aktualnie-problemi-pravovogo-rezhima.html
aktualnie-problemi-prokurorskoj-dejtelnosti.html
ч     PR.RU™