Обектно-ориентирано проектиране: определение, принципи и примери

Обектно-ориентираното проектиране е процес на планиране на система от взаимодействащи си обекти с цел решаване на софтуерен проблем. Това е един от подходите към дизайна на обезпеченията.

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

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

Теми на дизайна

Входните данни за обектно-ориентираното проектиране се осигуряват от резултатите от анализа. Трябва да се разбере, че не е задължително артефактът да е напълно разработен, за да служи като отправна точка. Анализът и проектирането могат да се извършват паралелно. На практика резултатите от едно действие могат да се включат в друго в кратък цикъл на обратна връзка чрез итеративен процес. Както първото, така и второто действие могат да се извършват на етапи, артефактите могат да се натрупват непрекъснато, а не да се разработват изцяло наведнъж.

Някои типични елементи

Разгледайте най-важните.

1. Концептуален модел.

Резултатите от обектно-ориентирания анализ и проектиране са обхванати от концепцията в предметната област. Концептуалният модел е изрично избран да бъде независим от детайлите на изпълнението, като паралелизъм или съхранение на данни.

2. Случай на употреба.

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

Изпълнителите на прецедента могат да бъдат крайни потребители или други системи. В много случаи случаите на използване се доразвиват под формата на диаграми. Прецедентните диаграми се използват за идентифициране на участниците и процесите, които те изпълняват. Прочетете повече в книгата на Грейди Бух "Обектно-ориентиран дизайн".

3. Диаграма на последователността на системата.

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

4. Документация за потребителския интерфейс.

Документ, който показва и описва външния вид на крайния продукт. Този елемент не е задължителен, но помага за визуализацията му, което улеснява дизайнера.

Релационен модел на данните

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

Възможно е обаче моделът на релационни данни да се разработва паралелно, а нарастването на артефакта може да стимулира усъвършенстването на други компоненти. Можете да прочетете повече за това в книгата на Бух "Обектно-ориентиран анализ и проектиране". Имайте предвид, че в новото издание на Grady Booch ще намерите множество практически съвети, свързани с анализ, внедряване, проектиране и управление на проекти.

Концепции

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

1. Клас на обект.

Какво представлява? Класът е тясно свързана или свързана структура от данни с методи или функции, които им въздействат (от него се създава обект). Всеки елемент има определена функция. Тя се определя от нейните свойства. Един обект може да бъде част от клас, който представлява набор от подобни обекти.

2. Скриването на обектно-ориентираното проектиране на информационни системи е способността да се защитят определени компоненти от външни влияния.

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

Това е способността на даден клас да разширява или заменя функционалността на друга група. Така нареченият подклас има цял раздел, който е производен (наследен) от суперклас и също така има свой собствен набор от функции и данни.

4. Интерфейс (Сред техниките на обектно-ориентираното проектиране съществуват т.нар. шаблони. Абстрактният интерфейс на фабриката е един от тях).

Възможност за отлагане на прилагането на методите и възможност за дефиниране на функции, без да се прилагат.

5. Полиморфизъм (особено подтип) - възможност за замяна на обект с негови подобекти. А също и способността на един променлив обект да съдържа не само този обект, но и всички негови компоненти.

Разработване на концепция

Дефинирането на обекти, създаването на диаграма на класовете от концептуална форма обикновено показва същността.

Идентификация на атрибута.

Трябва да използвате шаблони от гамата на обектно-ориентираните техники за проектиране. Това не е завършен продукт, а описание на решението на общ проблем в контекста на. Основен полза от използването на на шаблона за проектиране е, че той може да се използва повторно в множество приложения. Разглежда се и за решаване на проблеми, Което може да се случи в много различни ситуации. Обектно-ориентираните шаблони за проектиране на Gamma обикновено показват връзките и взаимодействията между класове или обекти, без да се уточняват крайните системи за приложение или участващите обекти.

Определяне на структурата.

Обикновено това е набор от библиотеки или класове, които се използват за реализиране на стандартна рамка за приложения за определен операционна система. Чрез обединяването на голямо количество код за многократна употреба в една платформа разработчикът спестява много време, като решава проблема с пренаписването на голямо количество стандартен код за всяко ново приложение, което трябва да се разработи.

Изходът (резултатите) на обектно-ориентираното проектиране

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

Диаграма на класовете - е тип Статична UML структура, която описва системите, показвайки техните атрибути и връзките между тях. Съобщенията и класовете, идентифицирани чрез разработването на диаграми на последователността, могат да послужат като входни данни за автоматичен генериране на глобална система.

Някои принципи и стратегии за проектиране

Често използване на прилагането на зависимости. Каква е основната идея? Ако даден обект зависи от съществуването на друг, то необходимият обект е вграден в зависимия. Пример за обектно-ориентиран дизайн: подаване на връзка към база данни като аргумент към конструктора, вместо да я създавате вътрешно. Друг пример за използване на модела "мост": отделяне на абстракция от нейната реализация, така че и двете да могат да се променят независимо.

