Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Структурированный естественный язык



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

Управляющие структуры языка должны иметь один вход и один выход. К ним относятся:

1) конструкция последовательности

DO функция1

DO функция2

DO функция3

2) конструкция выбора

IF < условие>

DO функция1

ELSE

DO функция2

END-IF

3) конструкция повторения

FOR < условие>

DO функция

END-FOR

или

WHILE < условие>

DO функция

END-WHILE

или

DO функция

WHILE < условие>

 

Следует придерживаться следующих соглашений:

1) логика процесса выражается в виде комбинации только этих трёх конструкций;

2) ключевые слова DO (выполнить), IF (если), FOR (для), WHILE (пока) и другие, должны быть написаны прописными буквами;

3) слова или фразы, определенные в словаре понятий предметной области, должны быть написаны прописными буквами;

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

5) логика процесса должна быть выражена чётко и недвусмысленно.

6) входные (in), выходные (out) и входные/выходные (inout) данные оформляются в виде набора параметров в заголовке спецификации процесса. Тело процесса ограничивается символами {и}, //- символ однострочного комментария.

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

8) имя процесса, как правило, является словосочетанием, где первое слово обозначает процесс действия, выраженное отглагольным существительным, другое слово – это имя существительное, зависимое от отглагольного существительного, обычно отображает основной выход (результат) процесса (например, «Оформление заказа»).

 

Приведем пример спецификации процесса 1.1 ПОЛУЧИТЬ ПАРОЛЬ, родительского процесса 1. ОПЛАТА СЧЕТА

ПОЛУЧИТЬ ПАРОЛЬ ( in Введенный пароль, in Пароль, out Сообщение, out Корректный пароль)

{ DO выдать Сообщение клиенту,

запрашивающее ввод Пароля

принять Введенный пароль

WHILE < Введенный пароль == Пароль

или были сделаны три попытки ввода >

DO установить флаг Корректный пароль

в случае равенства

} // конец спецификации процесса

 

Таблицы и деревья решений

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

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

Таблица решений состоит из двух частей. Верхняя часть таблицы используется для определения условий (событий). Обычно условие является IF – частью оператора условия IF-THEN и требует ответа «да -нет» («1-0»). Однако иногда в условии может присутствовать и ограниченное множество значений, например, ЯВЛЯЕТСЯ ЛИ ДЛИНА СТРОКИ БОЛЬШЕЙ, МЕНЬШЕЙ ИЛИ РАВНОЙ ГРАНИЧНОМУ ЗНАЧЕНИЮ?

Нижняя часть таблицы решений используется для определения действий (откликов), то есть THEN – части оператора IF-THEN.

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

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

1) если очередной символ является управляющим, то подать звуковой сигнал и вернуть код ошибки;

2) если буфер формируемой строки заполнен, то подать звуковой сигнал и вернуть код ошибки;

3) если очередной символ не находится в заданном диапазоне, то подать звуковой сигнал и вернуть код ошибки;

4) иначе поместить символ в буфер, увеличить значение счетчика выбранных символов и вернуть новое значение счетчика.

Таблица решений (табл.3.2) для заданного примера приведена ниже. Заметим, что если выполняется условие У1, то нет необходимости в проверке условий У2 и У3. поэтому комбинации условий 1, 2, 3, 4 могут быть заменены обобщающей комбинацией (1, -, -), где «-» означает любую из возможных альтернатив (в данном случае, 1 или 0). Аналогично, комбинации условий 5 и 6 могут быть заменены обобщающей комбинацией (0, 1, -). Редуцированная таким образом таблица решений приведена в табл.3.3.

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

IF (lit = = ctrl) {beep (1000); return (ERROR)}

ELSE {

IF (buffer > MAX) { beep (1000); return (ERROR)}

ELSE { IF (out_of_range(lit))

{ beep(1000); return (ERROR) }

ELSE { putchar (lit); return (++N) }

}

}

Таблица 3.2

Исходная таблица решений

  УСЛОВИЯ
у1 lit==ctrl
у2 buffer> MAX
у3 out_of_range(lit)
  ДЕЙСТВИЯ                
D1 beep (1000)  
D2 return (ERROR)  
D3 return (++ N)              
D4 putchar (lit)              

 

