Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






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






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

Диаграмма классов (class diagram) — диаграмма языка UML, на которой пред­ставлена совокупность декларативных или статических элементов модели, таких как классы с атрибутами и операциями, а также связывающие их отношения.

Диаграмма классов предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программиро­вания.

Диаграмма классов содержит интерфейсы, пакеты, отношения и даже отдельные экземпляры классификаторов, такие как объекты и связи.

Класс (class) — абстрактное описание множества однородных объектов, имею­щих одинаковые атрибуты, операции и отношения с объектами других классов.

Графически изображается в виде прямоугольника, который дополнительно мо­жет быть разделен горизонтальными линиями на разделы или секции (рис. 11). В этих секциях могут указываться имя класса, атрибуты и операции класса. Даже если секции атрибутов и операций пусты, в обозначении класса они должны быть выде­лены горизонтальной линией.


Рис. 11. Варианты графического изображения класса на диаграмме классов

В первом случае для класса Окружность (рис. 12, а) указаны только его атри­буты – точка на координатной плоскости, которая определяет расположение ее цен­тра. Для класса Окно (рис. 12, б) указаны только его операции, при этом секция его атрибутов оставлена пустой. Для класса Счет (рис. 12, в) дополнительно изображена четвертая секция, в которой указано требование – реализовать резервное копирова­ние объектов этого класса.

 


Рис. 12. Примеры графического изображения конкретных классов

 

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

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

Класс может иметь или не иметь экземпляров или объектов. В зависимости от этого в языке UML различают конкретные и абстрактные классы.

Конкретный класс (concrete class) — класс, на основе которого могут быть непо­средственно созданы экземпляры или объекты.

Рассмотренные выше обозначения относятся к конкретным классам.

Абстрактный класс (abstract class) — класс, который не имеет экземпляров или объектов.

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

Когда необходимо явно указать, к какому пакету относится тот или иной класс, используется специальный символ разделитель – двойное двоеточие - (::). Синтак­сис строки имени класса в этом случае будет следующий:

< Имя пакета>:: < Имя класса>

Например, если определен пакет с именем Банк, то класс Счет в этом банке мо­жет быть записан в виде: Банк:: Счет.

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

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

Общий формат записи отдельного атрибута класса следующий:

< квантор видимости> < имя атрибута> [кратность]: < тип ат­рибута> = < исходное значение> {строка-свойство}

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

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

- " +" – область видимости типа общедоступный (public). Атрибут с этой обла­стью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.

- " #" – область видимости типа защищенный (protected). Атрибут недоступен или невиден для всех классов, за исключением подклассов данного класса.

- " -" – область видимости типа закрытый (private). Атрибут недоступен или неви­ден для всех классов без исключения.

- " ~" – область видимости типа пакетный (package). Атрибут недоступен или не­виден для всех классов за пределами пакета, в котором определен класс-владелец данного атрибута.

Вместо условных графических обозначений можно записывать соответствую­щее ключевое слово: public, protected, private, package.

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

Кратность (multiplicity) — спецификация области значений допустимой мощ­ности, которой могут обладать соответствующие множества.

Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса:

[нижняя граница.. верхняя граница].

Интервалов кратности для отдельного атрибута может быть несколько. Если в качестве кратности указывается единственное число, то кратность атрибута прини­мается равной данному числу. Если же указывается " *", то кратность атрибута мо­жет быть произвольным положительным целым числом или нулем.

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

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

При задании атрибутов могут быть использованы дополнительные синтаксиче­ские конструкции — это подчеркивание строки атрибута, пояснительный текст в фигурных скобках и косая черта перед именем атрибута. Подчеркивание строки атрибута означает, что соответствующий атрибут общий для всех объектов данного класса, т.е. его значение у всех создаваемых объектов одинаковое (аналог ключевого слова static в некоторых языках программирования).

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

Отсутствие строки-свойства по умолчанию трактуется так, что значение соот­ветствующего атрибута может быть изменено в программе.

Знак " /" перед именем атрибута указывает на то, что данный атрибут является производным от некоторого другого атрибута этого же класса.

Производный атрибут (derived element) — атрибут класса, значение которого для отдельных объектов может быть вычислено посредством значений других атри­бутов этого же объекта.

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

Общий формат записи отдельной операции класса следующий:

< квантор видимости> < имя операции> (список параметров):

< выражение типа возвращаемого значения> {строка-свойство}

Квантор видимости операции аналогичен квантору видимости атрибутов.

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

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

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

