Inżynieria oprogramowania to wiedza techniczna odnosząca się do wszystkich etapów życia oprogramowania; inżyniera oprogramowania ujmuje samo oprogramowanie w kategoriach produktu, którego zadaniem jest spełnienie odpowiednich potrzeb technicznych, ekonomicznych lub społecznych. Dobre oprogramowanie powinno spełniać następujące warunki:

  • musi być efektywne
  • ergonomiczne
  • łatwe w utrzymaniu
  • adekwatne do wymagań użytkownika
  • niezawodne
  • poprawne

Wśród zagadnień dotyczących inżynierii oprogramowania wymienić można następujące:

  • analiza i projektowanie systemów
  • metody pracy w zespole oraz psychologiczne czynniki mające wpływ na efektywność pracy
  • sposoby kierowania przedsięwzięciami informatycznymi
  • sposoby obniżania kosztów konserwacji, czyli usuwania błędów, stosowania modyfikacji oraz rozszerzeń
  • sposoby przygotowywania technicznej oraz użytkowej dokumentacji
  • sposoby sprawdzania i szacowania niezawodności systemów
  • sposoby zapewniania niezawodności oprogramowania
  • stosowane procedury kontroli jakości
  • techniki służące planowaniu, szacowaniu kosztów, sporządzaniu harmonogramu oraz monitorowaniu przedsięwzięć informatycznych

Kryzys oprogramowania zakłada:

  • złożoność tworzonych systemów informatycznych
  • wydłużony okres czasu wytwarzania systemów informatycznych zachodzących w warunkach stałych zmian otoczenia
  • pozornie łatwe wprowadzanie zmian
  • oryginalność oraz wielodziedzinowość tworzonych projektów
  • "niewidzialność" systemów informatycznych oraz ich procesów wytwarzania

Złożoność systemów informatycznych wyraża się w:

  • znacznej liczbie ich elementów oraz złożonych związkach
  • złożoności oraz rozwoju środków technicznych i programowych
  • różnorodności, zmienności wymagań, skłonności do popełniania błędów i tajności użytkowników
  • umiejętnościach, czasie, odpowiednich środkach i komunikacji zespołu wykonawczego

Walka ze złożonością systemów informatycznych wymaga wdrożenia następujących zasad:

  • zasada dekompozycji oraz hierarchiczności, polegająca na wydzieleniu ze skomplikowanego problemu podproblemy, które mogą być rozpatrywane i rozwiązywane niezależnie
  • zasada abstrakcji i strukturyzacji polega na ukryciu lub pominięciu mało ważnych szczegółów przedmiotu lub informacji; jest to wyodrębnienie wspólnych, niezmiennych cech pewnego zbioru elementów
  • zasada ponownego użycia wyrażająca się w wykorzystywaniu wcześniej utworzonych schematów czy metod
  • zasada sprzyjania naturalnym ludzkim własnościom, polegająca na adekwatnym tworzeniu modeli pojęciowych i realizacyjnych systemów dla wrodzonych cech ludzkich, instynktów, właściwości psychologicznych oraz mechanizmów percepcji i rozumowania świata

Wieloaspektowość opisu polega na tym, iż złożony system może zostać opisany w skali homogenicznego opisu wielu różnych projektów.

Terminy: "modelowanie pojęciowe" oraz "model pojęciowy" dotyczą procesów myślowych oraz wyobrażeń, które towarzyszą pracy nad oprogramowaniem; modelowanie pojęciowe wspomagane jest poprzez środki mobilizujące wyobraźnię i pamięć ludzką.

Notacja stanowi formę zapisu; wyróżnia się następujące rodzaje notacji:

    • język naturalny
    • notacja graficzna
    • specyfikacja, czyli ustrukturalizowany zapis numeryczny i tekstowy

Do funkcji notacji zalicza się:

    • stanowi narzędzie pracy dla projektanta i analityka - umożliwia dokonywanie zapisu oraz analizę pomysłów
    • służy współpracy z użytkownikiem
    • stanowi podstawę dla komunikacji z członkami zespołu
    • jest podstawą dla implementacji oprogramowania
    • umożliwia dokonywanie zapisu dokumentacji technicznej

Technika jest sposobem wykorzystywania narzędzi dla rozwiązywania problemów, natomiast metoda stanowi sposób posługiwania się oraz wykorzystywania techniki.

Metodyka jest zestawem pojęć, modeli, języków, notacji, technik oraz sposobów postępowania, służącym do wykonywania analizy w dziedzinie będącej przedmiotem projektowanego systemu oraz projektowania pojęciowego, logicznego lub fizycznego. Pojęcie metodyki wiąże się z notacją, która służy dokumentowaniu wyników poszczególnych etapów projektu. Metodyka formułuje:

  • zasady przechodzenia z jednego do kolejnego etapu
  • wykorzystywane notacje
  • tworzoną na każdym etapie dokumentację
  • scenariusz postępowania na każdym etapie projektowania
  • poszczególne role jego uczestników
  • poszczególne etapy projektu
  • modele powstające na poszczególnych etapach pracy

Wyróżnia się metodyki:

  • obiektowe
  • strukturalne
  • mieszane

CASE to narzędzia informatyczne wspomagające proces tworzenia oprogramowania na wszystkich etapach projektu, które dzielą się na:

    • Integrated - CASE (dla wszystkich etapów)
    • Lower - CASE (stanowią wspomaganie implementacji)
    • Upper - CASE (dla wszystkich etapów)

