Enhetlig mjukvaruutvecklingsprocess. Enhetlig utvecklingsprocess och extrem programmering

I enlighet med GOST 34.601-90 "AS. Stadier av skapande" fastställer följande steg för att skapa en AIS, som i sin tur kan delas in i steg:

· upprättande av krav för AIS;

· utveckling av AIS-konceptet;

· teknisk uppgift;

· preliminär design;

· tekniskt projekt;

· arbetsdokumentation;

· driftsättning.

Varje steg har sin egen uppsättning designdokumentation och implementering av tekniska och mjukvarumoduler i systemet. Övning visar att processen att skapa ett system är iterativ och inkrementell. Författarna till UML betonar detta när de definierar begreppet enhetlig mjukvaru- och informationsutvecklingsprocess. Även om i det första steget en uppsättning krav för AS som helhet bildas, är den i själva verket alltid ofullständig i början och klargörs i efterföljande stadier. Jag måste göra iterationer, det vill säga upprepa enskilda steg och steg, antingen helt eller delvis. Dessutom är ett verkligt system multifunktionellt och komplext, så det är vanligtvis uppdelat i delsystem och separata uppsättningar av uppgifter, som särskiljer delsystem och uppgifter i det första steget, det andra, etc. Systemet håller på att skapas stegvis, genom gradvisa ökningar av funktionalitet med ersättning av preliminära designlösningar med mer utvecklade som bättre möter användarnas krav. Detta minskar ekonomiska risker och sparar tid och resursförbrukning i slutskedet av skapandet.

När man använder UML-metoden för att skapa AIS-programvara och informationsstöd, föreslås det att bygga en uppsättning sammankopplade modeller som återspeglar de statiska och dynamiska egenskaperna hos det framtida systemet:

· modell för användningsfall;

· analysmodell;

· designmodell;

· utbyggnadsmodell;

· genomförandemodell;

· testmodell.

Använd Case Model inkluderar användningsfallsdiagram och motsvarande scenarier, beskriver systemets funktionskrav och dess beteende vid interaktion med användare.

Analysmodell innehåller generiska klassdiagram för att implementera användningsfall på logisk nivå, tillhörande sekvensdiagram och/eller samarbetsdiagram, och är en skiss på hur användningsfallen på logisk nivå kommer att implementeras.

Designmodellär en detaljerad representation av den fysiska implementeringen av analysmodellen och inkluderar paketdiagram (delsystem), detaljerade klassdiagram, sekvensdiagram och/eller samarbetsdiagram, tillståndsdiagram, aktivitetsdiagram med varierande detaljeringsgrad.

Implementeringsmodell inkluderar preliminära distributionsdiagram som definierar alla nätverkskonfigurationer som systemet kan köras på. Distributionsdiagram anger nätverksnoder, anslutningstyper och fördelningen av aktiva systemklasser mellan noder.

Implementeringsmodell beskriver hur designklasser implementeras som komponenter. Följaktligen inkluderar den komponentdiagram, klass(implementerings-) spår, detaljerade distributionsdiagram och en beskrivning av systemarkitekturen.

Testmodell innehåller en uppsättning testfall, testprocedurer och beskrivningar av testkomponenter. Den specificerar metoder för att testa körbara systemkomponenter.

Låt oss jämföra processerna för att bygga modeller med de standardiserade stadierna för att skapa ett AS. Användningsfallsmodellen byggs i det skede då kraven ställs för AS; analysmodellen befinner sig i utvecklingsstadiet för AS-konceptet. I stadiet av tekniska specifikationer och preliminär design byggs en designmodell. Den förfinas på det tekniska konstruktionsstadiet och kompletteras med en utbyggnadsmodell. På arbetsdokumentationsstadiet skapas implementerings- och testmodeller. Slutligen, i driftsättningsskedet, förfinas testmodellen och blir en referensmodell under drift, avsedd för periodiska kontroller av systemets korrekta funktion och diagnostik.

1.5 Komponenter i UML-språket

Unified Modeling Language UML(Unified Modeling Language) är ett visuellt modelleringsspråk som används för att specificera, visualisera, konfigurera och dokumentera komplexa system (inklusive programvara) med hjälp av objektorienterad teknologi.

När man skapar ett AS i UML-metoden används principerna för strukturell systemanalys som är kända från Hein/Sarson- och SADT-metoderna:

· Top-down utveckling steg för steg;

· diagramteknik;

· hierarki av beskrivningar;

· strikt formalisering av beskrivningen av designlösningar;

· Inledande utveckling av projektet på en logisk nivå utan detaljer om tekniskt genomförande;

· konceptuell modellering i termer av ämnesområdet för att kunden ska förstå systemdesignen;

· tekniskt stöd med verktyg (CASE-system).

En modell av ett komplext system i UML kan studeras för att erhålla uppskattade egenskaper för effektiviteten av processer i systemet.

Modeller för driftsättning, implementering och testning av AS-mjukvara och informationsstöd i UML kan användas som ett applikationsprojekt med efterföljande automatiserad generering av applikationskod i någon av de utvalda programmeringsmiljöerna.

En ganska komplett modell av ett komplext system bör spegla två aspekter:

-statisk(strukturell) – sammansättning, struktur av komponenter och deras relationer;

-dynamisk(beteende) – beskrivning av logiken i processer som förekommer i systemet eller ska implementeras.

Huvudmetoden för att representera modeller som används i UML är diagram försedda med textinformation, inklusive uttryck i det inbyggda begränsningsspråket OCL, såväl som i programmerings- och informationsfrågorna som används för att implementera systemet.

