Aplikacja Filharmonia

Dziedzina problemowa:

Filharmonia jest instytucją państwową, która nie korzysta z większych unowocześnień. Do tej pory wszelkie ustalenia odbywały się na papierze, co doprowadzało do wielu opóźnień i niejasności. Wyszukanie danego koncertu stwarzało klientowi wiele problemów a także zajmowało dużo cennego czasu. Chcąc wyjść naprzeciw oczekiwaniom ludzi, zajmujących się organizacją koncertów, zarządzających muzykami oraz klientom Filharmonii, postanowiono wprowadzić system informacyjny, który chociaż w małym stopniu pozwoli na usprawnienie całej organizacji.

Cel:

Celem systemu jest usprawnienie ustalania koncertów, tworzenia programów oraz dobierania muzyków w Filharmonii. Ma on także pomoc samym muzykom w sprawnym szukaniu danych o koncercie.

Zakres odpowiedzialności systemu:

System będzie przechowywał dane o muzykach pracujących w filharmonii oraz jej repertuarze. Sama aplikacja będzie udostępniać narzędzia pozwalające na wprowadzanie i edycję danych, a także pozwalające na zautomatyzowanie procesu tworzenia repertuaru.

Użytkownicy systemu:

Użytkownikami systemu będą: muzycy, dział kadr oraz dyrektor artystyczny.

Wymagania użytkownika:

System przechowuje informacje dotyczące muzyków (imię, nazwisko, datę urodzenia, adres zamieszkania oraz telefon kontaktowy). Pamiętane jest na jakim gra instrumencie (musi grać przynajmniej na jednym). Muzycy dzielą się na kontraktowych oraz zatrudnionych na umowę o dzieło. Dla muzyków zatrudnionych kontraktowo pamiętana jest data zatrudnienia, długość kontraktu oraz wartość pensji podstawowej. Długość kontraktu nie może być krótsza niż 24 miesiące. System pozwala wyliczyć wartość wypłaty w ostatnim miesiącu (na podstawie pensji podstawowej i bonusów od zagranych koncertów w danym miesiącu). Dla muzyków zatrudnionych na umowę o dzieło system pozwala wyliczyć wartość wypłaty w ostatnim miesiącu na podstawie liczby zagranych koncertów. Ich liczba nie może być mniejsza niż 3.

System przechowuje informacje o wszystkich utworach z repertuaru Filharmonii. Pamiętana jest jego nazwa (opis utworu) oraz szacowana długość. Dla każdego utworu znany jest jego kompozytor, oraz ile egzemplarz nut na dany instrument znajduje się w Filharmonii. Utwór może być częścią innego utworu .

Dla kompozytorów pamiętane są imię i nazwisko. System pozwala policzyć ile utworów danego kompozytora znajduje się w repertuarze. oraz wyszukać ich tytuły.

System przechowuje informacje o programach z repertuaru. W skład programu musi wchodzić minimum jeden utwór. Na podstawie szacowanych długości utworów możliwe jest wyliczenie przybliżonej długości programu. Jeden program może być grany wiele razy przy czym w skład jednego koncertu może wchodzić tylko jeden program.

Dla koncertów pamiętane są data oraz godzina rozpoczęcia. Znana jest lista muzyków grających w danym koncercie, oraz sala (jedna), w której koncert się odbywa.

Dla każdej sali koncertowej pamiętana jest jej nazwa.

Wymagania funkcjonalne:

Przypadki uzycia pominiete na tym etapie analizy.

Schemat nietrywialnych przypadków użycia istotnych dla funkcjonalności systemu skonstruowany wyłącznie z perspektywy aktorów systemu.

Diagram przypadków użycia dla aktora: Biuro kadr

Diagram przypadków użycia dla aktora:Dyrektor artystyczny

Diagram przypadków użycia dla aktora: Muzyk

Opis struktury systemu

Diagram klas zbudowany w oparciu o opis struktury systemu

Analiza dynamiczna

1.Diagram stanów dla klasy Koncert

2. Diagram aktywności dla przypadku użycia dodaj koncert

3. Diagram kolaboracji dla przypadku użycia dodaj koncert

4 Diagram sekwencji dla przypadku użycia dodaj koncert

Opis stanów dla klasy Koncert:

Koncert jest ZAPLANOWANY jeśli jest ustalona data ,godzina koncertu oraz ustalony jest jego program.

Koncert jest OBSADZONY jeśli ustalono którzy muzycy będą grali na tym koncercie.

Wyjście ze stanu złożonego następuje jeśli koncert zostaje anulowany lub jeśli data>daty dzisiejszej