Wyróżnia się następujące struktury systemów informatycznych:

  • funkcjonalna, zawierające funkcje i cele
  • informacyjna, mówiąca, jakie dane zostały wprowadzone i wyprowadzone
  • oprogramowanie,czyli zespół programów narzędziowych oraz użytkowych
  • przestrzenna, określająca, co ma się znajdować w danym punkcie
  • techniczna, określająca, jaki sprzęt jest niezbędny dla realizacji danej funkcji

Budowa systemów informatycznych zakłada:

  • analizę, czyli badanie stanu aktualnego
  • projektowanie, którego rezultat stanowi projekt czegoś nowego
  • implementacja, czyli wytwarzanie
  • wdrażanie

Cykl życiowy oprogramowania jest to proces składający się z pewnego ciągu spójnych ze sobą etapów, umożliwiających w pełni oraz skutecznie tworzyć i używać systemów informacyjnych; cykl ten rozpoczyna się w momencie uświadomienia sobie potrzeby istnienia danego systemu a kończy w chwili wycofania go z eksploatacji. Cykl życiowy oprogramowania zakłada istnienie następujących faz:

  1. faza strategiczna, polegająca na określeniu strategicznych celów oraz planowaniu i definicji projektu
  2. faza formułowania wymagań
  3. analiza dotycząca dziedziny przedsiębiorczości oraz wymagań systemowych
  4. faza projektowania: pojęciowego i logicznego
  5. implementacja (konstrukcja), czyli rozwój, testowanie oraz dokumentacja
  6. przeprowadzanie testów
  7. przygotowanie dokumentacji
  8. instalacja
  9. przygotowanie użytkowników
  10. akceptacja
  11. szkolenie
  12. utrzymanie, pielęgnacja i konserwacja

Istnieją następujące modele cyklu życia oprogramowania:

  • kaskadowy(wodospadowy) - posiada stabilny zestaw potrzeb, które są niezmienne w trakcie całej budowy systemu informatycznego; każdy etap kończony jest powstaniem dokumentu, następuje sprawdzenie - pozytywna weryfikacja pozwala przejście do następnego etapu
  • spiralny - składa się z następujących faz:
  1. planowanie
  2. analiza ryzyka
  3. konstruowanie
  4. weryfikacja
  • prototypowanie -prototyp jest modelem systemu informatycznego, który demonstruje działanie przyszłego systemu; wśród obszarów jego działania wyróżnia się:
  • szybkie sprawdzanie koncepcji systemu
  • projektowanie przez prototypowanie
  • budowa przez prototypowanie
  • montowanie z gotowych komponentów zakłada następujące czynności:
  • projekt
  • kupienie poszczególnych elementów u dostawców
  • integracja i łączenie ich w system informatyczny

Do zalet tego modelu należy jego niezawodność, mniejsze ryzyko oraz efektywne wykorzystanie specjalistów; do wad zaliczyć można: dodatkowe koszty przygotowania elementów do ponownego wykorzystania, ryzyko uzależnienia od jednego dostawcy

  • przyrostowy

Warunki wyboru metodyki projektowania systemów informatycznych:

  • wielkość przedsięwzięcia
  • wraz ze wzrostem czasu realizacji zwiększa się również udokumentowanie (czyli czasookres realizacji danego przedsięwzięcia)
  • poziom współpracy z użytkownikami
  • rozmiary oraz umiejętności zespołu projektującego
  • dostęp do odpowiednich narzędzi
  • ocena systemu

Skutki doboru metodyki:

  • następstwo oraz zakres wykonywanych prac
  • zawartość dokumentacji
  • koszt
  • odpowiednia metodyka modelowania oraz projektowania
  • notacja

Faza strategicznama miejsce jeszcze zanim zostanie podjęta decyzja w sprawie realizacji danego przedsięwzięcia; określana jest również mianem strategicznego planu rozwoju informatyzacji (w skrócie SPRI) albo studium osiągalności. Wśród zadań i rezultatów pracy należy wymienić:

  • sformułowanie celów
  • sformułowanie zakresu oraz kontekstu (czyli otoczenia)
  • określenie ogólnych wymagań
  • szacunek kosztów oraz ryzyka
  • stworzenie wstępnego harmonogramu
  • zdefiniowanie standardów

Analiza systemów informatycznych:

  • wynik: sformalizowany model obszaru informatycznego
  • metody: obserwacja, wywiad, dziennik, dyskusja
  • metody opisu: słowna, modele procesów, tablice decyzyjne

Sformułowanie wymagań:

  • funkcjonalne (czyli przetwarzanie) oraz niefunkcjonalne

Poziomy opisu:

  • zdefiniowanie wymagań (na poziomie ogólnym)
  • specyfikacja wymagań (stworzenie diagramów funkcji oraz przypadków użycia)
  • specyfikacja oprogramowania (formalna)

Wynik:

  • co ma robić system

Wynik:

  • stworzenie logicznego modelu systemu

W wyniku modelowania uzyskujemy logiczny model systemu; wyróżnia się następujące techniki modelowania:

    • strukturalne (opierające się na diagramach przepływu danych oraz diagramach związków encji)
    • obiektowe (opierające się na diagramach obiektów i klas, iteracji oraz przejść stanów)

Rezultatem projektowania jest odpowiedź na pytanie jak powinien być zaimplementowany system; wyróżnia się następujące obszary projektowania:

  • interfejs użytkownika
  • optymalizacja obiektów oraz dostosowanie ich do wymagań środowiska
  • struktura fizyczna baz danych oraz kodu programu

