Kdy použít v Use Case Diagramu vztah Extend a kdy Include (část 1)
V mnoha školeních a konzultacích jsem takřka pokaždé narazil na rozepře mezi vývojáři o nasazení vztahu Extend. Jak se má tento vztah používat správně a korektně?
Yearly Archives
V mnoha školeních a konzultacích jsem takřka pokaždé narazil na rozepře mezi vývojáři o nasazení vztahu Extend. Jak se má tento vztah používat správně a korektně?
Nedávno mi přišel mail s tímto textem: Dobrý deň, pán Kravál,
V snahe zužitkovať znalosti získané na Vašom školení analytikov a návrhárov našej firmy sme narazili na jeden problém, možno nás budete vedieť nasmerovať k jeho riešeniu. Náš produkt obsahuje rozsiahlu konfiguračnú stránku, kde je možné veľa vecí zapnúť, vypnúť, nastaviť na jednu z možností, niektoré možnosti majú zmysel, iba keď sú zapnuté iné možnosti apod. Konfigurácia sa ukladá do súboru vo formáte kľúč=hodnota (java properties) Pri behu aplikácie sa hodnoty konfigurácie udržiavajú ako hodnoty inštančných premenných singleton objektu, ostatné časti aplikácie sa na ne dopytujú cez getter metódy. Podľa tejto konfigurácie sa potom produkt správa v rôznych situáciách (scenároch). Niektoré kroky sa podľa nastavenia vynechávajú, niektoré idú jednou z možných ciest apod. Ako toto najlepšie namodelovať? Jediné, čo mi napadlo, je case-om priradiť nejaké activity diagramy, ktoré popisujú logiku (vetvenie, algoritmy) v závislosti od nastavenia. Alebo aj samotné nastavenia modelovať ako triedy a ich atribúty? Ako ich potom previazať so scenármi?
V jedné z diskusí na našem serveru se objevil odkaz na zajímavý článek, ve kterém se autor snaží vysvětlit, proč je použití vzoru Singleton nepřípustné a proč jsou Singletony tzv. lháři (v originále “Singletons are Pathological Liars”). V tomto článku si blíže rozebereme tuto problematiku z pohledu tvorby čistého kódu.
Vyzkoušejte si malý test na OOP a Design Patterns. Po zaškrtnutí všech odpovědí si porovnejte svoje odpovědi s řešením, které se odkryje po stisku tlačítka s nápisem Ukázat správné odpovědi. Test se nikde neukládá a ani výsledky se nikam neposílají.
Při jedné konzultaci ve firmě, která vyvíjí technologické systémy, jsme narazili na zajímavý problém k řešení, který nakonec vedl k doporučení zavést logickou vrstvu aplikace a k použití vzoru BRIDGE.
V předešlém článku (viz zde) byl popsán rozdíl mezi prvky typu User Story (zavedené v agilních technikách vývoje) a prvky typu Use Case (zavedené v UML). Současně byl také vysvětlen jejich přímý vztah v souvislosti s vývojem IS.
Následující článek má za cíl ukázat, jak lze rychle a efektivně vyhledávat případy užití procesní školou (BPMN 2.0). Navíc poslouží také jako dobrý příklad na použití prvku v BPMN 2.0 zvaného Parallel Gateway.