Grundprincipen för modellering: ett system modelleras som en grupp av diskreta objekt som interagerar med varandra på ett sådant sätt att det tillfredsställer användarkrav.

En statisk modell specificerar struktur, typer av objekt och relationer mellan objekt. Den dynamiska modellen bestämmer objektens beteende över tid (objektens historia) och deras interaktion.

I grunden är UML ett diskret modelleringsspråk, det vill säga det innehåller begreppet diskreta händelser och tillståndsförändringar. Kontinuerliga processer modelleras ungefär genom diskretisering.

Modellen har två aspekter: semantisk information (semantik) och visuell representation (notation).

Den fullständiga sammansättningen av modellrepresentationer i UML-språket ges i tabell 1

Tabell 1 – Representation av systemmodeller i UML.

Den vanligaste konceptuella modellen för ett system är use case-diagrammet, det är utgångspunkten för att konstruera andra diagram.

Alla språkdiagram är grafer av en speciell typ, som innehåller hörn (geometriska figurer) förbundna med kanter (bågar). Vanligtvis är bildens skala och platsen för hörnen inte särskilt viktiga, men i sekvensdiagrammet introduceras tidsaxeln och där är den signifikant.

Anslutningar indikeras med olika linjer på planet, text är skriven inuti figurerna och några grafiska symboler kan avbildas nära hörn och anslutningar. UML-tillägg tillåter rumsliga diagram.

Språket har 4 typer av grafiska strukturer:

· ikoner (piktogram);

· grafiska symboler på ett plan;

· stigar (linjer);

· textrader.

1.6 Konceptuell nivå. Använd Case Model

I allmänhet sker den objektorienterade designprocessen i enlighet med de grundläggande principerna för strukturell systemanalys: top-down design med konstruktion av en hierarki av diagram som gradvis flyttar oss från nivå till nivå: konceptuell – logisk – fysisk (implementering)

Toppnivådiagrammet anses vara det som föreslagits av A. Jacobson i OOSE diagram för användningsfall systemen som helhet. Det är detta som är den första konceptuella representationen av systemet och är byggd med målet att:

· fastställa de allmänna gränserna och sammanhanget för det modellerade ämnesområdet;

· formulera allmänna krav på systemets funktionella beteende och gränssnitt;

· förbereda initial dokumentation för interaktion mellan utvecklare och kunder - användare av systemet.

Modellens synvinkel: extern användare av systemet. Ett användningsfallsdiagram inkluderar aktörer, användningsfall och associationer.

Aktant(aktör, extern enhet, aktör) - en abstrakt beskrivning av en klass av meddelandekällor/mottagare som direkt interagerar med ett system, delsystem eller klass. Detta är beskrivningen roller spelas av användaren (person eller annat system, delsystem, klass) under interaktion med systemet. I huvudsak är detta en generalisering av liknande informationsförfrågningar till systemet som kräver en viss service(tjänster).

En aktant behöver inte nödvändigtvis identifieras med en specifik individ eller enhet, även om detta ibland är möjligt i princip om de bara fyller en roll. Oftast - fysiskt - är det olika personer och enheter som kommer åt systemet för att få samma tjänst. På högsta nivån kan till exempel aktanter vara en operatör, en systemadministratör, en databasadministratör, en vanlig användare eller någon klass av enheter.

Alla möjliga aktanter tar ut alla möjliga sätt för användarinteraktion med systemet (undersystem, klass). När ett system implementeras förkroppsligas aktanter i människor och fysiska föremål. En person eller ett fysiskt föremål, beroende på interaktionssätt, kan representera flera aktanter (olika roller). Till exempel kan samma person vara en operatör och en databasadministratör, en säljare och en köpare osv.

I många AS finns det inga andra aktanter förutom människor. Emellertid kan aktanterna vara ett externt system, en I/O-enhet eller en timer (finns vanligen i inbäddade realtidssystem). Bland aktanterna i use casen sticker en ut huvudaktant(primär aktör), som initierar arbetet med systemet. Resten är sekundära, de deltar också i användningsfallet, tar emot resultat och anger en del mellandata.

På den logiska och fysiska nivån representeras aktanter av klasser och objekt som är instanser av klasser. Det är möjligt att bygga en hierarki av aktanter med arv av alla roller och relationer, attribut och operationer som förfäderaktanten har. En instans av en barnaktant kan alltid användas på den plats i systemet där användningen av förfaderaktanten deklareras (substitutionsprincipen).

En aktant kan representeras på diagram på två sätt:

3. Klasssymbol (rektangel) med intern indikation på stereotypen

4. Mer standard: "man" med en inskription (symbol för en person)

Aktanten är utanför systemet och dess inre struktur är inte bestämd. Det är källan/mottagaren av meddelanden.

Kund

Användningsfall(prejudikat, användningsfall) – en abstrakt beskrivning av tjänsteklassen (servicefunktioner) som tillhandahålls aktanten som svar på dess förfrågningar.

Tjänsten kan tillhandahållas av systemet som helhet, ett delsystem eller en klass. Således innebär ett användningsfall att modellera någon del av funktionaliteten eller beteendet hos ett system. Ett användningsfall har ett namn och betyder en viss sekvens av åtgärder som är synliga för en extern källa/mottagare (aktant). Det interna sättet att implementera alternativet är dolt och avslöjas på lägre detaljnivåer. samarbetsdiagram. Som alla klasser har ett användningsfall attribut och operationer, vars implementering är exponerad i det fysiska lagret.

Användningsfallet inkluderar hela sekvensen av meddelanden som aktanten börjar och slutar med systemet (undersystem, klass). Därför har varje instans av en användningsfallsimplementering alltid en början i tiden och ett slut när ingen aktant skickar meddelanden för detta alternativ. Detta inkluderar även felmeddelanden, alternativ för att utföra underhållsfunktionen med olika inställningar (alternativ).

