Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 1

Inżynieria systemów komputerowych

• Inżynieria systemów to czynność specyfikowania, projektowania, implementowania, weryfikowania, wdrażania i pielęgnacji systemów postrzegana jako całość.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 2

Cele• Dowiedzieć się, dlaczego oprogramowanie w systemie

pozostaje pod wpływem ogólniejszych zagadnień inżynierii systemów.

• Być wprowadzonym w pojęcia pojawiających się właściwości systemu takich jak niezawodność, efektywność, bezpieczeństwo i zabezpieczenia.

• Rozumieć, dlaczego w czasie projektowania systemu należy zbadać jego środowisko.

• Rozumieć inżynierię systemów i proces zaopatrywania w system.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 3

Zawartość• Pojawiające się właściwości systemu • Systemy i ich środowiska• Modelowanie systemu• Proces inżynierii systemów • Zaopatrywanie w system

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 4

Co to jest system?• System jest celową kolekcją powiązanych ze sobą

komponentów, które współpracują, aby osiągnąć pewien cel. • Bardzo prosty system, na przykład pióro, jest zrobiony z

trzech lub czterech komponentów sprzętowych.• System kontroli lotów składa się z tysięcy komponentów

programowych i sprzętowych oraz użytkowników, którzy podejmują decyzje na podstawie informacji otrzymanej z systemu.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 5

Problemy instrukcji systemów• Duże systemy są z reguły przeznaczone do

rozwiązywania skomplikowanych zadań.• Inżynieria systemowa wymaga dużego wysiłku

koordynacyjnego:• wzajemne związki pomiędzy komponentami,

• wymóg zrozumienia innych dziedzin inżynierii.

• Systemy muszą być trwałe.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 6

Oprogramowanie, a inżynieria systemowa

• Wzrasta rola oprogramowania np. w powszechnie stosowanych urządzeniach elektronicznych.

• Ogólnie rzec biorąc problemy inżynierii systemów są podobne do problemów inżynierii oprogramowania.

• Przez nieporozumienie problem oprogramowania jest spostrzegany jako problem inżynierii systemowej.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 7

Właściwości systemów• Systemy charakteryzują się tym, że właściwości i

zachowania ich komponentów są nierozerwalnie ze sobą splecione.

• Poprawne działanie każdego z komponentów systemu zależy od funkcjonowania kilku innych komponentów.

• Złożone zależności między komponentami systemu oznaczają, że system jest czymś więcej niż tylko sumą swoich części. Te pojawiające się właściwości (Checkland, 1981) nie mogą być przypisane żadnej części systemu.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 8

Przykłady • Całkowity ciężar systemu

• jest przykładem pojawiającej się właściwości, którą można wyznaczyć z właściwości poszczególnych komponentów .

• Niezawodność systemu • zależy od niezawodności komponentów systemu i związków

między nimi.

• Użyteczność systemu • jest bardzo złożoną właściwością, która nie zależy jedynie od

oprogramowania i sprzętu, ale także od operatorów systemu i środowiska, w którym się go używa .

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 9

Typy pojawiających się właściwości systemu

• Właściwości niefunkcjonalne, • takie jak niezawodność, efektywność, bezpieczeństwo i

zabezpieczenia. Są związane z zachowaniem systemu w jego środowisku pracy. Często są zasadnicze dla systemów komputerowych, ponieważ niepowodzenie w osiągnięciu pewnego zdefiniowanego minimalnego ich poziomu może sprawić, że system będzie bezużyteczny.

• Właściwości funkcjonalne,• które są widoczne, gdy wszystkie części systemu współpracują,

aby osiągnąć pewien cel. Rower ma na przykład cechę funkcjonalną bycia środkiem transportu, gdy scali się go z jego części.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 10

• Niezawodność jest złożonym pojęciem, które zawsze należy badać na poziomie systemu, a nie jego poszczególnych komponentów.

