Унифицированный процесс

Общие положения

1. УП управляется вариантами использования. Программная система создается в первую очередь для удовлетворения потребностей пользователей. Пользователь взаимодействует с системой посредством интерфейсных элементов. Выполняя определенную манипуляцию (например, нажатие кнопки в окне), он ожидает некоторой вполне определенной реакции от системы. Взаимодействие такого рода называется вариантом использования (прецедентом, use case). «Управляемый ВИ» означает, что весь процесс разработки порожден ими, предназначен для их реализации, тестируется ими, – всё в процессе подчинено удовлетворению ВИ и, соответственно, потребностей пользователя.

2. УП ориентирован на архитектуру. Понятие архитектуры программной системы достаточно объёмно и не имеет чёткого определения. Под архитектурой понимается набор некоторых взаимосвязанных(!) понятий, правил, документов, схем, программных компонент и т.п., которые являются принципиальными для построения системы. Для подобных блоков информации имеется специальный термин «артефакт». Артефакт – это любая порция информации в любом виде, которая создается, изменяется или используется в ходе выполнения проекта (примеры). Таким образом, архитектура – это набор взаимосвязанных артефактов проекта, существенных для построения системы.

Архитектура создается на основе требований (ВИ), она ориентирована на достижение главных целей проекта, используется для создания модулей (подсистем) системы, а также для учета интересов разработчиков (повторное использование, учет будущих изменений). УП уделяет большое внимание синтезу архитектуры и ориентирует все работы на её поддержку и взаимодействие подсистем через архитектуру. Значительная часть архитектуры системы обычно представлена в виде набора моделей. Эти модели выполняются с использованием унифицированных средств моделирования. Для УП таким средством является язык UML. Таким образом, UML является неотъемлемой частью УП.

3. УП является итеративным и инкрементным. УП относится к методологиям итеративного (спиралевидного) ЖЦ. Это означает «постепенную» разработку программы: сначала акцентируем внимание на наиболее важные ВИ, создаём архитектуру, призванную их реализовывать, затем постепенно наращиваем функциональность, постоянно при необходимости внося изменения в имеющуюся архитектуру.

Кроме того, УП является инкрементным процессом. Это означает, что по завершении каждой итерации мы получаем готовый к использованию (но ограниченный по функциональности) продукт. Следующая итерация дополняет его новыми возможностями или модифицирует имеющиеся, но в конце и этой итерации обязательно получается готовый к использованию программный продукт. Эти промежуточные продукты называются версиями или релизами.

4. УП ориентирован на командную разработку. Поскольку современные задачи, ставящиеся перед программным обеспечением, являются более масштабными, чем ранее (корпоративные системы), то и программное обеспечение становится более масштабным и сложным продуктом. Для его создания уже мало 1 программиста, как раньше. Как правило, сегодня над полномасштабными проектами работают коллективы в десятки и сотни человек, из которых программистами в том смысле слова, которое подразумевалось лет 20 назад, т.е. кодировщиками – создателями программного кода, являются от силы 10-20%. С тех пор в области программной инженерии появилось множество профессий, не связанных непосредственно с написанием кода программы – это системный аналитик, архитектор, инженер по вариантам использования и т.д. Таким образом, коллектив разработчиков осуществляет множество видов деятельности, и такому коллективу необходимо эффективное управление. УП является методологией именно коллективной работы над проектом и включает указания по распределению и организации работ. Однако УП может легко адаптироваться и для работы в коллективе из 1-2 человек. Это возможно благодаря тому, что каждый вид деятельности отнесен к определенной роли (профессии), при этом один человек может выполнять множество ролей в зависимости от выполняемого в данный момент вида деятельности.

Для поддержки эффективной коллективной работы над проектом УП настоятельно рекомендует использование вспомогательных инструментальных средств (утилит). Такие утилиты позволяют фиксировать изменения, вносимые каждым членом команды, совместно создавать модели, тестировать, писать программный код, поддерживать ведение документации.

5. УП предлагает контур процесса. Это означает, что разработчики могут модифицировать и адаптировать процесс под свои нужды, специфику команды или специфику разрабатываемого программного обеспечения. Это также означает, что необязательно создавать все документы, регламентированные УП, а сосредоточить основное внимание на наиболее важных. Однако незыблемыми принципами УП обязательно остаются ВИ, архитектура, итеративность и инкрементность.

Основные понятия объектно-ориентированного анализа, проектирования, программирования.

Объектно-ориентированный анализ и проектирование

Основная идея объектно-ориентированного анализа и проектирования (object-oriented analysis and design) состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов (понятий и сущностей). В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области. В процессе объектно-ориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и методы. И, наконец, в процессе конструирования (construction) или объектно-ориентированного программирования (object-oriented programming) обеспечивается реализация разработанных компонентов и классов.

Рассмотрим вкратце некоторые основные принципы объектно-ориентированного анализа и проектирования, в дальнейшем мы дадим более точные определения и более полную расшифровку всех рассмотренных терминов.

· С начала производится так называемый анализ требований (requirements analysis) во время которого выделяются основные процессы, происходящие в моделируемой системе и их формулировка в виде прецедентов. Прецедент (precedent)- это текстовое описание процессов, происходящих в предметной области.

· Шаг второй. Объектно-ориентированный анализ предметной области (object-oriented domain analysis). Задача этого шага в определении видов деятельности участников процесса и составлении концептуальной модели (conceptual model), которая отражает различные категории элементов предметной области. Причем не только виды деятельности участников, но и все относящиеся к делу понятия.

· Шаг третий. Разбираемся, кто, чем занимается. Эта деятельность и называется объектно-ориентированным проектированием (object-oriented design), при котором основное внимание сосредоточено на распределении обязанностей. Распределение обязанностей (responsibility assignment) означает выделение задач и обязанностей различных программных объектов в приложении.

Наиболее важным моментом объектно-ориентированного анализа и проектирования является квалифицированное распределение обязанностей между компонентами программной системы. Дело в том, что единственный вид деятельности, без которого невозможно обойтись. К тому же он оказывает определяющее влияние на робастность, масштабируемость, расширяемость и возможность повторного использования компонентов. Обязанности объектов и их взаимодействия изображаются с использованием диаграмм классов (design class diagram) и диаграмм взаимодействий (collaboration diagram).