En användningsfallsinstans är exekveringen av ett användningsfall som börjar efter att ha mottagit ett meddelande från en aktivinstans. Som svar på ett givet meddelande utför användningsfallet en specifik sekvens av åtgärder, som att skicka ett meddelande till andra instanser av aktanten (inte bara upphovsmannen). I sin tur skickar dessa aktanter meddelanden till denna användningsfallsinstans, och interaktionen fortsätter tills inga fler sådana meddelanden tas emot. Detta markerar slutet på användningsfallet.

Relationen mellan aktanten och användningsfallet visas förening.

Diagrammet visar användningsfallet på två sätt:

1) en ellips, ett namn placeras inuti

2) en rektangel - som vilken klass som helst

Kund

Sensor

Mellan aktanter och användningsfall är association den enda typen av koppling. Dessutom har den semantik växla kommunikation, det vill säga meddelandeförmedling, flaggas därför vanligtvis inte eftersom sammanhanget är tydligt från aktant- och usecase-notationen. Men du kan markera det och även ange mångfalden av anslutningen:

Bankklient

Mångfald(multiplicity) kännetecknar antalet specifika instanser av en klass som deltar i en given anslutning (en kund kan utfärda ett obegränsat antal lån).

I allmänhet föreningär ett förhållande mellan två eller flera modellkomponenter. Eftersom komponenter i de flesta fall är vissa klasser av objekt, är en associationsinstans helt enkelt en ordnad lista med referenser till specifika instanser, kanske utrustad med associationsattribut (egenskaper).

Föreningsnamnet, om det finns ett, måste vara unikt. Den bildas efter innebörden av relationerna mellan de klasser som är deltagare i föreningen. Till exempel "Anställd arbetar med Avdelningschef slutförs Dator” osv.

Föreningar är själva klasser ( föreningsklass, föreningsklass), har den både klass- och föreningsegenskaper. Förekomster av den här klassen är anslutningar som inte bara har länkar till objekt utan även attributvärden (egenskapsvärden).

Föreningens medlemmar kallas dess stolpar. Alla poler är rollerna för de klasser som är involverade i kopplingen, de är distinkta och kan listas i någon ordnad lista. I de flesta fall är associationer binära (två roller i en association med viss semantik), men det kan också finnas n -är. En och samma klass kan agera i olika roller, det vill säga vara samtidigt i två poler i föreningen.

Mångfalden av anslutningar anges vid polerna.

Anslutningar kan uppstå och försvinna under driften av systemet och motsvarande predikat kan anges vid föreningens poler.

Ibland ändras kopplingen endast vid en av polerna. Om en länk har attribut kan de ändras genom operationer, men länkarna till länkdeltagarna ändras inte.

En förening avbildas som en sammanhängande linje som förbinder gränserna för 2 klasser om föreningen n-ary, sedan ritas en romb (ett tecken på aggregation):

		Många föreningar - aggregering
	Binär association

Användningsfall utbyter inte meddelanden med varandra och kan bara vara i relationer (anslutningar) förlängningar(förlänga) inkludering(inkludera) och generaliseringar(generalisering).

I angående expansion användningsfall – klienten introducerar ytterligare en sekvens av åtgärder, med början från någon punkt i huvudsekvensen, och det kan finnas flera sådana "insättningar". Alla dessa punkter kallas expansionspunkter.

Rational Unified Process (RUP) är en av de bästa metoderna för mjukvaruutveckling, skapad av Rational Software. Baserat på erfarenheten från många framgångsrika programvaruprojekt låter Unified Process dig skapa komplexa mjukvarusystem baserade på industriella utvecklingsmetoder. En av de viktigaste pelarna som RUP förlitar sig på är processen att skapa modeller med hjälp av Unified Modeling Language (UML). Den här artikeln handlar om att använda UML-diagram i arbetsflödet för utveckling av mjukvarusystem med Rational Software-metoden.

Det är ingen hemlighet att att skapa mjukvara är en komplex process, som å ena sidan har mycket gemensamt med kreativitet, och å andra sidan, även om det är en mycket lönsam, är det också en högkostnadsaffär. Hård konkurrens på marknaden tvingar utvecklare att söka efter effektivare arbetsmetoder. Sätt att skapa mjukvarusystem på ännu snabbare tid, till lägre kostnad och med bättre kvalitet. Komplexiteten i programmen ökar hela tiden. Fram till nyligen kunde mjukvaruprodukter skapas inom överskådlig tid av enskilda personer eller till exempel på IT-avdelningen i ett automatiserat företag.

Nuförtiden är individer som skapar program på sina knän kvar med området för små verktyg och olika förlängningsmoduler för "tunga" mjukvaruprodukter. Framtiden tillhör det industriella förhållningssättet till att skapa mjukvara. 1913 lanserade Henry Ford den första monteringslinjen för bilar, och på 90-talet började en liknande monteringslinje användas inom IT-teknik. Teamutveckling kräver ett helt annat förhållningssätt och en annan metodik, som förr eller senare måste skapas.

