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

ПОЛЕЗНОЕ


КАТЕГОРИИ







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





Лекция №1

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

 

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

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



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

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

Проблема учета университетских курсов

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

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

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

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

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

 

Оценки рисков

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

Постановка задачи

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

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

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

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

Резюме

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

Функции системы

 

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

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

Активные субъекты

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

• Только вводить данные в систему;

• только получать информацию из системы;

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

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

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

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

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

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

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

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

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

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

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

 

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

 
   


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

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

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

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

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

Варианты использования (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) задает свойство уни­кальности объекта— даже в том случае, если состояние по­следнего и









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


©2015- 2018 zdamsam.ru Размещенные материалы защищены законодательством РФ.