Сущность объектного подхода к разработке программных средств. Объектное моделирование как содержание этапа внешнего описания при объектном подходе. Особенности этапа конструирования программного средства при объектном подходе.
Окружающий нас мир состоит из объектов и отношений между
ними [15.1]. Согласно В. Далю [15.2] объект (предмет) - это все, что представляется чувствам (объект вещественный) или уму (объект умственный). Таким образом, объект воплощает некоторую сущность и имеет некоторое состояние, которое может изменяться со временем как следствие влияния других объектов, находящихся с первым в каких-либо отношениях. Он может иметь внутреннюю структуру: состоять из других объектов, также находящихся между собой в некоторых отношениях. Исходя из этого, можно построить иерархическое строение мира из объектов. Однако, при каждом конкретном рассмотрении окружающего нас мира некоторые объекты считаются неделимыми, причем в зависимости от целей рассмотрения такими (неделимыми) могут приниматься объекты разного уровня иерархии. Отношение связывает некоторые объекты: можно считать, что объединение этих объектов обладает некоторым свойством. Если отношение связывает n объектов, то такое отношение называется n-местным (n-арным). На каждом месте объединения объектов, которые могут быть связаны каким-либо конкретным отношением, могут находиться разные объекты, но вполне определенные (в этом случае говорят: объекты определенного класса). Одноместное отношение называется простым свойством объекта (соответствующего класса). Многоместное отношение объектов будем называть ассоциативным свойством объекта, если этот объект участвует в этом отношении. Состояние объекта может быть изучено по значению простых или ассоциативных свойств этого объекта. Множество всех объектов, которые обладают каким-то общим набором свойств, называется классом объектов.В процессе познания или изменения окружающего нас мира мы
всегда принимаем в рассмотрение ту или иную упрощенную модель мира (модельный мир), в которую включаем объекты и отношения некоторых интересующих нас классов из окружающего нас мира. Каждый объект, имеющий внутреннюю структуру, может представлять свой модельный мир, включающий объекты этой структуры и отношения, которые их связывают. Таким образом, окружающий нас мир, можно рассматривать (в некотором приближении) как иерархическую структуру модельных миров.В настоящее время в процессе познания или изменения окружающего нас мира широко используется компьютерная техника для обработки различного рода информации. В связи с этим применяется
компьютерное (информационное) представление объектов и отношений. Каждый объект информационно может быть представлен некоторой структурой данных, отображающей его состояние. Простые свойства этого объекта могут задаваться непосредственно в виде отдельных компонент этой структуры, либо специальными функциями над этой структурой данных. Ассоциативные свойства (n-местные отношения для n>1) можно представить либо в активной форме, либо в пассивной форме. В активной форме n-местное отношение представляется некоторым программным фрагментом, реализующим либо n-местную функцию (определяющую значение свойства соответствующего объединения объектов), либо процедуру, осуществляющую по состоянию представлений объектов, связываемых представляемым отношением, изменение состояний некоторых из них. В пассивной форме такое отношение может быть представлено некоторой структурой данных (в которую могут входить и представления объектов, связываемых этим отношением), интерпретируемую на основании принятых соглашений по общим процедурам, независящим от конкретных отношений (например, реляционная база данных). В любом случае представление отношения определяет некоторые действия по обработке данных.При исследовании модельного мира пользователи могут по-разному получать информацию от компьютера.
В одних случаях пользователей может интересовать получение информации об отдельных свойствах определенных объектов или результаты какого-либо взаимодействия между некоторыми объектами модельного мира. Для удовлетворения таких запросов разрабатываются соответствующие ПС, которые выполняют интересующие пользователей функции, или подходящие информационные системы, способные выдавать информацию об интересующих пользователей отношениях. В начальный период развития компьютерной техники (при не достаточно высокой мощности компьютеров) такой подход к исследованию модельного мира был вполне естественным. Именно он и провоцировал реляционный
(процедурный, функциональный и т.п.) подход к разработке ПС, который был подробно рассмотрен в предшествующих лекциях. Сущность этого подхода состоит в систематическом использовании декомпозиции функций (отношений) для описания и построения структуры ПС (включая тексты программ). При этом сами объекты модельного мира, с которыми связаны заказываемые и реализуемые функции, представлялись фрагментарно (в том объеме, который необходим для выполнения этих функций) и в форме, удобной для реализации этих функций. Тем самым обеспечивалась эффективная реализация требуемых функций, но не создавалось цельного и адекватного компьютерного представления модельного мира, интересующего пользователя. Попытки даже незначительного расширения объема и характера информации об этом модельном мире, которую можно получить от ПС, могло потребовать серьезной модернизации этого ПС.В других случаях пользователя может интересовать наблюдение за изменением состояний объектов модельного мира в результате их взаимодействий. Это требует использования подходящих информационных моделей таких объектов, создания программных средств, моделирующих процессы взаимодействия объектов модельного мира, и предоставление пользователю доступа к этим информационным моделям (к пользовательским объектам). С помощью традиционных методов разработки это оказалось довольно трудоемкой задачей. Наиболее полно отвечает решению этой задачи объектный подход к разработке ПС. Сущность его состоит в систематическом использовании декомпозиции объектов при описании и построении ПС. При этом функции (отношения), выполняемые таким ПС, будут выражаться через отношения объектов других уровней, т.е. их декомпозиция будет существенно зависеть от декомпозиции объектов.
С точки зрения разработчиков ПС следует различать следующие категории объектов (и, соответственно, их классов):
Кроме того, в зависимости от способа представления в компьютере модельного мира и характера взаимодействия с ним со стороны пользователя следует различать пассивные и активные объекты. Пассивный объект представляет собой некоторый фрагмент информационной среды, который способен хранить разные данные определенного типа (представляющие разные состояния этого объекта) и с которым связан некоторый набор операций (применимых к этому объекту). Операции над таким объектом применяются под воздействием некоторой внешней по отношению к этому объекту активной силы, исходящей либо от пользователя, либо от какого-либо программного фрагмента в процессе его выполнения. Активный объект представляет собой такое расширение пассивного объекта, в котором фрагмент информационной среды способен также хранить и программные фрагменты, способные находиться в процессе выполнения (в активном состоянии). Активный объект, у которого какие-либо программные фрагменты находятся в активном состоянии, способен воспринимать сообщения или сигналы из операционной среды, в которую он погружен, и самостоятельно выполнять некоторые операции как реакцию на эти сообщения или сигналы. Таким образом, можно считать, что активный объект обладает внутренней активной силой
.Когда говорят об объектно-ориентированном подходе к разработке ПС, имеют в виду объектный подход с ориентацией на описание объектов модельного мира и построением их информационных моделей, причем используются, в основном, активные объекты. При этом многие процессы разработки ПС приобретают специфические (“объектные”) черты:
Основные из этих специфических особенностей разработки ПС покажем в рамках водопадной модели технологии.
При объектном подходе этап внешнего описания ПС оказывается существенно более емким и содержательным по сравнению с реляционным подходом [15.3, 15.4, 15.5, 15.6].
Определение требований заключается в неформальном описании модельного мира, который пользователь собирается изучать или просто использовать с помощью требуемого ПС. При этом повышается роль прототипирования, которое при этом подходе часто окупается уменьшением объема работы на последующих этапах разработки ПС. Часто определение требование завершается разработкой диаграммы вариантов использования, в которой фиксируются, в каких случаях будет использоваться ПС. Это позволяет при разработке ПС ограничиться только такими ее функциональными возможностями, которые поддерживают эти случаи (варианты) использования. По существу, диаграмма вариантов использования представляет собой описание некоторого контекста использования (см. лекцию 4). На рис. 15.1. приведен пример диаграммы вариантов использования [15.6].
Существенно изменяется содержание процесса спецификации требований: вместо разработки функциональной спецификации ПС создается формальное описание модельного мира, состоящее из трех частей:
Назначение этих частей можно образно определить следующим образом [15.3]: объектная модель определяет то, с чем что-то случается; динамическая модель определяет, когда это случается; функциональная модель определяет то, что случается.
Рис. 15.1. Диаграмма вариантов использования для банкомата.
Объектная модель показывает статическую объектную структуру модельного мира, который должно представлять разрабатываемое ПС (программная система). Она включает определения используемых классов объектов и отношений между этими классами, а также определение используемых объектов этих классов и отношения между этими объектами.
Обычно класс объектов в объектной модели представляется в виде тройки
(Имя класса, Список атрибутов, Список операций).
Каждый атрибут представляется некоторым именем и может принимать значения определенного типа. По существу, атрибут класса выражает некоторое простое свойство объектов этого класса. Представление некоторых простых свойств объектов атрибутами весьма удобно, особенно когда по значениям этих атрибутов осуществляется классификация объектов. Операции, указываемые в представлении класса, отражают другие свойства объектов этого класса (как простые, так и ассоциативные). Они показывают, что можно делать с объектами этого класса (или что могут делать сами эти объекты).
В объектной модели отношение между объектами некоторых классов обобщаются в отношения между этими классами. При этом используются, как правило, только одноместные и двуместные отношения между объектами. Более сложные отношения приводит к неоправданному усложнению объектных моделей, а с другой стороны, такие отношения всегда могут быть сведены к двуместным за счет определения дополнительных классов. Одноместные отношения называют атрибутами, причем некоторые атрибуты объекта получаются из атрибутов класса присвоением им конкретных значений. Отношение между двумя (и более) объектами называют связями, а их обобщение (отношение между классами) обычно называют ассоциациями. Ассоциации определяют допустимые связи между объектами. Различают следующие виды ассоциаций:
Ассоциация “взаимодействие”, по существу, означает, что объекты классов, находящихся в таком отношении, могут быть параметрами некоторых операций. Ассоциация “агрегирование” означает, что объект одного из классов, находящихся в таком отношении, включает (или может включать) в себя (как часть) объекты другого из этих классов. Ассоциация “абстрагирование” означает, что один из классов, находящихся в таком отношении, наследует свойства другого из этих классов и может обладать также и другими (дополнительными) свойствами.
Рис. 15.2. Пример отношения между классами объектов.
Для представления объектной модели часто используются графические языки спецификации объектов (например, язык UML [15.5]). На таких языках классы и объекты задаются прямоугольниками, которых указывается специфицирующая их информация. Для задания отношений между двумя классами соответствующие им прямоугольники связываются линией, снабженной различными графическими значками и некоторыми надписями. Графические значки специфицируют характер (вид) отношения между этими классами, а надписи обеспечивают полную идентификацию этого отношения (делают его конкретным). Например, на рис. 15.2 заданное отношение между классами Страна и Город имеет характер “один к одному”. Более конкретно это отношение означает, что каждый объект класса Страна обязательно связан отношением “имеет столицей” с одним и только одним объектом класса Город, и этот объект класса Город не связан таким отношением ни с каким другим объектом класса Страна.
Для описания декомпозиции объектов используется отношение вида агрегирования. Например, отношение “программа состоит из одного или нескольких модулей” представлено на рис. 15.3.
Рис. 15.3. Пример отношения агрегирования между классами объектов.
Следует заметить, что объектная модель полностью включает описание внешней информационной среды при реляционном подходе.
Динамическая модель показывает допустимые последовательности изменений состояний объектов из объектной модели модельного мира, который должно представлять разрабатываемое ПС (программная система). Она описывает последовательности операций в ответ на внешние сигналы (взаимодействия) без рассмотрения того, что эти операции делают. Динамическая модель необходима, если в соответствующей объектной модели имеются активные объекты.
Основные понятия динамической модели: события и состояния объектов. Под событием здесь понимается элементарное воздействие одного объекта на другой, происходящее в определенный момент времени. Одно событие может логически предшествовать другому или быть не связанным с другим. Другими словами, события в динамической модели частично упорядочены. Под состоянием объекта здесь понимается совокупность значений атрибутов объекта и представления текущих связей этого объекта с другими объектами. Состояние объекта связывается с интервалом времени между некоторыми двумя событиями, на которые реагирует этот объект. Объект переходит из одного состояния в другое в результате реакции на некоторое событие (в конце интервала, связанного с этим состоянием).
Рис. 15.4. Диаграмма состояний телефонной линии.
В связи с этим в динамической модели для каждого класса активных объектов строится своя диаграмма состояний. Она представляет собой граф, вершинами которого являются состояния, а дугами – переходы между этими состояниями (переходы часто обозначаются именами событий). Некоторые переходы могут быть связаны с условиями, разрешающими эти переходы. Условие – это предикат, зависящий от значений некоторых атрибутов объекта. Каждое условие указывается на дуге, переходом по которой управляет это условие. Существенно, что в диаграмме состояний с некоторыми состояниями или событиями связываются определенные операции. Операция, связываемая с событием, обозначает реакцию объекта на это событие и считается, что она выполняется мгновенно (в точке некоторого временного интервала). Такая операция называется действием. Операция, связываемая с состоянием, выполняется в рамках временного интервала, с которым связано это состояние (т.е. имеет продолжительность, ограниченную этим интервалом). Такая операция называется деятельностью. Диаграмма состояний определяет управление активизацией указанных операций. Таким образом, диаграмма состояний описывает поведение одного класса объектов. Пример диаграммы состояний класса приведен на рис. 15.4.
Динамическая модель в целом объединяет все диаграммы состояний с помощью событий между классами.
Функциональная модель показывает, как вычисляются выходные значения из входных без указания порядка, в котором эти значения вычисляются. Она определяет все операции, условия и ограничения, используемые в объектной и динамической моделях (внешние операции). Функциональная модель соответствует определению внешних функций при реляционном подходе к разработке ПС.
Для определения крупных операций в функциональной модели используются потоковые диаграммы (диаграммы потоков данных), позволяющие выразить эти операции через более простые операции. Основными понятиями потоковых диаграмм являются процессы, объекты и потоки данных. Потоковая диаграмма – это граф, вершинами которого являются объекты или процессы, а дугами – потоки данных. Процессы преобразуют данные, поступающие от одних объектов и направляемые для хранения в другие объекты. Эти процессы представляют внутренние операции, через которые выражается операция, представляемая данной потоковой диаграммой. Объекты могут быть пассивными (хранилищами данных) и активными (агентами). Пассивные объекты используются только для хранения данных, а активные объекты используются как для хранения, так и для преобразования данных. Потоки данных определяют допустимые направления перемещения данных и типы перемещаемых данных.
Процессы могут выражаться терминальными операциями (определяемые непосредственно) или с помощью других потоковых диаграмм. Таким образом, потоковые диаграммы являются иерархическими.
Терминальные операции определяются так же, как и при реляционном подходе (см. лекции 4 и 5). Впрочем, и диаграммы потоков данных используются при реляционном подходе.
Таким образом, основным содержанием этапа внешнего описания при объектном подходе является объектное моделирование. При этом широко используются формальные языки спецификаций, в том числе и графические. Одним из наиболее употребительных в настоящее время таких языков является язык UML [15.5].
На этапе конструирования при объектном подходе продолжается процесс объектного моделирования: уточняются модели, построенные на этапе внешнего описания, в терминах описания программных систем и производится дальнейшая декомпозиция объектов [15.3, 15.4, 15.5].
В процессе разработки объектной архитектуры ПС выделяются все объекты, с информационными моделями которых собирается непосредственно работать пользователь, и завершается их программная спецификация, а так же определяется их пользовательский интерфейс. Такие объекты мы будем называть пользовательскими. Классы таких объектов или отдельные активные объекты образуют архитектурные подсистемы. Определяется метод взаимодействия между этими подсистемами.
Рис. 15.5. Архитектура “Клиент-Сервер”
В случае использования активных объектов основным широким классом архитектур при объектном подходе является коллектив параллельно действующих программ (см. лекцию 6), причем здесь роль программ выполняют как раз эти активные объекты, а способ управления передачей сообщений зависит от выбранного подкласса таких архитектур. Типичной архитектурой такого класса является архитектура “клиент-сервер” (см. рис. 15.5). В такой системе один из активных объектов, называемый сервером, выполняет определенные программные услуги по запросам других активных объектов, называемых клиентами. Такой запрос передается серверу с помощью сообщения от клиента, результат выполнения сервером запроса передаются соответствующему клиенту с помощью другого сообщения.
Дальнейшая разработка структуры программных подсистем и их кодирование на языках программирования может осуществляться уже в рамках реляционного подхода на ориентированных на него языках программирования [15.7] – пользователь внутреннюю организацию этих подсистем уже “не видит”. Однако, во многих случаях существуют сильные аргументы за то, чтобы продолжить объектную декомпозицию этих подсистем. Объектная структура этих подсистем может быть существенно более понятной разработчику, чем их структура при реляционном подходе. Кроме того, продолжение объектной декомпозиции и использование основных понятий и методов объектного подхода при дальнейшей разработке ПС представляется “естественным”, так как весь процесс разработки становится единообразным (концептуально целостным).
При разработки модульной структуры при объектном подходе используются преимущественно информационно прочные модули. Информационно прочный модуль, реализующий какой-либо класс объектов или логически связанную совокупность таких классов, обычно называют компонентом ПС.
На этапе кодирования при объектном подходе используются языки программирования уже другого типа – объектно-ориентированные [15.7, 15.8]. Считается, что язык программирования поддерживает объектно-ориентированное программирование, если он включает конструкции для [15.8]
Однако, самое существенное различие между реляционными и объектно-ориентированными языками программирования заключается в следующем: в качестве основных средств декомпозиции программ в реляционных языках используются описания функций и процедур (декомпозиция отношений), а в объектно-ориентированных языках – описание классов объектов (декомпозиция объектов). Объекты, возникающие в программах при такой декомпозиции архитектурных подсистем, мы будем называть объектами процесса выполнения программ
.Изменяется и технология разработки программного модуля. При реляционном подходе для разработки модуля (в основном, реализующих функцию или процедуру) рекомендовались структурное программирование и пошаговая детализация (см. лекцию 8). При объектно-ориентированном подходе для разработки компонента (информационно прочного модуля) более подходит предложенная Дейкстрой [15.9] нисходящая технологию разработки слоистой структуры модуля. В этой технологии каждый модуль рассматривается состоящим из некоторой упорядоченной совокупности программных слоев (ср. со слоистой программной системой в лекции 6), причем каждый слой является реализацией некоторой абстрактной машины (в нашем случае это можно рассматривать как реализацию класса или логически связанной совокупности классов). Таким образом, модуль образует определенная цепочка иерархически связанных абстрактных машин (так называемые “бусы” [15.9]) Реализация каждой абстрактной машины выражается в терминах ниже стоящей абстрактной машины (ниже стоящего программного слоя) или в терминах выбранного языка программирования (при реализации абстрактной машины самого нижнего уровня). Разработка модуля начинается с разработки абстрактной машины самого верхнего уровня.
15.1. В чем заключается сущность объектного подхода к разработке программных средств (ПС)?
15.2. Какие категории объектов можно выделить с точки зрения разработчиков ПС?
15.3. Что такое объектная модель ПС?
15.4. Что такое динамическая модель
ПС?15.5. Что такое диаграмма состояний класса?
15.6. Что такое функциональная модель
ПС?15.7. Что такое компонент
ПС?15.1. К. Фути, Н. Судзуки. Языки программирования и схемотехника СБИС. – М.: Мир, 1988. С. 85-98.
15.2. В. Даль. Толковый словарь русского языка. – М.: Советская энциклопедия, 1975
15.3. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenzen. Objekt-Oriented Modeling and Design. – Prentice Hall. 1991.
15.4. Г.Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. – М.: Конкорд, 1992.
15.5. М. Фаулер, К. Скотт. UML в кратком изложении. – М.: Мир, 1999.
15.6. Ф. Крачтен. Введение в RATIONAL UNIFIED PROCESS. – М.: Изд. Дом “Вильямс”, 2002.
15.7. В.Ш.Кауфман. Языки программирования. Концепции и принципы. – М.: Радио и связь, 1993.
15.8. М. Бен-Ари. Языки программирования. Практический сравнительный анализ. – М.: Мир, 2000.
15.9. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. – М.: Мир, 1975. – С. 7-97.
|
|
 |
