16. Отношения между классами: ассоциация и зависимость. Привести примеры таких отношений на диаграмме классов Вашей курсовой работы . (102)

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

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

Ассоциация

Агрегация

Композиция

Наследование

Зависимость

Реализация

Рис.4.15. Значки отношений между классами

17.Отношения между классами: конкретизация и зависимость. Привести примеры таких отношений на диаграмме классов Вашей курсовой работы. (103)

Отношение «(наследование) конкретизация»

Значок отношения «наследование», представляющего отношение “is-a”(«специализация/обобщение»), либо “has-a” («включение»), выглядит как значок ассоциации с полой стрелкой на конце, которая указывает от Подкласса к Суперклассу (от наследника к родителю). В соответствии с правилами выбранного языка реализации, Подкласс наследует структуру и поведение своего Суперкласса. Конфликты имен между Суперклассами разрешаются в соответствии с правилами выбранного языка. К наследованию метка кратности не приписывается.

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

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

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

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

Класс – это подтип, если он может замещать свой супертип в независимости от того, использует он наследование (“is-a”), либо нет (“has-a”). Создание Подкласса используется как синоним обычного наследования.

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

Отношение «зависимость»

Зависимость является отношением использования между клиентом (зависимый исходный элемент) и сервером (независимый целевой элемент).

Зависимость – это семантическое отношение между двумя сущностями, при котором изменение одной из них может отразиться на семантике другой.

В случае отношений между классами, зависимости появляются по разным причинам [4]:

• один класс посылает сообщение другому классу (вызывает операцию поставщика);

• один класс владеет другим классом, как частью своих данных (отношения целого и части тут ни причем, поскольку целевой объект не входит в исходный, как в ассоциации, а только используется);

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

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

На рис.4.16 [21] показаны базовые зависимости, которые можно обнаружить в многоуровневом приложении. Класс ОкноЛьгот – это пользовательский интерфейс, или класс представления, зависящий от класса Сотрудник. Класс Сотрудник – это объект предметной области, который представляет основное поведение системы, в данном случае – бизнес- правила. Это означает, что если класс Сотрудник изменяет свой интерфейс, то есть свое поведение, то, возможно, и класс ОкноЛьгот также должен измениться.

Рис.4.16. Пример базовой зависимости

Здесь важно то, что зависимость имеет только одно направление и идет от класса представления к классу предметной области. Таким образом, мы знаем, что имеем возможность свободно изменять класс ОкноЛьгот, не оказывая влияния на объект Сотрудник, или другие объекты предметной области. Здесь мы видим ценное правило анализа: «Строго разделять логику представления от логики предметной области, когда представление зависит от предметной области, но не наоборот».

Второй существенный момент этой диаграммы: здесь нет прямой зависимости классов ШлюзДанных от класса ОкноЛьгот. Если эти классы изменяются, то, возможно должен измениться и класс Сотрудник. Но если изменяется только реализация класса Сотрудник, а не его интерфейс, то на этом изменения и заканчиваются.

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

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

Рис.4.18 Пример реализации отношений: агрегация, наследование, ассоциация и зависимость

Отношение «ассоциация» (структурная зависимость) - семантическая связь между классами, предполагающая наличие дополнительного атрибута – ссылки на целевой класс, в составе своего объекта. В нашем примере, класс Самолет должен содержать атрибут – ссылку на объект класса Двигатель. Направление ассоциации делается из предположения о существовании в классе Самолет способа извещения (отправки сообщения) классу Двигатель, но не наоборот. Отношение «зависимость» (функциональная зависимость) показывает, что один класс использует другой. При генерации кода для таких классов к ним не добавляются новые атрибуты, как в случае ассоциации, но создаются специфические для использования языка программирования операторы, необходимые для поддержки отношения. Например, на языке C# в код войдут операторы using, а в С++ - include.

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

using System;

using System.Collections.Generic;

using System.Text;

namespace ConsoleApplication1

{

class Двигатель

{

public void Запуск(string str)

{

Console.WriteLine("{0} - запущен",str);

}

}

class Самолет

{

Двигатель левый, правый; // агрегация

public Самолет()

{

левый = new Двигатель();

правый = new Двигатель();

}

public bool РешениеДиспетчера(Диспетчер d) //зависимость через параметр

{

if (d.Разрешение_на_Взлет())

return true;

else

return false;

}

public void ЗапуститьДвигатели()

{

левый.Запуск("Левый двигатель");

правый.Запуск("Правый двигатель");

Console.WriteLine("Ура !!! Полетели ");

}

} // класс Самолет

class Боинг : Самолет //конкретизация

{

public Боинг(): base() {}

public bool Готовность_к_Полету()

{

Console.WriteLine("Самолет исправен?");

bool ans = Convert.ToBoolean(Console.ReadLine());

return ans;

}

}

class Диспетчер

{

public Диспетчер() {}

public bool Разрешение_на_Взлет()

{

Метеослужба meteo = new Метеослужба();

//зависимость через локальный объект

if (meteo.РешениеМетеослужбы())

{ Console.WriteLine("Вылет разрешаю!"); return true;}

else

{

Console.WriteLine("Вылет не разрешаю! Ждем погоды ");

return false;

}

}

}

class Метеослужба

{

Погода wether; // ассоциация

public Метеослужба()

{ wether = new Погода(); }

public bool РешениеМетеослужбы()

{

if (wether.Прогноз())

return true;

else return false;

}

}

class Погода

{

public Погода() {}

public bool Прогноз()

{ Console.WriteLine("Состояние погоды?");

bool b = Convert.ToBoolean(Console.ReadLine());

return b;

}

}

class Test

{

static void Main()

{

Боинг boing = new Боинг();

Диспетчер disp = new Диспетчер();

if (boing.Готовность_к_Полету())

{

if (boing.РешениеДиспетчера(disp))

boing.ЗапуститьДвигатели()

}

else

Console.WriteLine("Рейс откладывается по техническим причинам");

Console.ReadKey();

}

}

}

Результат работы программы:

Самолет исправен ?

Нет, неисправен → Рейс откладывается по техническим причинам

Исправен → Состояние погоды ?

Непогода → Вылет не разрешаю! Ждем погоды

Нормально → Вылет разрешаю !

Левый двигатель – запущен

Правый двигатель – запущен

Ура !!! Полетели