Единен процес на разработка на софтуер. Унифициран процес на разработка и екстремно програмиране

В съответствие с ГОСТ 34.601-90 „AS. Етапи на създаване" установява следните етапи на създаване на AIS, които от своя страна могат да бъдат разделени на етапи:

· формиране на изисквания към АИС;

· развитие на концепцията за АИС;

· техническо задание;

· идеен проект;

· технически проект;

· работна документация;

· въвеждане в експлоатация.

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

Когато се използва UML методологията за създаване на AIS софтуер и информационна поддръжка, се предлага да се изгради набор от взаимосвързани модели, които отразяват статичните и динамични свойства на бъдещата система:

· модел на случай на използване;

· модел на анализ;

· дизайн модел;

· модел на разгръщане;

· модел на реализация;

· модел за тестване.

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

Модел на анализвключва общи диаграми на класове за прилагане на случаи на употреба на логическо ниво, свързани диаграми на последователности и/или диаграми за сътрудничество и е скица на това как ще бъдат внедрени случаите на употреба на логическо ниво.

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

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

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

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

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

1.5 Компоненти на езика UML

Унифициран език за моделиране UML(Unified Modeling Language) е език за визуално моделиране, използван за специфициране, визуализиране, конфигуриране и документиране на сложни системи (включително софтуер) с помощта на обектно-ориентирана технология.

При създаването на AS в методологията UML се използват принципите на структурния системен анализ, познати от методологиите Hein/Sarson и SADT:

· поетапно развитие отгоре надолу;

· техника на диаграмиране;

· йерархия на описанията;

· строга формализация на описанието на дизайнерските решения;

· първоначално развитие на проекта на логическо ниво без детайли на техническо изпълнение;

· концептуално моделиране по отношение на предметната област, за да може клиентът да разбере дизайна на системата;

· технологична поддръжка с инструменти (CASE системи).

Може да се изследва модел на сложна система в UML, за да се получат оценени характеристики на ефективността на процесите в системата.

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

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

-статичен(структурен) – състав, структура на компонентите и техните взаимоотношения;

-динамичен(поведенчески) – описание на логиката на процесите, протичащи в системата или подлежащи на изпълнение.

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

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

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

По принцип UML е дискретен език за моделиране, т.е. той съдържа концепцията за дискретни събития и промени в състоянието. Непрекъснатите процеси се моделират приблизително чрез дискретизация.

Моделът има два аспекта: семантична информация (семантика) и визуално представяне (нотация).

Пълният състав на моделните представяния на езика UML е даден в таблица 1

Таблица 1 – Представяне на системни модели в UML.

Най-често срещаният концептуален модел на система е диаграмата на случаите на използване; тя е отправната точка за конструиране на други диаграми.

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

Връзките са обозначени с различни линии в равнината, текстът е написан вътре във фигурите и някои графични символи могат да бъдат изобразени близо до върховете и връзките. UML разширенията позволяват пространствени диаграми.

Езикът има 4 вида графични структури:

· икони (пиктограми);

· графични символи върху равнина;

· пътеки (линии);

· редове текст.

1.6 Концептуално ниво. Модел на случай на използване

Като цяло процесът на обектно-ориентирано проектиране се извършва в съответствие с основните принципи на анализа на структурните системи: проектиране отгоре надолу с изграждането на йерархия от диаграми, които постепенно ни преместват от ниво на ниво: концептуално – логическо – физическо (изпълнение)

Диаграмата от най-високо ниво се счита за тази, предложена от A. Jacobson в OOSE диаграма на случаи на използванесистеми като цяло. Именно това е първоначалното концептуално представяне на системата и е изградено с цел:

· определяне на общите граници и контекста на моделираната предметна област;

· формулира общи изисквания към функционалното поведение и интерфейса на системата;

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

Гледната точка на модела: външен потребител на системата.Диаграмата на случаи на употреба включва участници, случаи на употреба и асоциации.

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

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

Всички възможни актанти изчерпват всички възможни начини за взаимодействие на потребителя със системата (подсистема, клас). При внедряването на система актантите се въплътяват в хора и физически обекти. Едно лице или физически обект, в зависимост от начина на взаимодействие, може да представлява няколко актанти (различни роли). Например едно и също лице може да бъде оператор и администратор на база данни, продавач и купувач и т.н.

