Polymorphism (Полиморфизм)
Полиморфизм позволяет обрабатывать альтернативные варианты поведения на основе типа и заменять подключаемые компоненты системы. Обязанности распределяются для различных вариантов поведения с помощьюполиморфных операций для этого класса. Все альтернативные реализации приводятся к общему интерфейсу.
Пример: Интеграция разрабатываемой системы с различными внешними системами учета налогов. Используются локальные программные объекты, обеспечивающие адаптацию (Адаптеры). При отправке сообщения к такому объекту выполняется обращение к внешней системе с использованием ее собственного программного интерфейса. Использование полиморфизма здесь оправдано для возможной адаптации к различным внешним системам.
Проблема. Как обрабатывать альтернативные варианты поведения на основе типа? Как создавать подключаемые программные компоненты?
Решение. Если поведение объектов одного типа (класса) может изменяться, обязанности распределяются для различных вариантов поведения с использованием полиморфных операций для этого класса.
Полиморфизм – это основной принцип проектирования поведения системы в рамках обработки аналогичных ситуаций. Если обязанности в системе распределены на основе шаблона Polymorphism, то такую систему можно легко модифицировать, добавляя в нее новые вариации. Например, добавив класс для адаптации новой системы вычисления налоговых платежей со своим полиморфным методом getTaxes, разработчик никак не повлияет на дееспособность уже существующей части системы.
Преимущества
С помощью этого шаблона впоследствии можно легко расширять систему, добавляя в нее новые вариации. Новые реализации можно вводить без модификации клиентской части приложения.
Насле́дование — механизм объектно-ориентированного программирования (наряду с инкапсуляцией, полиморфизмом и абстракцией), позволяющий описать новый класс на основе уже существующего (родительского), при этом свойства и функциональность родительского класса заимствуются новым классом.
Другими словами, класс-наследник реализует спецификацию уже существующего класса (базовый класс). Это позволяет обращаться с объектами класса-наследника точно так же, как с объектами базового класса.
2. Что такое UML. Назначение UML.
Что такое UML
Унифицированный язык моделирования (UML) — это язык визуального
моделирования, который используется при документировании проектных
решений в процессе разработки программной системы. UML можно
использовать со всеми методами, во всех предметных областях и на всех этапах программной разработки. Этот язык призван объединить в единый стандартный подход весь опыт, который был накоплен в процессе использования старых способов моделирования, а также все лучшее из современных методов проектирования. UML состоит из четырех частей, описывающих различные аспекты системы: статические, динамические, организационные и относящиеся к окружению. Спецификация UML не определяет конкретный процесс разработки, однако, использовать этот язык моделирования удобнее всего в итеративном процессе. Впрочем, его можно применять в большинстве существующих объектно-ориентированных процессов разработки.
Основное назначение UML — предоставить, с одной стороны, достаточно формальное, с другой стороны, достаточно удобное, и, с третьей стороны, достаточно универсальное средство, позволяющее до некоторой степени снизить риск расхождений в толковании спецификаций.
Таким образом, второе по важности назначение UML состоит в том, чтобы служить адекватным средством коммуникации между людьми.
В оригинале данное назначение UML определено с помощью слова construct, которое мы передаем осторожным термином "проектирование". Речь идет о том, что UML предназначен не только для описания абстрактных моделей приложений, но и для непосредственного манипулирования артефактами, входящими в состав этих приложений, в том числе такими, как программный код.
3. Понятие модели программной системы. Концепции UML для описания (представления) модели программной системы.
Невозможно охватить все тонкие детали сложной программной системы одним взглядом. Как отмечают Клейн и Джингрич: “Необходимо понять как функцио-нальные, так и структурные свойства объектов. Следует уяснить также используемые механизмы наследования, индивидуальное поведение объектов и динамическое поведение системы в целом. Эта задача в чем-то аналогична показу футбольного или теннисного матча, когда для вразумительной передачи
происходящего действия требуется несколько камер, расположенных в разных углах спортивной площадки. Каждая камера передает свой аспект игры, недоступный другим камерам”. На Рис. 6.1 представлены различные типы моделей, которые считаются главными в объектно-ориентированном подходе. Через них будут выражаться результаты анализа и проектирования, выполненные в рамках любого проекта. Эти модели в
совокупности семантически достаточно богаты и универсальны, чтобы разработчик мог выразить все заслуживающие внимания стратегические и тактические решения, которые он должен принять при анализе системы и формировании ее архитектуры. Кроме того, эти модели достаточно полны, чтобы служить техническим проектом реализации практически на любом объектно-ориентированном языке программирования. Следует помнить, что обозначения – только средство выразить итоги размышлений над архитектурой и поведением системы, а никак не самоцель. Надо пользоваться исключительно теми элементами обозначений, которые необходимы, и не более того. Также как опасно ставить слишком жесткие требования, нехорошо чересчур подробно описывать решение задачи. Например, на чертеже архитектор
может показать расположение выключателя света в комнате, но его точное место не будет определяться, пока заказчик и прораб не произведут осмотр уже сооруженного здания для уточнения деталей отделки.
Рис. 6.1 Объектные модели Глупо было бы заранее указывать на чертеже трехмерные координаты этого выключателя (конечно, если это не является функционально важной деталью для заказчика: может быть, все члены его семьи имеют рост намного выше или ниже среднего). Если разработчики большой программной системы — высоко-квалифицированные специалисты и уже сработались друг с другом, им будет дос-
таточно и грубых набросков, хотя и в этом случае они должны оставить свое твор-ческое наследие эксплуатационщикам в удобоваримом виде. Если же разработчики неопытны, отделены друг от друга во времени или пространстве или если так установлено контрактом, то на протяжении всего процесса проектирования необходимы более детальные эскизы проекта.
4. Диаграмма классов.
Диаграмма классов (Static Structure diagram) — статическая структурная диаграмма, описывающая структуру системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
· концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
· точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
· точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Основой статического представления модели являются классы и их отношения: ассоциации, обобщения и различные виды зависимостей, например реализация и использование. Класс – это некоторая сущность, инкапсулирующая данные и поведение. Классы являются тем центром, вокруг которого строится представление классов. Все прочие элементы либо принадлежат классам, либо относятся к ним.
Объект – это концепция, абстракция или сущность, обладающая
индивидуальностью и имеющая смысл в рамках приложения. Объект
является экземпляром класса.
Класс описывает группу объектов с одинаковыми свойствами (атрибутами),
одинаковым поведением (операциями), типами отношений и семантикой.
Классы можно описывать с разной степенью детализации. На ранней стадии проектирования модель отражает только логические аспекты системы. В процессе дальнейшей работы в модель вносится информация о различных проектных решениях и деталях реализации системы. Большинство представлений модели находятся приблизительно на одном уровне детализации. Связь – это физическое или концептуальное соединение между объектами. С математической точки зрения связь является кортежем, то есть списком объектов. Ассоциация – это описание группы связей, обладающих общей структурой и общей семантикой.
Агрегацией (aggregation) называется ассоциация, представляющая связь
«часть-целое». Схематически агрегация изображается в виде незакрашенного ромбика у класса-агрегата. Композиция (composition) – это более сильная форма агрегации, при которой агрегат несет полную ответственность за создание и уничтожение своих частей. Графически композиция изображается в виде закрашенного ромба у класса-агрегата. Между каждым классом, представляющим собой часть, и классом, представляющим собой целое, существует своя отдельная ассоциация, однако для удобства все ассоциации можно изображать в виде
дерева. Обобщение (generalization) – это вид отношений между общим описанием и специфическим описанием, которое основывается на общем и детализирует его.
5. Диаграмма вариантов использования.
Диаграмма вариантов использования (Use case diagram, диаграмма прецедентов) — диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования.
Основная задача — представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы. Диаграмма вариантов использования описывает функционирование системы с точки зрения ее пользователей, которые называются в моделировании актантами.
Вариант использования – это функциональный связный блок, выраженный в виде транзакции между актантом и системой. Вариант использования описывает последовательность действий, выполняемых системой с целью предоставить полезный результат конкретному актанту.
Назначение диаграммы вариантов использования – выявить всех актантов системы и все варианты ее использования, а также указать, какие актанты в каких вариантах использования фигурируют.
Ассоциация (использование) – пользователь имеет доступ к функционалу системы:
2.Обобщение (наследование) – поведение некоторых вариантов использования можно обобщить, вынести в отдельный вариант использования.
6. Диаграммы последовательности и кооперации.
На диаграммах последовательности отображаются сообщения в том же порядке, в котором они передаются во времени. Диаграмма последовательности описывает историю конкретной транзакции или сценарий. Одно из ее основных назначений – отобразить последовательность действий для части или целого варианта использования. В процессе реализации каждое сообщение на диаграмме соответствует вызову операции класса или формированию события в конечном автомате.
В нашем примере диаграмма последовательности отражает поток событий, происходящий в рамках варианта использования "Снять деньги" (Рис. 10.1). Это нормальный сценарий снятия $20 со счета (при отсутствии таких проблем, как неправильный идентификационный номер или недостаток денег на счету).
На диаграмме кооперации представлены объекты и связи между ними. Объекты и их связи имеют значение только в контексте определенного взаимодействия, причем объект описывается ролью-классификатором, а связь внутри кооперации – ролью-ассоциацией. Таким образом, диаграмма кооперации является графическим представлением взаимодействия этих двух ролей (Рис. 10.2).
Стрелки-сообщения, расположенные у линий, изображающих отношения,
связывают роли-классификаторы. Последовательность сообщений задается их нумерацией. Одно из назначений диаграммы кооперации – показать реализацию какой-либо операции. На диаграмме указываются параметры и локальные переменные операций, а также постоянные ассоциации. Последовательность сообщений на схеме соответствует структуре вложенных вызовов и прохождению сигналов в программе.
7. Диаграмма состояний и переходов.
Состояние (state) описывает период времени из жизненного цикла объекта. Оно характеризуется тремя дополнительными способами: набором значений объекта; временем ожидания наступления события; и временем деятельности. Состояние может иметь имя, однако чаще всего оно просто описывается своими действиями. В конечных автоматах состояния связаны между собой переходами. Переходы соединяют два различных состояния (или несколько, в случае если есть развилка или слияние управления). Обработка перехода производится в том состоянии, из которого он производится. Объект чувствителен к событиям, инициирующим переходы из того состояния, в котором он в данный момент
находится. Состояние изображается на диаграммах в виде рямоугольника с закругленными углами (Рис. 9.2).
Переход (transition) из некоторого состояния представляет собой реакцию объекта, находящегося в этом состоянии, на событие. Переход определяется переключающим событием, сторожевым условием, действием и целевым состоянием. В Таблица 9.2 вы найдете типы ереходов те действия, которые они вызывают. 
8. Диаграмма деятельности.
8. Диаграмма деятельности
Диаграмма деятельности (Activity diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.
Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения состояний и переходов. Отличие заключается в семантике состояний, которые используются для представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами – переходы от одного состояния действия к другому.
Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Именно они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Метамодель UML предоставляет для этого необходимые термины и семантику. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. При этом каждое состояние может являться выполнением операции некоторого класса либо ее части, позволяя использовать диаграммы деятельности для описания реакций на внутренние события системы.
В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения.
9. Диаграмма компонентов. Диаграмма развёртывания.
Диагра́мма компоне́нтов, Component diagram — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Компоненты связываются через зависимости, когда соединяется требуемый интерфейс одного компонента с имеющимся интерфейсом другого компонента. Таким образом иллюстрируются отношения клиент-источник между двумя компонентами.
Зависимость показывает, что один компонент предоставляет сервис, необходимый другому компоненту. Зависимость изображается стрелкой от интерфейса или порта клиента к импортируемому интерфейсу.
Когда диаграмма компонентов используется, чтобы показать внутреннюю структуру компонентов, предоставляемый и требуемый интерфейсы составного компонента могут делегироваться в соответствующие интерфейсы внутренних компонентов.
Диагра́мма развёртывания, Deployment diagram в UML моделирует физическое развертывание артефактов на узлах.[1] Например, чтобы описать веб-сайт диаграмма развертывания должна показывать, какие аппаратные компоненты («узлы») существуют (например, веб-сервер, сервер базы данных, сервер приложения), какие программные компоненты («артефакты») работают на каждом узле (например, веб-приложение, база данных), и как различные части этого комплекса соединяются друг с другом (например, JDBC, REST, RMI).
Узлы представляются как прямоугольные параллелепипеды с артефактами, расположенными в них, изображенными в виде прямоугольников. Узлы могут иметь подузлы, которые представляются как вложенные прямоугольные параллелепипеды. Один узел диаграммы развертывания может концептуально представлять множество физических узлов, таких как кластер серверов баз данных.
Существует два типа узлов:
1. Узел устройства
2. Узел среды выполнения
Узлы устройств — это физические вычислительные ресурсы со своей памятью и сервисами для выполнения программного обеспечения, такие как обычные ПК, мобильные телефоны. Узел среды выполнения — это программный вычислительный ресурс, который работает внутри внешнего узла и который предоставляет собой сервис, выполняющий другие исполняемые программные элементы.
Диагра́мма компоне́нтов:
Диагра́мма развёртывания:
10. Интерфейс. Абстрактный класс. Отличия.
ИНТЕРФЕЙС (английское interface), совокупность технических и программных средств, обеспечивающих взаимодействие различных функциональных устройств вычислительных, управляющих или измерительных систем (например, оперативного и внешнего запоминающих устройств ЭВМ). Интерфейс позволяет набирать системы из готовых модулей в соответствии с установленными правилами и соглашениями в отношении кодирования и синхронизации передаваемой информации, механические и электрические соединения устройств, вида сигналов, формы представления информации и т.д.
интерфейс — это класс, который обеспечивает программисту простой или более программно-специфический способ доступа к другим классам.
Абстрактный класс - класс, который оставляет некоторые или все члены не реализованными, реализацию которых оставляют производным классам.
Отличия:
| Интерфейс: | Абстр.Класс: |
| Содержит объявления методов, но не реализацию | Содержит абстактныеметоды и обычные методы |
| НЕ включает в себя св-ва (поля, костанты) | ВКЛЮЧАЕТ св-ва(поля, константы) |
| Все методы открыты | Присутствуют все виды защищенности |
| Реализуется | наследуется |
11. Понятие шаблона проектирования. Назначение шаблонов проектирования.
Шаблон проектирования или паттерн (англ. design pattern) — повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста. Обычно шаблон не является законченным образцом, который может быть прямо преобразован в код; это лишь пример решения задачи, который можно использовать в различных ситуациях. Объектно-ориентированные шаблоны показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться.
«Низкоуровневые» шаблоны, учитывающие специфику конкретного языка программирования, называются идиомами. Это хорошие решения проектирования, характерные для конкретного языка или программной платформы, и потому не универсальные.
На наивысшем уровне существуют архитектурные шаблоны, они охватывают собой архитектуру всей программной системы.
Назначение шаблонов проектирования можно, в частности, сформулировать следующим образом: они служат для уточнения и улучшения подсистем или компонентов. При последующем рассмотрении двух других категорий шаблонов обнаружится следующий характерный факт: шаблоны проектирования часто используются в других шаблонах, а некоторые из них могут применяться особым образом.
12. Шаблон Information Expert (информационный эксперт).
Information Expert (Информационный эксперт)
Шаблон Information Expert определяет базовый принцип назначения обязанностей. Он утверждает, что обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется информационным экспертом. Возможно, этот шаблон является самым очевидным из девяти, но вместе с тем и самым важным.
Если дизайн не удовлетворяет этому принципу, то при программировании получается спагетти-код, в котором очень трудно разбираться. Локализация обязанностей позволяет повысить уровень инкапсуляции и уменьшить уровень связанности. Кроме читабельности кода повышается уровень готовности компонента к повторному использованию.
Проблема. Каков наиболее общий принцип распределения обязанностей между
объектами при объектно-ориентированном проектировании?
Решение. Назначить обязанность информационному эксперту – классу, у которого
имеется информация, требуемая для выполнения обязанности.
Преимущества
Шаблон Expert поддерживает инкапсуляцию. Для выполнения требуемых задач
объекты используют собственные данные. Соответствующее поведение системы обеспечивается несколькими классами, содержащими требуемую информацию. Это приводит к определениям классов, которые гораздо проще понимать и поддерживать.
13. Шаблон Creator (создатель).
Creator (Создатель)
Шаблон Creator решает, кто должен создавать объект. Фактически, это применение шаблона Information Expert к проблеме создания объектов. Более конкретно, нужно назначить классу B обязанность создавать экземпляры класса A, если выполняется как можно больше из следующих условий:
· Класс B содержит или агрегирует объекты A.
· Класс B записывает экземпляры объектов A.
· Класс B активно использует объекты A
· Класс B обладает данными инициализации для объектов A.
Альтернативой создателю является шаблон проектирования Фабрика. В этом случае создание объектов концентрируется в отдельном классе.
Проблема. Кто должен отвечать за создание нового экземпляра некоторого класса?
Решение. Назначить классу В обязанность создавать экземпляры класса А, если выполняется одно из следующих условий.
Преимущества
Применение шаблона Creator не повышает степени связанности, поскольку созданный (created) класс, как правило, оказывается видимым для класса-создателя посредством имеющихся ассоциаций.
14. Шаблон Low Coupling (слабое связывание).