Таблица 3.3

Редуцированная таблица решений

  УСЛОВИЯ
у1 lit==ctrl
у2 buffer> MAX -
у3 out_of_range(lit) - -
  ДЕЙСТВИЯ        
D1 beep (1000)  
D2 return (ERROR)  
D3 return (++ N)      
D4 putchar (lit)      

 

Построение таблиц решений рекомендуется осуществлять по следующим шагам:

1) идентифицировать все условия (или переменные) в спецификации.

2) идентифицировать все значения, которые каждая переменная может иметь; Вычислить число комбинаций условий. Если все условия являются бинарными, то существует 2**N комбинаций N переменных;

3) идентифицировать каждое из возможных условий, которые могут вызываться в спецификации;

4) построить пустую таблицу, включающую все возможные условия и действия, а также номера комбинаций условий;

5) выписать и занести в таблицу все возможные комбинаций условий;

6) редуцировать комбинации условий;

7) проверить каждую комбинацию условий и идентифицировать соответствующие выполняемые действия;

8) выделить комбинации условий, для которых спецификация не указывает список выполняемых действий;

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

 

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

 

Рис. 3.26. Дерево решений

 

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

В заключении отметим особенности методов задания спецификаций процессов (СП).

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

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

 

Контрольные вопросы и задания

1. Что такое спецификация программного обеспечения?

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

3. На примере функционирования АТМ, промоделируйте различные типы влияний блоков на функциональной диаграмме ( связи по входу, управлению и т.п.).

4. Каково основное назначение DFD и какова связь диаграммы потоков данных с функциональными диаграммами?

5. Объясните этапы разработки модели предметной области и их действия с применением DFD?

6. Физическая и логическая модели системы в технике построения диаграммы DFD?

7. Что позволяет моделировать диаграмма переходов состояний?

8. Какие два способа применяются при построении STD?

9. Какова классификация абстрактных структур данных?

10. Какими свойствами должна обладать каждая сущность в сетевой модели данных?

11. Что такое ассоциированная сущность, и в каких случаях она используется в модели?

12. Объясните суть таких особых видов связей сетевой модели данных, как взаимно исключающие, рекурсивные и перемещаемые связи?

13. Перечислите основные методы задания спецификаций процессов.

14. Каковы шаги построения таблиц решений? Продемонстрируйте таблицу решений для функционирования АТМ.

15. Основные преимущества и недостатки методов задания спецификаций процессов?


ОСНОВЫ ОБЪЕКТНОЙ ТЕХНОЛОГИИ

Введение

Объектно-ориентированный подход (object-oriented approach) к разработке систем получил распространение в 1990-х годах прошлого столетия. Ассоциация производителей ПО Object Management Group (OMG) утвердила для этого подхода, в качестве стандартного средства моделирования, язык UML (Unified Modeling Language – унифицированный язык объектного моделирования).

По сравнению со структурным подходом [15], объектно-ориентированный в большей степени ориентирован на данные, – он развивается вокруг моделей классов. На этапе анализа, для классов не требуется определять операции – только атрибуты. Возрастающее значение использования в языке UML вариантов использования(Use Case) способствует незначительному смещению акцентов от данных к функциям.

Причинами популярности объектного подхода являются:

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

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

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

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

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

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

 

Объектная модель

Объектно-ориентированная технология основывается на так называемой объектной модели [3]. Основными принципами объектной модели являются: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе не нов, но в объектной модели они впервые применены в совокупности.

Объектная модель представляет собой набор правил, которые предписывают, каким образом объекты определяются и документируются. Все объекты, принадлежащие данной объектной модели, соответствуют строгим правилам, которые диктуют их: определение, создание, взаимодействия между объектами и уничтожение. Другими словами, объектная модель формально определяет, что представляет собой объект, как он располагается в памяти, когда создается, как взаимодействует с другими объектами и когда уничтожается. Большинство объектно-ориентированных языков программирования не составляют и не определяют настоящие объектные модели. Эти языки, включая С++, в основном поддерживают синтаксис и диктуют семантику при реализации объекта; они не определяют правила, унифицирующие системы объектов. А вот модель компонентного объекта (СОМ) является действительно настоящей моделью объектов, которая вносит некоторый порядок в хаотичную вселенную объектов.

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