В много AS няма други актанти освен хора. Въпреки това, актантите могат да бъдат външна система, I/O устройство или таймер (обикновено се среща във вградени системи в реално време). Сред актантите в случая на употреба се откроява един главен актант(основен актьор), който инициира работа със системата. Останалите са вторични, те също участват в случая на използване, получаване на резултати и въвеждане на някои междинни данни.

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

Актантът може да бъде представен на диаграми по два начина:

3. Символ на класа (правоъгълник) с вътрешна индикация на стереотипа

4. По-стандартен: „човек“ с надпис (символ на човек)

Актантът е извън системата и вътрешната му структура не е определена. Това е източникът/получателят на съобщенията.

Клиент

Случай на употреба(прецедент, случай на използване) – абстрактно описание на класа на услугата (функции на услугата), предоставен на актанта в отговор на неговите заявки.

Услугата може да се предоставя от системата като цяло, подсистема или клас. Следователно случай на използване означава моделиране на част от функционалността или поведението на дадена система. Случаят на използване има име и означава определена последователност от действия, видими за външен източник/приемник (актант). Вътрешният начин за изпълнение на опцията е скрит и разкрит на по-ниски нива на детайлност. диаграма на сътрудничество. Като всеки клас, случаят на използване има атрибути и операции, чието изпълнение е изложено на физическия слой.

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

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

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

Диаграмата изобразява случая на използване по два начина:

1) елипса, вътре е поставено име

2) правоъгълник - като всеки клас

Клиент

Сензор

Между актанти и случаи на употреба асоциацията е единственият тип връзка. Освен това има семантика превключваща комуникация, тоест предаването на съобщение, следователно обикновено не се маркира, тъй като контекстът е ясен от актанта и нотацията на случая на употреба. Но можете да го маркирате и също да посочите множествеността на връзката:

Банков клиент

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

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

Името на асоциацията, ако има такова, трябва да е уникално. Формира се според смисъла на отношенията между съсловията, които участват в сдружението. Например „Служител работи в Ръководител на отдел завършва Компютър” и др.

Асоциациите сами по себе си са класове ( асоциация клас, клас на асоциация), той има свойства както на клас, така и на асоциация. Екземпляри от този клас са връзки, които имат не само връзки към обекти, но и стойности на атрибути (свойства).

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

Множеството връзки е посочено на полюсите.

Връзките могат да се появяват и изчезват по време на работа на системата; на полюсите на асоциацията могат да се задават ограничения и съответните предикати.

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

Асоциацията е изобразена като непрекъсната линия, свързваща границите на 2 класа, ако асоциацията н-ary, тогава се изчертава ромб (знак за агрегация):

		Много асоциации - агрегиране
	Двоична асоциация

Случаите на използване не обменят съобщения помежду си и могат да бъдат само във взаимоотношения (връзки) разширения(разшири) включване(включва) и обобщения(обобщаване).

IN относно разширението use case – клиентът въвежда допълнителна последователност от действия, започвайки от някаква точка в основната последователност, като може да има няколко такива „вмъквания“. Всички тези точки се наричат точки на разширение.

Rational Unified Process (RUP) е една от най-добрите методологии за разработка на софтуер, създадена от Rational Software. Въз основа на опита от много успешни софтуерни проекти, Unified Process ви позволява да създавате сложни софтуерни системи, базирани на методи за индустриално развитие. Един от основните стълбове, на които RUP разчита, е процесът на създаване на модели с помощта на Unified Modeling Language (UML). Тази статия е за използването на UML диаграми в работния процес за разработка на софтуерни системи, използвайки методологията на Rational Software.

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

В днешно време хората, които създават програми на колене, са оставени с областта на малките помощни програми и различни модули за разширение за „тежки“ софтуерни продукти. Бъдещето принадлежи на индустриалния подход към създаването на софтуер. През 1913 г. Хенри Форд пуска първата автомобилна поточна линия, а през 90-те години подобна поточна линия започва да се използва в областта на IT технологиите. Развитието на екипа изисква съвсем различен подход и различна методология, която рано или късно трябваше да бъде създадена.

