Visual Paradigm 15.0 Released

Dzisiejszej nocy opublikowano wersję 15 pakietu CASE Visua-Paradigm. Producent tego oprogramowania konsekwentnie pnie się na szczyt rozwiązań CASE w swojej klasie, a jako obserwator i użytkownik powiem tak: strategia jest prosta czyli aplikacja dla analityka, projektanta i architekta ma udostępniać najwyższej klasy narzędzia do pracy ze standardowymi notacjami i zgodnie z ich specyfikacjami, wspierać pojęciowe i logiczne śladowanie pomiędzy modelami, w niczym nie ograniczać analityka (nie narzucać żadnej metodyki postępowania), dać narzędzia do pracy na etapie nieformalnym, wspierać cały proces MDA jaki zwinne metody pracy, i co najważniejsze: dać narzędzie do…

Czytaj dalejVisual Paradigm 15.0 Released

Biznesowy (kanoniczny) model danych – nie chcemy

Nadal obserwuję to, że model relacyjny i "tworzenie bazowych modeli danych na etapie analizy wymagań" (kanoniczny model danych) trzymają się twardo mimo tego, że nie wiele wnoszą do projektu a narzucają (sugerują) kiepską architekturę aplikacji z jedną relacyjna bazą danych.  Co ciekawe zaczynanie od bazy danych jest wręcz zaprzeczeniem zwinności (konieczność ukończenia projektu docelowej bazy danych przed rozpoczęciem kodowania czyli klasyka waterfall, w efekcie betonowanie stanu z dnia rozpoczęcia) mimo, że autorki artykułu piszą o sobie że są agile...) Popatrzmy na to co proponują w tym 2017 roku.: Jeśli w…

Czytaj dalejBiznesowy (kanoniczny) model danych – nie chcemy
Read more about the article Związki w UML czyli abstrakcja vs rzeczywistość
#1 - a 3d render series showing change and motion

Związki w UML czyli abstrakcja vs rzeczywistość

Wstęp Tym razem o kilku powszechnie popełnianych błędach w korzystaniu z UML. Chodzi o pojęcia abstrakcji, metamodeli i zależności oraz o związki między elementami na diagramach. Kluczową, moim zdaniem, przyczyną tworzenia "złych" modeli obiektowych jest używanie notacji UML do tworzenia modeli strukturalnych, nie mających z obiektowym paradygmatem nic wspólnego. Druga to niezrozumienie pojęcia paradygmatu obiektowego. Ogromna ilość diagramów wykonanych z  użyciem symboli notacji UML, z UML i paradygmatem obiektowym ma niewiele wspólnego. Najpierw kilka definicji i pojęć. Paradygmat programowania (ang. programming paradigm) ? wzorzec programowania komputerów przedkładany w danym okresie…

Czytaj dalejZwiązki w UML czyli abstrakcja vs rzeczywistość

Model pojęciowy, model danych, model dziedziny systemu

Niemalże każde spotkanie projektowe, na którym omawiane są modele UML, na każdym szkoleniu na temat UML, pojawia się problem o którym pisze Ron Ross (wytłuszczenia moje): Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That?s wrong. A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It?s about communication. A logical data model is about how you organize what you think you know about the world…

Czytaj dalejModel pojęciowy, model danych, model dziedziny systemu

Business Analysis – diagram klas UML i bazy danych

pytanie o diagram klas jako reprezentacja [relacyjnej] bazy danych to świadectwo kompletnego niezrozumienia analizy i projektowania zorientowanego obiektowo (żeby nie powiedzieć ignorancji). Jest to także świadectwo braku znajomości literatury, bo faktycznie, jak zauważa autor powyższych słów, nie ma oficjalnych materiałów (organizacja standaryzująca) mówiących o modelowaniu danych diagramami klas notacji UML. Do modelowania danych używamy notacji ERD (ang. [[Entity Relationship Diagram]], diagram związków encji).

Czytaj dalejBusiness Analysis – diagram klas UML i bazy danych
Read more about the article System Analysis And Design with UML 2.0
System Analysis and Design with UML Version 2.0. An Object-Oriented Approach (Second Edition), Alan Dennis, Barbara Haley Wixdom, David Tergarden

System Analysis And Design with UML 2.0

Książkę polecam przede wszystkim analitykom do nauki ale także "wyżartym" programistom, by sobie uporządkowali zdobyte doświadczenie i możliwie łagodnie przechodzili od metod strukturalnych do obiektowych. Tu pewnie nowinka dla nich: bazy danych projektujemy na samym końcu, na etapie implementacji opracowanego kompletnego projektu obiektowego.

Czytaj dalejSystem Analysis And Design with UML 2.0

Koniec treści

Nie ma więcej stron do załadowania