Enterprise Architect 10

Po několika týdnech čekání, dvou beta verzích a jednoho kandidáta na ostrou verzi tu máme konečnou podobu Enterprise Architecta 10 (sestavení 1004). Přehled zásadních novinek je na úvodní stránce produktu, podrobné změny pak najdete v historii jednotlivých vydání. Stahujte tedy novou verzi a studujte změny, je jich tam dost.

Informační toky a jejich použití v EA

Informační tok definuje obecné předávání informací v systému a to na té nejvyšší úrovni abstrakce. Nespecifikuje se ani povaha informace (typ, počáteční hodnota…), ani mechanismus, kterým výměna informací probíhá. Dokonce se neurčuje ani pořadí či podmínky pro možnost výměny. K tomu je určena až některá z následných – detailnějších – fází návrhu, ve které lze určit, které prvky přenášenou informaci reprezentují a které vztahy daný tok realizují.

Informační tok

Pro zavedení informačního toku do modelu se používá vztah InformationFlow, který říká, že jedna či více informací putuje ze svého zdroje do svého cíle. Zobrazuje se přerušovanou čarou zakončenou šipkou směrem k příjemci informace. U čáry je uvedeno klíčové slovo «flow». Pozor na to, že byť je čára přerušovaná, nejde o závislost (tj. přímou či nepřímou specializaci třídy Dependency metamodelu).

Poblíž čáry jsou pak dále textově zobrazeny i jednotlivé informace, které jsou tokem přenášeny (viz dále).

Příklad notace informačního toku

Postup v EA: V Enteprise Architektu je vytvoření informačního toku hodně jednoduchou záležitostí.  Najdeme jej v ToolBoxu v části Common. Hned po vytvoření vztahu mezi objekty se zobrazí dialog pro zadání informací (Information Items Conveyed), které tok přenáší. Záhy se k němu dostaneme.

Toolbox Classes

Informační tok může být podle UML standardu zaznamenán pouze mezi těmito prvky: Actor, Node, UseCase, Artifact, Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition a InstanceSpecification (navíc pokud zdroj či cíl je InstanceSpecification, nemůže jeho typ představovat třídu Relationship či libovolnou její specializaci). Zde je nutné uvést, že Sparx „zapomněl“ toto pravidlo v Enterprise Architectu implementovat a tak lze mít celkem jednoduše (tak, jak v mnoha ostatních případech) nevalidní model.

Informace

Informační tok může přenášet informaci v podobě nějakého klasifikátoru (např. třída) nebo informaci v nedefinované struktuře – třída InformationItem (což je nakonec také klasifikátor). Informace (již zmíněná třída InformationItem) je abstrakcí libovolného typu informace, kterou si mohou objekty mezi sebou vyměňovat. Jde o blíže neurčený klasifikátor pro reprezentaci informace na hodně abstraktní úrovni, tj. na takové, na které z ní nelze vytvořit instanci (prostě proto, že nelze přesně říct, o jaký typ, resp. klasifikátor jde). Informace nemá ani vlastnosti, ani asociace a ani na ni nelze použít generalizaci. Také z ní nelze vytvořit instanci.

Notace: Protože InformationItem je klasifikátor, lze informaci zobrazit jako obdélník s názvem informace a klíčovým slovem «information» nad názvem. Alternativní notace je opět obdélník s názvem a v pravém horním rohu je plný rovnoramenný trojúhelník „ukazující“ doprava (aniž by však měl jakoukoliv spojitost se směrem případného toku!).

Příklad notace třídy InformationItem

Postup v EA: V Enterprise Architectu najdeme Information Item v Toolboxu s objektovými prvky (Object). Pokud to někoho překvapuje, pak si uvědomte, ve kterých situacích to používáte: např. na naprostém začátku projektu při vyjednávání požadavků a prvních rozhovorech o analytických třídách. A zde se bavíte především v instancích.

Toolbox Object

Informace se většinou zobrazuje jako součást informačního toku nebo jako součást vztahu (informačního kanálu), který informační tok realizuje. V prvním případě se zobrazuje název informace poblíž čáry realizačního toku (viz příklad výše). V druhém případě se zobrazí černý trojúhelník směřující k příjemci informace přímo na čáře vztahu. Název informace se pak zobrazí poblíž tohoto trojúhelníku. Pokud vztah realizuje více přenosů informací stejným směrem, pak se zobrazí jen jeden trojúhelník a jednotlivé názvy informací se oddělí čárkou.

Příklad realizace informačního toku

Postup v EA: Abychom určili, které informace jsou informačním tokem přenášeny, potřebujeme již výše zmíněný dialog Information Items Conveyed. Ten se zobrazuje po vytvoření vztahu mezi prvky modelu nebo jej můžeme vyvolat přes kontextové menu informačního toku z položky Advanced ► Information Items Conveyed…  V něm pomocí tlačítek Add a Remove můžeme upravovat seznam informací, které jsou tokem přenášeny.

Dialog Information Items Conveyed

Pro přenesení dat je nutné mít nějaký „informační kanál“, který pak bude daný přenos realizovat. V UML se reprezentuje různými způsoby s ohledem na povahu zdroje a cíle. Těmito způsoby jsou asociacemi, linky, konektory a závislosti.

Postup v EA: Aby se uvedený vztah stal realizátorem informačního toku, stačí málo. Pomocí kontextového menu vztahu Advanced ►Information Flows Realized… vyvoláme stejnojmenný dialog. V něm se zobrazí seznam informačních toků mezi stejnými elementy, jako máme náš vztah. Zde pak stačí zaškrtnout požadované položky.

Dialog Information Flows Realized

Reprezentace informace

Konečně poslední věc, kterou v souvislosti s informačními toky zde zmíním, je reprezentace informace. Jde o vztah mezi informací (InformationItem) a klasifikátory, které budou (na nižší úrovni abstrakce) určovat strukturu dané informace. Těmito klasifikátory mohou být pouze třídy Class, Interface, InformationItem, Signal a Component.

Příklad notace reprezentace informace

Postup v EA: Enteprise Architect zde pro zobrazení používá svou oblíbenou prasárnu, tj. klasickou závislost se stereotypem «representation». Pozor však na to, že ve skutečnost opravdu o žádnou závislost ve smyslu třídy Dependency v UML nejde. V EA tedy můžeme vytvořit závislost a přidat uvedený stereotyp nebo použít ikonu reprezentace v Toolboxu Composite, která dělá totéž.

Toolbox Composite

Odkaz do standardu

• V aktuální verzi UML, tj. v době vydání článku to je 2.4.1, je to kapitola 17.2.
• V beta verzi UML 2.5 je to kapitola 20.

Stereotypová omalovánka

V jedné z nejlepších českých pohádek je scéna, kde podřízený chce navést svého nejvyššího na konkrétní místo v dokumentu. Ten ho však odbude slovy: Mrknu a vidím. Dneska vám představím možnost Enterprise Architecta, která dokáže čtenáře dostat do stejné situace: mrknout a vidět.

Nejprve si nastiňme problematiku. Řekněme, že máme model, ve kterém chceme zvýraznit elementy, které se v rámci projektu změnily, které se přidaly či ubraly a samozřejmě takové, které zůstaly na produkčním prostředí nedotčeny. Informaci budeme uchovávat pomocí následujících stereotypů:

• deployed – říká, že v našem projektu v daném elementu ke změně nedošlo,
• new – oznamuje zavedení nového elementu,
• modified – odkazuje na změnu a
• decommissioned – sděluje publiku, že element byl v rámci projektu odstraněn.

