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

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

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

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

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

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

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

1. Используйте простые предложения:.

2. Ясно укажите, кто «владеет мячом».

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

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

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

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

• Бездействие основного действующего лица .

• Предложение "система подтверждает" связано с обработкой неподтверждения.

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

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

• Неожиданная и необычная ошибка, которую необходимо обработать.

• Критически важные недостатки в производительности системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализ характеризуется тем, что:

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

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

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

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

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

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

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

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

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

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

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

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

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

Исполнителями процесса анализа являются архитектор, разработчик (или проектировщик), разработчик БД, разработчик пользовательского интерфейса, рецензент. Обязанности архитектора:

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

• определение структуры каждого архитектурного представления;

• осуществление архитектурного анализа.

Обязанности разработчика:

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

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

• анализ одного или нескольких пакетов или подсистем.

Рецензент оценивает решения, принятые в ходе процесса и созданные рабочие продукты (документы).

Объектно-ориентированный анализ включает два вида деятельности выполняемые друг за другом:

1. архитектурный анализ;

2. анализ вариантов использования.

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

1. утверждение общих стандартов (соглашений) моделирования и документирования системы;

2. предварительное выявление архитектурных механизмов (механизмов анализа);

3. формирование набора основных абстракций предметной области (классов анализа);

4. формирование начального представления архитектурных уровней.

Соглашения моделирования определяют:

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

• правила их применения;

• соглашения по именованию элементов модели;

• организацию модели (пакеты).

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

• Механизмы анализа: обеспечивают взаимодействие классов и компонентов предметной области, без деталей реализации.

• Проектные механизмы: учитывают некоторые детали среды реализации, без привязки к конкретной среде (например, выбор между РСУБД и ООСУБД).

• Механизмы реализации: зависят от конкретной технологии, языка программирования, поставщика (Oracle, Sun или Microsoft) и т.д.

Примеры механизмов анализа:

• Устойчивость (persistency): элементы модели, которые должны сохранять свое состояние в течение длительного времени должны быть определены как устойчивые (для каждого устойчивого элемента определяются его размер и количество хранимых объектов, сроки хранения, механизмы и частотные характеристики доступа).

• Интерфейс с унаследованными системами (legacy interface) – к этому механизму относят все элементы модели, ответственные за интерфейс с унаследованной системой.

• Безопасность (уровни, правила, привилегии) – элементы, обеспечивающие контроль доступа к системе.

• Распределение – элементы, которые должны быть распределены по узлам сети.

Идентификация основных абстракций заключается в определении набора классов системы (классов анализа), представляющих основные понятия предметной области. Набор ключевых абстракций создается на основе описания предметной области и спецификации требований к системе (в частности, глоссария проекта). Рисуется диаграмма классов Key Abstractions, на которую помещаются все ключевые абстракции.

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

• прикладной, содержащий набор компонентов, реализующих основную функциональность системы;

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

• промежуточный (middleware), куда входят платформо-независимые сервисы;

• системный, содержащий компоненты вычислительной и сетевой инфраструктуры.

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

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

• Модель-представление-управление (Model-view-controller, M-V-C) – разделение приложения на три части: данные и бизнес-правила; пользовательское представление; обработку данных.

• Каналы и фильтры (Pipes and filters) – шаблон архитектуры системы для потоковой обработки данных.

Архитектурный образец «Layers»:

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

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