1 Oprogramowanie

Są to programy komputerowe, cała związana z nimi dokumentacja i dane konfiguracyjne

Rodzaje produktów oprogramowania

-Powszechne

-Dostosowane (na zamówienie)

Co to jest inżynieria oprogramowania?

Jest to dziedzina inżynierii, która obejmuje wszystkie aspekty tworzenia oprogramowania od fazy początkowej do jego pielęgnacji

Inżynierowie oprogramowania pracują w sposób systematyczny i uporządkowany ponieważ jest to najskuteczniejszy sposób tworzenia oprogramowania wysokiej jakości

Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyka ?

Zasadniczo informatyka obejmuje teorie i podstawowe zasady działania komputerów. Inżynieria oprogramowania obejmuje praktyczne problemy związane z tworzeniem oprogramowania

Byłoby dobrze gdyby inżynier programowania znał teorie informatyczne, z drugiej strony nie zawsze przystają one do rzeczywistości

Jaka jest różnica pomiędzy inżynierią oprogramowania a inżynierią systemów?

Inżynieria systemów komputerowych obejmuje wszystkie aspekty tworzenia i ewolucji systemów komputerowych, w których oprogramowanie odgrywa zasadniczą rolę.

Inżynierowie systemów biorą udział w specyfikacji systemu i definiowania jego ogólnej architektury

2 Etyczne elementy Inż Opr.

Etyczne dylematy

-Zasadnicza niezgodność z z poglądami przełożonego

-Nieetyczne postępowanie pracodawcy np. przy fałszowaniu dzienników kontroli przy testowaniu krytycznego systemu

-Uczestnictwo w tworzeniu systemów wojskowych i nuklearnych

Odpowiedzialność etyczna i zawodowa

Inżynierowie oprogramowania muszą zaakceptować fakt, że ponoszą znacznie większą odpowiedzialność niż tylko wynikająca z ich technicznych umiejętności

Muszą postępować etycznie i moralnie, jeśli chcą być uważani za profesjonalistów

Zachowywać się etycznie, to więcej niż tylko przestrzegać obowiązujące prawo

Zasady zawodowej odpowiedzialności

Zachowywanie tajemnicy

Inżynierowie powinni zawsze dochowywać tajemnic powierzonych przez pracodawców i klientów, niezależnie od tego czy podpisano formalną umowę o ochronie tajemnicy.

Kompetencje

Inżynierowie nie powinni zawyżać poziomu swoich kompetencji. Nie powinni świadomie przyjmować prac, które przekraczają ich możliwości.

Zasady zawodowej odpowiedzialności

Prawo własności intelektualnej

Inżynierowie powinni znać miejscowe prawo regulujące korzystanie z własności intelektualnej. Powinni szczególnie dbać o poszanowanie intelektualnej własności swoich pracodawców i klientów.

Niewłaściwe użycie komputera

Inżynierowie oprogramowania nie powinni używać swoich umiejętności do niewłaściwego używania cudzych komputerów. Niewłaściwe użycie może być dość banalne (np. granie na maszynie pracodawcy) lub skrajnie poważne (rozsiewanie wirusów).

Kodeksy etyczne i zawodowe

Stowarzyszenia zawodowe w USA współpracują ze sobą przy publikowaniu kodeksów profesjonalnego zachowania i kodeksy etyczne.

Omówiony poniżej kodeks zawiera osiem zasad dotyczących zachowania i decyzji profesjonalnych inżynierów oprogramowania oraz nauczycieli, zarządzających, kierowników, strategów, a także studentów.

3 Podstawowe wasności systemów

-Konkretny zbiór właściwości zależy od zastosowania, niemniej można podąć ogólny zbiór właściwości

-Zdolność do pielęgnacji

-Zdolność do ewolucji zgodnie z potrzebami klientów

-Niezawodność

-Nie powinno powodować fizycznych lub ekonomicznych katastrof w przypadku awarii

-Efektywność

-Nie powinno marnotrawić zasobów systemu takich jak pamięć czy czas procesora

-Użyteczność

-Powinno być użyteczne, bez zbędnego wysiłku ze strony użytkownika (np. interfejsy)

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.

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ść sprzętu

Niezawodność oprogramowania

Niezawodność operatora