Rational Software Corporation (http://www.rational.com) пусна структурирана база от знания, наречена Rational Unified Process (RUP), която е набор от изчерпателни препоръки за създаване на почти всеки софтуерен продукт. Попивайки опита от най-добрите разработки, RUP разказва подробно кога, кой и какво трябва да направи в проекта, за да се получи софтуерна система навреме, с определена функционалност и в рамките на определения бюджет.

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

За да се изпълнят изискванията на клиента навреме, Унифицираният процес е разделен на фази, които се състоят от итерации, поради което процесът се нарича още итеративен и инкрементален. Всяка итерация преминава през цикъл на основна работа и довежда разработчиците до крайната цел: създаване на софтуерна система. По време на итерации се създават междинни артефакти, които са необходими за успешното завършване на проекта и версия на софтуерната система, която изпълнява определен набор от функции, който се увеличава от итерация на итерация. Фазите и основните работни потоци на процеса са показани на фиг. 1 там са дадени и приблизителните разходи за труд на работа по етапи.

ориз. 1 RUP фази и работни потоци

Трябва да се отбележи, че на фиг. 1 е показана само основната работа на Единния процес. Например дейностите по управление на дейности не са показани тук, за да се избегне претрупването на диаграмата.

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

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

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

Unified Modeling Language се появява в края на 80-те и началото на 90-те години, главно благодарение на усилията на „тримата приятели“ Гради Буча, Джим Рамбо и Ивар Джейкъбсън. Вече е приет от консорциума OMG като стандартен език за моделиране, който предоставя на разработчиците ясна нотация, която позволява моделите да бъдат показвани в графични елементи, които са общоприети и разбираеми от всички в проекта.

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

Софтуерната система е създадена за решаване на конкретни потребителски проблеми, а не за програмисти, за да тестват нови технологии и да трупат опит за ръководителя на проекта. Като цяло, потребителят не се интересува дали използвате обектно-ориентиран подход, UML, RUP или създавате система, използвайки метода XP (екстремно програмиране) в процеса на разработка. Използването на определени методи, технологии и създаването на оптимална вътрешна структура на проекта остава на съвестта на разработчиците, които вземат решения въз основа на предишен опит и собствените си предпочитания. Потребителят обаче няма да ви прости пренебрегването на неговите изисквания. Дори една софтуерна система да бъде разработена десет пъти с помощта на най-съвременни методи и технологии, ако потребителят не получи това, което се нарича „смислен резултат“ от нея, вашият софтуерен проект ще се провали мизерно.

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

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

Веднъж изнесох семинар за RUP в софтуерна компания, която беше доста успешна на пазара от десет години, но изобщо не използваше моделиране в работния си процес, а се базираше на прототипи. В залата се събраха около двайсетина млади и опитни програмисти, които внимателно изслушаха всичко, което им разказах за RUP и UML. И един от тях, гледайки дъската, покрита с примерни диаграми, отбеляза: „Всичко това е интересно и вероятно е добро за други проекти“, каза той, „но ние работим доста дълго време без всичко това, откакто сме все пак успяхме без UML, вероятно просто нямаме нужда от него.

Този въпрос ме накара да мисля, че промяната в бизнес процесите, която неизбежно трябва да настъпи в компания за разработка на софтуер при внедряването на RUP и UML, може да бъде толкова трудна, колкото внедряването на информационна система в индустриално предприятие.Всяко внедряване е разчупване на стереотипите. Тъй като квалификацията на служителите в компания за разработка на софтуер е доста висока, за такива хора е по-трудно да изоставят възгледите си, отколкото за „простосмъртните“, а трудностите и отхвърлянето, които възникват, могат да бъдат сравнени с прехода от процедурен към обектен ориентирано мислене.

1.Определяне на изискванията

Унифицираният процес е процес, управляван от случаи на употреба, които отразяват сценарии за взаимодействие с потребителя. Всъщност това е погледът на потребителите към софтуерната система отвън. По този начин един от най-важните етапи на разработка, според RUP, ще бъде етапът на определяне на изискванията, който се състои в събиране на всички възможни желания за работата на системата, които могат да дойдат само на ума на потребителите и анализаторите. По-късно тези данни ще трябва да бъдат систематизирани и структурирани, но на този етап, чрез интервюта с потребители и изучаване на документи, анализаторите трябва да съберат възможно най-много изисквания за бъдещата система, което не е толкова просто, колкото изглежда на пръв поглед. Потребителите често нямат представа какво трябва да получат в крайна сметка. За да улеснят този процес, анализаторите използват диаграми на случаи на използване (фиг. 2)

Фигура 2. Пример за диаграма на случай на използване

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

За детайлизиране на конкретен случай на употреба се използва диаграма на дейността, пример за която е даден на фигура 3.

ориз. 3 Пример за диаграма на дейността

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

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

За да определят правилно изискванията, разработчиците трябва да разберат контекста (част от предметната област), в който ще работи бъдещата система. За целта се създават модел на домейн и бизнес модел, които са различни подходи към един и същи проблем. Често се създава едно нещо: модел на домейн или бизнес модел.

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

За създаване на модел на домейн се използва обикновена класова диаграма (Фигура 6), но тя очевидно не е достатъчна за създаване на бизнес модел. В този случай се използва диаграма на случай на използване, като се използват допълнителни икони, които отразяват същността на бизнес процесите - това са бизнес актант, случай на бизнес употреба, бизнес субект и управление на бизнеса. Този модел е много по-близо до следващия модел, създаден в процеса на разработка – моделът за анализ.

2.Анализ

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

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

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

За да се покаже моделът на анализ с помощта на UML, се използва диаграма на класове със стереотипи (модели на поведение) „граничен клас“, „субект“, „контрол“ и се използват диаграми за сътрудничество за детайлизиране (Фигура 4). Стереотипът „граничен клас“ изобразява клас, който взаимодейства с външни актанти, стереотипът „субект“ изобразява класове, които са хранилища на данни, а стереотипът „контрол“ изобразява класове, които управляват заявки към обекти.

Фигура 4. Пример за диаграма за сътрудничество

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

Ако се съсредоточим върху реда на взаимодействие, тогава друго представяне би било диаграма на последователност (Sequence), показана на фигура 5. Тази диаграма ви позволява да разгледате обмена на съобщения във времето, показвайки визуално последователността на процеса. Когато използвате инструмент за създаване на модел като Rational Rose, тези два типа диаграми могат да бъдат създадени автоматично един от друг (можете да прочетете повече за Rational Rose, например в).

Ориз. 5 Пример за диаграма на последователност

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

3.Дизайн

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

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

Фигура 6. Пример за класова диаграма

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

4.Внедряване

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

ориз. 7 Примерна диаграма на компонентите

5.Тестване

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

6. Заключение

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

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

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

Кратчън. Е. Въведение Рационален унифициран процес . Изд. 2-ри - М.: Издателска къща Уилямс, 2002. - 240 с.: ил.

Jacobson A., Buch G., Rambo J. Унифициран процес на разработка на софтуер - Санкт Петербург: Peter, 2002. - 496 с.: ил.

Фаулър М., Скот К. UML накратко. Приложение на стандартен език за моделиране на обекти: Прев. от английски – М.: Мир, 1999. – 191 с., ил.

Бек. E. Екстремно програмиране. – Санкт Петербург: Питър, 2002. – 224 с.: ил.

ТрофимовС. CASE технологии: Практическа работа в Rational Rose.
Изд. 2-ри - М.: Бином-Прес, 2002 - 288 с.

Unified Process активно използва унифицирания език за моделиране ( UML). В сърцевината UMLе модел, който позволява на екипа за разработка да разбере по опростен начин разнообразието от сложни процеси, необходими за разработването на софтуер. Различни модели използвани в Унифициран процес, ви позволяват да визуализирате системата, да опишете нейната структура и поведение и да документирате решенията, взети по време на процеса на разработка.

История на произход

Произходът на рамката се крие в работата на служител EricssonИвар Якобсон, публикувана в края на 60-те години. Джейкъбсън и колегите му моделираха огромни телекомуникационни системи, използвайки слоеве от „блокове“ (които по-късно станаха известни като „компоненти“): долните слоеве послужиха като основа за подсистеми от горните слоеве. Екипът изгради долните блокове, като взе предвид „случаи на трафик“, които биха могли да се случат на потребителите на системата. Именно тези „инциденти“ станаха прототип на случаи на употреба, които по-късно бяха включени в UML. Работата на Джейкъбсън също вдъхнови създаването на диаграми, използвани в UML, включително диаграми на активност и последователност.

През 1987 г. Джейкъбсън основава собствена компания Възражение ABи заедно с партньори прекара няколко години в разработването на проект и продукт, наречен Възражение. През 1995 г. Джейкъбсън публикува книгата „ Обектно-ориентирано софтуерно инженерство”, описващ процес на разработка, ръководен от изискванията на клиента, които се превеждат в крайния продукт чрез случаи на употреба. Пускането на книгата съвпадна с първото публикуване на онлайн версията на ядрото Унифициран процес.

През 1995 г. компанията Възражение ABпогълнат от корпорацията Рационално. С помощта на значително увеличен брой колеги Джейкъбсън започва да разширява процеса Възражение, допълвайки го с инструменти за управление и развитие на проекти. Заедно с Грейди Бууч и Джеймс Ръмбо, които са работили в Рационалнопо-рано Джейкъбсън стана член на групата на „тримата приятели“, които ръководиха работата по създаването на процес, наречен Rational Objectory Process (ROP), както и разпределението Унифициран процес, което стана основа за унифициран език за моделиране.

В процес на работа по ROPИ UML, корпорация Рационалнопродължаващи сливания и придобивания на компании, участващи в създаването на инструменти за разработка на софтуер. Тези инструменти предоставиха възможности за управление на изискванията („RequisitePro“), общо тестване („SQA“), тестване на производителността, управление на конфигурацията и управление на промените. През 1998г Рационалнопроменя името на продукта на RUP, чието концептуално ядро ​​остава Унифициран процес.

Характеристики

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

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

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

Фази на развитие

Относителен размер на фазите на разработка за типичен проект

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

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

Вътре Унифициран процесВъв всяка фаза на разработка има пет вида работни процеси: изисквания, анализ, проектиране, внедряване и тестване.

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

Итерации и увеличения

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

Рационален унифициран процес(RUP) е технологична рамка за разработка на софтуер, разработена и предлагана на пазара от Rational Software. Той включва глобални най-добри практики в разработката на софтуер и осигурява дисциплинарен подход към възлагането и управлението на задачи и отговорности в рамките на организация за разработка на софтуер. Прилагайки този процес, екипите за разработка на софтуер ще могат да създават висококачествен софтуер, който отговаря на нуждите на техните крайни потребители, и да го правят в рамките на предвидим график и бюджет.

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

Рационалният унифициран процес се основава на няколко основни принципа, събрани от много успешни проекти:

· Започнете да атакувате основните рискове по-рано и го провеждайте непрекъснато, или те сами ще преминат в офанзива срещу вас.

· Уверете се, че изискванията на клиента са изпълнени.

· Концентрирайте се върху програмата, която се изпълнява.

· Адаптирайте се към промените от самото начало на проекта.

· Ранно установяване на изпълнима архитектура.

· Изграждане на система от компоненти.

· Работете заедно като екип.

· Превърнете качеството в начин на живот, а не в закъснение.

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

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

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

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

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

· бизнес модел. Дефинира абстракцията на организацията, за която се създава системата;

· модел на домейн. Коригира контекстната среда на системата;

· Случай на използване на модела. Определя функционалните изисквания към системата.

· модел за анализ. Интерпретира системните изисквания по отношение на модела на проектиране;

· дизайнерски модел. Дефинира речника на домейна на проблема и неговото решение;

· модел на разположение. Определя хардуерната топология, в която работи системата;

· модел на изпълнение. Дефинира частите, които се използват за сглобяване и внедряване на физическа система;

· тестов модел. Дефинира тестови случаи за тестване на системата;

· модел на процеса. Дефинира паралелизъм в системата и механизми за синхронизация.

Технически артефактиса разделени на четири основни групи:

· набор от изисквания. Описва Каквосистемата трябва да направи;

· дизайнерски комплект.

· набор от реализации. Описва асемблирането на разработени софтуерни компоненти;

· комплект за поставяне. Предоставя цялата информация за предоставената конфигурация.

Набор от изискванияможе да включва модел на случай на използване, модел на нефункционални изисквания, модел на домейн, модел за анализ и други форми на изразяване на потребителски нужди.

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

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

Комплект за поставянегрупира цялата информация за опаковане, доставка, инсталиране и стартиране на системата.

Всеки технологичен процес е придружен риск. При разработване на софтуерен продукт незадоволителен резултат (UN) може да бъде: надвишаване на бюджета, ниска надеждност, неправилно функциониране и др. Въздействието на риска се изчислява с помощта на израза

Индикатор за риск = Вероятност (LP) * Загуба (LP).

Управление на рискавключва шест действия:

1. Идентификация на риска – идентифициране на рискови елементи в проекта.

2. Анализ на риска – оценка на вероятността и размера на загубата за всеки рисков елемент.

3. Класиране на риска - подреждане на рисковите елементи според степента на тяхното влияние.

4. Планиране на управлението на риска – подготовка за справяне с всеки елемент на риска.

5. Резолюция на риска – елиминиране или разрешаване на рискови елементи.

6. Мониторинг на риска – проследяване на динамиката на рисковите елементи, предприемане на коригиращи действия.

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

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