Metodiky vývoje software, MDA

Metodiky vývoje software, MDA Karel Richta Katedra softwarového inženýrství Fakulta informačních technologií České vysoké učení technické v Praze © [email protected], 2011

Softwarové inženýrství I., BI-SI1 04/2011, Přednáška 10

Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

[email protected] (ČVUT)

Metodiky vývoje software, MDA

BI-SI1, 2011, Přednáška 10, 1/65

Metodiky vývoje software Klasické metodiky • Moderní strukturovaná analýza (MSA) • Unifikovaný proces vývoje (UP) Agilní metodiky • Extrémní programování (XP) • SCRUM Modelem řízený vývoj (MDD, MDA)




Proces vývoje software • Jedním ze základních cílů softwarového inženýrství je efektivní vytváření softwarových produktů. • Chceme-li vytvářet software efektivně, musíme studovat proces jeho tvorby – říká se mu také „softwarový proces“. • Musíme se zabývat otázkou, jak by se mělo postupovat, jaké fáze a kroky v životním cyklu produktu jsou podstatné, co je jejich vstupem a výstupem. • Musíme se zabývat otázkou, kdo tyto kroky realizuje, zda všichni dělají totéž, nebo se mohou specializovat. • Všechny takové znalosti můžeme shrnout do doporučení, jak organizovat proces vývoje – metodiky pro proces vývoje. • Metodika není metodologie (nauka o metodách). [email protected] (ČVUT)



Softwarové profese • • • • • • • • • • • • • • •

Manažer projektu Vedoucí týmu Procesní analytik Softwarový architekt Návrhář (rozhranní, API, grafik, …) Vývojář (ideový programátor, druhý programátor) Kodér Testér Manažer kvality Knihovník Specialista na jazyk, prostředí, knihovnu, … Dokumentarista Správce (sítě, aplikace, databáze, …) Redaktor obsahu …




Softwarové týmy • Software někdo vytváří. • Jedním z projevů přechodu od ruční výroby k manufaktuře je definice softwarových profesí. • Řešení velkých projektů vyžaduje spolupráci mnoha řešitelů a práci je nutno rozdělit. • Dělba práce vyžaduje organizaci týmů řešících větší softwarové projekty. • Týmy lze organizovat jako strukturované nebo nestrukturované.




Organizace týmů Nestrukturované týmy

Strukturované týmy

Dělí práci podle objemu. Mohou být organizovány jako: • „Osamělí vlci“ • „Horda“ • „Demokratická skupina“

Dělí práci podle profese. Mohou být organizovány jako: • „Chirurgický tým“ • „Tým hlavního programátora“ • „Agilní skupina“ • „Více-týmová organizace“




Kterou organizaci zvolit? • Volba organizace je dána rozsahem projektu a schopností zdrojů (liší se v rozsahu 1-20). • Pro menší rozsah lze použít nestrukturovaný tým. • Pro větší projekty se samozřejmě hodí strukturované týmy. • Máme-li dost prostředků, nejvýkonnější je chirurgický tým. • Nemáme-li, nejefektivnější může být tým hlavního programátora, agilní skupina, nebo demokratická skupina. • Na větší projekty je třeba více-týmová organizace (pravidlo 7±2).




Životní cyklus program. díla • • • • • • • • • • • •

Nápad Neformální specifikace (vize, odborný článek) Katalog požadavků (aktéři, úvodní studie) Formální specifikace (analýza) Dekompozice (návrh) Řešení komponent (modulů) Implementace komponent Testování komponent Integrace komponent do celku Testování celku (akceptační test) Instalace Provoz a údržba



Programování ve velkém

Programování v malém


Fáze tvorby SW produktu • Úvodní studie (informační plánování, feasibility study, sběr požadavků) – podklady pro rozhodnutí, zda vůbec má projekt smysl.

• Analýza (specifikace) – vytvoření dostatečně přesné specifikace produktu.