Efektywność i użyteczność

Są trudne do oceny, można je jednak zmierzyć po uruchomieniu systemu.

Mamy do czynienia nie z atrybutem ogólnego zachowania systemu, ale z zachowania systemu, które nie powinno mieć miejsca.

System zabezpieczony to taki, który nie dopuszcza nieuprawnionego dostępu do swoich danych.

4 Tworzenie ewolucyjne

Tworzenie badawcze

Celem procesu jest praca z klientem, polegająca na badaniu wymagań i dostarczeniu ostatecznego systemu. Tworzenie rozpoczyna się od tych części systemu, które są dobrze rozpoznane. System ewoluuje przez dodawanie nowych cech, które proponuje klient.

Prototypowanie z porzuceniem

Celem procesu tworzenia ewolucyjnego jest zrozumienie wymagań klienta i wypracowanie lepszej definicji wymagań stawianych systemowi. Budowanie prototypu ma głównie na celu eksperymentowanie z tymi wymaganiami użytkownika, które są niejasne.

5 Podstawowe metody projektowania

Model przepływu danych

Model strukturalny

Model obiektowy

6 Podział systemów CASE

- Narzędzia wspomagające poszczególne zadania w ramach procesu, np. s sprawdzania spójności projektu, kompilacji programu, porównywania wyników testów itd.

- Warsztaty wspomagają całe fazy procesów lub czynności, np. specyfikowanie, projektowanie itd.

- Środowiska wspomagają całość lub znaczną część procesu tworzenia oprogramowania.

7 Wymagania funkcjonalne i niefunkcjonalne

Wymagania funkcjonalne

stawiane systemowi opisują funkcjonalność lub usługi, które system powinien oferować.

Zależą od rodzaju tworzonego oprogramowania, spodziewanych użytkowników oprogramowania i rodzaju wytwarzanego systemu.

Gdy mają postać wymagań użytkownika, ich opis jest zwykle bardziej ogólny, natomiast wymagania funkcjonalne systemowe szczegółowo definiują funkcje systemu, jego wejścia, wyjścia, wyjątki itd.

Niefunkcjonalne

Mogą definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia i reprezentacje danych używane przez interfejsy systemu.

Przykładami wymagań stawianych procesowi są specyfikacja standardów jakości, których należy użyć w procesie, stwierdzenie, że projekt należy opracować za pomocą konkretnego zbioru narzędzi CASE, i opis procesu, którego należy przestrzegać.

Wymagania niefunkcjonalne wynikają z potrzeb użytkownika, ograniczeń budżetowych, strategii firmy, konieczności współpracy z innymi systemami sprzętu lub oprogramowania, czynników zewnętrznych.

8 Model procesu????????????????

Jest to uproszczona prezentacja procesu tworzenia oprogramowania. Modele ze swej natury są uproszczeniami .

Przykłady:

Model przepływu prac

Model przepływu danych (lub model czynności)

Model rola-akcja

Przykłady ogólnych modeli (paradygmatów) tworzenia oprogramowania:

Model kaskadowy

Tworzenie ewolucyjne

Formalne przekształcenia

Składanie systemu z komponentów ponownego użycia

9 Programowanie BD

Większość gospodarczych programów użytkowych obejmuje przetwarzanie danych z bazy danych i generowanie wyników, które polega na organizowaniu i formatowaniu danych.

Programowanie bazy danych jest wykonywane w specjalizowanym języku, który ma wbudowaną wiedzę o bazie danych i zawiera operacje służące do pracy z bazą danych.

Pojęcie język czwartej generacji (4GL) obejmuje zarówno język programowania bazy danych, jak i wspomagające go środowisko. Interfejs użytkownika składa się zwykle ze zbioru standardowych formularzy i arkuszy kalkulacyjnych.

10 Zalety systemów obiektywnych

Systemy powinny być łatwe w pielęgnacji, ponieważ obiekty są niezależne.

Można je poznawać i modyfikować jako samodzielne byty.

Zmiana implementacji obiektu lub dodanie usług nie powinno mieć wpływu na obiekty systemowe.

