Автор: Пользователь скрыл имя, 28 Сентября 2011 в 22:47, курсовая работа
Сегодня развитие программного обеспечения происходит в сторону увеличения и усложнения систем. Это связано отчасти с тем, что компьютеры с каждым годом становятся все мощнее, что побуждает пользователей ожидать от них все большего. Эта тенденция также связана с возрастающим использованием Интернета для обмена всеми видами информации — от простого текста до форматированного текста, изображений, диаграмм и мультимедиа. Наши аппетиты в отношении более продвинутого программного обеспечения растут по мере того, как мы начинаем понимать с выходом каждого следующего выпуска, как еще можно улучшить этот продукт. Мы желаем иметь программное обеспечение, еще лучше приспособленное для наших нужд, а это, в свою очередь, приводит к усложнению программ. Короче говоря, мы желаем большего.
1 Унифицированный процесс: управляемый вариантами использования, архитектурно- ориентированный, итеративный и инкрементный 2
1.1 Введение 2
1.2 Унифицированный процесс в двух словах 3
1.3 Унифицированный процесс управляется вариантами использования 5
1.4 Унифицированный процесс ориентирован на архитектуру 6
1.5 Унифицированный процесс является интеративным и инкрементным 9
1.6 Жизненный цикл Унифицированного процесса 12
1.6.1 Продукт 12
1.6.2 Разделение цикла на фазы 15
1.7 Интегрированный процесс 19
2 Процесс, направляемый вариантами использования 20
2.1 Введение в разработку управляемую вариантами использования 22
2.2 Необходимость вариантов использования 26
2.3 Определение вариантов использования 27
2.4 Анализ, проектирование и разработка при реализации варианта использования 27
2.4.1 Создание по вариантам использования аналитической модели 28
2.5 Тестирование вариантов использования 29
2.6 Резюме 32
3 Архитектурно-центрированный процесс 33
3.1 Введение в архитектуру 33
3.2 Необходимость архитектуры 35
3.3 Варианты использования и архитектура 36
3.4 Описание архитектуры 40
4 Интеративный и инкрементный процесс 42
4.1 Введение в итеративность и инкрементность 42
4.2 Необходимость использования итеративной и инкрементной разработки 42
4.3 Итеративный подход управляемый рисками 43
4.4 Обобщенная итерация 44
5 Заключение 46
6 Список использованной литературы 47
Поэтому архитектура определяется в виде представлений всех моделей системы, которые в сумме представляют систему целиком. Это означает, что существуют архитектурные представления модели вариантов использования, модели анализа, модели проектирования, модели реализации и модели развертывания. Представление модели реализации включает в себя компоненты для доказательства того, что архитектура выполнима. В ходе этой фазы определяются наиболее критичные варианты использования. Результатом выполнения этой фазы является базовый уровень архитектуры.
В конце
фазы проектирования менеджер проекта
занимается планированием действий
и подсчетом ресурсов, необходимым
для завершения проекта. Ключевым
вопросом в этот момент будет следующий:
достаточно ли проработаны варианты
использования, архитектура и план,
и взяты ли риски под контроль
настолько, чтобы можно было давать
контрактные обязательства
В ходе фазы построения происходит создание продукта — к скелету (архитектуре) добавляются мышцы (законченные программы). На этой фазе базовый уровень архитектуры разрастается до полной развитой системы. Концепции развиваются до продукта, готового к передаче пользователям. В ходе фазы разработки объем требуемых ресурсов вырастает. Архитектура системы стабильна, однако, поскольку разработчики могут найти лучшие способы структурирования системы, от них могут исходить предложения о внесении в архитектуру системы небольших изменений. В конце этой фазы продукт включает в себя все варианты использования, которые руководство и заказчик договорились включить в текущий выпуск. Правда, они могут содержать ошибки. Большинство дефектов будут обнаружены и исправлены в ходе фазы внедрения. Ключевой вопрос окончания фазы: удовлетворяет ли продукт требованиям пользователей настолько, что некоторым заказчикам можно делать предварительную поставку?
Фаза внедрения охватывает период, в ходе которого продукт существует в виде бета-выпуска или бета-версии. Небольшое число квалифицированных пользователей, работая с бета-выпуском продукта, сообщает об обнаруженных дефектах и недостатках. После этого разработчики исправляют обнаруженные ошибки и вносят некоторые из предложенных улучшений в главный выпуск, подготавливаемый для широкого распространения. Фаза внедрения включает в себя такие действия, как производство тиража, тренинг сотрудников заказчика, организацию поддержки по горячей линии и исправление дефектов, обнаруженных после поставки. Команда поддержки часто разделяет найденные дефекты на две категории: дефекты, оказывающие настолько значительный эффект на работу с программой, что это оправдывает немедленный выпуск дельта-версии, и дефекты, исправление которых можно отложить до следующего выпуска.
Унифицированный
процесс основан на компонентах.
Он использует новый стандарт визуального
моделирования. Унифицированный язык
моделирования и базируется на трех
ключевых идеях — вариантах
Задача Унифицированного процесса — предоставлять разработчикам план эффективного создания и развертывания систем, удовлетворяющих требованиям пользователя. Эффективность при этом измеряется в понятиях стоимости, качества и затраченного времени. Путь от получения требований заказчика до реализации непрост. Проблемы начинаются с определения требований заказчиков. Этот процесс предполагает, что мы способны определить требования пользователей и довести их без ошибок до всех участников проекта. После этого мы должны быть в состоянии спроектировать работающую реализацию, которая выполняла бы эти требования. И наконец, мы должны протестировать созданную систему, чтобы удостоверится в том, что требования пользователей выполнены. Сложность процесса заставляет нас описывать его в виде серии рабочих процессов, последовательно создающих работающую систему.
На рис. 3.1 изображена последовательность рабочих процессов и моделей Унифицированного процесса. Разработчики начинают с определения требований заказчика в виде вариантов использования и формирования на их основе модели вариантов использования. Затем они анализируют и проектируют систему, осуществляющую эти варианты использования, строя сначала модель анализа, а затем модели проектирования и развертывания. После этого они реализуют систему, получая модель реализации, которая содержит весь код проекта в виде компонентов. В конце разработчики создают модель тестирования, которая позволяет им проверить, обеспечивает ли система функциональность, описанную в вариантах использования. Все модели связаны между собой зависимостями трассировки. Модель реализации наиболее формальна, а самая неформальная модель — это модель вариантов использования. Происходит это потому, что модель реализации создается на компьютерном языке, то есть части модели реализации после компиляции и компоновки превращаются в исполняемые файлы, тогда как в модели вариантов использования применяется в основном естественный язык.
Варианты использования были разработаны в качестве почти универсального средства для определения требований к любым программным системам, в том числе и собираемым из компонентов, но с их помощью можно не только определять требования. Они направляют весь процесс разработки. Варианты использования вносят значительный вклад в поиск и описание классов, подсистем и интерфейсов, а также в поиск и описание вариантов тестирования, планирование итераций разработки и системной интеграции.
На каждой итерации они направляют выполнение всех рабочих процессов, от определения требований через анализ, проектирование и реализацию до тестирования. Таким образом они связывают различные рабочие процессы между собой.
Определение требований преследует две цели: определить существенные требования и представить их в форме, удобной для пользователей, заказчиков и разработчиков. Под «существенными требованиями» мы понимаем те требования, реализация которых принесет пользователям ощутимый и значимый для них результат. Под «представлением в форме, удобной для пользователей, заказчиков и разработчиков» мы понимаем главным образом то, что итоговое описание требований должны понимать пользователи и заказчики. Это один из главных результатов рабочего процесса определения требований.
Обычно у системы имеется несколько категорий пользователей. Каждая категория пользователей представляется в виде актанта. Актанты используют систему, участвуя в вариантах использования. Вариант использования — это последовательность действий, которые система предпринимает для получения актантом ценного для него результата. Полный набор актантов и вариантов использования системы образует модель вариантов использования.
В ходе анализа и проектирования модель вариантов использования преобразуется в модель анализа, а затем в модель проектирования. Если говорить коротко, и модель анализа, и модель проектирования — это структуры, построенные на основе классификаторов и набора реализаций вариантов использования, которые определяют, как эти структуры реализуют варианты использования. Классификаторы в основном представляют собой «классоподобные» сущности. Так, они содержат атрибуты и операции, их можно описывать с помощью диаграмм состояний некоторые из них допускают создание экземпляров, они могут участвовать в кооперациях и т. п. В UML существует множество типов классификаторов. Примерами классификаторов для этих моделей могут быть подсистемы, классы и интерфейсы. Актанты, варианты использования, компоненты и узлы также являются классификаторами.
Модель
анализа — это детальное
Модель проектирования имеет следующие свойства:
Разработчики создают модель анализа, используя модель вариантов использования в качестве исходных данных. Каждый вариант использования из модели вариантов использования превращается в реализацию варианта использования модели анализа. Дуализм вариантов использования/реализаций вариантов использования позволяет соблюсти полное подобие между определением требований и анализом. Прорабатывая варианты использования один за другим, разработчики идентифицируют классы, участвующие в реализации вариантов использования. Вариант использования Получить наличные, например, превращается в классы анализа Получение, Банковский счет, Устройство выдачи и еще несколько классов, которые мы пока идентифицировать не будем. Разработчики выделяют ответственности конкретных классов в ответственностях определенных в вариантах использования. В нашем примере класс Банковский счет будет нести ответственность за выполнение операции «Списать деньги со счета». Таким образом, мы можем убедиться в том, что получили набор классов, совместно реализующих варианты использования и действительно необходимых.
Затем разработчики проектируют классы и реализации вариантов использования для того, чтобы лучше понять, какие продукты и технологии следует использовать для построения системы (брокеры объектных запросов, библиотеки для создания графического интерфейса пользователя, СУБД). Классы проектирования собираются в подсистемы, и между этими подсистемами определяются интерфейсы. Разработчики также создают модель развертывания, которая определяет физическое распределение частей системы по узлам — отдельным компьютерам сети — и проверяют, могут ли варианты использования быть реализованы в виде компонентов, выполняемых на этих узлах. Далее, разработчики реализуют спроектированные классы в виде набора файлов с исходным текстом компонентов, из которых, если их скомпилировать и скомпоновать, можно получить исполняемый код — DLL, JavaBeans или ActiveX. Варианты использования помогают разработчикам определить порядок создания компонентов и включения их в систему.
И наконец, в ходе рабочего процесса тестирования тестеры проверяют, действительно ли система выполняет функции, определенные вариантами использования, и удовлетворяет требованиям к системе. Модель тестирования содержит тестовые примеры. Тестовый пример определяет набор исходных данных, условий выполнения и результатов. Множество тестовых примеров могут быть порождены прямо из вариантов использования, таким образом, мы можем говорить об отношении трассировки между тестовыми примерами и соответствующими вариантами использования. Это означает, что тестеры будут проверять, делает ли система то, чего хотят от нее пользователи, то есть выполняет ли она варианты использования. Каждый, тестировавший в прошлом программное обеспечение, фактически тестировал варианты использования, — хотя тогда это и называлось иначе. А вот что в Унифицированном процессе действительно изменилось, так это то, что теперь тестирование можно планировать гораздо раньше. Сразу же после определения вариантов использования можно начинать создание тестов вариантов использования (тесты для «черного ящика») и задавать порядок их выполнения, включения в систему и тестирования. Позднее, после реализации вариантов использования в ходе проектирования, можно детализировать тесты вариантов использования (тесты для «белого ящика»). Каждый способ выполнения варианта использования, а значит, каждый путь реализации варианта использования, является кандидатом на тестовый пример.
Существует несколько объяснений удобства, популярности и повсеместного применения вариантов использования. Две основные причины таковы:
Информация о работе Унифицированный процесс разработки программного обеспесчения