Разгледайте принципите на обектно-ориентирания дизайн на ацикличните зависимости. Обърнете внимание, че графът на компонентите (степента на детайлност зависи от обхвата на работата) не трябва да има цикли. Този граф се нарича още насочен ацикличен граф. Пример за обектно-ориентиран анализ и проектиране: да предположим, че C зависи от B, който е обект на A. Ако последният също е свързан с C, тогава ще има цикъл.

Какъв е принципът на повторната употреба на композитни материали? Предпочита се полиморфен състав на наследяването. След фазата на анализ концептуалният модел се доразвива в обектно-ориентиран проект на ИС. Тук технологично независимите концепции за анализ се съпоставят с класовете за изпълнение, определят се ограниченията и се проектират интерфейси, в резултат на което се създава модел за областта на решението.

Етапите на проектиране на обектно-ориентирани ИС могат да се определят по следния начин:

• Намиране на контекста на системата.
• Проектиране на неговата архитектура.
• Идентифициране на обекти в системата.
• Разпределения на дизайна на сградата.
• Спецификация на интерфейсите на обектите.
• Дизайн.

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

Първата концепция

Системният контекст има статична и динамична част. Първата е създадена чрез обектно-ориентирано проектиране с помощта на проста блок-схема, която се разширява в йерархия от подсистеми. Този модел е представен чрез UML пакети. Динамичният контекст описва начина, по който системата взаимодейства със средата. Тя се моделира с помощта на диаграми на случаите на употреба.

Архитектурата на системата се проектира въз основа на контекста и в съответствие с принципите на проектиране и предметната област. По принцип системата се декомпозира на слоеве, които се оформят като подсистеми.

Какво представлява обектно-ориентираната декомпозиция? Декомпозиция означава разделяне на голяма сложна система на йерархия от по-малки компоненти с по-малка сложност. Всяка основна част се нарича подсистема. Обектно-ориентираната декомпозиция идентифицира отделните автономни обекти в системата и връзките между тях.

Предимства на разлагането:

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

Идентифициране на паралелизъм

Тя позволява на няколко обекта да получават събития и да извършват множество действия едновременно. Паралелизмът се идентифицира и представя в динамичен модел.

За да се активира, за всеки паралелен елемент се задава отделен поток за управление. Ако паралелизмът е на ниво обект, тогава на два симетрични обекта се задават два различни потока за управление. Ако две операции на една от тях са паралелни по характер, те се разпределят между различни нишки.

Паралелизмът е свързан с проблеми, свързани с целостта на данните и взаимосвързаността. Това означава, че трябва да се разработи ясна стратегия, когато се изисква едновременност. Освен това тя трябва да бъде идентифицирана още на етапа на проектиране и не може да бъде оставена на етапа на изпълнение.

Обектно-ориентирани техники за проектиране, шаблони за проектиране

При разработването на приложения се приемат някои общи решения за определени категории проблеми. Това са например шаблони за проектиране. Тя може да се определи като документиран набор от градивни елементи, които могат да се използват при определени видове задачи за разработване на приложения.

Някои често срещани техники за обектно-ориентирано проектиране (шаблони за проектиране) могат да бъдат открити в шаблоните за проектиране:

• Модел на фасадата.
• Модел за разделен изглед.
• Образец на наблюдател.
• Модел на контролер на тип модел.
• Шаблон на прокси.
• Управление на събития.

По време на проектирането на обектно-ориентирана система трябва да се идентифицират и съответно да се обработват събития, които могат да възникнат в обектите.

Събитието е спецификация на значимо събитие, което има местоположение в време и пространство. Могат да се моделират четири вида, а именно:

• Сигнализиране - обект с име, пуснат от един и уловен от друг.
• Събитие за повикване е синхронно събитие, което представлява изпращане на операция.
• Процесът на времето е представен в хода на времето.
• Събитие за промяна - събитие, което представлява промяна на състояние.

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

На етапа на проектиране трябва да се разгледа инициализацията и прекратяването на системата като цяло, както и на всяка подсистема. Различни аспекти:

• Стартиране, t. е. преход от неинициализирано състояние към стабилно състояние.
• Завършване на системата, t. е. Затваряне на всички работещи нишки, изчистване на ресурсите и изпращане на съобщения.
• Първоначално конфигуриране и при необходимост повторно конфигуриране.
• Предвиждане на повреди или нежелани спирания на системата.
• Граничните условия се моделират, като се използват подобни случаи на употреба.

Дизайн на обекта

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

Проектирането на обекти включва следните стъпки:

• Идентификация.
• Представителство. Изграждане на модели за проектиране.
• Класификация на операциите.
• Алгоритъм за проектиране.
• Дизайн на взаимоотношенията.
• Осъществяване на контрол на външните взаимодействия.
• Пакетиране на класове и асоциации в модули.

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

Това е първият етап от проектирането. Обектите, идентифицирани по време на обектно-ориентирания анализ, се групират в класове и се усъвършенстват, така че да са подходящи за реално изпълнение.

Функциите на този етап:

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

Представяне на обекти

