RUP (Rational Unified Process)

 

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

К счастью, в этот раз случилось иначе. Когда обнаружилось, что Гради Буч, Айвар Джекобсон и Джеймс Рамбо (в русскоязычной литературе также нередко встречается написание его фамилии как "Румбах") работают над одной проблемой, вместо конкуренции они объединили усилия и начали совместную работу в компании Rational Software. В результате на свет явились два замечательных продукта: Унифицированный Процесс RUP, Rational Unified Process) и Унифицированный Язык Моделирования (UML, Unified Modeling Language). Помимо них, фирмой Rational выпущен также интегрированный продукт под названием Rose, назначение которого служить инструментальным средством для реализации RUP, однако он в данном классе не единственный и, пожалуй, не лучший, так что основное внимание в дальнейшем будет уделено двум перечисленным продуктам.

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

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

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

 

Примечание. Хотя технология RUP разрекламирована авторами как сквозной цикл проектирования, от постановки задачи до готового продукта, тем не менее она нередко (и на мой взгляд, вполне справедливо) критикуется за слабые инструментальные средства для системного анализа, который должен предшествовать разработке спецификаций. Помимо UML, имеются и другие нотации (IDEF0, IDEF3, DFD), которые намного выразительнее при функциональном моделировании, моделировании бизнес-процессов, документооборота, потоков данных и пр. Использование этих нотаций и соответствующего инструментария (например, AllFusion Process Modeler фирмы Computer Associates) позволяет более качественно провести системный анализ задачи и тем самым облегчить дальнейший процесс проектирования. Однако данная статья, несмотря на обзорный характер, все же ориентирована в первую очередь на технологическое обеспечение проектирования нового клубного форума. Поскольку эта задача довольно тривиальна в функциональном плане, в данном случае представляется возможным обойтись без строгого системного анализа, поэтому в целях экономии времени как автора, так и читающих данную статью разработчиков данная тем будет опущена, несмотря на безусловный интерес, который она представляет. Возможно, мы еще вернемся к этому разговору при подходящем случае.

 

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

 

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

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

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

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

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

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

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

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

 

⇐ Предыдущая12345678Следующая ⇒

Поделиться: