2020-06-29
522
Дата: 08.06.2020 (2 часа)
ИСиП Основы алгоритмизации и программирования
Лекция №48-49
Проектирование объектно-ориентированного приложения. Создание интерфейса пользователя
| Объектно-ориентированный метод проектирования приложения состоит из трёх этапов: 1. Объектно–ориентированный анализ.Создание объектно-ориентированной модели предметной области приложения. Здесь объекты отражают реальные объекты-сущности и операции, выполняемые этими объектами. 2. Объектно-ориентированное проектирование. Разработка объектно-ориентированной модели системы ПО (системной архитектуры) с учётом требований. В этой модели определение всех объектов подчинено решению конкретной задачи. 3.Объектно-ориентированное программирование. Реализация архитектуры (модели) системы с помощью объектно-ориентированного языка программирования (С++, С#, Java) для определения объектов и средств определения классов объектов. Объектно-ориентированные системы можно рассматривать как совокупность автономных и независимых объектов. Изменение реализации какого-нибудь объекта или добавление ему новых функций не влияет на другие объекты системы. Четкое соответствие между реальными объектами (например, аппаратными средствами) и управляющими объектами программной системы облегчает понимание и реализацию проекта. Объекты могут быть повторно используемыми компонентами, они независимо инкапсулируют данные о состоянии и операциях. Архитектуру ПО можно разрабатывать проект на базе объектов, ранее созданных в предыдущих проектах. Это снижает стоимость проектирования, программирования и тестирования ПО. Кроме того, возможность использования стандартных объектов уменьшает риск, связанный с разработкой ПО. Модель окружения системы и модель использования системы представляют собой две взаимно дополняющие друг друга модели взаимоотношений системы и с ее средой: Модель окружения системы – это статическая модель, которая описывает другие системы из пространства разрабатываемого ПО. Модель использования системы – динамическая модель, которая показывает взаимодействие данной системы со своим окружением (средой). Когда взаимодействия между проектируемой системой ПО и ее окружением определены, эти данные можно использовать как основу для разработки архитектуры системы. При этом необходимо применять знания об общих принципах проектирования системных архитектур и данные о конкретной предметной области. Существует два типа моделей системной архитектуры: – статические модели, которые описывают статическую структуру системы в терминах классов объектов и взаимоотношений между ними. Основными взаимоотношениями, которые документируются на данном этапе, являются отношения обобщения, отношения «используют-используются» и структурные отношения. – динамические модели, которые описывают динамическую структуру системы и показывают взаимодействия между объектами системы (но не классами объектов). Документируемые взаимодействия содержат последовательность запросов к сервисам объектов и описывают реакцию системы на взаимодействия между объектами. Язык моделирования UML поддерживает большое количество возможных статических и динамических моделей, в том числе модель подсистем и модель последовательностей. Модель последовательностей – одна из наиболее полезных и наглядных моделей, которая в каждом узле взаимодействия документирует последовательность происходящих взаимодействий между объектами. Метод моделирования UML Метод UML (United Modeling Language – унифицированный язык моделирования) является результатом совместной разработки специалистов программной инженерии и инженерии требований [6, 7]. Он широко используется ведущими разработчиками программного обеспечения как метод моделирования программных продуктов на всех стадиях жизненного цикла разработки программных систем. В основу метода положена парадигма объектного подхода, при котором концептуальное моделирование проблемы происходит в терминах взаимодействия объектов: – онтология домена определяет состав классов объектов домена, их атрибутов и взаимоотношений, а также услуг (операций), которые могут выполнять объекты классов; – модель поведения определяет возможные состояния объектов, инциденты, инициирующие переходы с одного состояния к другому, а также сообщения, которыми обмениваются объекты; – модель процессов определяет действия, которые выполняют объекты. UML концептуальная модель требований рассматривается как совокупность нотаций – диаграмм, которые визуализируют основные элементы структуры системы. Метод UML обеспечивает эффективное представление взаимодействий между разными участниками разработки с заданием комментариев. Допускаются два вида комментариев: традиционный неформальный текст или стереотип. Стереотип– это средство метаклассификации элемента в UML, т.е. стандартизированный комментарий элемента, который представлен какой-нибудь из диаграмм и характеризует содержание элемента диаграммы или его назначение. Они задаются на диаграммах названием, которое приводится в двойных угловых скобках (например, <<треугольник>>,<<кривая>>). Некоторые стереотипы являются фиксированными в UML и имеют стандартные названия, например, <<актер>>, <<система>>, <<подсистема>>, <<исключительная ситуация>>, <<интерфейс>> и т.п. Кроме того, разработчик может вводить стереотипы, типичные для своего домена, т.е. UML разрешает расширять и адаптировать стереотипы к конкретным областям применения и облегчают понимание конкретных моделей. Совокупность диаграмм метода отображает наиболее важные случаи функционирования системы. Рассмотрим более подробно основные диаграммы. Диаграмма классов (Class diagram) отображает онтологию домена и по содержанию эквивалентна информационной модели метода С.Шлаера и С.Меллора. Она определяет состав классов объектов и их взаимоотношения. Диаграмма задается иконами и связями между ними. Икона – стандартизированное и фиксированное визуальное изображение определенного понятия, имеет вид прямоугольника, который может быть разделен на две или три части. Верхняя часть – обязательная, определяет имя класса. Вторая и третья части определяют соответственно – список атрибутов класса и список операций класса. Атрибутами могут быть типы значений в UML: – рublic (общий), что означает операцию класса, вызванную из любой части программы любым объектом системы, – protected (защищенный) означает операцию, вызванную лишь объектом того класса, в котором она определена или наследована, – private (частный) означает операцию, вызванную только объектом того класса, в котором она определена. В то же время пользователь может определять специфические для него атрибуты. Под операцией понимается сервис, который экземпляр класса может выполнять, если к нему будет произведен соответствующий вызов. Операция имеет название и список аргументов. Классы могут находиться в следующих отношениях или связях. Ассоциация – взаимная зависимость между объектами разных классов, каждый из которых является равноправным ее членом. Она может обозначать количество экземпляров объектов каждого класса, которые принимают участие в связи (0 – если ни одного, 1 – если один, * – если много). Зависимость между классами, при которой класс–клиент может использовать определенную операцию другого класса; классы могут быть связаны отношением трассирования, если один класс трансформируется во второй в результате определенного процесса ЖЦ. Экземпляризация– зависимость между параметризированным абстрактным классом–шаблоном (template) и реальным классом, который инициирует параметры шаблона (например, контейнерные классы языка С++). Диаграмма сценариев. Содержание и нотация этой диаграммы полностью совпадает с той, которая описана в методе Э.Джекобсона. Диаграммы моделирования поведения системы.Под поведением системы понимается множество объектов, которые обмениваются сообщениями с помощью следующих диаграмм: – последовательность, упорядочивающей взаимодействие объектов при обмене сообщениями; – сотрудничество, определяющей роль объектов во время их взаимодействия; – активность, показывающей потоки управления при взаимодействии объектов; – состояний, указывающих на динамику изменения объектов. Диаграмма последовательности применяется для задания взаимодействия объектов. Любому из объектов сценария ставится в соответствие его линия жизни, которая отображает ход событий от его создания до разрушения. Диаграмма представляет все объекты, которые принимают участие во взаимодействии. Их порядок не имеет принципиального значения и выбирается произвольно, руководствуясь наглядностью взаимодействия. Взаимодействие объектов контролируется событиями, которые происходят в сценарии и стимулируют посылки сообщений другому объекту. Диаграммы сотрудничества представляют совокупность объектов, поведение которых имеет значение для достижения целей системы, и взаимоотношения тех ролей, которые важны в сотрудничестве. На этой диаграмме можно моделировать статическое взаимодействие объектов без учета фактора времени. При параметризации диаграмма представляет абстрактную схему сотрудничества – паттерн, для которого может быть создано определенное множество конкретных схем сотрудничества. Диаграмма деятельности представляет поведение системы в виде определенных работ, которые может выполнять система или актер и эти работы могут зависеть от принятия решений в зависимости от условий, которые сложились. Эта диаграмма напоминает блок–схемы алгоритмов и программ, но в отличие от них, предусмотрена возможность выполнять параллельно несколько деятельностей и точки синхронизации их завершения. Диаграмма состояний базируется на использовании расширенной модели конечного автомата и определяет: – условия переходов и действия при переходе; – действия при входе в состояние, его активности и при выходе из состояния; – вложенные и параллельно действующие состояния. Переход по списку данных инициирует некоторое событие. Состояние зависит от условий перехода, что подобно тому, как взаимодействуют две параллельно работающие машины, если изменение состояния одной машины влияет на другую машину. Диаграмма реализации состоит из диаграммы компонента и диаграммы размещения. Диаграмма компонента отображает структуру системы как композицию компонентов и связей между ними. Это граф, узлами которого являются компоненты, а дуги отображают отношения зависимости. Диаграмма размещения задает состав физических ресурсов системы (узлов системы) и отношений между ними. Разрабатывается не только программная часть, но и необходимые аппаратные устройства, которые должны взаимодействовать с программными компонентами. В диаграмме обычно используются стереотипы: <<процессор>>, <<устройство>>, <<дисплей>>, <<память>>, <<диск>> и др. Пакеты в UML Предусмотрен общий механизм организации некоторых элементов (объектов, классов, подсистем и т.п.) в группы. Группирование возможно начиная от системы к подсистемам разного уровня детализации, вплоть до классов. Результат группирования называется пакетом. Пакет определяет название пространства, занимаемого элементами, которые являются его составляющими и средством ссылки на это пространство. Это важно для больших систем, которые насчитывают сотни, а иногда и тысячи элементов, и потому требуют иерархического структурирования. Подсистема в UML рассматривается как случай пакета, который имеет самостоятельную функцию. Пакет может быть вложенным, то есть состоять из пакетов, классов, подсистем и т.п. Объединение элементов в пакеты может происходить из разных соображений, например, если они используются совместно или созданы одним автором, или касаются определенного аспекта рассмотрения, как например, интерфейс с пользователем, устройства ввода/вывода и т.п. На стадии реализации к одному пакету могут быть отнесены все подсистемы, которые в диаграмме размещения связаны с одним узлом. Пакет может быть элементом конфигурации, как элемент композиции при построении системы, на которую можно ссылаться в разных диаграммах. Термином конфигурация обозначается структура программной системы из отдельных модулей или из заведомо определенного состава их вариантов. Так, например, ОС может включать конфигурацию модулей, которые позволяют взаимодействие с разнообразными устройствами, но лишь отдельные из них подключаться к данному компьютеру с созданной версией ОС в виде конкретной конфигурации. Среди фиксированных стереотипов для обозначения разновидностей пакета введены такие: система, прикладная система, подсистема, элемент конфигурации, составная системы, охватывающая система и др. Например, стереотип <<унаследовано>> может прибавляться к пакету, который является элементом старой версии системы и без переработки включен в новую версии системы. Компонентный подход к проектированию По оценкам экспертов, 75 % работ по программированию в мире дублируются (например, программы складского учета, начисления зарплаты, расчета затрат на производство продукции и т.п.). Большинство из этих программ типовые, но каждый раз находятся особенности, которые влияют на их повторное разработку. Компонентное проектирование сложных программ из готовых компонентов является наиболее производительным. Переход к компонентам происходил эволюционно: от подпрограмм, модулей, функций. При этом усовершенствовались элементы, методы их композиции и накопления для дальнейшего использования. Компонентный подход дополняет и расширяет существующие подходы в программировании, особенно ООП. Объекты рассматриваются на логическом уровне проектирования программной системы, а компоненты – это непосредственная физическая реализация объектов. Один компонент может быть реализацией нескольких объектов или даже некоторой части объектной системы, полученной на уровне проектирования. Компоненты конструируются как некоторая абстракция, которая состоит из трех частей: информационной, внешней и внутренней. Информационная часть представляет собой информацию о компоненте: назначение, дата изготовления, условия применения (ОС, среда, платформа и т.п.); уровень повторного использования; контекст или окружение; способ взаимодействия между собой компонентов. Внешняя часть определяет взаимодействие компонента со средой и с платформой, на которой он будет выполняться. Эта часть имеет следующие основные характеристики: – интероперабельность как способ взаимодействия с другими компонентами, с клиентом или сервером, а также обеспечения переносимости на другую платформу; – способ интеграции (композиции) компонентов; – нефункциональные сведения (безопасность, аутентификация, надежность и др.); – технология проектирования (например, объектно-ориентированная среда и т.п.) и повторное использования компонентов. Внутренняя часть – это некоторый артефакт (кластер, системная или абстрактная структура, фрагмент кода и др.) и вид его представления: проектный компонент, проектная спецификация, вычисляемая часть, код и др. Разработана новая архитектура компонента – контейнер, в котором определяются функции, порядок их выполнения, вызываемые события и сервисные свойства. Выполнение контейнера осуществляется через его интерфейс с помощью провайдера. Компоненты наследуются в виде классов и используются в модели или композиции, а также в каркасе интегрированной среды. Управление компонентами проводится на трех уровнях: архитектурном, компонентном и на уровне инфраструктуры интерфейса. Интерфейсы отображают взгляд пользователя на компонент, то есть что компонент будет делать, когда к нему обращаются. Реализация – это код, который будет использоваться при обращении к операциям, которые определены в интерфейсах компонента. Компонент может иметь несколько реализаций, например, в зависимости от операционной среды или от модели данных и соответствующей системы управления базами данных, которая необходима для функционирования компонента. Развертка – это физический файл или архив, готовый к выполнению, который передается пользователю и содержит все необходимые способы для создания, настройки и функционирования компонента. Компонент описывается в языке программирования, не зависит от операционной среды (например, от среды виртуальной машины JAVA) и от реальной платформы (например, от платформ в системе CORBA), где он будет функционировать. Расширением понятия компонента есть паттерн – абстракция, которая содержит описание взаимодействия совокупности объектов в общей кооперативной деятельности, для которой определены роли участников и их ответственность. Представляется повторяемой частью программного элемента, как схемы или взаимосвязи контекста описания решения проблемы. Интерфейс компонентов. Для объединения компонентов в компонентную модель необходимым условием является наличие формально определенных интерфейсов в языках IDL и APL, а также механизмов динамического контроля связей между компонентами в современных средах. Спецификация интерфейса в API и IDL включает описание функциональных свойств компонентов, их типов и порядка задания операций передачи аргументов и результатов для взаимодействия компонентов. То есть, компонент – физическая сущность, которая реализует определенную совокупность интерфейсов. Сами интерфейсы являются понятием, которое связывает логическую и физическую модели. Для описания самих компонентов, как правило, применяется ООП и его свойства: наследование, инкапсуляция, полиморфизм. В языке JAVA понятие интерфейса и класса являются базовыми. Компонентные модели – Javabeans и Enterprise Javabeans, а также модель CORBA используют объектно-ориентированные свойства. Типы компонентных структур Компонентная модель – отражает многочисленные проектные решения по композиции компонентов, определяет типы паттернов компонентов и допустимые между ними взаимодействия, а также снижает время развертывания программной системы в среде функционирования. Каркас – представляет собой высокоуровневую абстракцию проекта программной системы, в которой отделены функции компонентов от задач управления ими. То есть, бизнес–логика – это функции компонентов, а каркас задает правильное и надежное управление ими. Каркас объединяет множество взаимодействующих между собою объектов в некоторую интегрированную среду для решения заданной конечной цели. В зависимости от специализации каркас называют “белым или черным ящиком”. Каркас типа “белый ящик” включает абстрактные классы для представления цели объекта и его интерфейс. При реализации эти классы наследуются в конкретные классы с указанием соответствующих методов реализации. Использование такого типа каркаса более характерно для OOП. Для каркаса типа «черный ящик» в его видимую часть выносятся точки, разрешающие изменять входы и выходы. Композиция компонентов включает четыре возможных класса: – композиция компонент–компонент обеспечивает непосредственное взаимодействие компонентов через интерфейс на уровне приложения; – композиция каркас–компонент обеспечивает взаимодействие каркаса с компонентами, при котором каркас управляет ресурсами компонентов и их интерфейсами на системном уровне; – композиция компонент–каркас обеспечивает взаимодействие компонента с каркасом по типу «черного ящика», в видимой части которого находится спецификация для развертывания и выполнения определенной сервисной функции на сервисном уровне; – композиция каркас–каркас обеспечивает взаимодействие каркасов, каждый из которых может разворачиваться в гетерогенной среде и разрешать компонентам, входящим в каркас, взаимодействовать через их интерфейс на сетевом уровне. Компоненты и их композиции, как правило, запоминаются в репозитарии компонентов, а их интерфейсы к репозитарии интерфейсов. Повторное использование в компонентном программирование в общем случае представляет собой любые порции формализованных знаний, добытые во время реализации программных систем и используемых в новых разработках. Повторно используемые компоненты (ПИК} – элементы знаний о минувшем опыте разработки систем, которые могут использовать не только их разработчиками, но и путём адаптации к новым условиям. ПИК упрощает и сокращает сроки разработки новых программных систем. Высокий уровень стандартизации и распространение электронных коммуникаций (сети Интернет) обеспечивает довольно простое получение и широкое использование готовых компонентов в разных проектах за счет: – отражения фундаментальных понятий приложения; – скрытия способа представления и предоставления операций обновления и получения доступа; – обработки исключительных операций в приложении. При создании компонентов, предназначенных для повторного использования, общий интерфейс должен содержать операции, которые обеспечивают разные способы использования компонентов. Возможность повторного использования приводит к усложнению компонента, а значит к уменьшению понятности. Поэтому требуется некоторый компромисс между ними. Как и любые элементы промышленного производства, компоненты должны отвечать определенным требованиям, иметь характерные свойства, структуру, механизмы использования и др. В UML все компоненты делятся на три типа: 1) для развертывания в компьютерной среде; 2) как рабочие продукты (файлы текстов с программами и данными, элементы с описаниями архитектуры и правилами генерации конечного кода и др.); 3) для среды выполнения (временные программные объекты, файлы, таблицы базы данных и др.). Главным преимуществом создания программных систем из компонентов является уменьшение затрат на разработку за счет: – выбора готовых компонентов с подобными функциями, пригодными для практического применения; – настраивания готовых компонентов на новые условия, которые связаны с меньшими усилиями, чем разработка новых компонентов. Поиск готовых компонентов основывается на их классификации и каталогизации. Метод классификации предназначен для представления информации о компонентах с целью быстрого поиска и отбора. Метод каталогизации обеспечивает физическое размещение компонентов в репозитариях для непосредственного доступа к ним в процессе интеграции. Интероперабельность компонентов. Сложились ряд подходов для решения этой проблемы, наиболее часто они связаны с анализом кода для внесения изменений при переносе его в другую среду. Механизмы обеспечения интероперабельности имеют разные концепции и реализации, т.е. приведение представления одного компонента к форме, понятной второму либо к некоторому промежуточному состоянию. Стандартный механизм интероперабельности для связи между Java и C/C++ компонентами использует Java Native Interface (JNI) при реализации обращения из Java–классов к функциям и библиотекам на других ЯП. Механизм реализации включает: анализ Java–классов для поиска прототипов обращений к функциям на C/C++; генерацию заглавных файлов для использования их при компиляции C/C++ программ. Java–класс “знает”, что в нем помещается обращение не к Java–методу. Другой вариант реализации этой задачи предлагает технология Bridge2Java фирмы IBM alpha Works. В ней обеспечивается обращение из Java–классов к COM–компонентам. Для COM–компонента генерируется оболочка, которая включает прокси–класс для преобразования данных с помощью стандартной библиотеки типов и вызов COM– функций. Данная схема не требует изменений в исходном Java–классе, а COM–компоненты могут быть написаны на разных ЯП. Механизм интероперабельности предлагает и платформа.Net [17] с помощью промежуточного языка Common Language Runtime (CLR), в который транслируются коды, написанные в ЯП (C#, Visual Basic, C++, Jscript) и интегрируются эти компоненты. При этом используется библиотека стандартных классов независимо от языка реализации и доступа к готовым компонентам без ориентации на эту платформу (например, к COM–компонентам). С этой целью используются стандартные средства генерации оболочки для COM–компонента в представление.Net–компонента, а также для приведенных выше ЯП. Особенности ОС и архитектур компьютеров учитывает среда CORBA, в которой реализована иерархия механизмов интероперабельности – от самого верхнего уровня (поддержка разных ЯП) к самому нижнему (с учетом архитектуры). Методология компонентной разработки систем Эта методология включает в себя две основные фазы процесса разработки. 1. Разработка отдельных компонентов исходя из следующих требований: – формализованное определение спецификаций интерфейсов, поведения и функциональности компонента; – использование системы классификации для поиска и отбора необходимых компонентов, а также для их физического размещения; – обеспечение принципа повторности. Интеграция (композиция) компонентов в более сложные программные образования: – разработка требований (Requirements) к программной системе; – анализ поведения (Behavioral Analysis) программной системы; – спецификация интерфейсов и взаимодействия компонентов (Interface and Interaction Specification); – интеграция разработанных компонентов и компонентов повторного использования (Application Assembly and Component Reuse) в единую среду; – тестирование компонентов и среды; – развертывание (System Deployment) программной системы у пользователя; – поддержка и сопровождение программной системы (System Support and Maintenance). Аспектно-ориентированное программирование Аспектно-ориентированное программирование (АОП) – это парадигма построения гибких к изменению ПС за счет добавление новых функций, средств безопасности и взаимодействия компонентов с другой средой, синхронизации одновременного доступа частей ПС к данным, вызова общесистемных средств и др. Аспектом может быть некоторая функция, ПИК, элемент или часть готовой программы, отдельный компонент, концепция взаимодействия, защиты и др. Созданная средствами АОП ПС из отдельных программ семейства может включать набор ПИК, объекты, небольшие методы и аспекты, как средство дополнения ПС необходимыми концепциями взаимодействия или защиты для новой среды, которые пересекают (переплетают) компоненты и тем самым значительно усложняют процесс вычислений. Реализация аспектов в различных частях программного кода ПС решается путем установления перекрестных ссылок и точек соединения, через которые осуществляется связь аспекта с транзакциями, защитой данных и т.п. В основе АОП лежит метод разбиения задач ПрО на ряд функциональных компонентов с применением аспектов (синхронизации, взаимодействия, защиты и др.), которые встраиваются в отдельные компонентов в некоторые их точки для выполнения соответствующих не функциональных требований к организации выполнения компонента с другими компонентами или средами. Кроме того, в качестве аспекта может использоваться некоторая задача, которая интересует нескольких заинтересованных лиц проекта и представленная с помощью вариантов использования, функции для компонента или программы. Некоторые аспекты могут реализовываться на этапах ЖЦ процесса разработки, способствуя улучшению результат разработки ПС. |
|
|
|
|
|
|
|
|
|
|
|
|
