курсовая работа. Учебное пособие по дисциплине технология разработки программного обеспечения специальность Программирование в компьютерных системах
 Скачать 7.57 Mb.
|
3.4 Компонентно-ориентированная модельКомпонентно-ориентированная модель является развитием спиральной модели и тоже основывается на эволюционной стратегии конструирования. В этой модели конкретизируется содержание квадранта конструирования — оно отражает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов (рис.7). Программные компоненты, созданные в реализованных программных проектах, хранятся в библиотеке. В новом программном проекте, исходя из требований заказчика, выявляются кандидаты в компоненты. Далее проверяется наличие этих кандидатов в библиотеке. Если они найдены, то компоненты извлекаются из библиотеки и используются повторно. В противном случае создаются новые компоненты, они применяются в проекте и включаются в библиотеку.   Идентификация кандидатов в компоненты  Содержание этапа конструирования   Конструирование n-й итерации системы Поиск компонентов в библиотеке  Извлечение компонентов (если найдены) Включение новых компонентов в библиотеку Построение компонентов   Рис.7. Компонентно-ориентированная модель Достоинства компонентно-ориентированной модели: уменьшает на 30% время разработки программного продукта; уменьшает стоимость программной разработки до 70%; увеличивает в полтора раза производительность разработки. 4. Прогнозирующие и адаптивные процессыВ XXI веке потребности общества в программном обеспечении информационных технологий достигли экстремальных значений. Программная индустрия буквально «захлебывается» от потока самых разнообразных заказов. Традиционно для упорядочения и ускорения программных разработок предлагались строго упорядочивающие тяжеловесные (heavyweight) процессы. В этих процессах прогнозируется весь объем предстоящих работ, поэтому они называются прогнозирующими (predictive) процессами. Порядок, который должен выполнять при этом человек-разработчик, чрезвычайно строг – «шаг вправо, шаг влево – виртуальный расстрел!». Иными словами, человеческие слабости в расчет не принимаются, а объем необходимой документации способен отнять покой и сон у «совестливого» разработчика. В последние годы появилась группа новых, облегченных (lightweight) процессов. Теперь их называют подвижными (agile) процессами. Они привлекательны отсутствием бюрократизма, характерного для тяжеловесных (прогнозирующих) процессов. Новые процессы должны воплотить в жизнь разумный компромисс между слишком строгой дисциплиной и полным ее отсутствием. Иначе говоря, порядка в них достаточно для того, чтобы получить разумную отдачу от разработчиков. Подвижные процессы требуют меньшего объема документации и ориентированы на человека. В них явно указано на необходимость использования природных качеств человеческой натуры (а не на применение действий, направленных наперекор этим качествам).Более того, подвижные процессы учитывают особенности современного заказчика, а именно частные изменения его требований к программному продукту. Известно, что для прогнозирующих процессов частые изменения требований подобны смерти. В отличие от них, подвижные процессы адаптируют изменения требований и даже выигрывают от этого. Словом, подвижные процессы имеют адаптивную природу. Таким образом, в современной инфраструктуре программной инженерии существуют два семейства процессов разработки: семейство прогнозирующих (тяжеловесных) процессов; семейство адаптивных (подвижных, облегченных) процессов. У каждого семейства есть свои достоинства, недостатки и область применения: адаптивный процесс используют при частных изменениях требований, малочисленной группе высококвалифицированных разработчиков и грамотном заказчике, который согласен участвовать в разработке; прогнозирующий процесс применяют при фиксированных требованиях и многочисленной группе разработчиков разной квалификации. 5. XP-процесс Экстремальное программирование (eXtreme Programming, XP) – облегченный (подвижный) процесс (или методология), главный автор которого – Кент Бек (1999) . XP-процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требовании. Основная идея XP – устранить высокую стоимость изменения, характерную для приложений с использованием объектов, паттернов и реляционных баз данных. Поэтому XP-процесс должен быть высокодинамичным процессом. XP-группа имеет дело с изменениями требований на всем протяжении итерационного цикла разработки, причем цикл состоит из очень коротких итераций. Четырьмя базовыми действиями в XP-цикле являются: кодирование, тестирование, выслушивание заказчика и проектирование. Динамизм обеспечивается с помощью четырех характеристик: непрерывной связи с заказчиком (и в пределах группы), простоты (всегда выбирается минимальное решение), быстрой обратной связи (с помощью модульного и функционального тестирование), смелости в проведении профилактики возможных проблем. Большинство принципов, поддерживаемых в XP (минимальность, простота, эволюционный цикл разработки, малая длительность итерации, участие пользователя, оптимальные стандарты кодирования и т.д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе. Просто XP эти принципы, как показано в табл. 2, достигают «экстремальных значений». Тот, кто принимает принцип «минимального решения» за хакерство, ошибается, в действительности. ХР — строго упорядоченный процесс. Простые решения, имеющие высший приоритет, в настоящее время рассматриваются как наиболее ценные части системы, в отличие от проектных решений, которые пока не нужны, а могут (в условиях изменения требований и операционной среды) и вообще не понадобиться. Таблица 2 Экстремумы в экстремальном программировании
Базис ХР образуют перечисленные ниже двенадцать методов. |