PMP Certification Links

Project Management Professional Exam Information; FAQ and few practical tips
How to Prepare and fill PMP application form
PMI Experience worksheet
The PMP® Exam Experience Verification Worksheet
How to prepare your PMP exam application
PMP Certification, A Beginner's Guide

Linki do stron o SmartGWT

Konfiguracja środowiska do pracy z GWT i Maven'em
SmartGWT Show Case
SmartGWT - projekt od podstaw za pomocą mavena
Setting Up SmartGWT 2.1 and GWT 2.0 with Eclipse 3.5
GWT 2.0.3 + Maven2 + Eclipse

Single Responsibility Principle - zasada pojedynczej odpowiedzialności

Single Responsibility Principle - każdy obiekt powinien mieć pojedynczą odpowiedzialność i wszystkie jego usługi powinny być blisko sprzymierzone z tą odpowiedzialnością. Na pewnym poziomie Spójność (cohesion) jest uważana za synonim dla SRP.

Odpowiedzialność (responsibility) - powód do zmiany. W przypadku, gdy mamy więcej niż jeden powód do zmiany klasy, oznacza to, że klasa ma więcej niż jedną odpowiedzialność. Przykładowo mając interfejs poniżej widzimy cztery sensowne funkcje modemu:

interface Modem {
  void dial(String phone);
  void hangup();
  void send(char ch);
  char recv();
}

jednak, przy bliższym spojrzeniu można dostrzec dwie odpowiedzialności. Pierwsza z nich dotycząca zarządzania połączeniem oraz druga związana z przesyłaniem danych. Lepszym rozwiązaniem byłoby rozdzielenie tych dwóch odpowiedzialności pomiędzy dwa interfejsy, tak jak poniżej:

interface Connection {
  void dial(String phone);
  void hangup();
}

interface DataChannel {
  void send(char ch);
  char recv();
}

class ModemImpl implements DataChannel, Connection {
}

Spójność (cohesion) - miara jak silno-skojarzona jest funkcjonalność wyrażona przez kod źródłowy modułu oprogramowania. Metody pomiaru spójności zmieniają się od miar jakościowych klasyfikujących tekst źródła podlegającego analizie używając rubryki z hermeneutykami do jakościowych miar które badają tekstowe charakterystyki kodu źródłowego by wskazać wartość numeryczną spójności.

Separation of Concerns - separacja zagadnień

Separation of Concerns jest procesem podziału programu komputerowego na odrębne cechy (moduły), które pokrywają się wzajemnie z punktu widzenia funkcjonalnego tak mało jak to tylko możliwe.

Mianem Concern (zagadnienie) określany jest pojedynczy element zainteresowania lub skupienia w programie. Typowo, zagadnienia są synonimami dla cech / właściwości lub zachowań.

Separacja pozwala między innymi na:
- indywidualną pracę w izolacji grupy ludzi nad kawałkami systemu,
- ułatwienie reużywalności,
- zapewnienie obsługiwalności systemu,
- dodawanie nowych właściwości w prosty sposób,
- zapewnienie każdemu lepszego zrozumienia systemu.

SoC nie jest przypisana jedynie do warstwy architektonicznej, często stosowana jest również do wielu innych zagadnień, takich jak:
- obiekt który reprezentuje zagadnienie z punktu widzenia języka,
- SOA może separować zagadnienia w usługi, wydzielając w ten sposób zachowanie jako zagadnienie w logiczne jednostki itd.

Zasada Separation of Concerns stanowi, że elementy systemu powinny mieć rozłączne i osobliwe (jednostkowe) zastosowanie. Inaczej mówiąc, żaden z elementów nie powinien współdzielić odpowiedzialności z innym elementem. Separację zagadnień można osiągnąć poprzez wytyczenie granic, gdzie granicą określamy logiczne lub fizyczne ograniczenie, które wytycza określony zestaw odpowiedzialności. Proces osiągania separacji zagadnień (SoC) zawiera podział zestawu odpowiedzialności, gdzie celem nie jest redukcja systemu na poszczególne części, a organizacja systemu w elementy niepowtarzalnych zestawów spójnych odpowiedzialności.

Celem SoC jest osiągnięcie dobrze zorganizowanego systemu, gdzie każda jego część pełni znaczącą i intuicyjną rolę przy maksymalizacji jej zdolności do adaptacji do zmian.


"Make everything as simple as possible, but not simpler."
Albert Einstein

Jak encje zostają skojarzone z kontekstem transakcji

Kontekst persystencji encji JPA jest zasobem, który jest skojarzony z transakcją. Tym sposobem, kontekst persystencji jest propagowany w ramach wywołania metod tak, że encje w jednostce persystencji (persistence unit) widzą swoje stany pośrednie, w ramach ich wspólnego kontekstu persystencji, gdy są one skojarzone z tym samym kontekstem transakcji. Również, ograniczenie polegające na tym, że jedynie jeden kontekst persystencji dla danej jednostki persystencji musi być skojarzony z określonym kontekstem transakcji zapewnia, że dla jakiejkolwiek encji typu T z identyfikatorem I, jej stan będzie reprezentowany przez jedynie jeden kontekst persystencji wewnątrz danego kontekstu transakcji.
Wewnątrz pojedynczego wątku aplikacji w danym momencie jest dostępny jedynie jeden kontekst transakcji. Serwer EJB jest uprawniony do tego by odłączyć pojedynczy kontekst persystencji od tego wątku i skojarzyć nowy kontekst persystencji z tą samą jednostką persystencji by zapewnić ograniczenia izolacji transakcji. Gdy serwer EJB wykona to, nowo utworzony kontekst persystencji nie jest w stanie zobaczyć zmian pośrednich wykonanych na encjach skojarzonych z uśpionym (suspended) kontekstem perystencji.