Сравнителен анализ на случайните средства
ЧАСТ 2.Рационалният розов модел
„Rational е не само ценен софтуерен продукт, но и 3-4 килограма лесно смилаема документация“
Контекстната диаграма тук ще бъде заменена отдиаграма на прецедентили диаграма на случай на използване (фиг. 1). Той определя -каквоще направи системата (вместокакще го направи).
Какво отразява? Той отразява основните прецеденти. Те се наричат още сценарии, случаи на използване.
Употребитеопределят функционалността на системата. Всеки от тях представлява специфичен начин за използване на системата. По този начин всеки случай на използване съответства на последователност от действия, извършвани от системата, така че клиентът да може да получи определен резултат. Тук прецедентите са: Консултация, Сключване на застрахователен договор, Изплащане на застрахователно обезщетение.
Това означава, че клиентът е инициатор на даден процес, а застрахователната агенция е негов изпълнител.
Клиент и застрахователна агенция сакласове. UML, за удобство при групиране на класове според тяхното предназначение, ви позволява да им присвоитестереотип, а Rose прави възможно показването им графично. И така, клиентът има стереотип за бизнес актьор (бизнес - актьор). Установява се асоциация между актьора и случая на използване, която се наричаасоциация.
Диаграмата на случаи на използване е по същество модел на функция на домейн. Той отразява външните връзки на системата.Това е поглед към системата отвън, от гледна точка на клиента.
Тази диаграма вече предполага, че е необходимо да се дефинират и класифицират основните обекти. Ще направим това с помощта на класова диаграма, на която ще покажемБизнес работници( Бизнес работник ). Те са свързаниасоциации и обобщения.
Асоциациясе показва като обикновена стрелка и означава, че служител на агенция - работи за застрахователната агенция.Обобщениесе показва с триъгълна стрелка и означава, че Консултантът, Застрахователят, Касиерът и др. са служители на агенцията. Това е много полезно, защото позволява в някои случаи да се опише конкретна роля, а когато това не се изисква, да се използва обобщена концепция (вместо да се нарисуват всички). Тъй като всички те са служители на агенцията, те споделят някои общи характеристики. Но всеки от тях има свои собствени характеристики. Може също така да се отрази, че Служителят на агенцията може да бъде мъж или жена, а те от своя страна са хора. Но би било излишно, т. к. надхвърля нашия модел. (Освен ако, разбира се, няма да разгледаме автоматизацията на тоалетните :).
Клиентът от своя страна може да бъде юридическо или физическо лице (фиг. 3).
Досега сме отразявали само едната страна на бизнес процесите въз основа на случая на използване. Други диаграми могат да се използват за допълнително усъвършенстване на процесите.
Един прецедент може да описва няколко сценария (последователности).
Сценарийе някаква последователност от действия, илюстриращи поведението на системата. Описва се отдиаграми на дейността( Дейност ). Диаграма на дейност в модел на случай на бизнес употреба илюстрира работния процес на случай на бизнес употреба.
Така че диаграмата на действие, описваща случая на използване на Consult, ще изглежда така (фиг. 4).
Всичко тук е приблизително същото като в модела BPWin. Диаграмата на активността по същество е съвместима с IDEF3.
Когато клиент се свърже (точка на започване), консултантът търси информация и докладва отговораклиент. Е, няма да разглеждаме случая, когато няма отговор. Въпреки че трябва!
Тази диаграма използва Swim Lines, за да посочи кой е отговорен за дадена стъпка на процеса. Това, между другото, също го има в BPWin.
При изграждането на диаграма веднага възниква въпросът: какво е необходимо за намиране на информация? Според нашия модел това е законодателство и инструкции. Това означава, че е необходимо да се създадат съответни класове и обекти. Нека направим това на диаграма, която ще наречем "Документи".
Общото описание на документите може да бъде представено в следната форма.
Документите на агенцията могат да бъдат разделени на външни, които идват от други организации, и вътрешни, които се произвеждат в самата агенция. Вътрешните документи са оцветени в жълто.
По подобен начин ще изградим диаграма на клиентски документи (фиг. 7).
Можете, разбира се, да продължите с подробностите: разделете инструкциите на вътрешни и от родителската организация. След това избройте конкретни инструкции с числа. Така че, между другото, трябва да се направи в истински модел. С по-нататъшно разработване атрибутите и операциите могат да бъдат посочени в свойствата на всеки документ.Атрибути на класа- отразяват състоянието на обекта или неговите данни.Операции на класа, това е изпълнението на услуга, която може да бъде поискана от всеки обект на класа. Това е, коетоможе да прави с обект.
Дори в Rose има добра възможност за асоцииране на обект с конкретен файл с документи. Въвеждане на свойствата на обекта, можете да извикате този документ.
Сега е време да помислим за организационната структура на агенцията. Нека го изведем на прецедентната диаграма (фиг. 8).
Той гласи следното. Застрахователната агенция включва: ръководителя, договорния отдел, отдела за застрахователни плащания,Разгледайте. Застрахователят и консултантът са служители на договорния отдел. Инспекторът е служител на отдела за осигурителни плащания.
Сега да продължим и да опишем прилагането на прецедента „Сключване на застрахователен договор“.
В този процес участват; клиент, застраховател, касиер и шеф. Входните данни са документите на клиента. Уикенд - застрахователна полица. Бих искал да обърна внимание на факта, че в диаграмата на активността няма класове, а обекти.Objectкапсулира данните и поведението на клас. Данните на даден обект се представят чрез атрибути, а поведението му се представя чрез операции. Обектът е дефиниран в клас. Е, това е много научно, отказах го. Просто казано, обектът е конкретна реализация на клас. Например, в този случай това е конкретна застрахователна полица, издадена на конкретен клиент.
По принцип клиентът може да бъде изключен. Изходният документ е маркиран в зелено. Можете да поставите документи тук, като първо създадете обект и след това плъзнете желания клас върху него.
Диаграмата на изпълнение на прецедента "Изплащане на застрахователно обезщетение" ще има следния вид (фиг. 10).
Тук се прави без Swim line, което не е забранено. Прекъснатите стрелки показват потоци от обекти (данни).
И така, какви могат да бъдат отбелязанинедостатъцитена продукта Rational Rose:
- не можете да показвате и изтривате неизползвани обекти за разлика от BPWin;
- недостатъчно функционална графика (не можете да промените дебелината на линиите, надписите не са центрирани, текстът не винаги може да бъде поставен изцяло, понякога е отрязан);
Но всичко това са дреболии! Какво фундаментално липсва на Роуз? И в него нямавъзможност за показване на потоци от данни между обекти или процеси. UML е друга методология, която използва обектно-ориентиран подход, а такива диаграми не сапредоставени. И те много липсват на първоначалното ниво на дизайн!
Но има много другизаслуги:
- много по-лесно класифициране на обекти, Роуз цели това;
- възможност за добавяне на нови нива под формата на пакети (папки);
- Лесно плъзгане и пускане на обекти от един пакет в друг;
- има възможност за прикачване на документи към обекти.
И така, в тази работа извършихмемоделиране на домейн, което включва:
1. Модел на функциите на предметната област (Business Use case model) - Фиг.1, 4, 9, 10;
2. Модел на обекти от предметната област (Business object model) - Фиг.2, 3, 5-8;
3. Спецификации, описващи производствения процес - това не сме направили;
4. Речник на термините от предметната област - добре, това е общо взето ясно.
Направихме само първата стъпка - началото на изграждането на модел на системата. Следващите стъпки трябва да бъдат:
-Моделиране на внедряването на системата(Use case model). Целта е да се определят функциите на създаваната автоматизирана система.
-Определяне на изисквания( Изисквания ). Целта е да се определи какво трябва да прави системата, да се съгласува с клиента и да се документира. Основният резултат от фазата на дефиниране на системните изисквания е:
1. Модел на системните функции ( Use case model ), т.е. всъщност описание на функциите, които трябва да бъдат автоматизирани.
2. Прототип на потребителски интерфейс ( User - Interface Prototype ).
3. Спецификации на системните функции (допълнителни спецификации).
-Анализ и дизайн.Целта е да се трансформират системните изисквания в системен дизайн. Основният резултат тук е моделът на етапа на проектиране ( Design Model ). Показва как ще бъдат функциите на систематареализирани чрез обекти и класове.
И по-нататък: разработка, тестване, внедряване. Някой ден в друга статия ще се спрем на това по-подробно. Just Rational е много голяма система. И е предназначен не само, дори не толкова за описване на бизнес процеси, а за поетапно създаване на големи автоматизирани системи от големи екипи, тяхното тестване, внедряване и поддръжка.