Jeden z takových příkladů může vypadat takto (ke stažení zde):

Stále však nejsme v cílovém stavu. Zde musí čtenář diagramu dost číst, aby „viděl“. Enterprise Architect si tedy nastavíme tak, aby se automaticky každý element přebarvil barvou odpovídající aktuálnímu stereotypu. K tomu potřebujeme nejprve vlézt přes menu Settings ► UML Types… do dialogového okna nazvaného UML Types.

Na záložce Stereotypes si v seznamu najdeme postupně každý z námi zavedených stereotypů a provedeme pro ně následující nastavení: 

Base Class změníme na <all>. Tím bude nastavení platit pro každý element s tímto stereotypem. Pole Notes můžeme změnit, chceme-li. A teď to nejdůležitější: dle libosti si vyberte výchozí barvy pro výplň, okraje a/nebo font. Jakmile budete mít hotovo, je nutné stisknout tlačítko Save.

Máte-li hotovo, pak výsledek může vypadat přibližně takto (za zvolené barvy se omlouvám, na tohle nemám cit):

Jakmile se s barvami sžijete, můžete potlačit zobrazování stereotypů (přes kontextové menu digramu vyberte dialog Properties… a na záložce Elements odškrtněte Show Element Stereotypes) a obrázek bude zase o něco přehlednější, přesně ve stylu Mrknu a vidím.

Pár tipů:

• Pokud nejprve zavedete stereotypy a až pak je nastavíte, pak v seznamu budete mít zavedený pro každý element jeden stereotyp (např. pro třídu a komponentu zvlášť). Buďto tedy nejprve nastavte stereotypy a až pak je u elementů používejte (další změna barvy je pak bez uvedeného efektu) nebo stereotyp dle uvedeného postupu a ostatní stejného jména smažte.
• Stereotyp lze nastavit každému prvku, tedy i např. atributům tříd či vztahům. Má-li to význam, používejte je.
• V případě atributů však nedochází k jejich obarvení (viz uvedený obrázek a v něm výčet).
• V případě vztahů můžete měnit barvu čáry a fontu.
• Každému elementu lze nastavit libovolné množství stereotypů. Enterprise Architect bere barvu podle prvního stereotypu v pořadí.
• Pokročilejší uživatelé mohou využít možnosti měnit nejenom barvu, ale napsat si kompletní skript pro vlastní vizualizaci prvku.
• Nastavení lze přenášet mezi jednotlivými projektovými soubory (*.EAP) pomocí exportu a importu referenčních dat (menu Tools ►Export Reference Data… resp. Import Reference Data…).

A na závěr snad už jen ona scéna, o které jsem mluvil v úvodu. Důležitý okamžik je na druhé minutě a dvaadvacáté sekundě.

Enterprise Architect 10 v první betě

Konečně jsem se dostal k tomu, abych informoval i o možnosti podívat se na připravovanou desátou verzi jednoho z nejpoužívanějších nástrojů pro modelování v UML Enterprise Architect. Registrovaní uživatelé si ji mohou stáhnout a začít zkoušet. Já si ji již nainstaloval a brzy poreferuji o svých dojmech.

UML 2.5 Beta 1 je na světě

Před několika málo dny byla vydána dlouho očekávaná první beta verze UML 2.5. Pokud můžeme věřit tomu, co se o ní šíří po Internetu (dobré je sledovat např. Eda Seidewitze), pak by měla obsahovat především zásadní zjednodušení jazyka jako takového. Zřejmě nejdůležitější je zrušení konceptu infrastruktury a superstruktury a nepoužívání operace merge (viz PackageMerge) v metamodelu.

Sám jsem se zatím dokumentem neprokousával, ale jakmile najdu trochu času, budu zde průběžně psát své pocity z nové verze.

Stokrát nic umořilo uživatele Enterprise Architecta

Ačkoliv je práce analytika či návrháře řešení značně tvůrčí, můžete se dostat do situace, kdy opět a opět děláte to samé, aniž by vás to jakkoliv bavilo. Vezměte si takový diagram aktivit. Kolikrát jste již za svůj život přetáhli na plochu počáteční a koncový uzel, k nim pár akcí a propojili je řídícím tokem? Kolikrát jste znovu a znovu přetáhli aktora, systém a pár případů užití? Po několika takových diagramech to začne být nuda, které se však lze vyhnout.

K řešení využijeme návrhové vzory (Design Patterns). Ty jsou silnou pomůckou při analýze, návrhu i programování. Pod tímto vznešeným názvem se skrývá velmi jednouchá myšlenka. Pokud nějaký problém řeším opakovaně, pak si pro něj připravím šablonu a tu napasuju na další výskyt téže problematiky. Ušetřím si tím práci.

V praxi se lze setkat s „velkými“ návrhovými vzory (povolené kombinace, přemostění, adaptér…), ale my zůstaneme při zemi. V dalším textu raději nebudu používat spojení návrhový vzor, ale slovo šablona, protože to více odpovídá situaci.

Následující postup (použit Enterprise Architect 9.3.933) ukazuje, jak si připravit šablonu pro již zmíněný počátek diagramu aktivit.

1. V prvním kroku si vytvořte (ještě jednou, ale již naposledy) jednoduchý diagram aktivit:
   
   
   
   
   
2. Nyní v hlavním menu zvolte dialog Diagram ► Advanced ► Save UML Pattern… Vypadá takto:
   
   
   
   
   
3. Zadejte název šablony (Pattern Name), soubor, do kterého se uloží (Filename), kategorii (Category) a přidejte poznámku (Notes). Zbytek nastavení můžete ignorovat.
4. Po stisku tlačítka OK se na disku vytvoří zvolený soubor, který je možné načíst do libovolného projektového souboru (*.EAP).
5. Načtení se prování v okně zdrojů (Resources). Pokud jej nemáte otevřené, provede tak z menu View ►More Project Tools ►Project Resources.
6. V okně zdrojů uvidíte stromovou strukturu, ve které je mj. položka UML Patterns. Zvolte její kontextové menu a vyberte (jedinou) položku, která se jmenuje Import UML Pattern.
7. Otevře se dialog na výběr souboru, vy zvolte ten, který jste před chvílí vytvořili. Tip: zde lze v jednu chvíli vybrat souborů více.
8. Jakmile jej vyberete, EA vytvoří (pokud již neexistuje) větev, která se bude jmenovat stejně jako kategorie, kterou jste zadali výše. V ní bude vaše šablona se zvoleným jménem.
9. Nyní máte vše připravené a nic vám nebrání šablonu použít. Otevřete si libovolný diagram a šablonu do ní z okna zdrojů jednoduše přetáhněte.
10. Zobrazí se dialog, ve kterém uvidíte popis vaší šablony, náhled a prvky, které budou do diagramu (a potažmo modelu) vloženy:
    
    
    
11. Před stiskem tlačítka OK můžete prvky přejmenovat (zvolte tři tečky na konci řádku s daným prvkem).
12. Po stisku tlačítka OK se prvky přenesou do vašeho diagramu.

Tento postup lze použít pro libovolný typ diagramu a prvky v něm uvedené.

Enterprise Architect pro vás připravil ty nejprofláklejší návrhové vzory od gangu čtyř (Gang of Four, GoF). Pokud je ve vaší edici EA nemáte, lze je stáhnout z webu Sparxu.

Dá se blog psát v UML?

