Современные технологии анализа

Современные технологии анализа

08.02.10

Лекция 1. Введение в программную инженерию

 

 

Программная инженерия – это применение определенного систематического измеримого подхода при разработке эксплуатации и поддержки программного обеспечения.

В 2004 году было создано руководство к своду знаний по программной инженерии.

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

{Здесь могли быть ваши комментарии}

 

1. Software requirements – программные требования

2. Software design

3. Software construction

4. Software testing

5. Software maintenance

6. Software configuration management

7. Software engineering management

8. Software engineering process

9. Software engineering tools and methods

10. Software …

 

При анализе разработки десятков тысяч проектов, связанных с разработкой ПО, выяснилось:

· 35% проектов завершились в срок, не превысили бюджет, реализовали все требуемые функции

· 46% проектов – завершились с опозданием, расходы превысили бюджет, требуемые функции не реализовались в полном объеме

· Среднее превышение сроков – 120%

· Среднее превышение затрат – 100%

· 19% проектов – полностью провалилось

 

Кто виноват? Как правило, никто…

 

Эволюция подходов к управлению программными проектами.

 

За 50 лет развития программной инженерии накопилось большое количество моделей разработки ПО, но мы среди этого большинства моделей можем выделить главные:

1. Подход «как получится»

· Разомкнутая система управления

· Полное доверие техническим лидерам

· Представители бизнеса практически не участвуют в проекте

· Планирование неформальное и словесное

· Время и бюджет, как правило, не контролируются

1. Подход «водопад» или «каскадная модель»
• Жесткая последовательная схема управления, переход на каждый следующий этап только после завершения предыдущего
• Лучше предыдущего, но не эффективно
2. «Гибкое управление»

 

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

· Гибкие методы позволяют учитывать внесение изменений и добавлений в программную реализацию

 

«ГОСТы»

По ГОСТам разработка производится по этапам, каждый из которых предполагает выполнение строго определенного набора работ – «каскадная модель».

 

«RUP» – Rational Unified Process – унифицированный процесс, разработанный сотрудниками компании Rational Software в качестве дополнения к языку UML.

Модель RUP описывает стандартный общий процесс, на основе которого проектная команда должна создать конкретный специализированный проект, ориентированный на конечного потребителя.

 

Выбор модели процесса

 

1. Тяжелые процессы (каскадная модель)

ПЛЮСЫ:

• Рассчитаны на среднюю квалификацию исполнителей
• Большая специализация исполнителей
• Низкие требования к стабильности команды

МИНУСЫ:

· Требуют существенной управленческой надстройки

· Более длительные стадии анализа и проектирования

· Более формализованные коммуникации (большое количество документации, которое передается от одного человека к другому)

 

1. Легкие модели

ПЛЮСЫ:

· Меньше непроизводительных расходов, связанных с управлением проектом, рисками, изменениями, конфигурацией

· Упрощенные стадии анализа и проектирования

· Основной упор на разработку функциональности, совмещение ролей

· Неформальные коммуникации

НЕДОСТАТКИ:

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

· Объемы и сложность выполняемых объектов ограничены

 

 

Успешность проекта

Для успешности программного проекта необходимо:

· Четко ставить цели

· Определять способ достижения целей

· Контролировать и управлять реализацией

· Анализировать угрозы и противодействовать им

· Создавать команду

 

Существует тест программного проекта на выживание. Так называемый check-лист из 33 пунктов. Каждый пункт этого теста оценивается от 0 до 3, применяются поправочные компоненты: для малых проектов 1,5, для средних (от 5 до 20 человек) – 1,25.

 

UML

UML не предлагает какую-то методологию проектирования. Он не привязан к конкретной методологии или жизненному циклу. UML предлагает поддержку визуального моделирования, совместно с UP – унифицированным процессом – происходит объединение всего лучшего в опыте разработки программного обеспечения.

Рождение UML

До 1994 года существовало несколько конкурирующих языков и методологий визуального моделирования. Очевидные лидеры: Гради Бутч, Джеймс Рамбо, Джекапсон, объединив свои усилия, создали язык UML, который стал открытым промышленным стандартом. Rational Corporation.

 

UML постоянно расширяется и модифицируется, как промышленный стандарт. Унификация UML заключается в следующем:

