introduction to object oriented design and uml

73
софтуерен софтуерен дизайн” дизайн” Обектно-ориентиран Обектно-ориентиран дизайн и дизайн и UML UML http://patterns.dev.bg Светлин Наков Светлин Наков Национална академия по Национална академия по разработка на софтуер разработка на софтуер academy.devbg.org

Upload: svetlin-nakov

Post on 28-May-2015

2.695 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Introduction To Object Oriented Design and UML

Курс “Шаблони заКурс “Шаблони засофтуерен дизайн”софтуерен дизайн”

Обектно-ориентиранОбектно-ориентирандизайн и дизайн и UMLUML

Обектно-ориентиранОбектно-ориентирандизайн и дизайн и UMLUML

http://patterns.dev.bghttp://patterns.dev.bg

Светлин НаковСветлин НаковНационална академия по Национална академия по разработка на софтуерразработка на софтуер

academy.devbg.org

Page 2: Introduction To Object Oriented Design and UML

Обектно-ориентиранОбектно-ориентирандизайн и дизайн и UMLUMLОбектно-ориентиранОбектно-ориентирандизайн и дизайн и UMLUML

• Съдържание:Съдържание:

• Въведение в обектно-Въведение в обектно-ориентирания дизайнориентирания дизайн

• Въведение в моделирането със Въведение в моделирането със средствата на средствата на UMLUML

• Съдържание:Съдържание:

• Въведение в обектно-Въведение в обектно-ориентирания дизайнориентирания дизайн

• Въведение в моделирането със Въведение в моделирането със средствата на средствата на UMLUML

Page 3: Introduction To Object Oriented Design and UML

Въведение в обектно-ориентирания дизайнВъведение в обектно-ориентирания дизайн

Page 4: Introduction To Object Oriented Design and UML

Въведение в обектно-ориентирания дизайнВъведение в обектно-ориентирания дизайн

• Съдържание:

• Какво е обектно-ориентиран дизайн?Какво е обектно-ориентиран дизайн?

• Идентификация на класовете

• Характеристики на класовете

• Дефиниране на отговорностите

• Cohesion Cohesion и и couplingcoupling

• Съдържание:

• Какво е обектно-ориентиран дизайн?Какво е обектно-ориентиран дизайн?

• Идентификация на класовете

• Характеристики на класовете

• Дефиниране на отговорностите

• Cohesion Cohesion и и couplingcoupling

Page 5: Introduction To Object Oriented Design and UML

Обектно-ориентиран Обектно-ориентиран дизайндизайн

• Методология за моделиране на Методология за моделиране на системата с класове от ООПсистемата с класове от ООП

• Декомпозиция на изискваниятаДекомпозиция на изискванията

• Моделиране на изискваниятаМоделиране на изискванията

• Идентификация на класоветеИдентификация на класовете

• АтрибутиАтрибути

• ОперацииОперации

• Дефиниране на връзки между Дефиниране на връзки между класоветекласовете

Page 6: Introduction To Object Oriented Design and UML

Обектно-ориентиран Обектно-ориентиран дизайндизайн

• Инструментът на обектно-Инструментът на обектно-ориентирания дизайнориентирания дизайн: Unified Modeling : Unified Modeling Language (UML)Language (UML)

• Use Case Use Case диаграмидиаграми

• Клас диаграмиКлас диаграми

• Диаграми на взаимодействиятаДиаграми на взаимодействията

• Sequence Sequence диаграмидиаграми

• Activity Activity диаграмидиаграми

• Deployment Deployment диаграмидиаграми

Page 7: Introduction To Object Oriented Design and UML

Идентифициране на Идентифициране на класовете и обектитекласовете и обектитеИдентифициране на Идентифициране на класовете и обектитекласовете и обектите

• Основна цел на ОО дизайна е да опише Основна цел на ОО дизайна е да опише класовете и обектите в системата, класовете и обектите в системата, техните връзки и поведениетехните връзки и поведение

• Потенциалните класове са предметите Потенциалните класове са предметите и явленията от реалния свят, описани и явленията от реалния свят, описани в изискваниятав изискванията

• Съществителните от спецификацията Съществителните от спецификацията са класове и техни характеристикиса класове и техни характеристики

• Глаголите от спецификацията са Глаголите от спецификацията са операциите в класоветеоперациите в класовете

• Основна цел на ОО дизайна е да опише Основна цел на ОО дизайна е да опише класовете и обектите в системата, класовете и обектите в системата, техните връзки и поведениетехните връзки и поведение

• Потенциалните класове са предметите Потенциалните класове са предметите и явленията от реалния свят, описани и явленията от реалния свят, описани в изискваниятав изискванията

• Съществителните от спецификацията Съществителните от спецификацията са класове и техни характеристикиса класове и техни характеристики

• Глаголите от спецификацията са Глаголите от спецификацията са операциите в класоветеоперациите в класовете

Page 8: Introduction To Object Oriented Design and UML

Идентифициране на Идентифициране на класовете и обектитекласовете и обектитеИдентифициране на Идентифициране на класовете и обектитекласовете и обектите

• Извадка от спецификацията на проекта:Извадка от спецификацията на проекта:• Извадка от спецификацията на проекта:Извадка от спецификацията на проекта:

The user must be allowed to specify each product byits primary characteristics, including its name andproduct number. If the bar code does not match theproduct, then an error should be generated to themessage window and entered into the error log. Thesummary report of all transactions must be structured as specified in section 7.A.

• Не всички съществителни съответстват на Не всички съществителни съответстват на клас или атрибут в системата!клас или атрибут в системата!

• Не всички съществителни съответстват на Не всички съществителни съответстват на клас или атрибут в системата!клас или атрибут в системата!

Page 9: Introduction To Object Oriented Design and UML

Класове и обектиКласове и обектиКласове и обектиКласове и обекти

• Класовете дефинират структурата и Класовете дефинират структурата и поведението на даден тип обектиповедението на даден тип обекти• Пример: класът “студент”Пример: класът “студент”• Студентите имат име, курс, специалност, Студентите имат име, курс, специалност,

факултет, университет и т.н.факултет, университет и т.н.

• Имената на класовете трябва да са Имената на класовете трябва да са съществителни в единствено числосъществителни в единствено число• ПримериПримери:: StudentStudent, , MessageMessage,, AccountAccount

• Можем да създаваме много конкретни Можем да създаваме много конкретни инстанции от всеки класинстанции от всеки клас

• Класовете дефинират структурата и Класовете дефинират структурата и поведението на даден тип обектиповедението на даден тип обекти• Пример: класът “студент”Пример: класът “студент”• Студентите имат име, курс, специалност, Студентите имат име, курс, специалност,

факултет, университет и т.н.факултет, университет и т.н.

• Имената на класовете трябва да са Имената на класовете трябва да са съществителни в единствено числосъществителни в единствено число• ПримериПримери:: StudentStudent, , MessageMessage,, AccountAccount

• Можем да създаваме много конкретни Можем да създаваме много конкретни инстанции от всеки класинстанции от всеки клас

Page 10: Introduction To Object Oriented Design and UML

Идентифициране на Идентифициране на класоветекласоветеИдентифициране на Идентифициране на класоветекласовете

• Понякога е трудно да се прецени дали Понякога е трудно да се прецени дали някой предмет или явление от реалния някой предмет или явление от реалния свят трябва да бъде классвят трябва да бъде клас

