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

.