Projekty

Linki

Polecam


MANEA – Mantis Bug Trucker i Enterprise Architect

poniedziałek 16 sie 2010

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 towarzyszące przypadkom użycia

wtorek 16 mar 2010

?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.


Czy warto stosować mechanizmy inżynierii wprzód i wstecz w zwinnym modelowaniu?

piątek 13 lis 2009

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ęść »


Mały sekret reverse i forward engineering w Enterprise Architect

piątek 13 lis 2009

W poprzednich tekstach (Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect, MDG Integration for Eclipse i generowanie kodu aplikacji z poziomu Enterprise Architect) pisałem o inżynierii wstecz w Enterprise Architect. Teraz czas na mały sekret.

przeczytaj pozostałą część »


Pisanie kodu w Enterprise Architect

czwartek 12 lis 2009

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ęść »


MDG Integration for Eclipse i generowanie kodu aplikacji z poziomu Enterprise Architect

wtorek 10 lis 2009

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ęść »


Enterprise Architect i MDG Integration for Eclipse w praktyce

wtorek 10 lis 2009

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ęść »


Inżynieria wstecz w projektach JAVA za pomocą Enterprise Architect

poniedziałek 9 lis 2009

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ęść »


Podkarpackie modelowanie

piątek 14 sie 2009

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. 


Modelowanie gier w języku UML

poniedziałek 1 cze 2009

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 razemimage 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.


Zwinne modelownie – mity i fakty

środa 27 maj 2009

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.


Transformacja PIM-PSM w Enterprise Architect

poniedziałek 25 maj 2009

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.

image

Zaprezentowany model jest odseparowany od swojej implementacji. Aby wykonać model PSM należy

przeczytaj pozostałą część »


Najczęściej czytane

Kategorie

  • agile
  • architektura korporacyjna
  • Enterprise Architect
  • literatura
  • metodyki
  • modelowanie biznesowe
  • o inżynierii oprogramowania
  • ogólne
  • SCRUM
  • StarUML
  • szkolenia
  • teksty
  • WMB
  • wydarzenia
  • zarządzanie wymaganiami
  • zwinne modelowanie
  • Słowa kluczowe

    agile agile modeling aktor biznesowy aplikacje webowe ASP.NET biznesowy przypadek użycia byt biznesowy diagram aktywności diagramy Enterprise Architect Extreme Programming IBM Rational Software Modeler inżynieria oprogramowania konsultacje metoda punktów przypadków użycia metodyki wytwarzania oprogramowania model analizy biznesowej model biznesowych przypadków użycia modelowanie modelowanie biznesowe modelowanie procesów biznesowych modelowanie systemów informatycznych narzędzia CASE pracownik biznesowy proces wytwórczy oprogramowania procesy biznesowe projektowanie systemów informatycznych przypadki użycia Rational Software Architect Rational Unified Process RUP scenariusze procesów biznesowych SCRUM Service Oriented Architecture SOA StarUML szacowanie oprogramowania szkolenie testowanie UML Unified Modeling Language wymagania na system XP zarządzanie wymaganiami zwinne modelowanie

    Archiwum