Obiekty są skojarzone z bytami, zwykle więc istnieje jasne odwzorowanie bytów świata rzeczywistego (np. komponentów sprzętowych) na sterujące nimi obiekty w systemie. Zwiększa to zrozumiałość i zarazem zdatność do pielęgnacji systemu.

11 Omówić proces tworzenia oprogramowania

Specyfikowanie oprogramowania. Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane.

Projektowanie i implementowanie oprogramowania. Oprogramowanie, które spełnia specyfikację, musi być stworzone.

Zatwierdzenie oprogramowania. Wytworzone oprogramowanie musi spełniać oczekiwania klienta.

Ewolucja oprogramowania. Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkowników.

12 Co rozumiemy pod pojęciem odpowiedzialność etyczna i zawodowa

Inżynierowie oprogramowania muszą zaakceptować fakt, że ponoszą znacznie większą odpowiedzialność niż tylko wynikająca z ich technicznych umiejętności

Muszą postępować etycznie i moralnie, jeśli chcą być uważani za profesjonalistów

Zachowywać się etycznie, to więcej niż tylko przestrzegać obowiązujące prawo

Zachowywanie tajemnicy

Inżynierowie powinni zawsze dochowywać tajemnic powierzonych przez pracodawców i klientów, niezależnie od tego czy podpisano formalną umowę o ochronie tajemnicy.

Kompetencje

Inżynierowie nie powinni zawyżać poziomu swoich kompetencji. Nie powinni świadomie przyjmować prac, które przekraczają ich możliwości.

Prawo własności intelektualnej

Inżynierowie powinni znać miejscowe prawo regulujące korzystanie z własności intelektualnej. Powinni szczególnie dbać o poszanowanie intelektualnej własności swoich pracodawców i klientów.

Niewłaściwe użycie komputera

Inżynierowie oprogramowania nie powinni używać swoich umiejętności do niewłaściwego używania cudzych komputerów. Niewłaściwe użycie może być dość banalne (np. granie na maszynie pracodawcy) lub skrajnie poważne (rozsiewanie wirusów).

13 Co rozumiemy pod pojęciem niezawodność systemu

Dla części technicznej systemu informacyjnego, cecha ta określa odporność na awarie techniczne, oraz zdolność do zapewnienia nieprzerwanego funkcjonowania systemu.

Niezawodność w części podmiotowej i organizacyjnej reguluje kwestie bezpieczeństwa danych, konstrukcji planów awaryjnych i organizacyjne askepty usuwania skutków awarii.

14 Ewolucja systemu- przykład

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.

Przykładem może tu posłużyć system operacyjny firmy Microsoft – Windows XP, który ewoluował poprzez dostarczane nieodpłatnie przez producenta, pakiety zwane Service Pack (1-3),  zawierające nowe funkcje i/lub zbiorczą aktualizację bezpieczeństwa dla oprogramowania, udostępnione najczęściej w postaci pojedynczego, łatwego do zainstalowania pliku.

15 Omów tworzenie formalne systemów

Tworzenie formalne systemów jest podejściem, które ma wiele wspólnego z modelem kaskadowym. Proces tworzenia jest tu jednak oparty na matematycznych przekształceniach specyfikacji systemu w program wykonywalny.

W procesie przekształcania formalna matematyczna reprezentacja systemu jest metodycznie przekształcana w bardziej szczegółowe, ale wciąż matematycznie poprawne reprezentacje systemu.

Podejście z przekształceniem złożone z ciągu małych kroków jest łatwiejsze w użyciu. Wybór, które przekształcenie zastosować, wymaga jednak dużych umiejętności.

Najlepiej znanym przykładem takiego formalnego procesu tworzenia jest Cleanroom, pierwotnie opracowany przez IBM (Proces Cleanroom jest oparty na przyrostowym tworzeniu oprogramowania, gdy formalnie wykonuje się każdy krok i dowodzi jego poprawności.)

Oprócz specjalistycznych dziedzin procesy oparte na przekształceniach formalnych są używane rzadko.

Wymagają specjalistycznej wiedzy i w praktyce okazuje się, że w wypadku większości systemów nie powodują zmniejszenia kosztów lub polepszenia jakości w porównaniu z innymi podejściami.

Interakcje systemów nie poddają się łatwo specyfikowaniu formalnemu.

16 Omów projektowanie i wyszukiwanie błędów