Na Internetu jsem narazil na myšlenku psát si (vlastně modelovat) blog v UML. Zaujala mě. O čem bych modeloval? Jaké diagramy bych používal? Osobně nemám moc rád strukturální diagramy, protože se v nich nic neděje, ale na druhou stranu pro zápis vět typu „byl jsem tam a tam“ diagramem aktivit nepřináší UML žádnou přidanou hodnotu. Přepis rozhovoru např. mezi mnou a dětmi v sekvenčním diagramu může vypadat pěkně jednou, dvakrát, ale pak se to ohraje.

Přesto jsem o tom přemýšlel dál a vzpomněl si na objektové diagramy. Pokud si udělám rozumný doménový model a poté vytvořím objektový diagram, možná by se v tom něco jako příběh mohlo najít. UML je hodně intuitivní i pro lidi, kteří jej neznají, takže by z toho mohli něco mít. Pohrál jsem si s tím a tady je můj záznam z úterý. Co z toho vyčtete?

class Workout Domain Model

object Tuesday

Přenos požadavků z Wordu do Enterprise Architectu

V minulém povídání jsem ukázal, jak relativně jednoduše přenést požadavky z Excelu do Enterprise Architectu. Dnes předvedu, jak toho lze dosáhnout z Wordu. Mnohé společnosti totiž své požadavky píší právě v něm.

Postup tentokrát bude trochu složitější, ale většinu jsem pro vás připravil. Jak tedy na to? Především se podívejme na to, jak se požadavky ve Wordu zaznamenávají. Já jsem vycházel z jednoduché tabulky (ne, nebudu zapírat, že v praxi „mí“ zadavatelé používají právě ji) ve Wordu, kde první sloupec je identifikace (jedinečný název) požadavku, text požadavku, priorita a vlastník. Identifikace je povinná, ostatní je volitelné (soubor si můžete stáhnout):

 
Uvedená tabulka musí splňovat ještě některé další podmínky:

• Žádný řádek ve sloupcích nesmí začínat rovnítkem (níže řeknu proč).
• Text v tabulce nesmí být formátovaný (pokud přesto je, je toto formátování při převodu ignorováno).
• V tabulce nesmí být použity obrázky, vložené dokumenty a další netextové prvky (nebudou přeneseny).

Všimněte si také, že identifikace začíná zkratkou BR (Business Requirement) a dále číslem. Jednoduše v nich poznáte hierarchickou strukturu. Důležité je oddělovat jednotlivé úrovně tečkou, přičemž tyto úrovně musí být uvedeny na konci celé identifikace požadavku. Na začátku může být cokoliv. Tedy např. BR_1 a pak BR_1.1, nebo místo podtržítka mezera, místo BR slovo Požadavek nebo to může být úplně bez textu, jen s čísly. Ve Wordu lze navíc použít automatické číslování.

Vlastní převod bude probíhat s mezikrokem, který už dobře známe. Ano, přeneseme požadavky do Excelu. Ve Wordu označte celou tabulku (najeďte na ni myší, v levém horním rohu tabulky se objeví křížové šipky, na ně klikněte). Zkopírujte celou tabulku do schránky (pravé tlačítko myši nad křížovými šipkami a v kontextovém menu zvolit Kopírovat/Copy).

Nyní je třeba otevřít si Excel, ale pozor, nepůjde o libovolný sešit, ale je třeba si stáhnout speciální soubor s makrem (hned se k němu dostaneme), takže při otvírání je třeba makra povolit. Na záložce BR z Wordu pak označte pole A1 a vložte tabulku z Wordu. Výsledek bude vypadat přibližně takto:

Všimněte si jedné věci: u požadavku BR 1.3 jsem porušil pravidlo zákazu formátování textu. Tím jsem dostal nepříjemné rozdělení, ale zrovna s tímhle se skript popere se ctí.

V Excelu ze záložky View zvolte Macros a spusťte makro nazvané SpojPožadavky (jiné tam v seznamu stejně není).

Nyní se přepněte na záložku Požadavky pro EA. Uvidíte známou strukturu požadavků, jak jsme si ji ukazovali v předchozím článku.

Nyní tedy již zbývá jen uložit tento list jako CSV soubor a importovat do Enterprise Architectu. Definice importu je zřejmá:

Po importu se v Project Browseru objeví následující struktura:

Je vidět, že tentokráte nejsou použity balíky (Packages), ale vnořuji požadavky přímo do sebe (což ale lze ovlivnit úpravou makra).

Proč je to celé složitější a jak to funguje?

Postup je složitější z prostého důvodu: Enterprise Architect neumí přímý import z wordového dokumentu (abych byl upřímný, šlo by to pomocí OLE Automation např. přímo z Wordu, ale do toho se pouštět nechci). Proto bylo nutné udělat tento mezikrok s Excelem, který navíc použijeme pro přeformátování tabulky, která je sice příjemná zadavatelům, ale pro nás není úplně dostačující.

Klíčovým prvkem je skript v Excelu, který vykoná dost práce. Nejprve si jej můžete prostudovat:

    'maximální počet řádků, které ve vstupním sheetu zpracuju
    Const aMaxLinesToProcess As Integer = 5000
    
    'Konstanty listu Vstup
    Const cVstupSheet As String = "BR z Wordu"
  
    'Konstanty listu Výstup
    Const cVystupSheet = "Požadavky pro EA"


    'Globální proměnné
    Dim lVystupRow As Integer
    Dim shtVstup  As Worksheet  'list, kde najdu vstupní BR
    Dim shtVystup As Worksheet  'list, kam davam naformatované BR

Sub ClearSheet(ws As Worksheet)
    'vyčistí prvních 30 sloupců kromě prvního řádku
    'asi existuje elegantnější řešení, ale nemá cenu se jím trápit
    
    Dim lindex As Integer
        
    For lindex = 1 To 30
        lchar = Chr(lindex + 64) 'převedu si na znak "A" a vyšší
        
        If ws.Cells(ws.Rows.Count, lindex).End(xlUp).Row > 1 Then
            ws.Range(lchar & "2", ws.Cells(ws.Rows.Count, lindex).End(xlUp)).Clear
        End If
    
    Next lindex
End Sub

Sub WriteRequirement(aBR As String, aNotes As String, aPriority As String, aAuthor As String, aCSVKey As String, aCSVParentKey As String)
'zapíše jeden požadavek dle znění daného parametry na řádek dle globální proměné lVystupRow, kterou následně ještě navýší
    shtVystup.Cells(lVystupRow, 1).Value = aBR
    shtVystup.Cells(lVystupRow, 2).Value = aNotes
    shtVystup.Cells(lVystupRow, 3).Value = aPriority
    shtVystup.Cells(lVystupRow, 4).Value = aAuthor
    shtVystup.Cells(lVystupRow, 5).Value = "Requirement"
    shtVystup.Cells(lVystupRow, 6).Value = aCSVKey
    shtVystup.Cells(lVystupRow, 7).Value = aCSVParentKey
    lVystupRow = lVystupRow + 1
End Sub

Sub AppendTextToPreviousRequirement(aText As String)
'přidá text požadavku k předchozímu
    If lVystupRow > 2 Then
        shtVystup.Cells(lVystupRow - 1, 2).Value = shtVystup.Cells(lVystupRow - 1, 2).Value & Chr(10) & aText
    End If
End Sub

