Файл: Инфрам.pdf

405
Такая минимизация интерфейсов позволяет увеличивать гибкость сис- темы.
Слои способны удачно инкапсулировать многое, но не все: модифи- кация одного слоя подчас связана с необходимостью внесения каскад- ных изменений в остальные слои. Наличие избыточных слоев нередко снижает производительность системы. При переходе от слоя к слою данные обычно подвергаются преобразованиям из одного представле- ния в другое. Несмотря на это, инкапсуляция нижележащих функций зачастую позволяет достичь весьма существенного преимущества. На- пример, оптимизация слоя транзакций обычно приводит к повышению производительности всех вышележащих слоев.
В статьях [15] рассматривается один из паттернов выделения слоев – представитель целого семейства паттернов выделения слоев. Подвидов у этого паттерна существует достаточно много, и каждый из них обла- дает своей спецификой. Рассматриваемый паттерн имеет следующую структуру (следуя терминологии автора статей).
Имя: выделение слоев.
Ситуация: на диаграмме представлены элементы, для которых вер- ны следующие условия: исходящие связи ведут только в последний выделенные слои (слой с номером n), или их нет, если ранее не был выделен ни один слой;
“кандидаты на объединение в новый слой” c номером n+1 должны обладать общим смыслом и/или функциональностью. Простейшей проверкой на наличие общности является простой критерий: если для кандидатов можно подобрать "общее определение", то можно считать что они обладают требуемой общностью.
Рецепт: Объединить блоки в новый слой “n+1”. Для двух произ- вольных слоев слой, обладающий большим порядковым номером, счи- тается "вышележащим". Если в результате применения паттерна было выделено n слоев, и еще остались блоки, которые в силу ограничений не смогли быть отнесены ни к одному из выделенных слоев и формально не могут быть выделены в новый слой, то эти блоки по-умолчанию счи- таются n+1 слоем, который в дальнейшем именуется "чердаком".
Различают строгие слои (гл.2. рис. 2.6), которые не допускают ника- ких отклонений в строгой структуре, и потому встречающейся относи- тельно редко, и нестрогие слои. Последние допускают связи вышеле- жащего слоя с несколькими нижележащими слоями (потенциально – ко всем), а не только к непосредственному соседу снизу. Как отмечается в
[14], архитектура с нестрогими слоями может быть как результатом эрозии, так и осознанным решением. Возможным дефектом архитекту- ры с нестрогими слоями является нарушение абстракции. Это затрудня- ет анализ системы. Кроме того, изменения слоя в такой архитектуре значительно сложнее локализовать – волна изменений прокатится по всем слоям, работающим с изменяемым слоем.
Как показано в разделе 6.5, рассмотренные виды слоев можно моди- фицировать, позволив включать в произвольные слои сильносвязанные компоненты (блоки C, D, E на рис. 6.8). При таком подходе сильносвя-

406 занные компоненты (СК) рассматривается, фактически, как атомарный элемент. Слои, содержащие СК в [14], названы поглощающими. Без подобного смягчения условий как сам СК, так и все блоки которые мог- ли бы попасть в вышележащие слои, будут отправлены на "чердак".
Заметим, что не всегда СК на структурных диаграммах свидетельствуют о плохой архитектуре системы. Возможным дефектом архитектуры с поглощающими слоями может стать эффект "пропавшего слоя" – де- фектная связь приводит к появлению СК, которые по смыслу должны находиться на разных слоях.
Паттерн выделения слоев может быть применен для чистого анализа
(раскопки) архитектуры. Выделение слоев – это прием, который позво- лит сократить и сделать более направленным семантический анализ системы за счет структурного анализа. Это, несомненно, хорошо, по- скольку семантический анализ – более ресурсоемкий процесс. При этом нет никакой необходимость отражения слоев на программный код и инфраструктуру его хранения. Например, при анализе архитектурного кода программной системы, написанной на Java, выделение слоев не предполагает обязательного выделения пакетов, соответствующих этим слоям. Если специалист, проводящий архитектурный рефакторинг, при- нимает решение все-таки не отображать слои в пакеты языка Java, то можно считать, что выделение слоев было применено для чистого ана- лиза архитектуры.
Выделение слоев – хорошая основа для улучшения системы. Найти строгие слои в произвольной программной системе значительно труд- нее, чем найти слои с некоторыми допустимыми отклонениями, как, например, сильносвязанные компоненты. Тем не менее, для каждого из допустимых отклонений известны побочные эффекты, которые можно устранять, по возможности приводя слои к строгим.
В заключение этого раздела отметим, что существуют и другие ар- хитектурные паттерны, часть из которых рассмотрена в [14]. В этой же работе предложены направления дальнейшего развития рефакторинга архитектуры:
1. Каталогизация. Направление связанное с дальнейшим сбором, обобщением и классификацией паттернов рефакторинга.
2. Автоматизация. Представляет большой интерес возможность об- легчения и автоматизации применения как существующих так вновь предлагаемых паттернов.
3. Верификация. Вызывает интерес возможность верификации со- хранности поведения программной системы при архитектурном рефак- торинге.
4. Направленность. Желательно вооружить разработчика, знающего паттерны архитектурного рефакторинга и имеющего соответствующие инструменты моделирования, процедурой, определяющей последова- тельность применения паттернов, чтобы сделать процесс эффективным.
Создание подобных процедур представляет значительный исследова- тельский интерес.