• Например адресът може да е клас Например адресът може да е клас AddressAddress или символен низили символен низ

• Колкото по-добре проучим проблема, Колкото по-добре проучим проблема, толкова по-лесно ще решим кое трябва да толкова по-лесно ще решим кое трябва да е класе клас

• Когато даден клас стане прекалено голям и Когато даден клас стане прекалено голям и сложен, той трябва да се декомпозира на сложен, той трябва да се декомпозира на няколко по-малки класовеняколко по-малки класове

• Понякога е трудно да се прецени дали Понякога е трудно да се прецени дали някой предмет или явление от реалния някой предмет или явление от реалния свят трябва да бъде классвят трябва да бъде клас

• Например адресът може да е клас Например адресът може да е клас AddressAddress или символен низили символен низ

• Колкото по-добре проучим проблема, Колкото по-добре проучим проблема, толкова по-лесно ще решим кое трябва да толкова по-лесно ще решим кое трябва да е класе клас

• Когато даден клас стане прекалено голям и Когато даден клас стане прекалено голям и сложен, той трябва да се декомпозира на сложен, той трябва да се декомпозира на няколко по-малки класовеняколко по-малки класове

Page 11: Introduction To Object Oriented Design and UML

Характеристики на Характеристики на класоветекласоветеХарактеристики на Характеристики на класоветекласовете

• Класовете имат атрибути (характеристики)Класовете имат атрибути (характеристики)

• Например: класът Например: класът StudentStudent има име, учебно има име, учебно заведение и списък от курсовезаведение и списък от курсове

• Не всички характеристики са важни за Не всички характеристики са важни за софтуерната системасофтуерната система

• Например: за класа Например: за класа StudentStudent цвета на очите е цвета на очите е несъществена характеристиканесъществена характеристика

• Само съществените характеристики трябва Само съществените характеристики трябва да бъдат моделиранида бъдат моделирани

• Класовете имат атрибути (характеристики)Класовете имат атрибути (характеристики)

• Например: класът Например: класът StudentStudent има име, учебно има име, учебно заведение и списък от курсовезаведение и списък от курсове

• Не всички характеристики са важни за Не всички характеристики са важни за софтуерната системасофтуерната система

• Например: за класа Например: за класа StudentStudent цвета на очите е цвета на очите е несъществена характеристиканесъществена характеристика

• Само съществените характеристики трябва Само съществените характеристики трябва да бъдат моделиранида бъдат моделирани

Page 12: Introduction To Object Oriented Design and UML

Отговорности на Отговорности на класоветекласоветеОтговорности на Отговорности на класоветекласовете

• Всеки клас трябва да има ясно Всеки клас трябва да има ясно дефинирани отговорностидефинирани отговорности

• Какви обекти или процеси от реалния Какви обекти или процеси от реалния свят представя?свят представя?

• Какви задачи изпълнява?Какви задачи изпълнява?

• Всяко действие в програмата се Всяко действие в програмата се извършва от един или няколко метода извършва от един или няколко метода в някой класв някой клас

• Действията се моделират с операции Действията се моделират с операции (методи)(методи)

• Всеки клас трябва да има ясно Всеки клас трябва да има ясно дефинирани отговорностидефинирани отговорности

• Какви обекти или процеси от реалния Какви обекти или процеси от реалния свят представя?свят представя?

• Какви задачи изпълнява?Какви задачи изпълнява?

• Всяко действие в програмата се Всяко действие в програмата се извършва от един или няколко метода извършва от един или няколко метода в някой класв някой клас

• Действията се моделират с операции Действията се моделират с операции (методи)(методи)

Page 13: Introduction To Object Oriented Design and UML

Отговорности на Отговорности на класоветекласоветеОтговорности на Отговорности на класоветекласовете

• За имената на методите се използват За имената на методите се използват глагол + съществителноглагол + съществително

• Примери: Примери: PrintReport()PrintReport(), , ConnectToDatabase()ConnectToDatabase()

• Не може веднага да се дефинират всички Не може веднага да се дефинират всички методи на даден класметоди на даден клас

• Дефинираме първо най-важните методи – Дефинираме първо най-важните методи – тези, които реализират основните тези, които реализират основните отговорности на класаотговорности на класа

• С времето се появяват още С времето се появяват още допълнителни методидопълнителни методи

• За имената на методите се използват За имената на методите се използват глагол + съществителноглагол + съществително

• Примери: Примери: PrintReport()PrintReport(), , ConnectToDatabase()ConnectToDatabase()

• Не може веднага да се дефинират всички Не може веднага да се дефинират всички методи на даден класметоди на даден клас

• Дефинираме първо най-важните методи – Дефинираме първо най-важните методи – тези, които реализират основните тези, които реализират основните отговорности на класаотговорности на класа

• С времето се появяват още С времето се появяват още допълнителни методидопълнителни методи

Page 14: Introduction To Object Oriented Design and UML

Cohesion Cohesion и и couplingcouplingCohesion Cohesion и и couplingcoupling

• Фундаментални принципи при Фундаментални принципи при софтуерния дизайн (и при обектно-софтуерния дизайн (и при обектно-ориентирания дизайн)ориентирания дизайн)

• Strong cohesionStrong cohesion

• Силна свързаност на отговорноститеСилна свързаност на отговорностите

• Класът решава една ясно дефинирана Класът решава една ясно дефинирана задача (само една!)задача (само една!)

• Loose couplingLoose coupling

• Слаба свързаност с другите класовеСлаба свързаност с другите класове

• Независимост от средатаНезависимост от средата

• Фундаментални принципи при Фундаментални принципи при софтуерния дизайн (и при обектно-софтуерния дизайн (и при обектно-ориентирания дизайн)ориентирания дизайн)

• Strong cohesionStrong cohesion

• Силна свързаност на отговорноститеСилна свързаност на отговорностите

• Класът решава една ясно дефинирана Класът решава една ясно дефинирана задача (само една!)задача (само една!)

• Loose couplingLoose coupling

• Слаба свързаност с другите класовеСлаба свързаност с другите класове

• Независимост от средатаНезависимост от средата

Page 15: Introduction To Object Oriented Design and UML

Good and Bad CohesionGood and Bad CohesionGood and Bad CohesionGood and Bad Cohesion

• Good: hard disk, cdrom, floppyGood: hard disk, cdrom, floppy

• BAD: spaghetti codeBAD: spaghetti code

• Good: hard disk, cdrom, floppyGood: hard disk, cdrom, floppy

• BAD: spaghetti codeBAD: spaghetti code

Page 16: Introduction To Object Oriented Design and UML

Loose and Tight Loose and Tight CouplingCouplingLoose and Tight Loose and Tight CouplingCoupling

• Loose Coupling:Loose Coupling:

• Easily replace old HDDEasily replace old HDD

• Easily place this HDD Easily place this HDD to another motherboardto another motherboard

• Tight Coupling:Tight Coupling:

• Where is the video Where is the video adapter?adapter?

• Can you change the Can you change the video controller?video controller?

• Loose Coupling:Loose Coupling:

• Easily replace old HDDEasily replace old HDD

• Easily place this HDD Easily place this HDD to another motherboardto another motherboard

• Tight Coupling:Tight Coupling:

• Where is the video Where is the video adapter?adapter?

• Can you change the Can you change the video controller?video controller?

Page 17: Introduction To Object Oriented Design and UML

Въведение в UMLВъведение в UML

