Architektura (příklady/UML)

[ajit]

Zdravím místní osazenstvo,

nedávno tu proběhla diskuze jak se udržet v programování a bylo tam pár zajímavých stránek s inspiracemi, co programovat. Neznáte někdo něco podobného i v oblasti architektury?

Ideální by bylo něco jako zadání: "namodelujte xyz" a i řešení jiných lidí, případně diskuze nad těmito řešeními.

Nějaký nápad?

Případně pokud máte nějaké jiné návrhy, jak se zdokonalit v psaní "čístého OO" kódu... Uvítám i linky (třeba na github) na projekty, které jsou podle Vás dobře navržené. Nicméně ty jsou většinou dost obsáhlé na to, aby člověk v rozumné době pochytil jádro návrhu. Na jazyku moc nezáleží Java/Ruby/Smalltalk/Objective-C/C++/...

[Reklama]

[gll]

S kreslením UML diagramů jsem se už dlouho nesetkal. Maximálně jen pro databázová schémata.

Častěji se generují diagramy z existujícího kódu pro účely dokumentace. Ruční synchronizace kódu/db schématu s diagramem nikdy moc nefungovala.

[Jan Forman]

Taky mě přišlo, že to nikdy pořádně nefungovalo. Chvíli jsem čuměl na BPMN (Aris, Bizagi, Enterprise Architekt), ale poslední dobou vkládám naděje do Ballerina Language, kde je jazyk nativně propojen s vizualizací.

DB jedině strojově vygenerovat, ale taky nic moc - raději tuhle cestu opustit a jít do API a Integrace obecně.
Už jen proto, že API je prostě popsané už z principu (Swaqqer, WSDL) a obvykle obsahuje i SDK pro import do různých programovacích jazyků. Bez té abstrakce je to stejně neuchopitelný bordel, který ale pak lze alespoň transformovat/čistit za chodu.

[ajit]

Ano, to se moc nedivím, ale zrovna na "učení" mi to nepřijde jako špatná volba. Přece jen naimplementovat něco pomocí UML diagramu není až tak složité, ale vymyslet jej...

Přišlo mi že by se tím to způsobem dalo trochu podvádět "víc příkladu architektury za méně času"...  Tedy nejde mi o to naučit se UML, nebo ho používat v rámci projektu, to je pouze berlička.

[Jan Forman]

Tak nakreslit a popsat to je základ samo sebou, paradoxně ale zrovna u té Balleriny je zajímavé, že grafická reprezentace působí složitěji než kód samotný.

Na to jsem narazil vždycky, že nápad působí jednoduše, kód je relativně krátký, ale rozkreslením to je strašně rozsáhlé.
Na to drobné malování jsme používali Bizagi nebo Visio, TIBCO občas někdo přinesl Aris nebo Enterprise Architekt. Ovšem každý to používal po svém, reálně to stejně neodpovídalo ve výsledku stačil papír
BizAgi, TIBCO a Enterprise Architekt šlo integrovat dál - ale málokdo se odvážil to reálně použít. Představa, že to rozseká půlku firmy každého děsila. BPMN bylo použitelné, protože už má potřebná pravidla UML mi příjde gumové.

Ano, to se moc nedivím, ale zrovna na "učení" mi to nepřijde jako špatná volba. Přece jen naimplementovat něco pomocí UML diagramu není až tak složité, ale vymyslet jej...

Přišlo mi že by se tím to způsobem dalo trochu podvádět "víc příkladu architektury za méně času"...  Tedy nejde mi o to naučit se UML, nebo ho používat v rámci projektu, to je pouze berlička.

[Reklama]

[gll]

Obrázkový popis se hodí jen na něco a většinou jen jako doplňek k textovém popisu nebo kódu. Kreslení programů jako obrázků se moc neosvědčilo.

Na databázová schémata se diagramy hodí lépe. Příklady snadno vygooglíte.

[balki]

Vacsina ludi ma problemy s uml, lebo nechape, ze je to jazyk na opis konceptov a nie na detailny opis aplikacie. Tak vznikaju zhovadilosti typu generovanie databazovych tabuliek z uml. Treba modelovat do urcitej miery, aby mal absolutny noob, tusenie, co sa robi v systeme. Na opis zdrojoveho kodu sluzi prekvapivo zdrojovy kod, netreba ho cely kreslit do obrazkov  