Kodowanie danych:

  • stworzenie systemu informatycznego przyjaznego użytkownikom
  • projekt formularzy
  • określenie czynności manualnych

Implementacja:

  • dobór języka (języki proceduralne i deklaratywne)
  • korzystanie z gotowych elementów
  • narzędzia RAD

Celem testowania systemów informatycznych jest wykrycie oraz usunięcie ewentualnych błędów wraz z ocenę stopnia niezawodności systemu. Wyróżnia się statyczne i dynamiczne sposoby testowania oraz dowód poprawności.

Dokumentowanie polega na wytwarzaniu dokumentów dla odbiorców takich jak autorzy, użytkownicy, administratorzy. Dokumentowanie służy:

  • opisowi budowy systemu informatycznego
  • nauce użytkownika oraz administratora
  • pomaga przy rozwiązywaniu różnych problemów (związanych z instalacją czy użytkowaniem)

Instalacjaobejmuje następujące elementy:

  • instalację sprzętu
  • instalację systemu operacyjnego
  • instalację oprogramowania wspomagającego BD oraz SI w całość

czego rezultatem jest gotowy do pracy system informatyczny

Celem wdrożenia jest sytuacja, w której system informatyczny stanowi integralną część systemu informatycznego organizacji. Do zadań wdrożenia zalicza się:

  • szkolenie
  • dostosowywanie systemu do odpowiednich wymagań
  • zapełnienie bazy danych
  • stworzenie bilansu otwarcia
  • przekazanie systemu użytkownikowi

Rozwój systemu informatycznego zakłada jego modyfikację, polegającą na poprawianiu błędów, udoskonalaniu, dostosowywaniu do wymagań oraz potrzeb użytkownika. Skutkiem modyfikacji jest naruszenie struktury systemu oraz wnoszenie błędów. Likwidacja systemu informatycznego obejmuje zaplanowanie procesu likwidacji, który zazwyczaj wiąże się z powstaniem nowego systemu informatycznego. Z Likwidacją wiążą się takie kwestie jak konieczność zapewnienia dostępu do archiwalnych danych przez długi okres czasu oraz migracja tych danych do kolejnego systemu.

System stanowi pewien spójny zespół niezależnych elementów istniejących w określonym celu, posiadających pewną stabilność oraz będących ze sobą powiązanych. Wejścia, czyli zasoby systemu stanowią elementy pozyskiwane przez niego z otoczenia lub innych systemów, natomiast wyjścia systemu stanowią te elementy, które są dostarczane przez system otoczeniu lub innym systemom.

Główny cel analizy stanowi rozpoznanie wszelkich aspektów rzeczywistości bez wprowadzania jakichkolwiek zmian do systemu. Analiza obejmuje następujące czynności:

  1. rozpoznanie
  2. wyjaśnienie
  3. modelowanie
  4. specyfikacja
  5. dokumentacja

W toku analizy dochodzi do ustalenia kontekstu projektu danego projektu, wymagań i potrzeb użytkowników, wymagań związanych z organizacją oraz innych ustaleń, dotyczących na przykład preferencji sprzętowych lub z zakresu oprogramowania, finansowych i czasowych itp. Wyróżnia się następujące metody analizy:

  • analiza dokumentów
  • dyskusja
  • dziennik
  • narada
  • obserwacja
  • samodzielny opis
  • wywiad
Notacja BNF:
  • = składa się
  • + i
  • () opcjonalność
  • {} iteracja
  • [] selekcja
  • *...* komentarz
  • | rozdzielanie alternatyw na liście
  • @ oznaczenie elementu identyfikującego

Zasady dotyczące budowy MPB:

  • zdarzenia wejściowe oraz wyjściowe
  • blok decyzyjny zawiera przynajmniej dwa wyjścia
  • blok decyzyjny poprzedzony jest weryfikacją
  • dokumenty we oraz wy (kierunek strzałek)
  • integracja poszczególnych procesów w hierarchii
  • jednoznaczność i prawidłowość opisu
  • dokładność, czytelność i abstrakcja
  • wyczerpanie wszelkich możliwości

Rezultat analizy stanowi dokument zawierający:

  • wprowadzenie, czyli opis celu, zakresu oraz podmiotu analizy
  • poszczególne modele procesów biznesowych w postaci diagramów i drzew decyzyjnych
  • tablice zawierające opis dokumentów we/wy
  • specyfikację treści tych dokumentów (czyli BNF wraz z opisem danych elementarnych)
  • pozostałe dane, takie jak kontekst, organizacja, planowane zmiany czy potrzeby

Faza strategiczna, czyli studium wierzytelności obejmuje sformułowanie celów oraz zakresu projektu, określenie ogólnych wymagań, szacunek kosztów oraz ryzyka i harmonogram wstępny, natomiast studium wykonalności obejmuje wykonalność techniczną, ekonomiczną (czyli efektywność), organizacyjną i prawną.

Opis treściowej zawartości dokumentu przeprowadzany jest według następujących zasad:

  • wykorzystanie metody zstępującej, polegającej na podziale na poszczególne kolekcje danych wraz z ich opisem
  • nie należy definiować tego, co zostało już zdefiniowane
  • nie należy definiować szaty graficznej, lecz same dane
  • opis elementów danych ma być przeprowadzony szczegółowo i poprawnie