• Návrh (design) – dekompozice systému na komponenty, které lze naprogramovat .

• Implementace (konstrukce) – realizace komponent definovaných v návrhu a jejich sestavení do výsledného produktu. [email protected] (ČVUT)



Náročnost fází životního cyklu • Každý produkt by měl projít všemi fázemi životního cyklu. • Ze statistik (pro velké systémy – řádově stovky tisíc řádků kódu) vyplývá, že úsilí věnované těmto fázím by mělo být rozděleno zhruba v poměru: – analýza 40% – návrh 40% – implementace 20% • Pokud nevěnujeme počátečním fázím dostatečné úsilí, projeví se to zvýšenými nároky při implementaci či údržbě systému.



BI-SI1, 2011, Přednáška 10, 10/65

Modely životního cyklu • Pro standardizaci postupů jsou zavedeny typové modely životních cyklů, např.: – Model vodopád (Waterfall) – Model průzkumník – Spirálový model – Přírůstkový model • Model životního cyklu určuje základní schéma postupu. • Životní cyklus by měl vždy začínat dostatečně přesnou specifikací a návrhem. • Není nutno realizovat celý systém najednou – naopak přírůstky poskytují uživateli dobrý pocit postupu prací.



BI-SI1, 2011, Přednáška 10, 11/65

Model vodopád Nikdy se nevracet zpět



BI-SI1, 2011, Přednáška 10, 12/65

Přírůstkový model

Rozdělíme řešení na přírůstky



BI-SI1, 2011, Přednáška 10, 13/65

Spirálový model PROVOZ

IMPLEMENTACE



ANALÝZA

NÁVRH

BI-SI1, 2011, Přednáška 10, 14/65

Model průzkumník Nejsme schopni odhadnout dopředu, jak to dopadne



BI-SI1, 2011, Přednáška 10, 15/65

Jiné modely životního cyklu • Model RAD (Rapid Application Development) – model určený pro dobře srozumitelné a dobře vymezené problémy, s malými riziky, využívající krátký vývojový cyklus (cca do 3 měsíců), problém je rozdělen na samostatné moduly - model založen na rychlé tvorbě prototypů

• Evoluční model – využívá skládání komponent, které mohou být vyvíjeny současně, či zakoupeny a upraveny

• Formální metody – využívají specifikací řízený styl vývoje, tj. generování programů ze specifikací

• Extrémní programování a podobné techniky • Testy řízený vývoj (spirála s testy) [email protected] (ČVUT)


BI-SI1, 2011, Přednáška 10, 16/65

V-model Vodopád s testy

act V-Model

Úvodní studie

Akceptační testy

Analýza

Integrační testy

Návrh

Testy jednotek

Implementace



BI-SI1, 2011, Přednáška 10, 17/65

Metodiky pro softwarový proces • Co to je softwarový proces – umění, manufaktura, modelování? • Proces vývoje software by se měl řídit nějakým doporučením – sníží se tím pravděpodobnost chyb, opomenutí apod. • Doporučení jsou obvykle shrnuta do metodiky (angl. methodology). • Metodika je jen šablona, musíme ji přizpůsobit firmě, týmu, projektu, účelu (vývoj, provoz, přizpůsobení). • Metodika předepisuje postup, jeho kroky a artefakty získané v těchto krocích. • Skutečný proces vývoje pak využívá různé standardy, idiomy, předepsané formáty apod. [email protected] (ČVUT)


BI-SI1, 2011, Přednáška 10, 18/65

Taxonomie metodik • Klasické – – – –

Strukturované, objektové, komponentové Vodopád (MSA, SSADM) Unifikovaný proces (UP) RUP (Rational Unified Process)

• Agilní (vycházejí z manifestu agilních metod) – – – –

Testy řízený vývoj Extrémní programování (XP) SCRUM AUP (Agile Unified Process)



BI-SI1, 2011, Přednáška 10, 19/65

