2.2Проектирование программных средств
Проектирование в основном рассматривается как двух-шаговый процесс [Орлик]:
Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент;
Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент.
Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде.
2.2.1Принципы проектирования
В качестве основных принципов проектирования выделим следующие:
Абстракция
Абстракция – отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков; абстрагирование; теоретическое обобщение как результат такого отвлечения [википедия].
Абстракция – модель, упрощающая поставленную проблему до рамок, значимых для заданного контекста [орлик].
В контексте проектирования программных систем существует два механизма абстракции – параметризация и детализация. При этом, абстракция через детализацию может быть: процедурной (связанной с поведением), абстракцией данных (связанной с информацией) и абстракцией контроля (связанной с управлением системой и обрабатываемой ею информацией).
Связанность и соединение
Связанность – определяет силу взаимосвязи между модулями. Соединение – определяет взаимосвязь элементов внутри модуля, внутренние связи.
Декомпозиция и разбиение на модули
Декомпозиция и разбиение на модули сложных программных систем производится с целью получения более мелких и относительно независимых программных компонентов, каждый из которых несет различную функциональность.
Инкапсуляция
Предполагает группировку и упаковку элементов и внутренних деталей абстракции в отношении реализации с тем, чтобы эти детали были недоступны пользователям элементов. В качестве «пользователя» одного компонента может выступать другой компонент. Более того, при использовании объектно-ориентированного подхода, наследники компонентов могут не иметь доступа ко внутренним деталям реализации компонента, который является их предком.
Разделение интерфейса и реализации
Данная техника предполагает отделение компонента через специфицирование интерфейса, известного и доступного клиентам (или другим компонентам), от непосредственных деталей реализации.
Достаточность, полнота и простота
Создаваемые программные компоненты должны обладать всеми необходимыми характеристиками, определенными абстракцией (моделью), но не должны включать функциональность, отсутствующую в модели.
2.2.2Структура и архитектура программного обеспечения
Архитектура программного обеспечения – описание подсистем, компонент программной системы и связей между ними. Архитектура задаёт способ, которым программная система организована.
На сегодняшний день сформировался взгляд на архитектуру, как на приложение общих принципов организации программных компонент, что привело к накоплению множества подходов и созданию различных архитектурных «фреймворков», то есть систематизированных комплексов методов, практик и инструментов, призванных формализовать имеющийся в индустрии опыт.
Фреймворк (англ. framework — каркас, структура) — структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. В отличие от библиотек, которые объединяют набор подпрограмм близкой функциональности, фреймворк содержит в себе большое количество разных по назначению библиотек. Употребляется также слово «каркас», а некоторые авторы используют его в качестве основного, в том числе не базируясь вообще на англоязычном аналоге. Можно также говорить о каркасном подходе[3] как о подходе к построению программ, где любая конфигурация программы строится из двух частей: первая, постоянная часть — каркас, не меняющийся от конфигурации к конфигурации и несущий в себе гнезда, в которых размещается вторая, переменная часть — сменные модули (или точки расширения) [википедия].
Примеры такой систематизации в форме фреймворков:
TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент первичного написания данной главы доступен в версии 8.1, впервые опубликованной в декабре 2003 года; в 2009 году вышла версия TOGAF 9)
Модель Захмана – Zachman Framework [Zachman]
Руководство по архитектуре электронного правительства E-Gov Enterprise Architecture Guidance [E-Gov, 2002]
2.2.2.1Архитектурные структуры и точки зрения
Принцип сужения предметной области с использованием точки зрения [пособие по ТССА] широко используется в программной инженерии. Система может рассматриваться с разных точек зрения – поведенческой, структурной, логической, физической и т.п. Следовательно, можно получить множество различных архитектурных представлений. Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы. Дизайн системы – комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения требований, предъявляемых к системе.
Архитектурная структура – применение архитектурной точки зрения и представления к конкретной системе и описания тех деталей, которые необходимы для реализации системы, но отсутствуют в используемом представлении. Таким образом, представление, концентрируясь на заданном подмножестве свойств является составной частью и/или результатом точки зрения, а архитектурная структура – дальнейшей детализацией в отношении проектируемой системы [орлик]. В качестве примера архитектурных точек зрения можно рассматривать модель Захмана [Zachman].
2.2.2.2Архитектурные стили
Архитектурный стиль – это мета-модель или шаблон проектирования макро-архитектуры – на уровне модулей, «крупноблочного» взгляда. Архитектурный стиль – набор ограничений, определяющих семейство архитектур, которые удовлетворяют этим ограничениям [орлик].
2.2.2.3Шаблоны проектирования
Архитектурный стиль определяет макро-архитектуру системы, а шаблоны проектирования задают микро-архитектуру, то есть определяют частные аспекты деталей архитектуры.
Чаще всего говорят о следующих группах шаблонов проектирования:
Шаблоны создания (Creational patterns) - builder, factory, prototype, singleton
Структурные шаблоны (Structural patterns) - adapter, bridge, composite, decorator, facade, flyweight, proxy
Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor
2.2.2.4Семейства программ и фреймворков
Один из возможных подходов к повторному использованию архитектурных решений и компонент заключается в формировании линий продуктов на основе общего дизайна. В объектно-ориентированном программировании аналогичную смысловую нагрузку несут «фреймворки», обеспечивающие решение одних и тех же задач – например, внутренней организации компонентов пользовательского интерфейса или общей логики работы распределенных систем [орлик].
2.2.3Анализ качества и оценка программного дизайна
2.2.3.1Атрибуты качества
Атрибуты для оценки качественного дизайна ПС можно разбить на следующие группы:
применимые во время выполнения системы, например, среднее время отклика системы;
используемые в режиме разработки, например, среднее количество методов в классе, среднее количество свойств объекта и т.д.;
атрибуты качества архитектурного дизайна, например, концептуальная целостность дизайна, непротиворечивость, полнота, завершенность.
Существуют атрибуты, которые сложно измерить, например, такой как безопасность.
Не стоит путать атрибуты качества дизайна с атрибутами качества, фигурирующими в ряду требований, предъявляемых к системе. Часть из них может отображаться друг на друга и нести эквивалентную смысловую нагрузку, некоторые могут быть связаны, большая часть атрибутов является специфичной именно для дизайна и не связана с требованиями [орлик].
2.2.3.2Анализ качества и техники оценки
Известно немало различных инструментов и методов, предназначенных для формирования качественного дизайна ПС:
обзор дизайна, например, неформальный обзор архитектуры членами проектной команды;
статический анализ, например, трассировка с требованиями;
симуляция и прототипирование – динамические техники проверки дизайна в целом или отдельных его атрибутов качества; например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым [орлик].
2.2.3.3Измерения
Измерения используются для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, сложности структуры ПС или качества требований, предъявляемых к производительности. Обычно метрики разделяют на 2 класса:
функционально-ориентированные;
объектно-ориентированные [орлик].
2.2.4Нотации проектирования
Нотация – система условных обозначений, принятая в какой-либо области знаний или деятельности. Нотация включает множество символов используемых для представления понятий и их взаимоотношений, составляющее алфавит нотации, а также правила их применения [википедия].
Следовательно, нотация – соглашение о представлении некоторой абстракции в визуальной (графической) форме. Нотация может задаваться:
стандартом;
общепринятой практикой;
внутренним методом проектной команды.
Определенные нотации используются на стадии концептуального проектирования, ряд нотаций ориентирован на создание детального дизайна, многие могут использоваться на обеих стадиях. Кроме того, нотации чаще всего используют в контексте применяемой методологии или подхода [орлик].
2.2.4.1Структурные описания
Следующие нотации, в основном, являются графическими, описывая и представляя структурные аспекты программного дизайна:
языки описания архитектуры, такие как текстовые языки, обычно используемые для описания программной архитектуры в терминах компонентов;
диаграммы классов и объектов, применяемые для представления набора классов и связей между ними (например, наследования);
диаграммы компонентов используемые для представления набора компонентов и связей между ними с учётом того, что компонент в отличие от класса является реализуемым элементом;
карточки функциональности и связей класса, используемые для обозначения имени класса, его функции и связей с другими сущностями (классами, компонентами и т.п.);
диаграммы развёртывания, применяемые для представления физических узлов, связей между ними и моделирования других физических аспектов системы;
диаграммы сущность-связь, служащие для представления информационной модели или концептуальной модели данных, хранимых в ходе работы информационной системы;
языки описания (определения) интерфейса, предназначенные для определения интерфейсов программных компонентов (имён и типов экспортируемых или публикуемых операций);
структурные диаграммы Джексона, описывающие структуры данных в терминах последовательности, выбора и итераций (повторений);
структурные схемы, применяемые для описания структуры вызовов в программах [орлик].
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 недели. Она заканчивается созданием работоспособной версии продукта (рабочий продукт), которую можно предъявить заказчику, запустить и подемонстрировать, пусть и с минимальными функциональными возможностями. После этого результаты обсуждаются и требования к продукту корректируются. Это удобно делать, имея после каждой итерации продукт, который уже можно как-то использовать, показывать и обсуждать. Далее происходит планирование новой итерации и все повторяется.
|