Параметр (parameter) — спецификация переменной операции, которая может быть изменена, передана или возвращена.

Параметр может включать имя, тип, направление и значение по умолчанию. Направление параметра — есть одно из ключевых слов in, out или inout со значе­нием in по умолчанию, в случае если вид параметра не указывается. Имя параметра есть идентификатор соответствующего формального параметра, при записи кото­рого следуют правилам задания имен атрибутов.

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

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

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

Список формальных параметров и тип возвращаемого значения не обязателен.

В рамках профиля для процесса разработки ПО (The UML Profile for Software Development Processes) языка UML можно рассмотреть три специальных графиче­ских примитива, которые могут быть использованы для уточнения семантики от­дельных классов при построении различных диаграмм:

Управляющий класс (control class) — класс, отвечающий за координацию дей­ствий других классов. На каждой диаграмме классов должен быть хотя бы один управляющий класс, причем количество посылаемых объектам управляющего класса сообщений мало, по сравнению с числом рассылаемых ими.

Управляющий класс отвечает за координацию действий других классов. Как правило, данный класс является активным и инициирует рассылку множества сооб­щений другим классам модели. Кроме специального обозначения управляющий класс может быть изображен в форме прямоугольника класса со стереотипом < < control> > (рис. 13, а).

Класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Класс-сущность содержит информацию, которая должна храниться постоянно и не уни­чтожается с уничтожением объектов данного класса или прекращением работы мо­делируемой системы, связанные с выключением системы или завершением про­граммы.

Как правило, класс-сущность соответствует отдельной таблице базы данных. В этом случае его атрибуты являются полями таблицы, а операции – присоединен­ными или хранимыми процедурами. Этот класс пассивный и лишь принимает сооб­щения от других классов модели. Класс-сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом < < entity> > (рис. 13, б).

Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но явля­ется составной частью системы. Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом < < boundary> > (рис. 13, в).


Рис. 13. Графическое изображение классов для моделирования ПО

 

В рамках профиля для бизнес-моделирования (The UML Profile for Business Modeling) языка UML модно рассмотреть три специальных графических примитива, которые могут быть использованы для уточнения семантики отдельных классов при построении моделей бизнес-систем:

Сотрудник (business worker) — класс, служащий на диаграмме классов для представления любого сотрудника, который является элементом бизнес-системы и взаимодействует с другими сотрудниками при реализации бизнес-процесса. Этот класс также может быть изображен в форме прямоугольника класса со стереотипом < < worker> > или < < internalWorker> > (рис. 14, а).

Сотрудник для связи с окружением (caseworker) – класс, служащий для пред­ставления в бизнес-системе такого сотрудника, который, являясь элементом бизнес-системы, непосредственно взаимодействует с актерами (бизнес-актерами) при реа­лизации бизнес-процесса. Этот класс также может быть изображен в форме прямо­угольника класса со стереотипом < < caseWorker> > (рис. 14, б).

Бизнес-сущность (business entity) — специальный случай класса-сущности, ко­торый также не инициирует никаких сообщений. Этот класс служит для сохранения информации о результатах выполнения бизнес-процесса в моделируемой бизнес-системе или организации. Этот класс также может быть изображен в форме прямо­угольника класса со стереотипом < < business entity> > (рис. 14, в).

 


Рис. 14. Графическое изображение классов для моделирования бизнес-систем

 

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

- отношение ассоциации (association relationship);

- отношение обобщения (generalization relationship);

- отношение агрегации (aggregation relationship);

- отношение композиции (composition relationship).

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

Ассоциации применительно к диаграммам классов немного шире, чем примени­тельно к диаграммам вариантов использования. В качестве дополнительных специ­альных символов могут использоваться имя ассоциации, символ навигации, а также имена и кратность классов-ролей ассоциации.Имя ассоциации - необязательный элемент ее обозначения. Однако если оно за­дано, то записывается с заглавной буквы рядом с линией ассоциации. Отдельные классы ассоциации играют определенную роль в соответствующем отношении, на что явно указывает имя концевых точек ассоциации на диаграмме. Наиболее простой случай данного отношения - бинарная ассоциация, которая служит для представления произвольного отношения между двумя классами. Она связывает в точности два различных класса и может быть не­направленным (симмет­ричным) или направленным отношением. Частный случай бинарной ассоциации - рефлексивнаяассоциация, которая свя­зывает класс с самим собой. Ненаправленная бинарная ассоциация изображается линией без стрелки. Для нее на диаграмме может быть указан порядок чтения клас­сов с использованием значка в форме треугольника рядом с именем данной ассоци­ации.