Główny cel fazy określenia wymagań stanowi ustalenie, jakie są wymagania klienta w stosunku do tworzonego systemu; określenie wymagań polega na zamianie celów klienta na konkretne wymagania, które mają zapewnić osiągnięcie owych celów. Ponieważ klient często nie ma świadomości, jakie wymagania umożliwią osiągniecie założonych przez niego celów, faza ta stanowi proces, w trakcie którego klient wraz z przedstawicielami producenta określa swoje wymagania adekwatnie do postawionych celów. W procesie tym uwzględnia się następujące czynniki:

  • adaptowalność systemu
  • bezpieczeństwo, wyrażające się w poufności, prywatności i odporności
  • dokładność systemu wyrażające się w liczbie miejsc znaczących
  • finansowe i ludzkie zasoby
  • interakcje człowieka z maszyną, czyli interfejs użytkownika oraz sprzęt, język i komunikaty
  • interfejsy komunikacyjne
  • interfejsy oprogramowania
  • interfejsy sprzętowe
  • możliwości systemu wyrażające się w zestawie jego funkcji w kontekście użytkownika
  • ograniczenia dotyczące czasu wykonania
  • ograniczenia systemu, czyli zakres jego zmienności
  • standardy systemu
  • szybkość systemu, czyli czas realizacji operacji oraz natężenie operacji
  • wielkość systemu wyrażająca się w liczbie jego użytkowników oraz objętości bazy danych
  • wytrzymałość na awarie

Trudności w procesie określania wymagań przejawiają się w:

  • nieumiejętności klienta zdefiniowania własnych celów oraz wymagań
  • różnorodnych sposobach osiągania celów klienta
  • występowaniu wielu użytkowników, posiadających sprzeczne cele, odmienną terminologię
  • sprzeczność interesów zleceniodawców i użytkowników
  • wieloznaczność języka

Poziomy opisu wymagań:

  1. poziom ogólny, czyli definicja wymagań
  2. specyfikacja wymagań polegająca na stworzeniu częściowo ustrukturalizowanego zapisu, wykorzystującego język naturalny oraz proste notacje
  3. specyfikacja oprogramowania, czyli formalny opis wymagań

Metody rozpoznawania wymagań:

  • wywiad - powinien mieć przygotowane pytania wraz z podziałem na poszczególne zagadnienia, przykrywającym ogólny temat; wywiad należy przeprowadzić na reprezentatywnej grupie, jego celem jest doprowadzenie do szerokiej zgody oraz akceptacji projektu
  • studia nad istniejącym oprogramowaniem - częste są sytuację, gdzie nowe oprogramowanie wchodzi w miejsce starego, zatem studia te dążą do ustalenia wszystkich dobrych i złych stron oprogramowania starego
  • studia nad wymaganiami systemowymi dotyczą sytuacji, gdy nowy system stanowić ma część systemu większego
  • studia nad osiągalnością, czyli zdefiniowanie realistycznych celów oraz metod ich osiągania
  • prototypowanie - budowa prototypu systemu, który działa w mniejszej skali oraz posiada uproszczone interfejsy

Wykaz zdarzeń obejmuje następujące rodzaje zdarzeń:

  • dane pojawiające się na granicy systemu
  • wymuszanie z wewnątrz lub z zewnątrz
  • sterowanie - systemowe
  • określenie zdarzeń w aspekcie otoczenia systemu
  • określenie wyjątków oraz zdarzeń niepożądanych

Model funkcji:

  • funkcja równa jest działaniu
  • zwięzłość i jednoznaczność opisu, numeracja funkcji
  • wszystkie poziomy mają są na takim samym poziomie szczegółowości
  • kompletność dekompozycji
  • bez znaczenia jest kolejność funkcji
  • funkcja z pozycji użytkownika
  • podejście top - down

Wymagania niefunkcjonalne - związane z produktem: np. istnienie możliwości operowania systemem tylko za pośrednictwem klawiatury; związane z procesem:

np. realizacja harmonogramowania zleceń należy przeprowadzić zgodnie ze standardem opisanym w danym dokumencie. Wymagania zewnętrzne - np. system harmonogramowania ma współpracować z bazą danych systemu komputerowego działu marketingu, która jest opisana w danym dokumencie, nie dopuszcza się dokonywania jakiekolwiek zmian w strukturze bazy.

Celami modelowania struktur danych są:

  • określenie informacyjnych potrzeb obiektu rzeczywistego, czyli firmy lub działu
  • identyfikacja ważnych elementów analizowanego systemu (encji lub obiektów) wraz z ich atrybutami oraz sposobami, w jaki są powiązane (związki)
  • dostarczenie modelu potrzeb informacyjnych, stanowiącego podstawę dla nowych systemów
  • dostarczenie modelu, który jest nie zależy od sposobu przechowywania danych oraz metod dostępu

Diagram związków encji jest diagramem prezentującym dane wraz z zachodzącymi pomiędzy nimi związkami logicznymi; diagram ten obejmuje encje zawierające określone właściwości (atrybuty) oraz ich związki (czyli relacje i odniesienia).

Encja jest jednoznacznie identyfikowalnym składnikiem badanej rzeczywistości (dziedziny przedmiotowej), o którym informacja jest lub może być, zbierana oraz przechowywana. Wszystkie encje muszą być jednoznacznie identyfikowane oraz wyraźnie odróżnialne od innych stanowiących ten sam typ. Związek encji to istotne powiązanie pomiędzy minimum dwoma encjami; charakteryzuje się on następującymi cechami:

  • jednoznaczną nazwą
  • stopniem i liczbą
  • opcjonalność

