|
|
|
Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 19.02.03 | |
| СТАТЬЯ |
19.02.03
|
© Леонов
Игорь Васильевич , "ЭСКЕЙП"
© Статья была опубликована сайте фирмы "ЭСКЕЙП"
Содержание
Эта глава включает в себя краткий обзор методологии разработки программного обеспечения при помощи Rational Rose. Материала, изложенного в этой главе, достаточно, чтобы можно было начать проектирование системы. Основная цель главы - кратко описать шаблоны построения различных артефактов проекта, которые могут послужить внутрифирменным стандартом. Отметим, что "кратко описать" не означает "привести полный шаблон". Полным шаблонам будут посвящены другие статьи, которые предполагается написать позднее по мере появления свободного времени и приобретения опыта реального проектирования. Сейчас в качестве полностью проработанных шаблонов мы можем предложить только шаблон описания прецедентов и шаблон для Use Case View модели Rational Rose. Подробнее см. следующий параграф.
Разработка программного продукта для поддержки бизнес-процессов в какой-либо компании может включать в себя два этапа. Первый этап - это анализ бизнес-процессов компании. Второй - это собственно проектирование и реализация программного продукта.
Если вы при разработке используете CASE-средство Rational Rose, то работы на обоих этапах выполняются сходным образом. На первом этапе сначала вы ищете внешних контрагентов компании (в терминах Rational - действующих лиц, actors) и бизнес-прецеденты (business use cases). Под "бизнес-прецедентами" здесь понимаются способы использования компании ее контрагентами - что получают от компании потребители, что ей предоставляют поставщики и т.п. То есть вы рисуете картину бизнеса компании с внешней точки зрения, не вдаваясь ни в какие подробности внутреннего устройства бизнес-процессов.
Отметим теперь, что при разработке программного продукта часто можно ограничиться простейшей моделью бизнес-прецедентов и перейдем ко второму этапу.
Сразу отметим ряд аналогий: внешние контрагенты используют компанию, сотрудники компании используют разрабатываемую систему. Для того, чтобы контрагенты получали требуемые результаты, в компании есть различные объекты - сотрудники, документы, с которыми они работают и т.п. Все эти объекты вовлечены в бизнес-процессы. Точно также для того, чтобы сотрудники компании могли получать от системы необходимые для успешной работы результаты, в системе есть объекты базы данных, объекты в виде экранных форм и в виде промежуточных управляющих объектов. Аналогом бизнес-процессов в системе служат потоки событий. Способы использования системы сотрудниками фиксируются в виде прецедентов системы (use cases).
Перейдем теперь в Rational Rose. Если позволяет объем модели и быстродействие компьютера, то имеет смысл хранить все элементы проекта в одной модели. Обобщенный уровень моделирования, уровень моделирования способов использования, носит название Use Case View. Этапов у нас два: включаем в шаблон модели в Use Case View два пакета - "Модель бизнес-прецедентов" и "Модель прецедентов системы". Дальше мы будем рассматривать только модель прецедентов системы, помня о том, что бизнес-процессы компании можно описать аналогично.
В модель прецедентов системы включаются действующие лица (сотрудники, которые будут пользоваться системой, или, точнее, категории сотрудников) и способы использования системы - прецеденты. Категорий сотрудников обычно немного; выделяем для них один отдельный пакет - "Действующие лица". Для каждой категории составляем описание. Впоследствии все эти описания можно извлечь в документ Word при помощи пакета Rational SoDA. Для всех прецедентов тоже выделяем один пакет - "Прецеденты". Однако в этом пакете нам наверняка понадобятся вложенные пакеты. Их структура может быть произвольной. В предлагаемом примере структура вложенных пакетов определена из соображений связности разделов документа, который формируется по описаниям каждого прецедента при помощи пакета Rational SoDA. Параллельно с формированием структуры пакетов и добавлением в модель действующих лиц и прецедентов необходимо нарисовать несколько диаграмм, на которых изображаются связи между действующими лицами и прецедентами и, возможно, связи между различными прецедентами (см. в примере диаграмму "Обзор основных прецедентов и действующих лиц" и прецедент-включение "Ведение протокола транзакций").
Помимо модели для прецедентов создаются текстовые описания. Шаблон описания прецедентов см. в главе Введение в методологию разработки программного обеспечения при помощи Rational Rose. Часть 2. Требования к системе и способы использования, там же приводятся подробные комментарии для каждого раздела шаблона. Здесь мы только отметим, что описания прецедентов образуют простой Web-сайт. Корневая страница представляет собой описание бизнес-прецедента максимально возможной общности. Сценарий этого бизнес-прецедента и его расширения - это оглавление верхнего уровня для всех остальных бизнес-прецедентов. В сценариях этих бизнес-прецедентов мы четко увидим, - где именно нам может помочь компьютерная система, какие задачи в рамках бизнес-процессов с ее помощью будут решаться эффективнее. Здесь появляются ссылки уже на прецеденты системы.
То есть мы последовательно детализируем наш взгляд на бизнес-процессы компании и выделяем те моменты в работе пользователей, где наша система может существенно улучшить производительность труда и качество результатов. Эти моменты и есть прецеденты системы.
Стоит отметить, что словосочетание "последовательно детализируем" не означает иерархическую структуру полученных описаний. Реальная структура почти всегда будет существенно более гибкой, нежели простое дерево.
После того, как мы определились с набором прецедентов системы, следует заняться описанием реализации каждого прецедента. Реализация - это набор описаний конкретных классов (пограничные классы пользовательского интерфейса, классы-сущности для объектов, которые хранятся в базе данных, и управляющие классы - посредники между пограничными классами и сущностями). Важно отметить, что разработчикам ничто не мешает заниматься объектно-ориентированным проектированием и в процессе реализации системы в среде, у которой объектные возможности отсутствуют. Просто в модели нужно будет указать, какие программы соответствуют каждому из классов.
Реализация моделируется в пакете Logical View. Предлагаемый шаблон модели содержит три пакета. Первый из них предназначен для подробного описания реализации бизнес-прецедентов. Этот пакет называется "Модель объектов бизнеса", он часто может оставаться пустым. Два других предназначены для описания реализации прецедентов системы. Имена этих пакетов - "Модель анализа" и "Модель объектов системы". В рамках модели анализа можно рассматривать отдельные наиболее сложные фрагменты реализации прецедентов на уровне прототипов. Эта модель не является обязательной. Модель объектов системы, напротив, является одним из самых существенных и объемных элементов проекта, поскольку она включает в себя полное описание реализации системы. Ключевые элементы этой модели - классы, их атрибуты и методы, диаграммы классов и диаграммы последовательности взаимодействий.
Более подробное описание процесса разработки модели объектов системы будет приведено позднее...
Специфика инструмента для связи с сервером Cache заключается в том, что при обмене данными с Rational Rose Cache полностью воспринимает имена пакетов в модели. Поэтому для классов Cache можно выделить несколько самостоятельных пакетов непосредственно на уровне Logical View. Предлагается выделить три пакета - "cEntity" для хранимых классов, "cBoundary" для пограничных классов пользовательского интерфейса и "cControl" для классов управления. Кроме того, нам понадобится пакет "Cache Data Types", а при разработке Web-приложений - пакет "csp".
В процессе проектирования реализации прецедентов ничто не мешает нам добавлять новые прецеденты, то есть разработка системы идет по спирали - от простого прототипа с минимальным набором функций к полностью законченной системе.
Важно отметить, что при помощи пакета Rational SoDA можно формировать самые разные отчеты - по действующим лицам, по прецедентам, по связям между ними, по классам, по отдельным реквизитам классов. Эти отчеты могут играть роль прототипа пользовательской документации, могут составлять существенную часть внутрифирменной документации, поэтому необходимо не забывать о поле "Документация" в спецификациях различных элементов модели. Как минимум должны быть продокументированы действующие лица, прецеденты, классы и их методы.
Модель прецедентов для задачи тиражирования данных в многофилиальном банке. Замечание. Для загрузки этого примера у вас должен быть установлен Rational Rose 2000 или более поздняя его версия.
Шаблон отчета по прецедентам и действующим лицам. Замечание. Для загрузки этого примера у вас должны быть установлены Word 2000 и Rational SoDA for Word 2000 или более поздние версии этих продуктов.
Готовый отчет по прецедентам и действующим лицам, автоматически сгенерированный по модели прецедентов для задачи тиражирования данных в многофилиальном банке. Этот отчет может использоваться в качестве простой заготовки для руководства пользователя. Замечание. Для загрузки этого примера у вас должен быть установлен Word 97 или более поздняя его версия.
Дополнительная информация
За дополнительной информацией обращайтесь в компанию Interface Ltd.
Обсудить на форуме Rational Software
| INTERFACE Ltd. |
| ||||