Унифицированный процесс разработки программного обеспесчения

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

     Мы  нуждаемся в архитектуре для  того, чтобы:

• понять систему;
• организовать разработку;
• способствовать повторному использованию кода;
• развивать систему в дальнейшем.

3. Варианты  использования и  архитектура

 

     Уточним, как происходит этот процесс, рассмотрев сначала, что оказывает влияние на архитектуру (рис. 4.1), а затем — какие факторы влияют на варианты использования.

       

     Варианты использования — это направляющие для архитектуры. В конце концов, мы хотим иметь архитектуру, которая является подходящей для осуществления наших вариантов использования. На ранних итерациях мы выбираем несколько вариантов использования, которые, как мы полагаем, позволят нам наилучшим образом разработать архитектуру. Эти важные для создания архитектуры варианты использования будут включать те, которые необходимы  клиентам в текущем выпуске и, возможно, в последующих выпусках.

     Однако  на архитектуру будут влиять не только важные для архитектуры варианты использования, но и другие факторы:

• Системное программное обеспечение, которым мы хотим пользоваться для построения системы (например, операционной системой или СУБД).
• Программное обеспечение среднего уровня, которое мы хотим использовать. Например, мы должны выбрать брокер объектных запросов, предоставляющий механизм прозрачного маршалинга и доставки сообщений распределенным объектам в гетерогенных средах или платформо-независимый каркас для создания пользовательского графического интерфейса.
• Унаследованные системы, которые войдут в нашу систему. Включая унаследованную систему, например   существующую  банковскую  систему,  в наш программный комплекс, мы можем повторно использовать множество существующих функций, но будем вынуждены приспосабливать нашу архитектуру к старому продукту.
• Стандарты и правила компании, которые мы должны соблюдать. Например, мы можем быть вынуждены использовать язык определения интерфейсов IDL , созданный OMG для определения интерфейсов к классам или стандарт телекоммуникаций TMN — для определения объектов системы.
• Общие нефункциональные требования (то есть не привязанные к конкретному варианту использования), типа требований к доступности, времени восстановления или потребления памяти.
• Требования к распределению, определяющие, как система распределяется   по компьютерам, например согласно архитектуре клиент/сервер.

 

     Разработка  архитектуры происходит на итерациях  фазы проектирования. Упрощенный, немного наивный подход — мысленная модель — осуществляется следующим образом. Мы начинаем с определения  типа архитектуры, например послойной архитектуры После этого в течение нескольких билдов первой итерации мы создаем архитектуру.

     В первом билде мы работаем с частями  общего уровня приложений

которые являются общими для предметной области и не специфичны для системы, которую мы собираемся разрабатывать. Имеется в виду, что мы выбираем системное программное обеспечение, средний уровень, наследуемые системы, используемые стандарты и правила. Мы решаем, какие узлы будут присутствовать в нашей модели развертывания и как они должны взаимодействовать друг с другом. Мы решаем, как удовлетворить общие нефункциональные требования, например требования по доступности. На этом первом проходе достаточно будет добиться общего понимания приложения.

     Во  втором билде мы работаем с архитектурой специфического уровня приложения. Мы выбираем комплект архитектурно значимых вариантов использования, определяем требования, анализируем их, проводим проектирование, реализуем и тестируем их. Результатом будут новые подсистемы, реализованные в виде компонентов. Они создаются для   поддержки выбранных нами вариантов использования. Кроме того, теперь, рассмотрев систему в понятиях вариантов использования, мы можем захотеть внести некоторые изменения в архитектурно значимые компоненты, выбранные во время первого билда. Для реализации вариантов использования создаются новые компоненты и изменяются старые. Таким образом мы адаптируем архитектуру для лучшего удовлетворения вариантам использования. Затем мы делаем следующий билд, затем еще и еще, пока не закончим итерацию. Когда фаза проектирования заканчивается, архитектура должна быть стабилизирована.

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

     

     Чтобы лучше определять новые варианты использования, мы применяем наше знание архитектуры. Когда мы оцениваем ценность каждого предложенного варианта использования и затраты на него, мы делаем это применительно к существующей архитектуре. Некоторые варианты использования будут легко осуществимы, в то время как осуществить другие будет затруднительно.

4. Описание  архитектуры

 

     Базовый уровень  архитектуры, разработанный во время фазы проектирования, сохраняется, в форме описания архитектуры. Описание архитектуры — это выдержка или, как мы говорим, набор представлений — возможно, аккуратно приведенный в удобный для чтения вид моделей базового уровня архитектуры. Представления моделей содержат существенные для архитектуры элементы. Множество элементов моделей, входящих в базовый уровень архитектуры, разумеется, войдет также и в описание архитектуры. Однако в описание архитектуры войдут не все элементы базового уровня, потому что для получения работающего базового уровня мы вынуждены были разработать некоторые элементы моделей, не существенные для архитектуры, но необходимые для создания исполняемого кода. Так как базовый уровень архитектуры используется не только для разработки архитектуры, но и для определения требований к системе на таком уровне, когда возможно создание детального плана, модель варианта использования этого базового уровня также может содержать не только те варианты использования, которые важны для построения архитектуры.

     Описание  архитектуры будет поддерживаться актуальным в течение всего времени жизни системы, отражая вносимые изменения и дополнения, которые существенны для архитектуры. Эти изменения обычно незначительны и могут включать в себя:

