Архитектура программного обеспечения

Размещено на http://www.allbest.ru/

Архитектура программного обеспечения

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

Точка зрения (viewpoint) -- это определенный взгляд на систему, который осуществляется для выполнения какой-то определенной задачи кем-либо из участников проекта.

Точку зрения нужно ясно осознавать при создании визуальных моделей, например, варианты использования. Важно понимать, что она может быть в каждом конкретном случае своя.

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

Важным вопросом, на который нужно честно себе ответить в самом начале моделирования -- это зачем вы используете диаграммы (в частности, UML). Это и есть определение цели моделирования.

Потому, что так создавать модели правильно? И все проблемы (даже те, о которых ничего еще не известно) волшебным образом исчезнут? Очень часто, например, при создании модели случаев использования присутствует именно такая "цель" моделирования. А потом оказывается, что никакие проблемы не "вылечились", а наоборот, возникли новые (например, созданные нами диаграммы никто не понимает и не принимает). Да и сам аналитик чувствует, что диаграммы получились какие-то странные….

А может все происходит совсем не так. Например, аналитик действительно задался целью выявить требования к системе -- не навязать свое собственное видение другим, а выяснить нужную информацию, смоделировать и изложить ее доступно. Для этого он и использует диаграммы случаев использования. Ему важно, чтобы будущие пользователи системы могли участвовать в этом процессе, диаграммы рисуются для них, они понятны и не избыточны. И эти же диаграммы структурируют и проясняют информацию для самого аналитика.

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

Анализ области решений

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

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

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

Таким образом, явно или неявно, проводится анализ области решений.

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

Искомый способ организации ПО в виде системы взаимодействующих компонентов называют архитектурой, а процесс ее создания -- проектированием архитектуры ПО.

Архитектура программного обеспечения

Под архитектурой ПО понимают набор внутренних структур ПО, которые видны с различных точек зрения и состоят из компонентов, их связей и возможных взаимодействий между компонентами, а также доступных извне свойств этих компонентов [1].

Под компонентом в этом определении имеется в виду достаточно произвольный структурный элемент ПО, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает.

Архитектура программной системы похожа на набор карт некоторой территории.

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

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

Рассмотрим в качестве примера программное обеспечение авиасимулятора для командной тренировки пилотов.

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

Симулятор должен:

· Моделировать определенные условия полета и создавать некоторые события, к которым относятся следующие:

o Скоростной и высотный режим полета, запас горючего, их изменения со временем.

o Модель самолета и ее характеристики по управляемости, возможным режимам полета и скорости реакции на различные команды.

o Погода за бортом и ее изменения со временем.

o Рельеф и другие особенности местности в текущий момент, их изменения со временем.

o Исходный и конечный пункты полета, расстояние и основные характеристики рельефа между ними.

o Исправность или неисправность элементов системы контроля полета и управления самолетом, показатели системы мониторинга и их изменение со временем.

o Наличие пролетающих вблизи курса самолета других самолетов, их геометрические и скоростные характеристики.

o Чрезвычайные ситуации, например, террористы на борту, нарушение герметичности корпуса, внезапные заболевания и "смерть" отдельных членов экипажа.

При этом вся совокупность условий должна быть непротиворечивой, выглядеть и развиваться подобно реальным событиям. Некоторые условия, например, погода, должны изменяться достаточно медленно, другие события -- происходить внезапно и приводить к связанным с ними последствиям (нарушение герметичности корпуса может сопровождаться поломками каких-то элементов системы мониторинга или "смертью" одного из пилотов). Если приборы показывают наличие грозы по курсу и они исправны, через некоторое время летчики должны увидеть грозу за бортом и она может начать оказывать влияние на условия полета.

· Принимать команды, подаваемые пилотами, и корректировать демонстрируемые характеристики полета и работы системы управления самолетом в зависимости от этих команд, симулируемой модели самолета и исправности системы управления. Например, при повороте на некоторый угол вправо, показываемый пилотам "вид из кабины" должен переместиться на соответствующий угол влево со скоростью, соответствующей скорости реакции симулируемой модели самолета и исправности задействованных элементов системы управления.



Рис. 6.1. Набросок архитектуры такого авиасимулятора.

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

Пунктирные стрелки изображают потоки данных, передаваемых для протоколирования.

Список стандартов, регламентирующих описание архитектуры, которое является основной составляющей проектной документации на ПО, выглядит так:

· IEEE 1016-1998 Recommended Practice for Software Design Descriptions [2] (рекомендуемые методы описаний проектных решений для ПО).

· IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems [3] (рекомендуемые методы описания архитектуры программных систем).

Стандарт IEEE 1471 определяет также представление архитектуры (architectural description) как согласованный набор документов, описывающий архитектуру с точки зрения определенной группы заинтересованных лиц с помощью набора моделей. Архитектура может иметь несколько представлений, отражающих интересы различных групп заинтересованных лиц.

Стандарт IEEE 1471 отмечает необходимость использования архитектуры системы для решения таких задач, как следующие:

