SIWZ-zal.1-Specyfikacja funkcjonalna PCM

Transkrypt

Specykacja wymaga« funkcjonalnych platformy
mikrobiologicznej PCM
Spis tre±ci
1 Wst¦p
1.1
1.2
1.3
1.4
1.5
Cel . . . . . . . . . . . . . . . . . . . . . . . . .
Opis konwencji u»ytej w dokumencie . . . . . . .
Denicja audytorium - przeznaczenie specykacji
Charakterystyka projektu . . . . . . . . . . . . .
Referencje . . . . . . . . . . . . . . . . . . . . .
2 Opis ogólny
2.1
2.2
2.3
2.4
2.5
2.6
2.7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Opis produktu . . . . . . . . . . . . . . . . . . . . . . .
Cechy produktu . . . . . . . . . . . . . . . . . . . . . .
Klasykacja u»ytkowników systemu i ich charakterystyka
rodowisko pracy systemu . . . . . . . . . . . . . . . .
Zaªo»enia konstrukcyjne i implementacyjne . . . . . . .
Dokumentacja u»ytkowników systemu . . . . . . . . . .
Uwarunkowania zewn¦trzne dziaªania Platformy . . . .
3 Opis Struktur Danych
.
.
.
.
.
.
.
.
.
.
.
.
3.1 Typy pomocnicze . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Opis Historii Izolacji (O-HI) . . . . . . . . . . . .
3.1.2 Opis Odno±nika Literaturowy (O-OL) . . . . . . .
3.1.3 Opis Pozycji Zamówienia (O-PZ) . . . . . . . . . .
3.1.4 Opis Skªadnika Po»ywki (O-SP) . . . . . . . . . .
3.1.5 Opis Warunków Hodowli (O-WH) . . . . . . . . .
3.1.6 Typ Akceptacji Wprowadzanych Danych (T-AWD)
3.1.7 Typ Cz¦stotliwo±ci Synchronizacji Danych (T-CS)
3.1.8 Typ Dost¦pu Do Rekordu (T-DDR) . . . . . . . .
3.1.9 Typ ¡cznika Do Pliku (T-LDP) . . . . . . . . . .
3.1.10 Typ ¡cznik Do Rekordu Gospodarza (T-LDRMB)
3.1.11 Typ Historii Namna»ania MBiol. (T-HNMB) . . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
4
4
5
7
7
8
9
10
11
12
13
14
14
14
14
15
15
15
15
16
16
16
16
17
SPIS TRECI
3.2
3.3
3.4
3.5
3.6
3.1.12 Typ Magazynowania MBiol. (T-MMB) . . . . . . .
3.1.13 Typ Postaci Przechowywania MBiol. (T-PPMB) . .
3.1.14 Typ Poziomu Bezpiecze«stwa Biologicznego (T-PBB)
3.1.15 Typ Protokoªu Wymiany Danych (T-PWD) . . . .
3.1.16 Typ Rekordów MBiol. (T-RMB) . . . . . . . . . . .
3.1.17 Typ Sposobu Pªatno±ci (T-SP) . . . . . . . . . . . .
3.1.18 Typ Stanu Konta (T-SK) . . . . . . . . . . . . . . .
3.1.19 Typ Stanu Pªatno±ci (T-SP) . . . . . . . . . . . . .
3.1.20 Typ Stanu Zlecenia (T-SZ) . . . . . . . . . . . . . .
3.1.21 Typ Synchronizacji Danych (T-SD) . . . . . . . . .
3.1.22 Typ Zapotrzebowanie Tlenowe (T-ZTL) . . . . . . .
3.1.23 Typ Zmiennych Cen (T-ZC) . . . . . . . . . . . . .
3.1.24 Typ Resrykcji (T-RST) . . . . . . . . . . . . . . . .
3.1.25 Typ Przesyªki (T-PRZ) . . . . . . . . . . . . . . . .
3.1.26 Typ Transportu MBiol. (T-TMB) . . . . . . . . . .
Rekord Danych Organizacji (R-DO) . . . . . . . . . . . . .
3.2.1 R-DO dla kolekcji . . . . . . . . . . . . . . . . . . .
3.2.2 R-DO dla organizacji . . . . . . . . . . . . . . . . .
3.2.3 R-DO dla systemów . . . . . . . . . . . . . . . . . .
Rekord Danych U»ytkowników (R-DU) . . . . . . . . . . .
3.3.1 R-DU u»ytkownika fabrycznego . . . . . . . . . . . .
3.3.2 R-DU u»ytkownika super-u»ytkownik . . . . . . . . .
3.3.3 R-DU u»ytkownika administrator . . . . . . . . . .
3.3.4 R-DU u»ytkownik klient . . . . . . . . . . . . . . .
3.3.5 R-DU u»ytkownika zarz¡dca . . . . . . . . . . . . .
3.3.6 R-DU dla u»ytkownika widz . . . . . . . . . . . . .
Rekord Transakcji Zakupu MBiol. (R-TZMB) . . . . . . . .
Rekord Danych Po»ywki (R-DP) . . . . . . . . . . . . . . .
Rekord Danych MBiol. (R-DMB) . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
18
18
18
18
19
19
20
20
20
20
21
21
21
21
22
22
22
23
23
23
24
24
24
25
25
26
4 Wymagania ogólne Platformy
27
5 Wymagania Moduªu Konguracyjnego Platformy (MKP)
28
6 Wymagania Moduªu Administracyjnego Platformy (MAP) 31
6.1 Ogólna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Cz¦±¢ Administrowania Magazynem (MAP-CAM) . . . . . .
6.3 Cz¦±¢ Administrowania Zleceniami (MAP-CAZ) . . . . . . . .
31
32
32
SPIS TRECI
4
6.3.1
6.4
6.5
6.6
6.7
Cz¦±¢ Administrowania Zleceniami Depozytu
CAZD) . . . . . . . . . . . . . . . . . . . . .
Cz¦±¢ Administrowania Danymi (MAP-CAD) . . . .
Cz¦±¢ Administrowania U»ytkownikami (MAP-CAU)
Cz¦±¢ Administrowania CMS (MAP-CAC) . . . . . .
Cz¦±¢ Administrowania Raportami (MAP-CAR) . .
(MAP. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
33
33
34
35
35
7 Wymagania Moduªu Zarz¡dczego Platformy (MZP)
37
8 Wymagania Moduªu U»ytkowego Platformy (MUP)
39
8.1 Wymagania ogólne Moduªu U»ytkowego Platformy . . . . . .
8.2 Moduª U»ytkowy - Cz¦±¢ Portalowa Ogólnodost¦pna (MUP CPO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Moduª U»ytkowy Platformy - Cz¦±¢ Komercyjna (MUP-CK)
8.4 Moduª U»ytkowy Platformy - Cz¦±¢ Depozytowa (MUP-CD)
8.5 Moduª U»ytkowy - Cz¦±¢ Portalowa (MUP-CP) . . . . . . . .
39
39
40
43
44
9 Wymagania systemu bazy danych (SBD)
45
10 Lista przypadków u»ycia (UC)
46
10.1 UC-LOG . . . . . . . .
10.2 UD-LOG-CERT . . . .
10.3 UD-WER-CERT . . . .
10.3.1 UC-AUTO-OFF
10.3.2 UC-LOGOUT .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11 Opis interfejsu u»ytkownika
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11.1 Architektura Informacji Serwisu . . . .
11.1.1 Ukªad stron serwisu . . . . . . .
11.1.2 Schematy ukªadu stron . . . . .
11.1.2.1 Strona gªówna serwisu
11.1.2.2 Podstrona serwisu . .
11.1.2.3 Podstrona Platformy .
12 Opis protokoªów komunikacyjnych
12.1
12.2
12.3
12.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Komunikacja z u»ytkownikami . . . . . . . . . . . . . .
Komunikacja wewn¡trz i pomi¦dzy moduªami Platformy
Komunikacja z baz¡ danych . . . . . . . . . . . . . . . .
Interfejs komunikacyjny z innymi systemami . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
50
52
54
55
57
57
57
60
61
61
62
63
63
63
64
64
SPIS TRECI
13 Wymagania niefunkcjonalne
13.1
13.2
13.3
13.4
Wymagania wydajno±ciowe . . . . . . . . . . . . . . . .
Wymagania dotycz¡ce zabezpieczenia dziaªania systemu
Wymagania dotycz¡ce bezpiecze«stwa . . . . . . . . . .
Wymagania jako±ciowe systemu . . . . . . . . . . . . . .
5
.
.
.
.
.
.
.
.
.
.
.
.
65
65
65
66
66
Spis rysunków
2.1 Podziaª logiczny Platformy na moduªy . . . . . . . . . . . .
2.2 Schemat budowy Platformy . . . . . . . . . . . . . . . . . . .
8
11
11.1 Schemat strony gªownej serwisu . . . . . . . . . . . . . . . .
11.2 Schemat podstrony serwisu . . . . . . . . . . . . . . . . . . .
11.3 Schemat podstrony systemu . . . . . . . . . . . . . . . . . .
61
61
62
6
Rozdziaª 1
Wst¦p
1.1 Cel
Celem niniejszej specykacji jest przedstawienie zbioru wymaga« postawionych przed
nowo tworzonym systemem bazodanowym - platform¡
PCM (Platform¡).
opisuje zarówno wymagania funkcjonalne jak i niefunkcjonalne.
Wymagania funkcjonalne przedstawiono zgodnie z logicznym podziaªem
Dokument
Platformy
na poszczególne podsystemy. Funkcjonalno±ci zostaªy podzielone na mniejsze fragmenty,
tak by ka»da z nich zostaªa jednoznaczne zaklasykowana do danego podsystemu
formy.
Plat-
Jako kryterium przynale»no±ci danej funkcjonalno±ci do danego podsystemu, wz-
i¦to mo»liwo±¢ jej inicjalizacji poprzez dany podsystem, t.j. funkcjonalno±¢ zostaªa zaliczona do danego podsystemu
Platformy, gdy interakcja u»ytkownika z tym podsystemem
powoduje rozpocz¦cie kaskady wydarze«.
Funkcjonalno±ci, które pomimo wykorzysta-
nia opisanego schematu mogªyby by¢ zaklasykowane do wi¦cej ni» jednego podsystemu
lub nie zaklasykowane do »adnego z podsystemów (np.
funkcjonalno±ci wykonywane
samoistnie, co pewien okres czasu), zostaªy zaklasykowane do cz¦±ci ogólnej. Funkcjonalno±ci w cz¦±ci ogólnej nale»y rozwa»a¢ jako wspóln¡ cz¦±¢ usªugow¡ systemu dost¦pn¡
z dowolnego podsystemu (moduªu).
Wymagania niefunkcjonalne zostaªy podzielone na kategorie zwi¡zane z u»ytkowaniem
systemu, zalicza si¦ do nich m.in. wymagania dotycz¡ce zabezpieczenia systemu i danych,
bezpiecze«stwa systemu, jego wydajno±ci oraz zaªo»onych protokoªów komunikacyjnych
Platformy z innymi systemami oraz u»ytkownikami.
Istotne jest podkre±lenie, »e niniejszy dokument jest tzw.
cym,
tzn.
dokumentem krocz¡-
b¦dzie on zmieniany w trakcie budowy systemu, tak by zawsze odpowiadaª
stanowi faktycznemu.
Autor, wraz z wªa±cielem Platformy - Instytutem Immunologii i
Terapii Do±wiadczalnej PAN we Wrocªawiu uzgodnili, »e taka forma b¦dzie najwªa±ciwsza
zwa»ywszy na wiele aspektów systemu, które okazaªy si¦ by¢ nieznane w czasie pisania
dokumentu, lub które podlegaj¡ dynamicznym zmian¡ w czasie. Takie podej±cie jest tym
bardziej wªa±ciwe w ±wietle odej±cia dzisiejszych projektów od tzw. metodologi Waterfall
w stron¦ tzw. planowania typu Agile. W tym podej±ciu zamiast szczegóªowego planowania, przedstawia si¦ jedynie plan zgrubny, a jego uszczegóªawianie wykonywane jest tu»
przed rozpocz¦ciem procesu budowy danego fragmentu systemu.
1
ROZDZIA 1.
WSTP
2
1.2 Opis konwencji u»ytej w dokumencie
W dokumencie wykorzystano nast¦puj¡ce konwencje pi±miennicze:
•
W niniejszej cz¦±ci wszelkie przykªady s¡ dodatkowo ograniczone (wyszczególnione)
za pomoc¡ nawiasów klamrowych, {}.
•
Wszystkie akronimy stworzone na potrzeby niniejszego dokumentu zostaªy pogrubione w tek±cie np.
Platforma
{
}.
Ich denicje mo»na znale¹¢ na stronie 73.
Wszystkie akronimy rozpoczynaj¡ si¦ wielk¡ liter¡.
•
Zwykle w przypadku pierwszego u»ycia akronimu podawane jest najpierw jego peªne
Platforma)}.
rozwini¦cie a nast¦pnie jego skrót, np. {platforma informatyczna (
•
W przypadku akronimów, które s¡ peªnymi rzeczownikami, stosuje si¦ zwykªe zasady
odmieniany, np. {... do rozwoju
•
Platformy
W przypadku akronimów nie-rzeczownikowych nie stosuje si¦ zasad odmiany ani nie
uwzgl¦dnia liczby mnogiej, np. {... wiele z
•
... }.
Do opisu wymaga«
UC
odnosi si¦ ...}.
Platformy wykorzystano zbiór pre-deniowanych typów u»ytkown-
ików, z których ka»dy deniuje zestaw przywilejów oferowanych przez Platform¦.
Nazwy typów u»ytkowników w teksie zostaªy pogrubione oraz pochylone (ang. italic),
np. {super-u»ytkownik }.
•
•
Wszystkie nazwy obce, nazwy produktów lub protokoªów wykorzystywanych przez
Platform¦ zostaªy zapisane kursyw¡ (pochylone), np.
{Adobe Flash Player }
Ka»de z wymagania funkcjonalne opisywanych w dokumencie skªada si¦ z trzech
cz¦±ci:
nazwy - opisuj¡cej w trybie oznajmuj¡cym pewn¡ funkcjonalno±¢, która powinna
Platform¦
przypadki u»ycia (UC - z ang.
by¢ oferowana przez
•
list¦ tzw.
use case).
istotno±¢ wymagania
Identykator (lub identykatory) odpowiednich przypadków u»ycia, które zostaªy
stworzone na podstawie danego wymagania zostaªy opisane w nawiasach kwadratowych dodanych na ko«cu opisu wymagania , np. [UC-LOG]. W przypadku gdy
to samo wymaganie jest podstaw¡ kilku ró»nych
UC,
ich identykatory zostaªy
1
rozdzielone przecinkiem, np: [UC-LOG-CERT, UD-WER-CERT] . Opis szczegóªowy
danego UC mo»na znale¹¢ w Rozdziale 10 na stronie 46
1 Poniewa» niniejszy dokument jest tzw. dokumentem krocz¡cym, mo»e opisywa¢ on w danej chwili
tylko okre±lony podzbiór wszystkich mo»liwych przypadków u»ycia.
W trakcie post¦pów w pracach
nad Platform¡, liczba opisanych UC powinna si¦ zwi¦ksza¢. Idea specykacji systemu jako dokumentu
krocz¡cego zakªada »e opis przypadków u»ycia powinien zosta¢ uzupeªniony przed rozpocz¦ciem prac
nad dan¡ funkcjonalno±ci¡.
ROZDZIA 1.
•
WSTP
3
Istotno±ci danej funkcjonalno±ci okre±lona jest za pomoc¡ liczby naturalnej umieszczonej w nawiasach klamrowych, zlokalizowanej na ko«cu nazwy wymagania. Istotno±¢ podana w niniejszym dokumencie przedstawia jedynie istotno±¢ wynikaj¡c¡ z
warto±ci biznesowej danego wymagania.
Przy ustalaniu kolejno±ci implementacji
posczególnych funkcjonalno±ci, nale»y uwzgl¦dni¢ tak»e ich zale»no±ci, zdeniowane
w
UC zwi¡zanych z dan¡ funkcjonalno±ci¡.
Istotno±¢ zostaªa okreslona jedynie dla
wymaga« funkcjonalnych, wymagania niefunkcjopnalna maj¡ domy±lny priorytet
{5}, jakkolwiek ich implementacja rozªo»ona jest w czasie i dlatego nie jest istone
okre±lanie jej kolejno±ci. Przyj¦to nast¦puj¡c¡ skal¦:
•
dodatkowa - {1}
przydatna - {2}
potrzebna - {3}
wymagana - {4}
niezb¦dna - {5}
U»yte w tek±cie czasowniki rozdzielone znakiem /, oznaczaj¡, »e funkcjonalno±¢
powinna by¢ powielona, w ka»dej wersji wykorzystuj¡c jeden z nich, np. {... umo»liwia aktywacj¦/dezaktywacj¦/reaktywacj¦ kont ...} - oznacza:
•
... umo»liwia aktywacj¦ kont ...
... umo»liwia dezaktywacj¦ kont ...
... umo»liwia reaktywacj¦ kont ...
Znaczenie u»ytych w tek±cie wyra»e« jest nast¦puj¡ce:
nie dopuszcza - oznacza dziaªanie, które za pomoc¡ wszelkich dost¦pnych
formie mechanizmów jest blokowane przed wykonaniem
umo»liwia, udost¦pnia - oznacza dziaªanie oferowane przez
Plat-
Platform¦, którego
moment uruchomienia jest nieokre±lony (wybieralny przez u»ytkownika).
posiada, przechowuje, udost¦pnia oznaczaj¡ dziaªania Platformy, których czas
wykonania jest niesprecyzowany, lub których dziaªanie jest rozci¡gni¦te w czasie.
wykonuje, dokonuje - oznacza dziaªanie oferowane przez
Platform¦,
którego
moment uruchomienia jest precyzyjnie okre±lony. Moment uruchomienia powinien
by¢ okre±lony, albo posiada¢ zdeniowan¡ cz¦stotliwo±¢ wykonania, np. {raz w
tygodniu}, lub jako dziaªanie nast¦puj¡ce zaraz po, lub jednocze±nie z innym
dziaªaniem, np. {po zako«czeniu zapisu faktury w bazie danych}
lista - sªowo to u»ywane w kontek±cie opisu pól rekordów bazy danych oznacza,
»e pole skªada si¦ z grupy danych o nieustalonej ilo±ci elementów, w której ka»dy
element (listy) ma przypisan¡ warto±¢ wynikaj¡c¡ z typu listy. Lista mo»e by¢
równie» porównana do tablicy o niezdeniowanej wielko±ci.
ROZDZIA 1.
WSTP
4
1.3 Denicja audytorium - przeznaczenie specykacji
Niniejszy dokument zostaª napisany z my±l¡ o trzech typach czytelników:
•
projektancie
•
wykonawcy
•
planisty
Dla pierwszych z nich (projektantów systemu, architektów) ma sªu»y¢ jako wysokopoziomowy
opis usªug oferowanych przez
Platform¦.
Lista wymaga« prezentowana w niniejszym
dokumencie powinna zosta¢ wykorzystana jako dokument podstawowy podczas tworzenia
innych dokumentów projektowych niezb¦dnych do wytworzenia w peªni funkcjonalnego
systemu, np. specykacji technicznej czy gracznej.
Dla wykonawców (graka, programisty, administratora systemu bazy danych), dokument ten powinien stanowi¢ baz¦ do dyskusji o celu danej funkcjonalno±ci - co jest szczególnie istotne w przypadku równolegªego wykonywania zada« podzielonych na mniejsze fragmenty. Dokument ten pozwala równie» wyodr¦bni¢ zale»no±ci pomi¦dzy poszczególnymi
elementami systemu, szczególnie na poziomie podsystemów, co jest pomocne w synchronizacji zada« pomi¦dzy zespoªami.
Dla planisty dokument ten powinien sªu»y¢ do okre±lenia ilo±ci niezb¦dnych etapów
po±rednich potrzebnych do uruchomienia w peªni funkcjonalnego systemu.
Dodatkowo
dokument zawiera priorytety ka»dego z wymaga«, co pozwala na klasykacj¦ ich poziomu
istotno±ci. Podobnie jak dla wykonawców, dokument ten pozwala na okre±lenie zale»no±ci
pomi¦dzy poszczególnymi fragmentami. Funkcja ta jest niezb¦dna do prawidªowego zaplanowania równolegªego wykonania niektórych zada« zwi¡zanych z tworzeniem systemu
Platformy.
Aby dostarczy¢ maksimum informacji a jednocze±nie uªatwi¢ jego pó¹niejsze wykorzystanie w formie leksykonu (spisu wymaga«), sugerowany jest nast¦puj¡cy schemat
zapoznawania si¦ z dokumentem:
1. Zapoznanie si¦ z rozdziaªami 1 na stronie 1 i 2 na stronie 7 aby móc zrozumie¢
konwencje pi±miennicze, zaªo»enia oraz ogólny opis
2. Zapoznanie si¦ z cechami ogólnymi
Platformy
Platformy.
(rozdziaª 4 na stronie 27)
3. W zale»no±ci od typu rozwi¡zywanego problemu (kodowanie, analiza potrzeb sprz¦towych, specykacja techniczna lub projekt graczny), zapoznanie si¦ z wymaganiami dotycz¡cymi badanego zagadnienie na podstawie jednego z pozostaªych rozdziaªów.
1.4 Charakterystyka projektu
Platforma, której opis wymaga« jest celem niniejszego dokumentu zostaªa zaplanowana
jako medium pozwalaj¡ce na gromadzenie i wymian¦ informacji dotycz¡cych ró»nego
MBiol.),
typu materiaªu czynnego biologicznie (
komórkowych itp.
np.bakterii, wirusów, plazmidów, linii
ROZDZIA 1.
WSTP
5
Potrzeba istnienia takiego systemu zostaªa zdeniowana przez pracowników Instytutu
Immunologii i Terapii Do±wiadczalnej PAN we Wrocªawiu.
W dzisiejszym ±rodowisku
naukowym dost¦p do informacji, a przede wszystkim czas jej uzyskania staje si¦ coraz
bardziej kluczowy dla prowadzonych bada« naukowych.
MBiol.
matycznego gromadz¡cego informacje nt.
Brak spójnego systemu infor-
dost¦pnego dla ró»nych jednostek
naukowych na terenie Polski powoduje powa»ne komplikacje i opó¹nienia w uzyskaniu
ko«cowych eksperymentu naukowego. Cz¦sto taka informacja nie tylko obni»yªaby koszt
eksperymentu (np. w przypadku gdy ten sam szczep bakterii mo»e by¢ zakupiony du»o
taniej na terenie kraju), ale równie» skróciªa czasu oczekiwania oraz znacz¡co zmniejszyªa
ilo±¢ komplikacji zwi¡zanych z przesyªem
MBiol.
na du»e odlegªo±ci np. pomi¦dzy kon-
tynentami.
Nale»y równie» podkre±li¢ niezwykle istotne znaczenie takiego systemu dla szeroko
rozumianego biznesu wykorzystuj¡cego
MBiol.
do swojego funkcjonowania, np. dro»d»e
Platforma w znacz¡cy sposób upro±ci wyszukiwanie »¡danego typu bakterii czy dro»d»y oraz
dla przemysªu winiarskiego, czy bakterie mlekowe dla przemysªu spo»ywczego.
ich zamawianie.
Wprowadzi ona równie» usystematyzowany sposób gromadzenia infor-
macji nt. kto, kiedy, ile i jakiego typu
MBiol.
zamówiª, co przy dzisiejszym zagro»eniu
bioterroryzmem pozwoli na bªyskawiczne pozyskiwanie informacji nt. dróg rozprzestrzeniania si¦ danego typu
MBiol.
Nie bez znaczenia jest tak»e mo»liwo±¢ deponowania
w znacz¡cy sposób wspomagana przez
Platform¦.
MBiol.,
którego procdura jest
Element ten jest kluczowy dla roz-
woju naszego Pa«stwa i Europy, gdzie wysoka konkurencja w pozyskiwaniu
MBiol.
o
okre±lonych wªa±ciwo±ciach powoduje nieuniknione spory dotycz¡ce wªasno±ci intelektualnej danego mikroorganizmu czy linii komórkowej.
Dzi¦ki istnieniu Platformy, b¦dzie
mo»na w prosty i szybki sposób uzyska¢ informacje nt.
nieniu kolekcji
PCM
uzyska¢
MBiol.
daty depozytu oraz dzi¦ki ist-
w takiej formie w jakiej zostaª zdeponowany.
Dzi¦ki tym informacjom mo»na w jednoznaczny sposób okre±li¢ wªasno±¢ spornego materiaªu lub przy±pieszy¢ proces uzyskania patentu poprzez szybsze zgromadzenie wszystkich
niezb¦dnych informacji, dost¦pnych dla uprawnionych osób z dowolnego miejsca na ±wieci
podª¡czonego do sieci Internet.
ponowania
MBiol.
Platforma
w istotny sposób przy±piesza procedur¦ de-
w kolekcji mikroorganizmów oraz umo»liwia szybki dost¦p do jego
opisu.
1.5 Referencje
Dokument zakªada znajomo±¢ typowych terminów dotycz¡cych aspektów technicznych,
formatu danych b¡d¹ specykacji protokoªów komunikacyjnych.
Poni»ej przedstawiono
list¦ wa»niejszych odno±ników, w którym mo»na znale¹¢ informacje dotycz¡ce mniej znanych
elementów niezb¦dnych do prawidªowego dziaªania systemu, lub informacji dodatkowych
które nie s¡ celem niniejszego dokumentu:
•
CABRI - http://cabri.org/ - Common Access to Biological Resources and Information - wyszukiwarka informacji nt.
MBiol.
w stowarzyszonych kolekcjach
MBiol.
Dane udost¦pnione poprzez wyszukiwark¦ s¡ gromadzone/udost¦pnione w formacie
zdeniowanym przez t¦ organizacj¦.
Format CABRI jest prostym formatem tek-
stowym, w którym poszczególne wiersze zbudowane s¡ w formie par skªadaj¡cych
ROZDZIA 1.
WSTP
6
si¦ z klucza i przypisywanej jemu warto±ci.
•
StrainInfo - http://www.straininfo.net/ - nowy system wyszukiwania baz danych
ró»nych kolekcji
•
MBiol.
Twórca nowatorskiego systemu opisu
MCL - http://www.straininfo.net/projects/mcl/
guage, j¦zyk opisu rekordu
MBiol.
- MCL.
- Microbiological Common Lan-
MBiol., oparty o standard XML.
Rozdziaª 2
Opis ogólny
2.1 Opis produktu
Platforma jest tworzona w celu zast¡pienie obecnej papierowej wersji zarz¡dzania danymi
MBiol. kolekcji PCM jak i usprawnienia obecnego systemu zamówie« MBiol., który
opiera si¦ o zbiór informacji znajduj¡cych si¦ cz¦±ciowo w systemie ksi¦gowym a cz¦±ciowo
w formie papierowych zlece« (np. wysªanych faksem). Celem
Platformy jest dodatkowo
wª¡czenie si¦ w istniej¡ce sieci teleinformatyczne o podobnym charakterze. Platforma ma
budow¦ moduªow¡, przedstawion¡ na rysunku 2.1:
7
ROZDZIA 2.
OPIS OGÓLNY
8
Rysunek 2.1: Podziaª logiczny
Platformy
na moduªy
Dodatkowo, z uwagi na du»¡ liczb¦ funkcjonalno±ci wyst¦puj¡c¡ w przypadku dwóch
moduªów
Platformy: MUP i MAP
- ich funkcjonalno±ci podzielono na mniejsze, log-
iczne cz¦±ci. W obu przypadkach w opisie wymaga« wydzielono tak»e tzw. cz¦±¢ wspóln¡
(wymagania ogólne), które sp¦ªnia ka»da z cz¦±ci w danym module.
2.2 Cechy produktu
Platforma charakteryzuje si¦ nast¦puj¡cymi gªównymi cechami i funkcjonalno±ciami:
•
wieloj¦zyczno±¢ - caªo±¢ informacji dost¦pnej z zewn¡trz b¦dzie oferowana w kilku
wybranych j¦zykach, których lista mo»e by¢ rozszerzona lub zmieniona
•
moduªowo±¢ - odzwierciadlaj¡ca logiczny podziaª funkcjonalno±ci Platformy na mniejsze
zbiory.
•
•
deponowanie
MBiol.)
MBiol.
- mo»liwo±¢ dostarczenia wszelkich informacji (poza samym
niezb¦dnej dla procesu deponowania.
zarz¡dzanie zbiorem
MBiol.
ROZDZIA 2.
OPIS OGÓLNY
9
MBiol.
•
zakup
•
zarz¡dzanie
•
udost¦pnianie
Platform¡
Platformy innym instytucjom do potrzeb samodzielnego gromadzenia,
sprzeda»y i zarz¡dzania MBiol.
•
udost¦pnianie informacji naukowej i technicznej
•
zarz¡dzanie informacj¡ naukow¡ i techniczn¡
•
umo»liwienie wymiany informacji pomi¦dzy u»ytkownikami
Platformy, tzw.
forum
dyskusyjne.
•
automatyczna wymiana informacji nt.
MBiol.
z innymi systemami o podobnym
prolu.
2.3 Klasykacja u»ytkowników systemu i ich charakterystyka
fabryczny - u»ytkownik fabryczny, specjalne konto posiadaj¡ce te same uprawnienia jak
super-u»ytkownik , ale dodatkowo jest jedynym kontem, którego modykacja nie
jest mo»liwa. Konto fabryczne posiada hasªo dost¦powe dostarczone przez producenta w zalakowanej kopercie do r¡k osoby odpowiedzialnej (pracownika kolekcji)
za kolekcj¦ i platform¦ informatyczn¡
PCM. Konto fabryczne przeznaczone jest do
sporadycznego wykorzystywania przy naprawie bª¦dów obsªugi systemu np:
•
Usuniecie wszystkich kont u»ytkowników uprzywilejowanych
•
Zapomnienie hasªa dost¦powego jedynego zaªo»onego konta uprzywilejowanego
oraz do zaªo»enia pierwszego konta super-u»ytkownika.
super-u»ytkownik - u»ytkownik uprzywilejowany, posiada uprawnienia pozwalaj¡ce na
konguracj¦ systemu, w tym deniowanie ról (zbiorów uprawnie«) dla innych u»ytkowników. Konguracja systemu dotyczy:
•
dodawania/modykacji/usuwania nowych serwerów do systemu (zarówno serwerów
aplikacyjnych jak i serwerów bazodanowych)
•
zakªadania kont u»ytkowników typu administrator oraz super-u»ytkownik
•
odtwarzania stanu systemu w przypadku awarii
•
przegl¡dania logów systemowych
•
anulowania zmian w systemie dokonanych przez innych u»ytkowników
administrator - u»ytkownik administracyjny kolekcji
PCM, posiada przypisan¡ co na-
jmniej jedn¡ rol¦. Ka»dy z administratorów mo»e posiada¢ nieco inny zestaw uprawnie« (ról).
ROZDZIA 2.
OPIS OGÓLNY
10
zarz¡dca - u»ytkownik administracyjny zewn¦trznych kolekcji, posiada uprawnienia zbli»one
do minimalnych uprawnie« u»ytkownika administrator , ale dotycz¡ one jedynie
podzbioru informacji nale»¡cych do danej instytucji wynajmuj¡cej cz¦±¢ funkcjonalno±ci
Platformy.
Zarz¡dcy przypisani s¡ do grupy reprezentuj¡cej dan¡ instytucj¦
(kolekcj¦ ). Prawa
zarz¡dcy s¡ jednakowe i niezale»ne od grupy, do której przy-
nale»y. Jedyna ró»nica dotyczy klasykacji danych, do których zarz¡dca ma dost¦p.
klient - u»ytkownik komercyjny, pªac¡cy za usªugi oferowane przez
Platform¦.
kolekcja - u»ytkownik wirtualny reprezentuj¡cy zewn¦trzn¡ kolekcj¦, korzystaj¡c¡ z usªug
oferowanych przez Platform¦; sªu»y do klasykowania danych, oraz do grupowania
zarz¡dców , w celu okre±lenia ich przynale»no±ci do danej kolekcji; istnieje jeden
pre-deniowany u»ytkownik typu kolekcja - u»ytkownik PCM, który reprezentuje
kolekcj¦
PCM, wªa±ciciela Platformy.
organizacja - u»ytkownik wirtualny reprezentuj¡cy inne przedsi¦biorstwo lub instytucje
(w tym instytuty naukowe); sªu»y do grupowania klientów (reprezentuj¡cych t¡
sam¡ organizacj¦).
widz - u»ytkownik odwiedzaj¡cy
Platform¦,
ale identykowalny przez system.
Widz
reprezentuje u»ytkowników posiadaj¡cych konta (identykowalnych) umo»liwiaj¡cych dost¦p do pewnych funkcjonalno±ci oferowanych w
MUP-CP Platformy,
np. forum dyskusyjne.
Platform¦, który
Platforma nie jest w stanie identykowa¢ ta-
anonimowy - u»ytkownik okre±laj¡cy ka»d¡ z osób odwiedzaj¡cych
nie autentykuje si¦ w »aden sposób.
kich u»ytkowników, poza mo»liwo±ciami oferowanymi przez mechanizm tzw. ciasteczek
(ang. cookies) czy numeru IP komputera z którego si¦ ª¡czy. U»ytkownik anonimowy ma dost¦p jedynie do cz¦±ci ogólnodost¦pnej portalu (
MUP-CPO )
system - u»ytkownik wirtualny reprezentuj¡cy inn¡ kolekcj¦, z któr¡ nast¦puje wymiana
informacji. Zawiera on nazw¦ systemu, jego adres internetowy oraz nazw¦ obsªugiwanego formatu danych.
platforma - wirtualny u»ytkownik wykorzystywany do przedstawienia czynno±ci uruchamianych przez
Platform¦ samoistnie (t.j.
1
pod wpªywem czynników innych ni» inter-
akcje z u»ytkownikami) .
2.4 rodowisko pracy systemu
Platforma dost¦pna b¦dzie poprzez uniwersalny interfejs u»ytkownika jakim jest WWW.
Interfejs ten b¦dzie wykorzystywany w sposób tradycyjny, tj. zgodnie z paradygmatem
klient - serwer.
Ze wzgl¦dów bezpiecze«stwa,
Platforma
wykorzystuje rozwi¡zania oparte o tzw.
prostego klienta aplikacji (ang. thin client), którego jedyn¡ funkcj¡ b¦dzie odbiór polece«
u»ytkownika i przekazywanie ich wizualnego efektu dziaªania.
1 platforma
UC
Caªo±¢ logiki biznesowej
pisana maªa liter¡ oznacza u»ytkownika reprezentuj¡cego system informatyczny w opisie
, podczas gdy Platforma pisana wielk¡ liter¡ oznacza system jako caªo±¢ oprogramowania i sprz¦tu
ROZDZIA 2.
OPIS OGÓLNY
11
aplikacji oraz przetwarzanie i przechowywanie danych zostaje przesuni¦te do cz¦±ci serwerowej, w której wyró»nia si¦ dwa typy serwerów (Rysunek 2.2)
•
serwery aplikacyjne - odpowiedzialne za przetwarzanie danych (logik¦ aplikacji);
komunikuj¡ si¦ one z u»ytkownikiem za pomoc¡ klienta WWW, oraz z serwerami
bazodanowymi.
•
serwery bazodanowe - odpowiedzialne za przechowywanie, przeszukiwanie i agregacj¦ danych udost¦pnianych serwerom aplikacyjnym; u»ytkownicy Platformy nie
kontaktuj¡ si¦ z serwerami bazodanowymi bezpo±rednio, a jedynie po±rednio poprzez
serwery aplikacyjne, gdy wykonywana operacja wymaga dost¦pu do danych.
Caªo±¢ systemu jest chroniona z zewn¡trz przez zapor¦ ognia (ang. rewall ). Dodatkowo,
w celu podniesienia poziomu bezpiecze«stwa, serwery aplikacyjne s¡ oddzielone od serwerów bazodanowych zapor¡ ognia.
Rysunek 2.2: Schemat budowy Platformy
Platforma powinna dobrze skalowa¢ si¦ wraz ze wzrostem ilo±ci u»ytkowników, oraz
by¢ odporna na awarie sprz¦towe, dlatego te» wykorzystuje tzw.
rozproszony model
dziaªania, w którym rezygnuje si¦ z koncepcji super-serwerów na rzecz wi¦kszej ilo±ci
jednakowych prostych serwerów, których rola i istotno±¢ dla dziaªania systemu jest jednakowa. Dodatkowo Platforma zakªada redundancj¦ danych, tj. utrzymywanie N kopii
danych (minimum dwóch kopii), co implikuje, »e nawet w przypadku awarii N-1 serwerów
system pracuje poprawnie z punktu widzenia u»ytkowników.
2.5 Zaªo»enia konstrukcyjne i implementacyjne
Platforma zakªada wykorzystanie interfejsu WWW, co automatycznie generuj¦ wymóg
wykorzystania tzw. przegl¡darki WWW. Przegl¡darki dost¦pne obecnie charakteryzuj¡
si¦ pewnymi ró»nicami w dziaªaniu i w sposobie prezentowania informacji. Poniewa» nie
jest mo»liwie wytestowanie Platformy ze wszystkimi mo»liwymi przegl¡darkami WWW,
zakªada si¦ dziaªanie Platformy i poprawne wy±wietlanie danych tylko z okre±lon¡ grup¡
przegl¡darek. Platforma b¦dzie obsªugiwa¢ poprawnie nast¦puj¡ce przegl¡darki WWW:
ROZDZIA 2.
OPIS OGÓLNY
•
Internet Exploler 7.x i 8.0
•
Mozilla Firefox 3.x i 4.0
•
Opera 11.x
•
Safari 5.x
12
Dodatkowo Platforma nie b¦dzie do swojego dziaªania wykorzystywa¢ »adnych specycznych rozszerze« dost¦pnych dla jakiejkolwiek przegl¡darki, ani wymaga¢ instalacji
jakichkolwiek dodatków (wtyczek - ang.
plugins), poza Adobe Flash Player i Adobe
PDF Viewer. Oba te dodatki, mog¡ zosta¢ zainstalowane bez udziaªu u»ytkownika (automatycznie), a z powodu ich powszechno±ci u»ycia przez serwisy internetowe, wi¦kszo±¢
u»ytkowników sieci WWW ma je ju» uprzednio zainstalowane.
Powy»sze zaªo»enia wymuszaj¡ wykorzystanie podzbioru j¦zyka HTML oraz szablonów
stylów (CSS - z ang.
Cascading Style Sheet - kaskadowy zestaw stylów), dziaªaj¡-
cych podobnie w w/w przegl¡darkach.
U»ycie CSS umo»liwia tworzenie tzw.
(ang. skins), które pozwalaj¡ na zmian¦ wygl¡du
i ingerencji w kod produkcyjny.
Platforma
Platformy
skórek
bez zmiany jej zachowania
b¦dzie wykorzystywaªa wszystkie nowo±ci
dost¦pne obecnie w produktach opartych o technologie WWW, np. AJAX - asynchroniczne odwoªania do serwera, wykorzystanie modelu DOM w skryptach Javascipt pozwalaj¡ce na zmian¦ wy±wietlanych danych bez przeªadowania (ang. reload) strony w przegl¡darce, itp.
2.6 Dokumentacja u»ytkowników systemu
Platforma powinna zosta¢ dostarczona wraz z dwoma niezb¦dnymi podr¦cznikami pozwalaj¡cymi na instalacj¦ (Instalcja Platformy PCM ) i u»ytkowanie platformy (Administracja
Platform¡ PCM ). Oba podr¦czniki zostan¡ dostarczone w formie elektronicznej - plików
w formacie PDF, które mog¡ by¢ czytane na ekranie komputera, b¡d¹ wydrukowane.
Podr¦czniki te dost¦pne b¦d¡ w j¦zyku polskim.
Dodatkowo Platforma b¦dzie wyposa»ona we wbudowany system pomocy dost¦pny z
wewn¡trz systemu - tak jak pozostaªe cz¦±ci systemu - poprzez interfejs WWW. System
pomocy b¦dzie oferowaª pomoc kontekstow¡ oraz pozwalaª na wyszukiwanie zadanego
tematu.
W systemie pomocy umieszczone zostan¡ tak»e przykªady u»ycia (tutoriale),
Platform¦. Lista
PCM, po zapoznaniu
obrazuj¡ce wykonanie podstawowych czynno±ci udost¦pnianych przez
tych czynno±ci zostanie ustalona przez przedstawiciela kolekcji
si¦ z dziaªaniem
Platformy.
Zawarto±¢ systemu pomocy zostanie podzielona na dwie
kategorie:
•
wewn¦trzna - dost¦pne jedynie w cz¦±ci administracyjno-konguracyjno-zarz¡dczej;
pomoc i przykªady dost¦pne b¦d¡ jedynie w j¦z. polskim.
•
zewn¦trzna - dost¦pne przez u»ytkowników zewn¦trznych (klient ,
widz , anon-
imowy ); pomoc i przykªady dost¦pne b¦d¡ w ka»dym z wybranych j¦zyków, w
których
Platforma ma si¦ komunikowa¢ z otoczeniem.
W ka»dej z kategorii systemu pomocy (wewn¦trzna, zewn¦trzna) zgromadzone informacje
b¦d¡ dotyczy¢ jedynie funkcjonalno±ci logicznie zwi¡zanej z dan¡ domen¡.
ROZDZIA 2.
OPIS OGÓLNY
13
2.7 Uwarunkowania zewn¦trzne dziaªania Platformy
Prawidªowe dziaªanie
Platformy
zakªada istnienie pewnych czynników zewn¦trznych,
których analiza nie jest istot¡ niniejszego dokumentu, ale których wyst¦powanie lub brak
w okre±lonej formie, mo»e zmieni¢ charakter dziaªania lub wyª¡czy¢ cz¦±¢ z funkcjonalno±ci
Platformy.
•
Do prawidªowego dziaªania Platformy zaªo»ono, »e:
Istnieje system certykacji podmiotów gospodarczych i instytucji pa«stwowych dopuszczonych do obrotu
•
MBiol.
Istnieje dopuszczalny przez prawo sposób bezpiecznego przesyªania
MBiol.
ofer-
owany przez rmy transportowe lub kurierskie.
•
Dost¦pny jest opis elektronicznego formatu systemu ksi¦gowego, do którego dane o
dokonanych zakupach oraz zwi¡zanych z nimi informacji nansowych maj¡ zosta¢
przetªumaczone.
•
Istnieje odpowiednia infrastruktura sprz¦towa i lokalowa niezb¦dna do uruchomienia
i administracji caªego systemu.
•
Mo»liwe jest uzyskanie opisu formatu
MBiol.,
wykorzystywanego przez inne sys-
temy informatyczne o podobnym prolu, z którymi
informacje.
Platforma powinna wymienia¢
Rozdziaª 3
Opis Struktur Danych
3.1 Typy pomocnicze
3.1.1 Opis Historii Izolacji (O-HI)
Typ
O-HI jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
1. Pola obowi¡zkowe
(a) imi¦ i nazwisko odkrywcy
(b) opis warunków izolacji
2. Pola opcjonalne
MBiol.
miejsce odkrycia MBiol.
(a) data odkrycia
(b)
(c) lista opisów odno±ników literaturowych (
O-OL)
3.1.2 Opis Odno±nika Literaturowy (O-OL)
Typ
O-OL jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
1. Pola obowi¡zkowe:
(a) tytuª artykuªu
(b) lista autorów, ka»dy zawiera imi¦ i nazwisko autora
(c) nazwa czasopisma
(d) oznaczenie numeru czasopisma (wolumenu)
(e) rok wydania
2. Pola opcjonalne:
(a) numer strony pocz¡tkowej
(b) numer strony ko«cowej
14
ROZDZIA 3.
OPIS STRUKTUR DANYCH
15
3.1.3 Opis Pozycji Zamówienia (O-PZ)
Typ
O-PZ jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
(a) gªównych numer identykacyjny
MBiol.
(b) specykacja typy postaci przechowywania
MBiol. (T-PPMB), w której MBiol.
ma by¢ dostarczony.
(c) cena zakupu netto
(d) ilo±¢
(e) warto±¢ procentow¡ podatku VAT
2. Pola opcjonalne:
(a) informacje dodatkowe
3.1.4 Opis Skªadnika Po»ywki (O-SP)
Typ
O-SP
jest typem strukturalnym skªadaj¡cym si¦ z pól obowi¡zkowych i opcjonal-
nych.
(a) nazwa skªadnika
(b) udziaª procentowy
2. Pola opcjonalne
3.1.5 Opis Warunków Hodowli (O-WH)
Typ
O-WH jest typem strukturalnym skªadaj¡cym si¦ jedynie z pól obowi¡zkowych.
(a) czas inkubacji
T-ZTL)
(b) zapotrzebowanie tlenowe (
(c) temeratura inkubacji
3.1.6 Typ Akceptacji Wprowadzanych Danych (T-AWD)
Typ
T-AWD jest typem wyliczeniowym i przyjmuje jedn¡ z warto±ci:
1. akceptacja automatyczna
2. akceptacja manualna
3. akceptacja automatyczna po okre±lonym czasie
ROZDZIA 3.
16
3.1.7 Typ Cz¦stotliwo±ci Synchronizacji Danych (T-CS)
Typ
T-CS
jest typem wyliczeniowym przybieraj¡cym jedn¡ z warto±ci: dziennie, tygod-
niowo, miesi¦cznie.
3.1.8 Typ Dost¦pu Do Rekordu (T-DDR)
T-DDR jest typem wyliczeniowym przybieraj¡cym jedn¡ z warto±ci podanych poni»ej:
1. dla wszystkich u»ytkowników
2. dla okre±lonych
kolekcji
3. dla
administratorów
4. dla
administratorów i okre±lonego klienta
3.1.9 Typ ¡cznika Do Pliku (T-LDP)
Typ
T-LDP jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
(a) nazwa orginalnego pliku
(b) nazwa linku
(c) format pliku
(d) poªo»enie pliku
1
2. Pola opcjonalne:
3.1.10 Typ ¡cznik Do Rekordu Gospodarza (T-LDRMB)
Typ
T-LDRMB jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
R-DMB)
(a) identykor rekordu MBiol. (
(b) wy±wietlana nazwa jako organizmu gospodarza
2. Pola opcjonalne
1 okre±la scie»k¦ do pliku, lub identykator pliku w innej tabeli bazy danych
ROZDZIA 3.
17
3.1.11 Typ Historii Namna»ania MBiol. (T-HNMB)
Typ
T-HNMB jest typem strukturalnym zawieraj¡cym jedynie pola obowi¡zkowe.
(a) miejsce przechowywania
(b) data skªadowania (wykonania próbki)
(c) identykator administratora (pracownika
PCM) który wykonaª próbk¦
(d) termin wa»no±ci próbki
(e) ilo±¢ dodanych próbek
3.1.12 Typ Magazynowania MBiol. (T-MMB)
T-MMB jest typem strukturalnym zawieraj¡cym
TPP-MB , a dla ka»dej pozycji na li±cie:
Typ
pola obowi¡zkowe i opcjonalne.
(a) typ postaci przechowywania
MBiol. (T-PPMB)
(b) ilo±¢ dost¦pnych sztuk
(c) wymagana minimalna ilo±¢ sztuk
(d) lista historii namna»ania
MBiol. (T-HNMB)
2. Pola opcjonalne:
3.1.13 Typ Postaci Przechowywania MBiol. (T-PPMB)
T-PPMB jest typem wyliczeniowym przybieraj¡cym jedn¡ z warto±ci podanych poni»ej:
1. liolizat
2. wysuszone (na kr¡»kach)
3. zamro»ony (zamra»arka)
4. zamro»ony (ciekªy azot)
5. o»ywiony
3.1.14 Typ Poziomu Bezpiecze«stwa Biologicznego (T-PBB)
Typ
T-PBB
jest typem numerycznym przyjmuj¡cym warto±ci: 1, 2, 3, 4. Warto±¢ 1 deniuje najni»szy
PBB - a warto±¢ 4 najwy»szy
PBB.
ROZDZIA 3.
18
3.1.15 Typ Protokoªu Wymiany Danych (T-PWD)
Typ
T-PWD jest typem wyliczeniowym przybieraj¡cym jedn¡ z warto±ci:
1. protokóª CABRI
2. protokóª MCL
3.1.16 Typ Rekordów MBiol. (T-RMB)
T-RMB jest typem wyliczeniowym przybieraj¡cym jedn¡ z warto±ci podanych poni»ej:
1. bakterie
2. bakteriofagi
3. archea
4. dro»d»e i grzyby
5. linie komórkowe ludzkie
6. linie komórkowe zwierz¦ce
7. linie komórkowe ro±linne
8. linie komórkowe typu: hybrydoma
9. plazmidy
10. wirusy
11. surowice
12. ro±liny (nasiona)
3.1.17 Typ Sposobu Pªatno±ci (T-SP)
Typ
T-SP jest typem wyliczeniowym przybieraj¡cym jedn¡ z warto±ci podanych poni»ej:
1. pªatno±¢ kart¡
2. pªatno±¢ przelewem na konto
3.1.18 Typ Stanu Konta (T-SK)
Typ
T-SK2
jest typem wyliczeniowym przyjmuj¡cym jedn¡ z warto±ci:
1. aktywne
2. nieaktywne
2 stan konta dotyczy kont u»ytkowników dowolnego typu, lub kont organizacji, np. u»ytkownik typu
system
ROZDZIA 3.
19
3.1.19 Typ Stanu Pªatno±ci (T-SP)
Typ
T-SP
jest typem wyliczeniowym z blokad¡, tj.
pozwalaj¡cym wybra¢ jak¡kol-
wiek warto±¢ z listy przedstawionej poni»ej, dopóki nie zostanie wybrana warto±¢ oznaczona jako stan ko«cowy . Wybranie takiej warto±ci blokuje mo»liwo±¢ przyszªej zmiany
warto±ci
T-SP. T-SP mo»e przybra¢ jedn¡ z warto±ci podanych poni»ej:
1. niezapªacone
2. zapªacone cz¦±ciowo
3. windykacja
4. zapªacone (stan ko«cowy)
5. windykacja skuteczna (stan ko«cowy)
6. windykacja nieskuteczna (stan ko«cowy)
3.1.20 Typ Stanu Zlecenia (T-SZ)
Typ
T-SZ
jest typem wyliczeniowym z blokad¡, tj.
pozwalaj¡cym wybra¢ jak¡kol-
wiek warto±¢ z listy przedstawionej poni»ej, dopóki nie zostanie wybrana warto±¢ oznaczona jako stan ko«cowy . Wybranie takiej warto±ci blokuje mo»liwo±¢ przyszªej zmiany
warto±ci
T-SZ. T-SZ mo»e przybra¢ jedn¡ z warto±ci podanych poni»ej:
1. wstrzymane
2. nowe
3. oczekuj¡ce
4. realizowane
5. wysªane
6. zwrócone (stan ko«cowy)
7. odrzucone (stan ko«cowy)
8. zrealizowane (stan ko«cowy)
9. anulowane (stan ko«cowy)
10. rezygnacja (stan ko«cowy)
11. zmodykowane (stan ko«cowy)
ROZDZIA 3.
20
3.1.21 Typ Synchronizacji Danych (T-SD)
Typ
T-SD jest typem wyliczeniowym przybieraj¡cym jedn¡ z warto±ci:
1. tylko import
2. tylko export
3. import-export
3.1.22 Typ Zapotrzebowanie Tlenowe (T-ZTL)
Typ
T-ZTL jest typem wyliczeniowym przyjmuj¡cym nast¦puj¡ce warto±ci:
1. beztlenowe
2. tlenowe
3. mikroaerolne
3.1.23 Typ Zmiennych Cen (T-ZC)
Typ
T-ZC to typ strukturalny zawieraj¡cy tylko pola obowi¡zkowe.
(a) cena w PLN
(b) cena w USD
(c) cena w EUR
(d) data od której obowi¡zuje
3.1.24 Typ Resrykcji (T-RST)
Typ
T-RST , jest typem wyliczeniowym, przybieraj¡cym jedn¡ z nast¦puj¡cych warto±ci:
1. tylko Polska
2. tylko kraje UE
3. tylko kraje UE, USA, Kanada, Autralia, Japonia
4. wybrane kraje
5. wszystkie kraje
ROZDZIA 3.
21
3.1.25 Typ Przesyªki (T-PRZ)
Typ
T-PRZ jest typem strukturalnym zawieraj¡cym jedynie pola obowi¡zkowe.
(a) identykator typu przesyªki
(b) opis typu przesyªki
T-RST)
(c) restrykcje (
(d) lista zmiennych cen (
T-ZC)
(e) dost¦pno±¢ (tak/nie)
3.1.26 Typ Transportu MBiol. (T-TMB)
Typ T-TMB jest typem strukturalnym posiadaj¡cym pola obowi¡zkowe i opcjonalne.
(a) identykator przewo¹nika
(b) nazwa przewo»nika
(c) lista typów przesyªek (
T-PRZ)
(d) aktywny (tak/nie)
2. Pola opcjonalne:
3.2 Rekord Danych Organizacji (R-DO)
Typ
R-DO
jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
DO wyst¦puje w kilku podtypach w zale»no±ci od typu opisywej organizacji.
3.2.1 R-DO dla kolekcji
(a) identykator
(b) peªna nazwa
(c) adres
(d) telefon kontaktowy
(e) imi¦ i nazwisko osoby kontaktowej
T-PBB)
akceptacja wprowadzanych danych (T-AWD)
(f ) poziom bezpiecze«stwa biologicznego (
(g)
2. Pola opcjonalne:
R-
ROZDZIA 3.
22
3.2.2 R-DO dla organizacji
(a) identykator
(b) peªna nazwa
(c) adres
(d) telefon kontaktowy
(e) imi¦ i nazwisko osoby kontaktowej
T-PBB)
(f ) poziom bezpiecze«stwa biologicznego (
2. Pola opcjonalne:
3.2.3 R-DO dla systemów
(a) identykator
(b) peªna nazwa organizacji która jest wªa±cicielem systemu informatycznego.
(c) adres URL - wykorzystywany do pobierania danych
T-PWD)
cz¦stotliwo±¢ synchronizacji danych (T-CS)
synchronizacja danych (T-SD)
stan konta (T-SK)
(d) protokóª wymiany danych (
(e)
(f )
(g)
2. Pola opcjonalne:
(b) adres organizacji
(c) imi¦ i nazwisko osoby kontaktowej
(d) numer telefonu
(e) email
3.3 Rekord Danych U»ytkowników (R-DU)
Rekord
R-DU
jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
R-DU wyst¦puje w kilku podtypach w zale»no±ci od typu opisywanego u»ytkownika.
ROZDZIA 3.
3.3.1 R-DU u»ytkownika
23
fabrycznego
(a) identykator - adres email: default@[domena wªa±ciciela
(b) hasªo - ustalone przez producenta
Platformy]
Platformy, indywidualnie dla ka»dej insta-
lacji osobno.
(c) certykat elektroniczny
(d) tzw. klucz prywatny niezb¦dny do re-generacji certykatu; klucz jest szyfrowany
za pomoc¡ hasªa u»ytkownika
2.
R-DU dla u»ytkownika fabrycznego
nie zawiera »adnych pól opcjonalnych.
super-u»ytkownik
(a) identykator - adres email
(b) hasªo
(c) imi¦
(d) nazwisko
(e) certykat elektroniczny
(f ) tzw. klucz prywatny niezb¦dny do ponownej generacji certykatu; klucz jest
szyfrowany za pomoc¡ hasªa u»ytkownika
T-SK)
(g) stan konta (
2. Pola opcjonalne:
(a) numer telefonu komórkowego
administrator
(b) hasªo
(c) imi¦
(d) nazwisko
(e) certykat elektroniczny
(f ) tzw. klucz prywatny niezb¦dny do re-generacji certykatu; klucz jest szyfrowany
za pomoc¡ hasªa u»ytkownika
T-SK)
(g) stan konta (
2. Pola opcjonalne:
ROZDZIA 3.
3.3.4 R-DU u»ytkownik
24
klient
(b) hasªo
(c) imi¦
(d) nazwisko
(e) identykator instytucji/przedsi¦biorstwa, którego reprezentantem jest
(f ) stan konta (
T-SK)
2. Pola opcjonalne:
zarz¡dca
(b) hasªo
(c) imi¦
(d) nazwisko
(e) identykator
(f ) stan konta (
kolekcji , której reprezentantem jest zarz¡dca .
T-SK)
2. Pola opcjonalne:
3.3.6 R-DU dla u»ytkownika widz
(a) identykator - tzw. nick.
(b) hasªo
(c) adres email
T-SK)
(d) stan konta (
2. Pola opcjonalne:
(a) imi¦
(b) nazwisko
(c) numer telefonu komórkowego
klient .
ROZDZIA 3.
25
3.4 Rekord Transakcji Zakupu MBiol. (R-TZMB)
Typ
R-TZMB jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
(a) identykator transakcji
(b) identykator transakcji nadrz¦dnej
(c) identykator konta
3
klienta
(d) data dokonania zamówienia
(e) estymowany termin realizacji
O-PZ)
typ transportu zmówionego MBiol. (T-TMB)
stan zlecenia (T-SZ)
stan pªatno±ci (T-SP)
(f ) lista pozycji zamówienia (
(g)
(h)
(i)
(j) kwota zapªacona
2. Pola opcjonalne:
3.5 Rekord Danych Po»ywki (R-DP)
Typ
R-RD jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
(a) identykator po»ywki
(b) typ po»ywki
(c) opis wªa±ciwo±ci po»ywki
O-SP)
(d) lista opisów skªadników po»ywki (
(e) lista zmiennych cen (
T-ZC)
2. Pola opcjonalne:
(a) lista opisów odno±ników literaturowych (
O-OL)
(b) informacje dodatkowe
3 transakcja nadrz¦dna - transakcja bazowa, na podstawie której zostaªa stworzona dana transakcja.
Transakcj¡ bazow¡ mo»e zosta¢ jakakolwiek inna transakcja, której stan transakcji (S-T) jest tzw.
stanem ko«cowym.
Wykorzystanie:
1.
Klient
modykuje transakcj¦ - transakcja orginalna jest za-
pisywana jako modykowana (nie b¦dzie realizowana), tworzona jest nowa transakcja, b¦d¡ca kopi¡
transakcji orginalnej, w której
klient
dokonuje wymaganych zmian - nowa transakcja b¦dzie reali-
zowana; 2. Klient potrzebuje utworzy¢ now¡ transakcje bed¡c¡ w du»ym stopniu zbie»n¡ z inn¡ zrealizowan¡/anulowan¡/modykowan¡ transakcj¡. Wybieraj¡c tak¡ transakcje, klient ma uproszczone zadanie
tworzenia zlecenia - modykuje list¦ zamówie« (np. ilo±¢ MBiol. b¡d¹ typ postaci przechowywania) zamiast tworzy¢ list¦ od nowa. W przypadku caªkowicie nowych transakcji, identykator transakcji nadrz¦dnej powinien przyjmowa¢ tzw.
warto±¢ niedopuszczaln¡ identykatora transakcji, zale»n¡ od przyj¦tej
konkencji identykacji transakcji, np. null, (napis pusty), czy -1.
ROZDZIA 3.
26
3.6 Rekord Danych MBiol. (R-DMB)
Typ
R-DMB jest typem strukturalnym zawieraj¡cym pola obowi¡zkowe i opcjonalne.
(a) nazw¦
MBiol.
(b) gªówny numer identykacyjny
(c) typ rekordu
MBiol. (T-RMB)
(d) poziom bezpiecze«stwa biologicznego (
T-PBB)
T-DDR)
lista typów magazynowania MBiol. (T-MMB)
lista zmiennych cen (T-ZC)
resrykcje (T-RST) wywozu
restrykcje (T-RST) przywozu
(e) dost¦p do rekordu (
(f )
(g)
(h)
(i)
2. Pola opcjonalne:
(a) lista mo»liwych po»ywek (identykatorów po»ywek)
(b) lista równowa»nych identykatorów
4
O-OL)
lista ª¡czników do pliku (T-LDP) zawieraj¡cego zdj¦cie z pªytki (format JPEG)
lista ª¡czników do pliku (T-LDP) zawieraj¡cego zdj¦cie z mikroskopu (format
(c) lista odno±ników literaturowe (
(d)
(e)
JPEG)
O-WH)
(f ) opis warunków hodowli (
(g) opis wªa±ciwo±ci biochemicznych (
T-WBCH)
O-HI)
(h) opis historii izolacji (
(i) ª¡cznik do pliku ( T-LDP ) zawieraj¡cego procedur¦ o»ywiania (format PDF )
(j) ª¡cznik do pliku ( T-LDP ) zawieraj¡cego instrukcj¦ BHP (format PDF )
(k) identykator deponenta
(l) ª¡cznik do pliku (
T-LDP)
zawieraj¡cego instrukcj¦ przysªania MBiol.
(dla
depozytów)
(m) ª¡cznik do rekordu gospodarza (
T-LDRMB)
(n) opis zastosowania (np. produkcja metabolitów biochemicznych)
(o) informacje dodatkowe
4 identykator równowa»ny danego MBiol. - to inny identykator danego MBiol. pod którym jest
on identykowalny w innych kolekcjach mikroorganizmów.
Rozdziaª 4
Wymagania ogólne Platformy
1.
Platforma wykonuje zapis wszystkich czynno±ci zmieniaj¡cych stan systemu, zanim
dana czynno±¢ zostanie wykonana (tzw. dziennik systemowy) - {5}.
2.
Platforma
wykonuje zapis wyniku wykonania ka»dej z czynno±ci zmieniaj¡cych
stan systemu - {5}.
3.
Platforma wykonuje zapis wszystkich polece« wydanych przez u»ytkowników systemu, zanim polecenie zostanie przekazane do wykonania - {5}.
4.
Platforma
wykonuje zapis wydarze« do dziennika systemowego bez wzgl¦du na
role czy uprawnienia u»ytkownika, który j¡ zainicjowaª - {5}.
5.
Platforma nie dopuszcza do jakichkolwiek zmian w strukturze czy zawarto±ci dziennika systemowego - {5}.
6.
Platforma
nie dopuszcza do usuwania jakichkolwiek kont u»ytkowników nieza-
le»nie od typu konta - {5}.
7.
Platforma nie dopuszcza do usuni¦cia jakichkolwiek rekordów opisuj¡cych MBiol.
- {5}.
8.
Platforma przechowuje informacje nt. MBiol.
w formacie opisanym w rozdziale 3.6
na poprzedniej stronie - {5}.
9.
Platforma przechowuje informacje nt. Po»ywek w formacie opisanym w rozdziale 3.5
na stronie 25- {5}.
10.
Platforma umo»liwia import/eksport danych dost¦pnych w formacie MCL. - {4}.
11.
Platforma umo»liwia import/eksport danych dost¦pnych w formacie CABRI. - {4}.
12.
Platforma
umo»liwia automatyczn¡ wymian¦ informacji pomi¦dzy instytucjami
pozwalaj¡cymi na wymian¦ danych w formacie MCL i CABRI . - {3}.
13.
14.
Platforma przechowuje pobrane dane w odr¦bnej bazie danych, rozª¡cznej z reszt¡
danych udost¦pnianych poprzez PCM - {5}.
Platforma umo»liwia na wybór danych dot. MBiol., które mog¡ by¢ udost¦pniane
innym systemom informatycznym - {3}.
27
Rozdziaª 5
Wymagania Moduªu Konguracyjnego
Platformy (MKP)
1.
2.
MKP oferuje jedynie polskoj¦zyczny interfejs u»ytkownika - {5}.
MKP
dost¦pna jest tylko dla wybranej grupy kilku osób super-u»ytkowników
- {5}.
3.
MKP traktuje u»ytkownika fabrycznego
tak jak jednego z
super-u»ytkowników
- {5}.
4.
MKP
dokonuje werykacji certykatu u»ytkownika przed udzieleniem dost¦pu -
{5} [UD-WER-CERT].
5.
MKP
dokonuje werykacji to»samo±ci u»ytkownika przed udzieleniem dost¦pu -
{5} [UD-LOG].
6.
MKP ko«czy sesj¦ z po upªywie okre±lonego czasu braku aktywno±ci super-u»ytkownika
- {5} [UC-AUTO-OFF].
7.
MKP umo»liwia zako«czenie sesji - {5} [UC-LOGOUT].
8.
MKP ustawia domy±ln¡ warto±¢ maksymalnego czasu braku aktywno±ci, po którym
system zako«czy bie»¡c¡ sesj¦ - {5}.
9.
MKP umo»liwia zmian¦ maksymalnego czasu braku aktywno±ci u»ytkowników, po
którym
10.
MKP
system zako«czy bie»¡c¡ sesj¦ - {3}.
udost¦pnia taki sam zbiór uprawnie« ka»demu z
super-u»ytkowników -
{5}.
11.
MKP wymaga konguracji infrastruktury PKI Platformy przed wykorzystaniem
jej jakichkolwiek innych funkcjonalno±ci, wª¡czaj¡c w to tworzenie dodatkowych
kont
12.
super-u»ytkowników czy administratorów - {5}.
MKP generuje klucz prywatny dla ka»dego nowo utworzonego konta super-u»ytkownika
- {5}.
28
ROZDZIA 5. WYMAGANIA MODUU KONFIGURACYJNEGO PLATFORMY (MKP)29
13.
MKP generuje klucz prywatny dla ka»dego nowo utworzonego konta administratora - {5}.
14.
MKP
super-u»ytkownika za
szyfruje klucz prywatny nowo utworzonego konta
pomoc¡ podanego hasªa u»ytkownika - {5}.
15.
MKP
szyfruje klucz prywatny nowo utworzonego konta
administratora za po-
moc¡ podanego hasªa u»ytkownika - {5}.
16.
MKP
tworzy certykat u»ytkownika dla ka»dego nowo utworzonego konta
super-
u»ytkownika - {5}.
17.
MKP tworzy certykat u»ytkownika dla ka»dego nowo utworzonego konta administratora - {5}.
18.
MKP umo»liwia tworzenie/modykacj¦/dezaktywacj¦/aktywacj¦ kont super-u»ytkowników
- {5}.
19.
MKP
umo»liwia tworzenie/modykacj¦/dezaktywacj¦/aktywacj¦ kont
adminis-
tratorów - {5}.
20.
MKP
uniewa»nia certykat dla dezaktywowanego konta
super-u»ytkownika -
{4}.
21.
MKP uniewa»nia certykat dla dezaktywowanego konta administratora
22.
MKP
wymaga zdeniowania jednej
jów, tzw.
23.
Roli minimum - {5}.
Roli
- {4}.
deniuj¡cej minimalny zestaw przywile-
MKP umo»liwia deniowanie Ról poprzez przypisanie nazwy do zbioru przywilejów
odpowiadaj¡cych ka»demu z wymaga« zdeniowanym w rozdziale 6, opisuj¡cym
wymagania Platformy dla Cz¦±ci Administracyjnej - {5}.
24.
25.
MKP przypisuje ka»demu
Rol¦ minimum - {5}.
nowo tworzonemu u»ytkownikowi administracyjnemu
MKP umo»liwia przypisanie listy Ról ka»demu z u»ytkowników administracyjnych
- {5}.
26.
MKP umo»liwia przegl¡danie dziennika systemowego - {3}.
27.
MKP
umo»liwia wyszukiwanie w dzienniku systemowym wydarze« speªniaj¡cych
zadane kryterium lub kryteria, np. danego typu, wykonane danego dnia lub przez
konkretnego u»ytkownika - {3}.
28.
MKP
umo»liwia przywrócenia stanu sytemu platformy
PCM
do dowolnego mo-
mentu z przeszªo±ci - {4}.
29.
MKP
wykonuje operacj¦ przywrócenie stanu systemu do okre±lonego momentu w
czasie po wpisaniu jej w dzienniku systemowym (jako kolejne wydarzenie w systemie) - {4}.
ROZDZIA 5. WYMAGANIA MODUU KONFIGURACYJNEGO PLATFORMY (MKP)30
30.
MKP ustawia domy±ln¡ warto±¢ cz¦stotliwo±ci wykonywania kopii zapasowej danych
systemu - {4}.
31.
MKP
umo»liwia zmian¦ domy±lnej warto±ci cz¦stotliwo±ci wykonywania kopii za-
pasowej - {4}.
32.
MKP ustawia maksymaln¡ cz¦sto±¢ notykacji administratorów
przez
system -
{5}.
33.
MKP umo»liwia zmian¦ maksymalnej cz¦stotliwo±ci notykacji administratorów
przez
34.
system - {3}.
MKP ustawia tzw.
czas inkubacji zlecenia, tj. maksymalny czas przez który nowo
powstaªe zlecenie nie jest przestawiane w stan oczekuj¡ce - {5}.
35.
MKP umo»liwia zmian¦ czasu inkubacji, o ile nowa warto±¢ jest mniejsza od maksymalnego czasu realizacji zlecenia - {3}.
36.
MKP
ustawia maksymalny czasie realizacji zlecenia, tj. czas który powinien up-
ªyn¡¢ pomi¦dzy utworzeniem zlecenia a jego realizacj¡ (wysªaniem do
klienta ) -
{4}.
37.
MKP umo»liwia zmian¦ maksymalnego czasu realizacji zlecenia, o ile nowa warto±¢
jest wi¦ksza od czasu inkubacji - {3}.
38.
39.
MKP umo»liwia dodanie/dezaktywacj¦/reaktywacj¦ serwerów bazodanowych wykorzystanych przez Platform¦ - {3}.
MKP umo»liwia dodanie/dezaktywacj¦/reaktywacj¦ serwerów aplikacyjnych wykorzystanych przez Platform¦ - {3}.
Rozdziaª 6
Wymagania Moduªu Administracyjnego
Platformy (MAP)
6.1 Ogólna
1.
2.
3.
MAP oferuje jedynie polskoj¦zyczny interfejs u»ytkownika - {5}.
MAP udost¦pniony jest jedynie
PCM - administratorów - {5}.
dla wybranej grupy osób pracowników kolekcji
MAP dokonuje werykacji certykatu u»ytkownika przed udzieleniem dost¦pu - {5}
[UD-WER-CERT].
4.
MAP
dokonuje werykacji to»samo±ci u»ytkownika przed udzieleniem dost¦pu -
{5} [UD-LOG].
5.
MAP ko«czy sesj¦ z po upªywie okre±lonego czasu braku aktywno±ci administratora - {5} [UC-AUTO-OFF].
6.
7.
MAP umo»liwia zako«czenie sesji - {5} [UC-LOGOUT].
MAP powiadamia administratorów zalogowanych do systemu o wyst¡pieniu zdeniowanych wydarze«, opisanych poni»ej - {4}.
8.
MAP pokazuje powiadomienia z ustalon¡ maksymaln¡ cz¦stotliwo±ci¡ - {3}.
9.
MAP umo»liwia zmian¦ kolorów, tªa, elementów wygl¡du interfejsu u»ytkownika {2}.
10.
MAP umo»liwia modykacj¦ wygl¡du pulpitu poprzez zmian¦ rozstawienie elementów na ekranie - {1}.
11.
MAP umo»liwia deniowanie zada« dla poszczególnych administratorów
12.
MAP umo»liwia podgl¡danie zada« danego administratora
13.
MAP
(swoich zada«) - {3}.
umo»liwia przegl¡danie/wyszukiwanie zada« wszystkich
- {3}.
31
- {3}.
administratorów
ROZDZIA 6. WYMAGANIA MODUU ADMINISTRACYJNEGO PLATFORMY (MAP) 32
14.
MAP
umo»liwia
administratorowi zaznaczenie wykonania zleconego zadania -
{3}.
15.
MAP umo»liwia dodawanie/modikacj¦/usuwanie notatek (informacji tekstowych)
- {2}.
6.2 Cz¦±¢ Administrowania Magazynem (MAP-CAM)
1.
MAP-CAM ustawia minimaln¡
MBiol. - {5}.
ilo±ci sztuk dost¦pnych danego
T-PPMB,
dla
danego typu
2.
3.
4.
5.
6.
MAP-CAM umo»liwia zmian¦ minimalnej
MB, dla danego typu MBiol. -{3}.
MAP-CAM umo»liwia dodanie
danego typu MBiol. - {5}.
TPP-
TPP-MB,
dla
MAP-CAM umo»liwia tworzenie/modykacj¦/dezaktywacj¦/aktywacj¦ danych Po»ywek- {5}.
MAP-CAM umo»liwia przygotowanie/wydruk kart identykacyjnych (w formacie
PDF ) dla wybranych typów MBiol. - {4}.
MAP-CAM informuje administratorów
T-PPMB dla danego MBiol.
T-PPMB jest równa ustawionej
o braku
gdy minimalna ilo±¢ sztuk dost¦pnych danego
minimalnej ilo±ci - {5}.
7.
MAP-CAM informuje administratorów o braku danego MBiol., gdy dla wszysTPP-MB, ilo±¢ dost¦pnych sztuk jest mniejsza od minimalnej
tkich pozycji na li±cie
- {5}.
8.
9.
MAP-CAM umo»liwia wyszukiwanie MBiol.
istratora - {3}.
MAP-CAM
namna»anych przez danego
admin-
umo»liwia przegl¡danie/przeszukiwanie historii namna»ania
MBiol.
- {4}
6.3 Cz¦±¢ Administrowania Zleceniami (MAP-CAZ)
1.
MAP-CAZ umo»liwia eksport danych faktur zamówie« zakupu MBiol.
w forma-
cie elektronicznym zgodnym z systemem ksi¦gowym Instytutu IITD PAN - {5}.
2.
MAP-CAZ umo»liwia eksport danych faktur zamówie« zakupu MBiol.
w forma-
cie PDF - {3}.
3.
MAP-CAZ
{4}.
umo»liwia wyszukiwanie faktur na podstawie zadanych kryteriów -
4.
MAP-CAZ umo»liwia dla niektórych typów pªatno±ci na zaznaczanie faktu dokonania zapªaty za faktur¦ - {4}.
5.
MAP-CAZ umo»liwia wydruk wybranych faktur - {4}.
6.
MAP-CAZ informuje administratorów
7.
MAP-CAZ umo»liwia wyszukiwanie zlece« wedªug zadanych kryterium - {5}.
8.
MAP-CAZ zmienia status nowo utworzonych zamówie« z nowe o nowo utworzonych zamówieniach - {5}.
na oczekuj¡ce je»eli min¡ª ustalony minimalny czas inkubacji nowych zlece« - {3}.
9.
MAP-CAZ
informuje
administratorów o zleceniach które nie osi¡gn¦ªy stanu
wysªane w okre±lonym czasie - maksymalnym czasie realizacji zlecenia -{4}.
10.
MAP-CAZ umo»liwia zmian¦ stanu pªatno±ci (T-SP) zlecenia klienta , o ile stan
pªatno±ci jest ró»ny od którego± z tzw. stanów ko«cowych - {5}.
11.
MAP-CAZ umo»liwia zmian¦ aktualnego stan zamówienia (T-SZ), o ile stan pªatno±ci jest ró»ny od którego± z tzw. stanów ko«cowych - {4}.
6.3.1 Cz¦±¢ Administrowania Zleceniami Depozytu (MAP-CAZD)
1.
MAP-CAZD zatwierdzenie informacji nt.
deponowanego
MBiol.
po sprawdzeniu
stanu pªatno±ci zlecenia deponowania oraz zycznym otrzymaniu próbki
MBiol.,
a nast¦pnie generuje ±wiadectwo przyj¦cia do depozytu i nadaje unikatowy numer
depozytu danemu
2.
MBiol.
- {5}.
MAP-CAZD umo»liwia pobranie/wydrukowanie ±wiadectwa przyj¦cia do depozytu
wraz z nadanym numerem - {5}.
3.
MAP-CAZD wymaga wyspecykowania ilo±ci i postaci otrzymanych próbek MBiol.
- {5}.
4.
MAP-CAZD wymaga wyspecykowania daty zycznego odbioru próbek MBiol.
- {5}.
6.4 Cz¦±¢ Administrowania Danymi (MAP-CAD)
1.
2.
3.
MAP-CAD umo»liwia
danych MBiol. - {5}.
tworzenie/modykacj¦/dezaktywacj¦/aktywacj¦ rekordów
MAP-CAD umo»liwia tworzenie/modykacj¦/dezaktywacj¦/aktywacj¦
danych Po»ywek. - {5}.
MAP-CAD
oznacza wszystkie nowo tworzone rekordy
informacj¡ o przynale»no±ci do kolekcji
4.
MAP-CAD
PCM - {3}.
MBiol.
lub
rekordów
Po»ywek
MBiol. i ich cech (pól rekordu R-DMB)
przygotowanie wydruku katalogu MBiol. (w formacie PDF ) - {4}.
umo»liwia wyboru
w celu
5.
6.
7.
8.
MAP-CAD umo»liwia zatwierdzanie danych opisuj¡cych MBiol.
Platform¦ z innych systemów informatycznych - {4}.
pobranych przez
MAP-CAD umo»liwia tworzenie/modykacj¦ listy T-PPMB - {3}
MAP-CAD umo»liwia
RMB) - {3}.
MAP-CAD
tworzenie/modykacj¦ listy typów rekordu
MBiol.
T-
(
umo»liwia dodawanie/podmian¦ plików PDF dotycz¡cych procedur
o»ywiania zakupionego materiaªu - {4}.
9.
10.
MAP-CAD umo»liwia dodawanie/podmian¦ plików PDF zawieraj¡cych instrukcje
BHP zwi¡zane obsªug¡ MBiol. o zadanym T-PBB - {4}.
MAP-CAD umo»liwia tworzenie/podmian¦/usuwanie poª¡czenia pomi¦dzy danym
MBiol. a odpowiedni¡ instrukcj¡ BHP - {4}.
typem
11.
MAP-CAD umo»liwia tworzenie/podmian¦/usuwanie poª¡czenia pomi¦dzy danym
typem MBiol. a odpowiedni¡ procedur¡ o»ywiania MBiol. - {4}.
6.5 Cz¦±¢ Administrowania U»ytkownikami (MAP-CAU)
1.
MAP-CAU
umo»liwia tworzenie/dezaktywacj¦/reaktywacj¦ konta
systemu .
-
{5}.
2.
MAP-CAU
ustawia domy±ln¡ cz¦stotliwo±¢ wymiany informacji dla danego
sys-
temu - {3}.
3.
MAP-CAU umo»liwia zmian¦ cz¦stotliwo±ci wymiany informacji dla danego systemu - {3}.
4.
MAP-CAU ustawia domy±lny typ protokoªu wymiany danych (T-PWD) - {4}.
5.
MAP-CAU umo»liwia zmian¦ typu protokoªu wymiany danych - {3}.
6.
MAP-CAU ustawia domy±lny typ synchronizacji danych (T-SD) - {5}.
7.
MAP-CAU umo»liwia zmian¦ typu synchronizacji danych - {3}.
8.
MAP-CAU umo»liwia dezaktywacj¦/reaktywacj¦ konta klienta
9.
MAP-CAU umo»liwia sprawdzenie bilansu pªatniczego ka»dego z klientów
10.
- {5}.
- {4}.
MAP-CAU umo»liwia dodanie do kont typu klient , zeskanowanych obrazów dokumentów dostarczonych przez u»ytkownika (np. poczt¡ lub kurierem) - {3}.
11.
MAP-CAU
umo»liwia aktywacj¦/dezaktywacj¦/reaktywacj¦ kont
zarz¡dców -
{5}.
12.
MAP-CAU
informuje
administratorów o nowych zapytaniach/wiadomo±ciach
anonimowych z MUP-CPO - {5}.
przesªanych przez u»ytkowników
13.
MAP-CAU
umo»liwia odpowied¹ na zapytania przesªane z
u»ytkowników
MUP-CPO
przez
anonimowych . Informacja zwrotna odsyªana jest poczt¡ elektron-
iczn¡, na adres podany w wiadomo±ci - {5}.
14.
15.
MAP-CAU umo»liwia zmian¦ Poziomu Bezpiecze«stwa
MBiol. dost¦pnego dla danego klienta - {5}.
MAP-CAU
umo»liwia zatwierdzanie modykacji dokonanych przez
nale»¡cych do danej
16.
17.
T-PBB)
Biologicznego (
zarz¡dców
kolekcji - {4}.
MAP-CAU umo»liwia tworzenie/modykacj¦ grup deniuj¡cych najemców Platformy - kolekcji - {5}.
MAP-CAU umo»liwia zmiane typu akceptacji wprowadzonych danych (T-AWD)
dla modykacji dokonanych przez
zarz¡dców nale»¡cych do okre±lonej kolekcji -
{3}.
6.6 Cz¦±¢ Administrowania CMS (MAP-CAC)
1.
MAP-CAC umo»liwia okre±lenie tzw. j¦zyka podstawowego dla Moduªu U»ytkowego
(MUP), który b¦dzie u»ywany, gdy odpowiednia wersja j¦zykowa jest niedost¦pna
-{4}.
2.
MAP-CAC
umo»liwia wyª¡czenie, dla okre±lonych informacji, automatycznego
tªumaczenia informacji prezentowanych w
3.
MUP - {4}.
MAP-CAC wymaga dla informacji z wyª¡czonym automatycznym tªumaczeniem,
dodanie co najmniej wersji przetªumaczonej na j¦zyk podstawowy - {2}.
4.
MAP-CAC umo»liwia
MUP-CPO - {5}:
tworzenie/modykacj¦/usuwanie danych wy±wietlanych w
(a) historii kolekcji PCM
(b) danych kotaktowych
(c) informacji o zmianach w taksonomii
(d) informacji o nowinkach technicznych w labolatorium
(e) informacji o planowanych konferencjach nauowych
5.
MAP-CAC umo»liwia modykacje struktury informacyjnej w MUP-CPO - tzw.
funkcjonalno±¢ CMS- {5}.
6.7 Cz¦±¢ Administrowania Raportami (MAP-CAR)
1.
MAP-CAR umo»liwia tworzenie nast¦puj¡cych raportów z wykorzystania i u»ytkowania cz¦±ci u»ytkowej Platformy:
(a) ilo±¢ u»ytkowników danego typu - {5}
(b) zmiana ilo±ci u»ytkowników danego typu - {5}
(c) rozkªad geograczny zycznej lokalizacji u»ytkowników - {2}
(d) cz¦stotliwo±¢ wizyt danego u»ytkownika - {3}
(e) cz¦stotliwo±¢ wizyt danej grupy u»ytkowników - {3}
(f ) cz¦stotliwo±¢ wizyt u»ytkowników danego typu - {3}
(g) ilo±ci odwiedzin - {5}
(h) zmiana ilo±ci odwiedzin - {4}
(i) ilo±¢ u»ytkowników telekonferencji - {5}
(j) zmiana ilo±ci u»ytkowników telekonferencji - {4}
(k) ilo±ci wiadomo±ci wysªanych na forum - {3}
(l) zmiana ilo±ci wiadomo±ci wysªanych na forum - {3}
(m) ilo±¢ wiadomo±ci (zapyta«) wysªanych do pracowników
PCM
z
MUP-CPO
- {4}
(n) zmiana ilo±ci wiadomo±ci (zapyta«) wysªanych do pracowników
CPO - {4}
2.
PCM z MUP-
MAP-CAR umo»liwia tworzenie nast¦puj¡cych raportów z funkcjonalno±ci komercyjnej Platformy, (w okre±lonym przedziale czasowym, z zadan¡ cz¦sto±ci¡ grupowania: dzienna, tygodniowa, miesi¦czna, roczna):
(a) wysoko±¢ obrotów - {5}
(b) zmiana wysoko±ci obrotów - {4}
(c) ilo±¢ zakupionych
MBiol.
- {5}
MBiol. - {4}
ilo±¢ zdeponowanych MBiol. - {5}
zmiana ilo±ci zdeponowanych MBiol. - {4}
(d) zmiana ilo±ci zakupionych
(e)
(f )
3.
MAP-CAR umo»liwia tworzenie raportów nt.
zgromadzonego
MBiol.:
(a) ilo±¢ zdeponowanych organizmów - {5}
(b) zmiana ilo±ci zdeponowanych organizmów - {4}
(c) listy
MBiol., których ilo±¢ dla okre±lonych TPP-MB jest bliska wyczerpania
- {5}
(d) listy
4.
MBiol., dla których upªywa termin wa»no±ci próbek - {5}
MAP-CAR umo»liwia tworzenie nowych rapartów poprzez wybieranie odpowiedniego typu danych w funkcji czasu, lub agregowanych w podanych przedziaªach
czasowych - {4}.
5.
MAP-CAR umo»liwia pobranie/wydruk ka»dego z raportów (format PDF ) - {4}.
Rozdziaª 7
Wymagania Moduªu Zarz¡dczego
Platformy (MZP)
1.
MZP oferuje jedynie polskoj¦zyczny interfejs u»ytkownika - {5}.
2.
MZP
udost¦pniony jest jedynie dla wybranej grupy osób pracowników kolekcji
mikroorganizmów wynajmuj¡cych
3.
Platform¦ - zarz¡dców
- {5}.
MZP dokonuje werykacji to»samo±ci u»ytkownika przed udzieleniem dost¦pu - {5}
[UC-LOG]
4.
MZP
ko«czy sesj¦ z po upªywie okre±lonego czasu braku aktywno±ci
zarz¡dcy -
{5} [UC-AUTO-OFF].
5.
MZP umo»liwia zako«czenie sesji - {5} [UC-LOGOUT].
6.
MZP
umo»liwia zmian¦ kolorów, tªa, elementów wygl¡du interfejsu u»ytkownika -
{2}.
7.
MZP umo»liwia modykacj¦ wygl¡du pulpitu poprzez zmian¦ rozstawienie elementów na ekranie - {1}.
8.
9.
MZP umo»liwia przypisanie grupy zarz¡dców
najemc¦ Platformy - {4}.
MZP
danej
10.
do zdeniowanej grupy deniuj¡cej
nie dopuszcza do modykowania jakichkolwiek danych nie nale»¡cych do
kolekcji , tj. stworzonych przez zarz¡dców danej kolekcji - {5}.
MZP umo»liwia tworzenie/modykacj¦/dezaktywacj¦/aktywacj¦ danych MBiol.
-
{5}.
11.
MZP umo»liwia tworzenie/modykacj¦/dezaktywacj¦/aktywacj¦ danych Po»ywek
-{5}.
12.
MZP oznacza wszystkie modykowane rekordy MBiol.
do danej
informacj¡ o przynale»no±ci
kolekcji , tej samej do której nale»y zarz¡dca wykonuj¡cy dan¡ operacj¦
- {5}.
37
ROZDZIA 7.
13.
WYMAGANIA MODUU ZARZDCZEGO PLATFORMY (MZP) 38
MZP wykonuje kopi¦ danych przed zapisem zmian.
Zmiany s¡ zapisywane na kopii
danych, i dlatego nie s¡ widoczne w innych moduªach systemu bez ich akceptacji {4}.
14.
MZP
umo»liwia automatyczn¡ akceptacj¦ modykacji, o ile taka usªuga zostaªo
skongurowana (w module MAP) dla danej
kolekcji -{3}.
Rozdziaª 8
Wymagania Moduªu U»ytkowego
Platformy (MUP)
8.1 Wymagania ogólne Moduªu U»ytkowego Platformy
1.
MUP oferuje interfejs u»ytkownika w nast¦puj¡cych wersjach j¦zykowych:
(a) Polskiej - {5}
(b) Angielskiej - {5}
(c) Niemieckiej - {4}
(d) Rosyjskiej - {3}
(e) Chi«skiej - {2}
2.
MUP
wybiera odpowiedni¡ wersj¦ j¦zykow¡ na podstawie ustawie« przegl¡darki -
{3}.
3.
MUP
wybiera j¦zyk podstawowy, gdy j¦zyk wymagany na podstawie ustawie«
przegl¡darki jest niedost¦pny- {4}.
4.
MUP umo»liwia u»ytkownikowi zmian¦ domy±lnego j¦zyka interfejsu - {5}.
5.
MUP umo»liwia wprowadzanie danych we wszystkich j¦zykach obsªugiwanych przez
interfejs u»ytkownika - {4}.
6.
MUP
umo»liwia automatyczne tªumaczenie prezentowanych informacji na ka»dy
j¦zyk obsªugiwany przez interfejs u»ytkownika - {5}.
8.2 Moduª U»ytkowy - Cz¦±¢ Portalowa Ogólnodost¦pna
(MUP - CPO)
1.
MUP-CPO dost¦pny jest dla nast¦puj¡cych typów u»ytkowników:
{5}.
39
anonimowy -
ROZDZIA 8.
2.
WYMAGANIA MODUU UYTKOWEGO PLATFORMY (MUP) 40
MUP-CPO
udost¦pnia funkcjonalno±ci bez sprawdzania to»samo±ci u»ytkownika
- {5}.
3.
4.
MUP-CPO umo»liwia przegl¡danie i szybkie wyszukiwanie MBiol.
MUP-CPO umo»liwia wyszukiwanie szczegóªowe MBiol.
- {5}.
na podstawie zadanych
kryteriów oraz warunków logicznych (i, lub, mniej ni», wi¦cej ni», równe,
itp.) - {5}.
5.
MUP-CPO umo»liwia dodawanie wybranego MBiol.
6.
MUP-CPO umo»liwia czytanie ogªosze« z ofertami pracy - {4}.
7.
MUP-CPO umo»liwia czytanie informacji nt.
8.
MUP-CPO umo»liwia czytanie wiadomo±ci z forum u»ytkowników - {4}.
9.
do koszyka zakupów - {5}.
konferencji naukowych - {4}.
zmian w nazewnictwie
MBiol.
(tak-
sonomii) - {4}.
10.
MUP-CPO
umo»liwia czytanie informacji nt. opis technik mikrobiologicznych -
{3}.
11.
nowo±ci sprz¦towych w laboratorium
- {3}.
12.
MUP-CPO
umo»liwia pobieranie plików w formatach PDF, MS Word i MS Ex-
cel uzupeªniaj¡cych informacje zawarte w cz¦±ciach informacyjnych np. na temat
technik mikrobiologicznych i innych - {4}.
13.
MUP-CPO umo»liwia zaªo»enie konta widza
14.
MUP-CPO
umo»liwia zaªo»enie konta
- {5}.
klienta , posiadaj¡cego minimalny
PBB
do momentu werykacji akceptacji przez administratora - {5}.
15.
MUP-CPO umo»liwia zaªo»enie konta zarz¡dcy , nieaktywnego do momentu werykacji i akceptacji przez uprawnionego administratora - {5}.
16.
MUP-CPO umo»liwia wysªanie krótkiej informacji/zapytania do pracowników kolekcji
PCM.Wiadomo±¢ musi zawiera¢ adres email nadawcy - {5}.
8.3 Moduª U»ytkowy Platformy - Cz¦±¢ Komercyjna
(MUP-CK)
1.
2.
MUP-CK udost¦pniony jest jedynie dla wybranej grupy osób iaj¡cych MBiol. poprzez Platform¦ - {5}.
klienta - zamaw-
MUP-CK dokonuje werykacji to»samo±ci u»ytkownika przed udzieleniem dost¦pu
- {5} [UC-LOG].
ROZDZIA 8.
3.
MUP-CK ko«czy sesj¦ z po upªywie okre±lonego czasu braku aktywno±ci klienta
4.
MUP-CK umo»liwia zako«czenie sesji - {5} [UC-LOGOUT].
5.
MUP-CK umo»liwia zmian¦ kolorów, tªa, elementów wygl¡du interfejsu u»ytkownika - {2}.
6.
MUP-CK
nadaje minimalny
PBB
ka»demu nowo zaªo»onemu kontu
klienta -
{2}.
7.
MUP-CK umo»liwia zakup MBiol.
8.
MUP-CK
których ilo±¢ sztuk jest zerowa - {3}.
wylicza czas realizacji zamówienia w zale»no±ci od ilo±ci sztuk danego
MBiol. i sposobu transportu - {3}.
9.
10.
MUP-CK wymaga wybrania jednego typu transportu MBiol. (TT-MB) - {3}.
MUP-CK
umo»liwia wysªania zeskanowanych kopii certykatów bezpiecze«stwa
biologicznego, w celu podniesienia poziomu
PBB po werykacji przez uprawnionego
administratora - {3}.
11.
MUP-CK umo»liwia zamawianie wybranego (wybranych) MBiol., o ile jego (ich)
PBB nie przekracza maksymalnego poziomu PBB dost¦pnego dla danego klienta
- {4}.
12.
13.
MUP-CK umo»liwia dokonywanie pªatno±ci za zamówiony MBiol.
- {5}.
MAP-CK pomniejsza ilo±¢ dost¦pnych sztuk danego typu postaci przechowywania
MBiol. (TPP-MB), dla danego typu MBiol. na skutek utworzenia przez klienta
nowego zamówienia - {5}.
14.
MAP-CK zwi¦ksza ilo±¢ dost¦pnych sztuk danego typu postaci przechowywania
MBiol. (TPP-MB), dla danego typu MBiol. na skutek rezygnacji przez klienta
z zamówienia - {5}.
15.
MUP-CK umo»liwia pobranie materiaªów dotycz¡cych procedur o»ywiania zakupionego materiaªu i instrukcji BHP zwi¡zanej z jego obsªug¡. Materiaªy b¦d¡ dost¦pne
w formacie PDF - {5}.
16.
MUP-CK
umo»liwia przygotowanie/wydruk kart identykacyjnych (w formacie
PDF ) dla wybranych typów
17.
MBiol.
- {4}.
MUP-CK umo»liwia przygotowanie/wydruk faktury pro-forma dla przygotowanego
zlecenia - {5}.
18.
MUP-CK zmienia status zlecenia dla zlece« z wydrukowan¡ faktur¡ pro-forma na
wstrzymane - {5}.
19.
MUP-CK
umo»liwia zmian¦ zlece« o statusie wstrzymane na nowe , tj.
doko«czenie procesu zamówieia wcze±niej wybranego zestawu
MBiol.
- {3}.
na
ROZDZIA 8.
20.
MUP-CK umo»liwia dokonanie pªatno±ci za pomoc¡ - {5}:
(a) karty kredytowej
(b) przelewu bankowego
(c) przelewu po odbiorze
21.
MUP-CK uniemo»liwia dost¦p do jakichkolwiek danych nieb¦d¡cych danymi specycznymi dla danego (autoryzowanego)
u»ytkowników
klienta , lub danymi dost¦pnymi ogólnie (dla
anonimowych ) - {5}.
22.
MUP-CK umo»liwia szybki dost¦p do ostatniego zlecenia - {5}.
23.
MUP-CK umo»liwia przegl¡danie/wyszukiwanie zlece« - {5}.
24.
MUP-CK umo»liwia sprawdzenie bilansu pªatniczego - {5}.
25.
MUP-CK umo»liwia sprawdzenie estymowanej daty realizacji zamówienia - {5}.
26.
MUP-CK
okre±la samodzielnie stan pªatno±ci, przybieraj¡cy jedn¡ z mo»liwych
warto±ci - {4}:
(a) niezapªacona
(b) zapªacona cz¦±ciowo
(c) zapªacono
27.
MUP-CK umo»liwia sprawdzenie aktualnego statusu zlecenia - {5}.
28.
MUP-CK
umo»liwia podgl¡d/wydruk/zapis faktur wystawionych dla ka»dego ze
zlece« - {5}.
29.
MUP-CK
umo»liwia rezygnacj¦ z zamówienia, o ile zamówienie nie przekroczyªo
stanu: wysªane - {5}.
30.
31.
MUP-CK umo»liwia dost¦p do opisu warunków reklamacji (D-WR) - {5}.
MUP-CK umo»liwia dost¦p do opisu warunków zakupu oraz restrykcji dotycz¡cych
MBiol. (D-WZIR) - {5}.
dost¦pu do niektórych typów
32.
MUP-CK
umo»liwia dost¦p do dokumentu o odpowiedzialno±ci karnej za po-
dawanie nieprawdziwych danych przy zamawianiu
33.
MUP-CK
MBiol. (D-OK) - {5}.
wymusza zapoznanie si¦ z dokumentami:
przed dokonaniem zakupu - {5}.
D-WR, D-WZIR, D-OK,
ROZDZIA 8.
8.4 Moduª U»ytkowy Platformy - Cz¦±¢ Depozytowa
(MUP-CD)
1.
MUP-CD
ponuj¡cych
2.
udost¦pniony jest jedynie dla wybranej grupy osób MBiol.
poprzez
Platform¦ - {5}.
klientów - de-
MUP-CD dokonuje werykacji to»samo±ci u»ytkownika przed udzieleniem dost¦pu
- {5} [UD-LOG].
3.
MUP-CD
ko«czy sesj¦ z po upªywie okre±lonego czasu braku aktywno±ci
klienta
4.
MUP-CD umo»liwia zako«czenie sesji - {5} [UC-LOGOUT].
5.
MUP-CD umo»liwia dodanie/modykowanie informacji nt.
deponowanego
MBiol.
- {4}.
6.
MUP-CD umo»liwia dodawanie/modykowanie zeskanowanych kopii wszelkich dokumentów niezb¦dnych w procesie patentowym - {3}.
7.
MUP-CD umo»liwia dost¦p do informacji nt.
dokonuj¡cej depozytu, oraz uprawnionym
8.
deponowanego
MBiol.
tylko osobie
administratorom - {5}.
MUP-CD uniemo»liwia dost¦p do informacji nt.
deponowanego
MBiol.
jakimkol-
wiek innym u»ytkownikom - {5}.
9.
MUP-CD umo»liwia dokonanie pªatno±ci za proces deponowania MBiol.
- {5}.
10. MUP-CD pobiera opªaty za - {5}:
(a) depozyt
(b) wydanie certykatu »ywotno±ci
(c) preparacj¦
11.
MBiol.
(np. liolizowanie)
MUP-CD umo»liwia dokonanie pªatno±ci za pomoc¡ - {5}:
(a) karty kredytowej
(b) przelewu bankowego
(c) przelewu po odbiorze
12.
MUP-CD umo»liwia sprawdzenie bilansu pªatniczego - {4}.
13.
MUP-CD
umo»liwia pobranie/wydrukowanie ±wiadectwa przyj¦cia do depozytu
wraz z nadanym numerem - {5}.
14.
MUP-CD
ponowania
umo»liwia podgl¡d/wydruk/zapis faktury wystawionej za proces de-
MBiol - {5}.
ROZDZIA 8.
8.5 Moduª U»ytkowy - Cz¦±¢ Portalowa (MUP-CP)
1.
MUP-CP
udost¦pniony jest jedynie dla wybranej grupy osób -
odwiedzaj¡cych
Platform¦,
widzów osób
którzy zdecyduj¡ si¦ na otworzenie konta pozwala-
j¡cego na identykacj¦ osoby - {2}.
2.
MUP-CP dokonuje werykacji to»samo±ci u»ytkownika przed udzieleniem dost¦pu
- {3} [UD-LOG].
3.
MUP-CP ko«czy sesj¦ z po upªywie okre±lonego czasu braku aktywno±ci widza
-
{5} [UC-AUTO-OFF].
4.
MUP-CP umo»liwia zako«czenie sesji (logout) - {5} [UC-LOGOUT].
5.
MUP-CP
umo»liwia dost¦p do telekonferencji transmitowanych na »ywo tzw.
Webinar - {5}.
6.
MUP-CP
umo»liwia
widzowi wysyªanie zapyta« w formie tekstowej, w czasie
trwania telekonferencji - {4}.
7.
MUP-CP umo»liwia dost¦p do archiwum telekonferencji - {5}.
8.
MUP-CP blog dla poszczególnych uzytkownikow - {4}.
9.
MUP-CP umo»liwia wysyªanie wiadomo±ci na forum u»ytkowników - {5}.
Rozdziaª 9
Wymagania systemu bazy danych
(SBD)
1.
SBD
- pracuje w konguracji klastrowej, tj. wykorzystuj¡c wiele zycznych serw-
erów poª¡czonych ze sob¡ za pomoc¡ sieci intranet - {5}.
2.
SBD pracuje w tzw.
trybie multi master, w którym ka»dy z serwerów bazy danych
ma równe uprawnienia i funkcje, tj. zapytania wybieraj¡ce jak i modykuj¡ce dane
mog¡ by¢ wysªane do dowolnego serwera
3.
4.
SBD - {5}.
SBD wykorzystuje system plików rozproszony pomi¦dzy ró»ne serwery plików - {4}.
SBD zachowuje poprawne dziaªanie systemu pomimo awarii pewnej ilo±ci serwerów.
Maksymalna ilo±¢ niedziaªaj¡cych serwerów, przy której SBD zachowuje swoje normalne funkcje jest deniowana podczas jego konguracji - {4}.
5.
SBD pozwala na wykonywanie kopii zapasowej danych w czasie dziaªania systemu
- {3}.
6.
SBD
pozwala na odtworzenie stanu bazy danych z wcze±niej stworzonych kopii
zapasowych - {5}.
7.
SBD pozwala na dodawanie/usuwanie serwerów w czasie dziaªania systemu - {3}.
45
Rozdziaª 10
Lista przypadków u»ycia (UC)
W rozdziale tym wykorzystywano jedn¡ z przyj¦tych powszechnie opisów przypadków
u»ycia, wyszczególniaj¡c:
•
nazw¦ przypadku (wraz ze zdeniowanym skrótem)
•
cel danego
•
jego wst¦pne zaªo»enia
•
list¦ aktorów bior¡cych udziaª
•
list¦ kroków wykonywanych w danym
•
opis wyj¡tków, które mog¡ zmieni¢ przebieg
•
list¦ zagro»e«, które wyst¡pienie mo»e by¢ zwi¡zane z wykonaniem danego
UC
UC
UC
UC
W opisie kroków oprócz standardowej konwencji pi±mienniczej dodtakowo do opisu kroków
posªu»ono si¦ symbolami grupowania kroków wyst¦puj¡cych w UC, oraz sªowami kluczowymi umieszczonymi w nawiasach klamrowych.
Do opisu przypadków uzycia wyko-
rzystano nast¦puj¡ce symbole grupowania:
•
<
>
- oznacza denicj¦ grupy, np. <1> - grupa jednoelementowa zawieraj¡ca ref-
erencj¦ do kroku numer 1; <1..3> - grupa zawieraj¡ca referencje do kroków: 1,2 i
3.
•
.. - symbol dwukropka (..) - u»ywany do okre±lenia grupy elementów przez podanie
zakresu; element stoj¡cy przed dwukropkiem i za nim tak»e nale»¡ do grupy, np.
<1..3> oznacza grup¦ z elementami (referencjami do kroków): 1, 2 i 3.
•
& - oznacza logiczne i - sªu»y do ª¡cz¦nia grup, np: <1>&<3..5>.
•
| - oznacza logiczne albo - sªu»y do ª¡cz¦nia grup, np: <1>|<3..5>.
•
! - oznacza logiczn¡ negacj¦ - sªu»y do negacji grupy, np: !<3..5>.
•
, - symbol przecinka (,) - u»ywany do wymieniania elementów grupy, np. <1,3,5>
oznacza grup¦ zawieraj¡c¡ referencje do kroków 1, 3 i 5.
46
ROZDZIA 10.
•
UC-ID:<x
LISTA PRZYPADKÓW UYCIA (UC)
>
47
- oznacza odwoªanie (referencj¦) do kroku x w
UC
o identykatorze:
UC-ID.
•
$ - symbol dolar ($ ), oznacza ostatni krok
UC.
Sªowa kluczowe informuj¡ o sposobie w jaki nale»y odczyta¢ sekwencj¦ kroków, np. wykonanie równolegªe, itp.
Pozostawiono je w j¦zyku angielskim ze wzgl¦du na ich wys-
tepowanie w takiej formie w wielu ró»nych wzorcach opisu
UC.
Opisywane przypadki
u»ycia wykorzystuj¡ nast¦puj¡ce sªowa kluczowe:
•
{ALT}
- oznacza, »e grupa podkroków przynale»¡cych do danego punktu b¦dzie
wykonywana alternatywnie, tj. zostanie wykoanny jeden z podpunktów speªniaj¡cy
okre±lony warunek. Wymagane jest aby podpunkty posiadaªy zdeniowane warunki
wykonania, i aby warunek wykonania kazdego z nich byª rozª¡czny z warunkami
innych podpunktów.
•
{CONT} - oznacza, »e dany krok ko«czy sekwencj¦ kroków i sterowanie jest przekazane
do nadrz¦dnego kroku gªównego; wykorzystywany gªównie do zako«czenia danej iteracji
{LOOP...} i rozpocz¦cia nast¦pnego przebiegu.
•
{HALT} - oznacza, »e dany krok jest krokiem ko«cowym na którym wykonanie
UC si¦ ko«czy. Jest on u»ywany w sytuacji wielu alternatywnych wersji przebiegu
UC, w sytuacji gdy jeden z nich nalnie ko«czy si¦ przerwaniem wykonania danego
UC.
•
{IF [warunek] } - oznacza, »e dany podkrok zostanie wykonany tylko w przypadku
speªnienia opisanego [warunku].
dodatkowo, dwa lub wi¦cej warunki mog¡ by¢ porównywane ze sob¡ za pomoc¡
nast¦puj¡cych wyra»e« logicznych:
∗
∗
∗
∗
∗
∗
== - czy obie strony wyra»enia s¡ sobie równe
> - czy lewa strona wyra»enia jest wi¦ksza
< - czy lewa strona wyra»enia jest mniejsza
>= - - czy lewa strona wyra»enia jest wi¦ksza lub równa
<=- czy lewa strona wyra»enia jest mniejsza lub równa
!= czy strony wyra»enia s¡ od siebie ró»ne
zwykle dla takich wyra»e« format sªowa kluczowego
j¡co:
{IF
[wyra»enie1]
!=
}
{IF...} wygl¡da nast¦pu-
[wyra»enie2] , gdzie symbol: ' !=' mo»e by¢ za-
mieniony na jeden z powy»szych.
•
{LOOP UNTIL
[wyda»enie]
1
}
- oznacza, »e grupa podpunktów przynale»¡cych
do danego punktu b¦dzie powtarzana a» do speªnienia opisanego [wyda»enia].
•
{LOOP
[x]
TIMES}
- oznacza, »e grupa podkroków przynale»¡cych do danego
punktu b¦dzie powtórzona [x] razy. [x] musi by¢ liczb¡ naturaln¡ wi¦ksz¡ od zera.
1 nawiasy kwadratowe wskazuj¡, »e sªowo(sªowa) w ich wn¦trzu opisuje zmienn¡ lub wyra»enie.
ROZDZIA 10.
•
48
{PAR} - oznacza, »e grupa podpunktów przynale»¡cych do danego punktu zostanie
wykonana równolegle, niezale»nie od siebie.
•
{PERFORM [UC-ID] } - oznacza, »e w danym kroku zostanie wykonany inny UC
o identykatorze UC-ID.
•
{PERFORM
}
•
{WAITFOR <R>} - oznacza, »e dana grupa podkroków zostanie wykonana, gdy
inna grupa kroków danego UC (dziaªaj¡cych równolegle) zako«czy swe dziaªanie.
•
{WAITFOR
[UC-ID:<R>]
- oznacza, »e w danym kroku zostan¡ wykonane
2
kroki zawarte w grupie <R> , deniowane przez
o identykatorze UC-ID.
[UC-ID:<R>]
nana, gdy inna grupa kroków
UC
} - oznacza, »e dana grupa podkroków zostanie wykoUC o identykatorze UC-ID (dziaªaj¡cych równolegle)
zako«czy swe dziaªanie.
•
{WAITFOR [wyda»enie]} - oznacza, »e dana grupa podkroków zostanie wykonane,
gdy nast¡pi opisane wyda»enie.
10.1 UC-LOG
Nazwa : UC-LOG - Logowanie do systemu
Umo»liwia sprawdzenie to»samo±ci u»ytkownika, oraz - w przy-
Cel :
padku pozytywnej werykacji danych u»ytkownika - inicjuje
sesj¦ komunikacji.
• u»ytkownik
-
zast¦puje
jakiegokolwiek
u»ytkown-
ika rzeczywistego posªuguj¡cego si¦ identykatorem i
hasªem.
Aktorzy :
• system
• przegl¡drka
- okre±la wirtualnego aktora, reprezentu-
j¡cego akcje inicjowane samoistnie przez przegl¡dark¦.
Zaªo»enia :
•
U»ytkownik nie pracuje z systemem.
•
System posiada licznik nieudanych prób autoryzacji dla
ka»dego u»ytkownika.
2 R - oznacza denicj¦ jak¡kolwiek grupy kroków, np. <1,2> lub <4>&<6..$> - mo»liw¡ do opisania
za pomoc¡ symboli grupowania.
ROZDZIA 10.
1.
2.
49
U»ytkownik otwiera przegl¡dark¦ internetow¡.
U»ytkownik wpisuje adres URL serwisu WWW
formy.
Plat-
3.
U»ytkownik wpysuje swój identykator.
4.
U»ytkownik wpisuje swoje hasªo.
5.
Przegl¡darka wysyªa identykator i hasªo do systemu .
6.
System sprawdza poprawno±¢ wpisanych danych przez
porównanie ich z wpisami dost¦pnymi w bazie danych
7.
{ALT}
(a)
{IF [dane pasuj¡ do wzorca w systemie bazy danych
- SBD ] }
i.
Kroki :
ii.
system otwiera
u»ytkownikiem .
system
wysyªa
sesji
dane
wymiany
strony
danych
gªównej
z
sys-
temu, dost¦pnej po zalogowaniu danego typu
u»ytkownika.
iii.
(b)
{IF
i.
przegl¡darka wy±wietla otrzyman¡ stron¦.
[dane nie pasuj¡ do wzorca w SBD ]
}
System zwi¦ksza licznik nieudanych prób autentykacji.
ii.
{IF
[ilo±¢ nieudanych prób autentykacji]
>
[maksymalna ilo±¢ dopuszczonych nieudanych
prób autentykacji]
A. system
próba
}
blokuje
konto
autentykacji
-
ka»da
nast¦pna
zako«czy
si¦
niepowodzeniem bez wzgl¦du na podawane
hasªo
iii.
System zamyka sesj¦
iv.
System
wysyªa
do
przegl¡darki
informacj¦
bª¦dzie.
v.
Przegl¡darka wy±wietla informacj¦ o bªedzie.
ROZDZIA 10.
•
50
w kroku <3>:
1.
{IF [ u»ytkownik
(a)
nie podaª identykatora]
przegl¡darka
wysyªa
identykator
}
pusty,
skªadaj¡cy si¦ z pustego ªa«cucha znaków.
Wyj¡tki :
•
w kroku <4>:
1.
{IF [ u»ytkownik
nie podaª hasªa]
}
(a) przegl¡darka wysyªa hasªo puste, skªadaj¡ce si¦
z pustego ªa«cucha znaków.
•
Obostrzenia :
sprawdzenie danych wprowadzonych przez u»ytkownika z
danymi przechowywanymi w bazie danych powinno by¢
wykonane w czasie poni»ej 1s.
Zagro»enia :
•
ochrona przed próbami wªama«
•
automatyczna blokada konta po okre±lonej ilo±ci nieudanych prób autentykacji.
10.2 UD-LOG-CERT
UC-LOG-CERT - Logowanie do systemu ze sprawdzeNazwa : niem wa»no±ci certykatu elektronicznego u»ytkownika.
Umo»liwia sprawdzenie to»samo±ci u»ytkownika, oraz - w przy-
Cel :
padku pozytywnej werykacji danych u»ytkownika - inicjuje
sesj¦ komunikacji.
• u»ytkownik
-
zast¦puje
jednego
z
nast¦puj¡cych
u»ytkowników:
Aktorzy :
super-u»ytkownik
administrator
• system
• przegl¡drka
ROZDZIA 10.
Zaªo»enia :
51
•
U»ytkownik nie pracuje z systemem.
•
System posiada licznik nieudanych prób autoryzacji dla
ka»dego u»ytkownika.
•
System posiada skongurowany system PKI.
1.
{PERFORM [UC-LOG:
2.
System
wysyªa
<1-5>]
»¡danie
o
}
pobranie
certykatu
u»ytkownika
3.
Przegl¡darka
informuje
u»ytkownika
o
potrzebie
wybrania wªa±ciwego certykatu.
4.
{ALT}
(a)
{IF [u»ytkownik
i.
ii.
Kroki :
(b)
{IF
i.
ii.
iii.
}
anuluje operacj¦]
Przegl¡darka wy±wietla informacj¦ o bª¦dzie.
{HALT}
}
[u»ytkownik wybierze certykat]
Przegl¡darka wysyªa certykat u»ytkownika
{PERFORM [UC-WER-CERT] }
{ALT}
A. {IF [certykat niepoprawny]}
•
System zwraca informacj¦ o bª¦dzie.
•
Przegl¡darka
wy±wietla
informacj¦
o
bª¦dzie.
{HALT}
{IF [certykat poprawny]}
• {PERFORM [UC-LOG:<6-$>] }
•
B.
Wyj¡tki :
Brak
•
Obostrzenia :
sprawdzenie danych (identykatora, hasªa i certykatu)
powinno by¢ wykonane w czasie poni»ej 1s, pomij¡j¡c
czas potrzebny na przesªanie certykatu.
ROZDZIA 10.
Zagro»enia :
•
•
10.3 UD-WER-CERT
Nazwa :
Cel :
Aktorzy :
Zaªo»enia :
UC-WER-CERT - Werykacja certykatu u»ytkownika.
Umo»liwia sprawdzenie poprawno±ci certykatu.
• system
•
System otrzymaª plik certykatu do sprawdzenia.
•
System posiada skongurowany system PKI.
52
ROZDZIA 10.
1.
2.
{IF
[rozmiar sprawdzanego pliku certykatu]
(a)
system zwraca informacj¦ o bª¦dzie.
(b)
{HALT}
{IF
4.
(b)
{HALT}
[certykat jest w nieobsªugiwanym formacie]
(a)
(b)
{HALT}
{IF
5.
6.
7.
8.
Wyj¡tki :
Brak
}
[certykat jest podpisane przez inne centrum auto-
ryzacji (
Kroki :
}
(a)
{IF
== 0}
[sprawdzany plik nie jest plikiem certykatu (obcy
fomat pliku)]
3.
53
CA)] }
(a)
(b)
{HALT}
{IF [certykat jest niewa»ny/przeterminowany]}
(a)
(b)
{HALT}
{IF
[certykat zostaª anulowany]
}
(a)
(b)
{HALT}
{IF [warto±¢ skrótu certykatu (ang.
wyliczona skrótu certykatu] }
hash)]
(a)
(b)
{HALT}
!= [warto±¢
system zwraca informacj¦ o poprawno±ci certykatu.
ROZDZIA 10.
•
Obostrzenia :
sprawdzenie danych (identykatora, hasªa i certykatu)
powinno by¢ wykonane w czasie poni»ej 1s, pomij¡j¡c
czas potrzebny na przesªanie certykatu.
Zagro»enia :
•
•
10.3.1 UC-AUTO-OFF
Nazwa :
Cel :
UC-AUTO-OFF - Automatyczne wylogowanie u»ytkownika
z systemu
Umo»liwia zako«czenie bie»¡cej komunikacji z
u»ytkownikiem po upªywie okre±lonego czasu
nieaktywno±ci u»ytkownika.
• u»ytkownik - zast¦puje jakiegokolwiek
u»ytkownika rzeczywistego posªuguj¡cego si¦
identyfikatorem i hasªem.
Aktorzy :
• system
• przegl¡drka - okre±la wirtualnego aktora,
reprezentuj¡cego akcje inicjowane samoistnie
przez przegl¡dark¦.
• U»ytkownik pracuje z systemem.
Zaªo»enia :
• System posiada zdefiniowany maksymalny czas
bezczynno±ci u»ytkownika.
54
ROZDZIA 10.
55
1. {LOOP UNTIL [sesja zostaªa zamkni¦ta] }
(a) {WAITFOR [polecenie u»ytkownika] | [upªyn¡
czas] == [maksymalnemu czasowi bezczynno±ci
u»ytkownika] }
2. {ALT}
Kroki :
(a) {IF [odebrano polecenie u»ytkownika] }
i. {CONT}
(b) {IF [czas oczekiwania] > [maksymalnemu
czasowi bezczynno±ci u»ytkownika] }
i. system wysyªa do przegl¡darki
infromacj¦ o zamkni¦ciu sesji z bowodu
zbyt dªugiego okresu bezczynno±ci
u»ytkownika.
ii. {PAR}
A. system zamyka sesj¦.
B. przegl¡darka przchodzi na stron¦
startow¡ stron¦ i wy±wietla otrzyman¡
informacj¦.
Wyj¡tki :
Brak
Obostrzenia :
Brak
Zagro»enia :
Brak
10.3.2 UC-LOGOUT
Nazwa : UC-LOGOUT - Wylogowanie u»ytkownika z systemu
Cel :
Umo»liwia zako«czenie bie»¡cej komunikacji z u»ytkownikiem
na »yczenie u»ytkownika.
• u»ytkownik
-
zast¦puje
jakiegokolwiek
u»ytkown-
ika rzeczywistego posªuguj¡cego si¦ identykatorem i
hasªem.
Aktorzy :
• system
• przegl¡drka
ROZDZIA 10.
Zaªo»enia :
•
56
U»ytkownik pracuje z systemem.
1.
U»ytkownik
2.
System
(a)
Kroki :
wysyªa »¡danie zako«czenia sesji.
odbiera »¡danie.
system
wysyªa
do
przegl¡darki
infromacj¦
o
zamkni¦ciu sesji.
(b)
{PAR}
i.
ii.
system zamyka sesj¦.
przegl¡darka przchodzi na stron¦ startow¡
stron¦.
Wyj¡tki :
Brak
Obostrzenia :
Brak
Zagro»enia :
Brak
Rozdziaª 11
Opis interfejsu u»ytkownika
Interfejs u»ytkownika, wykorzystywany przez
Platform¦
bazuje na standardzie HTML
w wersji XHTML 1.0, który jest obsªugiwany przez wi¦kszo±¢ wspóªczesnych przegl¡darek. Dodatkowo, warstwa prezentacyjna wykorzystuje tzw. dynamiczne mechanizmy
standardu HTML (DHTML), wraz z najnowszymi technologiami WEB 2.0.
11.1 Architektura Informacji Serwisu
Opis dost¦pnych elementów serwisu wraz z ich lokalizacj¡ w systemie.
Wszystkie ele-
menty poziomu gªównego s¡ dost¦pne ze strony gªównej, pomini¦tej w strukturze. Ka»dy
z punktów numerowanych (1,2,...
lub a,b,c...
lub i, ii, iii, iv,...)
oznacza jedn¡ z pod-
stron dost¦pn¡ przez u»ytkowników. Punktu wylistowane (ang. bulets) oznaczaj¡ gªówne
funkcjonalno±ci dost¦pne na danej podstronie.
11.1.1 Ukªad stron serwisu
1. Wyszukiwarka
MBiol.
(a) Lista wyszukanych
MBiol.
i. Poka» detale
ii. Dodaj do koszyka
iii. Poka» koszyk zakupów
iv. Zamów wybrany
2.
MBiol.
PCM
(a) O nas
(b) Historia kolekcji
(c) Status mi¦dzynarodowy
(d) Pracownicy
(e) Kariera
(f ) Opis zaplecza technicznego
57
ROZDZIA 11.
OPIS INTERFEJSU UYTKOWNIKA
58
(g) Organizacje wspóªpracuj¡ce
(h) Galeria
(i) Kontakt
•
wy±lij wiadomo±¢
•
dane teleadresowe
•
mapa dojazdu
3. Usªugi
(a) Zakup
MBiol.
(wymaga logowania jako
klient )
i. Lista zlece«
A. Szczegóªy zlecenia
B. Anulowanie zlecenie
C. Zapªata za zlecenie
D. Wydruk faktury
E. Tworzenie nowego zlecenia przez skopiowanie innego zlecenia
F. Uruchomienia zlecenia zawieszonego (pro-forma)
ii. Bilans pªatniczy
iii. Regulamin
iv. Instrukcje i Procedury
v. Wydruki
MBiol.
MBiol.
A. Karty identykacyjne wybranego
B. Katalogu wybranych typów
(b) Depozyt
MBiol.
(wymaga logowania jako
klient )
i. Budapest Treaty
ii. Regulamin
iii. Instrukcje i Procedury
iv. Deponuj
•
wybór wªa±ciwego dla danego
•
zapªata za usªug¦
MBiol.
formularza
v. Twoje depozyty
•
lista deponowanych organizmów
•
mo»liwo±¢ wydruku certykatu »ywotno±ci
•
mo»liwo±¢ wydruku potwierdzenia depozytu
(c) Indentykacja
i. Proteomika
ii. Genomika
iii. Immunologia
iv. Biochemia
ROZDZIA 11.
(d) Namna»anie biomasy
(e) Oznaczanie wybranych cech biochemicznych
(f ) Liolizacja szczepów
(g) Szkolenia
(h) Badania na zlecenie
4. Edukacja i Info
(a) Ucze«
i. Ciekawostki
ii. Konkursy
iii. Warsztaty
iv. Festiwal nauki
v. Wirtualna wycieczka po kolekcji (lm, animacja, animacja 3D)
vi. Forum dyskusyjne
vii. Taksonomia
(b) Student
i. Prace magisterskie
ii. Prace badawcze
iii. Praktyki studenckie
iv. Prace licencjackie
v. Forum dyskusyjne
vi. Taksonomia
(c) Nauczyciel
i. Przykªady eksperymentów
ii. Organizacja zaj¦¢ grupowych
iii. Festiwal nauki
iv. Biblioteka
v. Forum dyskusyjne
vi. Taksonomia
(d) Naukowiec
i. Towarzystwo Mikrobiologiczne
ii. Konferencje naukowe
iii. Stypendia zagraniczne
iv. Prace naukowe
v. Forum dyskusyjne
vi. Taksonomia
5. Webinar
59
ROZDZIA 11.
60
(a) Przegl¡daj archiwum
(b) Na »ywo
•
wysyªanie zapyta« (komunikacja z prowadz¡cym)
wspóªdzielenie desktopu (?)
ocena
(c) Lista planowanych
(d) Nasze ulubione webinary
6. Informacje sponsorowane
(a) reklama sprz¦tu
(b) ogªoszenia o konkursach i grantach
(c) reklama konfenerncji
11.1.2 Schematy ukªadu stron
Przedstawione poni»ej schematy powinny stanowi¢ pomoc w pracach nad wygl¡dem interfejsu u»ytkownika. Schematy opisuj¡ trzy istotne rozkªady elementów gracznych:
•
1
stron¦ gªówn¡ serwisu
- która jest gªównym punktem wej±ciowym do Platformy,
bez wzgl¦du na typ u»ytkownika.
•
podstron¦ serwisu - przedstawia jedn¡ z podston serwisu, widzianego przez u»ytkowników zewn¦trznych:
•
kupiec , widz lub u»ytkownik anonimowy .
podstron¦ systemu - przedstawia jedn¡ z podstron systemu, po zalogowniu si¦ jednego z nast¦puj¡cych u»ytkowników:
super u»ytkownik
administrator
zarz¡dca
1 sªowa: serwis i system u»yto do rozró»nienia cz¦±ci ogólno-dost¦pnej od cz¦±ci chronionej - dost¦pnej dla znacznie mniejszej liczby u»ytkowników i mocniej chronionej.
ROZDZIA 11.
11.1.2.1
Strona gªówna serwisu
Rysunek 11.1: Schemat strony gªownej serwisu
11.1.2.2
Podstrona serwisu
Rysunek 11.2: Schemat podstrony serwisu
61
ROZDZIA 11.
11.1.2.3
Podstrona Platformy
Rysunek 11.3: Schemat podstrony systemu
62
Rozdziaª 12
Opis protokoªów komunikacyjnych
Ze wzgl¦du na rozproszon¡ konstrukcj¦
Platformy, jej komunikacja wewn¦trzna musi
Platforma wykorzystuje ró»ne pro-
opiera¢ si¦ o protokoªy sieciowe. Zale»nie od celu,
tokoªy warstwy aplikacyjnej, jakkolwiek wszystkie z nich bazuj¡ na protokole TCP/IP.
12.1 Komunikacja z u»ytkownikami
1. Komunikacja pomi¦dzy u»ytkownikami a Platform¡ odbywa si¦ z wykorzystaniem
protokoªu HTTP 1.0, rozszerzaj¡c go dodatkowo o mo»liwo±ci asynchroniczne typu
AJAX.
2. W celu zapewnienia prawidªowej obsªugi protokoªu HTTP,
Platforma oferuje funkcjon-
alno±¢ serwera WWW, albo jako funkcjonalno±¢ wbudowan¡ albo wykorzystuj¡c
jeden z zewn¦trznych serwerów WWW.
3. W celu zapewnienia prawidªowej obsªugi protokoªu HTTP, po stronie u»ytkownika,
Platforma
wymaga korzystania z tzw. przegl¡darki WWW. Lista przegl¡darek, z
którymi dziaªanie
Platformy
zostaªo sprawdzone znajduje si¦ w rozdziale 2.5 na
stronie 11.
4. Wszystkie moduªy Platformy, do których dost¦p jest autoryzowany, transmituj¡
dane wykorzystuj¡c szyfrowanie protokoªu HTTP za pomoc¡ wbudowanych w przegl¡dark¦ i serwer WWW mechanizmów kryptogracznych (SSL, TLS ).
5. Moduªy:
MKP i MAP wymagaj¡ dodatkowo certykatu elektronicznego po stronie
u»ytkownika.
12.2 Komunikacja wewn¡trz i pomi¦dzy moduªami Platformy
Do komunikacji pomi¦dzy poszczególnymi moduªami i cz¦±ciami skªadowymi
wykorzystywana jest baza danych oraz system tzw.
Platformy,
rozproszonych obiektów danych,
wyst¦puj¡cych w wielu dzisiejszych systemach tworzenia aplikacji (z ang. framework).
63
ROZDZIA 12.
OPIS PROTOKOÓW KOMUNIKACYJNYCH
64
12.3 Komunikacja z baz¡ danych
Do komunikacji pomi¦dzy cz¦±ci¡ aplikacyjn¡ Platformy a cz¦±ci¡ bazodanow¡ wykorzystywany jest standardowy protokóª oparty o j¦zyk zapyta« SQL, wraz z rozszerzeniami
specycznymi dla danego typu bazy danych.
za pomoc¡ tzw.
rozszerze« (ang.
plug-in), tj.
Rozszerzenia j¦zyka SQL s¡ realizowane
pozwalaj¡ na zmian¦ bazy danych bez
konieczno±ci przebudowy caªego systemu. Platforma jest dostarczona z dwoma zestawami
plugin'ów: dla bazy MySQL i Postgress. Inne rozszerzenia mog¡ zosta¢ dodane na »yczenie wªa±ciciela systemu.
12.4 Interfejs komunikacyjny z innymi systemami
Ze wzgl¦du na sposób przechowywania danych,
Platforma mo»e komunikowa¢ si¦ z sys-
temami stosuj¡cymi opis danych zgodnego ze specykacj¡ MCL. Dodatkowo Platforma
zostaªa zaprojektowana do wymiany danych z systemami informatycznymi których dane
s¡ zgodne ze specykacj¡ CABRI.
Rozdziaª 13
Wymagania niefunkcjonalne
13.1 Wymagania wydajno±ciowe
1.
Platforma obsªuguje jednocze±nie 100 transakcji1
2.
Platforma obsªuguje 20 000 transakcji dziennie.
3.
Platforma
jest skalowalna, tj.
dodanie kolejnych serwerów applikacyjnych b¡d¹
bazodanowych powinno zwi¦kszy¢ wydajno±¢ systemu proporcjonalnie do stosunku
liczby dodanych serwerów do ilo±ci serwerów ju» pracuj¡cych w systemie.
4.
Platforma zwi¦ksza swoj¡ wydajno±¢ co najmniej w takim stopniu, w jakim pozwala
wykorzystywana baza danych i/lub system plików.
5.
Platforma
wykorzystuje rozproszony system plików, w którym dost¦p do danych
jest optymalizowany ze wzgl¦du na dynamicznie zmieniaj¡ce si¦ potrzeby poszczególnych serwerów, tj. dane s¡ keszowane (ang. cache) oraz lokowane (ang. lock) przez
poszczególne serwery.
6.
Platforma
wykorzystuje system plików pozwalaj¡cy na rozszerzenie/modykacje
systemu plików bez potrzeby zatrzymywania systemu.
7.
Platforma wymaga zwi¦kszania przepustowo±ci ª¡cza wraz z ilo±ci¡ obsªugiwanych
telekonferencji.
8.
Platforma
wymaga zmniejszenia parametrów jako±ciowych obrazu telekonferencji
w przypadku niemo»no±ci zmiany parametrów ª¡cza, gdy wymagane jest zwi¦kszenie
ilo±ci osób korzystaj¡cych z telekonfernecji w tym samym czasie.
13.2 Wymagania dotycz¡ce zabezpieczenia dziaªania systemu
1.
Platforma
znajduje si¦ w osobnym, klimatyzowanym pomieszczeniu, które jest
zaprojektowane dla du»ych systemów komputerowych.
1 transakcja okre±la jest przez ilo±¢ stron WWW oraz elementów w niej zawartych, np. zj¦cia, lmy,
które s¡ pobierane przez u»ytkownika.
65
ROZDZIA 13.
2.
WYMAGANIA NIEFUNKCJONALNE
66
Platforma posiada zabezpieczenie pr¡dowe (UPS ) pozwalaj¡ce na poprawne zamkni¦cie systemu nawet w przypadku zaniku napi¦cia elektrycznego. Zabezpieczenie pr¡dowe dodatkowo stabilizuje napi¦cie i eleminuje wszelkiego rodzaju skoki napi¦cia i
inne anomalie.
3.
Platforma
wykorzystuje sprz¦t komputerowy w sposób redundantny, tj. posiada
wiele jednostek wykonuj¡cych t¡ sam¡ funkcj¦ np. serwery bazy danych, które w
razie awarii mog¡ przej¡¢ funkcj¦ wadliwego komponentu.
4.
Platforma
posiada redundantne poª¡czenia sieciowe oraz tzw. aktywne elementy
np. przeª¡czniki sieciowe (ang. switch), dzi¦ki temu w przypadku awarii jednej z tras
poª¡cze« komunikacja mo»e przebiega¢ tras¡ alternatywn¡. W czasie gdy obie trasy
funkcjonuj¡,
Platforma
wykorzystuje je obie, w celu zwi¦kszenia przepustowo±ci
poª¡czenia.
13.3 Wymagania dotycz¡ce bezpiecze«stwa
1.
Platforma deniuje szereg u»ytkowników, sªu»¡cych m.in.
do przydzielania jedynie
minimalnej listy uprawnie« niezb¦dnych do wykonania wymaganych operacji.
2.
3.
Platforma separuje dost¦p do danych, uniemo»liwiaj¡c dost¦p do nich »adnemu z
u»ytkowników a jedynie warstwie aplikacyjnej systemu (u»ytkowi platforma).
Platforma
oferuje tzw. infrastruktur¦
PKI,
w szczególno±ci mo»liwo±¢ wystawia-
nia i werykowania certykatów bezpiecze«stwa
4.
Platforma
oferuje certykaty bezpiecze«stwa dla wbudowanego serwera WWW,
sªu»¡cego do komunikacji z u»ytkownikami.
5.
Platforma, do uzyskania dost¦pu dla u»ytkowników administrator i super u»ytkownik ,
wymaga indywidualnego elektronicznego certykatu.
6.
Platforma jest chroniona za pomoc¡ systemu rewall.
7.
Platforma chroni dost¦p do serwerów bazy danych dodatkowym rewallem.
8.
Platforma znajduje si¦ w osobnym pomieszczeniu, do którego dost¦p jest ograniczony tylko dla osób uprawnionych.
13.4 Wymagania jako±ciowe systemu
1.
Platforma jest rozbudowywalna.
(a) Wymagania i funkcjonalno±ci Platformy opisane w niniejszym dokumencie jedynie obrazuj¡ zbiór funkcjonalno±ci obecnie niezb¦dny do jej uruchomienia
i zapewnienia funkcjonalno±ci wymaganej przez wªa±ciela jak i potencjalnych
u»ytkowników. Nie powinno to jednak przesªanie¢ wysoce prawdopodobnych
modykacji i rozszerzania funkcjonalno±ci
Platformy, które dzisiaj pomini¦to
jako mniej istotne, lub które nie byªy znane w chwili pisania specykacji.
ROZDZIA 13.
(b)
67
Platforma jest przygotowana na maksymalnie proste i niedestrukcyjne rozbudowywanie swoich mo»liwo±ci, nawet o funkcjonalno±ci nie przewidziane w
niniejszym dokumencie.
2.
Platforma jest niezawodna.
(a) W swojej konstrukcji i konguracji jest przygotowana na wiele zdarze« losowych,
w przypadku których
Platforma
zachowa swoje podstawowe funkcjonalno±ci
dost¦pne dla u»ytkowników w taki sam sposób jakby wydarzenia nie zaszªy.
(b) Ilo±¢ zdarze«, na których dziaªanie Platforma jest odporna, jest rozszerzalne
i powinno by¢ deniowana jedynie przez ilo±¢ ±rodków które wªa±ciciel chce
po±wi¦ci¢ na jej zabezpieczenie.
3.
Platforma zapewnia poprawno±¢ danych.
(a) Zapisuje jedynie dane, które zostaªy zwerykowane.
(b) Zapisuje jedynie peªne transakcje bazodanowe, sprawdzaj¡c zale»no±ci pomi¦dzy
poszczególnymi podkrokami danej transakcji.
(c) W przypadku wyst¡pienia tzw.
nieoczekiwanych kolizji danych, Platforma
preferuje cofni¦cie caªej transakcji i wygenerowanie bª¦du ni» zapis za wszelk¡
cen¦.
4.
Platforma jest optymalizowalna.
(a) Dostarcza jedynie niezb¦dne informacje.
(b) Nie przeci¡»a u»ytkownika nadmiarem danych i mo»liwo±ci, w tym mo»liwych
operacji.
(c) Pozwala na zmian¦ kolorów, wygl¡du w zale»no±ci od upodoba« u»ytkownika.
(d) Pozwala na modykacj¦ wygl¡du, inne rozstawienie elementów na ekranie, tak
by dostosowa¢ si¦ do potrzeb u»ytkownika.
5.
Platforma jest szerokodost¦pna.
(a) Nie wymaga specjalistycznego sprz¦tu po stronie u»ytkownika.
(b) Nie wymaga instalacji jakichkolwiek dodatków, poza powszechnie przyj¦te przez
projektantów serwisów WWW.
(c) Nie wymaga wy±rubowanej jako±ci poª¡czenia internetowego, nawet ±rednia
pr¦dko±¢ okoªo 128-256 Mb/s pozwala na bezproblemow¡ prac¦.
6.
Platforma jest ªatwo zarz¡dzalna.
(a) Zarz¡dzenie systemem nie wymaga specjalistycznej wiedzy, poza pierwszym
uruchomieniem i wst¦pn¡ konguracj¡.
ROZDZIA 13.
(b) Jakkolwiek
68
Platforma udost¦pnia szczegóªowe mo»liwo±ci konguracyjne - s¡
one domy±lnie ukryte nawet przed u»ytkownikiem o najwy»szych uprawnieniach, czyli -
super-u»ytkownikiem.
(c) Obsªuga systemu zostaªa pomy±lania dla przeci¦tnego przedstawiciela kolekcji,
rozwi¡zuj¡cego raczej problemy powstaªe na skutek komunikacji z u»ytkownikami systemu, ni» wewn¦trzn¡ konguracj¡.
(d) Wiekszo±¢ ustawie« systemu, których zmiana nie powoduje wi¦kszego wzrostu
wydajno±ci, lub które mog¡ zosta¢ przez system uzyskane w sposób automatyczny - zostaªy wyeliminowane z opcji konguracyjnych, ich ustawieniem system
zajmnie si¦ automatycznie.
7.
Platforma jest przenoszalna, niezale»na.
(a) Jest niezale»na od rozwi¡za« specycznych dla danego systemu operacyjnego,
producenta sprz¦tu, czy twórcy systemu bazy danych.
(b) Mo»e pracowa¢ bardziej wydajnie w przypadku pewnych rozwi¡za« ni» innych,
ale jej cech¡ jest mo»liwo±¢ dziaªania w ró»nym ±rodowisku, tj.
mo»liwo±¢
uruchomienia na ró»nych systemach operacyjnych, na ró»nym sprz¦cie oraz z
wykorzystaniem ró»nego rodzaju rozwi¡za« bazodanowych.
8.
Platforma jest efektywna.
(a) Wykorzystuje zasoby sprz¦towe, pami¦ciowe i czasowe w sposób optymalny.
Platforma dziaªa wielow¡tkowo, wieloprocesorowo i wieloserwerowo.
(b) Optymalizuje wykorzystanie zasobów w zale»no±ci od wydarze« zewn¦trznych.
9.
Platforma jest testowalna.
(a) Pozwala na przeª¡czenie si¦ w tryb testowy, w którym mo»na testowa¢ np. jej
wydajno±¢ lub nowo dodane funkcjonalno±ci.
(b) W trybie testowania, udost¦pnia specyczny interfejs komunikacyjny pozwalaj¡cy na wstrzykiwanie danych testowych, tak jakby przyszªy one od rzeczywistego u»ytkownika.
10.
Platforma jest przyjazna dla u»ytkownika.
(a) Dla wi¦kszo±ci u»ytkowników biegªych w poruszaniu si¦ po sieci Internet nie
wymaga specjalnego przeszkolenia lub przygotowania.
(b) Dla mniej do±wiadczonych u»ytkowników wymaga jedynie kilkunastostominutowego przeszkolenia przed przyst¡pieniem do pracy.
(c) Udost¦pnia wi¦kszo±¢ potrzebnych informacji dotycz¡cych dziaªania systemu,
w trakcie korzystania z niego, za pomoc¡ tzw. podpowiedzi kontekstowych.
Dodatek A: Lista nierozwi¡zanych
problemów
Brak organizacji certykuj¡cej na potrzeby
Platformy, t.j.
wymaganie dotycz¡ce przed-
stawienia certykatu pozwalaj¡cego na zakup MBiol. o okre±lonym
PBB mo»e by¢ trudne
w realizacji. Brak jednostki autoryzuj¡cej, równy jest brakowi wiarygodnych certykatów
dot. maksymalnego poziomu bezpiecze«stwa biologicznego dopuszczonego dla danej instytucji czy przedsi¦biorstwa.
69
Lista symboli
CMS
Content Managment System - system zarzadzania informacja, oraz jej miejscem i
sposobem prezentacji
MAP Moduªu Administracyjnego Platformy, oferuje zespóª funkcjonalo±ci niezb¦dnych
do zarz¡dzania Platform¡
MAP-CAC Moduª Administracyjny Platformy - Cz¦±¢ Administrowania CMS
MAP-CAD Moduª Administracyjny Platformy - Cz¦±¢ Administrowania Danymi
MAP-CAM Moduª Administracyjny Platformy - Cz¦±¢ Administrowania Magazynem
MAP-CAR Moduª Administracyjny Platformy - Cz¦±¢ Administrowania Raportami
MAP-CAU Moduª Administracyjny Platformy - Cz¦±¢ Administrowania U»ytkownikami
MAP-CAZ Moduª Administracyjny Platformy - Cz¦±¢ Administrowania Zleceniami
MAP-CAZD Moduª Administracyjny Platformy - Cz¦±¢ Administrowania Zleceniami Depozytu
MBiol. Material biologiczny - wszelki material wykazujacy aktywnosc biologiczna, np.
bakterie, wirusy, plazmidy, linie komorkowe
MCL Microbiological Common Language, jezyk opisu rekordu MBiol., oparty o standard
XML
MPK Moduª Konguracyjny Platformy - cz¦±¢ Platfromy sªu»¡ca do konguracji podstawowej systemu, oraz deniowania jego administratorów
MUP Moduª U»ytkowy Platformy, moduª udost¦pniaj¡cy funkcjonalo±¢ dla u»ytkowników zewn¦trznych (widz, anonimowy, kupiec). MUP jest wewn¦trznie podzielony
na dwie cz¦±ci: Cz¦±¢ Komercyjn¡ i Cz¦±¢ Portalow¡
MUP-CP Moduª U»ytkowy - Cz¦±¢ Portalowa, jedna z funkcjonalno±ci Platformy oferowana przez Moduª U»ytkowy. Jej zadaniem jest umo»liwianie wymiany informacji
u»ytkownikom typu widz (rozpoznawalnych przez system).
MUP-CPO Moduª U»ytkowy Portalu - Cz¦±¢ Portalu Ogólnodost¦pna - cz¦±c funkcjonalno±ci Platformy dost¦pna dla u»ytkowników anonimowych.
Jej zadaniem jest
prezentowanie informacji naukowo-technicznych u»ytkownikom anonimowym (nie
autoryzowanym przez system).
70
ROZDZIA 13.
MZP
71
Moduª Zarz¡dczy Platformy, dostarcza ogóªu funkcjonalno±ci dost¦pnej dla zarz¡dców innych kolekcji.
O-HI
Opis Historii Izolacji - typ sªu»¡cy do opisu historii odkrycia danego rodzaju MBiol.
O-OL Opis Odno±nika Literaturowego - typ rekordu opisuj¡cego odno±niki literaturowe
wykorzystywane do opisu danych u»ywanych przez Platform¦.
O-PZ Opis Pozycji Zamówienia - typ opisuj¡cy ka»d¡ z pozycji MBiol. zamówionego w
transakcji zakupu dokonanej przez klienta.
O-SP Opis Skªadnika Po»ywki - Typ opisuj¡cy cechy pojedy«czego skªadnika, który
wchodzi w skªad po»ywki.
O-WH Opis Warunków Hodowli - typ danych opisuj¡cych szczegóªy hodowania danego
MBiol.
PCM Polish Collection of Microorganisms - Polska Kolekcja Mikroorganizmów, kolekcja
aliowany przy Intytucie Immunologii i Terapii Do±wiadczalnej PAN we Wrocªawiu,
wªa±ciciel Platformy
PKI
Private Key Infrastructure, Infrastruktura potrzebna do wykorzystania mechanizmu szyfrowania niesymetrycznego, w tym werykacji u»ytkowników.
Platforma informatyczna platforma PCM, caªo±¢ oprogramowania i sprz¦tu tworzaca
bazodanowy system informatyczny sªu»¡cy do gromadzenia, przetwarzania i sprzeda»y
informacji dot. materiaªu biologicznego przechowawynego w kolekcji mikroorganizmow PCM.
Po»ywka podªo»e wymagane do wzrostu okre±lonego mikroorganizmu czy linii komórkowej.
Zwykle zawiera list¦ substancji skªadowych wraz z ich udziaªem procentowym
R-DO Rekord Danych Organizacji - struktury danych wymagane do opisu instytucji lub
przedsi¦biorstwa wspóªpracuj¡cego z PCM, lub korzystaj¡cego z funkcjonalno±ci
Platformy.
R-DP Rekord Danych Po»ywek, wyszczególnienie wszystkich pól obowi¡zkowych i opcjonalnych rekordu danych Po»ywki gromadzonych w bazie danych Platformy
R-DU Rekord Danych U»ytkownika, termin opisuj¡cy wszystkie mo»liwe rekordy danych
dla wszelkich typów u»ytkowników wyst¦puj¡cych w strukurach danych Platformy.
R-TZMB Rekord Transakcji Zakupu MBiol. - zawiera pola opisuj¡ce rodzaj transakcji
zakupu MBiol.
oraz wszelkie dane umo»liwiaj¡ce okreslenie jej stanu realizacji i
pªatno±ci.
Rola
zbior urawnie« do wykonywania okre±lonych czynno±ci administracyjnych w Platformie. Role mog¡ by¢ ª¡czone poprzez przypisania u»ytkownikowi kilku ról. W
takim wypadku, nalny zbiór uprawnie« jest sum¡ wszystkich uprawnie« zdeniowanych przez kazd¡ z ról.
ROZDZIA 13.
SBD
72
System Bazy Danych, caªo±¢ oprogramowania niezb¦dna do przechowywania, udost¦pniania i wst¦pnego przetwarzania danych niezb¦dnych do dziaªania Platformy.
T-AWD Typ akceptacji wprowadzanych danych - opisuje sposób w jaki Platforma udost¦pnia dane wprowadzone przez zarz¡dców.
T-CS Typ Cz¦stotliwo±ci Synchronizacji - typ okre±laj¡cy cz¦sto±¢ z jak¡ Platforma synchnizuje swoje dane z innym system informatycznym.
T-DDR Typ Dost¦pu Do Rekordu - deniuje dost¦pno±¢ danego rekordu dla u»ytkowników Platformy.
T-HNMB Typ Historii Namna»ania MBiol. - jest typem opisuj¡cym szczegóªy procesu
namna»ania MBiol., m.in. identykator pracownika, dat¦ wykonania oraz termin
wa»no±ci próbki.
T-LDP Typ ª¡cznika do pliku - typ opisuj¡cy poªo»enie pliku który ma by¢ dost¦pny
poprzez ª¡cznik.
T-LDRMB Typ ¡cznik Do Rekordu MBiol. - opisuje link do innego rekordu R-DMB,
zwykle wykorzystywany jako organizm gospodarza danego MBiol.
T-MMB Typ Magazynowania MBiol. - typ opisuj¡cy stan magazynowy dla ka»dego typu
postaci przechowywania MBiol. (T-PPMB), dost¦pnego dla danego MBiol.
T-PBB Typ Poziomu Bezpiecze«stwa Biologicznego - deniuje liczbow¡ warto±¢ okre±laj¡c¡ maksymalny dost¦pny rodzaj MBiol. ze wzgl¦du na prezentowne zagro»enie
biologiczne.
T-PPMB Typ Postaci Przechowywania MBiol.
- deniuje typ przechowywania MBiol.
który zostaª wybrany do przechowywania danego MBiol.
T-PRZY Typ przesyªki - opisuje detale ofery cenowej danego przewo¹nika
T-PWD Typ Protokoªu Wymiany Danych - okre±laj¡cy typ protokoªu wykorzystywany
przez Platform¦ do wymiany danych z innym system informatycznym.
T-RMB Typ Rekordu MBiol. - zbiór typów rekordów zdeniowanych dla ró»nych MBiol.
oferowanych przez Platform¦.
T-RST Typ restrykcji - grupuje kraje do których przywóz lub wywóz MBiol.
jest do-
puszczony.
T-SD Typ Synchronizacji Danych - typ okre±laj¡cy sposób (kierunek) wymiany informacji
pomi¦dzy Platform¡ a innym systemem informatycznym.
T-SK Stan Konta - typ danych deniuj¡cy czy konto danego u»ytkownika lub systemu
jest aktywne (mo»e by¢ u»ytkowane).
T-SP Typ Sposobu Pªatno±ci - okre±la dost¦pne formy zapªaty za usªugi realizowane za
po±rednictwem Platformy.
ROZDZIA 13.
73
T-SP Typ Stanu Pªatno±ci - typ wyliczeniowy sªu»¡cy do deniowania stanu pªatno±ci
realizowanej transakcji wykonywanych za po±rednictwem Platformy.
T-SZ
Stan Transakcji - typ wyliczeniowy sªu»¡cy do deniowania stanu realizacji transakcji
wykonywanych za po±rednictwem Platformy.
T-TMB Typ Transportu MBiol. - okre±la sposób w jaki zakupiony towar b¦dzie wysªany
do klienta.
T-ZC Typ Zmiennych Cen - opisuje zmiany cen w czasie; pozwala na odtworzenie ceny
obowi¡zuj¡cej na dany towar w dowolnym momencnie w przesªo±ci.
T-ZTL Typ Zapotzebowanie Tlenowe - okre±la ilo±¢ telnu wymagan¡ do poprawnego
rozwoju danego MBiol.
UC
ang. use case, tzw. przypadek u»ycia, obrazyj¡cy pewien algorytm postepowania
za pomoc¡ opisu kroków podejmowanych przez system lub uzytkownika

SIWZ-zal.1-Specyfikacja funkcjonalna PCM

Transkrypt

Podobne dokumenty

404 Strony nie znaleziono

Termometr elektroniczny z przewodem