Виды связей между элементами объектной модели

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФГБОУ ВПО

«ФИНАНСОВЫЙ УНИВЕРСИТЕТ ПРИ ПРАВИТЕЛЬСТВЕ РОССИЙСКОЙ ФЕДЕРАЦИИ»

Кафедра аналитических информационных систем

КОНТРОЛЬНАЯ РАБОТА

По дисциплине

«Объектно-ориентировочный анализ и программирование»

Вариант 3

Преподаватель: Никифоров Д.К.

Студент 2 курса, день.

Алкин В.А.

Бизнес-информатика

11УЛБ00568

Калуга 2013г.



План работы

Теоретический вопрос

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

Задача

Список используемой литературы



Теоретический вопрос

Виды связей между элементами объектной модели

Одна из основных проблем при создании больших и сложных систем, в том числе ПО, - это проблема сложности. Виды сложности: техническая сложность и сложность управления. Техническая сложность может быть вызвана:

· структурной сложностью (большим количеством элементов и сложными взаимосвязями между ними);

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

· необходимостью интеграции существующих и вновь разрабатываемых приложений;

· функционированием в неоднородной среде на нескольких аппаратных платформах;

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

Сложность управления порождается следующими причинами:

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

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

· разобщенность и разнородность отдельных групп разработчиков по уровню квалификации и традициям использования инструментальных средств;

· значительная временная протяженность проекта.

Подход к решению этой проблемы основан на принципе «разделяй и властвуй» (divide et impera). Сложная программная система должна быть разделена на небольшие подсистемы, каждую из которых можно разрабатывать независимо (в какой-то степени) от других. Декомпозиция является главным способом преодоления сложности разработки ПО. Принципы декомпозиции:

· количество связей между подсистемами должно быть минимальным («низкая связанность» или «слабое зацепление» - Low Coupling);

· степень взаимодействия внутри каждой подсистемы должна быть максимальной («сильная связность» или «высокая прочность» - High Cohesion).

При разбиении системы на подсистемы необходимо добиться выполнения следующих условий:

· каждая подсистема должна инкапсулировать свое содержимое (скрывать его от других подсистем);

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

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

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

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

· совокупность структурных элементов системы и связей между ними;

· поведение элементов системы в процессе их взаимодействия;

· иерархия подсистем, объединяющих структурные элементы;

· архитектурный стиль (типовой способ организации системы).

Архитектура ПО многомерна, поскольку различные специалисты работают с её различными аспектами. Различные представления архитектуры служат различным целям (модель «4+1»):

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

· логическое представление (отображающее логическую структуру ПО, элементами которой являются пакеты, подсистемы, классы и связи между ними);

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

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

Среди 5-ти представлений особое место занимает представление вариантов использования, поскольку оно используется при управлении разработкой, служит своего рода скелетом проекта. В общем случае говорят о модели «N+1», имея в виду что перечень архитектурных представлений может варьироваться, но представление вариантов использования входит в него обязательно как сердцевина или ядро.

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

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

Гради Буч:

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

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

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

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

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

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

2. Модели образуют внешнее представление системы и объясняют, что эта система будет делать, тем самым облегчают общение с заказчиком.

3. Модели облегчают изучение методов проектирования, в частности объектно-ориентированных методов.

Современный взгляд на роль моделей в разработке ПО отражают рекомендации Скотта Амблера, опубликованные под названием Agile Modeling [4] («гибкое моделирование» - www.agilemodeling.com). Им введено понятие «гибкая модель», описывающее неизбыточную полезную для проекта модель. В ходе жизненного цикла ПО Амблер советует создавать разумное количество гибких моделей.

Модель может быть признана гибкой, если она обладает следующими характеристиками:

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

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

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

· Модель достаточно непротиворечива. Некоторые части модели могут быть несогласованны, если это не мешает общему пониманию и использованию модели.

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

· Модель неубыточна. Ресурсы, потраченные на моделирование, не должны быть чрезмерны. Эти расходы должны быть обоснованы.

