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

 

От вариантов использования - к модели реализации

 

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


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

 

 

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

 

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

 

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

 

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

 

Актант - Вариант использования


1. Автор

  • предложить тему статьи
  • прислать первый вариант
  • прислать доработанный вариант
  • получить гонорар

2. Редактор

  • направить автору статью на доработку
  • предложить статью в номер

3. Главный редактор

  • направить редактору статью на доработку
  • утвердить статью в номер и уведомить ответственного секретаря

4. Ответственный секретарь

  • направить редактору статью на доработку
  • направить в набор

5. Наборщик

  • направить редактору статью на доработку
  • набрать и направить в печать

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


Для построения схемы согласно данной спецификации я использовал Sybase Power Desiger, Use Case Diagram. Результат показан на рис. 2.

 

 

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

 

Даже по первой схеме вариантов использования можно сделать несколько практических выводов:

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

Архитектура как прагматическая точка зрения

 

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

 

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

 

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

 

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

 

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


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

 

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

 

 

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

 

Реализация: подготовленный прогнозируемый результат


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

 

В качестве иллюстрации уровня реализации приведу XML схему данных, описывающих сущность "статья".

 

 

Итоги

 

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

2004.05.20
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".