Типичные приемы моделирования

Введение

Предположим, что вы получили по почте загадочное устройство, с одной стороны которого находятся несколько кнопок и маленький жидкокристаллический дисплей. Помимо этого, в нем нет ничего примечательного, и у вас нет даже наме-ка на то, как его использовать. Можно, конечно, использовать метод проб и ошибок: произвольно нажимать на кнопки и смотреть, что получится, но таким путем на изучение устройства вам придется потратить огромное количество времени.

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

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

Рис. 17.1 Диаграмма прецедентов

Термины и понятия

Диаграммой прецедентов, или использования (Use case diagram), называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения между ними.

Общие свойства

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

Содержание

Диаграммы прецедентов обычно включают в себя:

· прецеденты (см. главу 16);

· актеры (см. главу 16);

· отношения зависимости, обобщения и ассоциации (см. главы 5 и 10).

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

Иногда в диаграммы прецедентов помещают пакеты (см. главу 12), применяемые для группирования элементов модели в более крупные блоки, а в ряде случаев и экземпляры (см. главу 13) прецедентов, особенно если надо визуализировать конкретную исполняемую систему.

Типичные примеры применения

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

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

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

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

Контекст системы

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

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

Моделирование контекста системы состоит из следующих шагов:

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

2. Организуйте похожих актеров с помощью отношений обобщения/специа лизации.

3. Введите стереотипы для каждого актера, если это облегчает понимание.

4. Поместите актеров на диаграмму прецедентов и определите способы их свя зи с прецедентами системы.

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

Рис. 17.2 Моделирование контекста системы

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

Требования к системе

Требование (Requirement) - это особенность проекта, свойство или поведение системы. Приступая к сбору требований, вы как бы описываете условия контракта, заключаемого между системой и сущностями вне нее, в котором декларируется, что система должна делать. При этом, как правило, вас заботит не то, как именно система будет выполнять поставленные задачи, а только то, что она будет делать. Хорошо спроектированная система должна полностью выполнять все требования, причем делать это предсказуемо и надежно. Ее создание начинается с соглашения о том, каково ее назначение, хотя в ходе разработки понимание требований будет постепенно изменяться. Аналогично при работе с готовой системой понимание того, как она себя ведет, имеет принципиальное значение для ее правильного использования.

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

Моделирование требований к системе производится следующим образом:

1. Установите контекст системы, идентифицировав окружающие ее актеры.

2. Для каждого актера рассмотрите поведение, которого он ожидает или требу ет от системы.

3. Поименуйте эти общие варианты поведения как прецеденты.

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

5. Смоделируйте эти прецеденты, актеры и отношения между ними на диа грамме прецедентов.

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

Рис. 17.3 расширяет предыдущую диаграмму. Хотя отношения между актерами и прецедентами на ней опущены, но присутствуют дополнительные прецеденты, которые описывают важные, пусть и невидимые для обычного пользователя, элементы поведения системы. Эта диаграмма удобна, поскольку дает возможность пользователям, экспертам и разработчикам совместно визуализировать, специфицировать, конструировать и документировать свои решения относительно функциональных требований к системе. Например, прецедент Обнаружение фальшивых карточек описывает поведение, важное как для Торговых предприятий, так и для Субсидирующих финансовых институтов. Другой прецедент - Отчет о состоянии счета - также описывает поведение, требуемое от системы различными организациями в своих контекстах.

Рис. 17.3 Моделирование требований к системе

Требование, моделируемое прецедентом Управление сбоями в сети, немного отличается от остальных, поскольку представляет вспомогательное поведение системы, необходимое, чтобы гарантировать надежное и непрерывное функционирование (см. главу 23).

Такая же методика применима и при моделировании требований к подсистеме (см. главу 31).

Советы

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

Хорошо структурированная диаграмма прецедентов обладает следующими свойствами:

· акцентирует внимание только на одном аспекте статического вида системы с точки зрения прецедентов;

· содержит только такие прецеденты и актеров, которые важны для понимания этого аспекта;

· содержит только такие детали, которые соответствуют данному уровню абстракции; следует показывать только те дополнения (например, точки расширения), которые необходимы для понимания системы;

· не настолько лаконична, чтобы ввести читателя в заблуждение относительно важной семантики.

При изображении диаграммы прецедентов руководствуйтесь следующими принципами:

· дайте ей имя, соответствующее назначению;

· расположите элементы так, чтобы свести к минимуму число пересечений;

· пространственно организуйте элементы так, чтобы семантически близкие сущности физически располагались рядом;

