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 wymaganiami
o Ergonomiczność, łatwość użycia
o Niezawodność współdziałania
o Efektywność
o Łatwość ponownego użycia i konserwacji
o 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 otoczeniu
Zł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żliwia
o Opracowanie jednorodnych opisów (projektów) poszczególnych elementów
o Dostosowanie opisu do możliwości percepcji człowieka
- Obiekt – układ powiązanych ze sobą systemów


Zasada 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 elementami


Walka 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 SI


Podstawowy problem IO:

- Człowiek (analityk, projektant, programista, administrator) z jego uwarunkowaniami:
o Fizycznymi
o Mentalnymi
o 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 programowania

Modelowanie 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
- Notacje


Notacje w IO – rodzaje:

- Język naturalny
- Notacje graficzne
- Specyfikacje – ustrukturalizowany zapis tekstowy numeryczny


Szczegó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ć przejrzyste


Technika, 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 cel


Metodyka 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 faz



Typy metodyk:

- Strukturalna (model danych i przetwarzań – procesów)
- Obiektowe (model obiektów z danymi procesów)
- Mieszane


Metodyki – 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 notacje


CASE (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
- Konstrukcja
o Budowlana
o Instalacje
o Wykończenie


Rodzaje struktur SI:

Funkcjonalna – zakres tematyczny, cele, funkcje SI, podział systemu na podsystemy, moduły, funkcje i zadania

Informacyjna – dane WE i WY, zbiory danych w SI, algorytmy

Techniczna – środki techniczne, niezbędne do realizacji (konfiguracja, parametry, urządzenia we/wy)
Przestrzenna – rozmieszczenie obiektów SI

Oprogramowania – zbiór programów narzędziowych i czynniki określające struktury.


Struktura Czynniki i obiekty/ zewnętrze Czynniki subiektywne / wewnętrzne
Funkcjonalna - Cele systemu- Zakres działalności
Informacyjna - dostępne informacje wej.- potrzeby w informacji wyj. - struktura funkcjonalna- podział systemu- wew. zbiory danych
Techniczna - 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 systemu
Przestrzenna - lokalizacja przestrzenna SI- możliwości tech. – organiz. rozmieszczenia sprzętu- miejsce wprowadzania lub wykorzystywania informacji - struktura funkcjonalna- struktura techniczna
Oprogramowania - oprogramowanie narzędziowe (istnienie i dostępność- doświadczenie projektantów programu - wszystkie struktury SI


Cykl ż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ój

Modele 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 klientem


Model 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 SI


Prototypowanie – techniki:

- Szybkie sprawdzanie koncepcji systemu (proof –of – concept prototyping)
- Projektowanie przez prototypowanie (design prototyping)
- Budowa systemu poprzez prototypowanie (development prototyping)
- Niewielki zakres


Prototypowanie – 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 SI


Prototypowanie – narzędzia:

- Generatory interfejsu i oprogramowania
- Programowanie wizualne
- Wykorzystanie gotowych komponentów
- Języki wysokiego poziomu (4GL, SQL)
- Szybkie oprogramowanie
- Papier, tablica, mazaki
- Programowanie odkrywcze






Programowanie 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 SI


Montaż z gotowych komponentów

- Projekt
- Zakup elementów od dostawców
- Integracja ich w SI


Zalety:

- wysoka niezawodność
- zmniejszenie ryzyka
- Efektywność wykorzystania specjalistów
- Narzucenie standardów


Wady:

- Dodatkowy koszt przygotowania elementów
- Ryzyko uzależnienia się od dostawcy elementów
- Niedostatki istniejących narzędzi


Metodyka 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 systemu


Uwarunkowania 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, notacje


Faza strategiczna

Zadania – rezultaty:

- Określenie celów
- Ogólne określenie wymagań (model projektowania)
- Oszacowanie kosztów i ryzyka
- Wstępny harmonogram
- Określenie standardów


Analiza systemu informacyjnego

- Rezultat: sformalizowany model obszaru informatycznego
o Metody analizy:
Obserwacja
Wywiady
Dzienniki
Dyskusje
Inne
o Metody opisu:
Słowny
Tablice decyzyjne
Modele procesów
Inne

Określone wymagania:

- Wymagania funkcjonalne i niefunkcjonalne
- Poziomy opisu:
o Definicja wymagań – ogólny opis
o Specyfikacja wymagań – diagramy funkcji, diagramy przypadków użycia
o 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. Środowiska


Projektowanie – 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ński
o 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ów


Stadium wykonalności:

- Wykonalność techniczna
- Wykonalność ekonomiczna (efektywność)
- Wykonalność organizacyjna
- Wykonalność prawna


Raport 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 systemu


Podsumowanie:

- Analiza pozwala poznać istniejący system
- Analiza wymaga stosowania różnych technik
- Faza strategiczna wytycza cele, wyznacza sposób realizacji systemu informatycznego oraz koszty











Okreś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ęzyka


Poziomy 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ów


Metody 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
- Prototypowanie

Typy wymagań:

- Funkcjonowanie – czynności, które SI musi wykonać w relacji na zdarzenia zewnętrzne (ewidencja, podliczanie)
SI – jest środkiem do osiągnięcia celu



Dokument – specyfikacja wymagań:

- Wprowadzenie (cele, adres, kontekst systemu)
o Adres – czego dotyczy system
o 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 informatyczny


Struktura 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żądanych

Obiekty 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 poziomy

Model 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 klienta
Dane wejściowe N + I + PESEL +
Źródło danych Dowód osób, paszport....
Wynik Zapis w BD
Uwagi


Wymagania niefunkcjonalne:

- Dodatkowe wymagania i ograniczenia
- Wynikają z wymagań użytkownika
- Weryfikowalność wymagań
o Liczebniki a nie przymiotniki
o 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 informatyczne


Plan:

- System informatyczny a rzeczywisty
- Model konceptualny implementacyjny
- Metodyki modelowania SI
- Diagramy przepływu danych (DFD)
- Diagramy związków encji


Model systemu informatycznego:

- Model myślowy SI – Projekt – Model konceptualny logiczny – Projekt – Model implementacyjny
- Analiza rzeczywista, abstrakcja w pojęciach problemowych


Jak system ma działać:

- Rezultat: konceptualny – logiczny
- Techniki modelowania SI
o 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 strukturalne


Elementy 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 daty


Data 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 + Numer
o Adres_dostawcy = Adres
o Adres_odbiorcy = Adres
- Nie definiować szaty graficznej, a tylko dane
- Poprawnie i szczegółowo opisywać elementy danych


Techniki 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 polski

Metodyki obiektowe:

- Metodyki obiektowe wykorzystują pojęcia obiektowości dla celów modelowania konceptualnego oraz projektowania systemów informatycznych
- Techniki:
o Diagramy obiektów
o Diagramy dynamiczne
o Diagramy funkcjonalne
o Angielski używa (USC Cases)
Diagram obiektów:

- Wariant notacyjny i rozszerzenie diagramów ERD


Diagram obiektów zawiera:

- klasy, w ramach klas specyfikacji atrybutów


Metodyki 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 SI


Modelowanie 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 systemu

DFD – 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 danych

DFD – symbole graficzne
SSADM – 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 algorytmu
DFD – 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 – Magazyn
o Obiekt zewnętrzny – Magazyn


DFD – 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 DFD


DFD – 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 decyzyjne


Podusmowanie:

- 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 opis






Wywiad z właścicielem SI „Szybki Bill”

Wł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życzalni
o Rozliczenie wypożyczalni
o Rezerwacja rowerów (przyjęcie rezerwacji, rezygnacji)
o Cennik
o Zestawienie wynikowe
- Kontekst systemu, SI „Szybki Bill” ma współpracować z istniejącym systemem F-K i działać na istniejącym sprzęcie


Wymagania 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 „locie”

Lp. Zdarzenie Obiekt Uwagi
1. 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 rowerowe
1.1.Ewidencja rowerów
1.2.Złomowanie
1.3.Edycja słow. Typ.

2. Ewidencja wypożyczalni
2.1.Ewidencja danych klientów
2.2.Obsługa rezerwacji
2.2.1.Rezerwacja
2.2.2.Rezygnacja
2.2.3.Zestawienie rezerwacji
2.3.Wydruk oferty
2.4.Ewidencja wypożyczenia
2.5.Ewidencja zwrotu
2.6.Sytuacja nadzwyczajna

3. Wspomaganie
3.1.Edycja
3.2.Raporty
3.3.Eksport danych


Opis funkcji 2.1

Nazwa 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 paszport
Wynik Zapis w bazie danych klientów
Uwagi Klient uzyskuje


Dane 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ów


Dane – potrzeby aplikacji:

- Dużo odczytu
- Dane wspólne dla
o Wielu programów
o Wielu użytkowników tego samego programu
- Trwałość danych: długi czas życia



Dane w plikach – problemy:

- Współdzielenie danych – efektywne i konflikty
- Rozw. (warstwa pośrednia) System Zarządzania Danych – SZBD


Co 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ść faktograficzna


Przetwarzanie rozproszone:

- Przezroczystość dla klienta
- Szybkość
- Wielkość BD
- Niezawodność
- Problemy: łączność, transakcyjność, integralność


Model implementacyjny – typy:

- Hierarchiczny
- Sieciowy
- Kartotekowy
- Relacyjny
- Obiektowo – relacyjny
- Obiektowy
- Hypertekst

Model relacyjny – historia:

- Lata 70: IBM, INERES (Uniwersytet Kalifornijski w Berkeley)
- Lata 80
o Mainframe: DB2, Oracle
o Minikomputery (Unix), Informix, Sybrse, Progres
o Mikrokomputery: dBase, FoxPro, Clipper, Parradox, R: BASE
- Lata 90
o Dowsizing dużych systemów
o MikrokomputeryL MS SQL, Server
RDB – 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 atomowe


Klucze:

- 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ązku
o Ograniczone usuwanie
o Usuwanie kaskadowe
o Wstawianie null
- Integralność dynamiczna



Porządkowanie wierszy:

- Wiersz w tablicach – porządek historyczny
- Znaczenie dla interfejsu
- Fizyczne sortowanie – bardzo pracochłonna operacja z wykorzystaniem roboczych indeksowych, operacja dynamiczna



Dostę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żnym


Transakcja a awaryjność w BD:

Transakcje zatwierdzone – mają być odtworzone
Transakcje nie zatwierdzone - wycofane
Metoda osiągnięcia
o Dzienniki transakcji
o Redundancja


4 GL:

Język czwartej generacji oparty na formularzach
Proceduralne
SQL – podzbiór
Język
o ORACLE PL/SQL
o Progress 4 GL


Mapowanie 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ślne
o Rozróżnialność (lub nie) wielkości znaków
o Procedury walidacyjne (trigery)
o Typ indeksu (np. słowny), opis, sposób konstrukcji indeksu
o Sekwencyjne


Tworzenie modelu implementacji:

Generowanie modelu konceptualnego (mapownie modelu konceptualnego na implementacyjny)
rewers ze schematami istniejącymi w BD
różne wersje modelu implementacyjnego


Problem 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
encjatabela
atrybutpole (kolumna)
unikalny identyfikator=>klucz główny
związki klucze obce(dodawane do encji)

np.
ERD z atrybutami
Tabele relacyjnej BD

Mapowanie 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 danych
o 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ęp
o wymagana szybkość dostępu
o 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 typy
o 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 relacyjny
Przykład:

Modelowanie danych na podstawie wymagań użytkownika
Model konceptualny
Modyfikacje modelu
Model implementacyjny - samodzielnie

Rzeczywiste obiekty organizacyjne – encje

Metodyka:

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 dostawy

2. Tablica krzyżowa (związki bezpośrednie między encjami):
Opiekun zwierzęcie
Zwierzę kaltka
Zwierzę racja żywnościowa
Pożywienie dostawa
Dostawca dostawa

3. 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 grupy


Model konceptualny:

Diagramy historii życia encji
Diagramy zmian stanów
Diagramy strukturalne
Pozostałe elementy projektu SI


Aspekty modelowania SI:

Funkcjonalny (DFD, hierarchiczny model funkcji)
Co zachodzi w systemie
Danych(ERD/LDS, obiektowy)
Dynamiki (ELH, STD) – kiedy zachodzi sterowanie


Diagram 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ątkowych



ELH – 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ów


Diagram historii życia obiektu – etapy budowy:

Etap1 przygotowawczy
o Wybranie obiektu z ERD
o 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 ERD
o Normalny cykl życia obiektu
o Zdarzenie specjalne (wyjątkowe)
o Sytuacje błędne

Kolejność budowy
1. wybór zdarzeń odziaływujących na obiekt
2. ustalenie sekwencji zdarzeń
3. sprawdzenie, czy pewne zdarzenia mogą zachodzić warunkowo (selektywnie)
4. sprawdzenie czy pewne zdarzenia mogą powtarzać się wielokrotnie
5. sprawdzenie i ewentualna korekta sekwencji zdarzeń pod wpływem iteracji


ELH – 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 systemie
o 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ący

Modelowanie zależności przyczynowych i czasowych:
Diagram zmian stanów STD (State Transmition Diagram):
o Uzupełnienie DFD o zależności czasowe
o 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-skutkowych

STD – 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ś stanie
o Sprzęgi wejściowe (START) i wyjście (STOP) – tylko jedne
o Każdy stan systemu musi być dostępny ze stanu początkowego
o Stan końcowy powinien być dostępny dla każdego stanu
o 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 aplikacji
o Struktura hierarchiczna: moduł nadrzędny (wywołujący) – moduł podrzędny (wywoływany)
o Budowa: przekształcenie diagramów DFD w STC

Charakterystyki 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 Projektu
o Struktura
o Typ danych
o Procesy

q Implementacji
o Algorytmika (krytyczne miejsca)
o Fizyczne rozmieszczenie danych
o Strojenia SZBD

Zasada efektywności !!
Tylko 10 % kodu ma istotny wpływ na efektywność SI

Bilansowanie modelu
q Różne przekroje modelu - projektu SI:
o Funkcjonalny (procesowy) - DFD,STC
o Informacyjny (danych) – ERD (LDS)
o Zdarzeniowy (stanów) – ELH, STD

q Problem: obiekty i nazewnictwo, struktura , zawartość, oznaczenia
q Cel: utrzymanie spójności projektu i usunięcie błędów

Dostosowanie 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ństwo

Projektowanie szczegółowe:
q Kodowanie informacji
q Interfejs użytkownika
q Formaty dokumentów we/wy
q Urządzenia we/wy
q Struktura techniczna i przestrzenna
q Problemy eksploatacji (autoryzacja dostępu)
q Elementy projektu poziomu fizycznego aplikacji

Kodowanie danych - istota i cele:
q Istota:
o zastąpienia danych przez inne, zwykle ustruktualizowane i określonej notacji
q Cele:
o Uproszczenie i skracanie wprowadzania danych
o Zmniejszenie ryzyka błędów i pomyłek
o Przeciwdziałanie redundancji
o 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życia
q 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 BD

Typ 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 mieszane


Definicja struktury kodu:

INF/01/0234



Nr kolejny numer roku (RR) kod kierunku :ZP, AG INF

Inne kody z cyframi kontrolnymi

q ISBN

K – uzupełnienie do podzielności przez 11

Zalety 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 tworzenia

Kody 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.: RMUA


Oznaczenia obiektów projektu:
- nr/symbol opcji w układzie menu
- kod podsystemu / modułu
- symbol tabulogramu
- symbol dokumentu we/wy
- symbol / nazwa zbioru/pliku

Interfejs użytkownika:
- SI składa się z dwóch części:
o Realizująca funkcje użytkowe
o 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/wy

Sterownie 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) SI
o dialog
- wyjściowych:
o wyświetlenie informacji w dialogu
o raporty
o graficzna prezentacja danych



Poprawny 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 SI

Reguła Millera:
- 7 ± 2
- człowiek może się jednocześnie skupić się na 5 do 9 elementach:
o liczba opcji
o liczba pól dialogowych
o liczba przycisków
o 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, grupowanie

Cele przyjazności SI:
- ograniczenie ilości pomyłek
- minimalizacja czasu i wysiłku uczenia się
- nie obciążanie pamięci krótkookresowej użytkownika

Architektury 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żytkownika


Okna dialogowe:
- dezaktywizują aplikację i wymuszają obsługę
- przyciski powrotu do aplikacji (przynajmniej jeden)
- przy złożonych zakładkach

Wspomaganie 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, stopy

Problemy 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ów

Urzą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łos

Projektowanie 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 liter

Typy 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 informatycznych




Identyfikacja 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ństwa

Dokument – 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ów
o specyfikacje procesów prostych (algorytmy)
- projekt struktury informacyjnej SI:
o kody, symbole, oznaczenia
o model danych konceptualny i implementacyjny
o specyfikacja i projekt informacji wyjściowych oraz wejściowych
o projekt diagramu z użytkownikiem (układ menu, formatek, okna, klawisze itp.)
- struktura techniczno - przestrzenna systemu

Podsumowanie:
- 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ątkowe

Tolerancja błędów:
- właściwość SI poprawnego działania po wystąpieniu błędu
- wymagania tolerancji:
o wykrycie błędu przez program
o wyjście z błędu (zakończenie pracy modułu z błędem)
o ewentualna naprawa błędu

Techniki 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, odrzucanie

Testowanie SI:
- Wykrycie i usunięcie błędów i błędnych wykonań => wykrywanie błędów
- Ocena niezawodności systemu => testy statystyczne

Dwa 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 konstrukcji

Fazy 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 sucho”
o wyszukiwanie błędów
- dynamiczne (wykonanie + analiza wyników)
- dowód poprawności – obliczenia matematyczne (10 KLOC = 500K$) – koszt


Kryteria 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 liczba

Typowe 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 <=)
- złożone wyrażenia (stosowanie nawiasów)
- nieuwzględnienie błędnych danych

Testowanie systemu techniki:
- Wstępujące (operowanie danych: procedur testujących, hierarchiczność strategii -> 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 losowe
o dane deterministyczne
o dane rzeczywiste

Miary 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ów

„Sianie 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ów

Faza 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 BD

Dokumentowanie:
- 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, administrowanie

Skutek 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 elektroniczne

Jakość dokumentacji:
- cel: jaki odbiorca (język)
- struktura
- standardy
- sposób pisania