Объектная модель – описывает обязанности, отношения и структуру различных объектов предметной области.

Объектная модель представляет системные сущности, их классификацию и агрегирование.

Объектные модели включают модели наследования, агрегирования и поведенческие модели.

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

Модель компонентного объекта (Component Object Model - COM) – это вклад компании Microsoft в мир объектных моделей. Она служит основой для технологии OLE (Object Linking and Embedding). COM представляет собой стандартную объектную модель промышленного уровня, которая унифицирует системы объектов. Эта модель специфицирует:

· правила, по которым объекты структурируются и особым образом располагаются в памяти – определение объекта;

· правила, по которым объекты создаются и уничтожаются – управление жизненным циклом;

· правила, по которым объекты взаимодействуют друг с другом и проявляют свои функции – протоколы взаимодействия между объектами.

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

СОМ – это объектная модель, на которой основана технология OLE. OLE – это широкий набор сервисов системного уровня, поддерживаемых объектами, которые подчиняются правилам СОМ.

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

СОМ - объекты представляют собой объекты, которые подчиняются спецификации СОМ в том, что касается базовой структуры, управления жизненным циклом и взаимодействие друг с другом. СОМ- объекты можно писать на любом языке программирования, который поддерживает «указатели – на - указатели», включая С, С++. Поэтому говорят, что СОМ обеспечивает двоичный стандартвзаимодействия! Это означает, что при разработке СОМ- объектов совершенно безразлично, какой язык использовать. Из этого следует, что СОМ - объекты, разработанные разными поставщиками и на разных языках, могут эффективно взаимодействовать друг с другом. Нет необходимости в замене двоичного или исполняемого кода.

СОМ поддерживает простую модель «клиент-сервер». Объекты, называемые серверами, предоставляют некие службы в распоряжение объектов, называемых клиентами. Серверы всегда являются СОМ - объектами, то есть объектами, которые подчиняются спецификации СОМ. С другой стороны, клиенты могут быть СОМ - объектами или не быть таковыми. СОМ-объект может быть одновременно клиентом и сервером; чем именно – определяется с точки зрения рассматриваемых объектов.

Клиенты и СОМ - серверы общаются друг с другом при помощи интерфейсов.

Интерфейсы – это группы функций, которыми СОМ - объекты обычно пользуются для взаимодействия друг с другом и своими клиентами.

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

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

У интерфейсов есть общие черты, которые делают их полезными. В СОМ - интерфейсах эти черты являются наследуемыми.

· Интерфейсы представляют набор функций как семантически связанную единицу. Панель банкомата, например, обеспечивает функции ввода информации и идентификации клиента.

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

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

· Интерфейсы остаются неизменными. Если интерфейс объявлен общедоступным, он таким и остается. Другими словами, интерфейсы не переделываются.

· Интерфейсы являются предсказуемыми. Заданный интерфейс всегда обеспечивает абсолютно одинаковый набор функций в любой момент времени. Например, нажатие кнопки «Ввод» на банкомате всегда подтверждает последнее действие. Это истинно для любого банкомата.

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

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

В заключении, отметим ряд преимуществ объектной модели от моделей, которые связаны с методами структурного анализа, проектирования и программирования [3].

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

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

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

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

Вычислительна платформа.NET развивает и расширяет идеи компонентного программирования, заложенные в основу архитектуры СОМ. В рамках платформы.NET выделяют три фундаментальные компонентные модели:

· Модель взаимодействия управляемых моделей, исполняющихся в среде CLR. Эта модель в наибольшей степени близка к СОМ, поскольку при ее реализации основной акцент делается на преодолении ряда проблем, присущих именно СОМ.

· Модель взаимодействия компонентов Web-приложений на основе архитектуры ASP.NET (Active Server Pages).

· Модель распределенного компонентного программирования, ориентированного на XML Web-сервисы. В рамках этой модели реализуется взаимодействие удаленных компонентов, исполняющихся на разных платформах, на базе протокола SOAP.

 

Объекты

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

