Inżynieria oprogramowania
część 2 - Inżynieria systemów komputerowych
Mgr inż. Piotr Greniewski
Europejska Wyższa Szkoła Informatyczno-
Ekonomiczna
Inżynieria oprogramowania
część 2 - Inżynieria systemów komputerowych
Mgr inż. Piotr Greniewski
Europejska Wyższa Szkoła Informatyczno-
Ekonomiczna
Slajd nr 2
©Ian Sommerville 2000 - Inżynieria oprogramowania
Inżynieria systemów komputerowych
Zawartość:
Pojawiające się właściwości systemu
Systemy i ich środowiska
Modelowanie systemu
Proces inżynierii systemów
Zaopatrywanie w system
Slajd nr 3
©Ian Sommerville 2000 - Inżynieria oprogramowania
Inżynieria systemów komputerowych
System jest celową kolekcją powiązanych ze
sobą komponentów, które współpracują aby
osiągnąć pewien cel.
Systemy są hierarchiczne czyli mogą zawierać
inne systemy.
System jest czymś więcej niż sumą swoich
części.
Pojawiające się właściwości nie mogą być
przypisane żadnej części systemu
Slajd nr 4
©Ian Sommerville 2000 - Inżynieria oprogramowania
Inżynieria systemów komputerowych
Przykłady pojawiających się właściwości
systemu:
Całkowity ciężar systemu
Niezawodność systemu
Użyteczność systemu
Slajd nr 5
©Ian Sommerville 2000 - Inżynieria oprogramowania
Pojawiające się właściwości systemu
Pojawiające się właściwości systemu są
atrybutami systemu jako całości. Ich wartość
można zmierzyć dopiero wtedy gdy
podsystemy są zintegrowane w kompletny
system
Dwa typy pojawiających się właściwości:
Funkcjonalne – rower ma cechy środka transportu
Niefunkcjonalne – niezawodność, efektywność,
bezpieczeństwo i zabezpieczenia
Przykład niezawodności systemu
Slajd nr 6
©Ian Sommerville 2000 - Inżynieria oprogramowania
Pojawiające się właściwości systemu
Istnieją trzy czynniki wpływające na
niezawodność całego systemu;
Niezawodność sprzętu
Niezawodność oprogramowania
Niezawodność operatora
Slajd nr 7
©Ian Sommerville 2000 - Inżynieria oprogramowania
Systemy i ich środowiska
Systemy nie są niezależnymi bytami ale
istnieją w pewnym środowisku
Środowisko ma wpływ na funkcjonalność i
efektywność systemu
Slajd nr 8
©Ian Sommerville 2000 - Inżynieria oprogramowania
Systemy i ich środowiska
Inżynierowie systemu muszą znać otoczenie
systemu
System może powodować zmiany w swoim
środowisku. Poprawne działanie systemu możemy
ocenić jedynie na podstawie jego wpływu na
środowisko
Na funkcjonowanie systemu mogą mieć wpływ
trudne do przewidzenia zmiany zachodzące w
środowisku
Slajd nr 9
©Ian Sommerville 2000 - Inżynieria oprogramowania
Systemy i ich środowiska
Systemy działają nie tylko w środowisku
fizycznym ale i organizacyjnym. Czynniki
mające wpływ na na projekt systemu:
Zmiany procesu – czy system wymaga zmian w
procesach pracy wykonywanej w środowisku?
Zmiana zawodu – czy system zmienia styl pracy
pracowników?
Zmiany organizacyjne – czy system zmienia
strukturę władzy w organizacji?
Slajd nr 10
©Ian Sommerville 2000 - Inżynieria oprogramowania
Modelowanie systemu
W trakcie czynności spisywania wymagań i
projektowania musi powstać model systemu jako zbioru
komponentów i związku między nimi
Jest on przedstawiany graficznie jako model architektury
systemu, dający przegląd organizacji systemu
Architektura systemu jest prezentowana jako diagram
blokowy obrazujący najważniejsze systemy i połączenia
między nimi
Każdy podsystem jest rysowany w postaci prostokąta
Związki pomiędzy podsystemami są zaznaczone za
pomocą strzałek łączących prostokąty
Związki obejmują: przepływ danych, relacje ‘używa’,
‘jest używany’ lub inne rodzaje zależności
Slajd nr 11
©Ian Sommerville 2000 - Inżynieria oprogramowania
Modelowanie systemu
Detektory ruchu
Detektory
Drzwiowe
Centralka alarmu
Syrena
Syntezator mowy
Automat
dzwoniący
Slajd nr 12
©Ian Sommerville 2000 - Inżynieria oprogramowania
Modelowanie systemu
Detektory ruchu
Wykrywają ruch w monitorowanych pomieszczeniach
Detektory drzwiowe
Wykrywają otwarcie drzwi
Centralka alarmu
Steruje działaniem systemu
Syrena
Nadaje sygnały dźwiękowe po wykryciu intruza
Syntezator mowy
Nadaje słowny komunikat o położeniu intruza
Automat dzwoniący
Wykonuje zewnętrzne połączenia do firmy
ochroniarskiej i policji
Data comms.
system
Transponder
system
Radar
system
Aircraft
comms.
Telephone
system
Flight plan
database
Backup
position
processor
Position
processor
Comms.
processor
Backup comms.
processor
Aircraft
simulation
system
Weather map
system
Accounting
system
Controller
info. system
Controller
consoles
Activity logging
system
ATC system
architecture
©Ian Sommerville 2000 - Inżynieria oprogramowania
Slajd nr 14
©Ian Sommerville 2000 - Inżynieria oprogramowania
Modelowanie systemu
Architektura systemu powinna być
zaprojektowana w kategoriach funkcjonalnych
podsystemów bez względu na to czy są to
systemy programowe czy sprzętowe
Komponenty funkcjonalne można zaklasyfikować:
Komponenty detektorowe – zbierają informację (np..
Detektor papieru w drukarce )
Komponenty uruchamiające (efektorowe) – powodujące
zmiany w środowisku systemu (np.. Mechanizm
wciągania papieru w drukarce)
Komponenty obliczeniowe - pobierają dane wejściowe,
wykonują na nich pewne obliczenia i wytwarzają wyniki
(np.. Procesor zmiennoprzecinkowy)
Slajd nr 15
©Ian Sommerville 2000 - Inżynieria oprogramowania
Modelowanie systemu
Komponenty funkcjonalne cd.
Komponenty komunikacyjne – umożliwiają
komunikację innym komponentom systemu (np..siec
ethernet w budynku)
Komponenty koordynujące - koordynują operacje
innych komponentów (np.. Proces szeregujący w
systemie czasu rzeczywistego)
Komponenty interfejsu – przetwarzają dane w
reprezentacji używanej jedne komponenty na
reprezentacje używane przez inne komponenty (np..
Przetwornik analogowo - cyfrowy)
Slajd nr 16
©Ian Sommerville 2000 - Inżynieria oprogramowania
Proces inżynierii systemów
Istotne różnice między procesem inżynierii
systemów a procesem tworzenia
oprogramowania:
Interdyscyplinarna zawiłość – wiele różnych dziedzin
inżynierii wchodzi w skład inżynierii systemów. Możliwe
są więc nieporozumienia
Ograniczona możliwość modyfikacji w trakcie tworzenia
systemu – gdy pewne decyzje techniczne są już podjęte
to wszelkie zmiany są bardzo kosztowne.
Fazy procesu inżynierii systemów są
przedstawione na następnym slajdzie
Proces ten miał duży wpływ na model kaskadowy,
który omówimy później
Slajd nr 17
©Ian Sommerville 2000 - Inżynieria oprogramowania
Proces inżynierii systemów
System
integration
Sub-system
development
System
design
Requirements
definition
System
installation
System
evolution
System
decommissioning
Slajd nr 18
©Ian Sommerville 2000 - Inżynieria oprogramowania
Proces inżynierii systemów
Omówimy teraz system ATC - kontroli lotów w
którym używa się radarów i innych
detektorów do wyznaczania pozycji
samolotów.
następny slajd pokazuje różne dyscypliny,
których specjaliści muszą być obecni w
zespole inżynierii systemów
Slajd nr 19
©Ian Sommerville 2000 - Inżynieria oprogramowania
Inter- dyscyplinarna zawiłość
ATC systems
engineering
Electronic
engineering
Electrical
engineering
User interface
design
Mechanical
engineering
Architecture
Structural
engineering
Software
engineering
Civil
engineering
Slajd nr 20
©Ian Sommerville 2000 - Inżynieria oprogramowania
Proces inżynierii systemów
W tego typu systemach oprogramowanie musi
być bardzo elastyczne i dlatego wiele
niespodziewanych problemów zostawia się
inżynierom oprogramowania (np.. Położenie
radaru powoduje powstanie podwójnego
obrazu. Przeniesienie radaru jest niemożliwe,
trzeba modyfikować oprogramowanie.
Inżynierowie oprogramowania często stają
przed zadaniem zwiększenia możliwości
oprogramowania bez zwiększania kosztu
sprzętu co czasami prowadzi do porażki nie z
winy oprogramowania.
Slajd nr 21
©Ian Sommerville 2000 - Inżynieria oprogramowania
Proces inżynierii systemów
Definiowanie wymagań systemowych ma na celu
odkrycie wymagań stawianych systemowi jako
całości. Proces ten tak jak w przypadku wymagań
dla oprogramowania obejmuje konsultacje z
klientami i użytkownikami. Najczęściej
uwzględniamy trzy rodzaje wymagań:
Abstrakcyjne wymagania funkcjonalne – podstawowe
funkcje są definiowane na wysokim poziomie abstrakcji
Właściwości systemu – są to wymagania niefunkcjonalne
takie jak: dostępność, efektywność i bezpieczeństwo
Cechy których system ma nie mieć – np.. Nie podawać
kontrolerowi zbyt dużej ilości informacji
Slajd nr 22
©Ian Sommerville 2000 - Inżynieria oprogramowania
Proces inżynierii systemów
Projektowanie systemu ma na celu określenie jak
funkcjonalność systemu będzie realizowana przez
jego poszczególne komponenty. Czynnościami tego
procesu są:
Podział wymagań
Identyfikacja podsystemów
Przypisanie wymagań podsystemom
Określenie funkcjonalności podsystemów
Zdefiniowanie interfejsów podsystemów
Strzałki dwukierunkowe oznaczają, że pomiędzy
każdą parą istnieje wiele iteracji i sprzężeń
zwreotnych
Dla niemal wszystkich systemów istnieje wiele
projektów realizacji
Slajd nr 23
©Ian Sommerville 2000 - Inżynieria oprogramowania
Proces projektowania systemu
Partition
requirements
Identify
sub-systems
Assign requirements
to sub-systems
Specify sub-system
functionality
Define sub-system
interfaces
Slajd nr 24
©Ian Sommerville 2000 - Inżynieria oprogramowania
Tworzenie podsystemów
W czasie tworzenia implementuje się
podsystemy zidentyfikowane w czasie
projektowania
Jeśli jest to podsystem oprogramowania to
rozpoczyna się proces tworzenia
oprogramowania o czym później.
Nie wszystkie podsystemy budujemy od zera.
Czasami używamy gotowe
Zwykle różne podsystemy tworzymy
równolegle
Slajd nr 25
©Ian Sommerville 2000 - Inżynieria oprogramowania
Integracja systemu
Integracja systemu polega na scaleniu
zbudowanych podsystemów w jeden kompletny
system. Najlepiej robić to przyrostowo tzn. w
jednym kroku integrowany jest jeden system
Powody stosowania metody przyrostowej:
Zwykle nie da się ustalić jednej daty uruchomienia
podsystemów
Integracja przyrostowa zmniejsza koszty wykrywania
błędów.
Awarie podsystemów, które są konsekwencjami
niewłaściwych założeń o innych podsystemach,
zwykle są wykrywane na etapie integracji systemu
Slajd nr 26
©Ian Sommerville 2000 - Inżynieria oprogramowania
Instalacja systemu
W trakcie instalacji system jest umieszczany w
środowisku w którym ma działać. Powstaje
przy tym wiele problemów:
Środowisko w którym ma działać system jest inne
niż zakładali twórcy. Występuje najczęściej w chwili
instalacji podsystemów oprogramowania
Potencjalni użytkownicy mogą być wrogami jego
wprowadzenia
Nowy system ma koegzystować z istniejącym
systemem do czasu stwierdzenia jego poprawności
Mogą wystąpić fizyczne problemy z instalacją
Slajd nr 27
©Ian Sommerville 2000 - Inżynieria oprogramowania
Działanie systemu
Po instalacji system zaczyna działać
Wymagane są szkolenia personelu
Pojawiają się przypadki nie uwzględnione w
wymaganiach
System działa zgodnie z wymaganiami ale
funkcjonalnie nie spełnia prawdziwych
potrzeb przedsiębiorstwa
Mogą wystąpić problemy z przeniesieniem
danych pomiędzy starym a nowym systemem
Slajd nr 28
©Ian Sommerville 2000 - Inżynieria oprogramowania
Ewolucja systemu
Czas życia systemów bywa bardzo długi
W trakcie życia system podlega ewolucji aby
usunąć błędy w założeniach
Firma może się zreorganizować
Kupowany jest nowy sprzęt komputerowy
Ewolucja systemu jest bardzo kosztowna
Slajd nr 29
©Ian Sommerville 2000 - Inżynieria oprogramowania
Likwidacja systemu
Po okresie funkcjonowania system należy
zlikwidować ...
Slajd nr 30
©Ian Sommerville 2000 - Inżynieria oprogramowania
Zaopatrywanie w system
Proces dostaw podzespołów, bywa
skomplikowany i długotrwały – przetargi
publiczne itp..
Slajd nr 31
©Ian Sommerville 2000 - Inżynieria oprogramowania
Proces zaopatrywania w system
Choose
supplier
Issue request
for bids
Choose
system
Adapt
requirements
Survey market for
existing systems
Let contract for
development
Negotiate
contract
Select
tender
Issue request
to tender
Off-the-shelf
system available
Bespoke system
required
Slajd nr 32
©Ian Sommerville 2000 - Inżynieria oprogramowania
Model wykonawca/podwykonawca
Sub-contractor 2
Sub-contractor 1
Sub-contractor 3
Principal
contractor
System
customer
Slajd nr 33
©Ian Sommerville 2000 - Inżynieria oprogramowania
Główne tezy
Inżynieria systemów jest złożonym i trudnym procesem,
który wymaga wkładu pracy specjalistów wielu innych
dziedzin inżynierii.
Pojawiające się właściwości są charakterystykami systemu
jako całości, a nie jego części składowych. Są to m.in.
efektywność, niezawodność, użyteczność, bezpieczeństwo i
zabezpieczenia. Powodzenie lub porażka systemu często
zależy od tych pojawiających się właściwości.
Architekturę systemu prezentuje się na diagramach
blokowych, przedstawiających główne podsystemy i związki
między nimi.
Typami komponentów funkcjonalnych systemu są
komponenty detektorowe, komponenty efektorowe,
komponenty obliczeniowe, komponenty koordynujące,
komponenty komunikacyjne i komponenty interfejsu.
Slajd nr 34
©Ian Sommerville 2000 - Inżynieria oprogramowania
Główne tezy
Proces inżynierii systemów obejmuje specyfikację,
projektowanie, tworzenie, integrację i testowanie.
Integracja systemów (łączenie podsystemów od
różnych dostawców tak, aby współpracowały) jest
zwykle najtrudniejsza i najważniejsza.
Proces zaopatrywania w system obejmuje specyfikację
systemu, ogłoszenie przetargu, wybór dostawcy i
zawarcie kontraktu na dostawę systemu. Niektóre
części systemu są kupowane jako komercyjne
komponenty z półki
.