Что такое класс объектной модели, атрибуты и операции класса и их форматы спецификаций на примере Вашей курсовой работы. (92)

Полный формат атрибута:

видимость имя: тип [кратность] = значение по умолчанию {характеристика}

Например:

- имя атрибута: string [1] = «Без имени» { readOnly}

Обязательно только имя.

· Метка видимость обозначает, относится ли атрибут к открытому (+) (public), или закрытому (-) (private), защищенному (#) (protected) или к пакетному (~) (package, internal) типам видимости.

· имя атрибута – способ ссылки класса на атрибут – приблизительно соответствует имени поля в языке программирования.

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

· кратность определим при рассмотрении ассоциации.

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

· Элемент { характеристика} позволяет указывать дополнительные свойства атрибута. В нашем примере он равен { readOnly}, то есть клиенты не могут изменять значение атрибута. Если этот элемент пропущен, то, как правило, атрибут можно модифицировать.

Отметим ряд других характеристик:

· changeable – нет ограничений на модификацию значения атрибута;

· addOnly – для атрибутов с множественностью большей единицы; дополнительные значения могут быть добавлены, но после создания значение не может удаляться или изменяться;

· frozen – после инициализации объекта значение атрибута не изменяется;

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

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

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

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

видимость Имя (список параметров): возвращаемый тип {характеристика}

· Метка видимости обозначает, относится ли операция к открытым (+) (public) или закрытым (-) (private), либо к пакетному (~) (package), либо к защищенному (#) (protected) уровням видимости.

· Список параметров – список параметров операции.

· Возвращаемый тип – тип возвращаемого значения, если таковое есть.

· Характеристика – значение свойства, которое применяется к данной операции.

Параметры операции имеют вид:

направление имя: тип = значение по умолчанию

· имя, тип и значение по умолчанию те же самые, что и для атрибутов.

· направление обозначает, является ли параметр входным (in), выходным (out) или тем и другим (inout). Если направление не указано, то предполагается in. Например, в классе Счет операция может выглядеть так:

+balanceOn (data: Date): Money

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();

}

}

}

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

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

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

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

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

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

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

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

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

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

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

На основе рассмотренных отношений между классами, приведем пример (рис. 4.19) полной иерархии классов проекта «Гирлянда из цветных лампочек» (Garland Application) [18].

На рис. 4.19 представлен вариант определения класса ColorableObject на основе интерфейса IColorable. Проиллюстрируем на этом примере основную идею, лежащую в основе концепции интерфейса. Цветом могут характеризоваться не только лампочки, но и самые разнообразные объекты.

В рамках программной модели было бы неплохо иметь какой-нибудь вполне унифицированный механизм работы с такими объектами. Интерфейс IColorable, «в кооперации» с типом – перечислением ColorEnum, предоставляет простейшую модель такого механизма. Тип ColorEnum содержит элементы перечисления, которые мы будем использовать для идентификации цвета. Интерфейс IColorable использует этот тип для определения сигнатур двух методов SetColor() и GetColor(), которые должен поддерживать любой объект, характеризуемый цветом.

В такой интерпретации класс ColoredLight может трактоваться как разновидность ColorableObject.

Можно реализовать и другие разновидности ColorableObject.

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

Рис.4.19. Диаграмма классов GarlandApplication

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

void SetWhite (IColorable * arg)

{ arg -> SetColor (WHITE); }

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

В заключение отметим, что большинство современных языков программирования поддерживают интерфейсы в виде встроенных средств языка (включая Java, C#, Visual C++.Net with Managed Extentions). Язык С++ напрямую не поддерживает интерфейсы, однако эквивалентная

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

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

Диаграмма классов интернет-системы бронирования авиабилетов