• обнаружение новых абстрактных классов и интерфейсов;
• добавление  новых функциональных   возможностей   к существующим  подсистемам;
• обновление компонентов многократного использования до новых версий;

перестройку структуры  процесса. 

4. Интеративный  и инкрементный процесс

1. Введение  в итеративность  и инкрементность

 

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

2. Необходимость использования итеративной  и инкрементной разработки

 

     В трех словах: программы получаются лучше. Немного более развернуто: чтобы  пройти главные и вспомогательные  вехи, по которым мы контролируем ход разработки. И еще более развернуто.

• Чтобы как можно раньше получить описание критических и опасных рисков.
• Чтобы сформулировать архитектуру для создания программного обеспечения.
• Чтобы обеспечить каркас, который наилучшим образом поддерживает неизбежно появляющиеся в ходе разработки дополнительные требования и другие изменения.
• Чтобы создавать систему в несколько приемов путем приращений, а не всю сразу и до конца, что сильно поднимает стоимость изменений.
• Чтобы обеспечить процесс разработки, который повысит эффективность работы сотрудников.

3. Итеративный подход управляемый рисками

 

     Риск  — это проектный фактор, который   подвергает   проект опасности. Это «вероятность того, что проект может столкнуться с нежелательной ситуацией, такой, как отставание  от плана, перерасход   средств  или  прекращение  работ»

     Мы  идентифицируем, расставляем по приоритетам и выполняем итерации, основываясь на рисках и их опасности. Это так, когда мы реализуем новые технологии. Когда мы выполняем требования клиентов, не важно, функциональные они или нет. Когда на ранних стадиях мы создаем устойчивую архитектуру, то имеем в виду такую, которая может приспосабливаться к изменениям с малым риском того, что появится   необходимость что-либо  перепроектировать. Да, мы организуем итерации для того, чтобы уменьшить риски. Другие серьезные риски связаны с вопросами производительности (скорость, мощность, точность), надежности, доступности, целостности системных интерфейсов, адаптируемости и переносимости. Многие из этих рисков не могут быть обнаружены до реализа­ции и начала тестирования   программного обеспечения, которое осуществляет основные функции системы. Именно поэтому уже в фазах анализа и определения требований и проектирования следует предусмотреть итерации реализации и тестирования, в ходе которых изучались бы риски. Наша цель определить риски на ранних итерациях.

     Интересно отметить, что в принципе все технические риски можно спроецировать на вариант использования или сценарий варианта использования. В данном случае «спроецировать» означает, что после реализации варианта использования с его функциональными и нефункциональными требованиями риск будет снижен. Это верно не только для тех рисков, которые относятся к требованиям и архитектуре, но и для рисков, связанных с базовыми программными и аппаратными средствами. Тщательно выбирая варианты использования, мы можем осуществить все функции базовой архитектуры.

     Снижение  рисков — это основная задача итераций, которые мы делаем в фазах анализа  и определения требований и проектирования. Позже, в фазе построения, риски в  основном уже уменьшены до приемлемого  уровня, а значит, на первый план выходят  стандартные методы разработки. Мы стараемся планировать итерации так, чтобы каждая следующая итерация была основана на предыдущей. В этой фазе мы стараемся, в частности, уйти от опасности того, что мы не сможем правильно определить порядок итераций, и нам придется переделывать несколько предыдущих итераций.

4. Обобщенная  итерация

 

     Как мы могли заметить, итерации на разных фазах цикла разработки сильно отличаются друг от друга.  Это  происходит потому, что различны задачи, с которыми разработчики сталкиваются на разных фазах разработки. В этом пункте мы намерены представить концепцию итерации на базовом уровне: что это такое, как ее планировать и каким должен  быть результат итерации. 

5. Заключение

 

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

6. Список  использованной литературы

 

1. Якобсон А. Унифицированный  процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. ? СПб.: Питер, 2002. ? 496 с.: ил.
2. Рамбо Дж. UML: специальный справочник / Дж. Рамбо, А. Якобсон, Г. Буч. ? СПб.: Питер, 2001. ? 656 с.: ил.
3. Дейт К. Дж. Введение в системы баз данных / Пер. с англ. ? 6-е изд. Киев; М.; СПб.: Издат. дом "Вильямс", 1999. 848 с.: ил.
4. Фаронов В.В. Delphi 5. Руководство разработчика баз данных / В.В. Фаронов, П.В. Шумаков. М.: "Нолидж", 2001. 640 с.: ил.
5. Тейкстейра С. Borland Delphi 6. Руководство разработчика / С. Тейкстейра, К. Пачеко; Пер. с англ. - М.: Издат. дом "Вильямс", 2002. - 1120 с.: ил.