Выбор технологии проектирования ИС. Критерии выбора

• руководства для всех участников проектной команды, охватывающие весь жизненный цикл ПО. Руководства представлены в двух видах: для осмысления процесса на верхнем уровне, и в виде подробных наставлений по повседневной деятельности;

• наставления по использованию инструментальных средств, входящих в состав Rational Suite;

• примеры и шаблоны проектных решений для Rational Rose;

• шаблоны проектной документации для SoDa;

• шаблоны в формате Microsoft Word, предназначенные для поддержки документации по всем процессам и действиям жизненного цикла ПО;

• планы в формате Microsoft Project, отражающие итерационный характер разработки ПО.

Адаптация RUP к потребностям конкретной организации или проекта обеспечивается с помощью Rational Process Workbench (RPW) –специального набора инструментов и шаблонов для настройки и публикации Web_сайтов на основе RUP. RPW поддерживает три основные функции моделирования технологических процессов:

• определение процесса;

• описание процесса;

• представление процесса.

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

RUP опирается на интегрированный комплекс инструментальных средств Rational Suite. Он существует в следующих вариантах:

• Rational Suite AnalystStudio – предназначен для определения и управления полным набором требований к разрабатываемой системе;

• Rational Suite DevelopmentStudio – предназначен для проектирования и реализации ПО;

• Rational Suite TestStudio – представляет собой набор продуктов, предназначенных для автоматического тестирования приложений;

• Rational Suite Enterprise – обеспечивает поддержку полного жизненного цикла ПО и предназначен как для менеджеров проекта, так и отдельных разработчиков, выполняющих несколько функциональных ролей в команде разработчиков.

В состав Rational Suite, кроме самой технологии RUP как продукта, входят следующие компоненты:

• Rational Rose – средство визуального моделирования (анализа и проектирования), использующее язык UML;

• Rational XDE – средство анализа и проектирования, интегрируемое с платформами MS Visual Studio .NET и IBM WebSphere Studio Application Developer;

• Rational Requisite Pro – средство управления требованиями, предназначенное для организации совместной работы группы разработчиков. Оно позволяет команде разработчиков создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающих на любом этапе разработки компонентов приложения;

• Rational Rapid Developer – средство быстрой разработки приложений на платформе Java 2 Enterprise Edition;

• Rational ClearCase – средство управления конфигурацией ПО;

• Rational SoDA – средство автоматической генерации проектной документации;

• Rational ClearQuest – средство для управления изменениями и отслеживания дефектов в проекте на основе средств e_mail и Web;

• Rational Quantify – средство количественного определения узких мест, влияющих на общую эффективность работы программы;

• Rational Purify – средство для локализации трудно обнаруживаемых ошибок времени выполнения программы;

• Rational PureCoverage – средство идентификации участков кода, пропущенных при тестировании;

• Rational TestManager – средство планирования функционального и нагрузочного тестирования;

• Rational Robot – средство записи и воспроизведения тестовых сценариев;

• Rational TestFactory – средство тестирования надежности;

• Rational Quality Architect – средство генерации кода для тестирования.

Одно из основных инструментальных средств комплекса Rational Rose представляет собой семейство объектно_ориентированных CASE_средств и предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose реализует процесс объектно-ориентированного анализа и проектирования ПО, описанный в RUP. В основе работы Rational Rose лежит построение диаграмм и спецификаций UML, определяющих архитектуру системы, ее статические и динамические аспекты.

В составе Rational Rose можно выделить шесть основных структурных компонентов:

                                          репозиторий,

                                          графический интерфейс пользователя,

                                          средства просмотра проекта (браузер),

                                          средства контроля проекта,

                                          средства сбора статистики

                                          генератор документов.

                                          К ним добавляются генераторы кодов для каждого поддерживаемого языка, состав которых меняется от версии к версии.

Репозиторий представляет собой базуданных проекта.

Браузер обеспечивает «навигацию» по проекту, в том числе перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д.

Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания.

Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.

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

Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на соответствующем языке (основные языки, поддерживаемые Rational Rose – С++ и Java).

В результате разработки проекта с помощью Rational Rose формируются следующие документы:

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

• спецификации классов, объектов, атрибутов и операций;

• заготовки текстов программ.

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

Инструментальное средство Rational XDE представляет собой развитие возможностей Rational Rose в части синхронизации модели и кода (исключающей необходимость прямой и обратной генерации кода). Rational XDE обеспечивает:

• синхронизацию между кодом и моделью;

