Modelowanie obiektowe - system zarządzania projektami

UML UML to język wizualny, służący do modelowania i opisywania systemów za pomocą diagramów i dodatkowego tekstu. UML jest językiem służącym do przekazywania informacji o systemie i jego wymogach. Składnia UML-a obejmuje diagramy, a semantyka opiera się na paradygmacie obiektowym.

Paradygmat obiektowy Opiera się na kilku podstawowych pojęciach, które pozwalają nam obserwować otaczający nas świat. Pojęcia ogólne przedstawione w zdaniach noszą nazwę klas, a ogólne relacje nazywane są asocjacjami. Podobnie jak w języku naturalnym w UML-u możemy przekazywać informacje za pomocą zdań szczegółowych, dotyczących konkretnych projektów, menedżerów, zespołów itp., w których konkretne pojęcia noszą nazwę obiektów a konkretne relacje nazwę powiązań. Klasa definiuje typ obiektu i właściwości swoich obiektów, a obiekt jest wystąpieniem (instancją) klasy.

Na diagramie przedstawione są następujące informacje: atrybuty operacje Na diagramie przedstawione są następujące informacje: Menedżer przewodzi zespołowi, który wykonuje projekt Każdy menedżer ma imię i numer telefonu, i może zainicjować lub zakończyć (przerwać) projekt Każdy projekt ma nazwę, datę rozpoczęcia i datę zakończenia Każdy zespół ma opis, i tylko on nas interesuje

Wymogi systemu zarządzania projektami Menedżer projektu wykorzystuje system zarządzania projektami do zarządzania projektem. Przewodzi on zespołowi, który ma wykonać projekt w wyznaczonych ramach czasowych. Po utworzeniu projektu w systemie zarządzania projektami menedżer może zainicjować projekt, a później przerwać go z powodu jego ukończenia lub z innych przyczyn. Danymi wejściowymi dla projektu są wymogi. Produktem wyjściowym projektu jest system lub jego część. Wymogi i system są produktami pracy, czyli rzeczami tworzonymi, używanymi, aktualizowanymi i rozwijanymi w ramach projektu. Każdy produkt pracy ma swój opis, jest w jakimś stopniu kończony podczas pracy i jego poprawność może być kontrolowana. Jednakże kontrola poprawności zależy od typu produktu pracy. Przykładowo, kontrolę poprawności wymogów przeprowadzają użytkownicy podczas warsztatów, a kontrola poprawności systemu polega na testowaniu na podstawie wymogów. Ponadto, wymogi mogą być publikowane z użyciem różnych mediów, między innymi Intranetu lub na papierze, a systemy mogą być wdrażane na określonych platformach.

Wymogi systemu zarządzania projektami - cd System zarządzania projektami musi być zdolny do obsługi następującego scenariusza: Jan Kowalski, który jest menedżerem, zarządza trzema projektami o nazwach: Dąb, Klon i Kasztan. W każdym projekcie biorą udział zespoły anonimowe lub nie mające nazw. Projekt Dąb tworzy system zarządzania projektami, podobny do opisywanego. Projekt Kasztan wykorzystuje platformę Java do wyprodukowania innego typu systemu, przeznaczonego dla szerszego rynku. Projekt Klon wykorzystuje platformę Microsoft.NET do stworzenia systemu podobnego do tego z projektu Kasztan, lecz z dodatkowymi wymogami związanymi z określoną organizacją. Wobec tego projekty Kasztan i Klon mają wspólne wymogi, przy czym projekt Klon ma wymogi dodatkowe. Podczas tworzenia projektu menedżer projektu za pomocą interfejsu użytkownika wprowadza swoje dane kontaktowe (przynajmniej imię i numer telefonu), nazwę projektu, datę początku i końca projektu, opis wymogów i systemu oraz opis zespołu. Po podaniu wymaganych informacji system odpowiednio przetwarza zgłoszenie, zapisując informacje i potwierdzając ukończenie czynności. Początkowo projekt jest nieaktywny. Stanie się aktywny, gdy zostaną do niego przydzielone zasoby ludzkie, może ponownie być nieaktywny po anulowaniu tego przydziału i jest usuwany z systemu po zakończeniu. Na potrzeby inspekcji i dla bezpieczeństwa system zarządzania projektami składa się z dwóch części: interfejsu użytkownika i bazy danych. Baza danych systemu znajduje się w centralnym serwerze. Interfejs użytkownika systemu zarządzania projektami uruchamiany jest na komputerze klienta, ma dostęp do drukarki i wykorzystuje bazę danych do składowania informacji związanych z projektem.

Obiekty z wartościami atrybutów

Komunikaty i bodźce W paradygmacie obiektowym komunikacja z obiektu nadawcy do obiektu odbiorcy służy do przekazywania informacji lub do żądania przetwarzania. Przykładowo nie inicjujemy projektu dla menedżera, lecz wysyłamy do niego żądanie inicjacji projektu. Gdy menedżer odbierze żądanie, wywoływana jest operacja obsługi żądania, a menedżer wykonuje metodę związaną z operacją. Wysłanie żądania i odbiór żądania są zdarzeniami. Komunikacja pomiędzy obiektami poprzez powiązanie nosi nazwę bodźca (stimulus), a komunikacja pomiędzy klasami poprzez asocjację nazywana jest komunikatem (message). Bodziec jest wystąpieniem komunikatu, podobnie jaj obiekt jest wystąpieniem klasy, a powiązanie wystąpieniem asocjacji. Nadawca nosi nazwę klienta, a odbiorca jest dostawcą. Komunikat lub bodziec jest przedstawiany w postaci strzałki dołączonej do powiązania, występującej od nadawcy w stronę odbiorcy i oznakowanej numerem sekwencji, który mówi o kolejności, w jakiej komunikat lub bodziec jest wysyłany, a następnie dwukropkiem i nazwą operacji, która ma zostać wywołana.

Komunikaty - interakcja szczegółowa Diagram pokazuje, że menedżer przydziela czynności i zadania zespołowi na podstawie wymogów projektu.

Generalizacja

Modelowanie strukturalne Pomaga ono w zrozumieniu i opisywaniu elementów składających się na system i funkcjonalności systemu.

Diagram klas dla systemu zarządzania projektami Diagram klas opisuje ogólną strukturę systemu i zawiera takie elementy jak: Klasa, asocjacja, atrybut, operacja