Programiści wykonują pewne testy kodu, który napisali. Często prowadzi to do wykrycia błędów, które należy usunąć z programu.

Testowanie usterek i usuwanie błędów to dwa różne procesy.

Lokalizacja błędu może wymaga nowych przypadków testowych.

Ciągle często projektowanie jest działaniem ad hoc, gdzie wymagania zapisuje się w języku naturalnym.

Lepsze podejście polega na użyciu metod strukturalnych, które są zbiorami notacji i porad dla projektantów oprogramowania. Ich użycie polega zwykle na opracowaniu graficznych modeli systemu i prowadzi do dużej ilości dokumentacji projektowej.

Metody strukturalne mogą obejmować:

modele przepływu danych,

modele encja-związek,

modele strukturalne,

modele obiektowe.

17 Etnografia

To metoda obserwacji, która może służyć do rozpoznawania wymagań społecznych i organizacyjnych.

Analityk pogrąża się w środowisku pracy, w którym system będzie używany.

Obserwuje codzienną pracę i odnotowuje podstawowe zadania wykonywane przez pracowników.

Zaleta etnografii jest to, że pomaga odkrywać niejawne wymagania systemowe odzwierciedlające rzeczywiste, a nie formalne procesy, w których biorą udział ludzie.

Rzeczywista praktyka pracy biurowej jest znacznie bogatsza, bardziej złożona i dynamiczna niż przewidywana przez proste modele w systemach automatyzacji biura.

Różnica między zakładem, a rzeczywistym trybem pracy jest najważniejsza przyczyną nikłego wpływu tych systemów biurowych na wydajność pracy.

Innymi studiami etnograficznymi nad rozpoznawaniem wymagań systemowych były prace nad systemem kontroli lotów i rozmaite działania projektowe.

18 Co to są metody formalne

Analiza matematyczna stanowi rutynowa składową procesu opracowywania i zatwierdzania projektu produktu.

Tak zwane „metody formalne” budowy oprogramowania nie są szeroko stosowane w przemysłowym wytwórstwie oprogramowania.

Pojęcie „metod formalnych” obejmuje:

Specyfikowanie formalne systemu

Analizowanie i dowodzenie specyfikacji

Proces tworzenia z przekształceniem

Weryfikowanie programów

Specyfikacja formalna jest doskonałym sposobem na wykrycie błędów w specyfikacji i przedstawienie specyfikacji systemu w sposób jednoznaczny.

W systemach, w których nie można dopuścić do awarii, użycie metod formalnych może być uzasadnione i opłacalne.

Metody formalne są coraz częściej stosowane w wyspecjalizowanej dziedzinie tworzenia systemów krytycznych.

Na ogół formalne matematyczne specyfikacje leżą gdzieś między wymaganiami systemowymi a specyfikacja projektu oprogramowania.

Nie obejmują detali implementacyjnych, ale powinny stanowić pełny model matematyczny systemu.

We wczesnych etapach procesu najważniejsza jest specyfikacja nastawiona na użytkownika.

Końcowy etap procesu, który obejmuje stworzenie pełnej, spójnej i precyzyjnej specyfikacji, jest jednak zasadniczo zadaniem zleceniobiorcy. Stanowi on podstawę implementacji systemu. Ta precyzyjna specyfikacja może być specyfikacja formalną.

-Podejście algebraiczne

Opisuje się system w kategoriach operacji i związków.

- Podejście oparte na modelach

Buduje się model systemu za pomocą pojęć matematycznych, takich jak zbiory i ciągi; operacje systemu definiuje się przez wywoływane przez nie zmiany stanu systemu.

19 Wymienić zalety jawnego projektowania

Komunikacja z uczestnikami

Architektura jest prezentacją systemu na wysokim poziomie, która może służyć za podstawę dyskusji w gronie różnych uczestników.

Analiza systemu

Ujawnienie architektury systemu we wczesnej fazie budowania systemu daje możliwość przeprowadzenia pewnej analizy. Decyzje projektowania architektonicznego mają znaczący wpływ na to, czy system może spełnić krytyczne wymagania dotyczące efektywności, niezawodności i zdatności do pielęgnacji, czy nie.

Użycie wielokrotne w wielkiej skali

