- •Раздел 2.7 Использование uml-нотации для разработки баз данных
- •Тема 2.7.1 Основные понятия баз данных. Ключи, триггеры и хранимые процедуры Самостоятельная работа № 32 (2 часа)
- •Теоретические сведенья
- •Тема 2.7.2 Организация реляционной бд. Разновидности баз данных Самостоятельная работа № 33 (2 часа)
- •“Реляционные, древовидные и объектно-ориентированные базы данных” Артур б. Смит m. Computing May/June 1996, V.4 n.2
- •“Проектирование реляционных баз данных. Просто и доступно” Джен л.Харрингтон – издательство “Лори”, 2000.-230 с. Теоретические сведенья
- •Тема 2.7.3 Расширение uml для моделирования базы данных Самостоятельная работа № 34 (2 часа)
- •“Реляционные, древовидные и объектно-ориентированные базы данных” Артур б. Смит m. Computing May/June 1996, V.4 n.2
- •“Проектирование реляционных баз данных. Просто и доступно” Джен л.Харрингтон – издательство “Лори”, 2000.-230 с. Теоретические сведенья
- •Самостоятельная работа № 35 (2 часа)
- •“Реляционные, древовидные и объектно-ориентированные базы данных” Артур б. Смит m. Computing May/June 1996, V.4 n.2
- •“Проектирование реляционных баз данных. Просто и доступно” Джен л.Харрингтон – издательство “Лори”, 2000.-230 с. Теоретические сведенья
- •Тема 2.7.4. Особенности отображения свойств объектов и классов при моделировании баз данных. Моделирование бд. Самостоятельная работа № 36 (2 часа)
- •Теоретические сведенья
- •Раздел 2.8 Унифицированный процесс разработки объектно-ориентированных пс
- •Тема 2.8.1 Управление риском Самостоятельная работа № 37 (2 часа)
- •Теоретические сведенья
- •Идентификация риска
- •Анализ риска
- •Ранжирование риска
- •Планирование управления риском
- •Разрешение и наблюдение риска
- •Тема 2.8.2 Этапы унифицированного процесса разработки Самостоятельная работа № 38 (2 часа) Тема: Основные этапы унифицированного процесса разработки
- •Теоретические сведенья Этап начало (Inception)
- •Этап развитие (Elaboration)
- •Этап конструирование (Construction)
- •Этап переход (Transition)
- •Самостоятельная работа № 39 (4 часа) Тема: Пример объектно-ориентированной разработки
- •Теоретические сведенья
- •Этап начало
- •Этап развитие
- •Этап конструирование
- •Тема 2.8.3 Разработка в стиле экстремального программирования. Самостоятельная работа № 40 (2 часа) Тема: хр-реализация.
- •Теоретические сведенья
- •Элемент хр-разработки
- •Самостоятельная работа № 41 (2 часа)
- •Теоретические сведенья
- •Взаимодействие с заказчиком
- •Стоимость изменения и проектирование
Теоретические сведенья Этап начало (Inception)
Главное назначение этапа — запустить проект.
Цели этапа НАЧАЛО:
определить область применения проектируемой системы (ее предназначение, границы, интерфейсы с внешней средой, критерий признания — приемки);
определить элементы Use Case, критические для системы (основные сценарии поведения, задающие ее функциональность и покрывающие главные проектные решения);
определить общие черты архитектуры, обеспечивающей основные сценарии, создать демонстрационный макет;
определить общую стоимость и план всего проекта и обеспечить детализированные оценки для этапа развития;
идентифицировать основные элементы риска. Основные действия этапа НАЧАЛО:
формулировка области применения проекта — выявление требований и ограничений, рассматриваемых как критерий признания конечного продукта;
планирование и подготовка бизнес-варианта и альтернатив развития для управления риском, определение персонала, проектного плана, а также выявление зависимостей между стоимостью, планированием и полезностью;
синтезирование предварительной архитектуры, развитие компромиссных решений проектирования; определение решений разработки, покупки и повторного использования, для которых можно оценить стоимость, планирование и ресурсы.
В итоге этапа НАЧАЛО создаются следующие артефакты:
спецификация представления основных проектных требований, ключевых характеристик и главных ограничений;
начальная модель Use Case (20% от полного представления); а начальный словарь проекта;
начальный бизнес-вариант (содержание бизнеса, критерий успеха — прогноз дохода, прогноз рынка, финансовый прогноз);
начальное оценивание риска;
проектный план, в котором показаны этапы и итерации.
Этап развитие (Elaboration)
Главное назначение этапа — создать архитектурный базис системы.
Цели этапа РАЗВИТИЕ:
определить оставшиеся требования, функциональные требования формулировать как элементы Use Case;
определить архитектурную платформу системы;
отслеживать риск, устранить источники наибольшего риска;
разработать план итераций этапа КОНСТРУИРОВАНИЕ.
Основные действия этапа РАЗВИТИЕ:
развитие спецификации представления, полное формирование критических элементов Use Case, задающих дальнейшие решения;
развитие архитектуры, выделение ее компонентов.
В итоге этапа РАЗВИТИЕ создаются следующие артефакты:
модель Use Case (80% от полного представления);
дополнительные требования (нефункциональные требования, а также другие требования, которые не связаны с конкретным элементом Use Case);
описание программной архитектуры;
выполняемый архитектурный макет;
пересмотренный список элементов риска и пересмотренный бизнес-вариант;
план разработки для всего проекта, включающий крупноблочный проектный план и показывающий итерации и критерий эволюции для каждой итерации.
Обсудим более подробно главную цель этапа РАЗВИТИЕ — создание архитектурного базиса.
Архитектура объектно-ориентированной системы многомерна — она описывается множеством параллельных представлений. Как показано на рис. 2.8.2, обычно используется «4+1»-представление.
Рисунок 2.8.2 - «4+1»-представление архитектуры
Представление Use Case описывает систему как множество взаимодействий с точки зрения внешних актеров. Это представление создается на этапе НАЧАЛО жизненного цикла и управляет оставшейся частью процесса разработки.
Логическое представление содержит набор пакетов, классов и отношений. Изначально создается на этапе развития и усовершенствуется на этапе конструирования.
Представление процессов создается для параллельных программных систем, содержит процессы, потоки управления, межпроцессорные коммуникации и механизмы синхронизации. Представление изначально создается на этапе развития, усовершенствуется на этапе конструирования.
Представление реализации содержит модули и подсистемы. Представление изначально создается на этапе развития и усовершенствуется на этапе конструирования.
Представление размещения содержит физические узлы системы и соединения между узлами. Создается на этапе развития.
В качестве примера рассмотрим порядок создания логического представления архитектуры. Для решения этой задачи исследуются элементы Use Case, разработанные на этапе НАЧАЛО. Рассматриваются экземпляры элементов Use Case — сценарии. Каждый сценарий преобразуется в диаграмму последовательности. Далее в диаграммах последовательности выделяются объекты. Объекты группируются в классы. Классы могут группироваться в пакеты.
Согласно взаимодействиям между объектами в диаграммах последовательности устанавливаются отношения между классами. Для обеспечения функциональности в классы добавляются свойства (они определяют их структуру) и операторы (они определяют поведение). Для размещения общей структуры и поведения создаются суперклассы.
В качестве другого примера рассмотрим разработку плана итераций для этапа КОНСТРУИРОВАНИЕ. Такой план должен задавать управляемую серию архитектурных реализаций, каждая из которых увеличивает свои функциональные возможности, а конечная — покрывает все требования к полной системе. Главным источником информации являются элементы Use Case и диаграммы последовательности. Будем называть их обобщенно — сценариями. Сценарии группируются так, чтобы обеспечивать реализацию определенной функциональности системы. Кроме того, группировки должны устранять наибольший (в данный момент) риск в проекте.
План итераций включает в себя следующие шаги:
Определяются все элементы риска в проекте. Устанавливаются их приоритеты.
Выбирается группа сценариев, которым соответствуют элемент риска с наибольшим приоритетом. Сценарии исследуются. Порядок исследования определяется не только степенью риска, но и важностью для заказчика, а также потребностью ранней разработки базовых сценариев.
В результате анализа сценариев формируются классы и отношения, которые их реализуют.
Программируются сформированные классы и отношения.
Разрабатываются тестовые варианты.
Тестируются классы и отношения. Цель — проверить выполнение функционального назначения сценария.
Результаты объединяются с результатами предыдущих итераций, проводится тестирование интеграции.
Оценивается итерация. Выделяется необходимая повторная работа. Она назначается на будущую итерацию.
