Анализ качества и оценка программного дизайна

1. Анализ качества и оценка программного дизайна

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

2. Измерения

Измерения используются для количественной оценки
ожиданий в отношении различных аспектов
конкретного дизайна, например, сложности структуры
ПС или качества требований, предъявляемых к
производительности. Обычно метрики разделяют на 2
класса: функционально-ориентированные и объектно-
ориентированные.
Нотации проектирования
Нотация – система условных обозначений, принятая в какойлибо области знаний или деятельности. Нотация
включает множество символов используемых для
представления понятий и их взаимоотношений,
составляющее алфавит нотации, а также правила их
применения

3. Нотации проектирования

Нотация – система условных обозначений, принята в
какой-либо области знаний или деятельности. Нотация
включает множество символов используемых для
представления понятий и их взаимоотношений,
составляющее алфавит нотации, а также правила их
применения.
Нотация может задаваться:
• стандартом;
• общепринятой практикой;
• внутренним методом проектной команды.
Определенные нотации используются на стадии
концептуального проектирования, ряд нотаций
ориентирован на создание детального дизайна, многие
могут использоваться на обеих стадиях. Кроме того,
нотации чаще всего используют в контексте применяемой
методологии или подхода.

4. Структурные описания

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

5.

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

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

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

7.

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

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

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

9. Общие подходы

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

10.

• каждая подзадача, в свою очередь, разбивается на подзадачи с
использованием тех же структур;
• процесс продолжается, пока на очередном уровне не получается
подзадача, которая достаточно просто реализуется средствами
используемого языка (1 - 2 управляющих оператора языка).
Нисходящий и восходящий подход к проектированию
Нисходящим методом проектирование программы ведется от
общего к частному, ко все большей детализации на каждом этапе.
При этом сначала определяется задача в целом, в виде
последовательности этапов, реализующих самостоятельные
смысловые части алгоритма. Затем она поэтапно детализируется.
Процесс детализации алгоритма продолжается до тех пор, пока
реализуемые части алгоритма не станут достаточно простыми и
легко программируемыми. Результатом этого процесса может быть
структура программы.
Альтернативным методом по отношению к методу нисходящего
проектирования является метод восходящего проектирования.
При этом вначале разрабатываются модули низшего уровня, а
затем они объединяются с помощью модулей более высокого
уровня. Сложные программные системы восходящим методом
создавать значительно труднее и дольше, чем нисходящим. На
практике используется смешанный метод.

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

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

12.

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

13.

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

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

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

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

Самым известным гибким методом является экстремальное
программирование (Extreme Programming или сокращенное
название – XP), созданный специалистом в области программной
инженерии Кентом Беком в результате его работы в 1996-1999
годах над системой контроля платежей компании "Крайслер".
Модель процесса по XP выглядит как частая последовательность
выпусков продукта, столь частых, сколь это возможно. Но при этом
обязательно, чтобы в выпуск входила новая функциональность.
Основные принципы организации процесса по XP:
планирование, основанное на принципе, что разработка ПО
является диалогом между возможностями и желаниями, при этом
изменятся и то и другое;
простой дизайн – против избыточного проектирования;
метафора – суть проекта должна умещаться в 1-2 емких фразах
или в некотором образе;
рефакторинг – процесс постоянного улучшения (упрощения)
структуры ПО, необходимый в связи с добавлением новой
функциональности;
парное программирование – один программирует, другой думает
над подходом в целом, о новых тестах, об упрощении структуры
программы и т.д.;

16.

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

17.

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