Architektura systemu jest zwartym i łatwym do opanowania opisem organizacji systemu i współpracy jego komponentów. Architekturę można przekazywać innym systemom, które mają podobne wymagania.

20 Omówić architekture zintegrowanego zestawu narzedzi CASE

21 CASE = 36

22 Jakie są podstawowe cele inżynierii systemów komputerowych

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

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

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 ?

24 Model wykonawca-podwykonawca

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.

25 Omówić tworzenie z użyciem wielokrotnym

W większości dyscyplin inżynieryjnych proces projektowania jest oparty na użyciu wielokrotnym komponentów.

Podstawą projektów są komponenty, które wypróbowano i przetestowano w innych systemach.

Obecnie powszechnie uważa się, że w wypadku tworzenia oprogramowania potrzebne jest podobne podejście. Oprogramowanie powinno być uważane za składnik majątku. Użycie wielokrotne tego składnika majątku jest zasadniczym warunkiem zwiększenia stopy zwrotu z inwestycji w jego tworzenie.

Użycie wielokrotne systemów programów użytkowych.

Można ponownie użyć cały system programów użytkowych przez włączenie go w niezmienionej postaci do innych systemów albo budowę rodziny programów użytkowych działających na różnych platformach lub dostosowanych do potrzeb konkretnych użytkowników.

Użycie wielokrotne komponentów.

Można wielokrotnie używać komponentów programu użytkowego mających różne rozmiary, od podsystemów do pojedynczych obiektów.

Użycie wielokrotne funkcji.

Można wielokrotnie użyć komponenty programowe, takie jak pojedyncze funkcje matematyczne.

Zwiększona niezawodność

Zmniejszone zagrożenie procesu

Efektywne wykorzystanie specjalistów

Zgodność ze standardami

Przyspieszone tworzenie

Musi istnieć możliwość znalezienia odpowiedniego komponentu użycia wielokrotnego.

Osoba ponownie używająca komponent musi być przekonana, że będzie on działał zgodnie ze specyfikacją i będzie niezawodny.

Komponenty muszą mieć dokumentację, która pomoże osobie pragnącej je wykorzystać w zrozumieniu ich i zaadaptowaniu do nowych zastosowań.

26 Podstawowe wymagania stawiane oprogramowaniu

Wymagania użytkownika

To wyrażenia w języku naturalnym oraz diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach, w których system ma działać.

Wymagania systemowe

Szczegółowo ustalają usługi systemu i ograniczenia. Dokumentacja wymagań systemowych, zwana czasem specyfikacją funkcjonalną, powinna być precyzyjna.

Specyfikacja projektu oprogramowania

Jest abstrakcyjnym opisem projektu oprogramowania, który jest podstawa bardziej szczegółowego projektu i implementacji.

Wymagania funkcjonalne

Jakie usługi ma oferować system

Jak ma reagować na określone dane wejściowe

Jak ma się zachowywać w określonych sytuacjach

Czego nie powinien robić

Wymagania niefunkcjonalne

Ograniczenia usług i funkcji systemu

Np. ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.

Wymagania dziedzinowe

Pochodzą z dziedziny zastosowania

Mogą być funkcjonalne lub niefunkcjonalne.

27 Model maszyn stanowych

Służą do opisywania zachowania systemu, gdy reaguje na wewnętrzne lub zewnętrzne zdarzenia.

Zawierają stany i zdarzenia, które powodują przejścia z jednego stanu do innego.

Nie obejmuje przepływu danych w ramach systemu.

Modele maszyn stanowych są integralna częścią metod projektowania systemów czasu rzeczywistego.

W metodzie Harela wprowadzono tzw. grafy stanów (statecharts), które są podstawą notacji do modelowania maszyn stanowych w UML.

28 Prototypowanie oprogramowania

Prototyp oprogramowania pomaga w dwóch czynnościach inżynierii wymagań:

Określenie wymagań. Prototypy systemu umożliwiają użytkownikom eksperymentowanie, w celu sprawdzenia czy system pomaga im w pracy. Dzięki temu użytkownicy wpadają na nowe pomysły itp.

Zatwierdzanie wymagań. Prototyp może ujawnić błędy i pominięcia w zaproponowanych wymaganiach.