След като класовете са идентифицирани, те трябва да бъдат показани с помощта на техники за моделиране. Тази стъпка по същество включва изграждането на UML диаграми.

Съществуват два вида модели за проектиране, които трябва да бъдат изработени:

Статичен. За описанието му се използват диаграми на класовете и обектите.

Динамични модели. За да се опишат и покажат връзките между класовете, се използват диаграми на взаимодействието и диаграми на състоянието.

Класификация на операциите

На този етап задачите, изпълнявани върху обекти, се определят чрез комбиниране на три модела: предметен, динамичен и функционален. Операцията е дефинирана, които следва да да се направи, а не как.

Във връзка с това трябва да се изпълнят следните задачи:

• Разработва се диаграма на прехода между състоянията на всеки обект в системата.
• Операциите се дефинират за събития, получени от обектите.
• Установяват се случаи, при които едно действие предизвиква други в същия или различен обект.
• Идентифицират се подоперациите в действията.
• Основните действия се разширяват до диаграми на потока от данни.

Проектиране на алгоритъм

Операциите в обектите се определят от поредица от. Алгоритъмът е поетапна процедура, която решава проблем, заложен в дадена операция. Фокусират се върху това как трябва да се работи.

Може да има повече от един алгоритъм, съответстващ на операцията. След като бъдат идентифицирани алтернативни последователности, се избира оптималната за проблемната област. Показатели за избор на алгоритъм:

• Сложност на броенето. Той определя ефективността на алгоритъма от гледна точка на времето за изчисление и изискванията за памет.
• Гъвкавост. Тази концепция определя дали избраният алгоритъм може да се приложи правилно и без загуба на съгласуваност в различни среди.
• Яснота. Показва дали избраният алгоритъм е лесен за разбиране и прилагане.

Дизайн на взаимоотношенията

Тази стратегия трябва да бъде записана на етапа на проектиране на сайта. Основните връзки включват асоциации, агрегации и наследяване.

Що се отнася до асоциациите, дизайнерът трябва да направи следното:

• Определете дали връзката е еднопосочна или двупосочна.
• Анализирайте пътищата на асоцииране и ги актуализирайте, ако е необходимо.

По отношение на наследяването планиращият трябва да направи следното:

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

Изпълнение на контрола

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

Подходи за прилагане на динамичен модел:

1. Представяне на състояние като местоположение в програма.

Това е традиционният подход, основан на процедури, при което местоположението на управляващия елемент определя състоянието. Машината с краен брой състояния може да се реализира под формата на програма. Преходът формира входния оператор, основният път за управление създава последователност от инструкции, разклоненията създават условия, а пътищата за връщане формират цикли или итерации.

2. Механизъм на краен автомат.

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

3. Управление - едновременни задачи.

При този подход обектът се реализира като въпрос на език за програмиране или операционна система. Тук събитието е реализирано като повикване между задачите, като се запазва присъщият паралелизъм на обектите от реалния свят.

Класове опаковки

При всеки голям проект е важно внимателно да се раздели изпълнението на модули или пакети. Класовете се групират заедно при създаването на обекти, което позволява на няколко общества да работят заедно.

Различни аспекти на опаковането:

1. Скриване на вътрешна информация от външен поглед. Това позволява класът да се третира като черна кутия и да се променя реализацията му, без да се налага клиентите да променят кода.

2. Съгласуваност на елементите. Една част (например клас, операция или модул) е свързана, ако е организирана по съгласуван план и всички нейни части са неделими, т.е. служат за обща цел.

Основи на конструирането на физически модули:

1. Класовете трябва да представят сходни неща или компоненти в един и същ съставен обект.

2. Тясно свързаните класове трябва да бъдат в един модул, докато несвързаните или слабо групираните класове трябва да бъдат поставени в отделни части.

3. Модулите трябва да имат високо ниво на взаимодействие между своите компоненти.

Оптимизиране на дизайна

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

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

Различни неща, които можете да направите, за да го подобрите:

• Добавяне на излишни асоциации.
• Изпускане на неизползвани асоциации.
• Оптимизиране на алгоритмите.
• Запазване на производни атрибути, за да се избегне преизчисляването на сложни изрази.

Нека разгледаме някои елементи по-подробно.

Добавяне на излишни асоциации.

По време на процеса на оптимизация се проверява дали създаването на нови асоциации може да намали разходите за достъп. Макар че тези излишни асоциации може да не добавят никаква информация, те могат да повишат ефективността на цялостния модел.

Премахване на неизползвани асоциации.

Наличието на твърде много асоциации може да направи системата неразбираема и да намали общата ефективност. Това означава, че по време на оптимизацията се премахват всички неизползвани асоциации.

Подобряване на алгоритмите.

В обектно-ориентираните системи структурата на данните се оптимизира по съвместен начин. След като проектът на класа е създаден, операциите и алгоритмите трябва да бъдат подобрени.

Оптимизацията се постига чрез:

• Пренареждане на реда на изчислителните задачи.
• Промени в последователността на циклите.
• Премахване на мъртви пътища в алгоритъма.
• Запазване на производните атрибути.