Прецеденты в спецификации программ

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структурное программирование

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

К сильным сторонам структурного подхода можно отнести:

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


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

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

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.

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

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

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

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

* Заполнить сведения об авторе.
* Заполнить аннотацию.
* Скопировать текст статьи в соответствующее окно.
* Выполнить предварительный просмотр статьи.
* Подтвердить публикацию.


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

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

Структурирование модели прецедентов

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

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

Включение

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

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

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



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

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

Расширение

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



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

Обобщение

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



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

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

Инструментарий построения диаграмм

Для работы с диаграммами UML в настоящее время имеется целый ряд инструментов, от примитивных "рисовалок" уровня чуть ли не Paintbrush до серьезных сложных пакетов сквозного проектирования программных комплексов с поддержкой моделей COM и CORBA.

Лично я использовал в работе два продукта: Microsoft Visio for Enterprise Architect и AllFusion Component Modeler от Computer Associates. Первый продукт достаточно прост в использовании, однако его функциональность довольно ограничена. К его достоинствам можно отнести неплохую интеграцию с Microsoft Visual Studio .NET, в частности, возможность reverse engineering - построение диаграмм UML по тексту программы, а также ограниченную возможность генерации кода по диаграммам.

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

Имеются и другие продукты, заслуживающие упоминания, в частности, Rose фирмы Rational. Однако отсутствие адекватных средств системного анализа, а также поддержки языка C# на момент начала моей работы с UML предопределило выбор в пользу AllFusion. Возможно, ситуация с тех пор изменилась.

Заключение

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

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

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

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

Литература

* Скотт, Кендалл. Унифицированный процесс. Основные концепции.: Пер. с англ. - М.: Издательский дом Вильямс, 2002.
* Скотт, Кендалл. UML. Основные концепции.: Пер. с англ. М.: Издательский дом Вильямс, 2002.
* Шмуллер, Джозеф. Освой самостоятельно UML за 24 часа, 2-е издание.: Пер. с англ. - М.: Издательский дом Вильямс, 2002.
* Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. Язык UML. Руководство пользователя.: Пер. с англ. М.: ДМК Пресс, 2004.
* Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite. - М.: ДИАЛОГ-МИФИ, 2003.
* Маклаков С.В. Моделирование бизнес-процессов с AllFusion Process Modeler. - М.: ДИАЛОГ-МИФИ, 2003.