Inne cele:

Szkolenia użytkowników

Testowanie systemu

Prototypowanie

Prototypowanie ewolucyjne- zaczyna się od zbudowania prostego systemu spełniającego wymagania użytkowników. Jest on następnie modyfikowany w marę poznawania wymagań. Ostatecznie staje się systemem, którego oczekiwano.

Prototypowanie z porzuceniem -służy do udoskonalania i wyjaśnienia specyfikacji. Po napisaniu specyfikacji prototyp jest porzucany.

Cele

Celem prototypowania ewolucyjnego jest dostarczenie użytkownikowi działającego systemu.

Celem prototypowania z porzuceniem jest zatwierdzenie i dostarczenie wymagań.

29 Architektury systemów rozproszonych

Architektury klient-serwer

W tym podejściu system jest postrzegany jako zbiór usług oferowanych klientom, którzy z nich korzystają. W takich systemach odmiennie traktuje się serwery i klientów.

Architektury obiektów rozproszonych

W tym podejściu nie istnieje rozróżnienie między klientami i serwerami. System jest postrzegany jako zbiór komunikujących się obiektów, których położenie jest nieistotne. Nie ma różnicy między dostawcą i użytkownikiem usług.

Różne komponenty systemu rozproszonego mogą być zaimplementowane za pomocą rozmaitych języków programowania i działać na zupełnie innych rodzajach procesorów.

Modele danych, reprezentacja informacji i protokoły komunikacyjne mogą być całkowicie odmienne.

System rozproszony musi zatem zawierać oprogramowanie, które będzie zarządzać tymi różnorodnymi częściami oraz zapewni im możliwość komunikacji i wymiany danych.

Do takiego oprogramowania odnosi się podejście śródprogramu (middleware), które znajduje się w środku różnych rozproszonych komponentów systemu.

30 Strategie obiektowe

Analiza obiektowa polega na opracowaniu modelu obiektowego dziedziny zastosowania. Rozpoznane obiekty odzwierciedlają byty i operacje związane z rozwiązywanym problemem.

Projektowanie obiektowe polega na opracowaniu modelu obiektowego systemu oprogramowania, który będzie implementacją zidentyfikowanych wymagań. Obiekty projektu obiektowego są związane z rozwiązaniem problemu.

Programowanie obiektowe polega na realizacji projektu oprogramowania za pomocą języka programowania obiektowego. Języki obiektowe, takie jak Java, umożliwiają bezpośrednią implementację obiektów i dostarczają udogodnienia do definiowania klas obiektów.

Pojęcia „obiekt” i „obiektowy” są obecnie często używane. Stosuje się je do różnych typów bytów, metod projektowania, systemów i języków programowania.

Istnieje ogólna zgoda, że obiekt jest obudową informacji. Oddaje to definicja obiektu i klasy obiektów.

31 Proces tworzenia oprogramowania = 34

32 System komputerowych

System komputerowy – układ współdziałania dwóch składowych: sprzętu komputerowego oraz oprogramowania, działających coraz częściej również w ramach sieci komputerowej. Można mówić o następujących poziomach takiego systemu: sprzęt komputerowy, system operacyjny (oprogramowanie systemowe), oprogramowanie użytkowe (aplikacje). W pełni zautomatyzowany system komputerowy działa bez udziału człowieka.

Organizacja systemu komputerowego to opis zależności sprzętowych, przedstawienie poszczególnych podzespołów komputera który funkcjonuje według pewnych reguł i zasad, współpracuje ze sobą – by osiągnąć określony cel. Organizacja systemu komputerowego określa zasady, reguły, cele oraz sposób wspomagania działań poszczególnych podzespołów.

Warstwy systemu komputerowego

Struktura systemu komputerowego składa się z pięciu zasadniczych warstw tj. warstwa sprzętowa, system operacyjny, programy narzędziowe, programy użytkowe i użytkownicy.

Sprzęt – zapewnia podstawowe możliwości obliczeniowe (procesor, pamięć, urządzenia wejścia/wyjścia) – podstawowe zasoby systemu komputerowego.