Rational Software Corporation (http://www.rational.com) har släppt en strukturerad kunskapsbas som heter Rational Unified Process (RUP), som är en uppsättning omfattande rekommendationer för att skapa nästan vilken mjukvaruprodukt som helst. Efter att ha tagit till sig erfarenheten av de bästa utvecklingarna berättar RUP i detalj när, vem och vad som ska göras i projektet för att få ett mjukvarusystem i tid, med en viss funktionalitet och inom den tilldelade budgeten.

Den enhetliga processen kan ses som summan av utvecklingsföretagets olika aktiviteter som är nödvändiga för att översätta kundkrav till ett mjukvarusystem. Ett system som skulle ge "meningsfulla resultat" till användarna och göra precis vad de förväntar sig av systemet. Därför styrs processen av användningsfall av systemet, eller på annat sätt - prejudikat.

För att implementera kundkrav i tid är Unified Process indelad i faser som består av iterationer, varför processen även kallas iterativ och inkrementell. Varje iteration går igenom en cykel av grundläggande arbete och för utvecklare till det slutliga målet: att skapa ett mjukvarusystem. Under iterationer skapas mellanliggande artefakter som krävs för ett framgångsrikt slutförande av projektet och en version av mjukvarusystemet som implementerar en viss uppsättning funktioner, som ökar från iteration till iteration. Processens faser och huvudsakliga arbetsflöden visas i fig. 1 anges där också de ungefärliga arbetskostnaderna för arbetet per fas.

ris. 1 RUP faser och arbetsflöden

Det bör noteras att i fig. 1 visar endast huvudarbetet i den förenade processen. Till exempel visas inte aktivitetshanteringsaktiviteter här för att undvika att diagrammet blir rörigt.

All mjukvaruutveckling betraktas i RUP som en process för att skapa artefakter. Alla resultat av projektet, vare sig det är källkoder, objektmoduler, dokument som överförts till användaren, modeller - dessa är underklasser av alla projektartefakter. Varje medlem i projektgruppen skapar sina egna artefakter och är ansvarig för dem. Programmeraren skapar programmet, chefen skapar projektplanen och analytikern skapar systemmodellen. RUP låter dig bestämma när, av vem och vilken artefakt som behöver skapas, modifieras eller användas.

En av de mest intressanta klasserna av projektartefakter är modeller, som tillåter utvecklare att definiera, visualisera, konstruera och dokumentera programvarusystemartefakter. Varje modell är en fristående bild av det system som utvecklas och är avsedd att både skissera problem och föreslå lösningar. Självförsörjning av modeller innebär att en analytiker eller utvecklare kan få all information han behöver från en specifik modell utan att vända sig till andra källor.

Modeller låter dig överväga det framtida systemet, dess objekt och deras interaktion även innan du investerar betydande medel i utvecklingen, de låter dig se det genom ögonen på framtida användare från utsidan och utvecklare från insidan redan innan den första raden med källkod; är skapad. De flesta modellerna representeras av UML-diagram du kan läsa mer om till exempel UML i;

The Unified Modeling Language dök upp i slutet av 80-talet och början av 90-talet, främst tack vare insatserna från de "tre vännerna" Gradi Bucha, Jim Rambo och Ivar Jacobson. Det har nu antagits av OMG-konsortiet som ett standardmodelleringsspråk som ger utvecklare en tydlig notation som gör att modeller kan visas i grafiska element som är allmänt accepterade och förstådda av alla i projektet.

Vi bör dock inte glömma att modelleringsspråket endast tillhandahåller en notation - ett verktyg för att beskriva och modellera ett system, och en enhetlig process bestämmer metodiken för att använda detta verktyg, såväl som andra metodstödverktyg från Rational. UML kan användas utan en specifik metod eftersom det är processoberoende, och oavsett vilket processalternativ som används kan du använda diagram för att dokumentera de beslut som tagits under utvecklingen och visa de skapade modellerna.

Ett mjukvarusystem skapas för att lösa specifika användarproblem, och inte för att programmerare ska testa ny teknik och skaffa erfarenhet åt projektledaren. Användaren bryr sig i stort sett inte om du använder ett objektorienterat tillvägagångssätt, UML, RUP eller skapar ett system med XP-metoden (extremprogrammering) i utvecklingsprocessen. Användningen av vissa metoder, teknologier och skapandet av den optimala interna strukturen för projektet förblir på utvecklarnas samvete, som fattar beslut baserat på tidigare erfarenheter och sina egna preferenser. Användaren kommer dock inte att förlåta dig för att du ignorerar hans krav. Även om ett mjukvarusystem utvecklas tio gånger med hjälp av toppmoderna metoder och teknologier, om användaren inte får vad som kallas ett "meningsfullt resultat" av det, kommer ditt programvaruprojekt att misslyckas totalt.

Det följer av detta att tanklös tillämpning av UML, helt enkelt för att det är på modet, inte bara inte kommer att leda utveckling till framgång, utan också kan orsaka missnöje bland anställda som behöver studera en stor mängd ytterligare litteratur och projektledare när det visar sig att arbetskostnaderna för projektet ökar, och avkastningen ökar inte. Du måste tydligt förstå vad du vill få ut av att implementera denna teknik och följa detta mål. Användningen av UML sparar utvecklingsresurser eftersom det gör att du kan få en uppfattning om systemet snabbare än när du skapar layouter och prototyper, och spenderar ojämförligt mindre resurser.

Diagram gör det enklare för projektmedlemmar att kommunicera med varandra och, vad som är särskilt värdefullt, involverar slutanvändare av systemet i processen. Modellering gör att du kan minska projektrisker, eftersom det alltid är lättare för programmerare att göra det som är tydligt och förståeligt än att gå till ett osäkert resultat. Att skapa diagram liknar att skapa ett projekt i konstruktion - du kan klara dig utan det, till exempel när du bygger ett skjul på en sommarstuga, men ju större byggnaden är (i vårt fall en mjukvaruprodukt), desto svårare är det att göra och desto mer osäkra slutresultatet.

Jag höll en gång ett seminarium om RUP på ett mjukvaruföretag som varit ganska framgångsrikt på marknaden i tio år, men som inte använde modellering alls i sitt arbetsflöde, utan baserades på prototyper. Ett tjugotal unga och erfarna programmerare samlades i hallen, som noga lyssnade på allt jag berättade om RUP och UML. Och en av dem, som tittade på tavlan täckt med exempeldiagram, anmärkte: "Det här är intressant och förmodligen bra för andra projekt," sa han, "men vi har jobbat ganska länge utan allt detta, eftersom vi är fortfarande klarade vi oss utan UML, vi behöver det förmodligen inte."

Denna fråga fick mig att tänka att förändringen i affärsprocesser som oundvikligen måste ske i ett mjukvaruutvecklingsföretag när man implementerar RUP och UML kan vara lika svår som att implementera ett informationssystem på ett industriföretag. Eftersom kvalifikationerna för anställda i ett mjukvaruutvecklingsföretag är ganska höga är det svårare för sådana människor att överge sina åsikter än för "bara dödliga", och de svårigheter och avslag som uppstår kan jämföras med övergången från processuell till objekt- orienterat tänkande.

1.Definition av krav

En enhetlig process är en process som drivs av användningsfall som återspeglar scenarier för användarinteraktion. I själva verket är det användarnas syn på mjukvarusystemet utifrån. Ett av de viktigaste utvecklingsstadierna, enligt RUP, blir alltså kravdefinitionsstadiet som består i att samla in alla möjliga önskemål om driften av systemet som användare och analytiker kan tänka sig. Senare kommer denna data att behöva systematiseras och struktureras, men i detta skede, genom intervjuer med användare och studerande dokument, måste analytiker samla in så många krav som möjligt för det framtida systemet, vilket inte är så enkelt som det verkar vid första anblicken. Användare har ofta ingen aning om vad de ska få i slutändan. För att underlätta denna process använder analytiker användningsfallsdiagram (Fig. 2)

Fig 2. Exempel på ett Use Case-diagram

Diagrammet är en återspegling av de aktörer (aktanter) som interagerar med systemet, och mjukvaruobjektens reaktion på deras handlingar. Aktanter kan vara både användare och externa agenter som behöver sända eller ta emot information. Ikonen för användningsfall återspeglar systemets svar på extern input och visar vad som behöver göras för aktanten.

För att detaljera ett specifikt användningsfall används ett aktivitetsdiagram, ett exempel på det ges i figur 3.

ris. 3 Exempel på ett aktivitetsdiagram

Enkelheten i användningsfallsdiagrammet gör det möjligt för analytiker att enkelt kommunicera med kunder under kravdefinitionsprocessen, identifiera begränsningar som läggs på systemet och på implementeringen av individuella krav, såsom systemsvarstid, som senare faller in i sektionen av icke-funktionella krav.

Ett use case-diagram kan också användas för att skapa testscenarier eftersom all interaktion mellan användare och systemet redan har definierats.

För att korrekt bestämma kraven måste utvecklare förstå sammanhanget (en del av ämnesområdet) där det framtida systemet kommer att fungera. För att göra detta skapas en domänmodell och en affärsmodell, som är olika förhållningssätt till samma fråga. Ofta skapas en sak: en domänmodell eller en affärsmodell.

Skillnaden mellan dessa modeller är att domänmodellen beskriver de viktiga koncept som systemet kommer att arbeta med och deras kopplingar till varandra. Medan en affärsmodell beskriver de affärsprocesser (befintliga eller framtida) som systemet ska stödja. Därför, förutom att definiera affärsobjekten som är involverade i processen, definierar denna modell arbetarna, deras ansvar och de åtgärder de måste utföra.

För att skapa en domänmodell används ett vanligt klassdiagram (Figur 6), men det räcker tydligen inte för att skapa en affärsmodell. I det här fallet används ett användningsfallsdiagram med ytterligare ikoner som återspeglar kärnan i affärsprocesser - dessa är affärsaktant, affärsanvändningsfall, affärsenhet och affärsledning. Denna modell ligger mycket närmare nästa modell som skapas i utvecklingsprocessen - analysmodellen.

2. Analys

Efter att ha fastställt kraven och det sammanhang i vilket systemet kommer att fungera, är det dags att analysera de erhållna uppgifterna. Under analysprocessen skapas en analytisk modell som guidar utvecklare till arkitekturen för det framtida systemet. En analytisk modell är en vy av ett system från insidan, till skillnad från en use case-modell, som visar hur systemet kommer att se ut från utsidan.

Denna modell låter dig förstå hur systemet ska utformas, vilka klasser det ska ha och hur de ska interagera med varandra. Dess huvudsakliga syfte är att bestämma riktningen för implementeringen av den funktionalitet som identifierades vid insamlingsstadiet och att skissa systemarkitekturen.

Till skillnad från designmodellen som skapas senare är analysmodellen mer en konceptuell modell och för bara utvecklare närmare implementeringsklasserna. Denna modell bör inte ha eventuella motsättningar som kan förekomma i prejudikatmodellen.

För att visa analysmodellen med UML används ett klassdiagram med stereotyper (beteendemönster), "gränsklass", "entitet", "kontroll" och samarbetsdiagram används för detaljering (Figur 4). Stereotypen "gränsklass" skildrar en klass som interagerar med externa aktanter, "entitets"-stereotypen skildrar klasser som är datalager, och "kontroll"-stereotypen skildrar klasser som hanterar frågor till enheter.

Figur 4. Exempel på ett samverkansdiagram

Numreringen av meddelanden visar deras ordning, men syftet med diagrammet är inte att beakta ordningen på meddelanden som utbyts, utan att tydligt visa klassernas relationer med varandra.

Om vi ​​fokuserar på interaktionsordningen, så skulle en annan representation vara ett sekvensdiagram (Sekvens), som visas i figur 5. Detta diagram låter dig titta på utbytet av meddelanden över tiden, och visuellt visa processens sekvens. När du använder ett verktyg för att skapa modell som Rational Rose kan dessa två typer av diagram skapas från varandra automatiskt (du kan till exempel läsa mer om Rational Rose i).

Ris. 5 Exempel på ett sekvensdiagram

Beslutet om vilket av de två diagrammen som ska skapas först beror på den individuella utvecklarens preferenser. Eftersom dessa diagram är en representation av samma process, låter de båda dig återspegla interaktionen mellan objekt.

3. Design

Nästa steg i processen att skapa ett system är design, under vilken en designmodell skapas utifrån de modeller som skapats tidigare. Denna modell speglar den fysiska implementeringen av systemet och beskriver den skapade produkten på klass- och komponentnivå. Till skillnad från analysmodellen har designmodellen ett tydligt beroende av implementeringsvillkoren, de programmeringsspråk och komponenter som används. För den mest exakta förståelsen av systemarkitekturen bör denna modell vara så formaliserad som möjligt och hållas uppdaterad under hela systemutvecklingens livscykel.

För att skapa en designmodell används en hel uppsättning UML-diagram: klassdiagram (fig. 5), samarbetsdiagram, interaktionsdiagram, aktivitetsdiagram.

Fig 6. Exempel på ett klassdiagram

Dessutom kan detta arbetsflöde skapa en distributionsmodell som implementeras baserat på ett distributionsdiagram. Detta är den enklaste typen av diagram som utformats för att modellera distributionen av enheter i ett nätverk. För visning används endast två alternativ för processor- och enhetsikonerna, tillsammans med anslutningarna mellan dem.

4.Genomförande

Huvuduppgiften för implementeringsprocessen är att skapa ett system i form av komponenter - programkällkoder, skript, binära filer, körbara moduler, etc. I detta skede skapas en implementeringsmodell som beskriver hur delar av designmodellen implementeras, vilka klasser som kommer att ingå i specifika komponenter. Denna modell beskriver sättet att organisera dessa komponenter i enlighet med de strukturerings- och modulariseringsmekanismer som används i den valda programmeringsmiljön och representeras av ett komponentdiagram (fig. 7).

ris. 7 Exempel på komponentdiagram

5.Testning

Under testprocessen kontrolleras resultaten av implementeringen. För denna process skapas en testmodell, som består av testfall, testprocedurer, testkomponenter, men som inte har en UML-diagramrepresentation, så vi kommer inte att uppehålla oss vid det.

6. Sammanfattning

Endast huvudprocesserna i den rationella metoden beaktades här. RUP är ganska omfattande och innehåller rekommendationer för att driva olika programvaruprojekt, från att skapa program av en grupp utvecklare av flera personer, till distribuerade programvaruprojekt som förenar tusentals människor på olika kontinenter. Men trots deras enorma skillnader kommer metoderna för att använda modeller skapade med UML att vara desamma. UML-diagram, skapade i olika utvecklingsstadier, är oskiljaktiga från resten av artefakterna i ett mjukvaruprojekt och är ofta länken mellan individuella RUP-processer.

Beslutet att använda specifika diagram beror på utvecklingsprocessen som ställts upp i företaget, som, även om den kallas enhetlig, inte är något fruset. Rational erbjuder inte bara att förbättra och förfina den, utan tillhandahåller också specialverktyg för att göra ändringar i RUP-databasen.

Men i alla fall kommer användningen av UML tillsammans med en enhetlig process att låta dig få ett förutsägbart resultat, möta den tilldelade budgeten, öka effekten av projektdeltagare och kvaliteten på den skapade mjukvaruprodukten.

Kratchen. F. Inledning Rationell enhetlig process . Ed. 2:a - M.: Williams Publishing House, 2002. - 240 s.: ill.

Jacobson A., Buch G., Rambo J. Unified mjukvaruutvecklingsprocess - St. Petersburg: Peter, 2002. - 496 s.: ill.

Fowler M., Scott K. UML i ett nötskal. Tillämpning av ett standardspråk för objektmodellering: Transl. från engelska – M.:Mir, 1999. – 191 s., ill.

Vink. E. Extrem programmering. – St Petersburg: Peter, 2002. – 224 s.: ill.

TrofimovS. CASE-teknologier: Praktiskt arbete i Rational Rose.
Ed. 2:a - M.: Binom-Press, 2002 - 288 sid.

Unified Process använder aktivt det enhetliga modelleringsspråket ( UML). I kärnan UML ligger en modell som gör att utvecklingsteamet på ett förenklat sätt förstår mångfalden av komplexa processer som krävs för mjukvaruutveckling. Olika modeller som används i Enhetlig process, låter dig visualisera systemet, beskriva dess struktur och beteende och dokumentera beslut som fattas under utvecklingsprocessen.

Ursprungshistoria

Ursprunget till ramverket ligger i en anställds arbete Ericsson Ivar Jacobson, utgiven i slutet av 1960-talet. Jacobson och hans kollegor modellerade enorma telekommunikationssystem med skikt av "block" (det som senare blev känt som "komponenter"): de nedre skikten fungerade som grunden för delsystem från de övre skikten. Teamet byggde de nedre blocken genom att överväga "trafikfall" som kan hända användare av systemet. Det var dessa "incidenter" som blev prototypen på användningsfall, som senare ingick i UML. Jacobsons arbete inspirerade också till skapandet av diagram som används i UML inklusive aktivitets- och sekvensdiagram.

1987 grundade Jacobson sitt eget företag Objectory AB och tillsammans med partners ägnade flera år åt att utveckla ett projekt och en produkt som heter Invändning. 1995 gav Jacobson ut boken " Objektorienterad mjukvaruteknik”, som beskriver en utvecklingsprocess som drivs av kundkrav som översätts till en slutprodukt genom användningsfall. Utgivningen av boken sammanföll med den första publiceringen av onlineversionen av kärnan Enhetlig process.

1995 företaget Objectory AB absorberas av bolag Rationell. Med hjälp av ett betydligt ökat antal kollegor börjar Jacobson utöka processen Invändning, som kompletterar den med verktyg för projektledning och utveckling. Tillsammans med Grady Booch och James Rumbaugh, som arbetade i Rationell tidigare blev Jacobson medlem i gruppen av "tre amigos", som ledde arbetet med att skapa en process som heter Rationell invändningsprocess (ROP), såväl som distributionen Enhetlig process, som blev grunden för Unified Modeling Language.

I färd med att arbeta på ROP Och UML, aktiebolag Rationell fortsatta sammanslagningar och förvärv av företag som är involverade i skapandet av verktyg för mjukvaruutveckling. Dessa verktyg gav möjligheter för kravhantering ("RequisitePro"), allmän testning ("SQA"), prestandatester, konfigurationshantering och förändringshantering. År 1998 Rationelländrar produktnamnet till RUP, vars konceptuella kärna kvarstår Enhetlig process.

Egenskaper

Enhetlig process baserat på användningsfall, som beskriver en eller flera aktörer som interagerar med systemet och får resultat som är värdefulla för deltagarna i processen. Det är användningsfall som är den främsta drivkraften som driver hela utvecklingsprocessen, från insamling och diskussion av krav, och slutar med analys, design och implementering. Användningsfall beskrivs på ett enkelt och begripligt språk, så att de är begripliga för en utomstående läsare.

Enligt Enhetlig process, i centrum för utvecklingsprocessen ligger arkitektur- den grundläggande organisationen av hela systemet. Det kan inkludera statiska och dynamiska element, deras interaktion, och låter dig lösa problem med produkteffektivitet, utbyggbarhet, möjligheten att återanvända element och hjälpa till att övervinna ekonomiska och tekniska begränsningar. Projektgruppen påbörjar arbetet med arkitekturbeskrivningen så tidigt som möjligt och utökar och förbättrar den hela tiden under utvecklingsprocessen. Arkitektur anses vara en viktig aspekt Enhetlig process av ett antal anledningar, vars nyckel är förmågan att se hela bilden av vad som händer, korrekt tillämpning av utvecklarinsatser, underlättande av möjligheter för återanvändning av komponenter, systemutveckling och korrekt val av användningsfall.

Den tredje grundläggande principen Enhetlig processär användningen iterativt och inkrementellt tillvägagångssätt. Iterationer är miniatyrprojekt som låter dig lansera en nyare version av systemet. Resultatet av iterationen, de ändringar som gjorts i systemet, kallas ett inkrement. I synnerhet låter det iterativa tillvägagångssättet dig konsekvent förbättra systemarkitekturen, hantera ständiga förändringar i kraven och flexibelt anpassa planen för hela projektet. Engagemang för principen om kontinuerlig integration gör att du kan identifiera möjliga problem i ett tidigt skede. Dessutom hjälper iterativitet till att minimera risker förknippade med tekniska begränsningar, arkitektur och förändrade krav.

Utvecklingsfaser

Relativ storlek på utvecklingsfaser för ett typiskt projekt

Varje utvecklingscykel, enligt Enhetlig process, består av fyra faser, som representerar tidsperioden mellan viktiga projektmilstolpar, vilket gör att chefer kan fatta viktiga beslut angående fortsättningen av utvecklingsprocessen, arbetets omfattning, budget och tidsplan.

Arbetsflödesvarianter

Inuti Enhetlig process I varje utvecklingsfas finns det fem typer av arbetsprocesser: krav, analys, design, implementering och testning.

Varje process är en uppsättning aktiviteter som utförs av olika medlemmar i projektgruppen. Målet med kravinsamlingsprocesser är alltså att skapa en modell av användningsfall som gör att man kan identifiera de grundläggande funktionskraven för systemet. Analysprocesser och motsvarande modell tillåter utvecklare att strukturera funktionskrav; Designprocessen beskriver den fysiska implementeringen av användningsfallen och är en abstraktion för följande modell. Implementeringsprocessen och modellen beskriver hur designelement förhåller sig till mjukvarukomponenter, inklusive källkod, dynamiska bibliotek etc. Den sista modellen, som beskriver testning, förklarar vilka systemtester och enhetstester som ska utföras och hur utvecklingsteamet ska utföra dem.

Iterationer och inkrement

Var och en av faserna som beskrivs i Unified Process består av iterationer, som är miniatyrdelprojekt med begränsad varaktighet. Vanligtvis inkluderar varje iteration alla fem delar av arbetsflödet i varierande grad. Resultatet av iterationen är ökning, en version som innehåller förbättringar jämfört med den tidigare versionen av produkten.

Rationell enhetlig process(RUP) är ett ramverk för mjukvaruutvecklingsteknologi utvecklat och marknadsfört av Rational Software. Den innehåller globala bästa praxis inom mjukvaruutveckling och ger ett disciplinärt tillvägagångssätt för att tilldela och hantera uppgifter och ansvar inom en mjukvaruutvecklingsorganisation. Genom att tillämpa denna process kommer mjukvaruutvecklingsteam att kunna skapa högkvalitativ programvara som möter deras slutanvändares behov och göra det inom ett förutsägbart schema och budget.

RUP vägleder mjukvaruproffs att effektivt tillämpa nuvarande bästa praxis som t.ex iterativ utveckling, Ansökan arkitekturcentrerat tillvägagångssätt, användningsfall, riskminskning i alla skeden av processen och kontinuerlig programverifiering.

Rational Unified Process bygger på flera grundläggande principer, samlade från många framgångsrika projekt:

· Börja attackera huvudriskerna tidigare och genomför det kontinuerligt, annars kommer de själva att gå till offensiv mot dig.

· Se till att kundernas krav uppfylls.

· Koncentrera dig på programmet som körs.

· Anpassa till förändring redan från början av projektet.

· Etablera körbar arkitektur tidigt.

· Bygga ett system av komponenter.

·Arbeta tillsammans som ett team.

· Gör kvalitet till ett sätt att leva, inte en eftertanke.

RUP använder iterativt tillvägagångssätt Varje iteration gör lite kravarbete, analys, design, implementering och testning. Varje iteration bygger på resultaten från tidigare iterationer och producerar ett körbart program som tar ett steg närmare slutprodukten.

RUP tillhandahåller strukturerad metod för iterativ utveckling, som delar upp projektet i fyra faser: Inception, Design, Construction och Implementation. Varje fas åtföljs av en så kallad milstolpe, en kontrollpunkt för processen, där uppnåendet av målen för nästa fas kontrolleras, och ett beslut fattas om övergången (eller inte) till nästa fas. Var och en av de fyra faserna av RUP har alltså en milstolpe och en tydligt definierad uppsättning mål. Dessa mål används för att bestämma vilka uppgifter som ska utföras och vilka artefakter som ska skapas. Varje fas fokuserar strikt på vad som endast är nödvändigt för att uppnå fasens affärsmål.

Alla processelement - roller, uppgifter, artefakter och relaterade koncept, guider och mallar grupperas i logiska behållare som kallas Discipliner(Discipliner). Det finns bara nio discipliner i standardprodukten RUP. Dessa inkluderar: affärsmodellering, kravhantering, projektledning, förändringsledning och miljö.

Varje processarbetsflöde: kravinsamling, analys, design, implementering och testning definierar en uppsättning associerade artefakter och aktiviteter. Kom ihåg att en artefakt är ett dokument, rapport, exekverbart element, etc. Artefakt kan produceras, bearbetas eller konsumeras.

Modell- den viktigaste typen av artefakt. Nio modeller tillhandahålls, tillsammans täcker de alla lösningar för visualisering, specifikation, design och dokumentation av mjukvarusystem:

· affärsmodell. Definierar abstraktionen av organisationen för vilken systemet skapas;

· domänmodell. Fixar systemets kontextuella miljö;

· Användningsfall för modell. Definierar funktionskrav för systemet.

· analysmodell. Tolkar systemkrav i termer av designmodellen;

· designmodell. Definierar domänens vokabulär för problemet och dess lösning;

· placeringsmodell. Definierar hårdvarutopologin i vilken systemet körs;

· implementeringsmodell. Definierar de delar som används för att montera och implementera ett fysiskt system;

· testmodell. Definierar testfall för att testa systemet;

· processmodell. Definierar parallellitet i systemet och synkroniseringsmekanismer.

Tekniska artefakterär indelade i fyra huvuduppsättningar:

· kravuppsättning. Beskriver Vad systemet bör göra;

· design set.

· uppsättning implementeringar. Beskriver sammansättningen av utvecklade mjukvarukomponenter;

· placeringsset. Ger all information om den medföljande konfigurationen.

Uppsättning krav kan inkludera en Use Case-modell, en icke-funktionell kravmodell, en domänmodell, en analysmodell och andra former för att uttrycka användarbehov.

Design set kan inkludera en designmodell, en testmodell och andra former för att uttrycka systemets väsen.

Uppsättning implementeringar grupperar all data om mjukvaruelementen som utgör systemet (programkod, konfigurationsfiler, datafiler, programvarukomponenter, systemsammansättningsinformation).

Placeringsuppsättning grupperar all information om förpackning, frakt, installation och uppstart av systemet.

Varje teknisk process åtföljs risk. Vid utveckling av en mjukvaruprodukt kan ett otillfredsställande resultat (FN) vara: överskridande av budget, låg tillförlitlighet, felaktig funktion, etc. Effekten av risk beräknas med hjälp av uttrycket

Riskindikator = Sannolikhet (LP) * Förlust (LP).

Riskhantering innehåller sex åtgärder:

1. Riskidentifiering – identifiera riskelement i projektet.

2. Riskanalys – bedömning av förlustens sannolikhet och storlek för varje riskelement.

3. Riskrankning - sortera riskelement efter graden av deras inflytande.

4. Riskhanteringsplanering – förbereda sig för att hantera varje riskmoment.

5. Risklösning – eliminering eller lösning av riskelement.

6. Riskövervakning – spåra dynamiken i riskelement, vidta korrigerande åtgärder.

De tre första åtgärderna tillhör riskbedömningsstadiet, de tre sista åtgärderna till riskkontrollsteget.

Det finns tre kategorier av riskkällor: projektrisk, teknisk risk och kommersiell risk. Efter att ha identifierat riskelement bör deras inverkan på mjukvaruprojektet kvantifieras och frågor om eventuella förluster bör lösas. Dessa frågor tas upp under riskanalyssteget. Och slutligen är en plan för att hantera varje riskelement, det vill säga en uppsättning funktioner för att hantera varje riskelement, integrerad i den övergripande planen för programvaruprojektet.