Экстремальное программирование

⇐ ПредыдущаяСтр 10 из 16Следующая ⇒

Самым известным гибким методом является экстремальное программирование (Extreme Programming или сокращенное название – XP), созданный специалистом в области программной инженерии Кентом Беком в результате его работы в 1996-1999 годах над системой контроля платежей компании " Крайслер".

Модель процесса по XP выглядит как частая последовательность выпусков продукта, столь частых, сколь это возможно. Но при этом обязательно, чтобы в выпуск входила новая функциональность. Основные принципы организации процесса по XP:

– планирование, основанное на принципе, что разработка ПО является диалогом между возможностями и желаниями, при этом изменятся и то и другое;

– простой дизайн – против избыточного проектирования;

– метафора – суть проекта должна умещаться в 1-2 емких фразах или в некотором образе;

– рефакторинг – процесс постоянного улучшения (упрощения) структуры ПО, необходимый в связи с добавлением новой функциональности;

– парное программирование – один программирует, другой думает над подходом в целом, о новых тестах, об упрощении структуры программы и т.д.;

– коллективное владение кодом – все участники проекта должны уметь писать код;

– участие заказчика в разработке – представитель заказчика входит в команду разработчика;

– создание и использование стандартов кодирования в проекте – при написании кода используются стандарты на имена идентификаторов, составление комментариев и т.д.;

– тестирование – разработчики сами тестируют свое ПО, перемежая этот процесс с разработкой (при этом рекомендуется создавать тесты до того, как будет реализована соответствующая функциональность с привлечением заказчика);

– непрерывная интеграция – разработка представляется как последовательность выпусков;

– 40-часовая рабочая неделя.

Однако в полном объеме XP не была использована даже ее авторами. Кроме того, известны и внедряются отдельные практики XP, как, например, парное программирование, коллективное владение кодом, рефакторинг кода. Однако идея простого, неизбыточного дизайна проекта также оказала значительное влияние на мир разработчиков ПО.

Более практичным гибким методом разработки является Scrum.

Метод схватки или Scrum

В 1986 японские специалисты Hirotaka Takeuchi и Ikujiro Nonaka опубликовали сообщение о новом подходе к разработке новых сервисов и продуктов (не обязательно программных). Основу подхода составляла сплоченная работа небольшой универсальной команды, которая разрабатывает проект на всех фазах. Приводилась аналогия из регби, где вся команда двигается к воротам противника как единое целое, передавая (пасуя) мяч своим игрокам как вперед, так и назад. В начале 90-х годов данный подход стал применяться в программной индустрии и обрел название Scrum (термин из регби, означающий – схватка), в 1995 году Jeff Sutherland и Ken Schwaber представили описание этого подхода на OOPSLA '95 – одной из самых авторитетных конференций в области программирования. С тех пор метод активно используется в индустрии и многократно описан в литературе. Scrum активно используется также в России.

Общее описание. Метод Scrum позволяет гибко разрабатывать проекты небольшими командами (7 человек плюс/минус 2) в ситуации изменяющихся требований. При этом процесс разработки итеративен и предоставляет большую свободу команде. Кроме того, метод очень прост – легко изучается и применяется на практике. Его схема изображена на рисунке.

Рис. 11.1.

Вначале создаются требования ко всему продукту. Потом из них выбираются самые актуальные и создается план на следующую итерацию. В течение итерации планы не меняются (этим достигается относительная стабильность разработки), а сама итерация длится 2-4 недели. Она заканчивается созданием работоспособной версии продукта (рабочий продукт), которую можно предъявить заказчику, запустить и подемонстрировать, пусть и с минимальными функциональными возможностями. После этого результаты обсуждаются и требования к продукту корректируются. Это удобно делать, имея после каждой итерации продукт, который уже можно как-то использовать, показывать и обсуждать. Далее происходит планирование новой итерации и все повторяется.

Использование UML в программной инженерии

Основные компоненты UML

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

Рис. 3.1. Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования

Основные задачи, решаемые с помощью UML:

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

2. Обеспечение возможности расширения и специализации UML для повышения качества моделирования систем в предметной области.

3. Независимость UML от конкретных языков программирования и инструментальных средств проектирования программных систем, что означает, что конструкции языка UML не должны зависеть от особенностей их реализации в применяемых языках программирования.

4. Наличие семантического базиса в описании UML для понимания общих особенностей ООП, что означает претензию UML на понимание общих принципов ООП.

5. Обеспечение развития рынка объектно-ориентированных инструментальных средств за счёт популяризации UML и распространение объектно-ориентированных технологий и соответствующих понятий ООАП.

6. Интеграция в UML последних достижений объектно-ориентированных технологий за счёт его дальнейшей интеграции с другими современными технологиями моделирования и методами программной инженерии.

Описание UML состоит из двух взаимодействующих частей, таких как:

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

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

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

Семантика определяется для двух видов объектных моделей: структурных моделей и моделей поведения. Структурные (статические) модели описывают структуру сущностей или компонентов некоторой системы, включая их классы, интерфейсы, атрибуты и отношения. Модели поведения (динамические модели) описывают поведение объектов системы, включая их методы, взаимодействие и связи между ними, а также процесс смены состояний компонентов и системы в целом.

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

- мета-метамодель;

- метамодель;

- модель;

- объекты пользователя.

Верхний уровень является основой для всех метамодельных представлений. Назначение уровня состоит в определении языка для спецификации метамодели. Мета-метамодель определяет модель UML на самом высоком уровне абстракции и является наиболее компактным ее описанием. Мета-метамодель может описывать несколько метамоделей.

Метамодель является экземпляром мета-метамодели. Главная задача уровня метамодели – определение языка для формирования моделей. Данный уровень обладает более развитой семантикой базовых понятий. Основные понятия UML относятся как раз к уровню метамодели. Примеры таких понятий — класс, атрибут, операция, компонент, ассоциация и многие другие.

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

Конкретизация понятий модели происходит на уровне объектов. Объект является экземпляром модели, поскольку содержит конкретную информацию относительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проектируемой базе данных: " Илья Петров, 30 лет, иллюзионист, ул. Невидимая, 10-20, 100-0000".

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

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

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

– диаграмма вариантов использования (use case diagram);

– диаграмма классов (class diagram);

– диаграммы поведения (behavior diagrams);

– диаграмма состояний (statechart diagram);

– диаграмма деятельности (activity diagram);

– диаграммы взаимодействия (interaction diagrams);

– диаграмма последовательности (sequence diagram);

– диаграмма кооперации (collaboration diagram);

– диаграммы реализации (implementation diagrams);

– диаграмма компонентов (component diagram);

– Диаграмма развертывания (deployment diagram).

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

- диаграмма вариантов использования;

- диаграмма классов;

- диаграмма состояний;

- диаграмма деятельности;

- диаграмма последовательности;

- диаграмма кооперации;

- диаграмма компонентов;

- диаграмма развертывания.

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

Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели сложной системы в терминах языка UML.

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

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

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

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

Таким образом, интегрированная модель сложной системы в нотации UML представляется в виде совокупности указанных выше диаграмм.

Рис. 3.10. Интегрированная модель сложной системы в нотации UML

⇐ Предыдущая 5 6 7 8 91011 12 13 14 Следующая ⇒