В качестве простого примера ненаправленной бинарной ассоциации можно рас­смотреть отношение между двумя классами - классом «Компания» и классом «Со­трудник» (рис. 15). Они связаны между собой бинарной ассоциацией «Работает». Для данного отношения определен следующий порядок чтения следования классов - сотрудник работает в компании.

 

Рис. 15. Графическое изображение ненаправленной бинарной ассоциации между классами

 

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

В качестве простого примера направленной бинарной ассоциации можно рас­смотреть отношение между двумя классами - классом «Клиент» и классом «Счет» (рис. 16). Они связаны между собой бинарной ассоциацией с именем «Имеет», для которой определен порядок следования классов. Это означает, что конкретный объ­ект класса «Клиент» всегда должен указываться первым при рассмотрении взаимо­связи с объектом класса «Счет», например, < клиент, счет_1, счет_2, …, счет_n>.

 


Рис. 16. Графическое изображение направленной бинарной ассоциации между классами

 

Частный случай отношения ассоциации - так называемая исключающаяассоци­ация (Xor-association). Семантика данной ассоциации указывает на то, что из не­скольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один.

На диаграмме классов исключающая ассоциация изображается пунктирной ли­нией, соединяющей две и более ассоциации (рис. 6.7), рядом с которой записывается ограничение в форме строки текста в фигурных скобках: {xor}.

 


Рис. 17. Графическое изображение исключающей ассоциации между тремя клас­сами

 

Тернарная ассоциация связывает отношением три класса. Ассоциация более вы­сокой арности называется n -арной ассоциацией.

n-арная ассоциация - ассоциация между тремя и большим числом классов.

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

Графически n -арная ассоциация обозначается ромбом, от которого ведут линии к символам классов данной ассоциации. Имя n -арной ассоциации записывается рядом с ромбом соответствующей ассоциации. Однако порядок классов в n -арной ассоциации, в отличие от порядка множеств в отношении, на диаграмме не фикси­руется.

В качестве примера тернарной ассоциации можно рассмотреть отношение между тремя классами: «Сотрудник», «Компания» и «Проект». Данная ассоциация указывает на наличие отношения между этими тремя классами, которое может представлять информацию о проектах, реализуемых в компании, и о сотрудниках, участвующих в выполнении отдельных проектов (рис. 18).

 


Рис. 18. Графическое изображение тернарной ассоциации между тремя классами

Класс может быть присоединен к линии ассоциации пунктирной линией, т.е. обеспечивать поддержку свойств соответствующей n-арной ассоциации, а сама n-арная ассоциация имеет атри­буты, операции и/или ассоциации. Такой класс явля­ется ассоциативным классом.

Класс ассоциация (association class) - модельный элемент, который одновре­менно является ассоциацией и классом.

Отдельный класс в ассоциации может играть определенную роль в данной ассо­циации. Поэтому вводиться специальный элемент - концевая точка ассоциации, которая графически соответствует точке соединения ли­нии ассоциации с отдельным классом.

Конец ассоциации (association end) - концевая точка ассоциации, которая связы­вает ассоциацию с классификатором. Конец ассоциации - часть ассоциации, но не класса. Каждая ассоциация может иметь два или больше концов ассоциации.

Роль (role) - имеющее имя специфическое поведение некоторой сущности, рас­сматри­ваемой в определенном контексте. Роль может быть статической или дина­мической.

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

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

Так, для примера (рис. 18) кратность " 1 " для класса «Компания» означает, что каждый со­трудник может работать только в одной компании. Кратность " 1..* " для класса «Сотрудник» озна­чает, что в каждой компании могут работать несколько сотрудников, общее число которых зара­нее неизвестно и ничем не ограничено. Вместо кратности " 1..* " нельзя записать только символ " * ", поскольку последний означает кратность " 0..* ". Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Такая кратность прием­лема в ситуациях, когда в компании вообще не выполняется никаких проек­тов.

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

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

Отношение обобщения является отношением классификации между более общим элементом (родителем или предком) и более частным или специальным эле­ментом (дочерним или потомком).

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

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

Отношение обобщения обозначается сплошной линией с треугольной стрел­кой на одном из концов (рис. 19). Стрелка указывает на более общий класс (класс-пре­док или супер­класс), а ее начало - на более специальный класс (класс-потомок или подкласс).

 