· используйте примечания и цвет, чтобы привлечь внимание читателя к важным особенностям диаграммы;

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

Предисловие

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

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

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

При всем при том использование самого мощного и выразительного языка еще не дает гарантии успеха: на C# при должном старании можно написать не менее запутанную программу, чем на Fortran IV с его бесконечными метками и переходами GOTO. Все эти блестящие инструменты бесполезны в руках человека, который не обучен ими владеть (и при этом особо не жаждет научиться). Много ли, к примеру, вы видели фрезеровщиков-самоучек? Лично я — нет, поскольку к станку не допустят человека, не прошедшего должное профессиональное обучение и не получившего соответствующее удостоверение. В программировании, к сожалению, на самотек обучение ставится гораздо чаще. То ли само ремесло кажется проще фрезеровки, то ли предполагаемый ущерб меньше: ни станок не запорет, ни сам не покалечится, а кривую программу и стереть недолго.

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

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

Единственная известная мне панацея от всех этих напастей — это работа над программой в соответствии со спецификациями. Во-первых, это практически единственный способ как-то обуздать полет фантазии заказчика, который способен сгенерировать десяток новых идей за то время, за которое вы едва ли способны реализовать одну. Помнится, в давние времена один из моих коллег был вынужден брать у начальника очередное задание под роспись, причем в момент приемки начальник делал круглые глаза и искренне изумлялся, неужели это действительно он поставил эту задачу и не подделана ли его подпись какими-то проходимцами. Только это и спасало коллегу от многократных бестолковых переделок одного и того же, а начальника постепенно приучило думать головой, выдавая задание (тоже весьма ценный навык, кстати).

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

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

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

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

Спецификации

Собственно, это достаточно широкое и расплывчатое понятие. Например, в Большой советской энциклопедии читаем: Спецификация (позднелатинского specificatio, от лат. species — вид, разновидность и facio — делаю), 1) определение и перечень специфических особенностей, уточнённая классификация чего-либо (дальнейшее, увы, к делу не относится). В дальнейшем мы будем употреблять это слово именно в данном смысле — как перечень всех свойств и функций некоего продукта, который мы хотим получить в результате разработки.

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

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

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

С чего начинается проект

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

Для выбора отправной точки процесса проектирования зададим себе вопрос: а для чего нужны программы вообще и наша в частности? Очевидно, заказывая разработку программы, заказчик предполагает, что она будет выполнять определенные функции, результат которых представляет для него определенный интерес. Таким образом, приходим к выводу, что первична в программе именно функциональность. Как программа будет устроена внутри, каким образом предполагается реализовать эти функции — заказчика, как правило, не должно волновать. (На самом деле требования заказчика могут также включать в себя эргономичность человеко-машинного интерфейса, но эти вопросы обычно решаются в рабочем порядке и в техническом задании на разработку жестко не фиксируются).

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

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

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

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

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

Актор

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

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

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

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

Прецедент

Понятие прецедента (в терминологии UML — Use Case) является очень важным в RUP, одним из центральных. Собственно, сам Унифицированный Процесс построен на основе прецедентов и управляется ими.Кратко определить прецедент можно следующим образом: это последовательность действий, которые актор совершает над системой для достижения определенного результата. Фактически он представляет с собой сценарий взаимодействия пользователя или управляемого объекта с системой, имеющий самостоятельное значение.

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

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

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

Диаграмма прецедентов

Для описания взаимодействия акторов и прецедентов, а также взаимоотношений прецедентов строится диаграмма прецедентов (в терминологии UML — Use Case Diagram).

Актор на диаграмме изображается значком в виде человечка, под которым указано его имя:

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

Прецедент изображается в виде эллипса, в котором содержится имя прецедента:

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

На диаграмме прецеденты обычно располагаются в середине листа, а акторы — слева. В случае, если прецедент активирует один актор, а результат выполнения достается другому, актор-получатель располагается справа:

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

В приведенном примере Actor1 инициирует прецеденты UseCase1 и UseCase2, и он же получает их результат. Actor2 инициирует прецеденты UseCase3, UseCase4 и UseCase5, однако результат выполнения UseCase5 получает Actor3.

Сценарий прецедента

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

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

Например, сценарий публикации статьи мог бы выглядеть примерно таким образом:

1. Заполнить сведения об авторе.

2. Заполнить аннотацию.

3. Скопировать текст статьи в соответствующее окно.

4. Выполнить предварительный просмотр статьи.

5. Подтвердить публикацию.