• Komponenty w systemie są od siebie zależne, a zatem awarie w jednym z nich mogą przenosić się na cały system i mieć wpływ na operacje innych systemów.

• Często projektanci systemu nie są w stanie przewidzieć, jak konsekwencje awarii przenoszą się na cały system

• Nie mogą zatem podać wiarygodnych oszacowań niezawodności systemu.

Niezawodność systemu

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 11

• Niezawodność sprzętu • Jakie jest prawdopodobieństwo awarii komponentu sprzętowego i

jak długi jest czas jego naprawy?

• Niezawodność oprogramowania • Jakie jest prawdopodobieństwo wytworzenia przez komponent

programowy błędnych danych wyjściowych? Awarie oprogramowania istotnie różnią się od awarii sprzętu, ponieważ oprogramowanie nie zużywa się.

• Niezawodność operatora• Jakie jest prawdopodobieństwo błędu operatora systemu?

Czynniki wpływające na niezawodność całego systemu

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 12

Zależność czynników niezawodności• Awarie sprzętu mogą spowodować wysłanie fałszywych

sygnałów, które są poza zakresem danych wejściowych spodziewanych przez oprogramowanie. W takim wypadku oprogramowanie może zachować się w sposób nieprzewidywalny.

• Błąd operatora jest najbardziej prawdopodobny w sytuacjach stresowych. Dochodzi do tego najczęściej wówczas, gdy system ulega awarii. Błędy operatora mogą mogą mieć wpływ na działanie sprzętu, co prowadzi do dalszych błędów i tak dalej, i tak dalej.

• Awaria jednego podsystemu, którą można by łatwo naprawić, przeradza się w poważny problem wymagający całkowitego wyłączenia systemu.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 13

Efektywność i użyteczność, bezpieczeństwo i zabezpieczenia

• Efektywność i użyteczność są trudne do oceny, można je jednak zmierzyć po uruchomieniu systemu.

• Bezpieczeństwo i zabezpieczenia: mamy tutaj do czynienia nie z atrybutem ogólnego zachowania systemu, ale z zachowania systemu, które nie powinno mieć miejsca. Np. system zabezpieczony to taki, który nie dopuszcza nieuprawnionego dostępu do swoich danych.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 14

Systemy i ich środowiska• Systemy nie są niezależnymi bytami, ale istnieją w

pewnym środowisku.• Środowisko to ma wpływ na funkcjonowanie i

efektywność systemu.• Czasem środowisko można uważać za system sam

w sobie. • W ogólniejszym wypadku składa się ono z pewnej

liczby oddziałujących na siebie systemów.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 15

Hierarchia systemów

System System System zsypów

zabezpieczeń oświetlenia na śmieci

System System System wodno-

ogrzewania energetyczny kanalizacyjny

Miasto

Ulica

Budynek

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 16

Ludzkie i organizacyjne czynniki obecne w środowisku systemu

• Zmiany procesu• Czy system wymaga zmian w procesach pracy wykonywanej w

środowisku?

• Zmiany zawodu• Czy system zmniejsza umiejętności użytkowników i sprawia, że

muszą zmienić swój styl pracy?

• Zmiany organizacyjne• Czy system zmienia strukturę ośrodków władzy politycznej w

organizacji?

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 17

Modelowanie systemu• W trakcie czynności spisywania wymagań i

projektowania musi powstać model systemu jako zbioru komponentów i związków między nimi.

• Architektura systemu jest zwykle prezentowana jako diagram blokowy, obrazujący najważniejsze podsystemy i połączenia między nimi.

• Każdy podsystem jest rysowany w postaci prostokąta na diagramie blokowym.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 18

Prosty system antywłamaniowy

Syrena

Detektory drzwiowe

Centralka alarmu

Syntezator mowy

Zewnętrzne centrum monitoringu

Detektory ruchu

Automat dzwoniący

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 19

Komponenty funkcjonalne systemu

• Komponenty detektorowe zbierają informacje.• Komponenty efektorowe (uruchamiające) powodują zmiany