Function GetCSVKey(aText As String) As String
'z textu udělá klíč pro označení daného BR tak, že ořeže bílé znaky na začátku a na konci řetězce
    Dim znak As String
    Dim ascc As Integer
    
    'nejprve na konci (prostě proto, že mám na výběr a tedy chci) - ve skutečnosti to můžeme považovat za optimalisaci
    znak = Right(aText, 1)
    While (znak = ".") Or (znak = " ") Or (znak = Chr(9)) Or (znak = Chr(7)) Or (znak = Chr(160))
        aText = Left(aText, Len(aText) - 1)
        znak = Right(aText, 1)
    Wend
    
    'a pak na začátku
    znak = Left(aText, 1)
    While (znak = ".") Or (znak = " ") Or (znak = Chr(9)) Or (znak = Chr(7)) Or (znak = Chr(160))
        aText = Right(aText, Len(aText) - 1)
        znak = Left(aText, 1)
    Wend
        
    GetCSVKey = aText
    Exit Function
End Function

Function GetCSVParentKey(aText As String) As String
'rodič je určen odebráním posledního místa s tečkou
    If aText = "" Then
        GetCSVParentKey = ""
        Exit Function
    End If

    Dim lPointPos As Integer
    lPointPos = InStrRev(aText, ".")
    If lPointPos > 0 Then
        GetCSVParentKey = Mid(aText, 1, lPointPos - 1)
    Else
        GetCSVParentKey = ""
    End If

End Function


Sub SpojPožadavky()
    ' projedu celej sheet a pokud v prvním sloupci nic není, pak obsah toho druhého vložím k předchozímu, zbytek ignoruju.
    
    'nastavím proměnné pro listy
    Set shtVstup = Worksheets(cVstupSheet)
    Set shtVystup = Worksheets(cVystupSheet)
    
    ClearSheet shtVystup

    lVystupRow = 2

    Dim lVstupRow As Integer
    Dim lCSVKey As String
  
    For lVstupRow = 2 To aMaxLinesToProcess
        If shtVstup.Cells(lVstupRow, 1) = "" Then
            If shtVstup.Cells(lVstupRow, 2) <> "" Then
                AppendTextToPreviousRequirement shtVstup.Cells(lVstupRow, 2)
            End If
        Else
            lCSVKey = GetCSVKey(Trim(shtVstup.Cells(lVstupRow, 1)))
            WriteRequirement lCSVKey, shtVstup.Cells(lVstupRow, 2), shtVstup.Cells(lVstupRow, 3), shtVstup.Cells(lVstupRow, 4), lCSVKey, GetCSVParentKey(lCSVKey)
        End If
    Next lVstupRow

End Sub

Co vlastně dělá? Jeho úkolem je projít zdrojový list s požadavky překopírovanými z Wordu a připravit je pro export do CSV souboru. V případě, že narazí na řádek, který nemá zadanou identifikaci požadavku, ale má jeho text, přidá jej k tomu předchozímu. To nám vlastně vyřeší onen příklad s výčtem barev: sice se nepřenese formát výčtu, ale odrážky nám to alespoň provizorně zachová a přechod na nový řádek také, byť jde stále o jeden požadavek. Dále se snaží z identifikace požadavku vyčíst hierarchii a tu ve výsledku zohlednit.

Z uvedeného také plyne ono omezení, že požadavek (resp. nový řádek požadavku) nesmí začínat rovnítkem, neboť Excel by to pochopil jako vzorec (pokud ale chcete, můžete si skript zdokonalit).

Připouštím, že skript obsahuje pár nevzdělaných míst (např. mazání výsledkového listu nebo to, že standardně pracuje s prvními 5000 řádky zdrojového listu). Je jen na vás, abyste si jej případně upravili. Stejně tak můžete vložit vytváření balíků namísto vnořování požadavků nebo jinak pojmenovávat požadavky. Vše je na vaší vůli. Pokud se budete chtít podělit s vaším výsledkem, klidně to v komentáři udělejte.

Import prvků do Enterprise Architecta

Ne každý zaměstnanec v rámci jedné společnosti používá tytéž nástroje. Management či zadavatelé si často vystačí s aplikacemi ze sady Microsoft Office. Jenže lidé na IT si nechtějí nechat vzít své hračky a tak se snaží vstupy od zadavatelů přesýpat do jiných aplikací. Enterprise Architect tomu dokáže výrazně pomoci.

Zůstaňme však stále ve směru z aplikací Microsoft Office do Enterprise Architecta. Existují sice lepší cesty přes formát XMI, ale tím se (prozatím) zabývat nebudeme, neboť běžný uživatel toto nedokáže. Naší klíčovou aplikací dnes bude Excel.

V Excelu lze tvořit mnoho pěkných věcí, ale přiznejme si, že např. na správu požadavků to není úplně ideální nástroj (byť se někde používá). Nebude tedy od věci podívat se, jak právě požadavky z Excelu přenést do „éáčka“. Vezměme si jako příklad požadavky na nové auto. Každé oddělení má trochu jinou představu o tom, které parametry má nový vůz obsahovat, ale to není v tuto chvíli náš boj. Vše může vypadat např. takto:

Lze vidět, že máme požadavky rozdělené dle oddělení (zde manžel, manželka, dcera a syn), přičemž v oddělení syn máme dva zaměstnance (Tomáše a Jakuba). Každý ze zaměstnanců má své požadavky.

Co s tím? Abychom mohli požadavky do EA přenést, musíme nejprve s textem ještě něco málo udělat. Přidejte si proto poslední sloupec, nazvěte jej např. Typ a na každý řádek dejte hodnotu Requirement (vysvětlím záhy). Soubor si můžete i stáhnout. Nyní si uložte (nebo stáhněte) celou tabulku ve formátu CSV a přepněme se do Enterprise Architecta. Tam si v Project Browseru vytvořte balík, do kterého chcete požadavky importovat a přes pravé tlačítko zvolte Import/Export ► CSV Import/Export… Zobrazí se dialog podobný tomuto:

První krok, který uděláme (a jen jednou, netřeba jej opakovat při každém dalším importu souboru s touže strukturou), je vytvoření si definice našeho importu. Tím nástroji řekneme, co má v souboru hledat. Stiskněte tedy tlačítko Edit/New… a zobrazí se dialog pro definici importu:

Postupujte podle těchto kroků:

1. Zadejte název vaší definice.
2. Zvolte oddělovat záznamů v souboru.
3. Můžete vložit poznámku k vaší definici a stejně tak výchozí soubor, který se pokaždé bude nabízet (a bude možné změnit).
4. Výchozí směr (rozbalovací seznam Default Direction) bude Import.
5. Pole Default Types nechte prázdný (Název pole je zavádějící, ve skutečnosti se sem zadávají typy, které se mají importovat, ostatní se ignorují. Pokud je prázdné, pracuje se se všemi typy.).
6. Zaškrtávací políčko Preserve Hierarchy nechte nezaškrtnuté (ještě se k němu vrátím).
7. A nyní se dostaneme k tomu, že nadefinujeme význam všech sloupců, které v souboru máme. Postupně zadejte tato pole:
1. Name
2. Author
3. Priority
4. Notes
5. Type
8. Stiskněte Save a následně Close, čímž se vrátíte do předchozího dialogu.

Tady již zvolte vaši definici importu a uvidíte, že se jednotlivá pole nastaví dle toho, co jste zadali. Zbývá stisknout tlačítko Run a chvíli nedýchat. Pokud jste vše provedli správně, do vašeho balíku se dostaly všechny vaše požadavky. Uzavřete dialog stiskem tlačítka Close a podívejte se do Project Browseru, co se nám tam objevilo. Uvidíte tam několik požadavků s názvem „Dcera“, „Syn“ atd:

Není to moc přehledné, co říkáte? Ještě, než se pustíme do úpravy, otevřete si libovolný požadavek. Dostanete dialog podobný tomuto:

Pokud se podíváte pořádně, pak zjistíte, že se nám přenesl název požadavku, jeho autor a popis, ale chybí nám priorita. To by nás asi doma nepochválili.

Nejprve vyřešíme prioritu. Ta je definována seznamem hodnot, který můžeme libovolně měnit anebo mu přizpůsobit náš soubor exportovaný z Excelu. Pokud zvolíme tu první možnost, pak se podívejte do menu Settings ►Project Types ►General Types… a přepněte se na záložku Priority. Zde si můžete se seznamem pohrát tak, jak potřebujete. Jestliže volíte druhou možnost, pak se na uvedený dialog podívejte také, ať víte, z čeho můžete vybírat.

Nyní k našemu souboru v Excelu. První věc, která nás může dráždit, je název požadavku, který se opakuje. To není dobré. Zde doporučuji přesvědčit zadavatele, ať si svůj požadavek pojmenují. Buď nějak rozumně, nebo třeba číslem. Přidáme tedy do Excelu sloupeček pro název požadavku.

Druhá věc není na první pohled zřejmá. Pokud budou mít (a že budou) manželka s dětmi požadavků hodně, pak se v nich budete hůře orientovat. Zkusme si tedy udělat jednoduchou hierarchickou strukturu a rozdělit si požadavky do balíků podle jednotlivých členů rodiny.

Hierarchická struktura v souboru pro Enterprise Architect se dělá tak, že poslední dva sloupce se jmenují CSV_KEY a CSV_PARENT_KEY. V tom prvním je jedinečný klíč, který určuje daný řádek. V tom druhém je pak odkaz na rodiče. Předchozí příklad je rozšířen na následujícím obrázku (můžete si taktéž stáhnout xlsx i csv soubor). Jednotlivým členům rodiny necháme vytvořit balík a relevantní požadavky se pak na něj odkazují, čímž říkáme, že do nich patří.

Na základě této změny pak musíme samozřejmě upravit i definici importu: důležité je zaškrtnout políčko Preserve Hierarachy a upravit položky, které importujeme. Pokud vše nastavíte správně, můžete dostat v Project Browseru balíky podobné těmto:

Uznejte sami, že to už je mnohem příjemnější, než náš první výsledek.

Jak to funguje v praxi? Samozřejmě ne tak ideálně jako v tomto modelovém příkladě. Od zadavatele těžko můžeme chtít zadávat věci jako typ elementu k importu nebo hierarchickou strukturu. Jednou z možností je udělat si nějaké vzorečky a překlápět si požadavky na zvláštní list v excelovém souboru. Druhou je nechat zadavatele využít dobrodiní Wordu a nechat je psát požadavky v něm. Překlopení do Enterprise Architecta už je trochu složitější, ale i tak to jde. Ukážu to příště.

Poznámka 1: Popsané importování lze použít pro základní elementy, ne však např. pro jejich atributy. Pro to slouží již v úvodu zmíněný formát XMI.

Poznámka 2: Pro ukázky byl použit Enterprise Architect verze 9.3.933.

Co si autoři UML myslí nejen o UML

Obálka knihy

 Díky recenzi Reného Steina (kterého jsem sice dosud nepotkal osobně, ale dle jeho vystupování a prezentaci na internetu považuji za přirozenou autoritu) jsem se dostal ke knize Masterminds of Programming: Conversations with the Creators of Major Programming Languages. Jedná se o sbírku rozhovorů s tvůrci různých (tedy nejen programovacích) jazyků. A to včetně UML.

UML dostalo v knize tu výsadu, že autor vedl fundovaný rozhovor hned se třemi jeho (hlavními) tvůrci: Ivarem Jacobsonem, Jamesem Rumbaughem a Gradym Boochem.

Protože tématem hovorů není pouze UML, ale mnoho věcí spojené s návrhem, dovolil jsem si pro mě zajímavé myšlenky, nápady či jen zmínky o čemkoliv vypsat a případně mírně okomentovat. Neberte tedy mé povídání jako recenzi knihy, ale jako mé vlastní názory na věci, které uvedení pánové zmiňují.

Poznámka: Citace (jsou psány kursívou) z knihy jsem překládal sám, takže je prosím neberte jako směrodatné.

Ivar Jacobson

• Případ užití (dle definice) popisuje chování systému z pohledu uživatele. Ivarova zkušenost napovídá přistupovat k systému jako k černé skříňce: svým způsobem má pravdu pro případ, že se bavíme o sběru požadavků, kdy od uživatele chceme znát, co požaduje. V praxi se často setkávám s uživateli, kteří do daného systému trochu vidí (ale už ne mimo něj) a snaží se business konzultantům (hlavně nováčkům) radit nebo říkat nikoliv co potřebují, ale jak to potřebují. Konzultanti pak přijdou s řadou nesmyslných požadavků, které se musí v tom lepším případě narovnat, v tom horším nemilosrdně zahodit. Analytik však již s případy užití musí pracovat jinak: systém pro něj musí být zcela jasnou doménou, kterou ovládá.
• Tip na knihu: Kurt Bittner, Ian Spence: Use Case Modeling (ostatně Ivar pro ni napsal předmluvu)
• „Každý případ užití definuje množinu scénářů, které popisují, jak jsou implementovány pomocí spolupráce mezi jednotlivými třídami a komponentami.“ Škoda, že se nerozmluvil trochu o tom, že vývoj řízený případy užití (use-case driven development) mnozí považují již za překonaný. Také by mě zajímal jeho pohled na diagramy složených struktur dodané právě v UML 2. Sám je považuji za poměrně silný nástroj, bohužel již ne tak intuitivní jako jiné typy diagramů.
• Líbí se mi jeho (skrytá) kritika metodiků, kteří přijdou, seřadí si celé IT, tři dny do nich hustí novinky, které se pak musí ihned začít používat: „Namísto šíření znalostí všeho o všem […] je třeba představit v jednom okamžiku pouze jednu věc, a to takovou, kterou v danou chvíli nejvíce potřebujete.“
• „Ty opravdu náročné věci se na universitách nenaučíte.“ Do kamene tesat! Jeho kritika výuky na vysokých školách mě však překvapuje. Chápal bych, kdyby mluvil o systému zavedeném u nás v České republice, ale i v zahraničí?
• „Náš pohled na způsob vývoje se dramaticky mění co dva až tři roky. Je to mnohem častěji než proměny v již tak vrtošivé módě.“ A poté hned dodává, že zaručené nové metodiky jsou často jen jinak pojmenované staré. A vše se veze na vlně dobrého marketinku. Ano, i zde smutně souhlasím a mnohem smutněji zažívám. Celé to vede k té nepříjemnosti, že „pokaždé, když změníme zaměstnání, tak se musíme učit nové přístupy k vývoji, než se do něj můžeme zapojit. To není efektivní, protože namísto používání toho, co již známe, musíme znovu a znovu začínat od píky.“
• Na druhou stranu dále popisuje, jak by to mělo být a to není nepodobné agilnímu přístupu, tedy přístupu, které dnešní čeští „manažeři“ s MBA dávají za každou cenu zelenou. Nechci úplně tvrdit, že si Ivar protiřečí, ale malý rozpor v tom vidím.
• Ivar neskutečně trefně reje do současné podoby podnikových architektů (enterpise architects) jako do partičky projektů se neúčastnících individuí, která si jen kreslí své architektonické obrázky. Mou přibarvenou interpretaci jen doplňuji, že to matlají ve Visiu, ti zkušenější přímo v PowerPointu.
• „Nikdy jsem nevěřil, že by lidé mohli používat RUP tak, jak se pokoušejí ho používat. RUP totiž musíte používat více jako znalostní a myšlenkovou databázi a pak pracovat dle toho, co pro vás dává smysl.“
• Asi každý rozumný člověk zná, ale přeci jenom: „Namísto učení se velkých metodik nebo jazyků jako je UML či Java, zaměřte se na praktickou stránku věci. Zkoušení si je lépe zvladatelné.“
• Celkem jasně vyznívá jeho kritika OMG a stavu UML, ve kterém je. Do UML si každý snaží prosadit tu svou část bez ohledu na to, jaký přínos (a pokud vůbec nějaký) to bude mít.