• отображение элементов кода Java и С# в UML;

• автоматическую синхронизацию с настраиваемым разрешением конфликтов;

• одновременное отображение кода и модели;

• постоянную синхронизацию модели UML, как части проекта Java или С#.

Модель Extreme Programming

Экстремальное программирование является примером так называемого метода «живой» разработки (Agile Development Method).

Модель жизненного цикла XP является итерационно-инкрементной моделью быстрого создания и модификации прототипов продукта, удовлетворяющих очередному требованию (user story). Особенности этой модели представлены на слайде. Основными фазами модели можно считать:

                        «Вброс» архитектуры – начальный этап проекта, на котором создается видение продукта, принимаются основные решения по архитектуре и применяемым технологиям. Результатом начального этапа является метафора (metaphor) системы, которая в достаточно простом и понятном команде виде должна описывать основной механизм работы системы.

                        Истории использования (User Story) – этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. Истории использования являются требованиями для планирования очередной версии и одновременной разработки приемочных тестов (Acceptance tests) для ее проверки.

                        Планирование версии (релиза). Проводится на собрании с участием заказчика путем выбора User Stories, которые войдут в следующую версию. Одновременно принимаются решения, связанные с реализацией версии. Цель планирования - получение оценок того, что и как можно сделать за 1-3 недели создания следующей версии продукта.

                        Разработка проводится в соответствии с планом и включает только те функции, которые были отобраны на этапе планирования.

                        Тестирование проводится с участием заказчика, который участвует в составлении тестов.

                        Выпуск релиза – разработанная версия передается заказчику для использования или бета-тестирования.

                        По завершению цикла делается переход на следующую итерацию разработки

Extreme Programming. Принципы

Особенности модели жизненного цикла XP проясняют следующие принципы этого метода. Прежде всего, это принципы «живой» разработки ПО,

                        Люди их общение более важны, чем процессы и инструменты

                        Работающая программа более важна, чем исчерпывающая документация

                        Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта

                        Отработка изменений более важна, чем следование планам

Кроме того, в XP есть несколько правил (техник), характеризующих особенности модели его жизненного цикла:

                            Живое планирование (planning game) - как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается на основе, в первую очередь, бизнес-приоритетов заказчика и, во-вторую, технических оценок. Планы изменяются, как только они начинают расходится с действительностью или пожеланиями заказчика.

                            Частая смена версий (small releases) - первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени.

                            Простые проектные решения (simple design) - в каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Новые функции добавляются только после ясной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.

                            Разработка на основе тестирования (test-driven development) - сначала пишутся тесты, потом реализуются модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.

                            Постоянная переработка (refactoring) - системы для устранения излишней сложности, увеличения понятности кода, повышения его гибкости. При этом предпочтение отдается более элегантным и гибким решениям, по сравнению с просто дающими нужный результат.

                            Программирование парами (pair programming) - весь код пишется двумя программистами на одном компьютере, что повышает его качество (отсутствие ошибок, понятность, читаемость,…).

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

                            40-часовая рабочая неделя - сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной.

Процесс моделирования  ICONIX

Рзработал Дуг Розенберг в 1992 г., компания ICONIX Software Engineering  - процесс моделирования, который  представляет собой нечто среднее между довольно громоздким рациональным унифицированным процессом (Rational Unified Process - RUP) и весьма компактной методологией программирования еХtreme (XP). Процесс ICONIX основан на прецедентах (вариантах использования). В этом процессе тоже применяется язык моделирования UML (Unified Modeling Language), однако основное внимание уделяется анализу требований.

ICONIX основан на прецедентах и является итеративным и инкрементным.

Задача процесса – быстрый переход от прецедентов к работающей системе за минимальное количество шагов.

Основные этапы процесса

•                      Анализ требований

•                      Предварительное проектирование

•                      Проектирование

•                      Реализация

1.      На этапе анализа

a.      Архитектурный анализ

b.     Создаются модели прецедентов

c.      Модель пользовательского интерфейса

d.     Логическое представление модели предметной области

2.      На этапе предварительного проектирования

a.      Дополняется и уточняется модель прецедентов

b.     Анализ вариантов использования

c.      Создается диаграмма пригодности

d.     Анализ пригодности

e.      Дополняется Модель предметной области

3.      На этапе детального проектирования

a.      Создаются диаграммы последовательности

b.     Создаются диаграммы классов для каждого варианта использования и общая диаграмма классов

c.      Создается модель данных с атрибутами и связями