· Модель проста настолько, насколько это возможно. При выборе между простым решением и сложным следует предпочесть простое, так как либо оно сработает, либо образуется запас времени для переключения на второе (сложное) решение.

Ценности гибкого моделирования:

· общение: модели создаются для общения, с их помощью происходит обмен идеями;

· простота: доминирует KISS (keep it simple, stupid - сделай это просто), отвергается принцип KICK (keep it complex, kamikaze), актуален принцип YAGNI (you ain't gonna need it) для сдерживания желания всюду подстелить соломки;

· обратная связь: моделирование ведётся в группе; в обсуждение модели вовлекается её целевая аудитория, модели проверяются на практике с помощью создания прототипов;

· смелость: отказаться от подпорок в виде руководств по технологии создания ПО могут только смелые люди;

· смирение: принятие факта, что всегда найдётся кто-то более компетентный в каком-то вопросе, и чтогордыня создаёт препоны для сотрудничества.

Принципы гибкого моделирования:

· Модель для разумной цели. Если модель уже решает поставленную задачу, дальнейшее моделировании излишне.

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

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

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

· Быстрая обратная связь. См. третья ценность.

· Добивайтесь простоты. См. вторая ценность. Чтобы следовать этому принципу количество принципов Амблер сократил во второй версии своих рекомендаций примерно в полтора раза.

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

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

· Качественная работа. Без комментариев.

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

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

В процессе создания ПО используются следующие виды моделей:

· модели деятельности организации (или модели бизнес-процессов):

o модели "AS-IS" ("как есть"), отражающие существующее положение;

o модели "AS-TO-BE" ("как должно быть"), отражающие представление о новых процессах и технологиях работы организации;

· модели проектируемого ПО, которые строятся на основе модели "AS-TO-BE", уточняются и детализируются до необходимого уровня.

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

Для облегчения труда разработчиков и автоматизированного выполнения некоторых рутинных действий используются CASE-средства (Computer Aided Software Engineering). В настоящее время CASE-средства обеспечивают поддержку большинства процессов жизненного цикла ПО, что позволяет говорить о CASE-технологиях разработки ПО. CASE-технология - это совокупность методов проектирования ПО и инструментальных средств для моделирования предметной области, анализа моделей на всех стадиях ЖЦ ПО и разработки ПО.

Рассмотрев роль моделей в обеспечении жизненного цикла ПО мы переходим к обсуждению объектной модели являющейся концептуальной базой объектно-ориентированного подхода (ООП). Она представляет собой сборник идей (понятий, принципов), используемых всеми, кто применяет ОО-подход. Изложение даётся в версии Гради Буча [1].

Проблемы, стимулировавшие развитие ООП:

· Необходимость повышения производительности разработки за счет многократного (повторного) использования ПО.

· Необходимость упрощения сопровождения и модификации разработанных систем (локализация вносимых изменений).

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

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

Краткая история ООП:

· 1967: язык Simula - 1ый среди объектно-ориентированных;

· 1970-е: Smalltalk - получил довольно широкое распространение;

· 1980-е: Теоретические основы, C++, Objective-C;

· 1990-е: Методы OOA и OOD (Booch, OMT, ....), появился язык Java;

· 1997: Принят стандарт OMG UML 1.1.

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

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

· абстрагирование;

· инкапсуляция;

· модульность;

· иерархия.

Дополнительные принципы:

· типизация;

· параллелизм;

· устойчивость (persistence).

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

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

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

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

Тип - точная характеристика некоторой совокупности однородных объектов, включающая структуру и поведение.

Типизация - способ защититься от использования объектов одного класса вместо другого, или, по крайней мере, управлять таким использованием.

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

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

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

Переходим к основным понятиям объектно-ориентированного подхода (элементам объектной модели). К ним относятся: объект; класс; атрибут; операция; полиморфизм; наследование; компонент; пакет; подсистема; связь.

Объект - осязаемая сущность (tangible entity) - предмет или явление (процесс), имеющие четко выраженные границы, индивидуальность и поведение Любой объект обладает состоянием, поведением и индивидуальностью. Состояние объекта определяется значениями его свойств (атрибутов) и связями с другими объектами, оно может меняться со временем. Поведение определяет действия объекта и его реакцию на запросы от других объектов. Поведение представляется с помощью набора сообщений, воспринимаемых объектом (операций, которые может выполнять объект). Поведение может зависеть от текущего состояния. В разных состояниях реакция на одни и те же события у объекта может различаться. Индивидуальность - это свойства объекта, отличающие его от всех других объектов.

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

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

Атрибут - поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Атрибуты могут быть скрыты от других классов, это определяет видимость атрибута: рublic (общий, открытый); private (закрытый, секретный); protected (защищенный); package (видимый внутри пакета). Мощность (кратность) атрибута показывает, сколько значений хранится в одном экземпляре атрибута. Если кратность больше 1, то атрибут описывает массив, список... Мощность указывается в профиле атрибута, примеры: name: string [1]; phones: string [*]. Описаны атрибуты: имя - строка; телефоны - список строк. По умолчанию кратность - 1.

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

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

Результат операции зависит от текущего состояния объекта. Виды операций:

· Операции реализации (implementor operations) - реализуют требуемую функциональность.

· Операции управления (manager operations) управляют созданием и уничтожением объектов (конструкторы и деструкторы).

· Операции доступа (access operations) - так называемые, get-теры, set-теры - дают доступ к закрытым атрибутам.

· Вспомогательные операции (helper operations) - непубличные операции, служат для реализации операций других видов.

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

Сравнение архитектур традиционной и ОО-системы:

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

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

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

Компонент представляет собой физическую реализацию проектной абстракции и может быть: компонентом исходного кода (cpp-шник); компонентом времени выполнения (dll, ActiveX и т. п.); исполняемым компонентом (exe-шником). Компонент обеспечивает физическую реализацию набора интерфейсов. Компонентная разработка (component-based development) представляет собой создание программных систем, состоящих из компонентов (не путать с объектно-ориентированным программированием, которое представляет собой способ создания программных компонентов, базирующихся на объектах).

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

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

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

· единицей управления конфигурацией.

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

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

· Соединение (link) - физическая или концептуальная связь между объектами, позволяющая им взаимодействовать.

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

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

А грегация - более сильный тип ассоциативной связи между целым и его частями (пример: автомобиль и мотор). Композиция - усиленная агрегация, когда часть не может существовать без целого (пример: университет, факультет, кафедра). Композиция и агрегация транзитивны, в том смысле, что если B является частью A, и C является частью B, то C также является частью A (но на диаграмме связи, возникающие за счет транзитивности, явно не изображаются).

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

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

Атрибут класса также может быть отображен на диаграмме составной структуры как внутренняя часть класса.

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

Мощность Значение

1 Ровно один

0..* или * Ноль или больше

1..* Один или больше

0..1 Ноль или один

2..4 Заданный диапазон

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

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

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

В UML 2.0 к объектной модели добавлено понятие N-арной ассоциации:

На рисунке представлена тернарная ассоциация, связывающая проекты, программистов, занятых в проектах, и языки, на которых они программируют в том или ином проекте. Некоторым аналогом тернарной ассоциации является реляционное отношение над тремя доменами (таблица со столбцамипроект, программист, язык). Также как в реляционном отношении не дублируются одинаковые кортежи, при N-арных ассоциациях не дублируются N-ки соединённых объектов (на каждую произвольную N-ку допускается неболее одного соединения). Экземплярами N-арных ассоциаций являются N-арные соединения.

Так, из рисунка следует, что программистка Мэри в одном проекте пишет на Коболе, а в другом на Си.

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

Соответственно экземплярами n-арной ассоциации являются соединённые n-ки, не (n-1)-ки и т. п.

В примере «проекты-программисты-языки» мощности на концах тернарной ассоциации разрешают Мэри писать в одном и том же проекте на разных языках (хотя на диаграмме объектов такое не показано). То, что * обозначает 0..* и, следовательно, минимальная мощность каждого полюса нулевая, не означает, что какой-либо программист может быть задействован в проекте без указания языка или допускаются пары программист-язык (без проекта), проект-язык (без программиста). Единственное ограничение, наложенное в данном случае, - два разных тернарных соединения не могут связывать одну и ту же тройку объектов - например: Мэри, проект accountingSystem и Кобол.

Мощность на полюсе тернарной ассоциации обозначает количество троек, которое допускается в ситуации, когда зафиксирована какая-либо пара объектов на других концах. Например, * на полюсе у класса Person означает, что если мы фиксируем произвольный проект (например, CAD program) и произвольный язык (например, Java) допускается любое количество троек, где проект = CAD program и языка = Java. Другими словами, программистов на Java, задействованных в проекте CAD program, может быть любое количество.

Рассмотрим, что означает минимальная мощность при полюсе тернарной связи. Пусть полюс, мощность при котором мы рассматриваем, как и прежде, находится при классе Person. Если минимальная мощность равна 0 (как в случае 0..*), значит, для произвольной пары проект-язык может не быть троек. Т. е. программиста пишущего в некотором проекте на некотором языке, может не быть. Если минимальная мощность равна 1, это значит, что для любой пары должно существовать как минимум одно соединение-тройка. Пусть у нас два проекта (accountingSystem и CAD program) и три языка (Cobol, C, Java). Декартово перемножаем множество проектов на множество языков. Получаем 6 возможных разных пар. Минимальная мощность 1 у полюса Person предписывает, что для каждой из 6 двоек существует как минимум один программист, с которым двойка образует тернарное соединение. Как видим, ограничение довольно сильное, поэтому обычно минимальные мощности при полюсах n-арных связей равны нулю.

1) Верхний полюс. Для любой пары персона-язык допускается не более одного соединения-тройки. Т. е. программист может использовать какой-либо язык неболее чем в одном проекте.

2) Нижний полюс. Для любой пары персона-проект допускается не более одного соединения-тройки. Т. е. в любом проекте программист может быть задействован для программирования неболее чем на одном языке.

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

Проиллюстрировать, как все три ограничения выполняются вместе можно такой таблицей:

Project	Language	Person
Accounting System	Cobol	Mary
Accounting System	C	John
CAD Program	Cobol	Paul
CAD Program	C	Mary

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

- нарушаются ограничения 2) и 3).

- нарушается уникальность соединения-тройки, дубль второй строки таблицы не допустим.

- нарушаются ограничения 1) и 3).

Для тетрарных (n=4) и n-арных связей (при n>4) смысл мощностей полюсов описывается аналогично.

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

В объектно-ориентированных языках N-арные ассоциации не поддерживаются

программный обеспечение моделирование графический



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

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

Полюса ассоциаций с мощностью «много» имеют еще две характеристики: упорядоченность связываемых объектов и повторяемость (т. е. образуют ли связываемые объекты множество или мультимножество). Различные сочетания этих характеристик образуют четыре типа полюсов: множества {set} (тип полюса по умолчанию), упорядоченные множества {ordered}, мультимножества {bag} и последовательности {sequence}:

Спички в коробке образуют множество (неупорядоченное). Окна на экране - упорядоченное (по глубине) множество. В мультиграфе между парой вершин может быть несколько ребер, значит, каждая вершина может быть связана с мультимножеством вершин. Вершины ломаной, если допускаются наложения, образуют последовательность, в которой одна и та же вершина может встречаться несколько раз. Заметим, что по умолчанию полюс имеет тип {set}, поэтому в примере множество ломаных, с которыми связана точка, является обычным множеством в отличие от множества точек, принадлежащих одной ломаной.

Типы {set}, {ordered}, {bag}, {sequence} могут быть указаны и у полюсов n-арных ассоциаций. По умолчанию полюс n-арной ассоциации имеет тип {set}, и это соответствует приведённому выше рассмотрению n-арных ассоциаций. Рассмотрим, что будет означать {bag} у полюса n-арной ассоциаций. Проделаем мысленно следующие операции. Зафиксируем по одному произвольному объекту на всех остальных полюсах. Получаем (n-1)-ку . Из всех n-ок - экземпляров ассоциации выберем те, в которых участвуют все выбранные нами объекты. Это будут n-ки вида , где вместо * будут стоять объекты класса, к которому ведёт рассматриваемый нами полюс. Из таких n-ок соберём коллекцию всех объектов, встречающихся на месте *: objn1, objn2, … . Свойства этой коллекции и описывает тип полюса. {Bag} означает, что в коллекции допускаются дубли и нет порядка. {Sequence} - есть и порядок и дубли, {ordered} - нет дублирования, но есть порядок.

Ассоциациям могут быть приписаны квалификаторы. Квалификатор - атрибут или набор атрибутов ассоциации, значение которых позволяет выбрать для конкретного объекта квалифицированного класса множество целевых объектов на противоположном конце соединения. Например, если в папке может находиться не более одного файла с заданным именем, то имя файла - квалификатор ассоциации папка -> файл. Обратите внимание, что в примере с папкой и фалом из-за наличия квалификатора мощность на нижнем полюсе ассоциации равна 0..1, так как,фиксируя на противоположном конце связи один объект папку и одно имя файла, можно получить не более одного связанного файла. Без квалификатора она была бы 0..*. Квалификатор не обязательно состоит из одного атрибута (также как и потенциальный ключ записей в таблице). Например, жильцы из домовой книги проиндексированы адресами, состоящими из названия улицы, номера дома и номера квартиры.

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

Зависимость между классами возникает в следующих случаях:

· в сигнатуре операции одного класса есть аргумент - объект другого класса;

· в методе одного класса есть локальный объект другого класса;

· результатом операции одного класса является экземпляр другого класса.

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

Зависимость между пакетами возникает при импорте описаний элементов одного пакета в другой.

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

Общие атрибуты, операции и/или отношения отображаются на верхнем уровне иерархии. Заметим, что ассоциации класса-предка наследуются классами потомками, т. е. экземпляры потомков могут иметь соединения того же рода, что и экземпляры родительского класса. Действует принцип подстановки Лисковой (Liskov substitution principle - LSP), по которому любое утверждение, справедливое для экземпляров класса, сохраняет справедливость для экземпляров всех его подклассов. Например, из LSP следует, что экземпляр подкласса подкласса (класса «внука») может рассматриваться как экземпляр подкласса или экземпляр исходного класса (своего «деда»).

В объектной модели наследование может быть множественным. На связи наследования могут накладываться ограничения. Например, если необходимо, множественное наследование внутри некоторой иерархии классов может быть запрещено (над связью указывается ключевое слово: {disjoint}). Можно ограничить набор классов-наследников на некотором уровне иерархии наследования указав ограничение {complete}.

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



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



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

Во время моделирования за описание сущностей отвечает:

б) исполнитель

Задача

Магазин компьютеров предлагает возможность приобретения своих товаров через Интернет. Клиент может выбрать компьютер на web-странице магазина. Компьютеры подразделяются на серверы, настольные, портативные и карманные.

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

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

Пока клиент ожидает прибытия компьютера, он может проверить состояние заказа (поставлен в очередь/собран/отправлен). Работник магазина проверяет, поступила ли оплата (в случае безналичных расчетов) и делает соответствующую пометку при поступлении денег.

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

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

Разработайте модель сайта интернет-магазина, создайте схему базы данных интернет-магазина.

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



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

Создадим диаграмму вариантов использования



Список используемой литературы

1. Буч Г. Объектно - ориентиранное проектирование с примерами применения. - М.:Конкорд, 1992

2. Иванова Г.С.- Основы программирования: учебник для вузов. - М.: Издательство МГТУ им. Н.Э. Баумана, 2001

3. Иванова Г.С., Ничушкина Т.Н., Пугачев Е.К. Объктно- ориентированное программирование: учебник для вузов/ под ред. Г.С.Ивановой. - М.: Издательство МГТУ им Н.Э.Баумана, 2001.

4. Кормен Т., Лейзерсон Ч., Ривест Р. Алгоритмы: построение и анализ. - М.: МЦНМО, 2004.

Размещено на Allbest.ru