Inżynieria oprogramowania
Tworzenie systemów informatycznych:- Programowanie – jedna z faz (coraz mniej znacząca)- Wyspecjalizowane: wieloosobowe zespoły (wielkość SI, czas realizacji, utrzymanie ciągłości pracy)- Wytworzenia a wdrożenie- Inżynieria: wytworzenie- Inżynieria oprogramowania jest to wiedza techniczna (i empiryczna) dotycząca wszystkich faz cyklu życia oprogramowania- Traktuje oprogramowanie jako produkt- Produkcja oprogramowania – wiele faz (i produkcja pośrednia), kodowanie – tylko jedna z nich – nie najważniejsza- Wysoka jakość:o Poprawnośćo Zgodność z wymaganiamio Ergonomiczność, łatwość użyciao Niezawodność współdziałaniao Efektywnośćo Łatwość ponownego użycia i konserwacjio Przenoszalność (przeniesienie z jednego środowiska w drugie środowisko)o Skalowalność (rozbudowa)- Na czas- Koszt sensowny- Analiza: projektowanie systemów- Testowanie systemów- Zapewnienie wysokiej jakości oprogramowania- Planowanie, realizacja i nadzór nad przedsięwzięciem informatycznym- Przygotowanie dokumentacji- Zapewnienie niskich kosztów pielęgnacji i rozwoju systemu- Praca z użytkownikiem i w zespole- Wysokie prawdopodobieństwo niepowodzenia projektu informatycznego- Ogromne koszty utrzymania oprogramowania informatycznego- Spadek wydajności wykonawców- Wydano 20 mld USD na projekty SI- 31% projektów w ogóle nie ukończono- 53% projektów kosztowało 189% zakładanego budżetu (koszty dodatkowe na ich ukończenie przekroczyły 51 USD)- 16% projektów terminowo i w budżecie- Utrzymanie 10 mld linii istniejących programów kosztowało 70 mld $ rocznie- Średnia wydajność wykonawców oprogramowania wzrosła o 13%- Zbyt szybki postęp – frustracje informatyków- Wzrost kosztów rozwoju i utrzymania SI- Problem integracji SI- Problem starych systemów- Kryzys starych systemów- Duża złożoność tworzonych SI- Niepowtarzalność i wielodziedziczoność projektów- Niewidzialność SI i procesu ich wytwarzania- Długi cykl wytwarzania SI w warunkach stałych w otoczeniuZłożoność – źródła:- Dziedzina problemowa: duża liczba elementów, złożone związki- Środku techniczne i programowe (TI): złożoność, rozwój- Użytkownicy: różnorodność, zmienność wymagań, skłonność do błędów, tajność- Zespół wykonawczy – umiejętność, czas, środki, komunikacji- Zasady dekompozycji hierarchiczności- Zasady abstrakcji i strukturyzacji- Zasada ponownego użycia- Wiele aspektów opisu- Zasada sprzyjania naturalnym ludzkim własnościom- Wieloetapowość i iteracyjnośćZasada hierarchiczności:- Podział opisu obiektu na poziomy wg stopnia detalizacji opisu – wydzielenie struktury obiektu (strukturyzacji)- Umożliwiao Opracowanie jednorodnych opisów (projektów) poszczególnych elementówo Dostosowanie opisu do możliwości percepcji człowieka- Obiekt – układ powiązanych ze sobą systemówZasada dekompozycji:- Podział złożonego obiektu na mniejsze części- Możliwość rozłączonego projektowania poszczególnych części z uwzględnieniem ograniczeń i związków z innymi elementamiWalka z kryzysem:- Techniki i narzędzia wspomagające pracę nad systemami- Metody wspomagające analizę i modelowanie zjawisk- Usystematyzowanie procesu wytwarzania aplikacji- Profesjonalizm w podejściu do SIPodstawowy problem IO:- Człowiek (analityk, projektant, programista, administrator) z jego uwarunkowaniami:o Fizycznymio Mentalnymio Psychologicznymi- Twórcy SI (ludzie) muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania- Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowaniaModelowanie pojęciowe:- Modelowanie pojęciowe (conceptal modeling) o model pojęciowy (conceptal model) powstaje w wyniku procesów myślowych i wyobrażeń towarzyszących nad SI- Modelowanie pojęciowe jest wspomagane przez wzmacniające ludzką pamięć i wyobraźnię- Służy ono do przedstawienia rzeczywistego opisywania danych procesów zachodzących w rzeczywistości, struktur oraz programów składających się na konstrukcje- NotacjeNotacje w IO – rodzaje:- Język naturalny- Notacje graficzne- Specyfikacje – ustrukturalizowany zapis tekstowy numerycznySzczególne znaczenie mają notacje graficzne. Oprogramowanie wzoruje się na innych dziedzinach techniki takich jak elektronika i mechanika. Zalety notacji graficznej potwierdzają badania psychologiczne.- Narzędzia pracy analityka i projektanta, zapis i analiza pomysłów- Współpraca z użytkownikiem- Komunikacja z innymi członkami zespołu- Podstawa implementacji oprogramowania- Zapis dokumentacji technicznej – notacje powinny być przejrzysteTechnika, metoda i metodyka- Technika – sposób wykorzystania narzędzi (np. aparat pojęciowy, wzory, notacje, oprogramowanie) do rozwiązywania problemów- Metoda – celowy sposób posługiwania się i wykorzystywania technik- Metodyka – zespół wytycznych dotyczących metod, efektywnych ze względu na określony celMetodyka IO- Fazy projektu, role uczestników projektu- Modele tworzone w każdej z faz- Scenariusze postępowania w każdej z faz- Reguły przechodzenia od fazy do następnej fazy- Notacje, których należy używać- Dokumentacje powstają w każdej z fazTypy metodyk:- Strukturalna (model danych i przetwarzań – procesów)- Obiektowe (model obiektów z danymi procesów)- MieszaneMetodyki – różnice i praktyka:- Podejście proponowane przez różnych autorów różnią się częściowo, inne są jednak ze sobą sprzeczne- Poszczególne metodyki zawierają elementy rzadko wykorzystywanych w praktyce- Notacje proponowane przez różnych autorów nie są koniecznie nierozerwalne z metodyką- Nie ma metodyk uniwersalnych, analitycy i projektanci wybierają kombinację technik i notacji, która jest w danym momencie najbardziej przydatna- Narzędzia CASE nie narzucają metodyk, raczej określają one tylko notacjeCASE (Computer Added Software Enginnering) – Zespół narzędzi informatycznych wspomagających proces wytwarzania oprogramowania na wszystkich jego fazach:- Upper – Case (dla wszystkich etapów)- Lower – Case (wspomaganie implementacji)- Integralność – Case (wszystkie fazy)SI a dom – opis i budowa:- Wymagania – Projekt – Realizacja – Konserwacja – Usunięcie- Funkcje- Architektura- Konstrukcjao Budowlanao Instalacjeo WykończenieRodzaje struktur SI:Funkcjonalna – zakres tematyczny, cele, funkcje SI, podział systemu na podsystemy, moduły, funkcje i zadaniaInformacyjna – dane WE i WY, zbiory danych w SI, algorytmyTechniczna – środki techniczne, niezbędne do realizacji (konfiguracja, parametry, urządzenia we/wy)Przestrzenna – rozmieszczenie obiektów SIOprogramowania – zbiór programów narzędziowych i czynniki określające struktury.Struktura Czynniki i obiekty/ zewnętrze Czynniki subiektywne / wewnętrzneFunkcjonalna - Cele systemu- Zakres działalności Informacyjna - dostępne informacje wej.- potrzeby w informacji wyj. - struktura funkcjonalna- podział systemu- wew. zbiory danychTechniczna - możliwości tech. sprzętu- możliwości zakupu- założenia technicz. – organiz. - natężenie informacji we/wy- organizacja i obojętn. danych- sposoby realizacji systemuPrzestrzenna - lokalizacja przestrzenna SI- możliwości tech. – organiz. rozmieszczenia sprzętu- miejsce wprowadzania lub wykorzystywania informacji - struktura funkcjonalna- struktura technicznaOprogramowania - oprogramowanie narzędziowe (istnienie i dostępność- doświadczenie projektantów programu - wszystkie struktury SICykl życia SI (Software Life Cycle) – proces złożony z ciągu wzajemnie spójnych etapów pozwalający na pełne i skuteczne stworzenie, a następnie użytkowanie SI, obejmuje okres od momentu uświadomienia potrzeby istnienia systemu do momentu jego wycofania z eksploatacji.Cykl życia – typowe etapy:- Faza strategiczna- Określenie wymagań- Analiza systemowa- Projektowanie (modelowanie)- Implementacja- Dokumentacja- Testowanie- Instalacja- Konserwacja, rozwójModele cyklu życia SI:- Kaskadowy- Prototypowanie- Spiralny- Przyrostowy (ewolucyjny)- Montaż z gotowych elementów (komponentowych)- Inne (ORACLE, RAD, V)Model kaskadowy (liniowy, klasyczny, waterfall):- Założenia: stabilny zestaw potrzeb i ich niezmienność w trakcie budowy SI, modelowa praca zespołów (top – down)- (+) Upraszcza zarządzanie u ułatwia planowanie- (-) Narzucenie ścisłej kolejności prac, wysoki koszt błędów popełnionych na początku, długa przerwa w kontaktach z klientemModel z prototypem:- Prototyp – model SI, działający lub demonstrujący działanie SI- (+) Zaangażowanie użytkownika, wczesne wykrycie różnic w rozumieniu SI (funkcji, specyfikacji), możliwości szkoleń na prototypie- (-) Dodatkowy koszt, uproszczenia, niebezpieczeństwo poprzestania na prototypie, przekonanie użytkownika o łatwości tworzenia SIPrototypowanie – techniki:- Szybkie sprawdzanie koncepcji systemu (proof –of – concept prototyping)- Projektowanie przez prototypowanie (design prototyping)- Budowa systemu poprzez prototypowanie (development prototyping)- Niewielki zakresPrototypowanie – zastosowanie:- Niewielki zakres przedsięwzięcia- Krótki czas realizacji SI- Ograniczone fundusze na realizację SI- Niezdecydowany i trudny użytkownik- Dynamiczność sytuacji gospodarczej, opisywanej w SIPrototypowanie – narzędzia:- Generatory interfejsu i oprogramowania- Programowanie wizualne- Wykorzystanie gotowych komponentów- Języki wysokiego poziomu (4GL, SQL)- Szybkie oprogramowanie- Papier, tablica, mazaki- Programowanie odkrywczeProgramowanie odkrywcze (Exploratory Programming):- (+) Szybkie rozpoczęcie prac z trudnym użytkownikiem- (-) Dodatkowy koszt, brak ścisłej specyfikacji systemu, brak możliwości zachowania sensownej struktury i niezawodności systemu, brak dokumentacji, amatorski sposób budowy SIMontaż z gotowych komponentów- Projekt- Zakup elementów od dostawców- Integracja ich w SIZalety:- wysoka niezawodność- zmniejszenie ryzyka- Efektywność wykorzystania specjalistów- Narzucenie standardówWady:- Dodatkowy koszt przygotowania elementów- Ryzyko uzależnienia się od dostawcy elementów- Niedostatki istniejących narzędziMetodyka ORACLE:- CASE * Method – własna metodyka firmy ORACLE (dostosowana do wytwarzania SI metodami CASE firmy ORACLE)- Analiza strategiczna obejmuje całość prac, następne etapy dotyczą poszczególnych fragmentów systemuUwarunkowania doboru metodyki projektowania SI:- Wielkość przedsięwzięcia (zakres tematyczny SI, rozbudowa SI, wielkość i złożoność struktury, danych, złożoność algorytmów)- Czasokres realizacji przedsięwzięcia- Współpraca z użytkownikiem- Wielkość i umiejętności zespołu projektującego SI (liczba osób, znajomość dziedziny przedmiotowej, znajomość narzędzi projektowo – programowych, CASE)- Dostępność narzędzi- Cena opracowania systemu (fundusze na użytkowanie SI i fundusze na realizację konkretnego zakresu prac projektowo – wdrożeniowych)Rezultaty wyboru metodyki- Kolejność i zakres prac- Zawartość dokumentacji- Koszty- Metodyki modelowania i projektowania, notacjeFaza strategicznaZadania – rezultaty:- Określenie celów- Ogólne określenie wymagań (model projektowania)- Oszacowanie kosztów i ryzyka- Wstępny harmonogram- Określenie standardówAnaliza systemu informacyjnego- Rezultat: sformalizowany model obszaru informatycznegoo Metody analizy:§ Obserwacja§ Wywiady§ Dzienniki§ Dyskusje§ Inneo Metody opisu:§ Słowny§ Tablice decyzyjne§ Modele procesów§ InneOkreślone wymagania:- Wymagania funkcjonalne i niefunkcjonalne- Poziomy opisu:o Definicja wymagań – ogólny opiso Specyfikacja wymagań – diagramy funkcji, diagramy przypadków użyciao Specyfikacja oprogramowania – formalna- Rezultat: co ma system robićModelowanie SI:- rezultat logiczny model systemu- techniki modelowania SI:o strukturalne (diagramy przepływu danych – DF, diagramy związków encji – ERD)o obiektowe (diagramy klas i obiektów, diagramy interakcji i przejść stanów)Projektowanie:- Rezultat: jak ma system być zaimplementowany- Obszar:o Interfejs użytkownika (układ menu, szata we/wy, komunikacja)o Fizyczna struktura BD i kodu progr. (podsystem, moduły, procedury i funkcje)- Optymalizacja projektu dostosowana do wy. ŚrodowiskaProjektowanie – inne elementy- Kodowanie danych (wartości, algorytmy, weryfikacja i maski)Zasady budowy MPB- Zdarzenia wej. i wyj. (zakończenie procesów)- Blok decyzyjny ma minimum 2 wyjścia- Po weryfikacji (we. Inform.) – blok decyzyjny- Dokumenty we i wy (zwrot strzałek)- Połączenie pomiędzy poszczególnymi procesami- Poprawność i jednoznaczność opisu- Dokładność, abstrakcja, czytelnośćAnaliza – wspomaganie:- Systemy wspomagania komputerowego: CASE- Przykłady:o ARIS (ARIS – Modeller, ARIS – Navigator, ARIS – Analyser)o BONNI – Uniwersytet Szczecińskio DIANA (Diagnostyczna Analiza)Dokument i Analiza:- Opis – wprowadzenie (cel, zakres, podmiot i jego struktura)- Modele procesów biznesowych (diagramy, drzewo decyzyjne, przypadki użycia)- Tablice z opisami dokumentami we/wy- Specyfikacja wartości informacyjnej dokumentów (BNF + opis danych elementarnych)- Inne dane (kontekst, organizacja, plany, potrzeby i oczekiwania)Faza strategiczna:Zadania – rezultaty:- Określenie celów- Określenie zakresu i kontekstu (otoczenia)- Ogólne określenie wymagań (model, projekt)- Oszacowanie kosztów i ryzyka- Wstępny harmonogram- Określenie standardówStadium wykonalności:- Wykonalność techniczna- Wykonalność ekonomiczna (efektywność)- Wykonalność organizacyjna- Wykonalność prawnaRaport wykonalności:- Słownik terminów, do których się odwołuje- Opis istniejącego systemu- Wymagania dotyczące nowego systemu- Opis proponowanego systemu- Plan wytwarzania systemu- Opis rozważanych alternatyw- Szacunek kosztów i korzyści- Ocena ryzyka i analiza jego redukcji- Prawne skutki realizacji systemuPodsumowanie:- Analiza pozwala poznać istniejący system - Analiza wymaga stosowania różnych technik- Faza strategiczna wytycza cele, wyznacza sposób realizacji systemu informatycznego oraz kosztyOkreślenie wymagań:- Istota fazy określenia wymagań- Celem jest ustalenie, co system ma realizować, funkcje, preferencje)- Zamiana celów klienta na wymagania- Proces współpracy analityk systemu + klient + ekspert dziedziczeń- Konieczność dużego zaangażowania klienta- Weryfikacja wymagań- Klient nie potrafi zdefiniować celów i wymagań- Cele mogą być osiągnięte na wiele sposobów- Wielu użytkowników – wiele celów – sprzeczności różnorodności terminologii- Zleceniodawcy a użytkownicy, przewidywalność potrzeb, sprzeczność interesów- Niejednorodność językaPoziomy opisu wymagań:- Definicja wymagań- Specyfikacja wymagań – zapis uporządkowany wykorzystujący notacje i formalne- Specyfikacja wymagań oprogramowania – formalny opis wymagańFormalizacja – dokładność, jednoznaczność (nie stwarza decyzji do różnej interpretacji):- Notacja- Jakość opisu wymagań- Kompletność i niesprzeczność (spójność)- Jednoznaczność i dokładność- Realistyczność i osiągalność- Wyraźna specyfikacja ograniczeń- Opis zewnętrznych zachowań SI (co będzie wykonywał system – od strony użytkownika)- Możliwość modyfikacji i zmian- Opis zachowania się SI w systemie wyjątkowym i sposób rozwiązania problemówMetody rozpoznawania wymagań:- Wywody i przeglądy procesów i zdarzeń (MBP – jeśli było przeprowadzone)- Analiza istniejącego oprogramowania- Analiza wymagań innych SI- Studium osiągalności- PrototypowanieTypy wymagań:- Funkcjonowanie – czynności, które SI musi wykonać w relacji na zdarzenia zewnętrzne (ewidencja, podliczanie)SI – jest środkiem do osiągnięcia celuDokument – specyfikacja wymagań:- Wprowadzenie (cele, adres, kontekst systemu)o Adres – czego dotyczy systemo Kontekst – w jakim otoczeniu- Opis ewolucji systemu- Opis wymagań funkcjonalnych- Opis wymagań niefunkcjonalnych- Model funkcjonalny SI- Wymagania przedsięwzięcia (czas, zasady)- Słownik terminów informatycznyStruktura MF (Modelu Funkcjonalnego):- Identyfikacja zdarzeń, na które ma reagować SI- Identyfikacja obiektów zewnętrznych generujących zdarzenia (osoby, systemy)- Diagram kontekstowy SI- Hierarchiczny model funkcji SI- Typy zdarzeńo Pojawienie się danych na granicy systemu (do i z systemu)o Wymuszenie z zewnętrznych (wpływ czasu)o Sterowanie systemu- Identyfikacja zdarzeń z punktu widzenia otoczenia systemu- Identyfikacja wyjątków zdarzeń niepożądanychObiekty zewnętrzne:- Obiekty (lub ich grupy), które dostarczają informacji do SI lub też wykorzystują informacje tworzone w rezultacie pracy SI (generują zdarzenia zewnętrzne)- Granica systemu – otoczenia (jak przepływają dane)Hierarchiczny model funkcji:- Lista hierarchii- Układ poziomyModel funkcji – zasady:- Funkcja - działania (czasownik) – otrzymanie- Zwięzłość, jednoznaczność opisu, numerowanie funkcji- Na każdym poziomie ten sam poziom szczegółowości- Kompletność dekompozycji (hierarchia)- Kolejność funkcji nie ma znaczenia- Funkcji i pozycji użytkownika- Podejście top – down (definiujemy od największego obszaru)Formularz opisu funkcji:Opis Umożliwia edycję danych klientaDane wejściowe N + I + PESEL +Źródło danych Dowód osób, paszport....Wynik Zapis w BDUwagiWymagania niefunkcjonalne:- Dodatkowe wymagania i ograniczenia- Wynikają z wymagań użytkownika- Weryfikowalność wymagańo Liczebniki a nie przymiotnikio Uzasadnienie (koszt)- Określenie wymagań jest początkiem budowy, jednocześnie przygotowaniem do testowania- Dokładność i jednoznaczność określeń- Formalizacja i podejście metodyczne jest gro sukcesu- Zawsze nazywać systemy informatycznePlan:- System informatyczny a rzeczywisty- Model konceptualny implementacyjny- Metodyki modelowania SI- Diagramy przepływu danych (DFD)- Diagramy związków encjiModel systemu informatycznego:- Model myślowy SI – Projekt – Model konceptualny logiczny – Projekt – Model implementacyjny- Analiza rzeczywista, abstrakcja w pojęciach problemowychJak system ma działać:- Rezultat: konceptualny – logiczny- Techniki modelowania SIo Strukturalne (diagramy przepływu danych) – DFD i diagramy związków encji ERD)o Obiektowe (diagramy klas i obiektów, diagramy interakcji i przejść stanów)Metodyki strukturalne (ustrukturyzowane)- Łączą opis statyczny danych i statyczny opis procesów- Metodyki strukturalneElementy danych:- X – dowolny znak (np. XXX, X(12))- S – cyfra, w tym i znak (np. 9999,9(11))- . – przecinek dziesiętny (np. 9999.99)- RRMMDD – format datyData zakupu = * data DDMMRRRR *Numer faktury = * unikalny numer w formacie: SSSS/MM/RR *Opis zawartości dokumentu:- Metoda zastępująca (top – down): podział na kolekcję z opisem poszczególnych kolekcji- Nie definiować co już zdefiniowane, np.:o Adres = kod_poczty + Miasto + Ulica + Numero Adres_dostawcy = Adreso Adres_odbiorcy = Adres- Nie definiować szaty graficznej, a tylko dane- Poprawnie i szczegółowo opisywać elementy danychTechniki strukturalne:- Model procesów – diagramy przepływu danych (DFD – Data Flow Diagram)- Model relacji – (ERD – Entity Relationship Diagram)- Model zdarzeń zachodzących w SI – diagramy życia obiektu (ECH – Entity Life History)- Model zmiany stanów systemu – diagramy stanów (STD – State Transation Diagram)- Schematy struktury aplikacji (STC)- Słownik danych (Data Dictionary)- Strukturalny Angielski (Structured English) – strukturalny polskiMetodyki obiektowe:- Metodyki obiektowe wykorzystują pojęcia obiektowości dla celów modelowania konceptualnego oraz projektowania systemów informatycznych- Techniki:o Diagramy obiektówo Diagramy dynamiczneo Diagramy funkcjonalneo Angielski używa (USC Cases)Diagram obiektów:- Wariant notacyjny i rozszerzenie diagramów ERDDiagram obiektów zawiera:- klasy, w ramach klas specyfikacji atrybutówMetodyki strukturalne:- Uważa się, że wadą metodyk strukturalnych są trudności w zintegrowaniu modeli- Metodyki strukturalne nie przystają do obiektowej implementacji SI- Metodyki strukturalne są dojrzałe, ale mogą nie być adekwatne do współczesnych tendencji produkcji SIModelowanie procesów:- Diagramy przepływu danych DFD – Data Flow Diagram- Strukturalna specyfikacja funkcji systemu (mapa procesów)- Identyfikacja zależności między procesami danymi- Precyzyjne określenie zakresu systemu, podsystemów i modułów- Zwięzły i czytelny opis funkcji systemu (łatwy do opanowania przez użytkowników, weryfikowalny)- Redukcja redundancji funkcjonalnej systemuDFD – elementy składowe:- Obiekt zewnętrzny – obiekt (lub grupa obiektów) nie należą do systemu, z którym system wymienia informacje (źródło / odbiorca danych dla / z systemu) – terminator, interfejs- Proces – element systemu przetwarzającego wejściowy strumień danych na wyjściowy lub tworzących dane wyjściowe na podstawie danych wejściowych- Magazyn danych – element systemu umożliwiający gromadzenie danych i przechowywanie danych- Przepływ danychDFD – symbole graficzneSSADM – Structured System Analysed and Design Method- Diagram kontekstowy – granice systemu- Diagram systemowy – DFD0 – diagram ogólny systemu (podsystemy + główne magazyny)- Diagram procesów – DFB – rozwinięcie poszczególnych podsystemów aż po procesy elementarne (niepodzielne)- Specyfikacja procesów elementarnych – FPD – specyfikacja, opis elementarnego algorytmuDFD – strumienie, magazyny i ich charakterystyki:- Na DFD nie definiuje się sposobu, w jaki obiekt zewnętrzny dostarcza lub pobiera dane- Magazyn jest elementem programu (nie wymusza obiegu danych) i może mieć złożoną strukturę- Procesy powinny być wzajemnie niezależne- DFD nie wyrażają zależności przyczyn – obiektów czasowo pomiędzy procesami- Nazwy i numery – każdy element na DFD ma swój unikalny identyfikator (adekwatny do elementu: nie proces 1, a np. weryfikacja poprawności dokumentów)- Przejrzystość i możliwość analizy – ilość procesów na diagramie- Czarne dziury – procesy pochłaniające informacje- Źródła danych – procesy bez wejść, a z wyjściami (generują dane z niczego, jak generator liczb losowych)- Puchnące magazyny – pochłaniający dane- Stałe magazyny – tylko pobiera z nich dane- Błędne przepływy:o Magazyn – Magazyno Obiekt zewnętrzny – MagazynDFD – bilansowanie:- Bilans poziomy (procesów i magazynów)- Bilans pionowy – suma (zawartości) przepływów danych wpływających do procesu jest równa sumie przepływów wpływających do różnych procesów na DFDDFD – struktura procesu:- Algorytmiczna definicja procesu- Dowodność formułowania, ale zwykle numer i nazwa procesu, dane WE i WY i opis- Opis algorytmów: słowny, pseudokod, makropolecenia, SQL, polecenia 4GL, tablice decyzyjnePodusmowanie:- Projekt to tworzenie modeli w przyszłym systemie- Metodyki strukturalne są dobrze zdefiniowane i sprawdzone- Modelowanie procesów zachodzących w SI- Hierarchia dekompozycji upraszcza, a jednocześnie umożliwia szczegółowy opisWywiad z właścicielem SI Szybki BillWłaściciel wypożyczalni rowerowej Szybki Bill potrzebuje systemu informatycznego, który zautomatyzuje mu obszar ewidencji wypożyczalni rowerowej z przygotowaniem danych do posiadania programu. F-K oraz gospodarstwo rowerowe. Każda wypożyczalnia powinna być odnotowana w systemie w sposób umożliwiający naliczenie opłat jak też dokładnej identyfikacji osoby wypożyczającej. Wypożyczalnia ma sporo stałych klientów. Prowadzi do nich system rezerw rowerowych. Rowery się psują i wymagają napraw w warsztacie samochodowym.Specyfikacja – wprowadzanie SI Szybki Bill- Cel: automatyzacja obsługi procesu ewidencji rowerów, rezerwacji, wyposażenia, naliczania opłat- Zakres:o Gospodarstwo rowerowe (ewidencja, remonty, złomowanie)o Ewidencja klientów i wypożyczalnio Rozliczenie wypożyczalnio Rezerwacja rowerów (przyjęcie rezerwacji, rezygnacji)o Cenniko Zestawienie wynikowe- Kontekst systemu, SI Szybki Bill ma współpracować z istniejącym systemem F-K i działać na istniejącym sprzęcieWymagania funkcjonalne SI Szybki Bill- SI Szybki Bill ma być zaimplementowany przy pomocy MS Access 2000 na komputerze z MS Windows 2000- Do szybkiej identyfikacji rowerów mają być użyte naklejki i czytnik kodu kreskowego- Musi istnieć możliwość obsługi przy pomocy myszy, klawiatury i / lub ekranu dotykowego- Wymiana z F-K ma się odbywać przy pomocy pliku tekstowego w formacie opisanym w dokumentacji systemu F-K- System ma mieć możliwość obsługi w języku polskim, angielskim z przełączaniem w locieLp. Zdarzenie Obiekt Uwagi1. Dostawa roweru Dostawca 2. Wypożyczenie roweru Klient, pracownik 3. Zwrot roweru Pracownik, F-K 4. Brak zwrotu roweru Pracownik, Policja 5. Zepsucie się roweru Pracownik, warsztat 6. Zmiana cennika Właściciel 7. Raport o wypożyczenie Właściciel 8. Rower naprawa Pracownik 9. Rezerwacja roweru Klient 10. Rezygnacja z rezerwacji Klient 11. Złomowanie roweru Pracownik SI Szybki Bill:1. Gospodarstwo rowerowe1.1.Ewidencja rowerów1.2.Złomowanie1.3.Edycja słow. Typ.2. Ewidencja wypożyczalni2.1.Ewidencja danych klientów2.2.Obsługa rezerwacji2.2.1.Rezerwacja2.2.2.Rezygnacja2.2.3.Zestawienie rezerwacji2.3.Wydruk oferty2.4.Ewidencja wypożyczenia2.5.Ewidencja zwrotu2.6.Sytuacja nadzwyczajna3. Wspomaganie3.1.Edycja3.2.Raporty3.3.Eksport danychOpis funkcji 2.1Nazwa funkcji 2.1. Ewidencja danych klienta.Opis Funkcja umożliwia wprowadzenie i edycję danych o kliencie.Dane wejściowe Nazwisko + Imię + PESEL + Adres + Numer + Typ dokumentuŹródło danych Dowód osobisty, prawo jazdy lub paszportWynik Zapis w bazie danych klientówUwagi Klient uzyskujeDane w programie:- Dane w wewnętrznym programie (we/wy, wykorzystanie przez jednego użytkownika i w trakcie pojedyncz., nietrwałe, niedostępne dla wielu użytkownikówDane – potrzeby aplikacji:- Dużo odczytu- Dane wspólne dlao Wielu programówo Wielu użytkowników tego samego programu- Trwałość danych: długi czas życiaDane w plikach – problemy:- Współdzielenie danych – efektywne i konflikty- Rozw. (warstwa pośrednia) System Zarządzania Danych – SZBDCo to jest BD?- Zorganizowany zbiór danych przechowywany w zewnętrznej pamięci komputera- Odzwierciedlenie fragmentu rzeczywistości- Cechy:o Trwałośćo Zgodność z rzeczywistościąZnaczenie: wiek pracownika:- część implementacyjna: schemat BD, definicja struktur i zasad poprawności- część ekstencjonalna: same dane, zawartość faktograficznaPrzetwarzanie rozproszone:- Przezroczystość dla klienta- Szybkość- Wielkość BD- Niezawodność- Problemy: łączność, transakcyjność, integralnośćModel implementacyjny – typy:- Hierarchiczny- Sieciowy- Kartotekowy- Relacyjny- Obiektowo – relacyjny- Obiektowy- HypertekstModel relacyjny – historia:- Lata 70: IBM, INERES (Uniwersytet Kalifornijski w Berkeley)- Lata 80o Mainframe: DB2, Oracleo Minikomputery (Unix), Informix, Sybrse, Progreso Mikrokomputery: dBase, FoxPro, Clipper, Parradox, R: BASE- Lata 90o Dowsizing dużych systemówo MikrokomputeryL MS SQL, ServerRDB – pojęcia podstawowe:- Tablica, plik- Atrybut, pole, kolumna- Rekord, wiersz tablicy- Typ danych- Domena, dziedzina- Wartość null- Związki wartościowe (preferencje)RDB – zasady:- Każda tablica w BD ma jednoznaczną nazwę- Każde pole (kolumna) ma jednoznaczną nazwę w tablicy- Wszystkie wartości w kolumnie są tego samego typu- Porządek kolumn i wierszy nie jest istotny- Każdy wiersz musi być różny (wartościowo)- Pola muszą zawierać wartości atomoweKlucze:- Klucz główny (Primary Key) – grupa kolumn o nie powtarzająych się danych- Klucz obcy (Foreign Key) – grupa kolumn z jednej tablicy, których wartości odpowiadają kluczowi głównemu innej tablicy (powiązanie)Integralność:- Poziom pól (dziedzina wartości)- Poziom tablic (klucz główny)- Integralność referencyjna:o Obowiązkowość związkuo Ograniczone usuwanieo Usuwanie kaskadoweo Wstawianie null- Integralność dynamicznaPorządkowanie wierszy:- Wiersz w tablicach – porządek historyczny- Znaczenie dla interfejsu- Fizyczne sortowanie – bardzo pracochłonna operacja z wykorzystaniem roboczych indeksowych, operacja dynamicznaDostęp do danych:- Sekwencyjny (rekordy w pliku, który musi być przeglądany od początku)- Bezpośredni (możliwość natychmiastowego odnalezienia potrzebnego rekordu w pliku)- Indeksowany (wykorzystując tablicę – indeks do odszukania miejsca przechowywania rekordu)Transakcje na BD:Ř Zmiana stanu bd Ř Logiczna jednostka pracy w BDŘ W trakcie trwania transakcji – BD nie jest spójna (nazywa się integralność)Ř Właściwości transakcji (niepodzielność spójność , izolacja i trwałość)Ř Blokowanie – podstawa realizacji transakcji w środowisku współbieżnymTransakcja a awaryjność w BD:Ř Transakcje zatwierdzone – mają być odtworzoneŘ Transakcje nie zatwierdzone - wycofaneŘ Metoda osiągnięciao Dzienniki transakcjio Redundancja4 GL:Ř Język czwartej generacji oparty na formularzachŘ ProceduralneŘ SQL – podzbiórŘ Języko ORACLE PL/SQLo Progress 4 GLMapowanie modelu konceptualnego na implementacyjny:Ř Konceptualny na implementacyjny model danychŘ Konceptualny (niezależny od SZBD, język programowania modelu bazy danych) – ERDŘ Implementacyjny – fizyczny(w konkretnym modelu bazy danych i SZBD)Ř Model implementacyjny służy do wygenerowania skryptu do tworzenia BD wraz z więzami integralności (słownik BD)Pojecie relacyjnego modelu implementacji:Ř Tabela (odpowiednik encji, nazwa l mnoga)Ř Kolumna - pole (odpowiednik atrybutu)Ř Dziedzina (konkretny typ danych i jego parametry)Ř Rekord (wystąpienie)Ř Klucz główny (indeks unikalny, klucze sztuczne)Ř Klucz obcy (indeks nieunikalny)Ř Odniesienie - (klucz główny, obcy, więzy integralności, referencyjny)Ř Klucz alternatywny - (indeks unikalny lub nie)Inne elementy modelu implementacji:· Atrybuty rozszerzone (nie SQL owe) – specyficzny dla danych SZBD:o Dodatkowe typy, opisy, etykiety, elementy, wyświetlane na ekranie (komunikaty, helpy)o Wartości domyślneo Rozróżnialność (lub nie) wielkości znakówo Procedury walidacyjne (trigery)o Typ indeksu (np. słowny), opis, sposób konstrukcji indeksuo SekwencyjneTworzenie modelu implementacji:Ř Generowanie modelu konceptualnego (mapownie modelu konceptualnego na implementacyjny)Ř rewers ze schematami istniejącymi w BDŘ różne wersje modelu implementacyjnegoProblem mapowania:Ř nazewnictwo(identyfikatory, nazwy typów, dziedziny)Ř ograniczenia ilościowe (np. .na liczbę pól w rekordzie)Ř brak wielowartowości pól (plaski model)Ř brak zmiennej struktury rekordu (wiersza)Mapowanie prosteŘ encjaŢtabelaŘ atrybutŢpole (kolumna)Ř unikalny identyfikator=>klucz głównyŘ związkiŢ klucze obce(dodawane do encji)np.ERD z atrybutamiTabele relacyjnej BDMapowanie złożone:Ř mapowanie złożone nieoczywiste (związki wielu encji)Ř mapowanie na pojedynczą tabelę (kodowane)Ř mapowanie na oddzielną tabelęŘ mapowanie związków wykluczających sięKlucze:Ř każda encja może mieć wiele unikalnych identyfikatorów – są to klucze kandydująceŘ spośród kluczy kandydujących wybiera się głównyŘ jeżeli brak klucza kandydującego tworzy się klucz sztuczny (generowany automatycznie)Wybór klucza zlecenia:Ř klucz główny powinien być atrybutem jak najkrótszymŘ klucz główny nie powinien mieć znaczenia dziedzinie przedmiotowej (nawet małe zmiany w dziedzinie biznesu spowodują istotne zmiany w BD)Ř klucz główny raczej powinien być generowany automatycznie (Re, JD, OJD)Ilościowe aspekty danych:Ř informacje charakterystycznych ilości danycho zajętość pamięci(liczba wystąpień w BD)o zmienność (prognozowany przyrost w czasie)o wypełnienie pól wartościamiŘ informacje charakteryzujące dostępo wymagana szybkość dostępuo zakres przetwarzań (najczęściej wykorzystywane atrybuty)Słownik danych DATA DICTIONARY:Ř słownik danych zawiera opis wartości , przepływów danych i encjiŘ szczegóły związków pomiędzy encjamiŘ opis struktury danych:o dane elementarne i ich typyo operatory – symbole (notacje BNF)Ř automatyczny generator słownika (BD, sekwencje SQL)Podsumowanie:Ř model danych jest podstawą do ich przetwarzaniaŘ technika ERD pozwala budować modele konceptualneŘ systemy baz danych w większości przypadków wykorzystują model relacyjnyŘ istnieje możliwość mapowania ERD na model relacyjnyPrzykład:Ř Modelowanie danych na podstawie wymagań użytkownikaŘ Model konceptualnyŘ Modyfikacje modeluŘ Model implementacyjny - samodzielnieRzeczywiste obiekty organizacyjne – encjeMetodyka:1. Wydzielenie encji ich atrybutów kluczowychŘ Opiekun Ţ identyfikator opiekunaŘ Zwierzę Ţ id zwierzęciaŘ Klatka Ţ nr klatki Ř Pożywienie Ţ indeks materiałowyŘ Racja żywnościowa Ţ numer racjiŘ Dostawca Ţ NIPŘ Dostawa Ţ numer dostawy2. Tablica krzyżowa (związki bezpośrednie między encjami):Ř Opiekun Ţ zwierzęcieŘ Zwierzę ŢkaltkaŘ Zwierzę Ţracja żywnościowaŘ Pożywienie ŢdostawaŘ Dostawca Ţdostawa3. Diagram ERD z tabeli krzyżowej:Modyfikacja – samodzielne:- Wprowadzanie pojęcia jadłospis (ustalono zbiór pożywienia, wielokrotne wykorzystanie i identyfikacja)- Wprowadzenie tożsamości przypisania zwierzęcia do gatunku, grupa itd.- Wprowadzenie słownika, jednostek miar, trybu zatrudnienia pracowników, klasyfikacja dostawców na grupyModel konceptualny:Ř Diagramy historii życia encjiŘ Diagramy zmian stanówŘ Diagramy strukturalneŘ Pozostałe elementy projektu SIAspekty modelowania SI:Ř Funkcjonalny (DFD, hierarchiczny model funkcji)Ř Co zachodzi w systemieŘ Danych(ERD/LDS, obiektowy)Ř Dynamiki (ELH, STD) – kiedy zachodzi sterowanieDiagram historii życia encji (ELH):Ř Odwzorowanie zmian stanów obiektów (encji)Ř Oddziaływanie zdarzeń z diagramem DFD na encje ERDŘ Dynamiczny aspekt istnienia obiektu w systemieŘ Modelowanie log. pojedynczej encji (obiektu) Ř Chronologia zdarzeń mających wpływ na encjeŘ Umożliwia identyfikacje wszystkich zdarzeń związanych z encjąŘ Umożliwia zdefiniowanie wszystkich błędnych sytuacji oraz zdarzeń wyjątkowychELH – elementy składowe:- Obiekt – wybrany obiekt (encja) z ERD- Zdarzenie sekwencyjne – pojedynczy element zdarzenie związane z obiektem- Zdarzenie złożone – możliwość rozłożenia na prostsze- Zdarzenie powtarzalne – więcej niż jeden raz zachodzi- Zdarzenie selektywne – (if) spełnienie pewnych warunkówDiagram historii życia obiektu – etapy budowy:Ř Etap1 przygotowawczyo Wybranie obiektu z ERDo Identyfikacja zdarzeń dotyczących danego obiektu na podstawie DFD o Dodatkowe rozważenia funkcji (bo można było coś pominąć)Ř Etap 2 – dla każdego obiektu z ERDo Normalny cykl życia obiektuo Zdarzenie specjalne (wyjątkowe)o Sytuacje błędneKolejność budowy1. wybór zdarzeń odziaływujących na obiekt2. ustalenie sekwencji zdarzeń3. sprawdzenie, czy pewne zdarzenia mogą zachodzić warunkowo (selektywnie)4. sprawdzenie czy pewne zdarzenia mogą powtarzać się wielokrotnie5. sprawdzenie i ewentualna korekta sekwencji zdarzeń pod wpływem iteracjiELH – identyfikacja sytuacji wyjątkowych i weryfikacji:o gdzie mogą wystąpić sytuacje wyjątkowe?o Czy i w jaki sposób są one rejestrowane w systemieo Jakie są efekty uboczne sytuacji wyjątkowej (tj. zdarzenia realizowane w systemie)o Weryfikacja ELH względem DFD: dla konkretnego zdarzenia na ELH musi istnieć co najmniej jeden przepływ na DFD mu odpowiadającyModelowanie zależności przyczynowych i czasowych:Diagram zmian stanów STD (State Transmition Diagram):o Uzupełnienie DFD o zależności czasoweo Szczególnie ważne dla systemów czasu rzeczywistego, ale też dla systemów rozproszonych rejestracji i produkcji, rezerwacji miejsc itp.o Identyfikacja zdarzeń w systemie i ich zależność przyczynowo-skutkowychSTD – elementy składowe:- STAN – zbiór określających wartości atrybutów systemu w danym momencie czasu- PRZEJŚCIE – zmiana stanu systemu, tj. jego przejście z jednego stanu do drugiego, w wyniku zajścia określonego Warunku (C: Condition i wykonania akcji – A: Action)- SPRZĘG – sprzęg wejścia – wyjścia określającego przejście do/z stanu na innym diagramie (w szczególności stan początkowy i końcowy sytemu).Zasady sporządzania STD:o System musi się zawsze znajdować w jakimś stanieo Sprzęgi wejściowe (START) i wyjście (STOP) – tylko jedneo Każdy stan systemu musi być dostępny ze stanu początkowegoo Stan końcowy powinien być dostępny dla każdego stanuo Dany warunek powinien powodować przejście z każdego stanu do jednego innego stanu (jednoznaczność przejścia)Diagramy strukturalne STC (Structured Charts):o Cel – modelowanie przepływu danych, parametrów i sterowań pomiędzy modułami kodu aplikacjio Struktura hierarchiczna: moduł nadrzędny (wywołujący) – moduł podrzędny (wywoływany)o Budowa: przekształcenie diagramów DFD w STCCharakterystyki podziału na moduły:o Spójność (niezależność)o Stopień powiązań międzymodułowych (dąży się by był on jak najmniejszy)o Rozmiar modułu (np. jedna strona kodu)o Zakres sterowania (złożoność , wywołanie nie więcej niż 9 modułów)o Jednorodność (zakres funkcjonalny)Optymalizacja:q Projektuo Strukturao Typ danycho Procesyq Implementacji o Algorytmika (krytyczne miejsca)o Fizyczne rozmieszczenie danycho Strojenia SZBDZasada efektywności !!Tylko 10 % kodu ma istotny wpływ na efektywność SIBilansowanie modeluq Różne przekroje modelu - projektu SI:o Funkcjonalny (procesowy) - DFD,STCo Informacyjny (danych) – ERD (LDS)o Zdarzeniowy (stanów) – ELH, STDq Problem: obiekty i nazewnictwo, struktura , zawartość, oznaczeniaq Cel: utrzymanie spójności projektu i usunięcie błędówDostosowanie implementacji do ograniczeń i uwarunkowań:q Rozmiary danych(bieżące, przyrost – ok. 10 % rocznie)q Czas odpowiedni (określenie, różne typy wejść)q Ograniczenie pozamerytoryczne (dostawca sprzętu, SZBD, zużywane zasoby)q Niezawodność (średni czas między awariami - MTBF, średni czas naprawy MTTR)q BezpieczeństwoProjektowanie szczegółowe:q Kodowanie informacjiq Interfejs użytkownikaq Formaty dokumentów we/wyq Urządzenia we/wyq Struktura techniczna i przestrzennaq Problemy eksploatacji (autoryzacja dostępu)q Elementy projektu poziomu fizycznego aplikacjiKodowanie danych - istota i cele:q Istota:o zastąpienia danych przez inne, zwykle ustruktualizowane i określonej notacjiq Cele:o Uproszczenie i skracanie wprowadzania danycho Zmniejszenie ryzyka błędów i pomyłeko Przeciwdziałanie redundancjio Uproszczenie i przyspieszenie przetwarzańRodzaje kodów:q Zewnętrzne: (pesel , nip ,kod pocztowy)q Wewnętrzne: (Id_pracownika, nr + czesci,kod operacji)q Dla celów projektu (we/wy, moduły, oznaczenia)Właściwości metod kodowania:q Rozszerzalnośćq Kompletnośćq Precyzja, jednoznacznośćq Zwięzłośćq Czytelnośćq Wygoda użyciaq Użyteczność (zgodność z istniejącym)Kod, a maska:q Kod - znacząca (zmienna, niosąca informacje) cześćq Maska – sposób wyświetlania (format), cześć stała nie przechowywana jako dana w BD, a jedynie w słowniku BDTyp kodów:q Porządkowy (nr kolejny, np. 123)q Klasyfikacyjny (pozycyjny np12.56.01)q Mieszany (np. lu\\02\\0089)q Kody z cyfrą kontrolną (np. pesel)q Kody mnemoniczne (np. NY, WAR)q Kody alfabetyczne, numeryczne i mieszaneDefinicja struktury kodu:INF/01/0234 Nr kolejny numer roku (RR) kod kierunku :ZP, AG INF Inne kody z cyframi kontrolnymiq ISBNK – uzupełnienie do podzielności przez 11Zalety cyfr kontrolnych:- wychwytywanie błędów w kodach bez konieczności odwoływania się do BD z zestawem kodów – pierwotna kontrola danych (prawdopodobieństwo 99,5%)- wykrycie nieprawidłowo zdefiniowanego kodu na etapie jego tworzeniaKody i symbole w projekcie:- standardowe oznaczenia (skróty) stosowane w projekcie:o format daty, godziny (np.: standard – rr.mm.dd)o opis pól rekordów: opis struktur pól w bazach danych, projektach we/wy (zwykle zgodny z symboliką SZBD)o symbole i oznaczenia obiektów (wydruków, ekranów, podsystemów itp.) – np.: RMUAOznaczenia obiektów projektu:- nr/symbol opcji w układzie menu- kod podsystemu / modułu- symbol tabulogramu- symbol dokumentu we/wy- symbol / nazwa zbioru/plikuInterfejs użytkownika:- SI składa się z dwóch części:o Realizująca funkcje użytkoweo Realizująca dialog z użytkownikiem- Komunikacja użytkownik – system informatyczny:o Sterowanie SI (polecenia)o Przepływ danych użytkownik – system- Typy: znakowy, graficzny(50-90% kosztów)- Urządzenia we/wySterownie SI - sposoby:- polecenia (linia komend)- klawisze sterujące (skróty)- opcje z menu- ikony (paski narzędziowe)- przyciski dialogu- działania myszą (i innymi urządzeniami wskazującymi)Poziomy użytkownika:- początkujący (wstępne wyjaśnienia, dodatkowe pomocniki, pomoc kontekstowa, blokowanie)- średnio-zaawansowany (największa grupa, standard interfejsu, pomoc szczegółowa, indeks)- ekspert (skróty, szybkość dostępu, indywidializajca interfejsu)Układ menu:- projektowanie (odzwierciedlenie struktury)- kolejność rozmieszczenia opcji- dublowanie opcji- język (słownictwo)Przepływ danych:- wejściowych (wprowadzanie):o parametry poleceńo odpowiedzi na pytania (zaproszenia) SIo dialog- wyjściowych:o wyświetlenie informacji w dialoguo raportyo graficzna prezentacja danychPoprawny interfejs:- spójny (topologia, słownictwo, otoczenie)- prosta obsługa, ilość obiektów (5-9 obiektów)- grupowanie (opcji, działań, kolejność/częstość)- możliwość skrótów w dostępie do funkcji (doświadczony użytkownik)- informacja o działaniach (potwierdzanie, aktualność)- odwoływanie akcji- poczucie spełnienia (drobne kroki, informacja)- wrażenie kontroli nad SIReguła Millera:- 7 ± 2- człowiek może się jednocześnie skupić się na 5 do 9 elementach:o liczba opcjio liczba pól dialogowycho liczba przyciskówo liczba kolumn z liczbami, wykresów itp.Przyjazność SI (user friendly):- stopniowe przekazywanie informacji, ukrywanie złożoność systemu- informowanie użytkownika o wszelkich działaniach systemu (potwierdzanie wprowadzonych informacji, zapytania, komunikaty)- wybieranie i wskazywanie zamiast pamiętania i pisania- duży stopień ochrony przed błędami użytkownika- ekran – drukarka- system podpowiedzi i pomocy (help) dla użytkownika wywoływany na jego życzenie- wygoda w użytkowaniu ergonomiczność systemu, właściwa organizacja, ekran (np.: taka organizacja pracy systemu, by ruchy oczu były minimalne)Inne elementy przyjazności:- podział ekranu na stałe strefy- jednolitość komunikatów i znaczeń klawiszy, przycisków, konsekwencja, zgodność z oczekiwaniami- zróżnicowanie sposobów wyświetlania informacji i komunikatów, adekwatność do statusu- kolejność wprowadzania danych na ekranach wejściowych, grupowanieCele przyjazności SI:- ograniczenie ilości pomyłek- minimalizacja czasu i wysiłku uczenia się- nie obciążanie pamięci krótkookresowej użytkownikaArchitektury interfejsu graficznego:- SDI (Single Document Interface) interfejs z jednym oknem obsługującym konkretną funkcę (okna dialogowe) komunikacja przy pomocy ikon- MDI (Multiple Document Interface) interfejs z jednym oknem głównym, w którym otwierane są kolejne okna – komutacje przy pomocy układu menu- Mieszane – łączenie ikon z oknem użytkownikaOkna dialogowe:- dezaktywizują aplikację i wymuszają obsługę- przyciski powrotu do aplikacji (przynajmniej jeden)- przy złożonych zakładkachWspomaganie budowy interfejsu - istotne dla GUI:- interaktywne projektowanie diagramu (okna, menu, ikony, przyciski z wykorzystaniem zestawów gotowych elementów)- definiowanie reakcji- symulacja pracy interfejsu (prototypowanie)- generowanie kodu (z możliwością wyboru środowiska)Problemy internacjonalizacji:- tłumaczenie na inny język - problem: stylu, miejsca na ekranie- zmienność kulturowa i prawna - problem: sortowania, daty, waluty, symboli, prawa- niuanse kulturowe – problem: kolor, kształt, klucz, znaki, kierunki odczytu, pozycje ręki, stopyProblemy językowe – unikaj:- gry słów (B2B)- metafor (Home Dom)- skomplikowanego słownictwa- zbyt długich nazw- tekstów wewnątrz rysunków (trudno zmienić)Struktury danych:- cyfry, pozycje, wielkość, zaokrąglenia- data,. Godzina, rok kalendarzowy- tytuł, kolejność nazwiska/imienia- wielkość strony = jednostki papieru- symbole kolorówUrządzenia realizacji interfejsu użytkownika:- WE: czytniki kart kodowy (perforowane, magnetyczne, optyczne); nośniki magnetyczne i optyczne; terminale (klawiatura); urządzenia wskazujące (mysz, pióro, dotyk); teletransmisja; głos- WY: wydruki; terminale; karty kodowe; plotery, naświetlarki; teletransmisja; głosProjektowanie formularzy:- tytuł- instrukcja- treśćProjektowanie – punkt wyjścia:- typ formularza- urządzenia techniczne- sposób wypełnienia (ręczne, maszynowo, komputerowo itd.)- kształt znaków, kolory, wzorce itp- pismo blokowe – skanowanie, technologia rozpoznawania literTypy formularzy:- pojedyncze kartki- książeczki (oprawione)- rozdzielone (wiek kopii)- wysyłkowe (w kopertach)· WYJŚCIOWE (druk w całości, nadruk, masowość, wiele kopii)· WEJŚCIOWE (ręcznie i maszynowo wypełnione, odczyt OCR)Obieg formularza:Wyspowość informatyczna – te same dane w różnych systemach informatycznychIdentyfikacja czynności manualnych:- przygotowanie danych do wprowadzania (np.: wcześniej przygotowanych dokumentów)- wykorzystanie rezultatów- przetwarzanie ręczne (rzeczy rzadko powtarzają się)- zwiększenie niezawodności czynności manualnych:o kodowanie (z cyfrą kontrolną)o nadmiarowość (np.: 2 dane)o kontrola logiczna (np.: data śmierci z daty urodzenia)o kontrola kolejności (jedna data przed drugą)Inne elementy projektu szczegółowego:- projekt struktury technicznej- struktura przestrzenna (użytkownik, sprzęt, moduły)- struktura oprogramowania (systemowe, narzędziowe, wspomagające)- projekt elementów eksploatacji (prawa dostępu, zabezpieczenia danych)- procedury bezpieczeństwaDokument – projekt SI:- wprowadzenie (przedmiot opracowania, nazwa systemu, cel, zakres i kontekst systemu, odwołanie się do specyfikacji wymagań SI)- projekt struktury funkcjonalnej systemu:o diagram systemowy (DFD0)o diagram DFD poszczególnych procesówo specyfikacje procesów prostych (algorytmy)- projekt struktury informacyjnej SI:o kody, symbole, oznaczeniao model danych konceptualny i implementacyjnyo specyfikacja i projekt informacji wyjściowych oraz wejściowycho projekt diagramu z użytkownikiem (układ menu, formatek, okna, klawisze itp.)- struktura techniczno - przestrzenna systemuPodsumowanie:- projektowanie dodatkowych elementów systemu informatycznego jest ważne- projekt kodów interfejsu, formularzy itd., jeśli jest integralną częścią projektu szczegółowego systemu- pytanie: jak nie zaprojektujemy to jak nie wykonamy?Kodowanie aplikacji:- język wysokiego poziomu (4GL, SQL)- programowanie komponentowe i wizualne- narzędzia RAD (Rapid Application Development)- generatory kodu- wykorzystanie języków proceduralnych i obiektowych (C++, Object Pascal, Java)Jakość kodowania - istota:- oczekiwania klientów- duży koszt wykonania programu (ekonomiczny, zdrowie, życie)- kompromis pomiędzy wydajnością a niezawodnościąJakość kodu – parametry:- poprawność- wydajność (szybkość wykonania)- efektywność (złożoność czasowa)- przenośność (możliwość przeniesienia na różne procesory)- konserwacja (rozwój kodu modyfikacja)- dokumentowanie – komentarze- prostota i jedność stylu (nazw zmiennych)Niebezpieczne techniki:- GO TO (lub inne o podobnym działaniu EXIT, HALT, BREAK itp.)- Programowanie trickowe (szybsze działanie, efektywność) – stosowanie funkcji nie udokumentowanych, odwołanie się do przerwań itp.- Skończoność dokładności obliczeń.- Rekurencje.- Wykorzystanie procesów równoległych i przerwań.- Złożone wyrażenia – priorytety.- Wykorzystanie współdzielonych zasobów (danych urządzeń itp.)Jakość kodowania – czynniki:- zasada ograniczonego dostępu – unikanie deklaracji zmiennych globalnych i dostępu do nadmiarowej ilości obiektów z modułów- kompilacja – zgodność typów różnych obiektów, należy używać kompilatorów sprawdzających zgodność typów (problem z językami implementacyjnymi Java, SQL)Błędy:- błąd (error, failure) – niepoprawna konstrukcja w SI, która może doprowadzać do niewłaściwego działania)- konsekwencją błędu jest błędne wykonanie. - Każdy program ma błąd – tylko nie wiemy. - Błędy w oprogramowaniu są od początku – nie powstają w trakcie eksploatacji.Błędy w SI - typy:- błędy krytyczne vs niekrytyczne- uciążliwe vs kosmetyczne- losowe vs stabilne- narastające- funkcjonalne vs obliczeniowe- wyjątkoweTolerancja błędów:- właściwość SI poprawnego działania po wystąpieniu błędu- wymagania tolerancji:o wykrycie błędu przez programo wyjście z błędu (zakończenie pracy modułu z błędem)o ewentualna naprawa błęduTechniki uzyskania tolerancji:- weryfikacja warunków integralności danych (warunki sprawdzone przez inne moduły czy metody)- porównywanie wyników wielu wersji oprogramowania, wyciąganie średnich, odrzucanieTestowanie SI:- Wykrycie i usunięcie błędów i błędnych wykonań => wykrywanie błędów- Ocena niezawodności systemu => testy statystyczneDwa typy testowania:- Atestowanie (walidacja) – zgodność z wymaganiami użytkowników- Weryfikacja – zgodność z dokumentacją (np.: specyfikacją systemu)Czarna i biała skrzynka:- testy na zasadzie białej skrzynki wykorzystują informację o programie do konstrukcji testów (danych testowych, analizy kodu) – nie pozwalają odkryć błędów funkcjonalnych- testy na zasadzie czarnej skrzynki, traktuje się program jako obiekt o nieznanej konstrukcjiFazy testowania:- test modułów (test kodu i funkcji)- testy systemu (całość)- testy akceptacyjne (końcowa, użytkownik sprawdza zgodność ze specyfikacją wymagań)Sposoby testowania kodu:- statyczne (inspekcje kodu, inny zespół niż programiści tego kodu):o śledzenia wykonania na suchoo wyszukiwanie błędów- dynamiczne (wykonanie + analiza wyników)- dowód poprawności – obliczenia matematyczne (10 KLOC = 500K$) – kosztKryteria doboru danych w testach dynamicznych:- każda instrukcja powinna wykonać się przynajmniej jeden raz – pokrycie testem wszystkich instrukcji- pokrycie instrukcji warunkowych (w tym i wartości granicznych)- testy pętli – minimalna liczba iteracji (w tym i 0) oraz maksymalna ich liczbaTypowe zagrożenia – konstrukcje:- brak inicjacji wartości zmiennych- porównania zmiennoprzecinkowe (różne liczby na którym miejscu)- indeksy tablic- operacje na wskaźnikach- pętle (wyjście z pętli)- warunki (np.: < zamiast brak możliwości zrównoleglenia prac) – testowanie funkcji oddzielnie każdej.- Zstępujące (robienie aplikacji od góry, najpierw ogólna nazwa programu, później drobiazgi, funkcja) – konieczność opracowania zaślepek – trudność w testowniu nowego modułu- test pod obciążeniem – (stress testing) – Do jakiego czasu aplikacja pracuje poprawnie dokładając na nią obciążenie (objętość, new users, klienci, obciążenie sieci – efektywność)- test odporności – (na nadzwyczajne zdarzenia). Zasilanie, sprzęt, niepoprawne dane, odłączenie od sieci, wyciągnięcie wtyczki – jak się zachowuje po ponownym uruchomieniu.Dane testowe:- kryteria wyboru danych testowych:o testy pozytywne (dane + poprawne wyniki)o testy negatywne (błędne dane, brak danych)o testy funkcjonalne (funkcje programów)o testy strukturalne (testowanie wszystkich ścieżek w programie)- pochodzenie danych:o dane losoweo dane deterministyczneo dane rzeczywisteMiary niezawodności:- prawdopodobieństwo błędnego wykonania transakcji- częstotliwość występowania błędu (ilość błędów w jednostce czasu)- średni czas między błędami (MTBF) – storna techniczna dotyczy sprzętu- średni czas odtwarzania systemu po awarii- dostępność systemu (np.: 99% czasu przy 1% konserwacji – procent dostępności do systemu)Liczebność testów:- Arbitralne (czas, koszty) – ograniczone ze względu na czas i koszty wytworzenia systemu.- Szacowane w trakcie testowania (np.: koniec testowania w odpowiednich przestankach, np.: stwierdzenie że zostało tylko S błędów)Metoda posiewanie błędów:- wprowadzenie do aplikacji (N) błędów- testowanie (wykrywanie) przez testerów- szacunek liczby pozostałych błędówSianie błędów – uwagi:- posiane błędy powinny być tego samego rodzaju co poszukiwane- inny zespół sieje inny testuje- możliwość sprawdzenia efektywności metod testowania i jakości pracy testerówFaza testowania w praktyce:- testowanie zwykle jest przeplatane poprawianiem kodu (przez programistę np.)- poprawianie wprowadza błędy (ponownie należy sprawdzić od początku)Scalanie SI:- scalanie oprogramowania- scalanie oprogramowania ze sprzętem- scalanie oprogramowania z BD- konwersja starej (spadkowej) BD – problemy poprawności, aktualności, integralności, kompletności spadkowej BDDokumentowanie:- Odbiorcy: autor systemu (projekt systemu), użytkownicy, administratorzy SI- Przeznaczenie: dokumentowanie budowy SI – rozwój, pielęgnowanie; uczenie się użytkownika i administratora; pomoc w rozwiązywaniu problemów – instalacja, użytkowanie, administrowanieSkutek pakietów dokumentacji:- opis funkcjonalny (co system robi)- podręcznik użytkownika- kompletny opis (SI)- opis instalacji SI ( na różnych systemach operacyjnych, konfiguracja systemu operacyjnego – biblioteki, sprzętu)- podręcznik administratora systemu- słownik terminów- indeks (wyszukiwanie) – podręczniki elektroniczneJakość dokumentacji:- cel: jaki odbiorca (język)- struktura- standardy- sposób pisania