Page 18: Introduction To Object Oriented Design and UML

Въведение в UMLВъведение в UML

• Съдържание:• Какво е моделиранеКакво е моделиране??

• Какво еКакво е UML? UML?

• Use case Use case диаграмидиаграми

• ClassClass диаграми диаграми

• Sequence Sequence диаграмидиаграми

• Activity Activity диаграмидиаграми

• Съдържание:• Какво е моделиранеКакво е моделиране??

• Какво еКакво е UML? UML?

• Use case Use case диаграмидиаграми

• ClassClass диаграми диаграми

• Sequence Sequence диаграмидиаграми

• Activity Activity диаграмидиаграми

Page 19: Introduction To Object Oriented Design and UML

Какво е моделиране?Какво е моделиране?Какво е моделиране?Какво е моделиране?

• Моделиране означава да създадем Моделиране означава да създадем абстракция на действителносттаабстракция на действителността

• Абстракциите представляват Абстракциите представляват опростен образ на реалносттаопростен образ на реалността::

• Те игнорират несъществените детайлиТе игнорират несъществените детайли

• Запазват само същественитеЗапазват само съществените

• Кое е Кое е същественосъществено и кое и кое несъщественонесъществено зависи от зависи от предназначението на моделапредназначението на модела

• Моделиране означава да създадем Моделиране означава да създадем абстракция на действителносттаабстракция на действителността

• Абстракциите представляват Абстракциите представляват опростен образ на реалносттаопростен образ на реалността::

• Те игнорират несъществените детайлиТе игнорират несъществените детайли

• Запазват само същественитеЗапазват само съществените

• Кое е Кое е същественосъществено и кое и кое несъщественонесъществено зависи от зависи от предназначението на моделапредназначението на модела

Page 20: Introduction To Object Oriented Design and UML

Пример: карта на градаПример: карта на градаПример: карта на градаПример: карта на града

Page 21: Introduction To Object Oriented Design and UML

Защо да моделираме Защо да моделираме софтуера?софтуера?Защо да моделираме Защо да моделираме софтуера?софтуера?

• Сложността на софтуера постоянно Сложността на софтуера постоянно нарастванараства

• Windows XP Windows XP се състои от над 40 се състои от над 40 милиона реда сорс кодмилиона реда сорс код

• Един програмист не може да познава в Един програмист не може да познава в детайли такъв обем коддетайли такъв обем код

• Има нужда от просто представяне на Има нужда от просто представяне на сложните системисложните системи

• Моделирането е средство за справяне Моделирането е средство за справяне със сложносттасъс сложността

• Сложността на софтуера постоянно Сложността на софтуера постоянно нарастванараства

• Windows XP Windows XP се състои от над 40 се състои от над 40 милиона реда сорс кодмилиона реда сорс код

• Един програмист не може да познава в Един програмист не може да познава в детайли такъв обем коддетайли такъв обем код

• Има нужда от просто представяне на Има нужда от просто представяне на сложните системисложните системи

• Моделирането е средство за справяне Моделирането е средство за справяне със сложносттасъс сложността

Page 22: Introduction To Object Oriented Design and UML

Системи, модели и Системи, модели и изгледиизгледиСистеми, модели и Системи, модели и изгледиизгледи

• МоделътМоделът ( (model) model) е абстракция, която е абстракция, която описва подмножество от систематаописва подмножество от системата

• ИзгледътИзгледът (view) (view) описва избрани описва избрани аспекти от моделааспекти от модела

• НотациитеНотациите ( (notations) notations) са множества от са множества от графични и текстови правила за графични и текстови правила за представяне на изгледитепредставяне на изгледите

• Изгледите и моделите на дадена Изгледите и моделите на дадена система могат да се припокриватсистема могат да се припокриват

• МоделътМоделът ( (model) model) е абстракция, която е абстракция, която описва подмножество от систематаописва подмножество от системата

• ИзгледътИзгледът (view) (view) описва избрани описва избрани аспекти от моделааспекти от модела

• НотациитеНотациите ( (notations) notations) са множества от са множества от графични и текстови правила за графични и текстови правила за представяне на изгледитепредставяне на изгледите

• Изгледите и моделите на дадена Изгледите и моделите на дадена система могат да се припокриватсистема могат да се припокриват

Page 23: Introduction To Object Oriented Design and UML

Системи, модели и Системи, модели и изгледиизгледиСистеми, модели и Системи, модели и изгледиизгледи

• ПримериПримери

• Система: самолетСистема: самолет

• Модели:Модели:

• Статичен моделСтатичен модел

• Аеродинамичен моделАеродинамичен модел

• ИзгледиИзгледи::

• Изглед на електрическата системаИзглед на електрическата система

• Изглед на двигателната системаИзглед на двигателната система

• Изглед на отоплителната системаИзглед на отоплителната система

• ПримериПримери

• Система: самолетСистема: самолет

• Модели:Модели:

• Статичен моделСтатичен модел

• Аеродинамичен моделАеродинамичен модел

• ИзгледиИзгледи::

• Изглед на електрическата системаИзглед на електрическата система

• Изглед на двигателната системаИзглед на двигателната система

• Изглед на отоплителната системаИзглед на отоплителната система

Page 24: Introduction To Object Oriented Design and UML

Системи, модели и Системи, модели и изгледиизгледиСистеми, модели и Системи, модели и изгледиизгледи

SystemView 1

Model 2View 2

View 3

Model 1

самолет

статиченна полета

аеродина- мичен модел

отопли-телна

система

електрическоокабеляване

Page 25: Introduction To Object Oriented Design and UML

Какво еКакво е UML? UML?Какво еКакво е UML? UML?

• UML (Unified Modeling Language)UML (Unified Modeling Language)

• Утвърден стандарт за моделиране на Утвърден стандарт за моделиране на софтуерни системисофтуерни системи

• Универсална нотация за графично Универсална нотация за графично изобразяване на модели и изгледиизобразяване на модели и изгледи

• Поддържа се от много инструментиПоддържа се от много инструменти• TogetherTogether

• Rational RoseRational Rose

• Microsoft VisioMicrosoft Visio

• PoseidonPoseidon

• UML (Unified Modeling Language)UML (Unified Modeling Language)

• Утвърден стандарт за моделиране на Утвърден стандарт за моделиране на софтуерни системисофтуерни системи

• Универсална нотация за графично Универсална нотация за графично изобразяване на модели и изгледиизобразяване на модели и изгледи

• Поддържа се от много инструментиПоддържа се от много инструменти• TogetherTogether

• Rational RoseRational Rose

• Microsoft VisioMicrosoft Visio

• PoseidonPoseidon

Page 26: Introduction To Object Oriented Design and UML

UML: UML: принципът принципът 80/280/200UML: UML: принципът принципът 80/280/200

• Можете да моделирате Можете да моделирате 80% 80% от от проблемите с проблемите с 20% 20% от средствата на от средствата на UMLUML

• Нека разгледаме тези Нека разгледаме тези 20%20%

• Можете да моделирате Можете да моделирате 80% 80% от от проблемите с проблемите с 20% 20% от средствата на от средствата на UMLUML

• Нека разгледаме тези Нека разгледаме тези 20%20%

Page 27: Introduction To Object Oriented Design and UML

UMLUML: видове диаграми: видове диаграмиUMLUML: видове диаграми: видове диаграми

• Use case Use case диаграми (случаи на диаграми (случаи на употреба)употреба)

