Эффективное объектно-ориентированное проектирование и структурное качество приложений

700 views

Published on

Алексей Петров, консультант Luxoft Training в области анализа и моделирования бизнес-процессов и проектирования баз данных, представил доклад «Эффективное объектно-ориентированное проектирование и структурное качество приложений» на Stratoplan TECH&BUSINESS Summit 2013.

В своем выступлении Алексей ответил на ряд важных вопросов:
- Что такое «структурное качество приложения»?
- Что такое «антишаблоны», и какой вред они могут нанести коду?
- Как соотносятся фундаментальные и канонические шаблоны ОО-проектирования и показатели структурного качества?
- Какую помощь в обеспечении качества приложения могут оказать современные языки ОО-программирования?
- Какие организационные мероприятия могут помочь в обеспечении структурного качества в условиях промышленной разработки?
- Реально ли повысить структурное качество уже написанного приложения?

Тезисы доклада:
«Значимой актуальной тенденцией в инженерии ПО является переход от обеспечения качества приложения путем всестороннего тестирования по завершении основной фазы его кодирования к обеспечению качества на всех этапах жизненного цикла разработки ПО. Кроме того, само понятие качества трактуется все более широко и в соответствии с общепринятыми стандартами (напр., ISO/IEC 9126) охватывает на сегодняшний день такие понятия, как безопасность, надежность, масштабируемость, удобство сопровождения.
Сформулировать соответствующие метрики качества нетрудно, гораздо труднее — добиться заданных показателей. И основную роль в этом играют не программисты, которые «изготавливают» исходный или объектный код, а аналитики и архитекторы, которые проектируют будущие артефакты с учетом оп

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
700
On SlideShare
0
From Embeds
0
Number of Embeds
92
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Эффективное объектно-ориентированное проектирование и структурное качество приложений

  1. 1. ЭФФЕКТИВНОЕОО-ПРОЕКТИРОВАНИЕИ СТРУКТУРНОЕ КАЧЕСТВОПРИЛОЖЕНИЙАлексей ПЕТРОВ
  2. 2. О ЧЕМ ПОЙДЕТ РЕЧЬ?1234Что такое «структурное качество» приложений?Как соотносятся шаблоны ОО-проектирования ипоказатели качества?Что такое «анти-шаблоны»?Какую помощь в обеспечении структурного качествамогут оказать современные языки?Какие мероприятия могут помочь в обеспеченииструктурного качества?Реально ли повысить структурное качество уже написанныхприложений?
  3. 3. НЕФОРМАЛЬНОЕ ВВЕДЕНИЕ1234Качество — это…… «степень соответствия присущих характеристик <…>изделия или продукта потребностям, ожиданиям»(ГОСТ Р ИСО 9000). Различают качество программногообеспечения (ПО) и исходного кода.Основная задача… планировать и осуществлять мероприятия по анализу иповышению структурного качества исходного программногокода как артефакта в процессах разработки ПОАктуальностьИтеративные методы разработки; распространение методовобеспечения и контроля качества на все этапы разработкиПО; распространение методов ОО-анализа, проектированияи разработки; применение UML и CASE-средств.Первые результатыПовышение качества управления рисками и затратами навсех этапах жизненного цикла ПО
  4. 4. МОДЕЛИ КАЧЕСТВА ПОМодели качества ПО — это упорядоченныесистемы атрибутов, значимых длязаинтересованных сторон проектаразработки ПООбщий принцип — числовое выражение фактора:линейная комбинация взвешенных влияющихметрик4,8Критерииточка зренияразработчикаточка зренияпользователяФакторыМетрикиатрибутымоделиДж.МакКолБ. БоэмISO912620стр.
  5. 5. ВОПРОС #1Что такое «качественное ПО»?12Что такое «качественное ПО»?– Ответьте, используя не более шести слов.Какие характеристики ПО, на ваш взгляд, можноназвать структурными?– Ответьте, используя не более шести слов.20стр.
  6. 6. МОДЕЛЬ КАЧЕСТВА ISO / IEC 9126199120016целейожиданиеот ПО21атрибутблизость кдостижениюцелиISO / IEC 9126ISO 25000:2005SQuaRE — Software productQuality Requirements andEvaluation5структурныххарактеристикПО❶Надежностьпрочность, устойчивость;степень риска, сопряженного сиспользованием системы❷Эффективностьпроизводительность операций;управление ресурсами; правилакодирования❸Безопасность правила кодирования;обработка ошибок и исключенийдокументация в коде; удобство чтениякода; отсутствие «грязных» техник;переносимость кода❹Удобство сопровожденияоценка трудозатрат вретроспективе и перспективе❺Размер кода
  7. 7. МЕТРИКИ КАЧЕСТВА В МОДЕЛИ ISO / IEC 9126199120016целейожиданиеот ПО21атрибутблизость кдостижениюцелиISO / IEC 9126SQuaRE — Software productQuality Requirements andEvaluationISO 9126-2, ISO 9126-3МетрикикачестваПолнота и корректностьреализации функцийОтношение числа найденныхдефектов к прогнозномуОтношение числа проведенныхтестов к общему их числу…В трактовке ISO 9126,качество ПО можно повысить,не внося в него изменений
  8. 8. ЛАНДШАФТ МЕТОДОВ ОЦЕНКИ КАЧЕСТВА ПО123Необходим «запуск» объектаисследования?По анализируемымартефактамПо способуизучениястатическиединамическиеформальные моделиисходный программный кодобъектный коддокументацияинструментальный анализцеленаправленнаяинспекция (desk-checking)рефакторинг
  9. 9. ВОПРОС #2Ограничения статическогоанализаВозможно ли путем статического анализа установитьстепень реализации следующих атрибутов качестваПО? Ответьте «да» или «нет»– Защищенность ________________________– Понятность ________________________– Правильность, точность ________________________– Привлекательность ________________________– Работоспособность ________________________– Удобство анализа ________________________– Удобство обучения ________________________20стр.
  10. 10. СТАТИЧЕСКИЙ АНАЛИЗ И СТРУКТУРНЫЕПОКАЗАТЕЛИ КАЧЕСТВА123Статическийанализ:Нефункциональныетребования:Оценка качества:удобство чтения низкая сложностькорректность обработки исключенийотсутствие предупреждений при компиляциилегкость отладки, тестирования, исправленияошибок, поддержки и внесения измененийполнота краткостьпонятность надежностьструктурированностьудобство сопровождениякомпонентная структураплатформа архитектураисходный код схема БД
  11. 11. МЕТРИКИ В АРТЕФАКТАХ1234АрхитектураСоблюдение стандартов разработки архитектуры;реализация шаблонов проектирования разного уровня;показатели связности и повторного использованиякомпонентовТранзакции и алгоритмыСложность транзакций и алгоритмов;сложность приемов программирования и отсутствие«грязных» техникИсходный кодСоблюдение правил оформления кода;обработка ошибок и исключений;соответствие выбранной парадигмеТехническая документацияУдобство чтения и структурированность;объем документации
  12. 12. БОРЬБА СО СЛОЖНОСТЬЮ: РАУНД 11234Сложность — это……атрибут качества, опосредованно оцениваемый черезколичество, размер и связность едиництрансляции, соблюдение правил и соглашений опроектировании, моделировании, кодировании продуктаСнижению сложности способствуют……предварительное проектирование архитектурыв соответствии с заданными критериями качествас учетом ее реализуемости на выбранном языке«Несложный» код:«Несложный» код обеспечивает……снижение совокупной стоимости владения ПОлаконичность модульностьиспользование шаблоновслабая связанностьсоблюдение правилоформления кодасистематическая обработка ошибок20стр.
  13. 13. БОРЬБА СО СЛОЖНОСТЬЮ: РАУНД 21234Самодокументируемость кодаОбеспечивает понятность кода без обращения кдокументации;способствует соответствию исходного кода «внутреннейпрограммной документации»Композиция объектов  компонентная разработкаНе порождает сильной связи суперклассов с подклассами;не вызывает проблемы «хрупких» базовых классов (fragilebase class)Контрактное программированиеПринцип «корректность по построению»Подразумевает применение методовпроектирования, автоматически гарантирующих корректностьполучаемого продукта
  14. 14. ВОПРОС #3«Контракты» в коде икачество ПО12Что вы знаете о контрактном программировании?– Предложите свое определение контрактногопрограммирования, содержащее не более пяти слов.Какие структурные показатели качества улучшаетприменение «контрактов» в исходном коде?– Ответьте, используя не более четырех слов.20стр.
  15. 15. ЗНАКОМЬТЕСЬ: ПРАКТИЧЕСКИЕ ПРИМЕРЫ123Стандарты и стили кодаОткрытые: Google C++ Style Guide,Code Conventions for the Java ProgrammingLanguage;частные: корпоративные, командные и т.д.Шаблоны проектированияФундаментальные (базовые);GoF, Gang of Four (Э. Гамма и др.);GRASP (К. Ларман);PoEAA (М. Фаулер)Автоматическая генерация, рефакторинг,комментирование и документирование кодаCASE- и ALM-средства (в составе Microsoft Visual Studio,Eclipse IDE, IntelliJ IDEA и т.д.);Doxygen, javadoc и т.д.
  16. 16. ФУНДАМЕНТАЛЬНЫЕ ШАБЛОНЫ ОО-ПРОЕКТИРОВАНИЯ. ШАБЛОНЫ GOF И GRASP123Цель ОО-проектированияРазработка архитектуры согласно выбранным критериямкачества и с учетом ее реализуемости на выбранном языкеТипичные компромиссыСоответствие дизайна задаче общность дизайна;доступность элементов системы безопасность;удобство вызова  возможность тонкой настройкиШаблоны (паттерны) проектирования —это……типовые архитектурные решения задач, в том числе:фундаментальные шаблоны:наследование, делегирование и др.;шаблоны «банды четырех» (GoF):стратегия, адаптер и др.;шаблоны GRASP, PoEAA и др.
  17. 17. ПРИМЕР #1:ШАБЛОНЫ ОО-ПРОЕКТИРОВАНИЯ (UML)Делеги-рованиеАдаптеробъекта
  18. 18. ПРИМЕР #2:ШАБЛОНЫ ОО-ПРОЕКТИРОВАНИЯ (JAVA)public class Singleton {private static final Singleton instance =new Singleton();private Singleton() {// …}public static Singleton getInstance() {return instance;}}
  19. 19. ВОПРОС #4Проблемы архитектуры икачество ПО20стр.Какие показатели качества ПО страдают от наличияследующих проблем в архитектуре системы? Ответьтеполно, насколько это возможно. Время на ответ —3 минуты.– Наличие «божественных» классов или объектов_______________________________________________– Сильная связанность классов или объектов_______________________________________________– Невозможность замены способа выполнения операции(запроса)_______________________________________________
  20. 20. КАК СООТНОСЯТСЯ ШАБЛОНЫПРОЕКТИРОВАНИЯ И КАЧЕСТВОПРИЛОЖЕНИЙ? (1 / 3)Проблема Пример шаблонаЧрезмерное количество используемыхклассов, объектов или глобальныхпеременных системыНаследование, прототип,одиночка, посредник,приспособленец«Хрупкие» базовые классы Композиция«Божественные» объектыДекоратор, состояние,стратегияСлабая инкапсуляция (локализация) именили зависимость от именАбстрактная фабрика,прототип, фабричный метод,фасад, шаблонный методСлабая инкапсуляция (локализация) кодаили структур данныхИтератор, мост, наблюдатель(менеджер), состояние,стратегия, строитель, фасад,шаблонный методКаждый шаблон (справа) призван решать проблемы вархитектуре системы, последовательно устраняяважнейшие причины перепроектирования (слева)20стр.
  21. 21. Проблема Пример шаблонаДублирование кодаНаследование, композиция,мост, шаблонный методНевозможность замены способавыполнения запроса, сложность сочетанияповедений или динамическогоконфигурирования системыДекоратор, делегирование(композиция), наблюдатель,посредник, прототип,состояние, стратегияПотребность в универсальном илиальтернативном способе доступа (системезапросов), абстрактном типе данных (ADT)Адаптер, интерфейс, итератор,компоновщик, наблюдатель,посетительПотребность в глобальной точке доступа ОдиночкаПотребность в константном объекте Неизменяемый объектЗависимость системы от программной илиаппаратной платформыАбстрактная фабрика, мостЗависимость клиента от алгоритмов,представления или реализации объектаИтератор, мостКАК СООТНОСЯТСЯ ШАБЛОНЫПРОЕКТИРОВАНИЯ И КАЧЕСТВОПРИЛОЖЕНИЙ? (2 / 3)20стр.
  22. 22. КАК СООТНОСЯТСЯ ШАБЛОНЫПРОЕКТИРОВАНИЯ И КАЧЕСТВОПРИЛОЖЕНИЙ? (3 / 3)Проблема Пример шаблонаСильная связанность классов или объектовКоманда, мост, посредник,фасадЧрезмерное использование наследования Декоратор, композицияНедостаточная скорость выполненияинициализирующих операцийЗаместитель, отложеннаяинициализацияНеобходимость широковещательныхкоммуникацийНаблюдательНедостаточная расширяемость,переносимость и безопасностьЗаместитель, команда, мост,фасадСложность архитектуры и компрометацияуровней многоуровневой системыНаблюдатель, фасад20стр.
  23. 23. ЧТО ТАКОЕ «АНТИ-ШАБЛОНЫ»…?Загадочный код (Cryptic code)умышленное или неумышленное несоблюдение принципасамодокументируемости исходного кодаБожественный объект (God object)монолитный артефакт большого размера в исходном кодеЖесткий код (Hard code)имена, адреса и пр. числовые и символьныелитералы, наличие которых затрудняет (делаетневозможным) конфигурирование системыМагические числа (Magic numbers)константы с трудно постижимой семантикой
  24. 24. … И ЧТО ТАКОЕ «ГРЯЗНЫЕ ТЕХНИКИ»?«Мертвый» или пустой кодкодовые фрагменты, которые не используются в текущейсборке (версии) приложения, устарели или сделаны «прозапас»Архитектурно необоснованные заглушкиметоды или функции, не выполняющие роль пустыхнеабстрактных методов, шаблонных методов (GoF) илиопераций-«зацепок» (hook operations)Код с непредсказуемым поведениемобращение к неинициализированнымпеременным, «трюки» в управлениипамятью, неконтролируемоепереполнение буферов и т.д.
  25. 25. ВОПРОС #5Языки ООП и качествоисходного кода20стр.12Какие «внеязыковые» возможности современныхсред разработки могут помочь в обеспеченииструктурного качества исходного кода?Какие возможности языков ОО-программированиявносят свой вклад в обеспечение структурногокачества кода?– Ответьте полно, насколько это возможно. Время на ответ —2 минуты.
  26. 26. КАКУЮ ПОМОЩЬ МОГУТ ОКАЗАТЬСОВРЕМЕННЫЕ ЯЗЫКИПРОГРАММИРОВАНИЯ? (1 / 2)C++ JavaИсполнение управляемого кода взащищенной программной средебыстро,небезопасномедленно,безопасно«Родные» методы(выполняют код вне защищенной среды,имеют доступ ко всем системнымресурсам)—быстро, небезоп.,непереносимоСтрогая типизация  Запрет автоматического приведения(преобразования) типовчаст., особ. в C++11Средства динамической идентификациитипов времени выполнения (RTTI)dynamic_cast,typeidinstanceofОтладочные утверждения (assertions)времени компиляции (исполнения) Автоматическая сборка мусораэмулируется20стр.
  27. 27. КАКУЮ ПОМОЩЬ МОГУТ ОКАЗАТЬСОВРЕМЕННЫЕ ЯЗЫКИПРОГРАММИРОВАНИЯ? (2 / 2)C++ JavaОбобщенное программирование споддержкой безопасности типов данныхшаблоныобобщенияЭлементы рефлексии в исходном кодехарактеристикитипованнотацииРасширенная поддержка ОО-парадигмы(абстрактные классы, «листовые» классы /методы, «удаленные» методы)особ. в C++11Обработка исключительных ситуаций.Стандартные и пользовательские классы-исключения Спецификация типов исключений,возбуждаемых методами классовна усмотрениеразработчикасуществуютнепроверяемыеАлгоритмы и структуры данных в составестандартных библиотек 20стр.
  28. 28. ЭЛЕМЕНТЫ РЕФЛЕКСИИ В ИСХОДНОМ КОДЕ1234Предотвращают……некорректное использование библиотек, ошибки привыборе (типов) фактических параметров, непреднамеренныеошибки в сигнатурах методов (архитектуре классов) и пр.Выделяют и принуждают…… к отказу от использования устаревающих элементовархитектурыУпрощают…… работу с атомарными характеристиками типов и позволяютпредельно оптимизировать специализированные версииуниверсальных функций и методовСопровождают…… намеренно сохраненные в итоговой сборке кодапредупреждения при компиляции
  29. 29. АЛГОРИТМЫ И КОНТЕЙНЕРЫ В СОСТАВЕСТАНДАРТНЫХ БИБЛИОТЕК1Позволяют…работать с эффективным готовым исходным кодом;ускорить процессы разработки;снизить издержки на сопровождение продукта2Предоставляют…строгие гарантии вычислительной сложности операций(напр., поиск элемента списка требует линейного времени)широкие возможности повторного использования кода;расширяемые, удобные, взаимозаменяемые программныемодули с унифицированными интерфейсами3Обеспечивают…вариативность решения задачи с учетом предпочтенийразработчика;структурную несовместимость контейнеров и алгоритмов,неэффективных при совместной работе
  30. 30. ПРИМЕР #3: СТАНДАРТНЫЕ АЛГОРИТМЫСОРТИРОВКИ (STD. TEMPLATE LIBRARY, C++)123
  31. 31. КАКИЕ ОРГАНИЗАЦИОННЫЕ МЕРОПРИЯТИЯМОГУТ ПОМОЧЬ В ОБЕСПЕЧЕНИИ КАЧЕСТВА?Выбор и внедрение модели качества ПОВыбор модели и атрибутов качества, определение метриккачества и их сравнительной значимости («весов»);принятие модели качества в «обязывающей» форме;утверждение и внедрение регламента регулярной оценкикачестваПрограмма повышения квалификации(Принятая) модель и атрибуты структурного качества ПО;расширенные возможности языков моделирования (UML),запросов к БД (SQL) и языков программирования;поддержка качественного проектирования и разработкиCASE-средствами, языками и инструментамиСоглашения опроектировании, моделировании, кодированииАктивное применение языков моделирования и CASE-технологий; автоматическая генерация исходного кода итехнической документации по нему1234Аудит наличной архитектуры и кодовой базыРазработка и реализация плана рефакторинга архитектурысистемы и ее исходного программного кода
  32. 32. РЕАЛЬНО ЛИ ПОВЫСИТЬ СТРУКТУРНОЕКАЧЕСТВО УЖЕ НАПИСАННЫХ ПРИЛОЖЕНИЙ?Да!❶ Провести комплексорганизационных мероприятий❷ Запустить систематическийрефакторинг архитектурыи исходного кода❸ Провести дополнительноетестирование приложения❹ На регулярной основе пересматриватьи ужесточать требования действующеймодели качества приложения❺ Держаться курса, чего бы это ни стоило!
  33. 33. СПАСИБО! ВОПРОСЫ?Алексей ПЕТРОВeducation@luxoft.com

×