Oprogramowanie systemowe – kontroluje i koordynuje użycie zasobów sprzętowych poprzez różne programy użytkowe dla różnych użytkowników. Warstwa tworzona poprzez twórców systemu operacyjnego – są to zazwyczaj wysoko wyspecjalizowani specjaliści.

Oprogramowanie narzędziowe – wspomaga zarządzanie zasobami sprzętowymi poprzez dogodne interfejsy użytkowe oraz usprawnia, modyfikuje oprogramowanie systemowe, zazwyczaj pisane przez niezależnych programistów którzy mają na celu usprawnienia wykonywania programów w bardziej wygodny i wydajny sposób, a przy tym często eliminują błędy czy też niedociągnięcia oprogramowania systemowego.

Oprogramowanie użytkowe – określają sposoby, w jakie zostają użyte zasoby systemowe do rozwiązywania problemów obliczeniowych zadanych przez użytkownika (kompilatory, systemy baz danych, gry, oprogramowanie biurowe), tworzone przez programistów.

Użytkownicy – ludzie, maszyny, inne komputery, mają bezpośredni kontakt z oprogramowaniem użytkowym.

33 Przykład hierarhii systemów

34 Proces tworzenia oprogramowania = 31

Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu programowego. Może to być tworzenie oprogramowania od zera, ale coraz częściej nowe oprogramowanie powstaje przez rozszerzanie i modyfikowanie istniejących systemów.

Specyfikowanie oprogramowania. Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane.

Projektowanie i implementowanie oprogramowania. Oprogramowanie, które spełnia specyfikację, musi być stworzone.

Zatwierdzenie oprogramowania. Wytworzone oprogramowanie musi spełniać oczekiwania klienta.

Ewolucja oprogramowania. Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkowników.

Model kaskadowy

W tym modelu podstawowe czynności specyfikowania, tworzenia, zatwierdzania i ewolucji są odrębnymi fazami procesu.

Tworzenie ewolucyjne

W tym procesie czynności specyfikowania, projektowania i zatwierdzania przeplatają się.

Tworzenie formalne systemu

To podejście jest oparte na budowaniu formalnych matematycznych specyfikacji systemu i przekształcaniu tych specyfikacji w program za pomocą metod matematycznych.

Tworzenie z użyciem wielokrotnym

W tym podejściu zakłada się istnienie dużej liczby komponentów zdatnych do ponownego użycia.

35 Tworzenia spiralne

Model spiralny (tworzenie spiralne) – jeden z modeli procesów tworzenia oprogramowania.

Proces tworzenia ma postać spirali, której każda pętla reprezentuje jedną fazę procesu. Najbardziej wewnętrzna pętla przedstawia początkowe etapy projektowania, np. studium wykonalności, kolejna definicji wymagań systemowych, itd.Spis treści

Model

Każda pętla spirali podzielona jest na cztery sektory:

Ustalanie celów - Definiowanie konkretnych celów wymaganych w tej fazie przedsięwzięcia. Identyfikacja ograniczeń i zagrożeń. Ustalanie planów realizacji.

Rozpoznanie i redukcja zagrożeń - Przeprowadzenie szczegółowej analizy rozpoznanych zagrożeń, ich źródeł i sposobów zapobiegania. Podejmuje się odpowiednie kroki zapobiegawcze.

Tworzenie i zatwierdzanie - Tworzenia oprogramowania w oparciu o najbardziej odpowiedni model, wybrany na podstawie oceny zagrożeń.

Ocena i planowanie - Recenzja postępu prac i planowanie kolejnej fazy przedsięwzięcia bądź zakończenie projektu.

Cechy

Widoczną cechą modelu spiralnego jest szczegółowe potraktowanie zagrożeń realizacji projektu. Dobrze rozpoznane zagrożenia i przedsięwzięte kroki im zapobiegania lub redukcji skutkują m.in. wysoką niezawodnością (dependability) powstającego oprogramowania, bądź pewnością, że projekt ma szanse dalszej realizacji.

W modelu spiralnym nie ma takich faz jak specyfikowanie albo projektowanie. Jeden cykl spirali może przebiegać w oparciu o model kaskadowy procesu tworzenia oprogramowania, w innym można użyć prototypowania lub przekształceń formalnych, w zależności od aktualnego etapu przedsięwzięcia / realizowanej części systemu (np. inny dla tworzenia interfejsu użytkownika, inny dla krytycznych funkcji bezpieczeństwa)