• Описват поведението на системата от Описват поведението на системата от гледна точка на потребителягледна точка на потребителя

• Какво може да правят различните Какво може да правят различните видове потребителивидове потребители

• Class Class диаграмидиаграми

• Описват класовете (атрибути и методи) и Описват класовете (атрибути и методи) и връзките между тях (асоциации, връзките между тях (асоциации, наследяване, ...)наследяване, ...)

• Use case Use case диаграми (случаи на диаграми (случаи на употреба)употреба)

• Описват поведението на системата от Описват поведението на системата от гледна точка на потребителягледна точка на потребителя

• Какво може да правят различните Какво може да правят различните видове потребителивидове потребители

• Class Class диаграмидиаграми

• Описват класовете (атрибути и методи) и Описват класовете (атрибути и методи) и връзките между тях (асоциации, връзките между тях (асоциации, наследяване, ...)наследяване, ...)

Page 28: Introduction To Object Oriented Design and UML

UMLUML: видове диаграми: видове диаграмиUMLUML: видове диаграми: видове диаграми

• Sequence Sequence диаграмидиаграми• Описват схематично на Описват схематично на

взаимодействието между взаимодействието между потребителите и систематапотребителите и системата

• Отделните действия са подредени Отделните действия са подредени във времетовъв времето

• Statechart Statechart диаграмидиаграми• Описват възможните състояния на Описват възможните състояния на

даден процес и възможните преходи даден процес и възможните преходи между тяхмежду тях

• Представляват краен автоматПредставляват краен автомат

• Sequence Sequence диаграмидиаграми• Описват схематично на Описват схематично на

взаимодействието между взаимодействието между потребителите и систематапотребителите и системата

• Отделните действия са подредени Отделните действия са подредени във времетовъв времето

• Statechart Statechart диаграмидиаграми• Описват възможните състояния на Описват възможните състояния на

даден процес и възможните преходи даден процес и възможните преходи между тяхмежду тях

• Представляват краен автоматПредставляват краен автомат

Page 29: Introduction To Object Oriented Design and UML

UMLUML: видове диаграми: видове диаграмиUMLUML: видове диаграми: видове диаграми

• Activity Activity диаграмидиаграми

• Описват потока на работните процеси Описват потока на работните процеси ((workflow)workflow)

• Представляват нещо като блок-схемиПредставляват нещо като блок-схеми

• Activity Activity диаграмидиаграми

• Описват потока на работните процеси Описват потока на работните процеси ((workflow)workflow)

• Представляват нещо като блок-схемиПредставляват нещо като блок-схеми

Page 30: Introduction To Object Oriented Design and UML

UML: Use Case UML: Use Case диаграмидиаграмиUML: Use Case UML: Use Case диаграмидиаграми

WatchUser WatchRepairPerson

ReadTime

SetTime

ChangeBattery

Actor

Use casePackageWatch

• Описват функционалността на системата от гледна точка на потребителя

• Описват функционалността на системата от гледна точка на потребителя

Page 31: Introduction To Object Oriented Design and UML

UML: Class UML: Class диаграмидиаграмиUML: Class UML: Class диаграмидиаграми

1

2

push()release()

1

1

blinkIdxblinkSeconds()blinkMinutes()blinkHours()stopBlinking()referesh()

LCDDisplay Batteryload

1

2

1

Timenow

1

Watch

ClassAssociation

Multiplicity

Attributes Operations

• Описват класовете и връзките между тяхОписват класовете и връзките между тях• Описват класовете и връзките между тяхОписват класовете и връзките между тях

state

PushButton

• Пример: часовникПример: часовник• Пример: часовникПример: часовник

Page 32: Introduction To Object Oriented Design and UML

UML: Sequence UML: Sequence диаграмидиаграмиUML: Sequence UML: Sequence диаграмидиаграми

:LCDDisplay

blinkHours()

blinkMinutes()

refresh()

commitNewTime()

:Time

incrementMinutes()

stopBlinking()

:Watch

pressButton1()

pressButton2()

pressButtons1And2()

pressButton1()

:WatchUser

Object

Message

Activation

• Описват взаимодействието между потребителите и системата във времето

• Описват взаимодействието между потребителите и системата във времето

Actor

Lifeline

Page 33: Introduction To Object Oriented Design and UML

BlinkHours

BlinkMinutes

IncrementHrs

IncrementMin.

BlinkSeconds IncrementSec.

StopBlinking

[button1&2Pressed]

[button1Pressed]

[button2Pressed]

[button2Pressed]

[button2Pressed]

[button1Pressed]

[button1&2Pressed]

[button1&2Pressed]

UML: Statechart UML: Statechart диаграмидиаграмиUML: Statechart UML: Statechart диаграмидиаграми

• Описват поведението чрез състояния и преходи между тях

• Описват поведението чрез състояния и преходи между тях

State

Initial state

Final state

Transition

Event

Page 34: Introduction To Object Oriented Design and UML

ДругиДруги UML UML нотациинотацииДругиДруги UML UML нотациинотации

• UML UML предоставя и други видове предоставя и други видове диаграми (нотации)диаграми (нотации)

• ИмплементационниИмплементационни диаграмидиаграми

• Component Component диаграмидиаграми• Моделират отделен компонентМоделират отделен компонент

• Deployment Deployment диаграмидиаграми• Моделират средата, в която ще се Моделират средата, в която ще се

инсталира систематаинсталира системата

• Език за ограничения на обектитеЕзик за ограничения на обектите

• Дефинира входни и изходни условияДефинира входни и изходни условия

• UML UML предоставя и други видове предоставя и други видове диаграми (нотации)диаграми (нотации)

• ИмплементационниИмплементационни диаграмидиаграми

• Component Component диаграмидиаграми• Моделират отделен компонентМоделират отделен компонент

• Deployment Deployment диаграмидиаграми• Моделират средата, в която ще се Моделират средата, в която ще се

инсталира систематаинсталира системата

• Език за ограничения на обектитеЕзик за ограничения на обектите

• Дефинира входни и изходни условияДефинира входни и изходни условия

Page 35: Introduction To Object Oriented Design and UML

UMLUML: основни нотации: основни нотацииUMLUML: основни нотации: основни нотации

• Правоъгълниците са класове или Правоъгълниците са класове или инстанции на класовеинстанции на класове

• Елипсите са функции или случаи на Елипсите са функции или случаи на употреба (употреба (use casesuse cases))

• Инстанциите се означават с Инстанциите се означават с подчертани имена, например:подчертани имена, например:

• myWatch:SimpleWatchmyWatch:SimpleWatch

• Joe:FirefighterJoe:Firefighter

• Правоъгълниците са класове или Правоъгълниците са класове или инстанции на класовеинстанции на класове

• Елипсите са функции или случаи на Елипсите са функции или случаи на употреба (употреба (use casesuse cases))

• Инстанциите се означават с Инстанциите се означават с подчертани имена, например:подчертани имена, например:

• myWatch:SimpleWatchmyWatch:SimpleWatch

• Joe:FirefighterJoe:Firefighter

Page 36: Introduction To Object Oriented Design and UML

UMLUML: основни нотации: основни нотацииUMLUML: основни нотации: основни нотации

• Типовете (класове, интерфейси и т.н.) Типовете (класове, интерфейси и т.н.) са без подчертани имена, например:са без подчертани имена, например:

• SimpleWatchSimpleWatch