James Rumbaugh

• „Z mých vlastních zkušeností mohu říct, že pouze necelá polovina programátorů umí pracovat s abstrakcí. Jeden z mých kolegů tvrdí, že je to méně než 10 %.“ Zkuste takovému programátorovi či analytikovi vůbec vysvětlit abstrakci. A myslet abstraktně? Hm, nebudu se raději rozepisovat.
• „Pokud musíte mít neustále při ruce tisícistránkový manuál, pak je něco špatně. Systém není správně rozdělen. Bohužel, mnozí lidé komplexitu zbožňují. IBM z ní udělala náboženství. Jak jinak, pomáhá jí to prodávat konzultanty.“ Pokud máte chuť, zkuste někdy ve větším podniku přijít s tím, že chcete něco zrychlit, zjednodušit, vylepšit. Uvidíte, kolik lidí tohle náboženství vyznává. Z mých zkušeností to je 95 % lidí v IT oddělení.
• Doporučení knihy: Fred Brooks: Mythical Man-Month
• „UML není dobře navržený programovací jazyk.“ Tolik lidí z akademické sféry by si uvedenou větu mělo přečíst, než začnou své studenty nutit v rámci cvičení např. přepisovat kus kódu v C do diagramu aktivit. Nerozumná práce s proměnnými, model akcí stojící za starou bačkoru a vlastně: UML není vůbec programovací jazyk, páni profesoři. Písmenko M v UML značí modelovací.
• „Znovupoužitelnost je přeceňovaná.“ „Znovupoužitelnost je proklatě těžká.“ Jamesův názor na znovupoužitelnost je trochu extrémní, ale opět mu nelze příliš odporovat. Svého času jsem se o ni také snažil, ale vždy přišlo to, co James říká: Buďto to doteď nikdo znovu nepoužil, nebo se to stejně muselo vlivem nových požadavků předělat. Jeho rada zní: „Předně, nedělejte věci příliš vymezené pro jeden účel, ale zkuste je lehce zobecnit. Nestavějte kolem sebe mantinely, pokud nemusíte. Jestliže lze něco zobecnit bez větší námahy, udělejte to. Navrhujte věci s myšlenkou, že je bude třeba někdy změnit.“ Ano, změnit, nikoliv znovupoužít. Co naplat, měl jsem si jeho myšlenku přečíst o pár let dřív, než jsem na to přišel také (na druhou stranu, zkušenost je nepřenositelná, každý se musí spálit).
• „Dobrý název je lepší než roční práce na projektu.“ Pokud máte dobrý název, lépe to celé prodáte a to leckdy bez ohledu na smysl toho, co prodáváte. Zde narážel na SOA.
• „V reálném životě obvykle neexistují jednosměrné vztahy. Málokdy se stane, že pokud A je ve vztahu s B, pak B není ve vztahu s A. Vztahy jsou již z podstaty obousměrné... přičemž obousměrnost nutné neznamená symetričnost. Člověk kousnutý psem je něco jiného než pes kousnutý člověkem.“ Na první pohled se může zdát, že to hodně souvisí s mírou abstrakce, ale při bližším zkoumání musíme tuto tezi zavrhnout.
• „Vše se jednou změní… Pokud píšete nějaké aplikace, vždy je píšete s jistotou, že se v příští verzi změní.“ K tomu snad jediné: a tak to pište tak, abyste druhý den/další měsíc/za rok věděli, proč jste to tak napsali a mohli to efektivně změnit.
• James opět značně kritizuje OMG, proces standardizace a jednotlivé přicmrndávače do UML standardu („když ty mi povolíš moji pitomost, tak já povolím tobě tu tvoji“). Nedivím se mu. Sám jsem dva týdny řeši jen změnu jména v jejich systémech. Ani nechci vědět, jak dlouho by opravovali chyby, které jsem ve standardu našel. O nelogičnostech ani nemluvě.

Grady Booch

• Grady byl oproti svým kolegům trochu žoviálnější a do OMG se neopíral, naopak myšlenku standardizace podporoval. Stejně tak i změnový proces mu připadl rychlý. Nesouhlasím s ním. Je mnoho požadavků na UML, na které se kašle, byť po nich mnozí volají (proč třeba dosud není jen blbá notace pro podmínkový uzel? Skoro deset let se OMG vymlouvá na nedostatek času).
• Grady dost dá na pocit: To, že něco nedokážu rozumově vysvětlit, ještě neznamená, že to dělám špatně.
• „Není těžké najít mizernou práci, kterou nenávidíš. Dělej však raději to, co tě naplňuje uspokojením.“ Netřeba komentáře, klasická klišoidní motivační hláška, ale stále zabírá.
• Líbilo se mi, jak se vyjádřil k Donu Knuthovi (autorovi geniálního TeXu): „… anebo jako to udělal Knuth: ‚sice teď píšu knihu, ale nelíbí se mi, jak je sázena. Takže psaní na pár let přeruším a vytvořím si jazyk, který sazbu udělá dle mých představ.‘“. Zřejmě se mi to líbí proto, že tak funguji také (a TeX mám rád).
• Pěkná je myšlenka, která říká, že nemá smysl pokoušet se pochopit fungování systému, dokud nebudeme mít předložený seznam pravidel a omezení. Proč já tohle nikdy nedělám? Aha, ono to není nikde nikým evidováno. Dokumentace nemá v dnešní době význam.

Pokud vás tento článek zaujal, knihu (či alespoň část věnovanou UML) si přečtěte. Najdete tam jistě mnoho dalších myšlenek, které vás zaujmou více než mě.

Příprava k OCUP Intermediate již dostupná

Během závěrečných hodin posledního červnového dne se mi podařilo dát na http://www.ocup.cz veškerou mou přípravu ke zkoušce OCUP Intermediate. Nyní tam tedy můžete nasávat znalosti hned pro dvě úrovně.

Připomínám, že byť je to postavené na Bloggeru, tak se to celé chová jako kniha a jednotlivé kapitoly tudíž naleznete v druhé části. Doporučuji se na ně dostavit pomocí obsahu.

Tištěná podoba webu bude také. V průběhu příštího týdne ji zašlu k tisku a k dispozici bude v druhé půli července.

Pokud se ptáte, zda bude někdy i třetí, poslední část, tak si stále myslím, že ano. Je možné, že se na ni začnu připravovat ještě letos o prázdninách (ano, záměrně nepíši o kterých).

Kritika otázek ve zkoušce OMG-OCUP-200