Atrybutycharakteryzują się autonomicznością, jednoznacznością, zależnością jedynie od instancji encji (czyli klucza głównego) oraz typem i formatem. Atrybut stanowi element danych - jednorodny lub w formie kolejki (np. atrybutem klienta będzie jego nazwisko, imię, kod pocztowy, ulica)

Procedura budowy ERD składa się z następujących czynności:

  1. identyfikacja, czyli wydzielenie zbioru danych w systemie oraz ich atrybuty kluczowe
  2. identyfikacja rodzaju powiązań bezpośrednich występujących pomiędzy obiektami (wg tablicy krzyżowej)
  3. zamiana tablicy krzyżowej zidentyfikowanych powiązań na logiczny model danych oraz określenie pozostałych atrybutów
  4. zamiana powiązań typu m:n na 2 powiązania 1:n oraz identyfikacja atrybutów nowopowstałych obiektów
  5. kontrola poprawności utworzonej struktury przez porównanie jej z założonymi wymaganiami systemu
  6. sprawdzenie DFD w związku z ERD (ma być szereg: encja - składnia danych)

Celem tworzenia systemów informatycznych jest automatyzacja procesów obejmujących następujący zakres:

  • cenniki
  • ewidencja
  • gospodarka
  • rezerwacje
  • rozliczenia
  • różne zestawienia

Istnieją następujące techniki strukturalne:

  • model danych znajdujących się w systemie, czyli związków obiektów (encji) - ERD
  • model procesów przedstawiający diagram przepływu danych - DFD
  • model zdarzeń mających miejsce w systemie informatycznym, przedstawiający diagram historii obiektu - ELH
  • model zmiany stanów systemu, czyli diagram zmian systemowych - STD
  • schemat struktury aplikacji - STC
  • słownik danych grupujący definicje poszczególnych obiektów i rekordów
  • strukturalny angielski - strukturalny polski

Porównanie metodyk strukturalnych z metodykami obiektowymi:

  • metodyki strukturalne wykazują trudności w integrowaniu metodyki, nie przesyłają do obiektowej implementacji systemu informatycznego, są dojrzałe, lecz mogą się okazać nieadekwatne w stosunku do aktualnych tendencji w produkcji systemów informatycznych
  • metodyki obiektowenadają się bardziej do systemów czasu rzeczywistego niż do systemów tradycyjnych, transakcyjnych, wymagają one znacznego nakładu pracy, ponadto są młode, bez znaczącego doświadczenia, ulegają wielu zmianom

Diagramy przepływu danych - DFD - zakładają:

  • strukturalną specyfikację funkcji systemu
  • określenie zależności występujących pomiędzy procesami oraz danymi
  • precyzyjne określenie zakresu systemu, podsystemów oraz modułów
  • zwięzły i czytelny opis funkcji systemu, który będzie przystępny dla użytkownika
  • redukcję funkcjonalnej redundancji systemu

DFD składa się z następujących elementów:

  • obiekt zewnętrzny, czyli terminator, służący dawaniu lub pobieraniu danych do systemu
  • procesprzetwarzający wejściowy strumień danych na wyjściowy
  • magazyn danychgromadzący oraz przechowujący dane
  • przepływ danych,czyli jaka jest struktura oraz trasa ich przepływu

Diagram kontekstowy wyznacza granice systemu; diagram systemowy stanowi ogólny diagram systemu składający się z podsystemów i głównych magazynów danych; diagram procesów stanowi rozwinięcie podsystemów, aż do procesów elementarnych, których specyfikacja obejmuje mini specyfikację oraz opis elementarnych algorytmów.

Budowa DFD przebiega według następujących zasad:

  • nie określa się sposobu pobierania lub dostarczania danych przez obiekt zewnętrzny
  • magazyn stanowi element pasywny, służący przechowywaniu danych, który może wykazywać złożoną strukturę
  • poszczególne procesy nie mogą być wzajemnie zależne
  • nie określa się występujących zależności między obiektami (czasowych, przyczynowo - skutkowych)
  • wszystkie procesy muszą posiadać swoje nazwy (unikalny identyfikator lub nazwa)
  • należy zapewnić przejrzystość oraz możliwość przeprowadzenia analizy (maksymalna liczba procesów znajdujących się na diagramie to 7 +- 2)

Wyróżnia się następujące konstrukcje:

  • proces aktualizowany przez proces
  • proces aktualizujący magazyn
  • proces czytający dane zawarte w magazynie
  • przesyłanie danych do obiektów zewnętrznych lub z obiektów zewnętrznych

Techniki dekompozycji, czyli podział procesu charakteryzują się:

  • dekompozycji podlega również strumień danych
  • może mieć miejsce podział na 2 i więcej procesów
  • może występować komunikacja za pośrednictwem magazynów
  • tworzą się 2 niezależne procesy

Występujące błędy w strukturze:

  • czarne dziury, czyli procesy pochłaniające pewne informacje
  • źródła danych, czyli proces posiadający wyjścia, lecz bez wejść
  • puchnące magazynypochłaniające dane, których się z nich już nigdy nie usuwa
  • stałe magazyny, z których możne jedynie pobrać dane
  • błędne przepływy, jak np. magazyn - magazyn czy obiekt zewnętrzny - magazyn

Proces elementarny zakłada:

  • algorytmiczną definicję procesu
  • dowolność w formułowaniu
  • tablice decyzyjne, pseudokod, SQL, słowny opis algorytmu

Bazy danych-dane w programie to dane znajdujące się wewnątrz programu (we/wy), wykorzystywane przez danego użytkownika w ciągu pojedynczej sesji; są one nietrwałe i nie są dostępne wielu użytkownikom.