• FirefighterFirefighter

• Диаграмите са графиДиаграмите са графи

• Върховете им са обекти от Върховете им са обекти от моделираната област (моделираната област (entitiesentities))

• Дъгите са връзки между обектитеДъгите са връзки между обектите

• Типовете (класове, интерфейси и т.н.) Типовете (класове, интерфейси и т.н.) са без подчертани имена, например:са без подчертани имена, например:

• SimpleWatchSimpleWatch

• FirefighterFirefighter

• Диаграмите са графиДиаграмите са графи

• Върховете им са обекти от Върховете им са обекти от моделираната област (моделираната област (entitiesentities))

• Дъгите са връзки между обектитеДъгите са връзки между обектите

Page 37: Introduction To Object Oriented Design and UML

Use Case Use Case диаграмидиаграмиUse Case Use Case диаграмидиаграми

• Използват се при извличане Използват се при извличане на изискванията за описание на изискванията за описание на възможните действияна възможните действия

• Актьорите (Актьорите (Actors)Actors) представят роли (типове представят роли (типове потребители)потребители)

• Използват се при извличане Използват се при извличане на изискванията за описание на изискванията за описание на възможните действияна възможните действия

• Актьорите (Актьорите (Actors)Actors) представят роли (типове представят роли (типове потребители)потребители)

Passenger

Purchaseticket

View thetimetable

• Случаите на употреба (Случаите на употреба (Use casesUse cases)) описват описват взаимодействие между актьорите и систематавзаимодействие между актьорите и системата

• Use case Use case моделът е група моделът е група use casesuse cases

• Предоставя пълно описание на Предоставя пълно описание на функционалността на систематафункционалността на системата

• Случаите на употреба (Случаите на употреба (Use casesUse cases)) описват описват взаимодействие между актьорите и систематавзаимодействие между актьорите и системата

• Use case Use case моделът е група моделът е група use casesuse cases

• Предоставя пълно описание на Предоставя пълно описание на функционалността на систематафункционалността на системата

Page 38: Introduction To Object Oriented Design and UML

Актьори (Актьори (ActorsActors))Актьори (Актьори (ActorsActors))

• Актьорът е някой, който Актьорът е някой, който взаимодейства със систематавзаимодейства със системата

• потребителпотребител

• външна системавъншна система

• външната средавъншната среда

• Актьорът има уникално име и Актьорът има уникално име и евентуално описаниеевентуално описание

• ПримериПримери::

• ПътникПътник: : човек във влакачовек във влака

• GPS GPS сателитсателит: : предоставяпредоставя GPS GPS координатикоординати

• Актьорът е някой, който Актьорът е някой, който взаимодейства със систематавзаимодейства със системата

• потребителпотребител

• външна системавъншна система

• външната средавъншната среда

• Актьорът има уникално име и Актьорът има уникално име и евентуално описаниеевентуално описание

• ПримериПримери::

• ПътникПътник: : човек във влакачовек във влака

• GPS GPS сателитсателит: : предоставяпредоставя GPS GPS координатикоординати

Passenger

GPSsatellite

Page 39: Introduction To Object Oriented Design and UML

Use CaseUse CaseUse CaseUse Case

• Един Един use case use case описва една от описва една от функционалностите на систематафункционалностите на системата

• Състои се отСъстои се от::

• Уникално имеУникално име

• Свързан е с актьориСвързан е с актьори

• Има входни условияИма входни условия

• Съдържа поток от действия Съдържа поток от действия (процес)(процес)

• Има изходни условияИма изходни условия

• Може да има и други изискванияМоже да има и други изисквания

• Един Един use case use case описва една от описва една от функционалностите на систематафункционалностите на системата

• Състои се отСъстои се от::

• Уникално имеУникално име

• Свързан е с актьориСвързан е с актьори

• Има входни условияИма входни условия

• Съдържа поток от действия Съдържа поток от действия (процес)(процес)

• Има изходни условияИма изходни условия

• Може да има и други изискванияМоже да има и други изисквания

Purchaseticket

View thetimetable

Page 40: Introduction To Object Oriented Design and UML

Use CaseUse Case – пример – примерUse CaseUse Case – пример – пример

ИмеИме:: Purchase ticketPurchase ticket

Участващи актьориУчастващи актьори:: PassengerPassenger

Входни условияВходни условия::

• PassengerPassenger е пред е пред продавача на билетипродавача на билети

• PassengerPassenger има има достатъчно пари за достатъчно пари за билетбилет

Изходни условияИзходни условия

• PassengerPassenger има билетима билет

ИмеИме:: Purchase ticketPurchase ticket

Участващи актьориУчастващи актьори:: PassengerPassenger

Входни условияВходни условия::

• PassengerPassenger е пред е пред продавача на билетипродавача на билети

• PassengerPassenger има има достатъчно пари за достатъчно пари за билетбилет

Изходни условияИзходни условия

• PassengerPassenger има билетима билет

Поток от действия Поток от действия (описание на процеса)(описание на процеса)::

1. 1. PassengerPassenger избира избира крайна гаракрайна гара

2. 2. Продавачът съобщава Продавачът съобщава дължимата сумадължимата сума

3. 3. PassengerPassenger подава париподава пари

4. 4. Продавачът връща Продавачът връща ресторесто

5. 5. Продавачът издава Продавачът издава билетбилет

Поток от действия Поток от действия (описание на процеса)(описание на процеса)::

1. 1. PassengerPassenger избира избира крайна гаракрайна гара

2. 2. Продавачът съобщава Продавачът съобщава дължимата сумадължимата сума

3. 3. PassengerPassenger подава париподава пари

4. 4. Продавачът връща Продавачът връща ресторесто

5. 5. Продавачът издава Продавачът издава билетбилет

Изпуснахме ли нещо? Случаите на проблем!

Page 41: Introduction To Object Oriented Design and UML

РелациятаРелацията <<extends>><<extends>>РелациятаРелацията <<extends>><<extends>>

• <<extends>><<extends>> представя изключение или представя изключение или рядко възникващ случайрядко възникващ случай

• <<extends>><<extends>> представя изключение или представя изключение или рядко възникващ случайрядко възникващ случай

Passenger PurchaseTicket

TimeOut

<<extends>>

NoChange

<<extends>>OutOfOrder

<<extends>>

Cancel

<<extends>>

• Процесът за Процесът за обработка на обработка на изключителна изключителна ситуация е извън ситуация е извън основния случай основния случай на употребана употреба

• Процесът за Процесът за обработка на обработка на изключителна изключителна ситуация е извън ситуация е извън основния случай основния случай на употребана употреба

Page 42: Introduction To Object Oriented Design and UML

РелациятаРелацията <<includes>><<includes>>РелациятаРелацията <<includes>><<includes>>

• <<includes>><<includes>> е е поведение, поведение, извадено извън извадено извън даден даден use caseuse case

• Позволява Позволява преизползване преизползване на споделена на споделена функционалностфункционалност

• <<includes>><<includes>> е е поведение, поведение, извадено извън извадено извън даден даден use caseuse case

• Позволява Позволява преизползване преизползване на споделена на споделена функционалностфункционалност

Passenger

PurchaseSingleTicket

PurchaseMultiCard

NoChange

<<extends>>

Cancel

<<extends>>

<<includes>>

CollectMoney

<<includes>>

Page 43: Introduction To Object Oriented Design and UML

Class Class диаграмидиаграмиClass Class диаграмидиаграми