o Анализ альтернативных проектов системы.

o Планирование перепроектирования системы, внесения изменений в ее организацию.

o Общение по поводу системы между различными организациями, вовлеченными в ее разработку, эксплуатацию, сопровождение, приобретающими систему или продающими ее.

o Выработка критериев приемки системы при ее сдаче в эксплуатацию.

o Разработка документации по ее использованию и сопровождению, включая обучающие и маркетинговые материалы.

o Проектирование и разработка отдельных элементов системы.

o Сопровождение, эксплуатация, управление конфигурациями и внесение изменений и поправок.

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

o Проведение обзоров, анализ и оценка качества системы.

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

1. Выделение компонентов

o Выбирается набор "основных" сценариев использования -- наиболее существенных и выполняемых чаще других.

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

o Каждый сценарий использования системы представляется в виде последовательности обмена сообщениями между полученными компонентами.

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

2. Определение интерфейсов компонентов

o Для каждого компонента в результате выделяется его интерфейс -- набор сообщений, которые он принимает от других компонентов и посылает им.

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

o Если интерфейсы недостаточны, они расширяются.

o Если интерфейс компонента слишком велик, или компонент отвечает за слишком многое, он разбивается на более мелкие.

3. Уточнение набора компонентов

o Там, где это необходимо в силу требований эффективности или удобства сопровождения, несколько компонентов могут быть объединены в один.

o Там, где это необходимо для удобства сопровождения или надежности, один компонент может быть разделен на несколько.

4. Достижение нужных свойств.

Все это делается до тех пор, пока не выполнятся следующие условия:

o Все сценарии использования реализуются в виде последовательностей обмена сообщениями между компонентами в рамках их интерфейсов.

o Набор компонентов достаточен для обеспечения всей нужной функциональности, удобен для сопровождения или портирования на другие платформы и не вызывает заметных проблем производительности.

o Каждый компонент имеет небольшой и четко очерченный круг решаемых задач и строго определенный, сбалансированный по размеру интерфейс.

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

Пример работы индексатора текста

1. Выделим следующие сценарии работы или модификации программы:

o Надо сделать так, чтобы индексатор мог работать в инкрементальном режиме, читая на входе одну фразу за другой и пополняя получаемый в процессе работы индекс.

o Надо сделать так, чтобы индексатор мог игнорировать предлоги, союзы, местоимения, междометия, частицы и другие служебные слова.

o Надо сделать так, чтобы индексатор мог обрабатывать тексты, подаваемые ему на вход в виде архивов.

o Надо сделать так, чтобы в индексе оставались только слова в основной грамматической форме -- существительные в единственном числе и именительном падеже, глаголы в неопределенной форме и пр.

2. Определим две возможных архитектуры индексатора для сравнительного анализа.

o В качестве первой архитектуры рассмотрим разбиение индексатора на два компонента. Один компонент принимает на свой вход входной текст, полностью прочитывает его и выдает на выходе список слов, из которых он состоит. Второй компонент принимает на вход список слов, а на выходе выдает его упорядоченный вариант без повторений. Этот вариант архитектуры построен в стиле "каналы и фильтры"

Архитектура индексатора в стиле "каналы и фильтры"

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

В дополнение к этим данным имеются следующие компоненты:

1. Первый читает очередной символ на входе и передает его на обработку одному из остальных.

Если это разделитель слов (пробел, табуляция, перевод строки), управление получает второй компонент.

Если это буква -- третий.

Если входной текст кончается -- четвертый.

2. Второй компонент закачивает ввод последнего слова -- оно помещается в список перед тем местом, на которое указывает ссылка, после чего последнее слово становится пустым, а ссылка начинает указывать на первое слово в списке.

3. Третий компонент добавляет прочитанную букву в конец последнего слова, после чего, быть может, перемещает ссылку на следующее за полученным слово в списке.

4. Четвертый компонент выдает полученный индекс на выход.

Эта архитектура построена в стиле "репозиторий" (см. следующую лекцию).

Архитектура индексатора в стиле репозитория

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

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

Образцы проектирования. Чем отличается работа опытного проектировщика программного обеспечения от работы новичка?

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

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

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

Более того, люди, наиболее активно вовлеченные в поиск образцов проектирования в середине 90-х годов прошлого века, пытались создать основанные на образцах языки, которые, хотя и были бы специфичными для определенных предметных областей, имели бы более высокий уровень абстракции, чем обычные языки программирования. Предполагалось, что человек, знакомый с таким языком, практически без усилий сможет создавать приложения в данной предметной области, компонуя подходящие образцы нужным способом. Эту программу реализовать так и не удалось, однако выявленные образцы, несомненно, являются одним из самых значимых средств передачи опыта проектирования сложных программных систем.

Образец (pattern) представляет собой шаблон решения типовой, достаточно часто встречающейся задачи в некотором контексте, т.е. при некоторых ограничениях на ожидаемые решения и определенном наборе требований к ним.

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

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

