- •Технология разработки
- •Введение
- •Жизненный цикл программных систем План лекции
- •Введение
- •Программа, программная система. Программный продукт. Программная система как технологический объект.
- •Понятие жизненного цикла программных систем
- •Модели жизненного цикла программного обеспечения
- •Фазы жизненного цикла по
- •Заключение
- •Прикладной системный анализ при разработке по. Принципы структурного анализа. Процедура требований
- •План лекции
- •Введение
- •Проблема сложности ис
- •Группы средств моделирования систем
- •Заключение
- •Моделирование функций по. Нотация 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-ххх «Информационная технология»
- •Группы процессов
- •Взаимосвязи процессов
- •Процессы инициации
- •Результаты
- •Исходная информация
- •Шаги задачи
- •Методика и подход
- •Выработать основные положения проекта
- •Определить область применения, цели и подход
- •Произвести оценку рисков
- •Получить подтверждение Заказчика и Исполнителя
- •Роли и ответственность
- •Заключение
- •Рабочий план
- •План лекции
- •Введение
- •Основные процессы планирования
- •Вспомогательные процессы планирования
- •Документ «Рабочий план»
- •По работам
- •По исполнителям
- •Диаграмма Гантта по проекту
- •Процессы управления
- •Основные процессы управления
- •Вспомогательные процессы управления
- •Основные процессы анализа
- •Вспомогательные процессы анализа
- •Заключение Заключение
- •Контрольные вопросы
- •Библиографический список
Пакеты в языке uml
Пакет — основной способ организации элементов модели в языке UML. Каждый пакет владеет всеми своими элементами, т. е. теми элементами, которые включены в него. Про соответствующие элементы пакета говорят, что они принадлежат пакету или входят в него. При этом каждый элемент может принадлежать только одному пакету. В свою очередь, одни пакеты могут быть вложены в другие пакеты. В этом случае первые называются подпаке-тами, поскольку все элементы подпакета будут принадлежать более общему пакету. Тем самым для элементов модели задается отношение вложенности пакетов, которое представляет собой иерархию.
Примечание При рассмотрении отношения "пакет-подпакет" наиболее естественно ассоциировать его с более общим отношением "множество-подмножество". Действительно, поскольку пакет можно рассматривать в качестве частного случая множества, такая интерпретация помогает нам использовать и графические средства для представления соответствующих отношений между пакетами.
Нам также известно, что для графического представления иерархий могут использоваться графы специального вида, которые называются деревьями. Однако в языке UML эти графические обозначения настолько модифицированы, что соответствующие ассоциации с общетеоретическими понятиями могут представлять определенную трудность для начинающих разработчиков. Тем не менее, на протяжении всей книги подчеркивается важность умения ассоциировать специальные конструкции языка UML с соответствующими понятиями теории множеств и системного моделирования, что, в некотором смысле, формирует стиль мышления системного аналитика. В противном случае не исключены досадные ошибки не только на начальном этапе концептуализации предметной области, но и в процессе построений различных представлений систем.
В языке UML для визуализации пакетов разработана специальная символика или графическая нотация, которой мы и будем пользоваться в дальнейшем. Именно с описания этой системы обозначений мы приступим к изучению основных элементов данного языка.
Для графического изображения пакетов на диаграммах применяется специальный графический символ — большой прямоугольник с небольшим прямоугольником, присоединенным к левой части верхней стороны первого (рис. 3.2 а, б). Можно сказать, что визуально символ пакета напоминает пиктограмму папки в популярном графическом интерфейсе. Внутри большого прямоугольника может записываться информация, относящаяся к данному пакету. Если такой информации нет, то внутри большого прямоугольника записывается имя пакета, которое должно быть уникальным в пределах рассматриваемой модели (рис. 3.2, а). Если же такая информация имеется, то имя пакета записывается в верхнем маленьком прямоугольнике (рис. 26).
Графическое изображение пакета в языке UML
Примечание Говоря об имени пакета, следует остановиться на общем соглашении об именах в языке UML. В данном случае именем пакета может быть строка (или несколько строк) текста, содержащее любое число букв, цифр и некоторых специальных знаков. С целью удобства спецификации пакетов принято в качестве их имен использовать одно или несколько существительных, например, контроллер, графический интерфейс, форма ввода данных.
Перед именем пакета может помещаться строка текста, содержащая некоторое ключевое слово. Подобными ключевыми словами являются заранее определенные в языке UML слова, которые получили название стереотипов. Такими стереотипами для пакетов являются слова facade, framework, stub и topLevel. В качестве содержимого пакета могут выступать имена его отдельных элементов и их свойства, такие как видимость элементов за пределами пакета. Более подробно стереотипы и видимость элементов будут рассмотрены в последующих главах книги.
Конечно, сами по себе пакеты могут найти ограниченное применение, поскольку содержат лишь информацию о входящих в их состав элементах модели. Не менее важно представить графически отношения, которые могут иметь место между отдельными пакетами. Как и в теории графов, для визуализации отношений в языке UML применяются отрезки линий, внешний вид которых имеет смысловое содержание.
Одним из типов отношений между пакетами является отношение вложенности или включения пакетов друг в друга. С одной стороны, в языке UML это отношение может быть изображено без использования линий простым размещением одного пакета-прямоугольника внутри другого пакета-прямоугольника (рис. 3.3). Так, в данном случае пакет с именем ПакетЛ содержит в себе два подпакета: Пакет_2 и Пакет_3.
Графическое изображение вложенности пакетов друг в друга
Графическое изображение вложенности пакетов друг в друга с помощью явной визуализации отношения включения
С другой стороны, это же отношение может быть изображено с помощью отрезков линий аналогично графическому представлению дерева. В этом случае наиболее общий пакет (метапакет или контейнер) изображается в верхней части рисунка, а его подпакеты — уровнем ниже. Метапакет соединяется с подпакетами сплошной линией, на конце которой, примыкающей к метапакету, изображается специальный символ © (знак плюс в кружочке). Этот символ означает, что подпакеты являются "собственностью" или частью контейнера, и, кроме этих подпакетов, контейнер не содержит никаких других подпакетов. Рассмотренный выше пример (рис. 27) может быть представлен с помощью явной визуализации отношения включения (рис. 28).
На графических диаграммах между пакетами могут указываться и другие типы отношений, часть из которых будут рассмотрены с последующих главах книги.