Po dnešku mám úspěšně za sebou zkoušku OMG-OCUP-200, tj. úroveň Intermediate. Musím říct, že ačkoliv jsem měl ze 70 možných otázek 67 správně, jsem z toho trošku rozladěný. V testu se objevovaly otázky např. na stavový automat protokolu (má se zkoušet až na úrovni Advanced) nebo se používaly termíny, které sice byly v návrhu UML verze 2.0, ale pak byly přejmenovány či vynechány (pamatuji si otázku na jakousi akci ApplyFunctionAction, která v současné verzi UML vůbec není).

Většinu z toho šlo odvodit logicky, ale přesto pachuť odfláknutí ze strany OMG zůstává. Skoro 7000 Kč za zkoušku není žádná láce, tak by se ta skupinka akademiků měla sakra starat o to, aby tato investice měla řádnou hodnotu.

Export a import RTF šablony pro generování dokumentace

Převedení vámi vytvořené šablony RTF reportu z jednoho projektu (EAP soubor) do druhého je poměrně jednoduchý krok, ale je třeba vědět, kam šáhnout.

Export šablony

1. Možnost uložení šablony na disk mnoho uživatelů Enterprise Architecta hledá v dialogu Generate Documentation (ukážeme si záhy) nebo v editoru šablony. Tam však hledají marně. Je třeba si nalézt dialog Export Reference Data. Ten zobrazíte z menu Project ► Model Import/Export díky položce Export Reference Data… (pozor na to, že v dřívějších verzích EA zmíněnou položku najdete v menu Tools)
   