• Жизненный цикл разработки ПО поддерживается визуальным синтаксисом UML (от постановки требований до реализации)
• UML используется в различных областях приложений (от аппаратных встроенных систем реального времени до систем поддержки принятия решений)
• UML является независимым от языков и платформ
• UML последовательно сохраняет применение небольшого набора своих диаграмм

 

Объекты UML

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

 

В UML-модели есть два аспекта:

· Статическая структура (описывает какие типы объектов важны для моделирования системы, и как они взаимосвязаны)

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

 

UML моделирует мир, как систему взаимодействующих объектов. Объект – это цельный блок, состоящий из данных и функциональности.

 

Структура UML

Как визуальный язык UML имеет структуру:

v Строительные блоки (основные элементы, отношения и диаграммы)

Сущности – это сами элементы модели. Это существительные UML-модели. Все UML-сущности можно разделить на:

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

 

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

 

Тип отношения	UML-синтаксис	Краткая семантика
Источник	Цель
Зависимость		Исходный элемент зависит от целевого элемента и изменение последнего может повлиять на первый
Ассоциация		Описание набора связей
Агрегация		Целевой элемент является частью исходного элемента (ромбик не закрашен)
Композиция		Строгая, более ограниченная форма агрегирования
Включение		Исходный элемент содержит целевой элемент
Обобщение		Исходный элемент является специализацией более обобщенного целевого элемента и может замещать его
Реализация		Исходный элемент гарантированно выполняет контракт, определенный целевым элементом

 

 

Диаграммы – представление моделей UML. Они показывают наборы сущностей, которые рассказывают о программной системе и являются способом визуализации того, что будет делать система (аналитические диаграммы) и как она будет делать это (проектные диаграммы).

 

Модель – это хранилище всех сущностей и отношений. Существует 13 различных типов диаграмм:

 

Структурные диаграммы:

· Пакетов

· Классов

· Компонентов

· Развертывания

· Объектов

· Композитных структур

Диаграммы поведения:

· Прецедентов использования

· Деятельности

· Конечных автоматов

Диаграммы взаимодействий:

· Последовательностей

· Коммуникации

· Обзоров взаимодействий

· Синхронизации

 

v Общие механизмы – пути достижения определенных целей

v Архитектура, как представление архитектуры будущей системы

 

ТРИ МОДЕЛИ

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

• Модель классов. Описывает статическую структуру объектов системы и их отношения. Эта модель определяет предметную область. Модель изображается на диаграмме классов (это граф, вершины которого – классы, ребра – их отношения)
• Модель состояний. Описывает изменяемые со временем аспекты объектов. Модель реализуется диаграммой состояния (это граф, вершины – состояния, ребра – переходы между состояниями, инициируемые событиями)
• Модель взаимодействия. Построение модели начинается с описания вариантов использования, которые уточняются затем на диаграммах последовательности и диаграммах деятельности. Вариант использования описывает функциональность системы, то есть то, что система делает для пользователя.
• Диаграмма последовательности изображает взаимодействие объектов во времени.
• Диаграмма деятельности уточняет важные этапы обработки

 

Центральной моделью является модель классов, поскольку сначала нужно определить, что именно изменяется, а затем ответить на вопрос: когда и как.

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

 

Разработка выполняется в виде нескольких краткосрочных мини-проектов фиксированной длительности (например, три недели), называемых ИТЕРАЦИЯМИ. Каждая итерация включает свои собственные этапы анализа требований, проектирования, реализация и завершается тестированием, интеграцией и созданием работающей части системы. Таким образом, итеративных жизненный цикл основывается на постоянном расширении и дополнении системы в процессе нескольких итераций с периодической обратной связью и адаптацией добавляемых модулей к существующему ядру системы. Такой подход иногда называются итеративной инкрементальной разработкой.

 

Важно:

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

 

При таком подходе исключаются: слишком быстрое написание кода (без детальное проработки) и чрезмерно длительный этап детального проектирования и построения диаграмм без обратной связи.

 

Замечание: проектирование и визуальное моделирование с помощью UML осуществляется в течение одного дня. Для выполнения этого разработчики обычно разбиваются на пары. В результате каждой итерации получается работающая, но не полнофункциональная система. Товарный вид приобретает система только после 10-15 итераций.

 

 

