Inżynieria oprogramowania - Faza projektowania

1. Celem projektowania jest opracowanie szczegółowego opisu implementacji systemu.

2. Zadania wykonywane w fazie projektowania:
  • uszczegółowienie wyników analizy (np. podanie metod, parametrów; metody jako funkcje wirtualne lub zwyczajne funkcje; zastąpienie niektórych prostych metod bezpośrednim dostępem do atrybutów; zastąpienie niektórych atrybutów redundantnych przez odpowiednie metody)
  • projektowanie składowych systemów nie związanych z dziedziną problemu 
  • optymalizacja systemu 
  • dostosowanie do ograniczeń i możliwości środowiska implementacji 
  • określenie fizycznej struktury systemu 
3. Dodatkowe elementy notacji:
  • wzorce klas
  • metaklasy (klasy zwierające pola i metody dotyczące klasy jako całości a nie pojedynczych obiektów, np. pola i metody statystyczne
  • wolne funkcje (nie będące metodami żadnej z klas)
  • sposoby widoczności obiektu do którego wysyłany jest komunikat
4. Gotowe oprogramowanie musi się jednak składać z dodatkowych składowych:
  • składowej interfejsu użytkownika
  • składowej zarządzania danymi
  • składowej zarządzania pamięcią operacyjną
  • składowej zarządzania zadaniami
5. RAD - Rapin Application Development - określa się narzędzia i techniki programowania umożliwiające szybką budowę prototypów lub gotowych aplikacji.

6. Realizacja komunikacji z użytkownikiem:
  • za pomocą linii komend (dla niewielkich systemów, dla prototypów, dla zaawansowanych użytkowników, często szybszy niż interfejs pełnoekranowy)
  • w pełnoekranowym środowisku okienkowym (tworzenie ma sens dla dużych systemów, wygodny dla początkujących i średnio zaawansowanych użytkowników)
7. Typowe sposoby wydobywania przez użytkownika poleceń systemowych:
  • wpisywanie poleceń za pomocą linii komend
  • wybór opcji z menu
  • wciśnięcie odpowiedniej kombinacji klawiszy (skrótu)
  • korzystanie z ikon w paskach narzędziowych
  • wybór przycisku w dialogu
  • korzystanie z nawigacji kursorem myszy i przycisków myszy
8. Zasady projektowania interfejsu użytkownika:
  • spójność (wygląd i obsługa interfejsu powinna być podobna w momencie korzystania z różnych funkcji)
  • skrótu dla doświadczonych użytkowników (możliwość zastąpienia komend w paskach narzędziowych przez kombinację klawiszy)
  • potwierdzenie przyjęcia zlecenia użytkownika (podczas dłuższych realizacji zleceń należy pokazać np. ilość sekund trwania, lub sekund do przewidywanego zakończenia)
  • prosta obsługa błędów (jeżeli użytkownik wprowadzi błędne dane, to po sygnale błędu system powinien automatycznie przejść do kontynuowania przez niego pracy z poprzednimi poprawnymi wartościami)
  • odwoływanie akcji (system powinien pozwalać cofnąć się)
  • wrażenie kontroli nad systemem (użytkownik musi orientować się co się dzieje w systemie)
  • nieobciążenie pamięci krótkotrwałej użytkownika (system powinien stale wyświetlać informacje, w taki sposób, aby użytkownik wiedział, co aktualnie się dzieje i w którym miejscu interfejsu się znajduje)
  • grupowanie powiązanych operacji (jeżeli zadanie nie da się zamknąć w prostym dialogu lub oknie, wówczas trzeba je rozbić na szereg powiązanych dialogów. Użytkownik powinien być prowadzony przez ten szereg, z możliwością łatwego powrotu do wcześniejszych akcji)
9. Trwałe dane mogą być przechowywane w:
  • pliku
  • w bazie danych
10. Poszczególne elementy danych - zestawy obiektów lub krotek - mogą być przechowywane w następującej postaci:
  • w jednej relacji lub pliku
  • w odrębnym pliku dla każdego rodzaju obiektów lub krotek
11. Sprowadzenie danych do pamięci operacyjnej oraz zapisanie do trwałej pamięci może być:
  • na bieżąco, kiedy program zażąda dostępu i kiedy następuje zapełnienie bufora
  • na zlecenie użytkownika
12. Zalety baz danych:
  • wysoka efektywność i stabilność
  • bezpieczeństwo i prywatność danych, spójność i integralność przetwarzania
  • automatyczne sprawdzanie warunków integralności danych
  • wielodostęp, przetwarzanie transakcji
  • rozszerzalność
  • możliwość geograficznego rozproszenia danych
  • możliwość kaskadowego usuwania powiązanych danych
  • dostęp poprzez języki zapytań (SQL)
13. Wady relacyjnych baz danych:
  • konieczność wprowadzenia nietrywialnych odwzorowań przy przejściu z modelu pojęciowego w strukturę relacyjną
  • ustalony format krotki powodujący trudności przy polach zmiennej długości
  • trudności reprezentacj dużych wartości
  • w niektórych sytuacjach - duże narzuty na czas przetwarzania
  • niedopasowanie interfejsu dostępu do bazy danych (SQL) do języka programowania (np. C)
  • brak możliwości rozszerzalności typów
  • brak systematycznego podejścia do informacji proceduralnej (metod)
14. Bezpośrednia implementacja projektu może doprowadzić o systemu o zbyt niskiej efektywności:
  • wykonanie pewnych funkcji jest zbyt wolne
  • struktury danych mogą wymagać zbyt dużej pamięci operacyjnej i masowej
15. Optymalizacja może być dokonana:
  • na poziomie projektu
  • na poziomie implementacji
16. Sposoby stosowane na etapie implementacji:
  • stosowanie zmiennych statycznych zamiast dynamicznych
  • umieszczanie zagnieżdżonego kodu zamiast wywoływania procedur
  • dobór typów o minimalnej, niezbędnej wartości
17. Co może przynieść zasadnicze zyski optymalizacyjne?
  • zmiana algorytmu przetwarzania
  • wyłowienie "wąskich gardeł"
  • zaprogramowanie "wąskich gardeł" w języku niższego poziomu
  • denormalizacja relacyjnej bazy danych
  • stosowanie indeksów, tablic wskaźników i innych struktur pomocniczych
  • analiza mechanizmów buforowania danych w pamięci operacyjnej i ewentualna zmiana tego mechanizmu
18. Projektant może zetknąć się z wieloma ograniczeniami implementacyjnymi:
  • brak dziedziczenia wielokrotnego
  • brak dziedziczenia
  • brak metod wirtualnych
  • brak złożonych typów
  • brak typów multimedialnych
19, Pod terminem jakość rozumie się bardziej szczegółowe kryteria:
  • spójność
  • stopień powiązania składowych
  • przejrzystość
20. Poprawność oznacza, że opis projektu jest zgodny z zasadami posługiwania się notacjami. Nie gwarantuje, że projekt jest zgodny z wymaganiami użytkownika.

21. Poprawny projekt musi być:
  • kompletny
  • niesprzeczny
  • spójny
  • zgodny z regułami składniowymi notacji
Kompletność projektu oznacza, że zdefiniowane są:
  • wszystkie klasy
  • wszystkie pola (atrybuty)
  • wszystkie metody
  • wszystkie dane złożone i elementarne
a także że opisany jest sposób realizacji wszystkich wymagań funkcjonalnych

22. Spójność projektu oznacza semantyczną zgodność wszystkich informacji zawartych na poszczególnych diagramach i w specyfikacji.

23. Kryteria podziału projektu (i rodzaje spójności):
  • Podział przypadkowy. Podział na moduły (części) wynika wyłącznie z tego, że całość jest za duża (utrudnia wydruk, edycję, itd)
  • Podział logiczny. Poszczególne składowe wykonują podobne funkcje, np. obsługa błędów, wykonywanie podobnych obliczeń.
  • Podział czasowy. Składowe są uruchamiane w podobnym czasie, np. podczas startu lub zakończenia pracy systemu.
  • Podział proceduralny (sekwencyjny). Składowe są kolejno uruchamiane. Dane wyjściowe jednej składowej stanowią wejście innej
  • Podział komunikacyjny. Składowe działają na tym samym zbiorze danych wejściowych i wspólnie produkują zestaw danych wyjściowych
  • Podział funkcjonalny. Wszystkie składowe są niezbędne dla realizacji jednej tej samej funkcji.
24. Na przejrzystość wpływają następujące czynniki:
  • Odzwierciedlenie rzeczywistości. Składowe i ich związki pojawiające się w projekcie powinny odzwierciedlać strukturę problemu. Ścisły związek projektu z rzeczywistością.
  • Spójność oraz stopień powiązania składowych.
  • Zrozumiałe nazewnictwo.
  • Czytelna i pełna specyfikacja
  • Odpowiednia złożoność składowych na danym poziomie abstrakcji.