Системный Анализ. Предметная область. Модели на UML

Михаил Кумсков

Конспект лекции по определению модели предметной области на конкретном примере. Используется подход, существенно отличающийся от известного ER-моделирования. Модель имеет «визуальный характер» и изображается в нотации Unified Modeling Language (UML), которая «широко известна в узких кругах» аналитиков, архитекторов, разработчиков и программистов. Описаны паттерны, применяемые для преобразования диаграмм классов на UML и приведены примеры их практического использования.

Раздел 2

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

В этом разделе будет показано, как формировать функциональные требования к ИС, опираясь на модель предметной области. Изложение будет построено на основе понятия сценария использования, которое является базовым в методологии разработки программного обеспечения IBM RUP (IBM Rational Unified Process)⁶. В свое время это была одна из ведущих методологий, и если процессы разработки в организации ставились на основе RUP, то это обеспечивало прозрачность и управляемость проекта, т. е. позволяло создавать ИС в соответствии с требованиями заказчика на момент сдачи системы.

RUP определяет роли, задачи, артефакты и 9 процессов, применение которых помогает сделать разработку программного обеспечения предсказуемой. IBM RUP — это оформленная в виде web-сайта электронная энциклопедия «правильной» (Framework) разработки, которая описывает основные процессы создания ИС:

1. Моделирование бизнес процессов.

2. Управление требованиями.

3. Анализ и проектирование.

4. Реализация.

5. Тестирование.

6. Развертывание.

7. Управление изменениями и конфигурациями.

8. Управление проектом.

9. Управление средой разработки.

Далее будем рассматривать методы и технику работы с требованиями к ИС на основе соответствующей «дисциплины» IBM RUP.

Было замечено, что в проектах разработки ИС часто возникают очень похожие друг на друга проблемы:

• Формально ИС удовлетворяет требованиям, однако заказчик не доволен: цели пользователей ИС или бизнес-цели не достигнуты.

• Требования запутаны, постоянно дополняются и изменяются.

• Модули не интегрируются при сборке системы.

• Затруднено сопровождение готового продукта.

• Дефекты, особенно в требованиях, обнаруживаются слишком поздно в проекте.

• Низкое качество рабочих материалов, создаваемых в проекте.

• Низкая производительность ИС при реальной нагрузке.

• Действия в рамках команды плохо скоординированы.

Анализ успешного опыта команд, преодолевших подобные проблемы, позволяет выделить практические паттерны — лучшие практики (Best Practices), которые могут быть использованы в любых проектах, связанных с разработкой ПО.

Rational Unified Process основан на шести лучших практиках:

• итеративная разработка;

• управление требованиями;

• использование компонентной архитектуры;

• визуальное моделирование;

• постоянный контроль качества;

• управление изменениями и конфигурациями.

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

• разработка системы ориентирована на удовлетворение бизнес-потребностей заказчика в автоматизации;

• лучшие практики при их совместном применении усиливают положительные эффекты друг от друга;

• вся команда хорошо понимает, что делать, как делать и когда делать.

Две из этих практик — «Управление требованиями» и «Визуальное моделирование» — мы рассматриваем в книге.

Визуальное моделирование позволяет:

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

• понять поведение создаваемой системы — как элементы взаимодействуют друг с другом при выполнении заданных операций;

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

• обеспечить целостность и согласованность проекта с реализацией системы;

• документировать принятые проектные решения, включая вновь возникающие запросы на изменения;

• скрывать или показывать детали элементов в зависимости от назначения модели и потребностей ее будущих «читателей»;

• обеспечить однозначность коммуникаций внутри команды, которые основаны на использовании моделей системы как «ее чертежей».

Одним из средств для построения визуальных моделей является Unified Modeling Language (UML) — «графический язык», обеспечивающий описание статических и динамических аспектов системы. Методология IBM RUP основана на повсеместном использовании визуальной нотации UML.

Модель описания требований «FURPS+»

Выявление требований согласно модели FURPS+ позволяет создать качественный набор документов в проекте. Аббревиатура FURPS образована из характеристик:

• Functionality — функциональность;

• Usability — удобство использования;

• Reliability — надежность;

• Performance — производительность;

• Supportability — удобство сопровождения.

При этом часть формулировок требований относится к ограничениям на проектирование, реализацию и интерфейсы (значок «+»):

• Design — ограничения проектирования;

• Implementation — ограничения на программную реализацию, например, разработка на заданном языке программирования;

• Interface — ограничения на интерфейсы;

Основной формой представления функциональных требований к ИС являются «сценарии использования» (Use-сases).⁷ Модель сценариев использования (Use-case Model) представляет собой набор текстовых описаний для каждого выявленного сценария. Шаги сценария со стороны системы представляют собой функциональные требования к ИС. Сценарий использования (Use-case) — это ключевое понятие RUP, которое является единицей организации работ в проекте (т. е. это единица планирования, проектирования, отладки и тестирования ИС). Модель сценариев использования является основой для эффективного планирования работ и управлению проектом, без его использования эффективность работы в проекте существенно снижается.

Требования и их документирование

Основными видами артефактов, содержащих описания требований к системе, согласно IBM RUP являются:

• запросы заинтересованных лиц (ЗЛ — Stakeholder Requests);

• глоссарий (Glossary).

• видение (Vision);

• модель сценариев использования (Use Case Model, состоит из Use Case Specification);

• дополнительные спецификации (Supplementary Specification).

В приложении 1 приведены шаблоны этих документов с кратким пояснением разделов.

Последовательность обработки требований

1. Выявить заинтересованных лиц (stakeholders, список ведется в Vision).

2. Собрать их пожелания (набор документов — Stakeholder Requests).

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

• симптомы бизнес-проблем («issues»);

• действующие лица (пользователи, «needs-actors»);

• варианты использования («need-use cases»);

• бизнес-правила и бизнес-процессы («needs-business rules», «needs-business processes»);

• ограничения (needs-constraints).

4. Основные термины проекта описать в Глоссарии (Glossary), используя модель предметной области.

5. Проанализировать симптомы и сформулировать основную бизнес-проблему, на решение которой будет направлена разрабатываемая ИС (секция Problem Statement формулируется в Vision).

6. Отобрать потребности (Needs), соответствующие предложенному направлению решению проблемы (Problem Statement используется как фильтр).

7. Для отобранных потребностей (на основе Глоссария) сформировать перечень бизнес-требований к разрабатываемой системе (Features формулируется в Vision). Построить матрицу трассировки Needs и Features.

8. На основе модели предметной области выявить сценарии использования. Построить UseCases диаграмму на UML.

9. Описать эскизы (Outline) сценариев использования (UseCases), трудоемкость которых можно оценить по объему альтернативных потоков.

Конец ознакомительного фрагмента.

Примечания

6

Крачтен Ф. Введение в Rational Unified Process.: пер. с англ. М.: Вильямс, 2002. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: пер. с англ. СПб: Питер, 2002.

7

Известны названия-синонимы: «варианты использования» или «прецеденты».