- •Оглавление
- •Глава 1. Жизненный цикл программного обеспечения ……………………………………………43
- •Глава 2. Методические аспекты
- •Глава 3. Моделирование бизнес-процессов
- •Глава 4. Анализ и проектирование
- •Глава 5. Технологии создания программного
- •Глава 6. Оценка трудоемкости создания
- •Глава 7. Особенности современных проектов ........527
- •Предисловие
- •Введение
- •Глава 1 жизненный цикл программного обеспечения
- •Нормативно-методическое обеспечение создания по
- •Стандарт жизненного цикла по
- •Основные процессы жц по
- •Вспомогательные процессы жизненного цикла по
- •Организационные процессы жизненного цикла по
- •Взаимосвязь между процессами жц по
- •Модели жизненного цикла по
- •Каскадная модель жц
- •Итерационная модель жизненного цикла
- •Методика spmn
- •Пример процесса «управление требованиями»
- •Пример процесса «управление конфигурацией по»
- •Общие принципы проектирования систем
- •Визуальное моделирование
- •Структурные методы анализа и проектирования по
- •Метод функционального моделирования
- •Описание типов связей
- •Моделирования процессов idef3
- •Типы связей idef3
- •Типы соединений
- •Моделирование потоков данных
- •Количественный анализ диаграмм
- •Сравнительный анализ sadt-моделей и диаграмм потоков данных
- •Моделирование данных
- •Объектно-ориентированные методы анализа и проектирования по
- •Основные принципы построения объектной модели
- •Основные элементы объектной модели
- •Значения мощности
- •Унифицированный язык моделирования uml
- •Диаграммы вариантов использования
- •Диаграммы взаимодействия
- •Диаграммы классов
- •Диаграммы состояний
- •Диаграммы деятельности
- •Диаграммы компонентов
- •Диаграммы размещения
- •Механизмы расширения uml
- •Количественный анализ диаграмм uml
- •Основные элементы языка uml
- •Основные типы связей языка uml
- •Диапазоны оценок для диаграмм uml
- •Образцы
- •Сопоставление и взаимосвязь структурного и объектно-ориентированного подходов
- •Структурный (процессный) подход к моделированию бизнес-процессов
- •Принципы процессного подхода
- •Применение диаграмм потоков данных
- •Система моделирования aris
- •Метод ericsson-penker21
- •Пример использвания процессного подхода
- •История болезни пациента
- •Спецификация структур данных
- •Построение диаграмм потоков данных нулевого и последующих уровней
- •Объектно-ориентированный подход к моделированию бизнес-процессов
- •Методика моделирования
- •Пример использования объектно-ориентированного подхода
- •Пример спецификации требований к программному обеспечению
- •Пример структурного проектирования по
- •Построение диаграмм системных процессов и диаграмм последовательностей экранных форм
- •Объектно-ориентированный анализ
- •Архитектурный анализ
- •Анализ вариантов использования
- •Объектно-ориентированное проектирование
- •Проектирование архитектуры системы
- •Проектирование элементов системы
- •Глава 5 технологии создания программного обеспечения
- •Определение технологии
- •Общие требования, предъявляемые
- •Внедрение тс по в организации
- •Общие сведения
- •Определение потребностей в тс по
- •Оценка и выбор тс по
- •Критерии оценки и выбора тс по
- •Выполнение пилотного проекта
- •Практическое внедрение тс по
- •Примеры тс по
- •Технология rup (rational unified process)
- •Технология oracle
- •Технология borland
- •Технология computer associates
- •Глава 6 оценка трудоемкости создания программного обеспечения
- •Методы оценки и их классификация
- •Методика оценки трудоемкости разработки по на основе функциональных точек
- •Определение функциональных типов
- •Определение количества и сложности функциональных типов по данным
- •Сложность ilf и eif
- •Определение количества и сложности транзакционных функциональных типов
- •Подсчет количества функциональных точек
- •Зависимость количества fp от сложности функционального типа
- •Коммуникации данных
- •Распределенная обработка данных
- •Сложность ei
- •Сложность ео
- •Производительность
- •Эксплуатационные ограничения
- •Частота транзакций
- •Ввод данных в режиме «онлайн»
- •Эффективность работы конечных пользователей1
- •Онлайновое обновление
- •Сложная обработка31
- •Повторное использование
- •Простота установки
- •Простота эксплуатации
- •Количество возможных установок на различных платформах
- •Гибкость32
- •Оценка трудоемкости разработки
- •Размер программного обеспечения в fp и loc
- •Распределение временных затрат по стадиям для маленьких и больших проектов
- •Статистические данные
- •Статистические (регрессионные) модели
- •Группа процессов
- •Определение весовых показателей вариантов использования
- •Определение технической сложности проекта
- •Определение уровня квалификации разработчиков
- •Оценка трудоемкости проекта
- •Методы, основанные на экспертных оценках
- •Метод дельфи
- •Метод декомпозиции работ
- •Средства оценки трудоемкости
- •Планирование итерационного процесса создания по
- •Глава 7 особенности современных проектов
- •Категории «безнадежных» проектов
- •Причины, порождающие «безнадежные» проекты
- •Причины разногласий между участниками проекта
- •Переговоры в «безнадежном» проекте
- •Человеческий фактор в «безнадежных» проектах
- •Процессы в «безнадежных» проектах
- •Динамика процессов
- •Контроль над продвижением проекта
- •Технология и инструментальные средства «безнадежных» проектов
- •Дополнительная литература
- •Краткий словарь терминов
- •Список основных сокращений
Диаграммы деятельности
В отличие от большинства других средств UML диаграммы деятельности заимствуют идеи из нескольких различных методов, в частности из метода моделирования состояний SDL и сетей Петри. Эти диаграммы особенно полезны в описании поведения, включающего большое количество параллельных процессов. Диаграммы деятельности также полезны при параллельном программировании, поскольку можно графически изобразить все ветви и определить, когда их необходимо синхронизировать.
Диаграммы деятельности можно применять для описания потоков событий в вариантах использования. С помощью текстового описания можно достаточно подробно рассказать о потоке событий, но в сложных и запутанных потоках с множеством альтернативных ветвей будет трудно понять логику событий. Диаграммы деятельности предоставляют ту же информацию, что и текстовое описание потока событий, но в наглядной графической форме.
На рис. 2.56 приведена диаграмма деятельности для потока событий, связанного с системой бронирования авиабилетов. Рассмотрим ее нотацию.
Основным элементом диаграммы является деятельность (activity). Интерпретация этого термина зависит от той точки зрения, с которой строится диаграмма (это может быть некоторая задача, которую необходимо выполнить вручную или автоматизированным способом, или операция класса). Деятельность изображается в виде закругленного прямоугольника с текстовым описанием.
Любая диаграмма деятельности должна иметь начальную точку, определяющую начало потока событий. Конечная точка необязательна. На диаграмме может быть несколько конечных точек, но только одна начальная.
На диаграмме могут присутствовать объекты и потоки объектов (object flow). Объект может использоваться или изменяться в одной из деятельностей. Показ объектов и их состояний (в дополнение к диаграммам состояний) помогает понять, когда и как происходит смена состояний объекта.
Объекты связаны с деятельностями через потоки объектов. Поток объектов отмечается пунктирной стрелкой от деятельности к изменяемому объекту или от объекта к деятельности, использующей объект.
На рис. 2.56 после ввода пользователем информации о кредитной карточке билет переходит в состояние «не подтвержден». Когда завершится процесс обработки кредитной карточки и будет подтвержден перевод денег, возникает деятельность «зарезервировать место», переводящая билет в состояние «приобретен»,
Рис. 2. 56. Диаграмма деятельности
и затем он используется в деятельности «формирование номера подтверждения».
Переход (стрелка) показывает, как поток управления переходит от одной деятельности к другой. Если для перехода определено событие, то переход выполняется только после наступления такого события. Ограничивающие условия определяют, когда переход может, а когда не может осуществиться.
Если необходимо показать, что две или более ветвей потока выполняются параллельно, используются линейки синхронизации. В данном примере параллельно выполняются резервирование места, формирование номера подтверждения и отправка почтового сообщения, а после завершения всех трех процессов пользователю выводится номер подтверждения.
Любая деятельность может быть подвергнута дальнейшей декомпозиции. Описание декомпозированной деятельности может быть представлено в виде другой диаграммы деятельности.
Подобно большинству других средств, моделирующих поведение, диаграммы деятельности отражают только вполне определенные его аспекты, поэтому их лучше всего использовать в сочетании с другими средствами.
Диаграммы деятельности предпочтительнее использовать в следующих ситуациях:
анализ потоков событий в конкретном варианте использования. Здесь нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание действий и объектов выполняется позднее с помощью диаграмм взаимодействия;
анализ потоков событий в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, на диаграмме деятельности удобно представить и проанализировать все их потоки событий (в этом случае диаграмма с помощью вертикальных пунктирных линий разделяется на зоны — так называемые «плавательные дорожки» (swimlanes). В каждой зоне изображаются потоки событий одного из вариантов использования, а связи между разными потоками — в виде переходов или потоков объектов).
2.5.6.