Moderní strukturovaná analýza (MSA) • Autoři E.Yourdon (analýza), M.Page-Jones (návrh). • Klasický vodopádový model. • Sběr požadavků – výstupem je odborný článek a hrubý model jednání. • Analýza (E.Yourdon): – Vytváří analytický model, který se skládá z datového modelu a funkční hierarchie – sady diagramů datových toků (diagramů aktivit), popisujících požadovanou funkčnost.

• Návrh (M.Page-Jones): – Výstup analýzy podrob tzv. transakční a transformační analýze a navrhni řešení.

• Implementace podle návrhu [email protected] (ČVUT)


BI-SI1, 2011, Přednáška 10, 20/65

act Moderní strukturov aná analýza (MSA) «centralBuffer» Hledání aktérů a případů užití

Model j ednání

Náv rh funkcí

Generalizace

«centralBuffer» Model chov ání

«centralBuffer» Doplnění dat

Datov ý model

Dekompzice

Transakční analýza

«centralBuffer» Transformační analýza



Logický model

BI-SI1, 2011, Přednáška 10, 21/65

MSA: Analýza • Vstupem je neformální specifikace (vize projektu). • Sestavte aktéry a případy užití (kontext). • Pro každý případ užití navrhněte funkci (proces), která bude tento případ obsluhovat. • Zjistěte potřebná data – pro každou funkci vymysli vstupní a výstupní data. • Proveďte generalizaci a dekompozici těchto funkcí. • Generalizací dospějete k modelu jednání, navrhněte strukturu „menu“ aplikace. • Dekompozicí postupně dojdete k elementárním funkcím, které již postačí popsat textově (pomocí tzv. minispecifikací). [email protected] (ČVUT)


BI-SI1, 2011, Přednáška 10, 22/65

MSA: Návrh • Proveď transakční analýzu - vezmi všechny diagramy datových toků (aktivity) a vyber z nich sadu pro každou transakci (případ užití). • Pro každý takto získaný popis transakce vysleduj jádro, které transformuje data – tzv. transformační analýza. • Z jádra učiň ředitele této transakce (řídicí třídu) a doplň komunikaci s třídami získávajícími vstupní data a formátujícími výstupní data. • K této sadě přidej tzv. transakční monitor: modul, který zjistí, o kterou transakci se jedná a vyvolá odpovídající řidící třídu.



BI-SI1, 2011, Přednáška 10, 23/65

Unifikovaný proces vývoje (UP) • UP je: – Průmyslový standard kostry vývojového procesu – Využívá notace UML (Unified Modeling Language) – Je to otevřený standard (na rozdíl např. od RUP – Rational Unified Process, dříve Rational, nyní IBM) – Základem je publikace Jacobson, Booch, Rumbaugh: „The Unified Software Development Process"

• UP je: – – – –

Řízen požadavky a případy užití (use case driven) Řízen rizikem Staví na architektuře, komponentách a znovupoužití Iterativní a přírůstkový proces

• UP je: – pouze generická metodika, musí být uzpůsobena pro danou firmu, projekt - standardy, šablony, nástroje, … [email protected] (ČVUT)


BI-SI1, 2011, Přednáška 10, 24/65

Agilní metodiky • • • • • • • • • •

