Конспект по курсу. Объектно ориентированный анализ и проектирование (1133667), страница 11

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

Текст из файла (страница 11)

• существенное влияние на архитектуру системы;

• рискованные, сложные для реализации или срочные функции;

• применение новой, неапробированной технологии;

• значимость в экономических процессах.

Правила написания сценариев:

1. Используйте простые предложения: Подлежащее...сказуемое...прямое дополнение... предложный оборот (Система...удерживает...сумму...из остатка на счёте).

2. Ясно укажите, кто «владеет мячом». На каждом шаге одно из действующих лиц "владеет мячом" – сообщением и данными, которые одно действующее лицо передаёт другому.

3. Пишите, глядя на вариант использования с точки зрения пользователя, а не системы.

4. Не показывайте слишком незначительные, мелкие действия.

Виды альтернативных сценариев:

• Некорректное действие действующего лица (ввод неверного пароля).

• Бездействие основного действующего лица (истечение времени ожидания пароля).

• Предложение "система подтверждает" связано с обработкой неподтверждения (неверный учётный номер).

• Несоответствующая реакция второстепенного действующего лица или её отсутствие (истечение времени ожидания ответа).

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

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

• Критически важные недостатки в производительности системы (время реакции не укладывается в 5 секунд).

Писать варианты использования следует с позиции пользователя, т. е.:

Т
ипичные ошибки в сценариях:

• Отсутствует система.

• Отсутствует основное действующее лицо.

• Слишком много деталей пользовательского интерфейса.

• Слишком низкий (подробный) уровень описания.

С
вязи между вариантами использования и действующими лицами отображаются на диаграмме вариантов использования:

Правила составления этих диаграмм:

1. Каждый вариант использования должен быть инициирован действующим лицом.

2. Не моделируйте связи коммуникации между действующими лицами.

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

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

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

И
нструментом структуризации также является обобщение вариантов использования.

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

Методика моделирования вариантов использования в технологии Rational Unified Process предусматривает специальное соглашение, связанное с группировкой структурных элементов и диаграмм модели. Это соглашение включает следующие правила:

• Все действующие лица, варианты использования и диаграммы вариантов использования помещаются в пакет с именем Use Case Model.

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

• структуризации модели в соответствии с типами пользователей (действующих лиц);

• функциональная декомпозиция;

• разделение модели на пакеты между группами разработчиков (в качестве объектов управления конфигурацией).

Дисциплина определения требований в рамках RUP описывается следующим набором ролей и деятельностей:

Н
аборы рабочих продуктов определения требований:

Спецификация требований в технологии Rational Unified Process не требует обязательного моделирования бизнес-процессов организации, для которых создается ПО, однако, наличие бизнес-моделей существенно упрощает построение системной модели вариантов использования. При переходе от бизнес-модели к начальной версии модели вариантов использования применяются следующие правила:

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

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

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

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

• для описания поведения, включающего большое количество параллельных процессов

• для анализа варианта использования (описывают последовательность действий и их взаимосвязь)

• для анализа потоков работ (workflow) в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельности являются средством представления и анализа их поведения.

П
ример диаграммы деятельности для двух синхронных потоков:

Модель вариантов использования можно считать завершенной, если есть утвердительный ответ на следующие вопросы:

• Можно ли на основании модели сформировать четкое представление о функциях системы и их взаимосвязях?

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

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

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

• Учли ли вы все внешние системы, с которыми будет взаимодействовать данная?

Литература к лекции 6

1. Коберн А. Современные методы описания функциональных требований к системам.: Пер. с англ. – М. Лори, 2002.

2. Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007. Лекция 4.

http://panda.ispras.ru/~kuliamin/lectures‑sdt/sdt‑book-2006.pdf

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. Параграфы 2.4-2.5.

2. Соммервил И. Инженерия программного обеспечения. 6-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Главы 5, 6.

3. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Главы 6, 7.

Лекция 7. Анализ и проектирование программного обеспечения. Анализ ПО

Сначала охарактеризуем в целом технологический процесс анализа и проектирования (один из процессов в рамках RUP). Его цели:

• преобразование требований в системный проект;

• создание стабильной (т. е. не подлежащей существенным изменениям) архитектуры системы;

• адаптация системного проекта к среде реализации.

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

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

Эскизная архитектура включает:

• Набор ключевых абстракций.

• Набор классов анализа.

• Механизмы анализа.

• Иерархию уровней.

• Структуру системы.

• Реализации вариантов использования.

Уточнение архитектуры состоит в переходе от классов анализа к проектным классам.

Определяются: проектные классы; механизмы проектирования; представление размещения.

Анализ поведения включает:

• анализ вариантов использования;

• определение элементов проекта;

• рецензирование проекта.

Проектирование элементов включает:

• выявление пакетов и подсистем;

• проектирование классов;

• проектирование подсистем.

Проектирование БД включает:

• выделение устойчивых классов;

• разработку структуры БД;

• определение механизмов хранения (таких как ODBC или OODBMS).

Анализ и проектирование отличаются подходом к создаваемой системе. Анализ характеризуется тем, что:

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

• не придается значения деталям;

• описывается структура и поведение системы;

• реализуются функциональные требования в архитектуре системы;

• модель анализа имеет относительно небольшой размер.

Характеристики проектирования:

• в центре внимания – решение;

• придается значение деталям – операциям и атрибутам;

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

• модель приближена к реальному коду;

• реализуются нефункциональные требования;

• проектная модель значительно больше модели анализа.

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

Характеристики

Список файлов лекций