Если можно представить набор требуемых операций как интерфейс некоторого класса в объектно-ориентированном языке программирования, достойно выйти из такой ситуации поможет образец проектирования адаптер (adapter).

Структура классов-участников образца "адаптер"

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

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

Образцы проектирования часто сильно связаны друг с другом в силу того, что они решают смежные задачи. Поэтому часто наборы связанных, поддерживающих друг друга образцов представляются вместе в виде систем образцов (pattern system) или языка образцов (pattern language), в которых указаны возникающие между ними связи и описываются ситуации, в которых полезно совместное использование нескольких образцов:

По типу решаемых задач выделяют следующие разновидности образцов:

· Образцы анализа (analysis patterns).

Они представляют собой типовые решения при моделировании сложных взаимоотношений между понятиями некоторой предметной области. Обычно они являются представлением этих понятий и отношений между ними с помощью набора классов и их связей, подходящего для любого объектно-ориентированного языка. Такие представления обладают важными атрибутами качественных модельных решений -- способностью отображать понятным образом большое многообразие ситуаций, возникающих в реальной жизни, отсутствием необходимости вносить изменения в модель при небольших изменениях в требованиях к основанному на ней программному обеспечению и удобством внесения изменений, вызванных естественными изменениями в понимании моделируемых понятий. В частности, небольшое расширение данных, связанных с некоторым понятием, приводит к небольшим изменениям в структуре, чаще всего, лишь одного класса модели.

Образцы анализа могут относиться к определенной предметной области, как следует из их определения, но могут также и с успехом быть использованы для моделирования понятий в разных предметных областях.

· Архитектурные образцы или архитектурные стили (architectural styles, architectural patterns).

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

· Образцы проектирования (design patterns) в узком смысле.

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

· Идиомы (idioms, programming patterns).

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

· Образцы организации (organizational patterns) и образцы процессов (process patterns).

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

Образец анализа является типовым решением по представлению набора понятий некоторой предметной области в виде набора классов и связей между ними.

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

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

Такого рода ошибка в 1998 году вывела из строя американский космический аппарат Mars Climate Orbiter, предназначавшийся для исследования климата Марса. Данные о текущих параметрах движения аппарата поступали на Землю, обрабатывались, и результирующие команды отправлялись обратно. При этом процедуры мониторинга и управления движением на самом аппарате воспринимали величину импульса как измеренную в Ньтонах на секунду, а программы обработки данных на Земле -- как значение импульса в фунтах силы на секунду.

В итоге это привело к выходу на гораздо более низкую, чем планировалось, орбиту, потере управления и гибели аппарата стоимостью около 130 миллионов долларов

Поэтому более аккуратное решение -- использовать для хранения данных числовых измерений объекты специального класса Quantity, в полях которого хранится не только значение величины, но и единица ее измерения. Кроме того, весьма полезно определить операции сложения, вычитания и сравнения таких величин.

архитектура программный интерфейс индексатор



Класс для представления величин, имеющих разные единицы измерения

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

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

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

Представление возможных преобразований между единицами измерений

Другой тип связи между различными единицами измерения -- так называемые составные единицы, например Ньютон для измерения силы (1 Н = 1 кг*м/с2). Разрешение подобного рода соотношений может быть реализовано, если определить два подкласса класса Unit -- один для представления простых единиц, PrimeUnit, другой для представления составных, CompoundUnit, и определить две связи, сопоставляющие одной составной единице два мультимножества простых -- те, что участвуют в ней в положительных степенях, и те, что участвуют в отрицательных.

Представление составных единиц измерений

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

Для того чтобы различать оба этих атрибута измерения -- объект измерения и вид измерения (например, пациент Иванов Петр Сергеевич и окружность его талии), -- их нужно явно ввести в модель. Так возникает образец измерение. Этот образец становится полезным, если имеется очень много различных измерений для каждого объекта, группируемых в достаточно много видов измеряемых явлений.



Набор классов для представления результатов измерений

Бывает, однако, необходимо вести учет не только количественных измерений, но и качественных наблюдений, результат которых представляется не числом, а некоторым значением перечислимого типа (группа крови II, ожог 3-й степени и пр.). При этом наблюдения очень похожи на измерения: относятся к некоторому объекту и определяют некоторое значение для какого-то вида наблюдений.

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

· Название образца, а также другие имена, под которыми этот образец используется.

· Назначение -- задачи, которые решаются с помощью данного образца. В этот же пункт включается описание контекста, в котором данный образец может быть использован.

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

· Решение -- основные идеи используемого решения. Включает следующие подпункты:

o Структура -- структура компонентов, принимающих участие в данном образце, и связей между ними. В рамках образца компоненты принято именовать, исходя из ролей, которые они в нем играют.

o Динамика -- основные сценарии совместной работы компонентов образца.

o Реализация -- возможные проблемы при реализации и способы их преодоления, примеры кода на различных языках (в данном курсе мы будем использовать для примеров только язык Java). Варианты и способы уточнения данного образца.

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

· Известные примеры использования данного образца.

· Другие образцы, связанные с данным.

Размещено на Allbest.ru

...