Ale k veci:
Nikde som "UML Challenge"  nevidel, musel by si ho zalozit. Na skole sme nieco malo mali, ale ucil som sa to "hard way". Proste som mal kolegu, ktory poctivo studoval modelovacie techniky a knihy o uml  (ucil to potom aj na skole) a vzdy ma zdrbal, ked som nieco spravil zle. Najlahsie sa v UML modeluje taky system, na ktorom clovek uz niekedy lopatoval, pokial to nie je nieco super tajne a pokryte mlcanlivostou.

V praxi som pouzival tieto diagramy:
- Activity diagram (Analogicky s flowchart diagramom len sa zvycajne pouziva na vyssej urovni abstrakcie)
- Sequence diagram
- Class diagram (a jeho derivaty vid logicky a fyzicky model db)
- Deployment diagram

A potom vec, co uml modeluje strasne zle
- Use cases , je to velmi dolezita technika a ma tam akurat nejakych pindurakov a bublinky. Na use cases viem odporucit knihu, na zvysok nie:
https://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp/0201702258

UML takmer nikto neovlada, lebo su ludia ignoranti, garantujem ti, ze barsake hovno nakreslis, vzdy ti to prejde. Ak si o UML aspon nieco precitas, budes lepsi ako 95% it-ckarov, co by vyplodili este vacsie blbosti, lebo su hlupi.

[ajit]

Asi jsem trochu nechtěně strhl pozornost na UML, ale to měla být opravdu jen berlička pro to, abych se zlepšil v návrhu.

Řekněme, že budu mít za úkol přidat na webovou stránku různé platební metody (různí provideři) tzn. budu chtít asi nějaké obecné rozhraní a použít třeba nějakou obdobu "strategy pattern"-u. To je jen příklad, ale takové věci se člověk buď naučí čtením o návrhových vzorech (ne vždy), anebo z reálného kódu, ale jak jsem psal, tak codebase je většinou obrovská a najít v ní obdobné hezké myšlenky není jen tak. Proto mi přišlo modelování pomocí UML jako taková zkratka, protože v UMLku to člověk uvidí rychleji než se hrabat v kódu...

Nicméně jestli Vás napadají alespoň nějaké dobře navržené open source projekty (rozumné velikosti) budu taky rád...

 

[UF]

doporucuju: http://codingthearchitecture.com/

[gll]

Řekněme, že budu mít za úkol přidat na webovou stránku různé platební metody (různí provideři) tzn. budu chtít asi nějaké obecné rozhraní a použít třeba nějakou obdobu "strategy pattern"-u. To je jen příklad, ale takové věci se člověk buď naučí čtením o návrhových vzorech (ne vždy), anebo z reálného kódu, ale jak jsem psal, tak codebase je většinou obrovská a najít v ní obdobné hezké myšlenky není jen tak.

Zobecnění by mělo vycházet z codebase. Ne naopak. Postupovat se má od konkrétního k obecnému. V tomto případě implementovat alespoň jednu platební metodu bez zbytečných abstrakcí a až potom vymýšlet nějaké obecné API.

Nicméně jestli Vás napadají alespoň nějaké dobře navržené open source projekty (rozumné velikosti) budu taky rád...

Je to záležitost vkusu. Snažte se napodobovat API knihoven, které se vám dobře používají.

[Yarda]

Pokud máš na mysli architekturu jako nakreslení baráku, zkus třeba
http://www.cadforum.cz/

[gll]

Zobecnění by mělo vycházet z codebase. Ne naopak. Postupovat se má od konkrétního k obecnému. V tomto případě implementovat alespoň jednu platební metodu bez zbytečných abstrakcí a až potom vymýšlet nějaké obecné API.

* obecné řešení

[balki]

Zobecnění by mělo vycházet z codebase. Ne naopak. Postupovat se má od konkrétního k obecnému. V tomto případě implementovat alespoň jednu platební metodu bez zbytečných abstrakcí a až potom vymýšlet nějaké obecné API.

* obecné řešení

Ano, toto dopadne tak, ze vsetky platobne metody sa budu tvarit ako ta jedna, aj ked to api nebude uplne pasovat. Potom sa kombajn bude tvarit, ze je lietadlo a kazdy normalnejsi si bude tukat na celo, preco to tak je. Poznam take pripady z praxe. Lepsie je uvazit viacere platobne metody a to api tak navrhnut. Teda, ak vieme, ze ich tam bude viac. (Aspon 3)