Każdy cykl wymaga formalnej decyzji o kontynuacji projektu.

Zalety

Można wykorzystać gotowe projekty

Faza oceny w każdym cyklu pozwala uniknąć błędów lub wcześniej je wykryć

Cały czas istnieje możliwość rozwijania projektu.

Wady

Metodologia nie do końca dopracowana. Każdy projekt jest inny i powstaje w innych warunkach. Ciężko określić jakie warunki brać pod uwagę.

Tworzenia w oparciu o model spiralny wymaga doświadczenia w prowadzeniu tego typu projektów oraz często wiedzy ekonomicznej w zarządzaniu.

36 Technologia CASE

Komputerowo wspomagana inżynieria oprogramowania (CASE) korzysta z różnego oprogramowania do wspomagania czynności procesu tworzenia oprogramowania, takich jak inżynieria wymagań, projektowanie, programowanie i testowanie.

Czynności, które można zautomatyzować za pomocą CASE:

oprogramowanie graficznych modeli systemu jako części specyfikacji wymagań i projektu oprogramowania,

czynności projektu za pomocą słownika danych, który przechowuje informacje o encjach i związkach w projekcie,

generowanie interfejsu użytkownika na podstawie graficznego opisu interfejsu opracowanego interaktywnie przez użytkownika,

śledzenie błędów przez udostępnienie informacji o wykonującym się programie,

automatyczne tłumaczenie programów ze starych wersji języków programowania.

Klasyfikacja narzędzi CASE pomaga zrozumieć różne typy narzędzi oraz ich rolę we wspomaganiu czynności tworzenia oprogramowania. Klasyfikacje prowadzić z:

perspektywy funkcjonalności, w której klasyfikuje się narzędzia CASE względem ich specyficznej funkcji;

perspektywy procesu, w której klasyfikuje się narzędzia CASE względem wspomaganych przez nie czynności procesu;

perspektywy integracji, w której klasyfikuje się narzędzia CASE względem sposobu ich integracji w spójne jednostki, które oferują wspomaganie jednej lub więcej czynności procesu.

37 Specyfikacja wymagań w PDL

Wymagania są określane przy użyciu języka opisu programów, który zawiera instrukcje zwiększające wyrazistość.

Do stosowania gdy:

Funkcja jest ciągiem akcji, a kolejność wykonania tych akcji jest istotna

Trzeba wyspecyfikować interfejsy programowe lub sprzętowe

Wady

W PDL nie da się wyrazić wymagań dziedzinowych

Specyfikacja jest traktowana jako projekt a nie jako specyfikacja

38 Notacja UML

Jest to uniwersalna notacja, która może służyć do modelowania maszyn stanowych rozmaitych typów.

Prostokąty z zaokrąglonymi rogami oznaczają stany systemu. Zawierają krótką informację (po słowie „do”) o akcjach wykonywanych w tym stanie.

Strzałki z etykietkami reprezentują bodźce, które powodują przejścia między stanami.

Notacja używana do oznaczenia klas obiektów jest zdefiniowana przez UML. Klasa obiektów jest przedstawiana jako nazwany prostokąt z dwoma sekcjami. Atrybuty obiektu są wymieniane w górnej sekcji. Operacje związane z obiektem są wymieniane w dolnej sekcji.

39 Zalety stosowania prototypowania ewolucyjnego

Przyspieszone dostarczanie systemu. W niektórych wypadkach błyskawiczne dostarczanie i użyteczność są znacznie ważniejsze niż funkcjonalność lub zdatność do pielęgnacji w długim okresie.

Włączenie użytkownika w budowę systemu. Udział użytkowników w procesie budowania powoduje nie tylko to, że system ma więcej szans spełnienia ich wymagań. Oznacza także akceptację systemu przez użytkowników, którzy będą chcieli, żeby dobrze działał.

40 Proces projektowania obiektowego

Zrozumienie i zdefiniowanie kontekstu oraz modelu użytkowania systemu.

Zaprojektowanie architektury systemu.

Identyfikacja głównych obiektów systemu.

Opracowanie modeli projektowych.

Wyspecyfikowanie interfejsów obiektów.