Podstawy in\
ynierii oprogramowania
Wykład 2 - In\
ynieria systemów komputerowych
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
Podstawy in\
ynierii oprogramowania
Slajd nr 29
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
Podstawy in\
ynierii oprogramowania
Slajd nr 30
In\
ynieria systemów komputerowych
Przykłady pojawiających się właściwości systemu:
Całkowity cię\
ar systemu;
jest właściwością, która jest wypadkową poszczególnych właściwości komponentów.
Niezawodność systemu;
zale\
y od wszystkich komponentów systemu.
U\
yteczność systemu;
jest bardzo zło\
ona i zale\
y nie tylko od oprogramowania i sprzętu, ale równie\
od
operatorów systemu i środowiska, w którym się go u\
ywa.
Podstawy in\
ynierii oprogramowania
Slajd nr 31
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, gdy\
jest
scalony z poszczególnych części, które współpracują ze sobą.
Niefunkcjonalne  niezawodność, efektywność, bezpieczeństwo i
zabezpieczenia.
Przykład niezawodności systemu
Podstawy in\
ynierii oprogramowania
Slajd nr 32
Pojawiające się właściwości systemu
Istnieją trzy czynniki wpływające na niezawodność całego
systemu;
Niezawodność sprzętu
mierzona prawdopodobieństwem awarii sprzętu komputerowego i czasu jego naprawy.
Niezawodność oprogramowania
mierzona prawdopodobieństwem błędnych danych wyjściowych wytworzonych przez
komponenty systemu.
Niezawodność operatora
mierzona prawdopodobieństwem błędu operatora systemy.
Podstawy in\
ynierii oprogramowania
Slajd nr 33
Zale\
ność czynników niezawodności
Awarie sprzętu mogą powodować wysyłanie fałszywych
sygnałów, które są poza zakresem danych wejściowych
oprogramowania. W konsekwencji mo\
e dojść do
nieprzewidywanych danych na wyjściu oprogramowania.
W sytuacjach, gdy system ulega awarii dochodzi
najczęściej wtedy do błędu operatora, co jest główną
przyczyną stresu. Błędy operatora mogą wywierać wpływ
na działanie sprzętu, co generuje coraz więcej błędów.
Je\
eli awarii ulegnie jeden z podsystemów, który wymaga
prostej naprawy, przeradza siÄ™ w powa\
ny problem, który
jest związany z wyłączeniem całego systemu.
Podstawy in\
ynierii oprogramowania
Slajd nr 34
Systemy i ich środowiska
Systemy nie sÄ… niezale\
nymi bytami ale istniejÄ… w
pewnym środowisku.
Środowisko to ma wpływ na funkcjonalność i efektywność
systemu.
Czasem środowisko jest uwa\
ane za system sam w sobie.
W ogólnym przypadku jest ono składową pewnych
oddziałujących na siebie systemów
Podstawy in\
ynierii oprogramowania
Slajd nr 35
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
Podstawy in\
ynierii oprogramowania
Slajd nr 36
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?
Podstawy in\
ynierii oprogramowania
Slajd nr 37
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
Podstawy in\
ynierii oprogramowania
Slajd nr 38
Modelowanie systemu
Detektory
Detektory ruchu
Drzwiowe
Centralka alarmu
Automat
Syrena Syntezator mowy
dzwoniÄ…cy
Podstawy in\
ynierii oprogramowania
Slajd nr 39
Modelowanie systemu
Detektory ruchu
WykrywajÄ… ruch w monitorowanych pomieszczeniach
Detektory drzwiowe
WykrywajÄ… otwarcie drzwi
Centralka alarmu
Steruje działaniem systemu
Syrena
Nadaje sygnały dz
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
Podstawy in\
ynierii oprogramowania
Slajd nr 40
Radar Transponder Aircraft Telephone
Data comms.
system system comms. system
system
Position Comms. Backup comms.
Backup
processor processor processor
position
processor
ATC system
Flight plan
Aircraft
database
simulation
architecture
system
Weather map
system
Controller Controller
Accounting
info. system consoles
system
Activity logging
system
Podstawy in\
ynierii oprogramowania
©Ian Sommerville 2000 - In\
ynieria oprogramowania
Slajd nr 41
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)
Podstawy in\
ynierii oprogramowania
Slajd nr 42
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)
Podstawy in\
ynierii oprogramowania
Slajd nr 43
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óz
niej
Podstawy in\
ynierii oprogramowania
Slajd nr 44
Proces in\
ynierii systemów
Podstawy in\
ynierii oprogramowania
Slajd nr 45
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
Podstawy in\
ynierii oprogramowania
Slajd nr 46
Inter- dyscyplinarna zawiłość
Podstawy in\
ynierii oprogramowania
Slajd nr 47
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 48
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
Podstawy in\
ynierii oprogramowania
Slajd nr 49
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
Podstawy in\
ynierii oprogramowania
Slajd nr 50
Proces projektowania systemu
Partition
Define sub-system
requirements
interfaces
Identify
Specify sub-system
sub-systems
functionality
Assign requirements
to sub-systems
Podstawy in\
ynierii oprogramowania
Slajd nr 51
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óz
niej.
Nie wszystkie podsystemy budujemy od zera. Czasami
u\
ywamy gotowe
Zwykle ró\
ne podsystemy tworzymy równolegle
Podstawy in\
ynierii oprogramowania
Slajd nr 52
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
Podstawy in\
ynierii oprogramowania
Slajd nr 53
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ą
Podstawy in\
ynierii oprogramowania
Slajd nr 54
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
Podstawy in\
ynierii oprogramowania
Slajd nr 55
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
Podstawy in\
ynierii oprogramowania
Slajd nr 56
Likwidacja systemu
Po okresie funkcjonowania system nale\
y zlikwidować ...
Podstawy in\
ynierii oprogramowania
Slajd nr 57
Zaopatrywanie w system
Proces dostaw podzespołów, bywa skomplikowany i
długotrwały  przetargi publiczne itp..
Podstawy in\
ynierii oprogramowania
Slajd nr 58
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 59
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 60