407
Литература к главе 8
1.
Model-View-Controller. http://ru.wikipedia.org/wiki/Model-view- controller
2.
Refactoring
(Рефакторинг)
(комментарии). http://www.gamedev.ru/code/forum/?id=131858 3.
Smalltalk?! http://www.smalltalk.ru/articles/smalltalk-2.html
4.
Welcome to Graphviz. http://graphviz.org/
5. wxWidgets. http://www.wxwidgets.org/
6.
Ворожко Я. Refactoring. http://pro100pro.com/category/refactoring
7.
Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разра- ботки программного обеспечения: учебное пособие / под ред. Л.Г. Гага- риной. – М.: ИД «ФОРУМ»: ИНФРА-М., 2008. – 400 с.
8.
Деревянко
В.
Рефакторинг в
Visual
Studio. http://soft.sibnet.ru/review/?id=623 9.
ДУБАКОВ М. Рефакторинг: улучшение существующего кода http://www.kv.by/index2003302301.htm
10. Дубина
О.
Обзор паттернов проектирования. http://citforum.ru/SE/project/pattern/p_4.shtml
11. Жидков Алексей П. Культура программирования.
12. Кериевски Дж. Рефакторинг с использованием шаблонов. : Пер. с англ. – М. : ООО “И.Д. Вильямс”, 2008. – 400 с.
13. Краковецкий А. Как писать высококлассный код. Часть вторая.
Возможности Visual Studio 2010. http://msug.vn.ua/Posts/Details/4165 14. Ксензов М. В. Рефакторинг архитектуры программного обеспе- чения. http://www.ispras.ru/ru/proceedings/docs/2004/8/1/isp_2004_8_1_211.pdf
15. Ксензов М. Рефакторинг архитектуры программного обеспече- ния: выделение слоев. Труды Института Системного Программирования
РАН, препринт 4, 2004, c. 211 – 227 16. Методы улучшения качества кода: рефакторинг. http://social.msdn.microsoft.com/Forums/ru- ru/fordesktopru/thread/63d9ba19-491b-4e75-9796-6de5132e1a56 17. Миронов В.О. Применение графов для анализа сложных сис- тем на основе исходного кода программ. http://berestneva.am.tpu.ru/Papers/KONF2009/%f7%c9%ce%c5%d2%cf%d7
%d3%cb%c9%c5%20%de%d4%c5%ce%c9%d1/2009%20(F)/fscommand/p df/056.pdf
18. Нильссон Дж. Глава из книги “Применение DDD и шаблонов проектирования: проблемно-ориентированное проектирование прило- жений с примерами на C# и .NET”. http://rsdn.ru/res/book/prog/ddd.xml
19. Обзор средств автоматизированного рефакторинга в Java IDE. http://www.javaportal.ru/java/ide/review_refactoring.html
20. Переименовать рефакторинг (C#) Visual Studio 2010 http://msdn.microsoft.com/ru-ru/library/6kxxabwd.aspx
21. Рефакторинг
- не панацея http://sly-and- fluffy.blogspot.com/2011/03/blog-post_25.html

408 22. Рефакторинг http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%84%D0%B0%D0%B
A%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3#.D0.9C.D0.B
5.D1.82.D0.BE.D0.B4.D1.8B_.D1.80.D0.B5.D1.84.D0.B0.D0.BA.D1.82.D0
.BE.D1.80.D0.B8.D0.BD.D0.B3.D0.B0#.D0.9C.D0.B5.D1.82.D0.BE.D0.B4.
D1.8B_.D1.80.D0.B5.D1.84.D0.B0.D0.BA.D1.82.D0.BE.D1.80.D0.B8.D0.
BD.D0.B3.D0.B0 23. Рефакторинг кода http://dev.mindillusion.ru/refactoring/
24. Рефакторинг. http://redoe.blogspot.com/2011/06/blog-post_29.html
25. Рефакторинг. http://ru.wikipedia.org/wiki/%D0%E5%F4%E0%EA%F2%EE%F0%E8%E
D%E3 26. Рефакторинги на уровне класса http://www.riotlabs.ru/post/Class- level-refactoring.aspx
27. Рефакторинги уровня метода http://www.riotlabs.ru/post/method-level- refactorings.aspx
28. Синдром рефакторинга http://habrahabr.ru/blogs/refactoring/120000/
29. Сперанский
В.
Рефакторинг: меняем архитектуру. http://www.pcmag.ru/solutions/sub_detail.php?ID=30214&SUB_PAGE=1 30. Тепляков С. Шаблоны проектирования. История успеха. RSDN
Magazine
#2-2010. http://sergeyteplyakov.blogspot.com/2010/01/blog- post.html
31. Технический долг http://habrahabr.ru/blogs/refactoring/119490/
32. Фаулер М., Бек К., Брант Д., Робертс Д., Апдайк У. Рефакто- ринг: улучшение существующего кода. – Спб: Символ-Плюс, 2009. —
С. 432.
33. Фаулер М.
Архитектура корпоративных программных прило- жений. Пер. с англ. — М.: Издательский дом "Вильяме", 2006. — 544 с.
34. Хант Э., Томас Д. Программист-прагматик. Путь от подмасте- рья к мастеру. Пер. с англ. Изд. Лори, 2009. – 270 с.
35. Черный С.Г. Оптимизация процесса структуризации кода. http://www.nbuv.gov.ua/portal/natural/Vejpt/2011_2_2/2011_2_2/31_34.pdf
36. Шаблон проектирования. http://ru.wikipedia.org/wiki/%D8%E0%E1%EB%EE%ED-
_%EF%F0%EE%E5%EA%F2%E8%F0%EE%E2%E0%ED%E8%FF
37. Эмблер С., Садаладж П. Рефакторинг баз данных: эволюцион- ное проектирование. Пер. с англ. — М.: Издательский дом "Вильяме",
2007. – 368 с.
38. Эффект второй системы http://habrahabr.ru/blogs/refactoring/121213/http://www.saasworld.ru/analyti cs/vend/

409
Содержание

Глава 1. Введение. Проблемы создания больших
программных систем
1.1. Особенности разработки сложных (больших) про- граммных систем
1.2. Проблемы создания ПС
1.3. Кризис программирования. Инженерный подход к раз- работке ПС
1.4. Становление и развитие программной инженерии
1.5. Развитие технологий программирования
1.6. Индустрия программного обеспечения
1.7. Современное состояние ИТ-индустрии в России
Глава 2. Архитектуры программных систем
2.1. Понятие архитектуры программной системы
2.2. Почему важна архитектура
2.3. Как появляется архитектура. Кто и что влияет на архи- тектуру
2.4. Архитектурные образцы, эталонные модели и эталон- ные варианты архитектуры
2.5. Что определяет и на что влияет выбранная архитектура
2.6. Архитектурные структуры и представления
2.7. Отношения между структурами
2.8. Варианты архитектур программных систем
2.8.1. Архитектура, основанная на уровнях абстракций
2.8.2. Архитектуры, основанные на портах
2.8.3. Архитектуры, основанные на потоках данных
2.8.4. Архитектуры независимых компонентов
2.8.5. Сервис-ориентированные архитектуры (SOA)
Глава 3. Жизненный цикл программных систем
3.1. Понятие жизненного цикла программных систем
3.2. Основные процессы ЖЦ ПС
3.3. Вспомогательные процессы ЖЦ ПО
3.4. Организационные процессы ЖЦ ПС
3.5. Взаимосвязь между процессами ЖЦ ПС
3.6. Модели и стадии ЖЦ ПС
3.7. Виды моделей ЖЦ ПС и технологии создания про- граммных систем
3.7.1. Каскадная модель (классический жизненный цикл)
3.7.2. Итерационная модель ЖЦ ПС
3.7.3. Макетирование
3.7.4. Стратегии конструирования ПС
3.7.5. Инкрементная модель
3.7.6. Спиральная модель ЖЦ ПО
3.7.7. Рациональный унифицированный процесс

410 3.7.8. SCRAM-методология
3.7.9. Agile-методологии
3.7.10. Управление жизненным циклом приложений.
Интегрированная среда поддержки создания программ- ных систем
Глава 4. Проектирование программных систем.
Определение требований и целей программного продукта
4.1. Процесс проектирования как последовательная транс- ляция требований, предъявляемых к системе
4.2. Методология решения задач проектирования ПС по Г.
Майерсу
4.3. Уровни требований к программным системам
4.4. Определение требований к программным системам
4.4.1. Постановка задачи и принципы разработки тре- бований
4.4.2. Бизнес-моделирование
4.4.3. Определение функциональных требований
4.4.4. Определение нефункциональных (эксплуатаци- онных) требований
4.5. Анализ и управление требованиями
4.6. Требования и риски
4.7. Проверка правильности требований
4.8. Цели программного продукта
4.9. Постановка целей для программной системы
4.9.1. Цели продукта
4.9.2.
Цели проекта
Глава 5. Разработка предварительного внешнего проекта
5.1. Представление и анализ требований
5.1.1. Требования в V-модели Халла
5.1.2. Моделирование в определении требований и спе- цификаций
5.1.3. Разработка программных систем, управляемая моделями
5.2. Анализ требований и определение спецификаций.
Структурный подход
5.2.1. Спецификации
5.2.2. Структурный подход представления специфика- ций
5.2.3. Метод функционального моделирования. Функ- циональные диаграммы