Model jest abstrakcyjnym obrazem systemu, który pomija pewne jego szczegóły. Mogą powstawać uzupełniające się modele systemu, które obejmują różne informacje o systemie.

W modelach kontekstowych zapisuje się, jak modelowany system jest umiejscowiony w środowisku innych systemów i procesów. Modele architektoniczne, modele procesów i modele przepływu danych mogą być używane jako modele kontekstowe.

Diagramy przepływu danych mogą służyć do specyfikowania przetwarzania danych zachodzącego w systemie. System jest przedstawiany w postaci zbioru przekształceń danych z funkcjami działającymi na tych danych.

Modele maszyn stanowych sa używane do modelowania zachowania systemu, gdy reaguje na zewnętrzne i wewnętrzne zdarzenia.

Prototyp. Aby przedstawić użytkownikom wizję udogodnień systemu, można zbudować jego prototyp. Prototyp może zatem pomóc w określeniu i zatwierdzeniu wymagań systemu.

W miarę wzrostu dążenia do szybkiego dostarczania oprogramowania, prototypowanie jest coraz częściej używane jako standardowa metoda tworzenia małych i średnich systemów w zastosowaniach gospodarczych.

Prototypowanie „z porzuceniem” polega na budowie prototypu, który pomoże w zrozumieniu wymagaÅ„ systemowych. W wypadku prototypowania ewolucyjnego prototyp ewoluuje przez kilka wersji do ostatecznego systemu.

Implementując prototyp porzucany, najpierw buduje się te części systemu, które rozumie się najsłabiej. Przy prototypowaniu ewolucyjnym najpierw buduje się te części systemu, które rozumie się najlepiej.

Tworzenie błyskawiczne jest bardzo ważne w wypadku prototypowych systemów. Aby szybko dostarczyć prototyp, trzeba pominąć pewną część funkcjonalności systemu lub rozluźnić więzy niefunkcjonalne, takie jak czas reakcji i niezawodność.

Metody prototypowania obejmują użycie języków bardzo wysokiego poziomu, programowanie bazy danych i konstrukcję prototypu z komponentów użycia wielokrotnego. Wiele środowisk prototypowania wspomaga twórcze podejście oparte na programowaniu graficznym.

Interfejs użytkownika zawsze należy tworzyć przez prototypowanie, ponieważ ich wyspecyfikowanie w postaci modelu statycznego jest praktycznie niemożliwe. Użytkownicy powinni brać udział w ocenie i ewolucji prototypu.

Metody specyfikacji formalnej systemów uzupełniają metody specyfikacji nieformalnej. Można ich użyć do udoskonalenia szczegółowej, ale specyfikacji nieformalnej wymagań systemowych. Pomagają zatem w zasypaniu przepaści między wymaganiami, a projektowaniem.

Specyfikacje formalne są dokładne i jednoznaczne. Usuwają ze specyfikacji obszary wątpliwe i pozwalają uniknąć niektórych problemów z niewłaściwą interpretacją języka. Niespecjaliści mogą mieć jednak trudności ze zrozumieniem specyfikacji formalnych.

Zasadniczą korzyścią z zastosowania metod formalnych w procesie budowania oprogramowania jest wymuszanie analizy wymagań systemowych już we wczesnej fazie. Poprawianie błędów w tej fazie jest tańsze niż modyfikacja gotowego systemu.

Metody specyfikacji formalnej najbardziej przydają się przy budowaniu systemów krytycznych, w których bezpieczeństwo, niezawodność i zabezpieczenia są szczególnie istotne. Można ich także użyć do określania standardów.

Metody algebraiczne specyfikacji formalnej są szczególnie przydatne do specyfikowania interfejsów, przy czym przez interfejs rozumie się zbiór klas obiektów lub abstrakcyjny typ danych. W tych metodach ukrywa się stan systemu, a system specyfikuje się w kategoriach związków między operacjami interfejsu.

W metodach opartych na modelach system przedstawia się za pomocą pojęć matematycznych, takich jak zbiory i funkcje. Można w nich odwołać się do stanu systemu, co upraszcza niektóre rodzaje specyfikacji zachowania.

Architektura oprogramowania jest zasadniczym zrębem do strukturalizacji systemu. W trakcie projektowania architektonicznego można opracować różne modele architektoniczne, na przykład model strukturalny, model sterowania i model podziału.