Vycházejí z principů „Manifestu agilních metodik”. Psychologie týmu (http://agilemanifesto.org/) SCRUM (http://www.scrumalliance.org/) Crystal Clear (http://www.agilekiwi.com/crystal_clear.htm) XP - Extreme Programming (http://www.extremeprogramming.org/) Dynamic Systems Development Method Adaptive Software Development Feature–Driven Development Lean Development OpenUP



BI-SI1, 2011, Přednáška 10, 25/65

Extrémní programování (XP) Agilní technika vývoje softwaru, která dle „agilního manifestu“ upřednostňuje: • Týmovou spolupráci a interakci před formálními procesy a nástroji. • Fungující software před obsáhlou, komplexní dokumentací. • Spolupráci mezi zákazníkem a vývojáři před specifikacemi, zadáními, dohodnutými kontrakty. • Rychlou adaptaci na změny v zadání před dodržováním předem stanovených pravidel.



BI-SI1, 2011, Přednáška 10, 26/65

XP: Základní principy • • • •

Řízeno požadavky uživatelů (user stories). Vyvíjí se v iteracích. Pracuje se ve dvojicích. Co nejjednodušší návrh (neprogramujeme dopředu), okamžité testování. • Refaktorizace kódu, kód je společný - standardy pro kódování. • Co nejrychlejší zpětná vazba, uživatel součástí vývojového týmu, minimum dokumentace. • Nepřehánět zátěž - 40 hodin týdně.



BI-SI1, 2011, Přednáška 10, 27/65

12 technik používaných v XP • • • • • • • • • • • •

Plánování hrou Malé dodávky (releases) Metafory Jednoduchý návrh Párové programování Intezivní testování Refaktorizace kódu Kolektivní vlastnictví kódu Spojitá intergace 40 hodin/týden Zákazník součástí týmu Kódové standardy



BI-SI1, 2011, Přednáška 10, 28/65

Kdy se hodí XP? • Když je limitovaný čas nebo finance. • Když zákazník není přesně co chce, nebo není schopen dodat dostatečně přesné zadání. • Když zákazník chce spolupracovat na projektu. • Když se ví, že se bude systém měnit. • Když jsou členové týmu schopni spolupracovat a dobře spolu vycházejí.



BI-SI1, 2011, Přednáška 10, 29/65

Kdy se nehodí XP? • Když je nutný větší tým vývojářů (více než 15). • Když je vývojový cyklus (oprava, překlad, sestavení spuštění) příliš dlouhý (5 minut, hodina). • Když jsou testy příliš dlouhé (minuty, hodiny). • Když nelze zákazníka dostat do týmu. • Když zákazník nechápe principy XP.



BI-SI1, 2011, Přednáška 10, 30/65

Srovnání • XP představuje alternativu k UP, či vodopádovému modelu. • Není to nekoordinované „hackování“ kódu zdivočelými programátory. • Aby fungovalo, musí mít tým jisté zkušenosti a musí dodržovat všech 12 technik. • XP není všelék, hodí se jen někdy, ale někdy může přinášet lepší výsledky za kratší čas.



BI-SI1, 2011, Přednáška 10, 31/65

SCRUM (pojem z rugby) • Žádné týmové hierarchie, tým do 7 osob, pracuje se v jedné místnosti (osmóza), tým si volí šéfa (scrum master) • Krátké iterace (sprints) • Plánovací schůzka před každou iterací • Seznam akcí pro danou iteraci (backlog) • Denní skrumáže (co jsem udělal, co budu dělat, jaké mám problémy) • Retrospekce po každé iteraci (heartbeat session) • Vlastníkem kódu je tým - standardy pro kódování



BI-SI1, 2011, Přednáška 10, 32/65

Role v metodice SCRUM Metodika SCRUM stanovuje následující role: • vedoucí projektu (Scrum Master) – řídí procesy a celkovou práci, • zadavatel (Product Owner) – který reprezentuje zainteresované osoby (stakeholders) a • vývojář (TeamMember) – který zahrnuje členy týmu.



BI-SI1, 2011, Přednáška 10, 33/65

SCRUM - postup • Vytvoření plánu projektu (project backlog) – Sestavení případů užití (user stories) – Definice potřebných úloh (sprintů).

• Realizace plánu projektu – – – –

Výběr sprintu (sprint backlog) Realizace sprintu Denní setkání (SCRUM Meetings, Sledování postupu

skrumáže) (burndown graf).

Zdroj: Wikipedia [email protected] (ČVUT)


BI-SI1, 2011, Přednáška 10, 34/65

Agilní přístupy a dokumentace • Představa, že v agilních metodikách se nevytváří žádná dokumentace, či modely, ale pouze kód, není pravdivá. V agilních metodikách modelujeme, dokumentujeme, ale pouze v jiné formě a pouze to, co je nezbytně nutné. • Uživatelské příběhy (user stories) popisují funkčnost a detaily jsou zachyceny v testech. • Další dokumentací je samozřejmě dobře strukturovaný a komentovaný zdrojový kód. • Modely také existují ale například pouze jako náčrty na tabuli či na papíře. Jelikož jsou běžné krátké obrátky, kód se často mění (refaktoruje), stálo by přepracování modelů či jiných dokumentů spoustu úsilí nebo by se tyto staly brzy neaktuální, proto opravdu dokumentujeme jen důležité věci.



BI-SI1, 2011, Přednáška 10, 35/65

Agilní přístupy a architektura • Není pravda, že v agilních metodikách nenavrhujeme žádnou architekturu – je pravdou, že na začátku projektu si nesedneme ke všem požadavkům (protože je ani nemáme) a neřešíme „papírovou architekturu“. • V úvodních iteracích ale řešíme určitou kostru aplikace, vrstvy, způsob ukládání dat, komunikaci s ohledem na celé řešení, definujeme rozhraní vrstev, jelikož toto mohou být zásadní technické problémy (např. integrace se zastaralým – „legacy“ - bankovním systémem, pravidelné dávkové importy, implementace standardů), které mohou silně ovlivnit celé řešení – použitou technologii, způsob komunikace mezi vrstvami, nutnost prototypů apod. • Detailní architekturou se pak zabýváme vždy jen pro danou iteraci (tj. jen pro scénáře které nyní implementujeme), neřešíme architekturu s ohledem na požadavky, které bychom měli implementovat v budoucích iteracích, protože se mohou změnit priority, tyto požadavky se mohou posunout do dalších verzí, či úplně zrušit a naše snaha může přijít vniveč. Neděláme tedy architekturu „do šuplíku“, ale jen pro aktuální potřebu.



BI-SI1, 2011, Přednáška 10, 36/65

Agilní jsou/mají být jen vývojáři? • Agilní nemohou být jen vývojáři, obchodníci a management musí agilnímu přístupu rozumět také. • Pokud zákazníkovi řekneme (tedy spíše naši obchodníci), že jsme schopni dodat opravdu všechno, co si vymyslel, za tu cenu, v tom čase a v té kvalitě (což se opravdu často děje), bez ohledu na to, co říká trojúhelník kvality, pak nás samozřejmě ani agilní přístupy nezachrání. • Pokud zákazník nebude chtít spolupracovat, nebude se chtít účastnit pravidelných schůzek (user play), kde si hraje s dosud vyvinutým řešením, komentuje se a připomínkuje, nelze očekávat úspěch. • Musíme zákazníka učit, vysvětlovat, proč je nutné vidět aplikaci a korigovat své i naše představy, že jen tak dostane opravdu to, co očekával. • Je to těžké, protože zákazník byl po léta zvyklý na začátku nadiktovat všechny, tedy i ty nepotřebné požadavky (kterých je podle Standish Group více než polovina) a na konci očekával řešení.



BI-SI1, 2011, Přednáška 10, 37/65

Podpora vedení firmy není třeba? • Podpora vedení firmy je velmi důležitá. Nestačí, aby vedení vývojářům řeklo: „ano, nějak si to teda udělejte (rozuměj zaveď agilní metodiku)“ – to je další častou chybou a naivní představou. • Co je ještě horší, je zavádět agilní praktiky a životní cyklus potají. Tajné zavádění či nedostatečná podpora ze strany managementu v podstatě úplně zhatí celou snahu, jelikož bez podpory managementu (který má tuto vizi protlačit) a bez oficiálních prostředků a schválení (vývojáři absolvují tréninky, zpomalí se tempo vývoje) agilní přístup ani zavést nelze, jedná se totiž o úplnou změnu chování a myšlení všech lidí v organizaci a také o změnu vystupování směrem k zákazníkovi (což potají moc dobře nejde :-). • Standish Group řadí podporu managementu (executive support) na 1. místo svého pravidleného tzv. „Chaos report“, který popisuje situaci ohledně projektů v IT. Angažovanost uživatelů v projektu řadí až na 2. místo.



BI-SI1, 2011, Přednáška 10, 38/65

Agilní přístupy obecné shrnutí • Agilní přístupy jako Scrum, XP, Lean development, OpenUP, AUP apod. většinou představují sadu doporučení, co se v praxi osvědčilo. • Metodika přesně říká co, kdy, kdo a jak má dělat. Zde se často popisují kroky, které je možné provádět při vývoji software, jaké artefakty mohou zachycovat různé informace, prostě jaké činnosti se v praxi osvědčily. • Na nás pak je, abychom si vybrali, co konkrétně nyní potřebujeme, uznáme za vhodné dělat, tj. vytvořili si vlastní proces.



BI-SI1, 2011, Přednáška 10, 39/65

Nutné je přizpůsobení metodiky • Je to pochopitelné, každá organizace je jiná, má jinou strukturu, kulturu, distribuce týmu se různí, členové týmu mají jiné zkušenosti a znalosti, jejich povahové rysy jsou různé, také zákazník se chová jinak. • Proto není možné postupovat vždy podle stejné či podobné metodiky, ale je třeba si daný proces vývoje upravit podle potřeb daného projektu (přesně toto doporučují či říkají dané přístupy). • Samozřejmě je třeba dodržet a následovat určité zásady a principy. • Funguje to stejně jako s bufetem ve formě švédských stolů. Bereme si jen to, co máme rádi (ne všechno – častá dezinterpretace UP, že je příliš těžkopádná; nikde však není psáno, že máme dělat vše, co UP popisuje), s čím máme dobré zkušenosti, sem tam zkusíme něco nového a snažíme se tomu přijít na chuť, ale musíme dodržovat určité zásady. Jídlo dáváme na talíř, většinou jíme příbory, nápoje naléváme do skleniček apod.

Zdroj: Procházka: Problémy s adopcí agile přístupů [email protected] (ČVUT)


BI-SI1, 2011, Přednáška 10, 40/65

Snaha o standardizaci • V roce 1979 vytváří Fletcher Buckley standard IEEE 370 pro vytváření plánů zajišťujících kvalitu software. • V roce 1986 vzniká standard IEEE 1002, který definuje taxonomii softwarově inženýrských standardů. • 1990 – 1995 vznikají standardy pro proces životního cyklu software (Standard for Software Life Cycle Processes) - standard ISO/IEC12207, vychází z DoD Std 498. • Standardizováno je všechno možné (např. ISO 5218 - reprezentace pohlaví). • Vznikají normy jako CMMI, ISO. • Standardy pro řízení procesu vývoje ISO 9001:2000. • CMMI je zkratkou z anglického The Capability Maturity Model Integration - volně přeloženo: integrovaný, účinný a funkční model řízení procesů vývoje. Jedná se o soubor pravidel, požadavků a doporučení, které mají splňovat firemní procesy a co je třeba dodržovat, aby procesy vývoje byly efektivní, účinné a spolehlivé. [email protected] (ČVUT)


BI-SI1, 2011, Přednáška 10, 41/65

Modelem řízený vývoj • Model vzniká vždy. Někdy bohužel jen v hlavách vývojářů. • Sdružení OMG propaguje přechod na modelem řízený vývoj MDA Guide (http://www.omg.org/mda). Alternativní označení MDD (Model Driven Development), či dokonce MDE (Model Driven Engineering) • Model je kombinací textu a diagramů. • Model by měl být „čitelný“ i bez diagramů. • Diagramy „pouze“ usnadňují pochopení základní myšlenky popisovaného. • Každý digram by měl obsahovat pouze jednu myšlenku. • Vytváření modelu je tedy převážně mentální úsilí vyúsťující v psaní textu a kreslení diagramů. [email protected] (ČVUT)


BI-SI1, 2011, Přednáška 10, 42/65

Proč modely vytvářet? • • • • • •

„Zaměstnanci přicházejí a odcházejí, modely zůstávají.“ Znovu-použitelnost (firemní know-how). Sledovatelnost realizace požadavků. Zvýšení udržovatelnosti produktů. Možnost kontroly, animace. Možnost automatizovaného zpracování.



BI-SI1, 2011, Přednáška 10, 43/65

Modelem řízený vývoj (OMG) Doménový model Konceptuální model

Logický model

ISM (Implementation Specific Model

Zdroj: Materiály OMG [email protected] (ČVUT)


Fyzický model

BI-SI1, 2011, Přednáška 10, 44/65

Reverzní inženýrství • Reverzní inženýrství v informatice je definováno jako „proces analýzy předmětného systému s cílem identifikovat komponenty systému a jejich vzájemné vazby a/nebo vytvořit reprezentaci systému v jiné formě nebo na vyšší úrovni abstrakce“ (Wikipedie). • Reverzní inženýrství řeší v České republice Autorský zákon tedy zákon 121/2000Sb. – § 65 (2) Myšlenky a principy, na nichž je založen jakýkoli prvek počítačového programu, včetně těch, které jsou podkladem jeho propojení s jiným programem, nejsou podle tohoto zákona chráněny. – § 66 Omezení rozsahu práv autora k počítačovému programu. Do práva autorského nezasahuje oprávněný uživatel rozmnoženiny počítačového programu, jestliže: • b) jinak rozmnožuje, překládá, zpracovává, upravuje či jinak mění počítačový program, je-li to nezbytné k využití oprávněně nabyté rozmnoženiny počítačového programu v souladu s jeho určením, není-li dohodnuto jinak, • d) zkoumá, studuje nebo zkouší sám nebo jím pověřená osoba funkčnost počítačového programu za účelem zjištění myšlenek a principů, na nichž je založen kterýkoli prvek počítačového programu, činí-li tak při takovém zavedení, uložení počítačového programu do paměti počítače nebo při jeho zobrazení, provozu či přenosu, k němuž je oprávněn.



BI-SI1, 2011, Přednáška 10, 45/65

Okružní jízda („Round-Trip“) • Sen OMG. • Vezmu existující systém, reverzním inženýrstvím z něj udělám model, ten opravím a vygeneruji novou verzi systému. • Vezmu model z repositáře, upravím model podle požadavků, vygeneruji pracovní verzi systému, opravím v ní chyby, reverzním inženýrstvím z ní vytvořím opravený model, který schovám do repositáře.



BI-SI1, 2011, Přednáška 10, 46/65

Okružní jízda (Round-Trip) Doménový model (CIM)

Analýza

Návrh

Konceptuální Model (PIM)

Logický model (PSM)

Reverzní inženýrství

Implementace

Fyzický model (ISM – kód) Provoz



BI-SI1, 2011, Přednáška 10, 47/65

Podmínky pro okružní jízdu • • • •

Nástroje pro práci s modely na všech úrovních. Nástroje pro transformace modelů v obou směrech. Řada nástrojů již umí některé přímé transformace. Např. pro datový model se umí generovat různé PSM z konceptuálního PIM. • Speciálně pro relační platformu generují z konceptuálního PIM relační model (PSM) a posléze také SQL (ISM). • Méně nástrojů umí zpětné transformace. • Řada nástrojů umí vyrobit z kódu (ISM) jistou část platformově specifického modelu, např. z SQL relačního PSM.



BI-SI1, 2011, Přednáška 10, 48/65

The End



BI-SI1, 2011, Přednáška 10, 49/65

Metodiky vývoje software, MDA

Recommend Documents