Bazy danych są zorganizowanym zbiorem danych, który jest przechowywany w zewnętrznej pamięci komputera; stanowią one odzwierciedlenie określonego fragmentu rzeczywistości oraz posiadają cechy takie jak trwałość oraz zgodność z rzeczywistością.

Baza danych powinna wykazywać następujące właściwości:

  • abstrakcyjność
  • brak redundancji
  • niezależność danych od programów
  • niezawodny dostęp
  • poufność
  • spójność
  • współdzielenie danych
  • zabezpieczenie przed utratą

Wyróżnia się następujące poziomy odwzorowania danych:

  • poziom zewnętrzny, który jest widoczny tylko dla konkretnych użytkowników
  • poziom konceptualny
  • poziom wewnętrzny, czyli implementacyjny zawierający konkretny system zarządzania bazami danych; fizyczny - czyli miejsce jego umieszczenia)

Na system zarządzania bazami danych składają się następujące czynności:

  • organizacja struktury bazy danych, czyli definiowanie jej schematu
  • konstruowanie bazy danych, czyli systemu plików
  • przetwarzanie danych wyrażające się w aktualizacji (wprowadzanie, poprawianie lub usuwanie) oraz wyszukiwaniu danych (czyli zapytania do bazy danych)
  • administracja bazą danych
  • zapewnianie właściwości bazy danych w praktyce

Specyfika systemu zarządzania bazami danych:

  • transakcyjność i optymalizacja przetwarzań
  • blokowanie zasobów, czyli rozwiązywanie konfliktów dostępu
  • zabezpieczenie przed zakleszczeniem
  • system kont wraz z uprawnieniami dostępu
  • monitorowanie bazy danych

Języki stosowane w bazach danych:

  • DCL, czyli język sterowania danymi
  • DDL, czyli język definiowania danych
  • DML czyli język manipulowania danymi
  • Query Language - język zapytań (raportowania)

Rodzaje architektury systemu zarządzania bazami danych:

  • jednopoziomowa
  • dwupoziomowa, składająca się z klienta i serwera
  • trójpoziomowa, składająca się z serwera www, serwera aplikacji i serwera bazy danych
  • rozproszona, składająca się z wielu serwerów baz danych

Właściwości bazy danych:

  • niezależność danych i aplikacji
  • abstrakcyjna reprezentacja wykorzystywanych przez aplikacje danych
  • możliwość widzenia danych w różny sposób przez poszczególnych użytkowników przez zastosowanie filtrów, perspektyw
  • logiczne i fizyczne niezależności

Typy modelu implementacyjnego:

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

Relacyjne bazy danych składają się z następujących pojęć podstawowych:

  • atrybut
  • domena
  • dziedzina
  • kolumna
  • plik
  • pole
  • rekord
  • tablica
  • typ danych
  • wartość null
  • wiersz tablicy
  • związki wartościowe, czyli preferencje

Zasady tworzenia relacyjnych baz danych:

  • wszystkie tablice zawarte w bazie danych posiadają jednoznaczne nazwy
  • wszystkie pola (kolumny) posiadają jednoznaczną nazwę w tablicy
  • wartości zawarte w danej kolumnie są takiego samego typu
  • nie ma znaczenia porządek wierszy czy kolumn
  • każdy wiersz powinien różnić się wartościowo
  • wszystkie pola powinny zawierać wartości atomowe

Wyróżnia się następujące klucze:

  • Primary Key czyli klucz główny, stanowiący grupę kolumn z danymi niepowtarzającymi się 
  • Foreign Key czyli klucz obcy, stanowiący grupę kolumn pochodzących z tej samej tablicy, o wartościach odpowiadających kluczowi głównemu z innej tablicy

Integralność dotyczy poziomu pól oraz poziomu tablic; integralność referencyjna zakłada obowiązkowość związku, kaskadowe oraz ograniczone usuwanie i wstawianie null. Integralność dynamiczna zakłada porządkowanie wierszy (wiersze w tablicach przestrzegają porządku historycznego), znaczenie dla interfejsu oraz sortowanie fizyczne (polegające na wykorzystaniu roboczych plików dyskowych) i logiczne (czyli indeksowanie, polegające na tworzeniu i wykorzystywaniu tablic indeksowych)

Transakcje przeprowadzane na bazach danych:

  • zmiana stanu bazy danych
  • logiczna jednostka pracy w bazach danych
  • w czasie transakcji baza danych jest niespójna
  • transakcja wykazuje właściwości takie jak spójność i trwałość
  • blokowanie stanowi podstawę realizacji transakcji zachodzącej we współbieżnym środowisku

Związek transakcji z awaryjnością baz danych:

  • transakcje zatwierdzone muszą zostać odtworzone
  • transakcje niezatwierdzone muszą zostać wycofane

Mapowanie konceptualnego modelu na model implementacyjny:

  • model konceptualnynie zależy od systemu zarządzania bazą danych, posiada język programowania modeli baz danych (ERD)
  • model implementacyjny ma fizyczny charakter, znajduje się w konkretnym modelu baz danych oraz systemu zarządzania bazami danych; służy on generowaniu skryptów do tworzenia baz danych z więzami integralności

Podstawowe pojęcia dla relacyjnego modelu implementacji:

  • dziedzina
  • indeks
  • klucz alternatywny
  • klucz główny
  • klucz obcy
  • kolumna (odpowiada atrybutowi)
  • odniesienie
  • rekord
  • tabela (odpowiada encji)