Управление изменениями

Девизом итеративной разработки может быть лозунг: ДОПУСКАЙТЕ ИЗМЕНЕНИЯ!

 

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

 

Длительность итерации

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

 

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

 

Рис. 3. Процент изменений для проектов различного размера

 

 

Функциональная точка – это любой из следующих элементов разрабатываемой системы:

• Входной элемент приложения (входной документ или экранная форма) (первичный документ, если это унифицированная форма, в ней размещены различные окна ввода. В некоторых ИС рассматривается единая форма для ввода с различных документов, но там есть окна, где указывается конкретный тип документа (платежное поручение, и т.п.).
• Экранная форма – стандартная электронная форма для различных типов документов
• Выходной документ. Например: отчет, документ, экранная форма
• Запрос. Пара: вопрос-ответ
• Логический файл. Совокупность записей данных, используемых внутри приложения
• Интерфейс приложения. Совокупность записей данных, передаваемых другому приложению или получаемых от него

 

Любой анализ, моделирование или управление проектом говорит о нестабильности создаваемых артефактов[1].

 

 

Итеративное планирование на основе рисков и с учетом потребностей пользователей

 

На ранних итерациях цели проектирования должны обеспечить:

• Идентификацию и учет наибольших рисков
• Реализацию наиболее важных для пользователей свойств системы

 

Существуют наиболее распространенные риски программного проекта:

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

 

Другие специалисты приводят другой список:

• Изъяны календарного планирования
• Текучесть кадров
• Раздувание требований
• Нарушение спецификаций
• Низкая производительность

 

В процессе разработки риски нужно идентифицировать и подвергнуть качественному анализу.

 

ГИБКИЕ МЕТОДЫ РАЗРАБОТКИ

 

Среди гибких методов разработки выделяют:

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

 

Основные принципы подходы гибкого процесса:

• Люди и взаимодействие, а не процессы и средства
• Работоспособное программное обеспечение, а не исчерпывающая документация
• Сотрудничество с потребителями (beta-тестирование – пользователями)
• Реакция на изменения

 

 

Дисциплины унифицированного процесса

 

Унифицированный процесс предполагает выполнение различных видов деятельности

 

Начало (inception)

Развитие (elaboration)

Конструирование (construction)

Передача (transition)

 

Бизнес-моделирование – подразумевает разработку модели предметной области. Это визуальное представление наиболее важных сущностей из предметной области и их взаимосвязь

 

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

 

Проектирование – модель проектирования, отражающая программные объекты

 

Реализация – программирование и построение системы

 

Таблица 2. Примерный набор инструментов унифицированного процесса (н — начало, р — развитие)

 

Дисциплина	Приемы	Артефакт Итерация->	Начало И	Развитие Е1..Еп	Конструи­рование С1..Сп	Передача Т1..Тп
Бизнес-моделирование	Гибкое моде­лирование, регулярные семинары	Модель предмет­ной области		н
Требования	Регулярные семинары	Модель преце­дентов	н	Р
		Видение системы	н	Р
		Дополнительная спецификация	н	Р
		Словарь терминов	н	Р
Проектирование	Гибкое моде­лирование, разработка на основе рисков	Модель проекти­рования		н	Р
		Описание архи­тектуры		н
		Модель данных		н	Р
Реализация	Разработка на основе рисков, пар­ное програм­мирование, непрерывная интеграция
Управление проектом	Гибкое управление, ежедневные семинары в стиле Scrum

 

Описание прецедента

 

Прецеденты – повествовательные истории об использовании системы, которые широко используются для осмысления и формулировки требований

 

Три типа исполнителей

 

Все сущности, включая разрабатываемую систему, могут играть различные роли:

• Основной исполнитель – его задачи выполняются с использованием системы (кассир)
• Вспомогательный исполнитель – обслуживает систему (например, предоставляет информацию). Служба авторизации платежей
• Закулисный исполнитель – заинтересован в реализации прецедента. Например: налоговая служба

 

Выделение прецедентов

 

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

1. Определяются рамки системы (включает отдельного пользователя или своих пользователей, или всю организацию):

· Программное приложение

· Аппаратно-программный комплекс

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

 

При определении исполнителей и задач часто возникают вопросы, на которые нужно ответить:

• Кто запускает и выключает систему
• Кто является системным администратором
• Кто осуществляет управление пользователями и безопасностью
• Должна ли система выполнять какие-либо действия в ответ на события времени (время – исполнитель?)
• Существует ли процесс мониторинга

 

15.03.10

Диаграмма прецедентов

Рис. 2. Пример диаграммы прецедентов

 

 

 

Рис. 3. Некоторые обозначения диаграммы прецедентов

 

 

Модели предметной области

 

Модель предметной области – это самая важная модель объектно-ориентированного анализа.

 

Каждой итерации соответствует своя модель предметной области, поскольку отражает реализуемые на каждом этапе прецеденты. Модель предметной области связана с моделью проектирования, особенно с программными объектами.

 

Модель предметной области – это визуальное представление концептуальных классов или объектов реального мира в терминах предметной области. Эти модели связаны с моделями взаимоотношений концептуальных сущностей. Модели используются как модели данных для разработки баз данных.

 

*Замечание: модели предметной области не описывают программные классы или программные объекты с их обязанностями.

 

Модель предметной области – это конкретизация модели бизнес-объектов. На языке UML модель предметной области представляется в виде набора диаграмм-классов, на которых не определены никакие операции, в ее состав входят

· объекты предметной области

· ассоциации между ними

· атрибуты концептуальных классов

 

Концептуальные классы

 

Концептуальный класс – это представление идеи или объекта.

 

Пример: для события «Осуществление покупки» концептуальный класс – ПРОДАЖА. Содержанием этого понятия является осуществление покупки в определенный день и определенное время.

 

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

 

Создание модели предметной области

 

Для создания:

1. Выделить концептуальные классы
2. Отобразить их на диаграмме
3. Добавить необходимые ассоциации и атрибуты

 

1. Выделение концептуальных классов.

 

Существует три стратегии определения концептуальных классов.

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

 

№	Категории	Примеры
	Транзакции. Эта классы особенно критичны, поскольку чаще всего описывают финансовые операции	Продажа, платеж
	Элементы транзакций	Элемент продажи
	Товары или службы, связанные с транзакциями или их элементами	Элемент продажи
	Места записи транзакций. Очень важная категория	Реестр
	Роли людей или организации, связанные с транзакциями. Исполнители прецедентов (необходимо знать, кто участвует в транзакции)	Покупатель, кассир, магазин
	Места транзакций	Магазин
	Важные события, для которых необходимо хранить время и место	Продажа и платеж
	Физические объекты. Такие объекты обычно соответствуют программным системам, предназначенным для управления или моделирования	Товар, реестр
	Описание объектов	Спецификация товара
	Каталоги (описание товара зачастую приводится в каталоге)	Каталог товаров
	Контейнеры других объектов (физических или информационных)	Магазин, склад
	Содержимое контейнеров	Элемент
	Другие системы, внешние по отношению к данной системе	Система авторизации кредитных платежей
	Записи финансовой, трудовой, юридической и другой деятельности	Чек
	Финансовые инструменты	Кредитная линия, наличные, чек
	Руководство, документы, статьи, на которые ссылаются в процессе работы	Трудовой договор, бюллетень ежедневного изменения цен, прайс-лист

 

 

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

 

ПРИМЕР

Оформление продажи.

29.03.10

Диаграммы взаимодействия

 

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

 

CRC cards— Class-Responsibility-Collaborator cards

CRC-карты – это индексные карты, по одной на каждый класс, на которых кратко описаны обязанности класса и перечислены объекты, которые взаимодействуют с данным классом при выполнении этих обязанностей.

 

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

 

Диаграммы взаимодействия включают два типа:

• Диаграммы последовательностей (sequence diagram)
• Диаграммы коммуникации (communication diagram)

 

Диаграммы последовательностей иллюстрируют взаимодействие

 

Рис. 1. Диаграмма последовательности

 

(диаграмму следует рассматривать слева направо, сверху вниз)

Класс А содержит метод doOne и атрибут типа B (класса B).

Класс В, в свою очередь, содержит методы doTwo и doThree.

 

Диаграмма коммуникации

 

Рис. 2. Диаграмма коммуникации

 

Взаимодействие А и В представлено в форме графа.

 

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

 

Диаграмма коммуникации дает возможность добавлять объекты в двух направлениях.

 

ОСНОВНЫЕ ОБОЗНАЧЕНИЯ ДЛЯ ДИАГРАММ ПОСЛЕДОВАТЕЛЬНОСТИ

 

Прямоугольники – участники взаимодействия (реестр, продажа):

• объекты,
• классы,
• экземпляры классов

 

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

получатель = сообщение (параметр: типПараметра): типПолучателя

 

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

 

Рис. 3. Примеры участников взаимодействия

 

1 – неименованный экземпляр класса Sale

2 – именованный экземпляр класса Sale

3 – экземпляр метакласса (Font – описание шрифтов)

 

Каждый прямоугольник участника взаимодействия имеет линию жизни – пунктирная линия

 

СООБЩЕНИЯ

 

Рис. 4. Сообщения и фокус управления с блоком выполнения

 

Сообщения изображаются в виде соединяющих вертикальные линии жизни – линии с заштрихованными стрелками (черненькая).

 

Линия сообщений с открытыми стрелками – это асинхронное сообщение.

 

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

 

Рис. 5. Два способа отображения возврата значения

 

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

Рис. 6. Сообщения, передаваемые самому объекту

 

 

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

Рис. 7. Уничтожение объекта

 

Фреймы на диаграммах последовательностей

 

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

 

Рис. 8. Пример фрейма

 

Основные операторы, изображаемые с помощью фреймов

• alt – альтернативный фрагмент для взаимоисключающих условий
• loop – фрагмент цикла, выполняемый в случае истинности условного выражения
• opt – необязательный фрагмент, которые выполняется в случае истинности условного выражения
• par – фрагменты, выполняемые параллельно
• interactive – диалоговый, после ввода команды пользователя

 

 

Рис. 12. Условное сообщение

 

Взаимоисключающее условное сообщение имеет вид:

Рис. 9. Взаимоисключающие условные сообщения.

 

Фреймы могут быть вложенными

 

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

 

ДИАГРАММЫ КОММУНИКАЦИИ

 

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

Рис. 10. Сообщения

 

Сообщение может передаваться объектом самому себе. Начальное сообщение может не нумероваться.

Рис. 11. Нумерация последовательности сообщений

 

Для создания экземпляров объектов можно использовать любые сообщения, которые выбираются из палитры инструментов диаграммы или путем установления связей.

 

Рис. 12. Условное сообщение

 

В квадратных скобках указывается условное сообщение.

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

 

Взаимоисключающие условные маршруты

 

Рис. 13. Взаимоисключающие сообщения

 

 

Итерационный процесс или цикл.

 

Рис. 14. Итерационный процесс или цикл

 

Цифра 1 – номер сообщения

Символ * – цикл

В скобках параметр – цикл изменяется от 1 до N

 

 

 

 

 

12.04.10

Требования и бизнес-правила

 

Для описания требований диаграммы прецедентов недостаточно. Существуют и другие артефакты требований:

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

· Словарь терминов (Включает термины и определения и может служить словарем данных)

· Документ-видение (Определяет видение проекта, описывает важнейшие идеи, положенные в основу разработки системы)

· Бизнес-правила (Устойчивые правила или политики, применяемые в предметной области – правила налогообложения, торговая политика и т.д.)

 

Ценность документов Видение и Дополнительная спецификация состоит в формировании первого приближения требований к системе и определение главных идей проекта.

В то же время это не является надежной спецификацией. Реальные требования можно сформулировать только после написания кода, его тестирования и получения обратной связи от пользователей системы.

 

Пример Дополнительной спецификации (фрагмент)

1. Введение

· Описание всех требований, не вошедших в описание прецедентов.

2. Функциональность.

· Описание, относящееся к большинству прецедентов.

· Кроме того, описывается, каким образом регистрируются события и обрабатываются ошибки.

· Подключение бизнес-правил

3. Безопасность – аутентификация всех пользователей

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

4. Надежность

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

5. Производительность

· Время взаимодействия с внешними системами

6. Возможности поддержки

· Адаптация системы. Для различ