• Описват структурата на систематаОписват структурата на системата

• Използват се:Използват се:

• По време на анализиране на изискванията за По време на анализиране на изискванията за моделиране на обектите от реалния святмоделиране на обектите от реалния свят

• По време на дизайна за моделиране на По време на дизайна за моделиране на подсистемитеподсистемите

• Дефинират класове и връзки между тяхДефинират класове и връзки между тях

• Описват структурата на систематаОписват структурата на системата

• Използват се:Използват се:

• По време на анализиране на изискванията за По време на анализиране на изискванията за моделиране на обектите от реалния святмоделиране на обектите от реалния свят

• По време на дизайна за моделиране на По време на дизайна за моделиране на подсистемитеподсистемите

• Дефинират класове и връзки между тяхДефинират класове и връзки между тях

Enumeration getZones()Price getPrice(Zone)

TarifSchedule

* *

Tripzone:Zone

Price: Price

Page 44: Introduction To Object Oriented Design and UML

КласовеКласовеКласовеКласове

• КласътКласът е същност от реалния свят е същност от реалния свят

• Има Има имеиме, състояние , състояние ((атрибутиатрибути)) и поведение и поведение (операции)(операции)

• Всеки атрибут имВсеки атрибут имaa типтип

• Всяка операция има Всяка операция има сигнатурасигнатура (връщан тип) (връщан тип)

• КласътКласът е същност от реалния свят е същност от реалния свят

• Има Има имеиме, състояние , състояние ((атрибутиатрибути)) и поведение и поведение (операции)(операции)

• Всеки атрибут имВсеки атрибут имaa типтип

• Всяка операция има Всяка операция има сигнатурасигнатура (връщан тип) (връщан тип)

zone2pricegetZones()getPrice()

TarifScheduleTable zone2priceEnumeration getZones()Price getPrice(Zone)

TarifScheduleName

Attributes

OperationsSignature

(return type)

Page 45: Introduction To Object Oriented Design and UML

ИнстанцииИнстанцииИнстанцииИнстанции

• ИнстанциятаИнстанцията е конкретен екземпляр от е конкретен екземпляр от даден класдаден клас ( (обект)обект)

• Имената на инстанциите са Имената на инстанциите са подчертаниподчертани и и могат да съдържат класамогат да съдържат класа

• Атрибутите се задават заедно със Атрибутите се задават заедно със стойностите систойностите си

• ИнстанциятаИнстанцията е конкретен екземпляр от е конкретен екземпляр от даден класдаден клас ( (обект)обект)

• Имената на инстанциите са Имената на инстанциите са подчертаниподчертани и и могат да съдържат класамогат да съдържат класа

• Атрибутите се задават заедно със Атрибутите се задават заедно със стойностите систойностите си

zone2price = {{‘1’, .20},{‘2’, .40},{‘3’, .60}}

tarif_1974:TarifSchedule

Page 46: Introduction To Object Oriented Design and UML

Актьори, класове и Актьори, класове и инстанцииинстанцииАктьори, класове и Актьори, класове и инстанцииинстанции

• АктьорАктьор::

• Външен за системата обект, който Външен за системата обект, който взаимодейства с нея, например "пътник"взаимодейства с нея, например "пътник"

• Клас:Клас:

• Абстракция, моделираща същност от Абстракция, моделираща същност от реалния свят, част от системата, реалния свят, част от системата, например "потребител"например "потребител"

• ОбектОбект: :

• Специфична инстанция на клас, например Специфична инстанция на клас, например "пътникът Бай Киро""пътникът Бай Киро"

• АктьорАктьор::

• Външен за системата обект, който Външен за системата обект, който взаимодейства с нея, например "пътник"взаимодейства с нея, например "пътник"

• Клас:Клас:

• Абстракция, моделираща същност от Абстракция, моделираща същност от реалния свят, част от системата, реалния свят, част от системата, например "потребител"например "потребител"

• ОбектОбект: :

• Специфична инстанция на клас, например Специфична инстанция на клас, например "пътникът Бай Киро""пътникът Бай Киро"

Page 47: Introduction To Object Oriented Design and UML

PriceZone

АсоциацииАсоциацииАсоциацииАсоциации

• Асоциациите представляват връзки между Асоциациите представляват връзки между класоветекласовете

• Моделират взаимоотношенияМоделират взаимоотношения

• Могат да дефинират множественост (1 към Могат да дефинират множественост (1 към 1, 1 към много, много към 1, 1 към 2, ...)1, 1 към много, много към 1, 1 към 2, ...)

• Асоциациите представляват връзки между Асоциациите представляват връзки между класоветекласовете

• Моделират взаимоотношенияМоделират взаимоотношения

• Могат да дефинират множественост (1 към Могат да дефинират множественост (1 към 1, 1 към много, много към 1, 1 към 2, ...)1, 1 към много, много към 1, 1 към 2, ...)

Enumeration getZones()Price getPrice(Zone)

TarifSchedule Trip

* *

Page 48: Introduction To Object Oriented Design and UML

Асоциации Асоциации 1-1-къмкъм-1 -1 ии 1- 1-къмкъм--многомного

Country

name: String

City

name: StringHas-capital

Polygon

draw()

Point

x: Integer

y: Integer

•Асоциация 1-към-1:

*

1 1

•Асоциация 1-към-много:

Consists-of

Page 49: Introduction To Object Oriented Design and UML

АсоциацииАсоциациимногомного--къмкъм--многомного

StockExchange Company

tickerSymbol

Lists **

StockExchange CompanyLists 1*tickerSymbol SX_ID

•Асоциация много-към-много:

•Асоциация много-към-много по атрибут:

Page 50: Introduction To Object Oriented Design and UML

От реалната ситуация От реалната ситуация към обектния моделкъм обектния модел

•Реална ситуация:Реална ситуация:

• Борсата търгува с много компанииБорсата търгува с много компании

• Всяка компания се идентифицира с Всяка компания се идентифицира с tickerticker

•Клас диаграма:Клас диаграма:

StockExchangeStockExchange CompanyCompany

tickerSymboltickerSymbolListsLists

**11

Page 51: Introduction To Object Oriented Design and UML

От реалната ситуация към От реалната ситуация към програмния кодпрограмния кодОт реалната ситуация към От реалната ситуация към програмния кодпрограмния код

•Реална ситуация:Реална ситуация:

• Борсата търгува с много компанииБорсата търгува с много компании

• Всяка компания се идентифицира с Всяка компания се идентифицира с tickerticker

•Клас диаграма:Клас диаграма:

•Програмен код:Програмен код:

StockExchangeStockExchange CompanyCompany

tickerSymboltickerSymbolListsLists **11

public class StockExchangepublic class StockExchange{{ private ArrayList Company; private ArrayList Company; ......}}

public class Companypublic class Company{{ private string private string tickerSymbol;tickerSymbol; ......}}

Page 52: Introduction To Object Oriented Design and UML

население

АгрегацияАгрегацияАгрегацияАгрегация

• Агрегацията е специален вид асоциацияАгрегацията е специален вид асоциация

• Моделира връзката "цяло / част"Моделира връзката "цяло / част"

• АгрегатАгрегат наричаме родителския клас наричаме родителския клас

• КомпонентиКомпоненти наричаме класовете- наричаме класовете-наследницинаследници

• Агрегацията е специален вид асоциацияАгрегацията е специален вид асоциация

