2.2.4.2Поведенческие (динамические) описания

Рассмотрим нотации и языки, используемые для описания динамического поведения программных систем и их компонентов:

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

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

• диаграммы потоков данных, описывающие потоки данных внутри набора процессов;

• таблицы и диаграммы принятия решений, используемые для представления сложных комбинаций условий и действий (операций);

• схемы алгоритмов и структурированные схемы алгоритмов, служащие для представления потоков управления (контроля) и связанных операций;

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

• диаграммы перехода и карты состояний, применяемые для описания потоков управления переходами между состояниями;

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

• псевдокод и программные языки проектирования, описывающие поведение процедур и методов, в основном на стадии детального проектирования [орлик].

2.2.5Подходы и методы проектирования программного обеспечения

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

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

2.2.5.1Общие подходы

Наиболее часто используются следующие общепринятые подходы:

• метод пошаговой декомпозиции;

• нисходящий и восходящий подход к проектированию;

• абстракция и инкапсуляция;

• итеративный и инкрементальный подход.

Метод пошаговой декомпозиции

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

• определяется общая структура программы в виде одного из трех вариантов:

• последовательности подзадач (например, ввод данных, преобразование данных, вывод данных),

• альтернативы подзадач (например, добавление записей к файлу или их поиск),

• повторения подзадачи (например, циклически повторяемая обработка данных);

• каждая подзадача, в свою очередь, разбивается на подзадачи с использованием тех же структур;

• процесс продолжается, пока на очередном уровне не получается подзадача, которая достаточно просто реализуется средствами используемого языка (1 - 2 управляющих оператора языка).

Нисходящий и восходящий подход к проектированию

Нисходящим методом проектирование программы ведется от общего к ча­стному, ко все большей детализации на каждом этапе. При этом сначала оп­ределяется задача в целом, в виде последовательности этапов, реализующих самостоятельные смысловые части алгоритма. Затем она поэтапно детализи­руется. Процесс детализации алгоритма продолжается до тех пор, пока реа­лизуемые части алгоритма не станут достаточно простыми и легко програм­мируемыми. Результатом этого процесса может быть структура программы. Это направленный граф, определяющий взаимосвязи подпрограмм в виде бло­ков подпрограмм и их вызовов. На последнем этапе каждый модуль представ­ляется в виде детального описания его функций, например с помощью схемы алгоритма. Схема алгоритма – это направленный граф, который определяет процесс обработки данных.

Альтернативным методом по отношению к методу нисходящего проектиро­вания является метод восходящего проектирования. При этом вначале разра­батываются модули низшего уровня, а затем они объединяются с помощью модулей более высокого уровня. Сложные программные системы восходящим методом создавать значительно труднее и дольше, чем нисходящим. На прак­тике часто используют смешанный метод, т. е. в основном используют метод нисходящего проектирования, а в некоторых случаях, по мере необходимос­ти, – восходящее проектирование.

Абстракция и инкапсуляция

Абстракция – это придание объекту характеристик, которые четко определяют его концептуальные границы, отличая от всех других объектов. Основная идея состоит в том, чтобы отделить способ использования составных объектов данных от деталей их реализации (инкапсуляция) в виде более простых объектов, подобно тому, как функциональная абстракция разделяет способ использования функции и деталей её реализации в терминах более примитивных функций, таким образом, данные обрабатываются функцией высокого уровня с помощью вызова функций низкого уровня [2].

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

Итеративный и инкрементальный подход

Итеративный подход – выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка (англ. plan-do-check-act cycle).

Преимущества итеративного подхода:

• снижение воздействия серьёзных рисков на ранних стадиях проекта, что ведет к минимизации затрат на их устранение;

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

• акцент усилий на наиболее важные и критичные направления проекта;

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

• раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

• более равномерная загрузка участников проекта;

• эффективное использование накопленного опыта;

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

• затраты распределяются по всему проекту, а не группируются в его конце [1].

2.2.5.2Функционально-ориентированное (структурное) проектирование

Классический метод проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций “сверху-вниз”. Структурное проектирование, обычно, используется после проведения системного анализа с применением диаграмм потоков данных, функциональных моделей и схем алгоритмов.

2.2.5.3Объектно-ориентированное проектирование

Представляет собой совокупность методов проектирования, базирующихся на концепции объектов. Главную роль в ООП играют полиморфизм и инкапсуляция, наследование и абстракция.

2.2.5.4Проектирование на основе структур данных

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

2.2.5.5Компонентное проектирование

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

2.2.6Гибкие методы разработки

Гибкие методы разработки ПО появились в 90-е годы 20-го века в качестве альтернативы формальным методологиям, перегруженных значительным объёмом документирования и проверок, которые зачастую, особенно небольших коммерческих проектах, неэффективны. Основными положениями гибких методов являются следующее:

• индивидуальные методы и взаимодействие вместо процессов и программных средств;

• работающее ПО вместо сложной документации;

• взаимодействие с заказчиком вместо жестких контрактов;

• реакция на изменения вместо следования плану.

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

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

Самым известным гибким методом является экстремальное программирование (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 недели. Она заканчивается созданием работоспособной версии продукта (рабочий продукт), которую можно предъявить заказчику, запустить и подемонстрировать, пусть и с минимальными функциональными возможностями. После этого результаты обсуждаются и требования к продукту корректируются. Это удобно делать, имея после каждой итерации продукт, который уже можно как-то использовать, показывать и обсуждать. Далее происходит планирование новой итерации и все повторяется.