При желании каждый пункт можно расширить двумя-тремя абзацами. Например, в п. 2 можно указать требования к объему и содержанию аннотации. Однако не следует вдаваться в излишние подробности, поскольку текстовое описание сценария на данном этапе все равно имеет временный характер.

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

Включение

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

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

Графически включение прецедента выглядит следующим образом:

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

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

Расширение

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

На данной диаграмме прецедент "Edit article" расширяет прецедент "Publish article". Смысл этой конструкции заключается в следующем: при определенном условии, не отраженном на данной диаграмме (а именно — автор недоволен содержимым статьи и не намерен выставлять ее на общее обозрение), процесс публикации приостанавливается, и автор производит редактирование.

Обобщение

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

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

Примечание. В ныне действующем стандарте UML 1.4 для отношения обобщения предусмотрен соответствующий стереотип Generalization. Однако по какой-то причине он отсутствует в палитре инструментов Microsoft Visio for Enterprise Architect (10.0.525), которым я пользовался при подготовке иллюстраций к данной статье. Поэтому пришлось пользоваться стрелкой расширения, подчеркивая вертикальным расположением прецедентов, что речь идет именно об обобщении, а не расширении базового прецедента.

Заключение

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

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

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

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

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

· Базовыми элементами диаграммы вариантов использования являются эктор и вариант использования.

· Эктор(актер)(Actor) – согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними.

· Вариант использования (Use Case), или прецедент, – внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с экторами.

· Таким образом, диаграмма прецедентов – это графическое представление экторов и прецедентов и их взаимодействия в системе.

· Экторы. Экторы (актеры) – это роли, исполняемыми сущностями, непосредственно взаимодействующими с системой.

· В литературе очень часто вместо термина «эктор» используется термин «актер», который мы и будем использовать в дальнейшем изложении.

· В языке UML актеры изображаются в виде пиктограммы «анимационный человечек» или в виде пиктограммы класса (рис. 5.6). Актеры представляют собой роли, а не конкретных людей или наименования работ. Актерами могут быть как люди (пользователи данной системы), так и внешние системы, которым необходима некоторая информация от данной системы. Большинство разработчиков моделей предпочитают использовать пиктограммы «человечек» для тех ролей, которые будут исполняться людьми, а пиктограммы класса – для тех ролей, которые будут играть другие системы.

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

· Рис. 5.6. Варианты изображения актера

· на диаграмме прецедентов

· Можно выделить три основных типа актеров:

· – пользователи системы;

· – другие системы, взаимодействующие с данной;

· – время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе.

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

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

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

· Прецеденты.В книге «UML 2 и унифицированный процесс. Практический объектно-ориентированный анализ и проектирование» Дж. Арлоу и А. Нейштадт определяют прецедент как описание последовательности действий, которые выполняют система, подсистема или класс.

· Варианты использования в контексте процесса управления требованиями к системе согласно А. Коберну (Коберн А. Современные методы описания функциональных требований к системам : пер. с англ. М. : Лори, 2002. 263 c.) трактуются следующим образом:

· – вариант использования фиксирует соглашение между участниками проекта относительно поведения системы;

· – вариант использования описывает поведение системы при различных условиях, когда система отвечает на запрос одного из участников, называемого основным действующим лицом;

· – основное действующее лицо инициирует взаимодействие с системой, чтобы добиться некоторой цели. Система отвечает, соблюдая интересы всех участников.

· Пиктограмма прецедента представляет собой овал (рис. 5.7). Имя прецедента, как правило, записывается внутри овала, хотя может указываться и под ним.

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

· Рис. 5.7. Пиктограмма прецедента

· ОтношенияОтношения – семантические (значимые) связи между элементами модели.

· На диаграмме прецедентов могут использоваться следующие типы отношений:

· – ассоциация (Аassociation) – для отношений между актерами и прецедентами;

· – включение (Include) и расширение (Еxtend) – для отношений между прецедентами и прецедентами;

· – обобщение (Generalization) – для отношений между актерами и актерами и прецедентами и прецедентами.

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

· Простая ассоциация отражается линией без стрелки, проведенной между актером и вариантом использования (рис. 5.8).

· Рис. 5.8. Отношение простой ассоциации

· Направленная ассоциация обозначается линией со стрелкой. Связь может быть как от актера к прецеденту, так и наоборот. Направление связи показывает, кто является ее инициатором: актер или прецедент (рис. 5.9).

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

· Пример отношения включения. Пусть при решении вопроса о предоставлении кредита клиенту в поведение базового прецедента «Предоставление кредита в банке» включается обязательный прецедент «Проверка платежеспособности клиента» (рис. 5.10). Отношение включения отображается пунктирной стрелкой, направленной от основного прецедента к включаемому прецеденту.