Modelami podziału systemu są m.in.. Model repozytorium, model klient-serwer i model maszyny abstrakcyjnej. Repozytorium jest modelem współdzielenia danych we wspólnej składnicy. W modelach klient-serwer dane są zwykle rozproszone. Modele maszyny abstrakcyjnej są warstwowe, przy czym każda warstwa jest zaimplementowana za pomocą udogodnień swojej warstwy podstawowej.

Modelami sterowania są model scentralizowany i model zdarzeń. W modelach scentralizowanych decyzje dotyczące sterowania są podejmowane na podstawie stanu systemu. W modelach zdarzeń systemami sterują zdarzenia zewnętrzne.

Modelami podziału na moduły są model przepływu danych i model obiektowy. Modele przepływu danych są funkcjonalne; modele obiektowe są oparte na luźno zależnych od siebie bytach, które zarządzają swoim stanem i operacjami.

Architektoniczne modele charakterystyczne dla dziedziny są abstrakcjami w ramach dziedziny zastosowań. Mogą być modelami ogólnymi, które są budowane wstępująco z istniejących systemów lub modelami odniesienia, które są wyidealizowanymi abstrakcyjnymi modelami dziedziny.

Systemy rozproszone mogą charakteryzować się współdzieleniem zasobów, otwartością, współbieżnością, skalowalnością, odpornością na awarie i przezroczystością.

Systemy klient-serwer to systemy rozproszone, których modelem jest zbiór usług oferowanych procesom klientów przez serwery.

W systemach klient-serwer interfejs użytkownika działa zwykle u klienta, a zarządzanie danymi jest zawsze wykonywane przez współdzielony serwer. Funkcjonalność użytkowa może być zaimplementowana na komputerze klienta lub na serwerze.

W architekturze obiektów rozproszonych nie ma rozróżnienia na klientów i serwery. Obiekty oferują ogólne usługi, które mogą być wywoływane przez inne obiekty. To podejście można wykorzystać do implementacji systemów klient-serwer.

Systemy obiektów rozproszonych muszą korzystać ze śródprogramów do obsługi komunikacji obiektów oraz dodawania i usuwania obiektów z systemu. Na poziomie projektowym można postrzegać te śródprogramy jako szynę programową, do której podłącza się obiekty.

CORBA jest zbiorem standardów dla śródprogramów do obsługi architektur obiektów rozproszonych. Obejmuje definicje modelu obiektowego, pośrednika zleceń obiektowych i wspólnych usług. Są już dostępne rozmaite implementacje standardów CORBA.

Projektowanie obiektowe jest sposobem projektowania oprogramowania, w którym zasadnicze komponenty projektu odpowiadają obiektom z ich prywatnym stanem i operacjami, a nie funkcjami.

Obiekt powinien mieć operacje konstruktowe i inspekcyjne, które umożliwiają odczyt stanu i jego modyfikację. Obiekt oferuje usługi (operacje korzystające z informacji o stanie) innym obiektom. Obiekty są tworzone w czasie wykonywania na podstawie specyfikacji zawartej w definicji klasy obiektów.

Obiekty można implementować sekwencyjnie lub współbieżnie. Obiekt współbieżny może być pasywny, wówczas jego stan jest zmieniany jedynie przez jego interfejs. Może być też obiektem aktywnym, który zmienia swój stan bez interwencji z zewnątrz.

Unified Modeling Language (UML) obejmuje wiele różnych notacji, które służą do dokumentowania interfejsów obiektów.

System czasu rzeczywistego to system oprogramowania, który musi reagować na zdarzenia w czasie rzeczywistym. Jego poprawność nie zależy tylko od wytwarzanych wyników, ale także od czasu ich wytworzenia.

Uniwersalny model architektury systemu czasu rzeczywistego przewiduje skojarzenie procesu z każdą klasą detektorów i efektorów. Mogą być potrzebne także inne procesy koordynujące.

Projektowanie architektoniczne systemu czasu rzeczywistego polega zwykle na nadaniu systemowi struktury zbioru oddziałujących na siebie procesów współbieżnych.

Moduł wykonawczy czasu rzeczywistego odpowiada za zarządzanie procesami i zasobami. Zawsze obejmuje moduł szeregujący, który jest komponentem podejmującym decyzje o tym, który proces ma się wykonywać. Decyzje o szeregowaniu są podejmowane na podstawie priorytetów procesów.

