plik


ÿþIn\ynieria oprogramowania wykBad IV prowadzcy: dr in\. Krzysztof Bartecki Faza analizy systemowej  cig dalszy Wymagania Projektowanie Implementacja Testowanie Konserwacja Instalacja Strategiczna Analiza Dokumentacja Przypomnienie: Jej celem jest udzielenie odpowiedzi na pytanie: jak system ma dziaBa? W wyniku fazy analizy otrzymujemy logiczny model systemu, opisujcy sposób realizacji przez system postawionych wymagaD, lecz abstrahujcy od szczegóBów implementacyjnych. K. Bartecki, In\ynieria oprogramowania, IV/2 Model funkcji   diagram przepBywu danych (DFD) Ï% przedstawia on, w jaki sposób dane przepBywaj w systemie oraz opisuje procesy sBu\ce do przetwarzania tych danych, Ï% opisany jest za pomoc notacji zgodnej z okre[lon konwencj, Ï% zbudowany jest przy u\yciu dobrze znanych metod i narzdzi, Ï% bazuje na hierarchicznej dekompozycji funkcji systemu, Ï% u\ywany jest do wnioskowania o przyszBym oprogramowaniu, . Ï% unika terminologii implementacyjnej. K. Bartecki, In\ynieria oprogramowania, IV/3 SkBadniki diagramu DFD Ï% Terminatory (obiekty zewntrzne), Ï% procesy, Ï% magazyny (skBadnice) danych, Ï% przepBywy danych. K. Bartecki, In\ynieria oprogramowania, IV/4 TERMINATOR Terminator (ang. Terminator) Ï% reprezentuje zródBo lub miejsce przeznaczenia informacji, które jest zewntrzne w stosunku do sytemu, Ï% mo\e by to np. osoba, dziaB urzdu, firma, inny system komputerowy, maszyna, lub inny obiekt znajdujcy si na zewntrz systemu, Ï% nazwa terminatora, to rzeczownik w liczbie pojedynczej, np. KLIENT, DZIAA SPRZEDA[Y, URZD SKARBOWY, DOSTAWCA. K. Bartecki, In\ynieria oprogramowania, IV/5 Inne wBa[ciwo[ci terminatora Ï% Jest obiektem generujcym lub przyjmujcym strumienie danych, Ï% przepBywy Bczce terminatory z ró\nymi skBadowymi modelu reprezentuj interfejsy pomidzy systemem a [wiatem zewntrznym, Ï% le\y poza obszarem odpowiedzialno[ci projektowanego systemu, Ï% analityk/projektant systemu nie mo\e zmienia zawarto[ci terminatora, Ï% w modelu DFD nie pokazuje si przepBywów danych midzy terminatorami, nawet je[li takie w rzeczywisto[ci istniej. K. Bartecki, In\ynieria oprogramowania, IV/6 PROCES Proces (ang. Process) Ï% realizuje transformacj danych wej[ciowych w dane wynikowe  odpowiada tym skBadnikom systemu, które przetwarzaj dane, Ï% otrzymuje i przesyBa dane za po[rednictwem przepBywów danych, Ï% kojarzy si z procedur, której specyfikacja jest przedstawiona przy u\yciu innych technik strukturalnych, Ï% nazwa procesu, to rzeczownik odczasownikowy + dopeBnienie, np. WYSTAWIENIE FAKTURY, PRZYJCIE TOWARU, OBLICZENIE PAAC, Ï% dla celów porzdkowych proces mo\e by oznaczony numerem. K. Bartecki, In\ynieria oprogramowania, IV/7 magazyn danych Magazyn danych (ang. Data store) Ï% reprezentuje miejsce, w którym przez pewien czas s przechowywane dane, Ï% jest dostpny tylko dla procesów, tzn. nie mo\e by poBczony bezpo[rednio z terminatorem lub z innym magazynem, Ï% istnienie magazynu danych w diagramie ma sens, gdy przechowywane dane sBu\ do realizacji co najmniej dwóch procesów, Ï% nazwa magazynu danych to rzeczownik w liczbie mnogiej, np. klienci, faktury, towary, studenci, grupy, pracownicy, Ï% dla celów porzdkowych magazyn danych mo\e by oznaczony numerem. K. Bartecki, In\ynieria oprogramowania, IV/8 Cel istnienia magazynu Umo\liwienie przechowywania danych w sytuacji, gdy: Ï% dane s u\ywane nie od razu po wytworzeniu, Ï% dana jest kilkakrotnie odczytywana, Ï% dane s u\ywane w innej kolejno[ci ni\ byBy wytworzone. PrzykBad: [EGNANIE PRZYJMOWANIE wizieD wizieD wizniowie K. Bartecki, In\ynieria oprogramowania, IV/9 Inne wBa[ciwo[ci magazynu danych Ï% magazyn przechowuje oryginaBy, a oddaje kopie i tylko w przypadku kasowania oryginaBy  znikaj , Ï% przepByw wychodzcy z magazynu interpretowany jest jako czytanie lub dostp do informacji w magazynie, Ï% przepByw do magazynu interpretowany jest jako zapis, modyfikacja lub usunicie danych, Ï% je[li przepByw nie ma etykiety, oznacza to, \e peBen pakiet informacji jest wyszukiwany i pobierany (np. wszystkie rekordy magazynu), Ï% je[li etykieta na przepBywie jest taka sama jak na magazynie ale w liczbie pojedynczej oznacza to, \e jest pobrane jedno wystpienie pakietu (jeden rekord), Ï% nazwy magazynów, takie jak rejestr faktur, archiwum zleceD, baza pojazdów nie s zalecane, lepiej po prostu: faktury, zlecenia, pojazdy. K. Bartecki, In\ynieria oprogramowania, IV/10 przepByw danych PrzepByw danych (ang. Data flow) Ï% opisuje strumieD danych o okre[lonej zawarto[ci, przepBywajcy pomidzy dwoma skBadnikami DFD:  terminatorem a procesem,  procesem a innym procesem,  procesem a magazynem danych. Ï% nazwa przepBywu to rzeczownik w liczbie pojedynczej  np. kwestionariusz osobowy, umowa, faktura dla klienta, potwierdzenie transakcji. K. Bartecki, In\ynieria oprogramowania, IV/11 Inne wBa[ciwo[ci przepBywu danych Ï% PrzepByw danych nie odpowiada na wiele pytaD proceduralnych, np.:  kiedy wchodzi do procesu,  czy jest wynikiem zapytania systemu,  czy istnieje jaka[ wspóBzale\no[ pomidzy przepBywem wchodzcym a wychodzcym, Ï% je[li przekazywana jest informacja zwrotna, mo\na u\ywa kolejnych linii lub strzaBek dwukierunkowych. K. Bartecki, In\ynieria oprogramowania, IV/12 mka jajka ciasto/placek PIECZENIE CIASTA mleko cukier przepBywy proces przepByw wej[ciowe wyj[ciowy K. Bartecki, In\ynieria oprogramowania, IV/13 PrzykBad przepBywu rozbie\nego (te same dane dostarczane s do kilku ró\nych procesów) K. Bartecki, In\ynieria oprogramowania, IV/14 PrzykBad przepBywu rozbie\nego (pakiet danych dzielony jest na kilka ró\nych skBadowych) K. Bartecki, In\ynieria oprogramowania, IV/15 Notacje stosowane na diagramach DFD Yourdon- Gane- nazwa SSADM DeMarco Sarson KLIENT KLIENT KLIENT terminator KLIENT terminator powtórzony faktura faktura przepByw faktura danych K. Bartecki, In\ynieria oprogramowania, IV/16 1 KALKULACJA CEN 1 KALKULACJA CEN * proces KALKULACJA KALKULACJA proces elementarny CEN CEN 1 KALKULACJA CEN proces wielokrotny faktury D1 magazyn faktury faktury danych faktury D1 magazyn powtórzony K. Bartecki, In\ynieria oprogramowania, IV/17 BBdne konstrukcje na diagramach DFD Typowe bBdy przy tworzeniu diagramów DFD wynikaj z: Ï% u\ycia niewBa[ciwych nazw dla skBadników diagramu, Ï% niewBa[ciwego Bczenia komponentów, Ï% u\ycia procesów  duchów i procesów  studni , Ï% niewBa[ciwego bilansowania przepBywów w przypadku dekompozycji, K. Bartecki, In\ynieria oprogramowania, IV/18 BBdne nazwy skBadników diagramu drukowanie drukowanie Cel raport roczny raporu Szef raport roczny raporu rocznego rocznego NiewBa[ciwa nazwa terminatora rejestracja rejestracja Klient wprowadzanie danych Klient infomacja o kliencie danych danych NiewBa[ciwa nazwa przepBywu danych K. Bartecki, In\ynieria oprogramowania, IV/19 przygotowanie Kontrahent dane kontrahenta Kontrahent dane kontrahenta Kowalski umowy NiewBa[ciwa nazwa procesu rejestracja rejestracja termin zapBaty FV 345/2004 termin zapBaty faktury pBatno[ci pBatno[ci NiewBa[ciwa nazwa magazynu danych K. Bartecki, In\ynieria oprogramowania, IV/20 NiewBa[ciwe Bczenie komponentów Kontrahent faktura zakupu Towary Dostawca Klient Niedopuszczalne poBczenie Niedopuszczalne poBczenie dwóch terminatorów terminatora z magazynem faktury klienci Niedopuszczalne poBczenie dwóch magazynów K. Bartecki, In\ynieria oprogramowania, IV/21 Procesy  duchy i procesy  studnie tworzenie rejestru oferta sprzeda\y rejestracja zamówienie klienta rejestr sprzeda\y zamówieD Proces bez przepBywów Proces bez przepBywów wyj[ciowych ( studnia ) wej[ciowych ( duch ) K. Bartecki, In\ynieria oprogramowania, IV/22 Dekompozycja procesów  diagramy hierarchiczne Umieszczenie na jednym poziomie wszystkich procesów skutkowaBoby powstaniem nieczytelnego diagramu ze zbyt du\ liczb procesów, przepBywów, magazynów danych: Z tego wzgldu modelowanie przepBywów danych polega zazwyczaj na stworzeniu hierarchicznej, wielopoziomowej grupy diagramów DFD. K. Bartecki, In\ynieria oprogramowania, IV/23 W skBad hierarchicznego DFD wchodz nastpujce poziomy diagramów: Ï% diagram kontekstowy  definiujcy zakres i granice systemu, Ï% diagram systemowy (diagram poziomu zerowego)  pokazujcy gBówne funkcje systemu, Ï% diagramy szczegóBowe (procesów elementarnych)  ukazujcy podziaB gBównych procesów systemu, rozBo\onych na podprocesy:  diagram poziomu 1,  diagram poziomu 2, : K. Bartecki, In\ynieria oprogramowania, IV/24 Diagram kontekstowy Ï% to szczególny przypadek DFD, na którym caBy modelowany system reprezentowany jest przez pojedynczy proces, Ï% proces ten powizany jest z terminatorami za pomoc przepBywów danych, Ï% diagram ten ma na celu przedstawienie powizaD systemu ze [rodowiskiem zewntrznym, Ï% terminator mo\e komunikowa si z systemem bezpo[rednio lub przez magazyn, Ï% z lub do terminatora mo\e wypBywa/wpBywa kilka przepBywów, dlatego dla wikszej czytelno[ci diagramu, dopuszcza si powielanie terminatorów. K. Bartecki, In\ynieria oprogramowania, IV/25 PrzykBadowy diagram kontekstowy K. Bartecki, In\ynieria oprogramowania, IV/26 PrzykBadowy diagram kontekstowy K. Bartecki, In\ynieria oprogramowania, IV/27 Diagram systemowy (zerowego poziomu) Ï% przedstawia gBówne funkcje, kluczowe dla modelowanego systemu, Ï% stanowi najbardziej ogólne spojrzenie na  wntrze systemu, Ï% zawiera kilka procesów (2-8), terminatory oraz magazyny danych. K. Bartecki, In\ynieria oprogramowania, IV/28 (b) (a) PrzykBadowy diagram kontekstowy (a) oraz odpowiadajcy mu diagram systemowy (b) K. Bartecki, In\ynieria oprogramowania, IV/29 (b) (a) PrzykBadowy diagram kontekstowy (a) oraz odpowiadajcy mu diagram systemowy (b) K. Bartecki, In\ynieria oprogramowania, IV/30 PrzykBadowy diagram systemowy K. Bartecki, In\ynieria oprogramowania, IV/31 Diagramy szczegóBowe Ï% przedstawiaj procesy, na które dekomponowany ( rozkBadany ) jest ka\dy z procesów diagramu systemowego, Ï% proces o numerze 1. z diagramu systemowego dekomponowany jest na podprocesy o numerach 1.1, 1.2, 1.3, itd., proces 2.  na podprocesy 2.1, 2.2, 2.3, itd., Ï% na kolejnym poziomie dekompozycji proces 1.1 mo\e by rozBo\ony na podprocesy 1.1.1, 1.1.2, itd., Ï% dekompozycj prowadzi si tak dBugo, a\ otrzymamy procesy elementarne. K. Bartecki, In\ynieria oprogramowania, IV/32 DK 0 3 1 2 3.2 3.3 3.1 1.1 1.2 1.2.1 1.2.2 PrzykBadowa hierarchia diagramów przepBywu danych K. Bartecki, In\ynieria oprogramowania, IV/33 Zasady tworzenia diagramów wielopoziomowych Ï% Prosty system powinien mie nie wicej ni\ 2-3 poziomy, [redni 3-5 poziomów, du\y do 8 poziomów, Ï% liczba procesów na jednym diagramie nie powinna by wiksza ni\ 6-8, Ï% nie wszystkie procesy musz by rozwijane do tej samej liczby poziomów (ró\ny stopieD zBo\ono[ci), Ï% obiekty, które Bcz si z dekomponowanym procesem za pomoc przepBywów (terminatory, magazyny, inne procesy) musz wystpi na poziomie ni\szym, Ï% diagramy powinny by zbalansowane (zrównowa\one). K. Bartecki, In\ynieria oprogramowania, IV/34 Metody rozwijania hierarchicznych DFD Ï%  z góry na dóB (top-down), Ï%  z doBu do góry (bottom-up). W metodzie  z góry na dóB rozpoczynamy budow od diagramu kontekstowego i drog kolejnych uszczegóBowieD (dekompozycji) procesów dochodzimy do rozwizania koDcowego w postaci procesów atomowych (elementarnych). W metodzie  z doBu do góry najpierw tworzy si list niezale\nych procesów, które nie bd dalej dekomponowane. Nastpnie grupuje si je do postaci procesów wy\szego rzdu, a\ do otrzymania diagramu kontekstowego. K. Bartecki, In\ynieria oprogramowania, IV/35 Balansowanie (równowa\enie) diagramów DFD Ï% Hierarchiczne diagramy DFD powinny by zbalansowane, czyli zrównowa\one wzgldem kolejnych poziomów dekompozycji, Ï% wszystkie przepBywy, które pojawiBy si na diagramie poziomu wy\szego, powinny si znalez na diagramie poziomu ni\szego, Ï% na ni\szym poziomie pojawiaj si dodatkowe przepBywy pomidzy procesami i magazynami danych oraz pomidzy nowymi procesami, które pojawiBy si w wyniku dekompozycji procesów wy\szego poziomu. K. Bartecki, In\ynieria oprogramowania, IV/36 Równowa\enie diagramu DFD K. Bartecki, In\ynieria oprogramowania, IV/37 Równowa\enie diagramu DFD K. Bartecki, In\ynieria oprogramowania, IV/38 Równowa\enie diagramu przepBywu danych (DFD) wzgldem diagramu zwizków encji (ERD) Ï% Ka\dy magazyn danych na DFD musi odpowiada encji na ERD, Ï% nazwy encji na ERD oraz nazwy magazynów danych na DFD musz sobie odpowiada (np. encja: KLIENT, magazyn danych: KLIENCI), Ï% je\eli s na diagramie DFD magazyny danych nie majce swojego odpowiednika na diagramie ERD, model nale\y poprawi. Ï% je\eli s na diagramie ERD encje nie majce swojego odpowiednika na diagramie DFD, model nale\y poprawi, Ï% na diagramie DFD powinny istnie procesy, realizujce operacje tworzenia i usuwania instancji ka\dej z encji (elementu magazynu danych). K. Bartecki, In\ynieria oprogramowania, IV/39 Specyfikacja procesów Ï% stanowi algorytmiczn definicj procesu, czyli opisuje, co dzieje si wewntrz procesu w celu przeksztaBcenia danych wej[ciowych w dane wyj[ciowe, Ï% tworzona jest dla procesów elementarnych, czyli dla procesów na najni\szym poziomie diagramu przepBywu danych, Ï% stanowi mo\liwie precyzyjny i jednoznaczny opis czynno[ci wykonywanych przez proces, Ï% istnieje wiele sposobów specyfikowania procesów, np.  opis w jzyku strukturalnym (tzw. pseudokod),  opis warunków zachodzcych przed i po wykonaniu procesu,  drzewo lub tablica decyzyjna,  wzór matematyczny. K. Bartecki, In\ynieria oprogramowania, IV/40 PrzykBad specyfikacji procesu w formie pseudokodu status potwierdzenie wykonania Zlecenia wykonania 1.3 SERWISANCI POTWIERDZENIE WYKONANIA data ostatniego przegldu wysBanie Przegldy rachunku KLIENCI GET potwierdzenie wykonania FROM TERMINATOR Serwisanci AS potwierdzenie IF (potwierdzenie) { SEND wysBanie rachunku TO TERMINATOR Klienci SET data ostatniego przegldu AS aktualna data SAVE data ostatniego przegldu TO STORE Przegldy SET status wykonania AS wykonane SAVE status wykonania TO STORE Zlecenia } K. Bartecki, In\ynieria oprogramowania, IV/41 PrzykBad specyfikacji procesu w formie pseudokodu raport Zlecenia 1.5 KIEROWNICTWO TWORZENIE RAPORTÓW IF (data systemowa > 27 danego miesica) { FOR Serwisanci { DO { FIND (Serwisant, data realizacji, status) FROM STORE Zlecenia IF (data realizacji = bie\cy miesic AND status = wykonane) } WHILE TRUE } SEND raport TO TERMINATOR Kierownictwo K. Bartecki, In\ynieria oprogramowania, IV/42 Macierz CRUD jest tabel, odwzorowujc zwizki pomidzy procesami a magazynami danych lub pomidzy procesami a danymi elementarnymi. Nazwa macierzy pochodzi od pierwszych liter operacji wykonywanych przez procesy na magazynach lub elementach danych: C  Create, w przypadku zapisu danych, R  Read, w przypadku odczytu danych, U  Update, w przypadku modyfikacji danych, D  Delete, w przypadku usuwania danych. K. Bartecki, In\ynieria oprogramowania, IV/43 Ï% NagBówkami kolumn macierzy CRUD s nazwy procesów, a nagBówkami wierszy  nazwy magazynów lub elementów danych, natomiast na przeciciu kolumn i wierszy wystpuj odpowiednie litery oznaczajce wykonywan operacj. Ï% Analizujc zawarto[ macierzy mo\na przeprowadzi dodatkow kontrol modelu pod ktem wykorzystania magazynów danych przez procesy. Ï% W praktyce magazyny danych najcz[ciej oznaczaj tablice relacyjnej bazy danych, w odniesieniu do których wykonywane s standardowe instrukcje jzyka SQL:  zapis (INSERT),  odczyt (SELECT),  aktualizacja (UPDATE),  kasowanie (DELETE). K. Bartecki, In\ynieria oprogramowania, IV/44 PrzykBadowa macierz CRUD K. Bartecki, In\ynieria oprogramowania, IV/45 Fragment przykBadowej macierzy CRUD w programie PowerDesigner K. Bartecki, In\ynieria oprogramowania, IV/46 PrzykBadowy diagram DFD  System rejestracji studentów Diagram kontekstowy K. Bartecki, In\ynieria oprogramowania, IV/47 Diagram systemowy (zerowego poziomu) K. Bartecki, In\ynieria oprogramowania, IV/48 Diagram szczegóBowy (pierwszego poziomu) dla procesu 4. K. Bartecki, In\ynieria oprogramowania, IV/49 K. Bartecki, In\ynieria oprogramowania, IV/49 SBownik danych Nie jest mo\liwe zamodelowanie wymagaD u\ytkownika bez zdefiniowania danych wystpujcych w systemie. Dlatego oprócz diagramu zwizków encji (ERD) oraz diagramu przepBywu danych (DFD), w skBad modelu strukturalnego wchodzi równie\ sBownik danych (ang. data dictionary). SBownik danych to uporzdkowany wykaz wszystkich danych, majcych zwizek z projektowanym systemem. K. Bartecki, In\ynieria oprogramowania, IV/50 Zawarto[ sBownika danych W sBowniku danych opisywane s: Ï% przepBywy i magazyny danych pokazane na diagramach DFD, Ï% zBo\one pakiety danych transmitowane wzdBu\ przepBywów, Ï% pakiety danych w magazynach, odpowiadajce encjom z diagramu ERD wraz i ich atrybutami. K. Bartecki, In\ynieria oprogramowania, IV/51 PeBna definicja elementu danych powinna okre[la: Ï% znaczenie elementu danych w kontek[cie aplikacji u\ytkownika, na ogóB w formie komentarza, Ï% budow elementu danych, Ï% zbiór warto[ci, jakie mo\e przyjmowa element danych, w przypadku danych elementarnych, czyli niepodlegajcych dekompozycji. SBownik danych powstaje na etapie analizy wymagaD dotyczcych systemu, nie za[ na etapie projektowania fizycznej implementacji. Dlatego uwzgldnia on istnienie elementów danych, a nie ich posta fizyczn  np. pensja to siedem cyfr dziesitnych z dwoma miejscami po przecinku. K. Bartecki, In\ynieria oprogramowania, IV/52 Notacja sBownika danych Istnieje wiele notacji sBownika danych, ale jednym z najprostszych i najpopularniejszych jest schemat skBadajcy si z nastpujcych operatorów: = jest zBo\ony z " i () element opcjonalny {} element powtarzalny (iteracja) [ ] wybór z mo\liwo[ci alternatywnych | rozdzielenie mo\liwo[ci alternatywnych ** pocztek i zakoDczenie komentarza (minispecyfikacji elementu danych) @ element identyfikujcy K. Bartecki, In\ynieria oprogramowania, IV/53 Fragment przykBadowego sBownika danych Cyfra = [ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ] Litera = [a...z | A...Z] Znak = [! | @ | # | $ | % | & | * | ( | ) | _ | + | - | = | { | } | [ | ] |  | ; |  | < | > | , | . | ? | / | ^ ] Dostawca = @Id_dostawcy + Nazwa + Adres + (e-mail) + Telefon + Oso- ba_kontaktowa @Id_dostawcy = 1{cyfra}8 Nazwa = nazwa firmy {litera} Adres = Adres firmy Ulica + Numer budynku + (Numer lokalu) + Kod + Miejscowo[ Ulica = {litera} Numer budynku = {cyfra} + (litera) Numer lokalu = {cyfra} + (litera) Kod = Kod pocztowy cyfra + cyfra + znak - + cyfra + cyfra + cyfra Miejscowo[ = {litera} e-mail = {litera + (znak .| znak _)} + znak @ + {litera + (znak . | znak _)} Telefon = (znak ( + {cyfra} + znak )) + {cyfra} K. Bartecki, In\ynieria oprogramowania, IV/54 Fragment przykBadowego sBownika danych  cig dalszy Osoba_kontaktowa = Osoba z firmy odpowiedzialna za kontakty z obsBug systemu Imi + Nazwisko Imi = {litera} Nazwisko = {litera} Cena towaru = Id_towaru + Cena netto + VAT + Ilo[_dla_upustu + Data wa\no[ci Id towaru = Identyfikator towaru, którego dotyczy kalkulacja ceny {cyfra} Cena netto = {cyfra} + znak , + cyfra + cyfra VAT = Wielko[ podatku VAT naliczanego dla danego towaru {cyfra} Ilo[_dla_upustu = Minimalna liczba sztuk towaru gwarantujca upust cenowy {cyfra} Upust = Warto[ okre[lajca, o ile zmniejszy si cena w przypadku upustu {cyfra} Data wa\no[ci = Data koDcowa obowizywania kalkulacji cenowej dla danego towaru w formacie dd-mm-rrrr cyfra + cyfra + znak - + cyfra + cyfra + znak - + cyfra + cyfra + cyfra + cyfra Id_towaru = Identyfikator towaru, którego dotyczy raport {cyfra} K. Bartecki, In\ynieria oprogramowania, IV/55

Wyszukiwarka

Podobne podstrony:
io wyklad1
io wyklad2
IO Wyklad 01a SSM i Rich Picture
io wyklad5
io wyklad5
IO Wyklad 01 Wprowadzenie
Wyklad IO 7
Wyklad IO 4
Wyklad IO 1
Wyklad IO 3
wyklad io 1
Wyklad IO 2
IO notatki z wykladow
Sieci komputerowe wyklady dr Furtak
Wykład 05 Opadanie i fluidyzacja
amd102 io pl09

więcej podobnych podstron