2. V tomto dialogu najděte položku Templates – RTF Document a označte ji.
3. Stiskněte tlačítko Export.
4. EA se vás zeptá na soubor, do kterého budou uloženy všechny vaše uživatelské RTF šablony.
5. Předpokládejme, že se vše povedlo, EA vám to dá na vědomí.
   
   
6. Jestliže nechcete předávat všechny šablony, ale jen některé, pak je třeba vygenerovaný soubor upravit. Jde o XML formát, takže úprava bude jednoduchá: Smažte všechny elementy <DataRow>, které neobsahují potřebné šablony (hledejte dle názvu šablony v atributu value elementu <Column> názvu DocName (příklad: <Column name="DocName" value="My template for Requirements"/>).

Import šablony

Importovat šablonu lze dvěma způsoby:

1. Importem referenčních dat
1. V menu Project ► Model Import/Export zvolte položku Import reference data… Zobrazí se dialog podobný tomuto:
   
   
2. Zadejte soubor, který jste získali při exportu.
3. Po načtení se zobrazí hlavní části ze souboru, označte (v tomto případě jedinou) položku Templates – RTF document.
4. Stiskněte tlačítko Import.
5. O úspěšném importu jste informování.
   
   
2. Importem šablony
1. Z menu Project ► Documentation vyberte položku Rich Text Format (RTF) Report… (případně stiskněte F8), zobrazí se dialog Generate Documentation.
2. Přepněte se na záložku Templates
   
   
3. Tam zvolte tlačítko Import From Reference File.
4. Zobrazí se dialog stejný jako v předchozím postupu, použijte ho tedy.
5. V seznamu šablon se pak zobrazí všechny nově importované šablony.

Poznámka: Postup a obrázky odpovídají EA verze 9.3.933.

OCUP Intermediate

Pomalu se chýlí ke konci můj text k přípravě na zkoušku OCUP úrovně Intermediate. Již jsem aktualizoval obsah a jako ochutnávku dal na web notační plachty. Ke zveřejnění chybí již jen pár kroků:

1. Ještě jednou si to celé přečíst a opravit nedostatky.
2. Udělat zkoušku.
3. Připsat pár otázek pro představu, co vás čeká.
4. Překlopit text z Wordu sem na stránky.

 Minimálně první dva body budou provedeny teď v červnu, další dva buďto také nebo v první půli července.

Poznámka ke kompozitním diagramům v EA

Při psaní textu k certifikaci OCUP úrovně Intermediate a dělání příkladů v Enterprise Architectu jsem našel pár nedostatků tohoto nástroje. Pokud budete modelovat kompozitní strukturu v EA, pak narazíte na tyto problémy (platí pro EA verzi 9.2 build 922 a zřejmě i nižší):

• Pokud má část pouze název, nezapisuje za něj dvojtečku.
• Neumí zakreslit násobnost části do pravého horního rohu.
• Neumí zakreslit chovací port (isBehavior = True).
• Nedobře pracuje s částmi a instancemi.

V daných příkladech jsem si tedy musel pomoci malým „podvodem“.

Kam míří UML

UML už tu pár let je a prošlo si vlnami nadšení i kritiky. Kam se může ubírat ukazuje téměř dva roky starý článek od Ivara Jacobsona a Steva Cooka. Doporučuji k přečtení a zhodnocení současné situace.

Test schopnosti UML nástrojů pracovat s XMI

OMG nedávno provedla test vybraných nástrojů, ve kterém se zaměřila na jejich schopnost pracovat se standardizovaným formátem pro výměnu dat mezi modely (XMI). Celkem se provedlo na 16 testových scénářů v aplikacích firem Atego, IBM, NoMagic, Sodius, SOFTEAM a Sparx Systems (poslední jmenovaný dodává mnou používaný Enterprise Architect).

Předseda skupiny, která se formátem pro výměnu dat zabývá, mj. prohlásil: The ability to interchange models offers the potential to significantly improve productivity, quality, and the long term retention of models. Volně přeloženo s přihlédnutím mezi řádky: test dopadl katastrofálně. Výrobci musí vyvinout ještě mnoho úsilí, než dosáhnou uživateli požadovaného výsledku (totiž aby to fungovalo správně).

Ku dobru všech firem je ale nutné přičíst, že na testu spolupracovaly a všechny chyby, které se v průběhu testu našly, byly opraveny. Současně dodávané verze by tedy všemi scénáři nyní prošly bezchybně.

Důležitější je ale zřejmě ohlášení normativního XMI (Canonical XMI). XMI tak, jak je dnes definováno, nabízí poměrně dost volitelných možností, jak např. element či atribut zapsat. Proto vzniklo normativní XMI, které utahuje popuštěnou uzdu volnosti. Teď už jen, aby to všechny významné nástroje začaly plně podporovat.

Odkazy:

• Všechny testové scénáře
• Původní tisková zpráva OMG

Změny v UML 2.4.1 oproti UML 2.3

V UML 2.4.1 ze srpna 2011 (betu 2.4 můžeme ignorovat) došlo k poměrně dosti změnám v diagramech. V mnoha se do diagramu přidaly (existující) třídy, takže je to obecně hůře čitelné a je třeba trávit více času nad jednotlivými diagramy. Obzvláště nečitelný je např. diagram strukturovaného uzlu (Activities::StructuredActivities). Připadne mi to značně kontraproduktivní. Opět uvádím změny především z Classes::Kernel.

• Kapitola 7: Drobné změny v úvodní kapitole Reusing packages from UML 2 Infrastructure.
• Kapitola 7: Změna v diagramu Expressions diagram of the Kernel package. Přibyla třída LiteralReal.
• Kapitola 7: Změna v diagramu Classifiers diagram of the Kernel package. Jde především o pojmenování rolí tříd v asociacích.
• Kapitola 7: Jinak zakreslen diagram Features diagram of the Kernel package. Jinak a mnohem hůř. Zobrazení několika tříd vícekrát „pro lepší čitelnost“ tu čitelnost naopak zhoršili. Navíc z obrázku vyhodili výčet ParameterDirectionKind a nedali nikam jinam. V textu knihy jsem jej v obrázku záměrně nechal. Dále zde není zakreslena třída ValueSpecification, která byla přesunuta do diagramu Operations diagram of the Kernel package.
• Kapitola 7: Překreslen diagram Operations diagram of the Kernel package. Zásadní změna je v tom, že jsou zde více formalizované výchozí hodnoty všech atributů třídy Operation. Oproti předchozímu mi tento naopak připadne obsažnější než v předchozí verzi a to bez zhoršení čitelnosti.
• Kapitola 7: Překreslen diagram Classes diagram of the Kernel package, přidání výchozích hodnot atributů tříd Property a Association.
• Kapitola 7: V diagramu DataTypes diagram of the Kernel package přibyla vazba mezi třídami EnumerationLiteral a Enumeration. 
• Kapitola 7: V diagramu The Packages diagram of the Kernel package došlo k pár drobným, nevýrazným změnám.
• Kapitola 7: Překreslen diagram Contents of Dependency package. Jde ale o čuňárnu. V původních verzích bylo (zcela správně) používáno kvalifikovaných jmen u relevantních tříd. Dnes je tam pouze v závorce uvedeno, ze kterého balíku třída pochází. Není to dobrý příklad, jak kreslit diagramy podle UML. V textu používám lepší zápis. Jinak ale jde o zpřehlednění a při čtení se lépe hledají souvislosti. Vypadla (jen ze zápisu, nikoliv ze standardu) asociace mezi třídami NamedElement a Namespace.
• Kapitola 7: Překreslen diagram Contents of Interfaces package.
• Kapitola 7.3.38: Třída Package má nový atribut URI.
• Kapitola 7.3.45: Třída Property má nový atribut isID.
• Kapitola 7.3.55: Třída ValueSpecification má novou metoda realValue(). Ta souvisí s novou třídou LiteralReal.
• Kapitola 7.3.39: Třída PackageableElement má opravenou výchozí hodnotu atributu visibility z false na public (původní hodnota byla chybou standardu).
• Kapitola 7.3.29: Přibyla nová třída LiteralReal.
• Až do UML 2.3 byla kapitola PrimitiveTypes součástí superstruktury. UML 2.4.1 ji však přesunulo do infrastruktury. Pro znalost primitivních datových typů je tedy třeba sáhnout do 13 kapitoly infrastruktury. Další novinkou v této oblasti je nový typ Real. V superstruktuře (balík Classes::Kernel) pak najdeme odpovídající třídu LiteralReal a dále novou motody třídy ValueSpecification nazvanou realValue().

Načtení standardu UML 2.4.1 do Enterprise Architecta 9.2

Jak jsem před pár dny slíbil, napsal jsem postup, jak si importovat UML standard 2.4.1 do Enterprise Architecta. Zde překládám všechny jeho kroky.

1. Je nutné mít Enterprise Architect verze 9.2.
2. Stáhněte si XMI podobu specifikace, konkrétně tyto soubory:
1. PrimitiveTypes.xmi
2. Infrastructure.xmi
3. Superstructure.xmi
3. V EA si zvolte balík, do kterého chcete standard importovat.
4. V kontextovém menu balíku zvolte možnost Import Model from XMI...
5. Zadejte soubor PrimitiveTypes.xmi (věcí v Options si všímat nemusíte, pokud si s tím chcete pohrát, můžete).
   

   

   Dialog Import Package from XMI

6. Stiskněte tlačítko Import.
7. Čekejte. Aplikace bude chvíli chroupat, během čehož vytvoří požadované elementy.
8. Zopakujte kroky 5. až 7. pro soubory Infrastructure.xmi a Superstructure.xmi.
9. Stiskněte tlačítko Close.

A je hotovo. Ve vybraném balíku máte tři další: PrimitiveTypes, InfrastructureLibrary a UML (což je superstruktura).

Importovaný UML standard

Co importem získáte? Budete mít v modelu všechny třídy včetně vazeb, jejich atributy a metody a umístění v balících. U atributů a metod dostanete krátký popis jejich významu.

Co naopak mít nebudete? Nedostanete hlavně diagramy. Pokud chcete i je, musí bohužel nastoupit ruční práce (ta vaše). Dále nebudete mít základní popis významu tříd, nebudou tam omezení a další.

Enterprise Architect by měl umět načít specifikaci UML

Podle stránek produktu by „éáčko“ verze 9.2 mělo umět načíst specifikaci UML 2.4.1 dodávanou mimo jiné v XMI (připomínám, že XMI je součástí standardu). EA tento formát již nějakou tu dobu podporuje, ale standard se mi do něj dosud nepodařilo načíst. Jakmile budu mít prodlouženou licenci nástroje, vyzkouším to.

Změny v UML 2.3 oproti UML 2.2

Při pročítání UML verze 2.3 a psaní nových textů pro OCUP.CZ jsem narazil na pár změn v UML 2.3 proti předchozí verzi. Nejsou tu samozřejmě vypsány všechny, ale jen takové, které mě (jakkoliv) zaujaly. Nejvíce se starám o balík Classes::Kernel.

• Kapitola 5: Byla odstraněna původní relativně bezvýznamná věta a nyní se zabývá významem slov typu „musí“, „nesmí“, „měl by“, apod. Jde o odkaz na RFC 2119. Dále se zabývá anotacemi v některých příkladech uvedených ve standardu.
• Kapitola 7, Diagram 7.9
• Role u Property již neobsahuje subsets feature.
• Třída Classifier má nový atribut isFinalSpecialization: Boolean
• Třída Generalization má nový atribut isSubstitutable: Boolean [0..1] = true
• Kapitola 7.3.3: V třídě Asociation přibyla věta v úvodním popisu: A link is a tuple with one value for each end of the association, where each value is an instance of the type of the end.
• Kapitola 7.3.4: Změněn popis asociační třídy a sémantika.
• Kapitola 7.3.8: Třída Classifier má nový atribut isFinalSpecialization (viz popis klasifikátoru).
• Kapitola 7.3.11: V popisu sémantiky třídy DataType je místo slovíčka „equal“ používáno „same“. Jde tedy o drobné zmírnění podmínek, v mém českém překladu bez dopadu na význam.
• Kapitola 7.3.35: Rozšíření definice atributů třídy OpaqueExpression.
• Kapitola 7.3.40: Změny v pravidlech třídy PackageMerge. Je vhodné si pročíst, ale stále platí to, co je uvedeno v textu.
• Kapitola 7.3.46: Popsán vliv atributu isLeaf třídy RedefinableElement na operaci spojení balíků (třída PackageMerge).

K čemu zase další blok

Občas jsou věci, které mě ohledně UML napadnou, zaujmou, nadchnou nebo nepotěší. Většinu si někam zapíšu a pak použiju např. při revizích textu na mých stránkách věnovaných přípravě k certifikaci OCUP. Stejně tak při používání nástroje Enterprise Architect narážím na jeho omezení nebo naopak na funkce, které mi v práci pomáhají.

Abych si své poznatky pořád někde nesyslil, budu je sem průběžně dávat. Neočekávám, že budu přispívat pravidelně (třeba na úkor kvality), na druhou stranu nechci, aby tu třeba půl roku nic nepřibylo. Uvidíme, sám jsem zvědavý. Pro případné zájemce je vlevo umístěna možnost sledovat aktualizace pomocí RSS čtečky.