• Моделира връзката "цяло / част"Моделира връзката "цяло / част"

• АгрегатАгрегат наричаме родителския клас наричаме родителския клас

• КомпонентиКомпоненти наричаме класовете- наричаме класовете-наследницинаследници

Влак

Локомотивмощност

1 1..*Пътник

име

Държава

Градиме

*

именомер

1

Агрегат

Компонент

Page 53: Introduction To Object Oriented Design and UML

КомпозицияКомпозицияКомпозицияКомпозиция

• Запълнен ромб означава Запълнен ромб означава композициякомпозиция

• Композицията е агрегация, при която Композицията е агрегация, при която компонентите не могат да съществуват без компонентите не могат да съществуват без агрегата (родителя)агрегата (родителя)

• Запълнен ромб означава Запълнен ромб означава композициякомпозиция

• Композицията е агрегация, при която Композицията е агрегация, при която компонентите не могат да съществуват без компонентите не могат да съществуват без агрегата (родителя)агрегата (родителя)

Диалогов прозорец

Бутон2

Page 54: Introduction To Object Oriented Design and UML

Свързващи атрибути Свързващи атрибути ((QualifiersQualifiers))Свързващи атрибути Свързващи атрибути ((QualifiersQualifiers))

• Свързващите атрибути (Свързващите атрибути (qualifiersqualifiers) ) намаляват множествеността намаляват множествеността ((multiplicitymultiplicity) на дадена асоциация) на дадена асоциация

• Свързващите атрибути (Свързващите атрибути (qualifiersqualifiers) ) намаляват множествеността намаляват множествеността ((multiplicitymultiplicity) на дадена асоциация) на дадена асоциация

DirectoryFile

filename

Без свързващ атрибут

1 *

Със свързващ атрибут

Directory File0…11

filename

Page 55: Introduction To Object Oriented Design and UML

НаследяванеНаследяванеНаследяванеНаследяване

• Класовете-наследници наследяват Класовете-наследници наследяват атрибутите и операциите от родителския атрибутите и операциите от родителския (базовия) клас(базовия) клас

• Наследяването опростява модела като Наследяването опростява модела като премахва повторениятапремахва повторенията

• Класовете-наследници наследяват Класовете-наследници наследяват атрибутите и операциите от родителския атрибутите и операциите от родителския (базовия) клас(базовия) клас

• Наследяването опростява модела като Наследяването опростява модела като премахва повторениятапремахва повторенията

Button

ZoneButtonCancelButton

Page 56: Introduction To Object Oriented Design and UML

Практика: Идентификация Практика: Идентификация на класоветена класоветеПрактика: Идентификация Практика: Идентификация на класоветена класовете

FooAlabalaCustomerId

Deposit()Withdraw()GetBalance()

• Идентификация на класоветеИдентификация на класовете::

• Име на класаИме на класа

• АтрибутиАтрибути

• МетодиМетоди

• Пример:Пример:

• Идентификация на класоветеИдентификация на класовете::

• Име на класаИме на класа

• АтрибутиАтрибути

• МетодиМетоди

• Пример:Пример:

Page 57: Introduction To Object Oriented Design and UML

Foo

Alabala

CustomerId

Deposit()Withdraw()GetBalance() Account

Type

CustomerId

Deposit()Withdraw()GetBalance()

Имената са важни! Foo ли е правилното име?

Ами това Alabala?

Практика: Правилно Практика: Правилно именуванеименуванеПрактика: Правилно Практика: Правилно именуванеименуване

Page 58: Introduction To Object Oriented Design and UML

Практика: Обектно-Практика: Обектно-ориентирано моделиранеориентирано моделиранеПрактика: Обектно-Практика: Обектно-ориентирано моделиранеориентирано моделиране

Customer

NameCustomerId

Bank

Name

1) Търсим нови обекти

2) Намираме техните име, атрибути, методи

Account

Type

Deposit()Withdraw()GetBalance()

Page 59: Introduction To Object Oriented Design and UML

Практика: Моделиране на Практика: Моделиране на банкова системабанкова системаПрактика: Моделиране на Практика: Моделиране на банкова системабанкова система

Account

Type

Deposit()Withdraw()GetBalance()

Customer

NameCustomerId

CustomerIdBank

Name

1) Търсим нови обекти

2) Намираме техните име, атрибути, методи

3) Намираме асоциациите между обектите

Has

4) Задаваме имена на асоциациите5) Задаваме множественост на асоциациите

*

Page 60: Introduction To Object Oriented Design and UML

CustomerId()

Account

Amount

Deposit()Withdraw()GetBalance()

CustomerId

Bank

Name Has**

SavingsAccount

Withdraw()

CheckingAccount

Withdraw()

MortgageAccount

Withdraw()

Практика: ИтерирамеПрактика: ИтерирамеПрактика: ИтерирамеПрактика: Итерираме

Customer

NameCustomerId

Page 61: Introduction To Object Oriented Design and UML

ПакетиПакетиПакетиПакети

• Пакетът еПакетът е UML UML нотация за нотация за организиране на елементи в групаорганизиране на елементи в група

• Сложните системи се декомпозират Сложните системи се декомпозират на подсистеми, всяка от които е на подсистеми, всяка от които е пакетпакет

• Пакетът еПакетът е UML UML нотация за нотация за организиране на елементи в групаорганизиране на елементи в група

• Сложните системи се декомпозират Сложните системи се декомпозират на подсистеми, всяка от които е на подсистеми, всяка от които е пакетпакет

DispatcherInterface

Notification IncidentManagement

Page 62: Introduction To Object Oriented Design and UML

Sequence Sequence диаграмидиаграмиSequence Sequence диаграмидиаграми

• Използват се при Използват се при моделиране на моделиране на изискваниятаизискванията

• За по-добро описание на За по-добро описание на use case use case сценариитесценариите

• Позволяват описание на Позволяват описание на допълнителни участници допълнителни участници в процеситев процесите

• Използват се при дизайнаИзползват се при дизайна

• За описание на За описание на системните интерфейсисистемните интерфейси

• Използват се при Използват се при моделиране на моделиране на изискваниятаизискванията

• За по-добро описание на За по-добро описание на use case use case сценариитесценариите

• Позволяват описание на Позволяват описание на допълнителни участници допълнителни участници в процеситев процесите

• Използват се при дизайнаИзползват се при дизайна

• За описание на За описание на системните интерфейсисистемните интерфейси

selectZone()

pickupChange()

pickUpTicket()

insertCoins()

PassengerTicketMachine

Page 63: Introduction To Object Oriented Design and UML

Sequence Sequence диаграмидиаграмиSequence Sequence диаграмидиаграми

• КласоветеКласовете се се представят с колонипредставят с колони

• Съобщенията Съобщенията (действията) се (действията) се представят чрез представят чрез стрелкистрелки

• УчастницитеУчастниците се се представят с широки представят с широки правоъгълнициправоъгълници

• СъстояниятаСъстоянията се се представят с представят с пунктирана линияпунктирана линия

• КласоветеКласовете се се представят с колонипредставят с колони

• Съобщенията Съобщенията (действията) се (действията) се представят чрез представят чрез стрелкистрелки

• УчастницитеУчастниците се се представят с широки представят с широки правоъгълнициправоъгълници

• СъстояниятаСъстоянията се се представят с представят с пунктирана линияпунктирана линия

selectZone()

pickupChange()

pickUpTicket()