w środowisku systemu.• Komponenty obliczeniowe wytwarzają wyniki.• Komponenty komunikacyjne łącza różne komponenty.• Komponenty koordynujące koordynują operacje innych

komponentów.• Komponenty interfejsu przetwarzają reprezentacje danych.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 20

Przykłady komponentów funkcjonalnych systemu

• Komponenty detektorowe• Zbierają informacje ze środowiska systemu. Przykładami takich

komponentów są radary w systemie kontroli lotów, detektory papieru w drukarkach laserowych i termopara w piecu.

• Komponenty efektorowe (uruchamiające)• Powodują zmiany w środowisku systemu. Przykładami takich

komponentów są zawory, które otwierają się i zamykają, aby zwiększyć lub zmniejszyć przepływ cieczy w rurze, stateczniki samolotu, które wyznaczają kierunek lotu, i mechanizm wciągania papieru do drukarki, który przesuwa papier za detektor papieru.

• Komponenty obliczeniowe• Pobierają dane wejściowe, wykonują na nich pewne obliczenia i wytwarzają

wyniki. Przykładem takiego komponentu jest procesor zmiennopozycyjny, który wykonuje obliczenia na liczbach rzeczywistych.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 21

C.d. przykładów komponentów funkcjonalnych systemu

• Komponenty komunikacyjne• Umożliwiają komunikację innym komponentom systemu. Przykładem

takiego komponentu jest sieć łącząca różne komputery wewnątrz budynku.

• Komponenty koordynujące • Koordynują operacje innych komponentów. Np. w układach czasu

rzeczywistego jest to komponent szeregujący zadania.

• Komponenty interfejsu• Przetwarzają dane w reprezentacji używanej przez jedne komponenty na

reprezentacje używane przez inne komponenty. Przykładem może być komponent interfejsu do komunikacji z człowiekiem, który pobiera pewien model systemu i wyświetla go operatorowi. Innym przykładem jest przetwornik analogowo-cyfrowy, który zamienia wejście analogowe na wyjście cyfrowe.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 22

Charakterystyka procesu inżynierii systemów

• Interdyscyplinarna zawiłość:• wiele różnych dziedzin inżynierii wchodzi w skład inżynierii

systemów.

• Ograniczona możliwość modyfikacji systemu w trakcie jego tworzenia:• zmiana raz podjętych decyzji dotyczących systemu często jest

bardzo kosztowna, ale wtedy można jeszcze – odpowiadając na nowe wymagania - wykorzystać elastyczność oprogramowania.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 23

Proces inżynierii systemów

Definicja wymagań

Projektowanie systemu

Tworzenie podsystemów

Integracja systemu

Instalacja systemu

Ewolucjasystemu

Likwidacja systemu

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 24

Interdyscyplinarna zawiłość inżynierii systemów

Inżynieria oprogramowania Inżynieria elektroniczna Inżynieria mechaniczna

Inżynieria strukturalna Inżynieria systemu kontroli lotów Projektowanie

interfejsu użytkownika

Inżynieria lądowa Inżynieria elektrycznaArchitektura

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 25

Rodzaje wymagań systemowych• Trzy rodzaje wymagań:

• abstrakcyjne wymagania funkcjonalne: podstawowe funkcje, które system ma wypełniać są definiowane na wysokim poziomie abstrakcji;

• właściwości systemu: są to niefunkcjonalne, pojawiające się właściwości systemu;

• cechy, których system ma nie mieć: czasem wyspecyfikowanie tego, czego systemowi nie wolno robić, jest tak samo ważne, jak określenie tego, co system powinien robić.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 26

Dwojaki sposób definiowania wymagań systemowych

• Ważną częścią fazy definicji wymagań jest ustalenie zbioru ogólnych celów, które system ma osiągnąć.

• (1) Funkcjonalność systemu• Dostarczyć antywłamaniowy i przeciwpożarowy system alarmowy

biurowca, który na zewnątrz i we wnętrzu wyemituje ostrzeżenie o pożarze lub włamaniu.

• (2) Cele organizacyjne• Zapewnić, aby normalna praca w biurowcu nie była poważnie

zakłócona przez pożary i włamania.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 27

Trudność z określaniem wymagań stawianych systemowi

• Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle „problemami złośliwymi” (Rittel i Webber, 1973). „Problem złośliwy” to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja.

• Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 28

Proces projektowania systemu

• Podziel wymagania• Analizuje się i łączy w grupy powiązane ze sobą wymagania. Zwykle istnieje

kilka możliwych sposobów podziału.

• Zidentyfikuj podsystemy• Identyfikuje się różne podsystemy, które samodzielnie lub zespołowo spełniają

wymagania.

• Przypisz wymagania podsystemom• Przypisuje się wymagania do podsystemów. Teoretycznie powinno to być bardzo

proste, o ile do identyfikacji podsystemów użyto grupowania wymagań.

• Określ funkcjonalność podsystemów• Specyfikuje się poszczególne funkcje realizowane przez podsystemy.

• Zdefiniuj interfejsy podsystemów• Definiuje się interfejsy oferowane i wymagane przez poszczególne podsystemy.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 29

Diagram procesu projektowania systemu

Podziel wymagania

Zdefiniuj interfejsy podsystemów

Przypisz wymagania podsystemom

Zidentyfikuj podsystemy

Określ funkcjonalnośćpodsystemów

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 30

Trudności z określaniem wymagań stawianych systemowi

• Objęcie wymaganiami całego zakresu rozwiązań z rożnymi kombinacjami sprzętu, oprogramowania i pracy ludzkiej.

• Oczekiwanie, ze system będzie od razu funkcjonował bez zarzutu.

• Czynniki natury organizacyjnej i politycznej mają istotny wpływ na wybór rozwiązania.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 31

Tworzenie podsystemów

• W czasie tworzenia podsystemów implementuje się podsystemy zidentyfikowane w trakcie projektowania.

• Proces tworzenia rzadko będzie polegał na budowie wszystkich podsystemów od zera. Na ogół część podsystemów będzie jednak komercyjnymi systemami z półki (Commercial, Off-The-Shelf, COTS) zakupionymi w celu integracji z naszym systemem.

• Różne systemy są zwykle tworzone równolegle.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 32

• Z powodów technicznych i menedżerskich najlepiej jest jednak integrować przyrostowo, tzn. w jednym kroku jest integrowany jeden system.

• Zwykle nie da się ustalić harmonogramów budowania wszystkich podsystemów tak, aby kończyły się w tym samym czasie.

• Integracja przyrostowa zmniejsza koszty wykrywania błędów.

• Awarie podsystemów , które są konsekwencjami niewłaściwych założeń o innych podsystemach, są zwykle wykrywane w trakcie integracji systemu.

Integracja systemu

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 33

• Środowisko, w którym system ma być zainstalowany, jest inne niż to, które zakładali twórcy systemu.

• Potencjalni użytkownicy systemu mogą być wrogami jego wprowadzenia.

• Nowy system ma koegzystować z istniejącym systemem do czasu przekonania firmy, że nowy system pracuje poprawnie.

• Mogą wystąpić fizyczne problemy z instalacją.

Problemy instalacji

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 34

• Uruchomienie systemu może wymagać organizacji sesji szkoleniowych dla operatorów i zmiany normalnego toku pracy.

• Nie wykryte problemy mogą pojawić się w tej fazie, ponieważ specyfikacja systemu mogła zawierać błędy i opuszczenia.

• Współpraca nowego systemu z istniejącymi już systemami:• niekompatybilność,

• zwiększenie liczby błędów operatora, poprzez mylenie poleceń dostępnych w różnych interfejsach.

Działanie systemu

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 35

Ewolucja systemu• Czas życia wielkich złożonych systemów jest bardzo długi.

W trakcie swego działania systemy te musza ewoluować.• Ewolucja oprogramowania jest ze swej natury kosztowna:

• proponowane zmiany muszą być bardzo starannie rozważone z punktu widzenia przedsiębiorstwa i technologii,

• podsystemy nigdy nie są całkowicie niezależne,

• przyczyny pierwotnych decyzji projektowych zwykle nie są zapisywane,

• w miarę starzenia się systemu jego struktura staje się coraz bardziej skomplikowana przez zmiany.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 36

Likwidacja systemu• Likwidacja systemu oznacza wycofanie go po

okresie jego pożytecznego użytkowania.• Utylizacja substancji systemu.• W wypadku samego oprogramowania, w

odróżnieniu od całego systemu, nie ma mowy o żadnych fizycznych problemach z likwidacją.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 37

Zaopatrywanie w system

• Klientami kupującymi złożone systemy komputerowe są zwykle duże przedsiębiorstwa, np. instytucje wojskowe, rządowe i służby ratownicze.

• System może być kupiony jako całość, a także jako zestaw oddzielnych części, które potem się integruje, specyficznie projektuje i wytwarza.

• W wypadku wielkich systemów podjęcie decyzji, którą z tych opcji wybrać, może trwać miesiące, a nawet lata.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 38

Proces zaopatrywania w system

Zaadaptuj wymagania Wybierz system

Wyślij zapytanie ofertowe Wybierz ofertę

Negocjuj kontraktPodpisz kontraktna budowanie

Wybierz dostawcę

Ogłoś przetarg

Zbadaj rynek w poszukiwaniu istniejących

systemów

Systemy z półki są dostępne

Wymagany jest system na zamówienie

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 39

Problemy zaopatrywania

• Komponenty z półki zwykle nie spełniają wymagań idealnie, chyba że napisano te wymagania z myślą o tych właśnie komponentach.

• Gdy system będzie budowany na zamówienie, specyfikacja wymagań jest podstawą kontraktu na zamówienie w system.

• Po wybraniu wykonawcy systemu następuje okres negocjacji kontraktu, w trakcie którego uzgadnia się dalsze zmiany wymagań i omawia różne sprawy, np. koszt zmian.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 40

Wykonawcy i podwykonawcy

• Bardzo wiele firm może samodzielnie projektować, tworzyć i przetestować wszystkie komponenty wielkiego złożonego systemu.

• Wykonawca, którego zwykle nazywamy generalnym, może podpisać kontrakt na zbudowanie rozmaitych podsystemów z pewna liczbą podwykonawców.

• Takie konsorcjum powinno być zdolne do wykonania wszystkich prac związanych z tym typem systemu.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 41

Model wykonawca - podwykonawca

Klient potrzebujący systemu

Generalny wykonawca

Podwykonawca 1 Podwykonawca 2 Podwykonawca 3

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 42

Główne tezy• Inżynieria systemów jest złożonym i trudnym

procesem, który wymaga wkładu pracy specjalistów wielu dziedzin inżynierii.

• Pojawiające się właściwości systemu są charakterystykami systemu jako całości, a nie jego części składowych.

• Architektury systemów zwykle prezentuje się na diagramach blokowych, przedstawiających główne podsystemy i związki między nimi.

Ian Sommerville Inżynieria oprogramowania WNT 2003 Rozdz. 2 Slajd 43

Główne tezy c.d.

• Typami komponentów funkcjonalnych systemu są komponenty detektorowe, komponenty detektorowe, komponenty obliczeniowe, komponenty koordynujące, komponenty komunikacyjne i komponenty interfejsu.

• Proces inżynierii systemów obejmuje specyfikację, projektowanie, tworzenie, integrację i testowanie.

• Proces zaopatrywania w system obejmuje specyfikację systemu, ogłoszenie przetargu, wybór dostawcy i zawarcie kontraktu na dostawę systemu.