Объект обладает состоянием, поведением и идентичностью; структура и поведение схожих объектов определяет общий для них класс; термины «экземпляр класса» и «объект» взаимозаменяемы.

Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств.

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

Идентичность – это такое свойство объекта, которое отличает его от всех других объектов.

Объект – это переменная абстрактного типа данных, которая состоит из приватных данных и из процедур, которые оперируют этими данными.

Объект – абстракция данных, имеющая интерфейс в виде именованных операций и собственные данные с ограничением доступа к ним.

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

Объект типа – содержит ссылку на класс, который реализует данный тип (интерфейс).

Объект-экземпляр

Объект – это экземпляр (instance) некоторой сущности. Он может быть одним из множества экземпляров одной и той же сущности. Общее описание «сущности» называется классом.

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

 

Рис. 4.1. Спецификация объекта

 

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

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

Рис. 4.2 иллюстрирует потоки сообщений между четырьмя объектами. Сообщение – это имя операции объекта – приемника, причем сообщение может принимать параметры. Объект Заказ предписывает объекту Поставка доставить заказ. Для этого объект Поставка инструктирует объект Склад о необходимости вычесть соответствующее количество товаров. Затем объект Склад анализирует новый уровень Запаса и, если он оказывается ниже определенного значения, предписывает объекту Покупка сделать повторный заказ дополнительного объема товаров. Так как целью кооперации объектов является демонстрация потоков сообщений между объектами, поэтому на порядок, в котором активируются объекты, не накладывается строгих ограничений, из чего следует, что нумерацию сообщений можно опустить.

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

 

 

Рис. 4.2. Кооперация объектов

 

В сценариях взаимодействия объектов выделяются объекты – клиенты и объекты – сервера, которые выполняют роли Актора, Агента и Сервера. Возможны пять видов операций объекта – клиента над объектом – сервер:

1) Модификатор – изменяет состояние объекта – сервера.

2) Итератор – осуществляет доступ к содержанию объекта – сервера по частям в строго определенном порядке. Операция позволяет взаимодействовать с частями объекта (через указатель).

3) Селектор – произвольный доступ к состоянию объекта – сервера без изменения его состояния.

4) Конструктор – создает объект и инициализирует его состояние.

5) Деструктор – разрушает объект и освобождает занимаемую им память.

Примеры следующих сообщений: УменьшитьКоличествоТовара() – это модификатор; ПоказатьУровеньЗапаса() –это селектор; ПоказатьАссортиментТоваров () – это итератор; СоздатьОбъект(параметры) – это конструктор; УничтожитьОбъект() – это деструктор.

 

Отношения между объектами

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

· Связи.

· Агрегация.

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

· Актор. Объект – Актор может воздействовать на другие объекты, но сам никогда не подвергается воздействию других объектов; в определенном смысле это соответствует понятию активный объект. Актор – это исполнитель ролей (Actor – это просто деятель, исполнитель).

· Сервер. Объект – сервер может подвергаться воздействию со стороны других объектов, но он никогда не выступает в роли воздействующего объекта.

· Агент. Такой объект - агент может выступать как в активной, так и в пассивной роли; как правило, объект–агент создается для выполнения операций в интересах какого-либо объекта - актора или агента.

В качестве примера покажем достаточно популярную организацию объектов, которая считается типовым проектным решением, а в Smalltalk аналогичный механизм известен как MVC, (Model/View/Controller - Модель/ Представление/ Контроллер). Более того, хорошо структурированные системы имеют много таких опознаваемых типовых решений.

На рис. 4.3 объект Controller выступает как актор, объект DisplayItem – как агент и объект View – как сервер. Агент, ответственен за то, каким образом отобразить информацию на дисплее, поэтому эта связь может проявляться хотя бы в том, что объект DisplayItem явно получает объект View в качестве параметра одной из своих операций (и, в качестве локального объекта одной из своих операций).

Надо отметить, что такой тип связи между объектами DisplayItem и View определяет отношение «зависимость» (использование) между классами DisplayItem и View.

 

 

 

Рис. 4.3. Связи

 


Поделиться:



Последнее изменение этой страницы: 2017-05-11; Просмотров: 617; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.095 с.)
Главная | Случайная страница | Обратная связь