insertCoins()

PassengerTicketMachine

Page 64: Introduction To Object Oriented Design and UML

СъобщенияСъобщенияСъобщенияСъобщения

• Посоката на стрелката определя изпращача Посоката на стрелката определя изпращача и получателя на съобщениетои получателя на съобщението

• Хоризонталните прекъснати линии Хоризонталните прекъснати линии изобразяват потока на даннитеизобразяват потока на данните

• Посоката на стрелката определя изпращача Посоката на стрелката определя изпращача и получателя на съобщениетои получателя на съобщението

• Хоризонталните прекъснати линии Хоризонталните прекъснати линии изобразяват потока на даннитеизобразяват потока на данните

selectZone()

PassengerZoneButton TarifSchedule Display

lookupPrice(selection)

displayPrice(price)

price

Dataflow

Page 65: Introduction To Object Oriented Design and UML

Итерация и условияИтерация и условияИтерация и условияИтерация и условия

• Итерацията се означава с * преди Итерацията се означава с * преди съобщениетосъобщението

• Условията се означават с булев израз вУсловията се означават с булев израз в [ ] [ ]

• Итерацията се означава с * преди Итерацията се означава с * преди съобщениетосъобщението

• Условията се означават с булев израз вУсловията се означават с булев израз в [ ] [ ]

PassengerChangeProcessor

insertChange(coin)

CoinIdentifier Display CoinDrop

displayPrice(owedAmount)

lookupCoin(coin)

price

[owedAmount<0] returnChange(-owedAmount)

Iteration

Condition

*

Page 66: Introduction To Object Oriented Design and UML

State Chart State Chart диаграмидиаграмиState Chart State Chart диаграмидиаграми

BlinkHours

BlinkMinutes

IncrementHrs

IncrementMin.

BlinkSeconds IncrementSec.

StopBlinking

[button1&2Pressed]

[button1Pressed]

[button2Pressed]

[button2Pressed]

[button2Pressed]

[button1Pressed]

[button1&2Pressed]

[button1&2Pressed]

• Описват поведението чрез състояния и преходи между тях

• Описват поведението чрез състояния и преходи между тях

State

Initial state

Final state

Transition

Event

Page 67: Introduction To Object Oriented Design and UML

Activity Activity диаграмидиаграмиActivity Activity диаграмидиаграми

• Показват потока на действията в Показват потока на действията в систематасистемата

• Представляват специален тип Представляват специален тип statechart statechart диаграми, при които диаграми, при които състоянията са действиясъстоянията са действия

• Показват потока на действията в Показват потока на действията в систематасистемата

• Представляват специален тип Представляват специален тип statechart statechart диаграми, при които диаграми, при които състоянията са действиясъстоянията са действия

HandleIncident

DocumentIncident

ArchiveIncident

Page 68: Introduction To Object Oriented Design and UML

Activity Activity диаграми: диаграми: моделиране на условиямоделиране на условияActivity Activity диаграми: диаграми: моделиране на условиямоделиране на условия

OpenIncident

NotifyPolice Chief

NotifyFire Chief

AllocateResources

[fire & highPriority]

[not fire & highPriority]

[lowPriority]

Condition

Page 69: Introduction To Object Oriented Design and UML

Activity Activity диаграми: диаграми: моделиране на паралелизъммоделиране на паралелизъмActivity Activity диаграми: диаграми: моделиране на паралелизъммоделиране на паралелизъм

• Синхронизация на действияСинхронизация на действия

• Разделяне на работата на няколко Разделяне на работата на няколко нишки (нишки (threads)threads)

• Синхронизация на действияСинхронизация на действия

• Разделяне на работата на няколко Разделяне на работата на няколко нишки (нишки (threads)threads)

OpenIncident

AllocateResources

CoordinateResources

DocumentIncident

ArchiveIncident

SynchronizationSplitting

Page 70: Introduction To Object Oriented Design and UML

• Зависи от проектаЗависи от проекта

• Forward Engineering:Forward Engineering:

• Генерираме код по Генерираме код по UML UML моделамодела

• Reverse Engineering:Reverse Engineering:

• Генерираме Генерираме UML UML модел по кодамодел по кода

• При преработка на съществуващи При преработка на съществуващи проектипроекти

• Roundtrip Engineering:Roundtrip Engineering:

• Комбинация между дветеКомбинация между двете

• Зависи от проектаЗависи от проекта

• Forward Engineering:Forward Engineering:

• Генерираме код по Генерираме код по UML UML моделамодела

• Reverse Engineering:Reverse Engineering:

• Генерираме Генерираме UML UML модел по кодамодел по кода

• При преработка на съществуващи При преработка на съществуващи проектипроекти

• Roundtrip Engineering:Roundtrip Engineering:

• Комбинация между дветеКомбинация между двете

Първо правим модела или Първо правим модела или пишем кода?пишем кода?Първо правим модела или Първо правим модела или пишем кода?пишем кода?

Page 71: Introduction To Object Oriented Design and UML

UMLUML – обобщение – обобщениеUMLUML – обобщение – обобщение

• UML UML предоставя съвкупност от предоставя съвкупност от нотации за описание на различни нотации за описание на различни аспекти на софтуерните проектиаспекти на софтуерните проекти

• Мощен, но сложен езикМощен, но сложен език

• При неправилна употреба носи повече При неправилна употреба носи повече объркване, отколко яснотаобъркване, отколко яснота

• Да се ползва ако наистина има смисълДа се ползва ако наистина има смисъл

• Да не се прекалява с екзотични Да не се прекалява с екзотични нотации – те са непонятнинотации – те са непонятни

• UML UML предоставя съвкупност от предоставя съвкупност от нотации за описание на различни нотации за описание на различни аспекти на софтуерните проектиаспекти на софтуерните проекти

• Мощен, но сложен езикМощен, но сложен език

• При неправилна употреба носи повече При неправилна употреба носи повече объркване, отколко яснотаобъркване, отколко яснота

• Да се ползва ако наистина има смисълДа се ползва ако наистина има смисъл

• Да не се прекалява с екзотични Да не се прекалява с екзотични нотации – те са непонятнинотации – те са непонятни

Page 72: Introduction To Object Oriented Design and UML

UMLUML – обобщение – обобщениеUMLUML – обобщение – обобщение

• Модели на софтуерните системиМодели на софтуерните системи

• Функционален модел:Функционален модел:

• Use case Use case диаграмидиаграми

• Обектен модел:Обектен модел:

• Class Class диаграмидиаграми

• Динамичен моделДинамичен модел::

• Sequence Sequence диаграмидиаграми

• StatechartStatechart диаграми диаграми

• Activity Activity диаграмидиаграми

• Модели на софтуерните системиМодели на софтуерните системи

• Функционален модел:Функционален модел:

• Use case Use case диаграмидиаграми

• Обектен модел:Обектен модел:

• Class Class диаграмидиаграми

• Динамичен моделДинамичен модел::

• Sequence Sequence диаграмидиаграми

• StatechartStatechart диаграми диаграми

• Activity Activity диаграмидиаграми

Page 73: Introduction To Object Oriented Design and UML

Въпроси?Въпроси?Въпроси?Въпроси?

Обектно-ориентиранОбектно-ориентирандизайн и дизайн и UMLUMLОбектно-ориентиранОбектно-ориентирандизайн и дизайн и UMLUML

http://patterns.dev.bghttp://patterns.dev.bg