Унифицированный процесс разработки объектно-ориентированных программных систем
Эволюционно-инкрементная организация жизненного цикла разработки объектно-ориентированного ПО. Назначение, цели, содержание и основные итоги каждого этапа унифицированного процесса разработки. Описание содержания ХР-процесса экстремальной разработки.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | реферат |
Язык | русский |
Дата добавления | 22.06.2009 |
Размер файла | 676,8 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
13
|
Федеральное агентство по рыболовству Федеральное государственное образовательное учреждение высшего профессионального образования «Астраханский государственный технический университет» Образовательная деятельность в сфере высшего и дополнительного профессионального образования сертифицирована DQS по ISO 9001 |
ИНСТИТУТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И КОММУНИКАЦИЙ
Реферат по дисциплине
«Разработка и стандартизация программных средств
и информационных технологий»
на тему:
«Унифицированный процесс разработки объектно-ориентированных ПС»
Студент гр. ДИП-21 |
||
____________ Д. В. Бестаев |
||
«____»_____________2009г. |
||
Руководитель ст. преподаватель ___________ Н.Д. Куркурин |
||
«____»______________2009г. |
Астрахань 2009Введение
В данном реферате внимание сосредоточено на детальном обсуждении унифицированного процесса разработки объектно-ориентированного ПО, на базе которого возможно построение самых разнообразных схем конструирования программных приложений. Далее описывается содержание ХР-процесса экстремальной разработки, являющегося носителем адаптивной технологии, применяемой в условиях частого изменения требований заказчика.
Эволюционно-инкрементная организация жизненного цикла разработки
Рассматриваемый подход является развитием спиральной модели Боэма [8], [40], [44], [57]. В этом случае процесс разработки программной системы организуется в виде эволюционно-инкрементного жизненного цикла. Эволюционная составляющая цикла основывается на доопределении требований в ходе работы, инкрементная составляющая - на планомерном приращении реализации требований.
В этом цикле разработка представляется как серия итераций, результаты которых развиваются от начального макета до конечной системы. Каждая итерация включает сбор требований, анализ, проектирование, реализацию и тестирование. Предполагается, что вначале известны не все требования, их дополнение и изменение осуществляется на всех итерациях жизненного цикла. Структура типовой итерации показана на рис. 15.1.
Видно, что критерием управления этим жизненным циклом является уменьшение риска. Работа начинается с оценки начального риска. В ходе выполнения каждой итерации риск пересматривается. Риск связывается с каждой итерацией так, что ее успешное завершение уменьшает риск. План последовательности реализаций гарантирует, что наибольший риск устраняется в первую очередь.
Такая методика построения системы нацелена на выявление и уменьшение риска в самом начале жизненного цикла. В итоге минимизируются затраты на уменьшение риска.
Как показано на рис. 15.2, в структуре унифицированного процесса разработки выделяют два измерения:
§ горизонтальная ось представляет время и демонстрирует характеристики жизненного цикла процесса;
§ вертикальная ось представляет рабочие потоки процесса, которые являются логическими группировками действий.
Первое измерение задает динамический аспект развития процесса в терминах циклов, этапов, итераций и контрольных вех. Второе измерение задает статический аспект процесса в терминах компонентов процесса, рабочих потоков, приводящих к выработке искусственных объектов (артефактов), и участников.
Рис. 15.1. Типовая итерация эволюционно-инкрементного жизненного цикла
Рис. 15.2. Два измерения унифицированного процесса разработки
Этапы унифицированного процесса разработки
Обсудим назначение, цели, содержание и основные итоги каждого этапа унифицированного процесса разработки.
Этап НАЧАЛО (Inception)
Главное назначение этапа - запустить проект.
Цели этапа НАЧАЛО:
§ определить область применения проектируемой системы (ее предназначение, границы, интерфейсы с внешней средой, критерий признания - приемки);
§ определить элементы Use Case, критические для системы (основные сценарии поведения, задающие ее функциональность и покрывающие главные проектные решения);
§ определить общие черты архитектуры, обеспечивающей основные сценарии, создать демонстрационный макет;
§ определить общую стоимость и план всего проекта и обеспечить детализированные оценки для этапа развития;
§ идентифицировать основные элементы риска. Основные действия этапа НАЧАЛО:
§ формулировка области применения проекта - выявление требований и ограничений, рассматриваемых как критерий признания конечного продукта;
§ планирование и подготовка бизнес-варианта и альтернатив развития для управления риском, определение персонала, проектного плана, а также выявление зависимостей между стоимостью, планированием и полезностью;
§ синтезирование предварительной архитектуры, развитие компромиссных решений проектирования; определение решений разработки, покупки и повторного использования, для которых можно оценить стоимость, планирование и ресурсы.
В итоге этапа НАЧАЛО создаются следующие артефакты:
§ спецификация представления основных проектных требований, ключевых характеристик и главных ограничений;
§ начальная модель Use Case (20% от полного представления);
§ начальный словарь проекта;
§ начальный бизнес-вариант (содержание бизнеса, критерий успеха - прогноз дохода, прогноз рынка, финансовый прогноз);
§ начальное оценивание риска;
§ проектный план, в котором показаны этапы и итерации.
Этап РАЗВИТИЕ (Elaboration)
Главное назначение этапа - создать архитектурный базис системы. Цели этапа РАЗВИТИЕ:
§ определить оставшиеся требования, функциональные требования формулировать как элементы Use Case;
§ определить архитектурную платформу системы; а отслеживать риск, устранить источники наибольшего риска; а разработать план итераций этапа КОНСТРУИРОВАНИЕ. Основные действия этапа РАЗВИТИЕ:
§ развитие спецификации представления, полное формирование критических элементов Use Case, задающих дальнейшие решения;
§ развитие архитектуры, выделение ее компонентов. В итоге этапа РАЗВИТИЕ создаются следующие артефакты: а модель Use Case (80% от полного представления);
§ дополнительные требования (нефункциональные требования, а также другие требования, которые не связаны с конкретным элементом Use Case);
§ описание программной архитектуры; а выполняемый архитектурный макет;
§ пересмотренный список элементов риска и пересмотренный бизнес-вариант;
§ план разработки для всего проекта, включающий крупноблочный проектный план и показывающий итерации и критерий эволюции для каждой итерации.
Обсудим более подробно главную цель этапа РАЗВИТИЕ - создание архитектурного базиса.
Архитектура объектно-ориентированной системы многомерна - она описывается множеством параллельных представлений. Как показано на рис. 15.4, обычно используется "4+1"-представление [44].
Рис. 15.4. "4+1 "-представление архитектуры
Представление Use Case описывает систему как множество взаимодействий с точки зрения внешних актеров. Это представление создается на этапе НАЧАЛО жизненного цикла и управляет оставшейся частью процесса разработки.
Логическое представление содержит набор пакетов, классов и отношений. Изначально создается на этапе развития и усовершенствуется на этапе конструирования.
Представление процессов создается для параллельных программных систем, содержит процессы, потоки управления, межпроцессорные коммуникаций и механизмы синхронизации. Представление изначально создается на этапе развития, усовершенствуется на этапе конструирования.
Представление реализации содержит модули и подсистемы. Представление изначально создается на этапе развития и усовершенствуется на этапе конструирования.
Представление размещения содержит физические узлы системы и соединения между узлами. Создается на этапе развития.
В качестве примера рассмотрим порядок создания логического представления архитектуры. Для решения этой задачи исследуются элементы Use Case, разработанные на этапе НАЧАЛО. Рассматриваются экземпляры элементов Use Case - сценарии. Каждый сценарий преобразуется в диаграмму последовательности. Далее в диаграммах последовательности выделяются объекты. Объекты группируются в классы. Классы могут группироваться в пакеты.
Согласно взаимодействиям между объектами в диаграммах последовательности устанавливаются отношения между классами. Для обеспечения функциональности в классы добавляются свойства (они определяют их структуру) и операторы (они определяют поведение). Для размещения общей структуры и поведения создаются суперклассы.
В качестве другого примера рассмотрим разработку плана итераций для этапа КОНСТРУИРОВАНИЕ. Такой план должен задавать управляемую серию архитектурных реализаций, каждая из которых увеличивает свои функциональные возможности, а конечная - покрывает все требования к полной системе. Главным источником информации являются элементы Use Case и диаграммы последовательности. Будем называть их обобщенно - сценариями. Сценарии группируются так, чтобы обеспечивать реализацию определенной функциональности системы. Кроме того, группировки должны устранять наибольший (в данный момент) риск в проекте.
План итераций включает в себя следующие шаги:
1. Определяются все элементы риска в проекте. Устанавливаются их приоритеты.
2. Выбирается группа сценариев, которым соответствуют элемент риска с наибольшим приоритетом. Сценарии исследуются. Порядок исследования определяется не только степенью риска, но и важностью для заказчика, а также потребностью ранней разработки базовых сценариев.
3. В результате анализа сценариев формируются классы и отношения, которые их реализуют.
4. Программируются сформированные классы и отношения.
5. Разрабатываются тестовые варианты.
6. Тестируются классы и отношения. Цель - проверить выполнение функционального назначения сценария.
7. Результаты объединяются с результатами предыдущих итераций, проводится тестирование интеграции.
8. Оценивается итерация. Выделяется необходимая повторная работа. Она назначается на будущую итерацию.
Этап КОНСТРУИРОВАНИЕ (Construction)
Главное назначение этапа - создать программный продукт, который обеспечивает начальные операционные возможности.
Цели этапа КОНСТРУИРОВАНИЕ:
§ минимизировать стоимость разработки путем оптимизации ресурсов и устранения необходимости доработок;
§ добиться быстрого получения приемлемого качества;
§ добиться быстрого получения контрольных версий (альфа, бета и т. д.).
Основные действия этапа КОНСТРУИРОВАНИЕ:
§ управление ресурсами, контроль ресурсов, оптимизация процессов;
§ полная разработка компонентов и их тестирование (по сформулированному критерию эволюции);
§ оценивание реализаций продукта (по критерию признания из спецификации представления).
В итоге этапа КОНСТРУИРОВАНИЕ создаются следующие артефакты:
§ программный продукт, готовый для передачи в руки конечных пользователей;
§ описание текущей реализации;
§ руководство пользователя.
Реализации продукта создаются в серии итераций. Каждая итерация выделяет конкретный набор элементов риска, выявленных на этапе развития. Обычно в итерации реализуется один или несколько элементов Use Case. Типовая итерация включает следующие действия:
1. Идентификация реализуемых классов и отношений.
2. Определение в классах типов данных (для свойств) и сигнатур (для операций). Добавление сервисных операций, например операций доступа и управления. Добавление сервисных классов (классов-контейнеров, классов-контроллеров). Реализация отношений ассоциации, агрегации и наследования.
3. Создание текста на языке программирования.
4. Создание (обновление) документации.
5. Тестирование функций реализации продукта.
6. Объединение текущей и предыдущей реализаций. Тестирование итерации.
Этап ПЕРЕХОД (Transition)
Главное назначение этапа - применить программный продукт в среде пользователей и завершить реализацию продукта.
Этап начинается с предъявления пользователям бета-реализации продукта. В ней обнаруживаются ошибки, они корректируются в последующих бета-реализациях. Параллельно решаются вопросы размещения, упаковки и сопровождения продукта. После завершения бета-периода тестирования продукт считается реализованным.
Оценка качества проектирования
Качество проектирования оценивают с помощью объектно-ориентированных метрик, введенных в главе 14.
Этап РАЗВИТИЕ
Качество логического представления архитектуры оценивают по метрикам:
§ WMC - взвешенные методы на класс;
§ NO С - количество детей;
§ DIT - высота дерева наследования;
§ NO M - суммарное количество методов, определенных во всех классах системы;
§ NC - общее количество классов в системе.
Метрики WMC, NOC вычисляются для каждого класса, кроме того, формируются их средние значения в системе. Метрики DIT, NOM, NC вычисляются для всей системы.
Этап КОНСТРУИРОВАНИЕ
На каждой итерации конструирования продукта вычисляются метрики:
§ WMC - взвешенные методы на класс;
§ NOC - количество детей;
§ СВО - сцепление между классами объектов;
§ RFC - отклик для класса;
§ LCOM - недостаток связности в методах;
§ CS - размер класса;
§ NO О - количество операций, переопределяемых подклассом;
§ NOA - количество операций, добавленных подклассом;
§ SI - индекс специализации;
§ OSavg - средний размер операции;
§ NPavg - среднее количество параметров на операцию;
§ NC - общее количество классов в системе;
§ LOC - суммарная LOC-оценка всех методов системы;
§ DIT - высота дерева наследования;
§ NOM - суммарное количество методов в системе.
Метрики WMC, NOC, СВО, RFC, LCOM, CS, NOO, NOA, SI, OSAVG, NPAVG вычисляются для каждого класса, кроме того, формируются их средние значения в системе. Метрики DIT, NOM, NC, LОС? вычисляются для всей системы.
На последней итерации дополнительно вычисляется набор метрик MOOD, предложенный Абреу:
§ МНР - фактор закрытости метода;
§ AHF - фактор закрытости свойства;
§ MIF - фактор наследования метода;
§ AIF - фактор наследования свойства;
§ POF - фактор полиморфизма;
§ COF - фактор сцепления.
§
Заключение
В свою очередь, каждый этап процесса разделяется на итерации. Итерация - это полный цикл разработки, вырабатывающий промежуточный продукт. По мере перехода от итерации к итерации промежуточный продукт инкрементно усложняется, постепенно превращаясь в конечную систему. В состав каждой итерации входят все рабочие потоки - от сбора требований до тестирования. От итерации к итерации меняется лишь удельный вес каждого рабочего потока - он зависит от этапа. На этапе Начало основное внимание уделяется сбору требований, на этапе Развитие - анализу и проектированию, на этапе Конструирование - реализации, на этапе Переход - тестированию. Каждый этап и итерация уменьшают некоторый риск и завершается контрольной вехой. К вехе привязывается техническая проверка степени достижения ключевых целей. По результатам проверки возможна модификация дальнейших действий.
Подобные документы
Особенности исследования методик объектно-ориентированного проектирования программ с помощью языка UML по формализации, решению поставленной задачи, технологических приемов разработки объектно-ориентированных программ на языке Си++. Разработка программы.
контрольная работа [188,9 K], добавлен 22.10.2014Использование объектно-ориентированного программирования - хорошее решение при разработке крупных программных проектов. Объект и класс как основа объектно-ориентированного языка. Понятие объектно-ориентированных языков. Языки и программное окружение.
контрольная работа [60,1 K], добавлен 17.01.2011Приемы и правила объектно-ориентированного программирования с использованием языка С++. Общие принципы разработки объектно-ориентированных программ. Основные конструкции языка С++. Разработка различных программ для Windows с использованием WIN32 API.
учебное пособие [1,6 M], добавлен 28.12.2013Особенности разработки информационных систем с использованием унифицированного языка моделирования UML. Основные этапы рационального унифицированного процесса разработки информационных систем с примерами и иллюстрациями. Реализация информационной системы.
методичка [950,2 K], добавлен 23.01.2014Методика разработки объектно-ориентированной модели информационной подсистемы необходимой для учета успеваемости студентов факультета, которая спроектирована с помощью программного продукта Rational Rose 2003 и унифицированного языка моделирования UML.
курсовая работа [183,9 K], добавлен 25.06.2011Общая характеристика основных моделей жизненного цикла: каскадная, инкрементная, спиральная. Стадия как часть процесса создания программного обеспечения, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта.
презентация [159,1 K], добавлен 27.12.2013Основные элементы объектной модели. Сущность и преимущества объектно-ориентированного подхода, понятие объекта и класса. Унифицированный язык моделирования UML. Диаграммы классов и взаимодействия: назначение, построение и примеры использования.
реферат [273,2 K], добавлен 09.06.2009Характеристика UML как унифицированного графического языка моделирования для описания, визуализации, проектирования и документирования объектно-ориентированных систем. Диаграмма программного обеспечения, деятельности, последовательности и реализации UML.
курсовая работа [439,9 K], добавлен 05.06.2014Использование скриптового языка программирования для разработки web-приложений (сценариев). Изучение основ объектно-ориентированного программирования в языке PHP. Ознакомление со специальными методами для работы с классами. Назначение интерфейсов.
контрольная работа [25,1 K], добавлен 14.03.2015Создание программы, реализующей игру "Линии". Среда разработки программы, описание ее общего вида. Основные алгоритмы программы. Реализация программы в среде разработки Microsoft Visual Studio 2008 на языке объектно-ориентированного программирования С++.
курсовая работа [639,0 K], добавлен 16.03.2012