1.Diagram Stanów dla klasy Koncert

.

Scenariusz dla przypadku użycia dodaj koncert: (dla tego przypadku użycia zostały zrealizowane diagramy aktywności, kolaboracji, sekwencji)

Dodanie koncertu

Wybranie daty

Wybranie godziny

jeśli istnieje program, to

Wybierz program

Koniec przypadku użycia

jeśli nie istnieje program

Dodaj program

Wpisz nazwę

Wybierz utwory

Koniec przypadku użycia

2.Diagram aktywności dla przypadku użycia dodaj koncert

3.Diagram kolaboracji dla przypadku użycia dodaj koncert

4.Diagram sekwencji dla przypadku użycia dodaj koncert

Transformacja poszczególnych klas i opis wybranych asocjacji

1.Asocjacja Koncert-Muzyk

2.Asocjacja Muzyk-Kontrakt

3.Asocjacja Sala_koncertowa-Koncert

4.Asocjacja z klasą asocjacji

5.Asocjacja(Kompozycja) Utwor

1.Asocjacja Koncert-Muzyk

Jest to asocjacja dwustronna *-*

Liczność wiele wymusza dodanie obiektu, który w sposób dynamiczny będzie zmieniał swoją wielkość. W Javie takimi obiektami są klasy implementujące interfejs Collection.

W klasie Koncert dodałam referencje do obiektu typu muzyk . Niezbędne było także dodanie metod pozwalających na dodawanie i usuwanie powiązań między klasami Koncert i Muzyk.

W klasie Muzyk dodałam referencje do obiektu typu koncert oraz podobnie jak w klasie Koncert dwie metody powalające na dodawanie i usuwanie koncertów.

2.Asocjacja Muzyk-Kontrakt

Jest to jednostronna asocjacja typu 1_0..1

Implementacja jednostronnej asocjacji skierowanej do klasy Kontrakt wymusza dodanie w klasie Muzyk referencji do obiektu typu kontrakt. Wartość null tego obiektu odpowiada liczności 0 asocjacji. Niezbędne jest także dodanie metod w klasie Muzyk pozwalających na dodawanie i usuwanie powiązań pomiędzy klasami Muzyk i Kontrakt.

3.Asocjacja Sala_koncertowa-Koncert

Jest to dwustronna asocjacja 1_*.

Implementacja tej asocjacji wymaga dodania w klasie Sala_Koncertowa referencji do obiektu typu koncerty oraz metod pozwalajacych na zrealizowanie tej asocjacji czyli dodających i usuwających koncerty.

W klasie Koncert dodałam obiekt sala typu Sala_Koncertowa oraz metody pozwalajace na zrealizowanie tej asocjacji czyli przypisz_sale i usun_ sale.

4.Asocjacja z klasą asocjacji

Implementacja asocjacji z klasą asocjacji wymaga stworzenia klasy Nuty odpowiadającej klasie asocjacji Nuty połączonej asocjacjami z klasami Instrument i Utwor.

W klasie Utwor i w klasie Instrument dodałam referencje do obiektu typu nuty oraz dwie metody pozwalające na dodawanie i usuwanie nut.

W klasie Instrument dodałam obiekt instrument typu Instrument oraz obiekt utwor typu Utwor oraz metody dodajace i usuwajace powiazania miedzy klasami czyli dodaj usuń utwor oraz dodaj usuń instrument.

5.Asocjacja(Kompozycja) Utwor

Implementacja kompozycji rekurencyjnej polega na dodaniu w tej klasie obiektu calosc typu Utwor oraz referencje do obiektu czesc typu Utwor. Niezbedne bylo takze dodanie metod pozwalajacych na dodanie czesci oraz utworzeni czesci w calosci.

Schemat logiczny systemu

Diagram klas stanowiący podstawę do implementacji:

zalącznik: klasy.jpg

Projekt interfejsu użytkownika

Wymagania niefunkcjonalne:

System do zarządzania Filharmonią powinien działać przy następujących ograniczeniach:

dane działające w ramach systemu powinny być dostępne codziennie w godzinach od 6.00 do 22.00

maksymalna niedostępność systemu nie powinna przekroczyć 12 godzin od momentu zgłoszenia błędu.

Opis przyszłej ewolucji systemu:

W obecnej chwili nie planuje rozbudowy systemu o nową funkcjonalność.

Słownik

Dyrektor artystyczny- osoba zarządzająca koncertami, repertuarem oraz programami.

Biuro kadr- osoba zarządzająca muzykami

Muzyk-pracownik Filharmonii

1

---