Systemy monitorowania i sterowania okresowego odpytują zbiór detektorów, które dostarczają informacje ze środowiska systemu. Takie systemy przez wydawanie poleceń efektorom wykonują akcje, które zależą od odczytów detektorów.

Systemy gromadzenia danych są zwykle zgodne z modelem producent-konsument. Proces producenta wkłada dane do bufora cyklicznego, skąd są pobierane do wykorzystania przez konsumenta. Również bufor jest implementowany jako proces, co umożliwia wyeliminowanie konfliktów między producentem, a konsumentem.

Projektowanie z użyciem wielokrotnym polega na projektowaniu oprogramowania zgodnie z istniejącymi przykładami dobrych projektów i wykorzystaniu komponentów programowych tam, gdzie są potrzebne.

Korzyści z użycia wielokrotnego to niższe koszty, szybsze tworzenie oprogramowania i mniej zagrożeń. Przez wykorzystanie wiedzy specjalistów do budowania komponentów użycia zwiększa się niezawodność systemu, a specjaliści są wydajniejsi.

TworzÄ…c komponentowo, polegamy na komponentach „czarnych skrzynkach” z jasno okreÅ›lonymi interfejsami wymaganym i oferowanym. Rodzaje komponentów, które można użyć wielokrotnie, obejmujÄ… funkcje, abstrakcje danych, zrÄ™by i caÅ‚e systemy programów użytkowych.

Użycie wielokrotne produktów COTS polega na wykorzystaniu wielkich systemów z półki. Takie systemy maja mnóstwo funkcjonalności. Ich użycie wielokrotnie może znacząco zmniejszyć koszty i czas tworzenia.

Komponenty programowe, które zaprojektowano z myślą o użyciu wielokrotnym, powinny być niezależne, odzwierciedlać stabilne abstrakcje dziedzinowe i oferować dostęp do swego stanu przez operacje interfejsu oraz nie obsługiwać samemu swoich wyjątków.

Rodziny programów użytkowych zawierają powiązane programy użytkowe, które zbudowano na podstawie co najmniej jednego programu bazowego. Uniwersalny system jest adoptowany i specjalizowany tak, aby spełnił konkretne wymagania dotyczące funkcjonalności, docelowej platformy lub konfiguracji działania.

Wzorce projektowe to abstrakcje wysokiego poziomu, będące dokumentacją udanych rozwiązań projektowych. Są podstawowym sposobem użycia wielokrotnego projektów w tworzeniu obiektowym. Opis wzorca powinien obejmować nazwę wzorca, opis problemu i rozwiązania oraz wyjaśnienie wyników i kompromisów związanych ze stosowaniem wzorca.

Proces projektowania interfejsu użytkownika powinien koncentrować się na użytkowniku. Interfejs powinien porozumiewać się z użytkownikiem za pomocą ich pojęć. Powinien być logiczny i spójny. Powinien zawierać tez udogodnienia pomagające użytkownikom w pracy z systemem i w wycofywaniu się z pomyłek.

Sposoby interakcji z systemem oprogramowanym to m. in. Bezpośrednie działanie, wybór z menu, wypełnianie formularza, języki poleceń i język naturalny.

Informacje należy wyświetlać graficznie, gdy chce się przedstawić trendy i wartości przybliżone. Wyświetlacze cyfrowe powinny być stosowane jedynie wówczas, gdy jest wymagana precyzja.

W interfejsie użytkownika kolory należy używać oszczędnie i spójnie. Projektanci powinni brać pod uwagę, że znacząca liczba osób to daltoniści.

Systemy pomocy powinny oferować dwa rodzaje pomocy: Pomóżcie!, to znaczy „Pomóżcie! Jestem w kÅ‚opotach!” i „Pomożecie?”, to znaczy „Pomożecie? PotrzebujÄ™ informacji”.

Komunikaty obłędach nie powinny sugerować, że użytkownik jest winny. Powinny za to sugerować, jak naprawić błąd, i dawać odsyłacz do systemu pomocy.

Dokumentacja użytkownika powinna obejmować przewodniki dla początkujących i podręczniki. Należy dostarczyć oddzielenie dokumenty dla administratora.

Specyfikacja systemu powinna zawierać (tam gdzie to jest możliwe) ilościowe wartości atrybutów użyteczności. Proces oceny powinien polegać na weryfikacji systemu względem tych wymagań.

---