Рис. 19. Графическое изображение отношения обобщения в языке UML

 

От одного класса-предка одновременно могут наследовать несколько классов-потомков. т.е. в класс-предок входит несколько линий со стрелками.

Пример: класс «Транспортное средство» (курсив обозначает абстрактный класс) может вы­ступать в качестве суперкласса для подклассов, соответствующих кон­кретным транспортным средствам, таким как: «Автомобиль», «Автобус», «Трактор» и другим (рис 20).

 

а) б)

Рис. 20. а) Пример графического изображения отношения обобщения для несколь­ких классов-по­томков; б) Альтернативный вариант графического изображения от­ношения обобщения классов для случая объединения отдельных линий

 

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

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

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

- {complete} - означает, что в данном отношении обобщения специфицированы все классы-по­томки, и других классов-потомков у данного класса-предка быть не может.

- {incomplete} - означает случай, противоположный первому. А именно, предпо­лагается, что на диаграмме указаны не все классы-потомки. В последующем возможно разработчик восполнит их перечень, не изменяя уже построенную диа­грамму.

- {disjoint} - означает, что классы-потомки не могут содержать объектов, одно­временно являю­щихся экземплярами двух или более классов.

- {overlapping} - случай, противоположный предыдущему. А именно, предполага­ется, что отдель­ные экземпляры классов-потомков могут принадлежать одновременно нескольким классам.

С учетом дополнительного использования стандартного ограничения диаграмма классов (рис. 20) может быть уточнена (рис. 21).

 

Рис. 21. Вариант уточненного графического изображения отношения обобще­ния классов с использованием строки-ограничения

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

Очевидно, что рассматриваемое в таком аспекте деление системы на составные части пред­ставляет собой иерархию, но принципиально отличную от той, которая порождается отношением обобщения. Отличие заключается в том, что части си­стемы никак не обязаны наследовать ее свой­ства и поведение, поскольку являются самостоятельными сущностями. Более того, части целого обладают собственными атрибутами и операциями, которые существенно отличаются от атрибу­тов и опера­ций целого. Графически отношение агрегации изображается сплошной линией, один из кон­цов которой представляет собой не закрашенный внутри ромб. Этот ромб указывает на тот класс, который представляет собой " целое" или класс-контейнер. Остальные классы являются его " частями" (рис. 22).

 

Рис. 22. Графическое изображение отношения агрегации в языке UML

 

В качестве примера отношения агрегации можно рассмотреть взаимосвязь типа " часть-це­лое", которая имеет место между классом «Системный блок» персональ­ного компьютера и его со­ставными частями: «Процессор», «Материнская плата», «Оперативная память», «Жесткий диск» и «Диско­вод гибких дисков».

 


Рис. 23. Диаграмма классов для иллюстрации отношения агрегации на примере системного блока ПК

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

Композит (composite) - класс, который связан отношением композиции с одним или большим числом классов. Графически отношение композиции изображается сплошной линией, один из концов кото­рой представляет собой закрашенный внутри ромб. Этот ромб указы­вает на тот класс, который представляет собой класс-компо­зит. Остальные классы являются его " частями" (рис. 24).

 


Рис. 24.

Для отношений композиции и агрегации могут использоваться дополнительные обозначе­ния, применяемые для отношения ассоциации. А именно, могут указы­ваться кратности отдельных классов, которые в общем случае не обязательны. При­менительно к описанному выше примеру класс Окно программы является классом-композитом, а взаимосвязи составляющих его частей мо­гут быть изображены сле­дующей диаграммой классов (рис. 25).

 

Рис. 25. Диаграмма классов для иллюстрации отношения композиции на примере класса-композита «Окно программы»

 

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

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

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

Пример: Программное средство представляет собой базу данных «Автоматиза­ция процесса со­ставления расписания в учебном заведении». Программное средство обеспечивает корректировку данных, а именно в БД «Группы» может изменяться пере­чень предметов в соответствие с курсом группы и отделением; в БД «Пред­меты» могут из­меняться номера аудиторий и фамилии пре­по­давателей; осуществ­ляет поиск по ФИО преподавателя, номеру аудитории, названию предмета и номеру группы. Программное средство составляет расписание работы для конкретного пре­подавателя на не­делю; для группы на неделю; для группы по конкретному пред­мету, а также отчет о загрузке аудиторий на каждый день.

Рис. 26. Пример диаграммы классов

 






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.