Specyficzne dla systemu zarządzania bazami danych atrybuty rozszerzone wykazują następujące właściwości:

  • elementy dodatkowe w postaci opisów, etykiet, itp. wyświetlanych na ekranie
  • możliwość rozróżniania (albo nierozróżniania) wielkości znaków
  • procedury walidacyjne (czyli trigery)
  • typ, opis i konstrukcja indeksu
  • wartości domyślne

Tworzenie modelu implementacji obejmuje wygenerowanie go z modelu konceptualnego (czyli mapowanie konceptualnego na implementacyjny) oraz rewers z istniejącymi w bazie danych schematami. Proces mapowania wiąże się z następującymi trudnościami:

  • problem ilościowych ograniczeń ( np. liczba pól w rekordzie)
  • problem związany z nazewnictwem (identyfikatory, dziedziny, nazwy typów)
  • pola są jednowartościowe - jest to model płaski
  • rekord nie posiada zmiennej struktury

Rodzaje mapowania złożonego:

  • na oddzielną tabelę
  • na pojedynczą tabelę, czyli kodowane
  • wykluczających się związków
  • złożone nieoczywiste - są to związki występujące między wieloma encjami

Każda z encji może posiadać wiele niepowtarzalnych identyfikatorów, stanowiących klucze kandydujące, spośród których wybierany jest klucz główny; w przypadku braku klucza kandydującego tworzony jest klucz sztuczny, który jest generowany w sposób automatyczny. Dobór klucza głównego przebiega według następujących zasad:

  • musi być generowany w sposób automatyczny (RecLD, OJD)
  • musi stanowić jeden atrybut
  • nie może posiadać swojego znaczenia w dziedzinie przedmiotowej

Ilościowe aspekty danych obejmują:

  • informacje charakteryzujące ilość danych, czyli:
  • obszar zajęty pamięci, czyli ilość wystąpień w bazie danych
  • zmienność, czyli przewidywany przyrost
  • wypełnianie pól
  • informacje charakteryzujące dostęp, a więc:
  • wymagana szybkość
  • zakres przetwarzań
  • częste operacje w bazach danych (konto klienta):
  • dodawanie nowej operacji
  • zapytania dotyczące stanu konta
  • zmiana stanu konta
  • rzadkie operacje w bazach danych:
  • zmiany danych adresowych

Wyróżnia się dwa aspekty modelowania systemów informatycznych:

  • aspekt funkcjonalny (hierarchiczny model funkcji, DFO) mówiący, co zachodzi w systemie
  • aspekt danych(LDS, ERD, obiektowy) mówiący, na czym zachodzi

Etapy budowy diagramu historii życia obiektu (encji):

  1. Etap przygotowawczy
  • wybranie określonego obiektu z ERD
  • określenie zdarzeń związanych z danym obiektem na podstawie DFD
  • dodatkowe sprawdzenie funkcji
  1. Etap dla każdego obiektu z ERD
  • zwykły cykl życia danego obiektu
  • zdarzenie wyjątkowe
  • błędne sytuacje

Etapy budowy:

  1. dobór zdarzeń mających oddziaływanie na dany obiekt
  2. określenie sekwencji zdarzeń
  3. zbadanie, czy określone zdarzenia mogą warunkowo zachodzić
  4. zbadanie, czy określone zdarzenia mogą się wielokrotnie powtarzać
  5. kontrola i korekta kolejności zdarzeń pod wpływem iteracji
  6. zbadanie, wszystkie iteracje zdarzeń określonego typu są jednakowo traktowane przez system

Identyfikacja zdarzeń wyjątkowych oraz weryfikacja - ELH

  • gdzie występują zdarzenia wyjątkowe?
  • czy są rejestrowane przez system?
  • jak są rejestrowane?
  • jakie towarzyszą zdarzeniu wyjątkowemu skutki uboczne, czyli realizowane w systemie zdarzenia?
  • weryfikacja ELH względem DFD (konkretnemu zdarzeniu na ELH musi odpowiadać przynajmniej jeden przepływ na DFD)

Zasady sporządzania STD:

  • istnieją tylko jedne sprzęgi wejściowe (czyli start) oraz wyjściowe (czyli stop)
  • jednoznaczność przejścia polegająca na tym, iż dany warunek ma powodować przejście z jednego stanu do drugiego stanu
  • każdy stan musi być zawsze dostępny z pozycji stanu początkowego
  • stan końcowy musi być zawsze dostępny dla wszystkich stanów
  • system zawsze musi się znajdować w pewnym stanie

Bilansowanie modelu obejmuje:

  • różne rodzaje przekrojów modelu projektu systemu informatycznego (funkcjonalny informacyjny i zdarzeniowy)
  • problemy związane z obiektami i nazewnictwem, strukturą i zawartością
  • celem jest usunięcie błędów oraz spójność projektu

Dostosowywanie implementacji do panujących uwarunkowań i ograniczeń

  • bezpieczeństwo systemu
  • czas odpowiedni, określający różne rodzaje wejść
  • niezawodność
  • ograniczenia pozamerytoryczne (np. dostawca sprzętu )
  • ograniczenia związane ze środowiskiem
  • rozmiar danych

Projektowanie szczegółowe obejmuje:

  • elementy projektu dotyczące poziomu fizycznej aplikacji
  • format dokumentów wewy
  • interfejs użytkownika
  • kodowanie informacji
  • problemy związane z eksploatacją
  • procedury
  • strukturę techniczną oraz przestrzenną
  • urządzenia wewy

Kodowanie danych służy:

  • upraszczaniu, skracaniu wprowadzania danych
  • uproszczeniu i przyspieszeniu przetwarzań
  • zapobieganiu redundancji
  • zmniejszeniu ryzyka błędów oraz pomyłek

Istnieją następujące rodzaje kodów:

  • kody zewnętrzne (np. pesel czy kod pocztowy)
  • kody wewnętrzne ( np. Id pracownika)
  • kody do celów projektu (np. moduły czy oznaczenia)

Zasady kodowania:

  • czytelność
  • jednoznaczność
  • kompletność
  • precyzja
  • rozszerzalność
  • użyteczność
  • wygoda użytkowania
  • zwięzłość

Istnieją następujące typy kodów:

  • kody porządkowe (numer kolejny - np. 132)
  • kody klasyfikacyjne (numer pozycyjny - np. 12.56.01)
  • kody mieszane (np. lu2089)
  • kody zawierające cyfrę kontrolną (np. numer pesel)
  • kody mnemoniczne (np. WAR)
  • kody alfabetyczne, numeryczne i mieszane

Cyfra kontrolna wychwytuje błędy zawarte w kodach bez odwoływania się do bazy danych zawierającej zestaw kodów oraz wykrywa nieprawidłowo zdefiniowany kod jeszcze na etapie tworzenia go.

Symbole i kody znajdujące się w projekcie

  • do standardowych oznaczeń zalicza się:
  • format daty i godziny (RR.MM.DD)
  • opis pól i struktur pól w bazie danych oraz projektach we/wy
  • symbole oraz oznaczenia obiektów
  • do oznaczeń obiektów projektu zalicza się:
  • nr lub symbol opcji w projekcie
  • kod podsystemu lub modułu
  • symbol tabulogramu, dokumentu we/wy oraz symbol lub nazwa zbioru lub pliku

Projektowanie interfejsu (GUI - Graficzny Interfejs Użytkownika)

Komunikacja między użytkownikiem i systemem informatycznym obejmuje sterowanie systemem informatycznym w formie poleceń oraz przepływ danych. Wyróżnia się następujące sposoby sterowania systemem informatycznym:

  • polecenia (poprzez linię komend)
  • klawisze sterujące (tzw. skróty)
  • opcje wybierane z menu
  • ikony lub paski narzędziowe
  • przyciski dialogu
  • manipulacja myszą oraz innymi podzespołami wskazującymi

Poziomy użytkownika:

  • początkujący (przedwstępne wyjaśnienia, blokowanie, pomoc kontekstowa)
  • średnio zaawansowany (najszersza grupa, pomoc szczegółowa, indeks, standard interfejsu)
  • eksperci (szybkość dostępu, skróty, indywidualizacja interfejsu)

Przepływ danych:

  • Wejściowych (wprowadzanie): polecenia → odpowiedzi na pytania → dialog
  • Wyjściowych: prezentacja informacji na temat dialogu → raporty → graficzna prezentacja danych

Poprawny interfejs:

  • Spójny (słownictwo, otoczenie, topologia)
  • Prosta obsługa, liczba obiektów od 5 do 9
  • Grupowanie (działań, opcji, kolejność/częstość)
  • Możliwość skrótów dostępowych do funkcji
  • Informacje na temat działań
  • Odwołanie akcji
  • Poczucie spełnienia (informacja, drobne kroki)
  • Wdrażanie kontroli do SI

Cele SI w aspekcie satysfakcji klienta:

  • ograniczanie ilości błędów
  • minimalizacja czasu uczenia się
  • unikanie obciążania pamięci krótkotrwałej użytkownika

Architektura interfejsu graficznego (SDI, MDI)

Okna dialogowe:

  • dezaktywują aplikację oraz wymuszają obsługę
  • klawisze powrotu do programu (co najmniej jeden)

Problemy interakcyjności:

  • translacja na obcy język (problem: prosty styl )
  • zmienność kulturowa oraz prawna (problem: waluty, daty)
  • niuanse dotyczące kultury (problem: kolory np. czarny, czerwony)

Problem języka:

  • gra słów (przykładowo: Bussiness to Bussiness - B2B)
  • skomplikowanego słownictwa
  • metafor
  • tekstów wewnątrz plików graficznych
  • za długich nazw

Urządzenia realizujące interfejs użytkownika:

Wejściowe:

  • czytniki kart kodowych (magnetyczne, perforowane)
  • nośniki optyczne i magnetyczne
  • urządzenia wskazujące (mysz, pióro)
  • terminale
  • teletransmisja

Wyjściowe:

  • wydruki
  • karty kodowe
  • terminale
  • nośniki optyczne i magnetyczne
  • teletransmisja
  • naświetlarka, ploter

Projektowanie - punkt początkowy:

  • typ formularza
  • sposób wypełniania
  • urządzenia techniczne
  • kolory, wzorce, kształt znaków

Typy formularzy:

  • wysyłkowe - wyjściowe (całe druki)
  • pojedyncze kartki - książeczki

Identyfikacja pracy modularnej:

  • wykorzystanie rezultatów
  • przygotowanie informacji do wprowadzania
  • zwiększenie niezawodności prac manualnych (nadmiarowość, kodowanie - kontrola logiczna)
  • przetwarzanie ręczne

Projekt powinien zawierać:

  • strukturę przestrzenną (użytkownik, moduły, sprzęt)
  • projekt struktury technicznej
  • projekt elementów eksploatacyjnych (zabezpieczanie danych, prawo dostępu)
  • strukturę oprogramowania (narzędziowe, wspomagające, systemowe)