· Рис. 5.9 Отношения направленной ассоциации на диаграмме прецедентов банкомата

· Рис. 5.10. Отношение включения

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

· Отношение расширения применяется при описании изменений
в нормальном поведении системы. Оно позволяет прецеденту использовать функциональные возможности другого прецедента только при необходимости. Например, при решении вопроса о предоставлении кредита клиенту банка базовый вариант использования «Предоставление кредита в банке» может быть расширен посредством необязательного расширяющего прецедента «Предоставление налоговых льгот» (рис. 5.11). Отношение включения отображается пунктирной стрелкой, направленной от расширяющего прецедента к основному прецеденту.

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

· Рис. 5.11. Отношение расширения

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

· Графически отношение обобщения обозначается сплошной линией со стрелкой в виде незакрашенного треугольника, которая указывает на родительский вариант использования (рис. 5.12). Эта линия имеет специальное название – стрелка «обобщение».

· Рис. 5.12. Отношение обобщения между прецедентами

· Отношениеобобщения между актерами используется, когда несколько актеров могут обладать общими свойствами и поведением, т. е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщенияс другим, возможно, абстрактным актером, который моделирует соответствующую общность ролей (рис. 5.13).

Служащий с почасовой оплатой

Служащий

Временный служащий

Служащий на окладе

· Рис. 5.13. Отношение обобщения между актерами

Выводы

· Модель прецедентов позволяет описать систему на концептуальном уровне.

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

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

· Эктор - это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью.

· Прецеденты (как и экторы) могут быть генерализованы, т. е. наследовать и дополнять свойства своих предков.

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

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

· Сценарии специфицируют прецеденты, а диаграммы взаимодействий визуализируют сценарии.

Контрольные вопросы

· Что такое нефункциональные требования? Как они отображаются на диаграммах прецедентов?

· Какие способы изображения экторов вы знаете?

· В какие отношения могут вступать экторы между собой?

· В чем состоит смысл отношений включения и расширения?

· Что такое точка расширения?

· Перечислите известные вам причины использования прецедентов.

· Как прецеденты применяют в прямом и обратном проектировании?

Предложена методика проектирования прикладных приложений на платформе «1С:Предприятие 8» с использованием языка UML, которая апробирована автором в учебном процессе в рамках дипломного проектирования в течение 4 лет. Унифицированный язык моделирования (Unified Modeling Language) является в настоящее время фактически промышленным стандартом языка описания, визуализации и документирования объектно-ориентированных систем и бизнес-процессов с ориентацией на дальнейшую реализацию в виде программного обеспечения. Объектная ориентированность технологической платформы системы «1С:Предприятие» позволяет эффективно использовать для проектирования предметно-ориентированных прикладных приложений язык UML.

Проектирование прикладной конфигурации с использованием языка UML можно представить как процесс поуровневого спуска от исходного концептуального представления к объектной модели прикладных объектов конфигурации. Сначала для спецификации функционального назначения системы строится общая концептуальная модель прикладной конфигурации в виде диаграммы прецедентов (Use case diagram). На рис. 1 представлен пример диаграммы прецедентов, описывающей набор функциональных сервисов автоматизированной системы налогового бюджетирования (АСНБ) [1].

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

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

Рис. 1. Диаграмма прецедентов системы АСНБ

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

Для отражения наследования предопределенных атрибутов и процедур прототипа конкретными прикладными объектами на диаграмме может быть использовано отношение обобщения (рис. 2). Например, отношение обобщения, связывающее справочник «СтатьиБюджетов» с соответствующим прототипом, отражает наследование структурой этого справочника предопределенных реквизитов с типами, указанными по умолчанию. Для справочника «РаходыБудущихПериодов» реквизит «Код» переопределен. Механизм наследования предопределенных процедур графически на диаграмме классов также отражается отношением обобщения. Например, для справочника «СтатьиБюджета» определены процедуры ПередЗаписью() и ПередУдалением(). Это свидетельствует о том, что для этого конкретного справочника необходима обработка указанных событий.

Рис. 2. Использование отношения обобщения для отражения механизма наследования

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

Таким образом, рассмотрены особенности использования графической нотации UML для визуализации, специфицирования, конструирования и документирования процесса разработки прикладных приложений на платформе «1С:Предприятие». Описанная методика позволяет разработать модель прикладной системы в терминах объектно-ориентированной технологической платформы «1С:Предприятие», которая является основой для построения конфигурации в среде «1C:Предприятие».