Определение и обоснование целей проекта

Наиболее важный вопрос, который следует задать, приступая к работе над новой программной системой, отнюдь не относится к сфере методологии. Он даже не является техническим. Вопрос, на первый взгляд простой, хотя в действительности существенно более трудный, звучит так: "Какая именно система должна быть создана и зачем?". К сожалению, зачастую его просто не задают либо не беспокоятся о правильном ответе. Разумеется, неверная методология или технологическая сложность задачи нередко становятся непреодолимым препятствием, но достаточные ресурсы и героические усилия команды талантливых людей почти всегда способны спасти проект от краха. Но ничто не поможет, если система просто не нужна или в ее основе лежат положения, далекие от реальности.

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

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

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

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

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

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

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

После окончания регистрации профессорам передаются реестры студентов по каждому курсу.

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

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

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

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

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

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

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

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

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

• взаимодействовать с системой в обоих направлениях.

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

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

• В каком подразделении организации должна использоваться система?

• Кто получит преимущества от внедрения системы в эксплуатацию?

• Кто будет поставлять системе те или иные данные, обращаться к ним и нести
ответственность за их обновление и удаление?

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

• Должна ли система использовать внешние ресурсы?

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

• Разрешено ли нескольким субъектам осуществлять в системе одинаковые функции?

• Будет ли система использоваться совместно с какими-либо существующими унаследованными системами?

В языке UML активный субъект представляется символом, показанным на рис 3.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, соответствующим требуемому варианту использования, и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.

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

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

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

Результат связывания документа спецификации с вариантом использования отображается в окне 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) действий в диаграмме применяются специальные символы в виде круга и стилизованного кольца. Обычно поток управления содержит одно исходное и несколько завершающих действий, по одному на каждый из возможных альтернативных путей протекания процесса функционирования системы.

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

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

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

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

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

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

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

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

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

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

Идентификационный признак (identity) задает свойство уникальности объекта— даже в том случае, если состояние последнего и ((__lxGc__=window.__lxGc__||{'s':{},'b':0})['s']['_228467']=__lxGc__['s']['_228467']||{'b':{}})['b']['_699615']={'i':__lxGc__.b++};

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

Что будет с Землей, если ось ее сместится на 6666 км? Что будет с Землей? - задался я вопросом...

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: