Различия между композицией и агрегацией




Отношения между классом Вуз и классами Студент и Факультет слегка отличаются друг от друга, хотя оба являются отношениями агрегирования. В ВУЗе может быть любое количество студентов (включая ноль), и каждый студент может обучаться в одном или нескольких вузах; вуз может состоять из одного или нескольких факультетов, но каждый факультет принадлежит одному и только одному ВУЗу. Отношение между классами ВУЗ и Факультет называют композицией, так как при уничтожении модели Вуз модели факультетов, принадлежащих этому вузу, также должны быть уничтожены. Студент и Вуз в отношении агрегации потому, что Студента нельзя удалить при уничтожении Вуза.[1]

Обобщение (наследование)

 

Диаграмма классов, показывающая наследование двух подклассов от одного суперкласса

Обобщение (Generalization) показывает, что один из двух связанных классов (подтип) является частной формой другого (надтипа), который называется обобщением первого. На практике это означает, что любой экземпляр подтипа является также экземпляром надтипа. Например: животные — супертип млекопитающих, которые, в свою очередь, — супертип приматов, и так далее. Эта взаимосвязь легче всего описывается фразой «А — это Б» (приматы — это млекопитающие, млекопитающие — это животные).

Графически обобщение представляется линией с пустым треугольником у супертипа.

Обобщение также известно как наследование или «is a» взаимосвязь (или отношение "является").

Реализация

Реализация — отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Реализация — отношение целое-часть. Графически реализация представляется так же, как и наследование, но с пунктирной линией.

Зависимость

Зависимость (dependency) — это слабая форма отношения использования, при котором изменение в спецификации одного влечёт за собой изменение другого, причём обратное не обязательно. Возникает, когда объект выступает, например, в форме параметра или локальной переменной.

Графически представляется штриховой стрелкой, идущей от зависимого элемента к тому, от которого он зависит.

Существует несколько именованных вариантов.

Зависимость может быть между экземплярами, классами или экземпляром и классом.

Уточнения отношений

Уточнение имеет отношение к уровню детализации. Один пакет уточняет другой, если в нём содержатся те же самые элементы, но в более подробном представлении. Например, при написании книги вы наверняка начнете с формулировки предложения, в котором кратко будет представлено содержание каждой главы. Предположим, что резюме к каждой главе в качестве отдельного элемента входит в пакет «Предложение». Допустим также, что «Завершённая книга» — это пакет, элементами которого являются законченные главы. В этом контексте пакет «Завершённая книга» является уточнением пакета «Предложение».

Мощность отношений (Кратность)!

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

нотация объяснение пример
0..1 Ноль или один экземпляр кошка имеет или не имеет хозяина
  Обязательно один экземпляр у кошки одна мать
0..* или * Ноль или более экземпляров у кошки может быть, а может и не быть котят
1..* Один или более экземпляров у кошки есть хотя бы одно место, где она спит

 

dfd

 

Idef0-3

Idef0-3

Idf0-2

Idef0-2

Idef-1

Idef0-1

Use case. diagramm1

Use case 2

Заказ товаров.

Activity

Sequence

Class

Statechart

Class3

Диаграмма последовательности (Sequence Diagram)

Удобное средство для обозначения очередности следования друг за другом различных стимулов (сообщений), с помощью которых объекты взаимодействуют между собой.
Например, когда нужно проработать буквально по шагам какой-то очень важный участок выполнения программы.
Главный акцент - порядок и динамика поведения, т.е. как и в каком порядке происходят события.
Отличие от диаграммы классов:
Диаграмма классов дает статическую картинку, т.е. описание которое не меняется во время выполнения программы.
Отличие от диаграммы коммуникаций (или как она раньше называлась colaboration):
Диаграмма последовательности фокусирует наше внимание на очередности выполнения по времени, а диаграмма коммуникаций - на составляющих элементах.
Обычно нормальные люди стараются описывать одной диаграммой только один определенный кейс (UseCase, вариант использования), например: "оставить коммент к сообщению в блоге", "стать постоянным читателем" и т.д...
Диаграммы последовательности,
которые описывают всю систему сразу, представляют из себя монстра, пожирающего внимание, сознание, силы, время и мозг разработчика.

Итак, предлагаю рассмотреть простенькую диаграмму последовательности.
Возьмем банальный пример:

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

1. Объект, Участник (Object, Participant)
Обозначается прямоугольником, в котором указывается информация об участнике действий. Это, как правило, название объекта и его класс, разделенные двоеточием.
Например: saveButton или saveButton:JButton или :JButton
Т.е. по большому счету, название класса можно опустить или наоборот не указывать название объекта, но что-то одно из двух (объект или класс) следует указать, а то останется нечто совсем анонимное.
Если имя объекта не указано, двоеточие перед названием класса обязательно!
В старой нотации (до UML 2.0) требовалось еще и подчеркивать.
Приблизительно вот так: oldButton:JButton
Располагаются объекты (как правило) вдоль верхнего края диаграммы. От прямоугольника вниз спускается Линия Жизни.

2. Линия жизни (Life Line)
Линия, идущая вниз от участника, обозначающая отведенное объекту время жизни. Обозначается пунктирной линией.

3. Активация, фрагмент выполнения (Activation Bar, Execution Occurances)
Обозначается узким прямоугольником (серого или белого цвета), расположенным на линии жизни. Указывает начало и завершение действия, в котором участвует объект. Поскольку линия жизни - это метафора времени, то прямоугольник на линии жизни указывает на активизацию объекта во времени.

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

5. Уничтожение объекта
Обозначается диагональным крестом на линии жизни. Обозначает конец жизни объекта.

 

Описание интерфейса разрабатываемой системы.

 

 

Функциональность:

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

Результаты:

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

 

Функциональность:

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

Результаты:

  • возможность получения информации о спросе
  • возможность получения портрета клиента
  • увеличение базы пользователей

 

ПК - компьютеры, с помощью которых ведется учёт.

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

 

Statechart

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

 

 

Erd-диаграмма

При создании моделей данных используется метод семантического моделирования. Семантическое моделирование основывается на значении структурных компонентов или характеристик данных, что способствует правильности их интерпретации (понимания, разъяснения). В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER — Entity-Relationship) — ERD.

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

Базовые понятия ERD

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

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

Экземпляр сущности (запись, кортеж)- это конкретный представитель данной сущности.

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

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

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

Один-к-одному, многое-ко-многим, один-ко-многим.

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

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

Связь типа один-ко-многим означает, что одинэкземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны «один») называется родительской, правая (со стороны «много») — дочерней.

 

 

Erd-диаграмма

 

Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемыпредметной области.

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD).

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

(сделать саму диаграмму)

Заключение.

 

 



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2019-05-16 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: