- •Технология разработки
- •Введение
- •Жизненный цикл программных систем План лекции
- •Введение
- •Программа, программная система. Программный продукт. Программная система как технологический объект.
- •Понятие жизненного цикла программных систем
- •Модели жизненного цикла программного обеспечения
- •Фазы жизненного цикла по
- •Заключение
- •Прикладной системный анализ при разработке по. Принципы структурного анализа. Процедура требований
- •План лекции
- •Введение
- •Проблема сложности ис
- •Группы средств моделирования систем
- •Заключение
- •Моделирование функций по. Нотация idef0. Case-средство bpWin
- •План лекции
- •Введение
- •ДиаграммыIdef0.
- •Виды связей вIdef0
- •Диаграмма дерева узлов
- •Диаграмма «Только для просмотра» (ForExpositionOnly–feo)
- •Case-средство bpWin
- •Заключение
- •Описание динамики системы. Нотация idef3
- •План лекции
- •Введение
- •Основные символыIdef3
- •Виды перекрестков вIdef3
- •Виды связей вIdef3
- •Пример диаграммыIdef3
- •Заключение
- •Постановка требований к данным. Словари данных. Моделирование данных в нотации idef1x. Case-средство erWin
- •План лекции
- •Введение
- •Словарь данных
- •Моделирование данных в нотацииIdef1x
- •Базовые понятияErd
- •Виды сущностей вIdef1x
- •Виды связей вIdef1x
- •Нормализация схемы данных
- •Заключение
- •Постановка требований к интерфейсу по. Понятие Usability.
- •План лекции
- •Введение
- •Эргономические цели и показатели качества программного продукта
- •Проблемы, возникающие на этапе разработки прототипа gui и варианты их решения
- •Принципы реализации пользовательского интерфейса
- •Заключение
- •Объектно-ориентированная методология проектирования по. Язык uml. Case-средство Rational Rose.
- •План лекции
- •Введение
- •Основные компоненты языка uml
- •Назначение языка uml
- •Общая структура языка uml
- •Пакеты в языке uml
- •Основные пакеты метамодели языка uml
- •Пакет Основные элементы
- •Пакет Элементы ядра
- •Пакет Вспомогательные элементы
- •Пакет Механизмы расширения
- •Пакет Типы данных
- •Пакет Элементы поведения
- •Пакет Общее поведение
- •Пакет Кооперации
- •Пакет Варианты использования
- •Пакет Автоматы
- •Пакет Общие механизмы
- •Пакет Управление моделями
- •Специфика описания метамодели языка uml
- •Особенности изображения диаграмм языка uml
- •Объектно-ориентированные case-средства (Rational Rose)
- •Структура и функции
- •Взаимодействие с другими средствами и организация групповой работы
- •Среда функционирования
- •Вариант использования
- •Интерфейсы
- •Примечания
- •Отношения на диаграмме вариантов использования
- •Отношение ассоциации
- •Отношение расширения
- •Отношение обобщения
- •Отношение включения
- •Пример построения диаграммы вариантов использования
- •Заключение
- •Проектирование внутренней структуры приложений при помощи диаграмм классов в uml
- •План лекции
- •Введение
- •Имя класса
- •Атрибуты класса
- •Операция
- •Отношения между классами
- •Отношение зависимости
- •Отношение ассоциации
- •Отношение агрегации
- •Отношение композиции
- •Отношение обобщения
- •Интерфейсы .
- •Объекты
- •Шаблоны или параметризованные классы
- •Заключение
- •Проектирование динамики приложений при помощи диаграмм переходов состояний, диаграмм последовательности и диаграмм взаимодействия в uml
- •План лекции
- •Введение
- •Автоматы
- •Состояние
- •Имя состояния
- •Список внутренних действий
- •Начальное состояние
- •Конечное состояние
- •Переход
- •Сторожевое условие
- •Выражение действия
- •Составное состояние и подсостояние
- •Последовательные подсостояния
- •Параллельные подсостояния
- •Историческое состояние
- •Сложные переходы
- •Переходы между параллельными состояниями
- •Переходы между составными состояниями
- •Синхронизирующие состояния
- •Заключительные рекомендации по построению диаграмм состояний
- •Диаграмма деятельности (activity diagram)
- •Состояние действия
- •Переходы
- •Дорожки
- •Объекты
- •Рекомендации по построению диаграмм деятельности
- •Диаграмма последовательности (sequence diagram)
- •Объекты
- •Линия жизни объекта
- •Фокус управления
- •Сообщения
- •Ветвление потока управления
- •Стереотипы сообщений
- •Временные ограничения на диаграммах последовательности
- •Комментарии или примечания
- •Пример построения диаграммы последовательности
- •Заключение
- •Управление требованиями к программному продукту. Case-средство Requisite Pro.
- •План лекции
- •Введение
- •Нормативная основа
- •Термины, сокращения и определения
- •Основные положения
- •Цели управления требованиями
- •Участники управления требованиями
- •Политика в области управления требованиями
- •Обеспечение процессов управления требований
- •Распределение ответственности
- •Аналитик
- •Менеджер проекта
- •Тестировщик
- •Проектировщик
- •Разработчик
- •Документирование
- •Обеспечение ресурсами
- •Обучение
- •Действия по управлению требованиями
- •Анализ требований
- •Разработка материалов проекта на основе требований
- •Контроль изменений требований
- •Измерения
- •Показатель важности
- •Контроль со стороны руководителя проекта
- •Контроль со стороны гок
- •Стандарт оформления требований
- •Шаблон для разработки требований
- •Правила оформления требований
- •Структурирование требований
- •Показатели качества требований
- •Проверяемость
- •Модифицируемость
- •Прослеживаемость
- •Начало работы сRequisitePro
- •Создание и настройка проекта
- •Создание проекта
- •Создание типов требований
- •Определение атрибутов
- •Создание типов документов
- •Добавление требований
- •Требования в документах
- •RequisitePro Views
- •Обсуждения
- •Заключение
- •Тестирование приложений. Функциональное тестирование, нагрузочное тестирование. Case-средстваRational Functional Tester,Rational Performance Tester.
- •План лекции
- •Введение
- •Дестабилизирующие факторы и методы обеспечения высокого качества функционирования по
- •Использование среды автоматизированного тестированияPlatinumTestBytes
- •Методы обеспечения качества и надежности программных средств
- •Использование case для повышения качества по
- •Влияние стандартов открытых систем на качество по
- •Повышение качества по путем тестирования
- •Основные особенности процесса тестирования по
- •Организационные особенности тестирования
- •Сертификация по
- •Организация и планирование тестирования для обеспечения качества по
- •Важнейшие разделы iso 9003
- •Общие положения
- •Документирование системы качества
- •Программа качества
- •Внутренние проверки системы качества
- •Корректирующие действия
- •Заключение
- •Комплексная интеграция bpWin, erWin и Paradigm Plus.
- •План лекции
- •Введение
- •Соответствие объектов моделей процессов и моделей данных
- •Экспорт между моделью данных и моделью процессов
- •Paradigm Plus: двусторонняя связь с eRwin
- •Создание физической модели данных вErWin
- •Уровни физической модели
- •Правила валидации и значения по умолчанию
- •Индексы
- •Триггеры и хранимые процедуры
- •Значения ri, используемые erWin для различных типов связей
- •Заключение
- •Стандарты, регламентирующие разработку по
- •План лекции
- •Введение
- •Iso 15504 spice
- •Серия стандартов гост 34-ххх «Информационная технология»
- •Группы процессов
- •Взаимосвязи процессов
- •Процессы инициации
- •Результаты
- •Исходная информация
- •Шаги задачи
- •Методика и подход
- •Выработать основные положения проекта
- •Определить область применения, цели и подход
- •Произвести оценку рисков
- •Получить подтверждение Заказчика и Исполнителя
- •Роли и ответственность
- •Заключение
- •Рабочий план
- •План лекции
- •Введение
- •Основные процессы планирования
- •Вспомогательные процессы планирования
- •Документ «Рабочий план»
- •По работам
- •По исполнителям
- •Диаграмма Гантта по проекту
- •Процессы управления
- •Основные процессы управления
- •Вспомогательные процессы управления
- •Основные процессы анализа
- •Вспомогательные процессы анализа
- •Заключение Заключение
- •Контрольные вопросы
- •Библиографический список
Пример построения диаграммы вариантов использования
В качестве примера рассмотрим процесс моделирования системы продажи товаров по каталогу, которая может быть использована при создании соответствующих информационных систем.
В качестве актеров данной системы могут выступать два субъекта, один из которых является продавцом, а другой — покупателем. Каждый из этих актеров взаимодействует с рассматриваемой системой продажи товаров по каталогу и является ее пользователем, т. е. они оба обращаются к соответствующему сервису "Оформить заказ на покупку товара". Как следует из существа выдвигаемых к системе требований, этот сервис выступает в качестве варианта использования разрабатываемой диаграммы, первоначальная структура которой может включать в себя только двух указанных актеров и единственный вариант использования (рис. 46).
Исходная диаграмма вариантов использования для примера разработки системы продажи товаров по каталогу
Значения указанных на данной диаграмме кратностей отражают общие правила или логику оформления заказов на покупку товаров. Согласно этим правилам, один продавец может участвовать в оформлении нескольких заказов, в то же время каждый заказ может быть оформлен только одним продавцом, который несет ответственность за корректность его оформления и, в связи с этим, будет иметь агентское вознаграждение за его оформление. С другой стороны, каждый покупатель может оформлять на себя несколько заказов, но, в то же время, каждый заказ должен быть оформлен на единственного покупателя, к которому переходят права собственности на товар после его оплаты.
Примечание: Рассмотренные выше примеры значений для кратности отношения ассоциации могут вызвать невольное восхищение глубиной своей семантики, которая в единственном специальном символе отражает вполне определенные логические условия реализации соответствующих компонентов диаграммы вариантов использования.
На следующем этапе разработки данной диаграммы вариант использования "Оформить заказ на покупку товара" может быть уточнен на основе введения в рассмотрение четырех дополнительных вариантов использования. Это следует из более детального анализа процесса продажи товаров, что позволяет выделить в качестве отдельных сервисов такие действия, как обеспечить покупателя информацией о товаре, согласовать условия оплаты товара и заказать товар со склада. Вполне очевидно, что указанные действия раскрывают поведение исходного варианта использования в смысле его конкретизации, и поэтому между ними будет иметь место отношение включения.
С другой стороны, продажа товаров по каталогу предполагает наличие самостоятельного информационного объекта — каталога товаров, который в некотором смысле не зависит от реализации сервиса по обслуживанию покупателей. В нашем случае, каталог товаров может запрашиваться покупателем или продавцом при необходимости выбора товара и уточнения деталей его продажи. Вполне резонно представить сервис "Запросить каталог товаров" в качестве самостоятельного варианта использования.
Полученная в результате последующей детализации уточненная диаграмма вариантов использования будет содержать 5 вариантов использования и 2 актеров (рис. 47), между которыми установлены отношения включения и расширения.
Уточненный вариант диаграммы вариантов использования для примера системы продажи товаров по каталогу
Приведенная выше диаграмма вариантов использования, в свою очередь, может быть детализирована далее с целью более глубокого уточнения предъявляемых к системе требований и конкретизации деталей ее последующей реализации. В рамках общей парадигмы ООАП подобная детализация может выполняться в двух основных направлениях.
С одной стороны, детализация может быть выполнена на основе установления дополнительных отношений типа отношения "обобщение-специализация" для уже имеющихся компонентов диаграммы вариантов использования. Так, в рамках рассматриваемой системы продажи товаров может иметь самостоятельное значение и специфические особенности отдельная категория товаров — компьютеры. В этом случае диаграмма может быть дополнена вариантом использования "Оформить заказ на покупку компьютера" и актерами "Покупатель компьютера" и "Продавец компьютеров", которые связаны с соответствующими компонентами диаграммы отношением обобщения (рис. 48).
Уточненный таким способом вариант диаграммы вариантов использования содержит одну важную особенность, которую необходимо отметить. А именно, хотя на данной диаграмме (рис. 48) отсутствуют изображения линий отношения ассоциации между актером "Продавец компьютеров" и вариантом использования "Оформить заказ на покупку компьютера", а также между актером "Покупатель компьютера" и вариантом использования "Оформить заказ на покупку компьютера", наличие отношения обобщения между соответствующими компонентами позволяет им наследовать отношение ассоциации от своих предков. Поскольку принцип наследования является одним из фундаментальных принципов объектно-ориентированного программирования, в нашем примере можно с уверенностью утверждать, что эти линии отношения ассоциации с соответствующими кратностями присутствуют на данной диаграмме в скрытом виде.
Один из вариантов последующего уточнения диаграммы вариантов использования для примера рассматриваемой системы продажи
Для пояснения изложенного можно привести фрагмент диаграммы вариантов использования для рассмотренного примера, на котором явно указаны отношения ассоциации между дочерними компонентами (рис. 49). Данное изображение фрагмента диаграммы приводится с методической целью, при этом остальные компоненты диаграммы, которые остались без изменений, условно отмечены многоточием.
Фрагмент диаграммы вариантов использования, который в неявном виде присутствует на уточненной диаграмме с отношением ассоциации между отдельными компонентами
Примечание: Строго говоря, приведенное выше изображение фрагмента диаграммы не является допустимым с точки зрения нотации языка UML Причиной этого следует считать многоточие, которое не может быть использовано в подобной интерпретации. Тем не менее, данное изображение иллюстрирует основные идеи наследования свойств и поведения, которые неявно могут присутствовать в графических моделях сложных систем. С другой стороны, следует всегда помнить, что эта информация является избыточной с точки зрения семантики языка UML, а значит может быть опущена, что и было сделано на предыдущей диаграмме (см. рис. 48).
Второе из основных направлений детализации диаграмм вариантов использования связано с последующей структуризацией ее отдельных компонентов в форме элементов других диаграмм. Например, конкретные особенности реализации вариантов использования в терминах взаимодействующих объектов, определенных в виде классов данной сущности, могут быть заданы на диаграмме кооперации. Указанное направление отражает основные особенности ООАП применительно к их реализации в языке UML. Эти особенности являются предметом рассмотрения во всех последующих главах книги.
Построение диаграммы вариантов использования является самым первым этапом процесса объектно-ориентированного анализа и проектирования, цель которого — представить совокупность требований к поведению проектируемой системы. Спецификация требований к проектируемой системе в форме диаграммы вариантов использования представляет собой самостоятельную модель, которая в языке UML получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип "useCaseModel".
В последующем все заданные в этой модели требования представляются в виде общей модели системы, которая состоит из пакета Системы. Последний в свою очередь может представлять собой иерархию пакетов, на самом верхнем уровне которых содержится множество классов модели проектируемой системы. Если же пакет системы со стандартным именем "topLevel Package" является подсистемой, то ее абстрактное поведение в точности такое же, как и у исходной системы.