MANEA jest to dodatek (plugin) do MANTIS BUG TRUCKER, który pozwala na dwukierunkową synchronizację wybranych wpisów z systemu MANTIS BT z repozytorium wymagań znajdujących się w Enterprise Architect firmy Sparx.
MANEA cechy:
- mapowanie, za pomocą Enterprise Architecta, wpisów i zgłoszeń na konkretne artefakty modelu aplikacji
- prowadzenie w systemie MANTIS dyskusji nad wymaganiami zapisanymi w Enterprise Architect
- umożliwienie szerokiemu gronu osób zgłaszania propozycji wymagań – tylko administrator wstawiając odpowiedni wskaźnik – tag EA-MANTIS może zezwolić na integracje wpisu z Enterprise Architectem
- możliwość zarządzania zgłoszeniami o błędach w oparciu o model wykonany w języku uml
- łatwość instalacji w systemie MANTIS gdyż MANEA to standardowy plugin,
- wsparcie dla repozytoriów błędów i modeli gromadzonych za pomocą bazy danych mysql
Wersja demo jest do pobrania ze strony www.manea.info
?Złote reguły? to nic innego jak wykaz punktów, które zazwyczaj kontroluję podczas tworzenia przypadków użycia. Gdy mam już narysowany przypadek użycia sprawdzam czy:
- przypadek użycia zapewnia wartość aktorom,
- krótki opis zwięźle opisuje cel przypadku użycia,
- przypadek użycia jest kompletny i sensowny,
- wydarzenie rozpoczynające przypadek użycia jest jasne,
- sposób i czas zakończenia przypadku użycia jest jasny,
- stosowana terminologia jest jasna, a istotne terminy zdefiniowane w słowniczku lub podobnym,
- rozpoczęcie i zakończenie przepływu alternatywnego
jest jasne a każdy przepływ alternatywny posiada jasne
odniesienie do sposobu, w jaki się zaczyna i dokąd zawrócona jest kontrola po tym jak zostanie wykonany,
- przypadek użycia jest możliwy do zweryfikowania,
- wszystkie kroki są indywidualnie ponumerowane,
- aby uprościć długie i złożone przepływy zdarzeń, wykorzystywane są podprzepływy w postaci dekompozycji aktywności
Powyższy dekalog sprawdzanych parametrów pozwala na utrzymywanie w repozytorium projektu w miarę sensownych przypadków użycia.
Ostatnie kilka wpisów:
dotyczyło metod integracji kodu z jej modelem. Przedstawiłem to zagadnienie w różnych wariantach z pluginem (MDG Integration for Eclipse) i bez. Teraz czas na podsumowanie i pytanie czy jest sens synchronizować model z jego implementacją w trakcie kodowania. Moim skromnym zdaniem NIE. Dlaczego?
przeczytaj pozostałą część »
Czy można pisać kod aplikacji w Enterprise Architect? Tak można i zaprezentuje to na przykładzie z którego korzystałem w tekście: Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect
przeczytaj pozostałą część »
W tekście Enterprise Architect i MDG Integration for Eclipse w praktyce opisałem wstępnie wtyczkę MDG Integration for Eclipse, która ułatwia integrację Enterprise Architecta ze środowiskiem Eclipse. Teraz postaram się zaprezentować możliwości wtyczki w zakresie synchronizacji kodu z modelem.
przeczytaj pozostałą część »
Tradycyjną metodę inżynierii wstecz opisałem kilka dni temu w tekście: Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect. Dziś chciałbym się skupić na płatnej wtyczce jaką można zastosować do Enterprise Architecta celem synchronizacji modeli ze środowiskiem JAVA czyli MDG Integration for Eclipse.
przeczytaj pozostałą część »
Mechanizm inżynierii wstecz (ang. reverse engineering) wstecz jest użyteczny w tedy, gdy mamy napisany program i chcemy go udokumentować za pomocą modeli UML. Powstała w ten sposób dokumentacja jest modelem implementacji. W Enterprise Architect można dokonać tego poprzez wybór odpowiedniego parametru w menu kontekstowym pakietu do którego będzie importowany kod.
przeczytaj pozostałą część »
Kolejny raz okazało się, że duży potencjał jest ukryty także poza dużymi ośrodkami takimi jak Warszawa, Kraków czy Gdańsk. O Wrocławiu nie wspominając. Tym razem miałem okazję i przyjemność przekonać się o tym w jednej z podkarpackich miejscowości. W czasie dwóch dni, jakie tam spędziłem wspierając młody i ambitny zespół ludzi, przed którymi stanęło dość ciekawe zadanie (niestety z uwagi na ochronę interesów klienta nie mogę podać więcej szczegółów). Tempo prac było bardzo duże bo i temat nie był banalny. Wydaje się mi, że udało się uzyskać zamierzone cele co potwierdzają ankiety. Moje oceny ze szkolenia były w zakresie przygotowanie konsultanta i ważność poruszanych tematów: otrzymałem same bardzo dobre oceny a w zakresie sposób prezentacji tematu jedna ocena dobry a pozostałe bardzo dobry.
O tym, że modelowanie jest przydatne w projektowani wszelakich aplikacji, nie trzeba przekonywać nikogo. Cieszy mnie bardzo, gdy widzę, że kolejne firmy mają ten sam pogląd i razem
wypracowujemy metodykę działania dla ich potrzeb. Tak też było w ostanie dni maja, w które prowadziłem szkolenie dla kilku osób z firmy produkującej gry. Bardzo dobrze spędziłem ten czas z dwóch powodów. Po pierwsze już dawno nie miałem tak wdzięcznego tematu do pracy. Po drugie uczestnicy ? rzeczowi, wymagający, doświadczeni programiści poszukujący rozwiązań szytych na ich miarę, co spowodowało, że szkolenie było bardzo intensywne i myślę, że udane. Świadczą o tym ankiety, w których otrzymałem same bardzo dobre oceny za ważność poruszanych tematów, ćwiczenia i moje przygotowanie. Na koniec cytat z ankiety z punktu Co najbardziej podobało Ci się w niniejszym szkoleniu: ?Duża liczba ćwiczeń praktycznych. Szkolenie zostało dostosowane do dziedziny jaką się zajmujemy?. Dziękuję za te słowa.
Mit: Zwinne zespoły nie produkują dokumentacji
Fakt: Dobry zwinny zespół produkuje taką ilość dokumentacji, która jest niezbędna do wspierania, utrzymania i rozwoju oprogramowania. Zwinne zespoły produkują przykładowo dokumentacje wyjaśniającą metafory i pojęcia słownikowe używane w trakcie projektu oraz modele w ograniczonym zakresie.
Mit: Zwinne zespoły nie potrzebują inwestować w wymagania
Fakt: Zwinne zespoły maniakalnie koncentrują się na spotkaniach z klientem związanych z określeniem wymagań. Nie potrzebują zapisywać wszystkiego na przód. Jeśli nie ma na miejscu klienta, zespoły używają bardziej tradycyjnych technik, takich jak przypadki użycia.
Mit: Zwinne zespoły nie tworzą modeli ani architektury systemu
Fakt: Zespoły tworzą wiele modeli (zazwyczaj ręcznie na białych kartach) w celu ułatwienia komunikacji. Badania wykazały, że większość zwinnych zespołów wykonuje modele by pomóc zrozumieć jak oni budują i konstruują system. Brak projektu całości na początku przedsięwzięcia nie oznacza braku projektowania. Najczęściej obok przypadków użycia powstają diagramy klas i aktywności.
Mit: Zwinne zespoły nie maja żadnych planów
Fakt: Zwinne zespołu projektują by nie było jak z Alicją w Kainie Czarów Lewisa Carrolla:
? Czy nie mógłby pan mnie poinformować, którędy powinnam pójść? ? mówiła dalej.
? To zależy w dużej mierze od tego, dokąd pragnęłabyś zajść ? odparł Kot ? Dziwak.
? Właściwie wszystko mi jedno.
? W takim razie również wszystko jedno, którędy pójdziesz.
? Chciałabym tylko dostać się dokądś ? dodała Alicja w formie wyjaśnienia.
? Ach, na pewno tam się dostaniesz, jeśli tylko będziesz szła dość długo.
Mit: Zwinne zespoły szybko przestają być kontrolowane, robią cokolwiek jak lubią i kiedy chcą.
Fakt: Zespół jest właściwie bardzo zdyscyplinowany i bardzo skupiony.Zadania zawsze są wykonywane w ustalonym porządku, z priorytetem określonym przez klienta przy pomocy przypadków użycia. Mierzenie osiągnięć celów nakreślonych przez przypadki użycia służy do jasnego oszacowania postępu i wydajności.
Mit: Jeśli jesteś zwinny, to nie potrzebujesz żadnych menadżerów
Fakt: Potrzebny jest menadżer by utworzyć dobre środowisko pracy i zaplanować iteracje w oparciu o przypadki użycia. Zwinny zespół dostarcza mierzalnych celów, określonych przez przypadki użycia. Menadżer za pomocą przypadków użycia szacuje ryzyko co umożliwia mu tym samym bardziej efektywne zarządzanie.
Kilka dni temu, w tekście Model Driven Architecture modele PIM a PSM, napisałem dwa słowa o modelach PSM i PIM w architekturze MDA. Teraz chciałbym pokazać jak taką transformację zrobić w Enterprise Architect.
Zrobię to na przykładzie wzorca projektowego Adapter, którego celem jest którego celem jest umożliwienie współpracy dwóm klasom o niekompatybilnych interfejsach.
Zaprezentowany model jest odseparowany od swojej implementacji. Aby wykonać model PSM należy
przeczytaj pozostałą część »
