Блог за програмиране на Delphi, UML моделиране в Delphi
Ефективното UML моделиране опростява процеса на разработване на вашите проекти. Тясната интеграция на средата и инструментите за моделиране улеснява трансформирането на модела в изходен код. Основната цел на UML моделирането е да организира и представи структурата и компонентите на софтуерните системи, разработени в стила на ООП. Моделите се използват за визуално представяне на изисквания, подсистеми, логически и физически елементи, блокови диаграми и модели на поведение (модели). В Delphi изградените UML модели се синхронизират автоматично с изходния код. UML диаграмите са проектирани с помощта на концепциите за пакети, интерфейси, класове, атрибути (свойства) и операции.
UML моделът не само представя цялата система, но също така ви позволява да се съсредоточите върху нейната структура и поведение. Този инструментариум предоставя функциите, необходими за проектиране и изграждане на обектно-ориентирани системи, позволявайки на целия екип за разработка (архитекти, разработчици, тестери, мениджъри, лидери) да използват общ език, независимо от използвания език за програмиране, опростявайки обсъждането на проекта и неговото развитие.
Разбира се, без постоянна взаимна синхронизация на модела и кода, подобен инструмент не би бил особено полезен/удобен. Както споменахме по-горе, инструментите за моделиране са вградени в IDE (в зависимост от версията на продукта, разбира се, всичко е във версията Architect). Когато активирате поддръжка за моделиране за проект (Проект->Поддръжка за моделиране), към структурата на проекта се добавя директория за модела. Активиран е разделът Model View, който показва структурата и йерархията на модулите / класовете на проекта, както и Diagram View, който показва диаграмите, създадени за проекта. Тези два прозореца позволяватизвършване на достатъчно голям брой действия: създаване и изтриване на диаграми, създаване, изтриване или преименуване на елементи на диаграма (възли и връзки), добавяне / изтриване на членове за елементи на диаграма; създаване на диаграми за различни дизайнерски модели (singletons, factories и т.н.), експортиране на диаграми в изображения, генериране на кодова документация. За мен последните две точки са много важни.
В допълнение към тези прозорци е разширена функционалността на Инспектора на обекти, където можете да промените свойствата на диаграмите. В режима за редактиране на диаграма иконите, специфични за този тип диаграма, се появяват в палитрата с инструменти. Менюто на проекта се допълва с различни специфични команди.
Като цяло инструментите за моделиране ви позволяват да създавате различни видове UML диаграми, независимо от Delphi или C++. Диаграмите се синхронизират с кода и в двете посоки, така че промените в диаграмата ще засегнат кода и промените в кода се отразяват в диаграмите. Според диаграмите може да се генерира изходен код за класове и можете да използвате различни шаблони за проектиране. Когато моделирането е активирано, използването на одити и показатели става достъпно. Моделите могат да бъдат импортирани от форматите на IBM Rational Rose и XMI (т.е. можете да импортирате модел на проект, разработен в друг пакет за проектиране, и да изградите изходния код на вашия проект от него). С поддръжката на моделиране е налична функцията за автоматично генериране на документация към изходния код в HTML формат. Можете да придружавате диаграми с бележки и изображения, да ги оцветявате по всякакъв начин и да използвате OCL ограничения [още не знам :)]
UML е с версии, инструментите за моделиране на Delphi позволяват използването на UML 1.5 и UML 2.0. НомерВерсията, която използвате, зависи от типа на проекта. В контекста на моделирането има два типа проекти: проект за внедряване на източник и проект за архитектура. Първият случай е познат проект с изходен код, в който е активирана поддръжка за симулация. Вторият тип проект (дизайн проект) е предназначен за изграждане на архитектурата/дизайна на системата или нейните компоненти. За да създадете такъв проект, изберете File - New - Other - Design Projects. За проекти за внедряване е наличен UML 1.5, а за дизайнерски проекти можете да избирате между UML 1.5 и UML 2.0. В зависимост от версията на UML, която изберете, броят на поддържаните типове диаграми и елементи на диаграма може да варира.
Моделирането използва термините пакет и пространство от имена. Най-общо казано, тези термини са синоними. Въпреки това, терминът "пакет" се отнася конкретно за дизайна, а "пространство от имена" до изпълнението под формата на изходен код. Когато поддръжката за симулация е активирана, се създава пакет с име default. Ако има други пакети, те могат да бъдат показани на специална пакетна диаграма, която показва самите пакети и елементите, които съдържат. Всеки клас може да се съдържа само в един пакет и да има уникално име в него. Различните пакети обаче могат да съдържат класове с еднакви имена.
Диаграмите представляват граф от възли и връзки между тях. Всяка диаграма има тип. Съответно за всяка диаграма възлите и връзките имат свое собствено значение / значение. Например, класова диаграма съдържа класовете на пакет и връзките между тях, връзките в този случай могат да определят наследяването. Диаграмите и техните елементи имат свойства. В допълнение към стандартните свойства е възможно да се създават персонализирани свойства. За да направите това, е необходимо диаграмата или нейният елемент да влезеизберете Потребителски свойства от контекстното меню. Свойствата са двойка име=стойност и се показват в инспектора на обекти, когато се добавят.
За проекти с внедряване, синхронизирането на модела и изходния код заема важно място в инструментариума за моделиране. От една страна е възможно да се изградят диаграми за съществуващ код, от друга страна, можете да изградите обща диаграма на класа и след това да генерирате изходен код за нея. Всички промени, направени в изходния код или в диаграмата, веднага се показват "от другата страна". Тук има едно „но“: за да преименувате класове, трябва да използвате подходящите инструменти за рефакторинг, а не просто да го преименувате ръчно в изходния код.
класови диаграми
Диаграмите на класове са вид UML диаграма, която описва структурата на вашия проект по отношение на пространства от имена, класове и интерфейси, техните атрибути, свойства и методи. Диаграмата също така представя връзката между тези елементи. Всички промени в класовата диаграма се отразяват незабавно в изходния код.
Обобщение (генерализация) е една от UML терминологията, използвана за обозначаване на наследяването на класове. При изграждане на модел от изходния код, такива връзки се създават автоматично. В диаграмата връзката на наследяване се показва като плътна линия със стрелка (без запълване, празна) от детето към родителя. Релациите "Реализация на интерфейс " (също UML термин) се показват в диаграмата по същия начин, но линията не е плътна, а пунктирана. Ако можем да имаме само един клас като наследник (тъй като нямаме множествено наследяване), тогава класът може да има само една стрелка за наследяване. Но, разбира се, може да има няколко връзки за внедряване на интерфейс. И всички те са в класациятасе показват.Асоциацията е вид връзка между два класа, когато първият клас съдържа връзка към друг (атрибут или свойство). В диаграмата членовете на структурните типове данни са разделени на 4 групи: класове (вложени типове), методи, свойства, полета.
По-долу е диаграма на класове, която създадох в празен конзолен проект за демонстрационни цели.
Както можете да видите вдясно, разделът ModelView е отворен и представлява дървовидната структура. Проектът се нарича uml и първоначално беше празен (т.е. 1 dpr файл). След като активирах поддръжката за моделиране, превключих на раздела Изглед на модела. Като избрах горния uml възел и използвах контекстното меню, добавих пакета uTest. На ниво изходен код това означава добавяне на uTest.pas към проекта. Лентата с инструменти съдържа специфични за диаграмата елементи. Използвайки диаграмата, създадох 2 интерфейса ITest и ITest2, като родителският клас TCustomTest поддържа и двата интерфейса. Можете да укажете поддръжка на интерфейс или с помощта на Object Inspector, като попълните полетоinherites или като щракнете върху самата диаграма. Родителският клас за TCustomTest е автоматично зададен на TInterfacedObject. След това добавих дъщерен клас TTest, в резултат на което съответната връзка беше показана на диаграмата. След това въведох класа TItem и структурата TTestStruct и създадох съответните полета в класа TTest. Връзките за асоцииране са показани на диаграмата. TMyAttribute е rtti атрибут, който наследява от класа TCustomAttribute. Класът TTest беше маркиран с този атрибут, но не беше намерен в диаграмата на класовете за картографиране (Delphi 2010, трябва да се провери в XE2), вероятно няма такива връзки в самия UML 1.5.
Друга функция е много удобна. Елементът на диаграмата и съответният клас могат да имат различни имена. Или по-скоро, ако името на класа ени е даден, например, TItem, след което на диаграмата можем да го покажем по различен начин, например "Element", за това е необходимо да попълните свойството Alias . По този начин полето Име в инспектора на обекти, когато е избран клас, означава действителното име на класа, а стойността на полето Псевдоним се показва в диаграмата. Това ни дава възможност да подписваме обекти на диаграмата на нашия роден език, което улеснява работата по проекта за всички участници в процеса.