Modelowanie i analiza systemów informatycznych.

Transkrypt

1 Modelowanie i analiza systemów informatycznych. dr Robert Plebaniak 2 grudnia 2013 roku

2 Metodyka RUP Wykład 10

3 Metodyka RUP Metodyka RUP

4 Metodyka RUP Znaczenie iteracyjno-przyrostowego procesu projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany zestaw metod i procedur o charakterze technicznym i organizatorskim, pozwalających zespołowi projektowemu realizować cykl życia systemu. Ogólnie metodyki można podzielić na strukturalne, obiektowe i społeczne.

5 Metodyka RUP Podejście obiektowe Podobnie jak w przypadku metodyk strukturalnych, pojawił się szereg propozycji związanych z modelowaniem obiektowym. Największe uznanie zdobyły podejścia OMT, OOAD i OOSE, inkorporujące pewne elementy metodyki. Pierwsza próba unifikacji obiektowego procesu tworzenia systemu nosiła nazwę USDP (Unified Software Development Process). Autorami USDP są l. Jacobson, G. Booch oraz J. Rumbaugh. Jest to metodyka rodzajowa (ang. generic), stwarzająca możliwość opracowywania różnych jej konfiguracji i implementacji.

6 Metodyka RUP Metodyka rodzajowa Do głównych cech tego podejścia należą: ukierunkowanie na przypadki użycia; potraktowanie architektury systemu jako centralnego zagadnienia w procesie tworzenia oprogramowania; iteracyjno-przyrostowy charakter procesu tworzenia systemu.

7 Metodyka RUP RUP RUP (ang. Rational Unified Process ) to metodyka tworzenia systemów informatycznych oparta na paradygmacie obiektowości i języku UML, zaproponowana przez korporację Rational Software. Jako kompletna metodyka RUP zawiera następujące elementy: przyrostowo-iteracyjny cykl życia systemu; pojęcia, metody i techniki z zakresu języka UML i inne, w tym heurystyczne; zintegrowany pakiet narzędzi CASE, wspomagający stosowanie elementów metodyki; role zdefiniowane w zespole projektowym i procedury zarządzania projektem; kryteria oceny i monitorowania postępu prac; hipertekstową bazę wiedzy; internetowy serwis wspomagający metodykę i jej użytkowników.

8 Metodyka RUP RUP Metodyka RUP jest ukształtowana w sposób umożliwiający dopasowanie procesu tworzenia systemu do potrzeb konkretnego przedsięwzięcia na podstawie pełnego spektrum swoich możliwości. W efekcie RUP jest elastyczny - znajduje zastosowanie zarówno przy mniejszych, jak i dużych projektach informatycznych.

9 Metodyka RUP Rozwój metodyki RUP

10 Metodyka RUP RUP Najważniejsze obszary zmian w zakresie metodyki związane były z: rozwijaniem poszczególnych dyscyplin, w tym przepływów pracy oraz dotyczących ich dokumentów; wprowadzeniem modułów dodatkowych (ang. plug-ins) RUP oraz integracją i włączaniem nowych narzędzi CASE, wspomagających metodykę RUP; reorganizacją układu hipertekstowej bazy wiedzy; zdefiniowanymi w metodyce artefaktami - modelami i dokumentami.

11 Metodyka RUP USDP Założenia rodzajowej metodyki USDP, iteracyjno-przyrostowy cykl życia systemu, a także kategorie modelowania języka UML wykorzystywane są przez inne, aktualnie rozwijane metodyki obiektowe. Do najbardziej interesujących należą: XP (Extreme Programming); Agile; Scrum, DSDM (Dynamie Systems Development Method).

12 Metodyka RUP Struktura RUP Przez kilka dekad dominującym wzorcem cyklu życia systemu był cykl liniowy, a później spiralny. Metodyka RUP opiera się na zasadniczym novum - iteracyjno przyrostowym (ang. iterative-incremental) cyklu życia systemu. Ma on postać dwuwymiarową.

13 Metodyka RUP Struktura RUP Linia pozioma reprezentuje czas, a zatem dynamiczny aspekt procesu TSI, uwzględniając: fazy; iteracje; punkty przeglądu. Z kolei linia pionowa odzwierciedla statyczny aspekt procesu TSI, tj. jego opis w kategoriach: dyscyplin; czynności; artefaktów; ról; przepływów pracy.

14 Metodyka RUP Struktura RUP

15 Metodyka RUP Rola Rola oznacza obowiązki i kompetencje osoby lub zespołu zaangażowanego w proces tworzenia systemu informatycznego lub jego wycinka. W wyniku realizacji roli powstają oczekiwane artefakty. Spektrum ról, odpowiadających często współczesnym zawodom informatycznym, jest bardzo szerokie i wiąże się z możliwościami zaawansowanych technologii informatycznych. Przykładami ról w metodyce RUP są: menadżer projektu, inzynier procesu, analityk procesów biznesowych, analityk systemowy, projektant testów, testujacy, specjalista ds. narzędzi CASE. Przepływ pracy - stanowi sekwencję czynności, w wyniku której powstaje lub jest przetwarzany artefakt.

16 Metodyka RUP Dyscypliny Dyscyplina (ang. discipline), jest kolekcją powiązanych czynności, artefaktów, ról oraz przepływów pracy odpowiadających tematycznie głównym obszarom tworzenia systemów informatycznych.

17 Metodyka RUP Dyscypliny podstawew Dyscypliny podstawowe stanowią rdzeń procesu tworzenia systemu. Należą do nich: modelowanie biznesowe; specyfikacja wymagań; analiza i projektowanie; programowanie; testowanie; wdrożenie.

18 Metodyka RUP Dyscypliny wspomagające Dyscypliny wspomagające realizują funkcje zarządcze i konfiguracyjne w procesie tworzenia systemu. Można do nich zaliczyć: zarządzanie konfiguracjami i zmianami; zarządzanie projektem; przygotowanie środowiska.

19 Metodyka RUP Układ i zależności pomiędzy wymienionymi dyscyplinami

20 Metodyka RUP Podstawowy zakres merytoryczny dyscyplin w procesie RUP Modelowanie biznesowe (ang. - business modeling) zawiera wizję nowej, docelowej organizacji, definicje występujących w jej ramach procesów, ról i zakresów odpowiedzialności. Informacje te przedstawia się w postaci biznesowych diagramów. Specyfikacja wymagań (ang. requirements) - oznacza opracowanie wizji systemu, modelu przypadków użycia i zdefiniowanie wymagań niefunkcjonalnych.

21 Metodyka RUP Podstawowy zakres merytoryczny dyscyplin w procesie RUP Analiza i projektowanie (ang. analysis and design ) - zawiera analizę i projekt systemu z wykorzystaniem całego spektrum diagramów UML. Programowanie (ang. implementation ) - pozwala na opracowanie kodu źródłowego w wybranym języku programowania oraz kompilację kodu i integrację komponentów. Testowanie (ang. test) - oznacza planowanie testów oraz ocenę systemu poprzez wykonanie szeregu testów.

22 Metodyka RUP Podstawowy zakres merytoryczny dyscyplin w procesie RUP Wdrożenie (ang. deployment ) - dotyczy instalacji oprogramowania systemu i formalną akceptację kolejnych wersji systemu przez klienta czy użytkownika. Zarządzanie konfiguracjami i zmianami (ang. configuration and change menagement) - obejmuje kontrole wersji artefaktów opracowanych podczas kolejnych iteracji. Zarządzanie projektem (ang. project menagement) - oznacza planowanie i kontrole realizacji projektu. Przygotowanie środowiska (ang. environment) - obejmuje przygotowanie infrastruktury dla skutecznej realizacji projektu.

23 Metodyka RUP Fazy Fazą (ang. phase) w metodyce RUP jest okres między kolejnymi punktami przeglądu cyklu iteracyjno-przyrostowego, w którym zrealizowano niezbędne czynności i opracowano adekwatne artefakty. Metodyka RUP wprowadza cztery fazy: rozpoczęcie (ang. inception); opracowanie (ang. elaboration); budowa (ang. construction); przekazanie (ang. transition).

24 Metodyka RUP Iteracje System informatyczny jest rozwijany w kolejnych iteracjach (ang. iterations), występujących w ramach każdej z wymienionych faz. Przejście pomiędzy iteracjami poprzedza przyrostowa integracja artefaktów otrzymanych we wszystkich dotychczasowych iteracjach. Iteracja w metodyce RUP to pojedynczy cykl w ramach fazy, polegający na realizacji czynności poszczególnych dyscyplin; jej efektem jest kolejny przyrost systemu.

25 Metodyka RUP Fazy w metodyce RUP i ich cele Rozpoczęcie (ang. inception) - wypracowanie ogólnej wizji przedsięwzięcia oraz osiągnięcie zrozumienia i akceptacji projektu ze strony wszystkich jego uczestników. Opracowanie (ang. elaboration) - ustalenie architektury systemu, stworzenie planu projektu oraz wyeliminowanie elementów wysokiego ryzyka z projektu. Budowa (ang. construction) - stworzenie systemu na podstawie przyjętej architektury. Przekazanie (ang. transition) - dostarczenie gotowego systemu użytkownikom czy klientom.

26 Modelowanie biznesowe Modelowanie biznesowe

27 Modelowanie biznesowe Znaczenie modelowania biznesowego W procesie tworzenia systemu zgodnym z metodyką RUP pierwszą dyscypliną iteracyjno-przyrostowego cyklu życia systemu jest modelowanie biznesowe. Modelowanie biznesowe (ang. business modeling) jest sposobem odwzorowywania i dokumentowania procesów biznesowych. W nawiązaniu do kategorii modelowania języka UML, wyróżnić można: modelowanie systemowe - ukierunkowane na tworzenie systemu informatycznego, jego oprogramowania oraz infrastruktury sprzętowej; modelowanie biznesowe.

28 Modelowanie biznesowe Reengineering Modelowanie biznesowe można połączyć z reengineeringiem procesów biznesowych (ang. Business Process Reengineering) - w skrócie BPR - w przypadku, gdy zamierza się dokonać radykalnej zmiany funkcjonowania organizacji i opracować modele nowych procesów biznesowych. Modele biznesowe znajdują zastosowanie przede wszystkim w pierwszej fazie cyklu życia RUP, fazie rozpoczęcia, a w mniejszym zakresie także w kolejnych fazach (opracowaniu, budowie oraz przekazaniu).

29 Modelowanie biznesowe Modelowanie biznesowe w procesie tworzenia systemu

30 Modelowanie biznesowe Podstawowe kategorie pojęciowe oraz notacja graficzna Model biznesowy, podobnie jak model systemu informatycznego, jest przedstawiany w postaci diagramów. Diagramy biznesowe są w ujęciu czysto technicznym odpowiednikami diagramów systemowych. Tak więc możliwe jest przystosowanie do potrzeb modelowania biznesowego większości diagramów wymienionych w specyfikacji języka UML 2.0, czyli: diagramów przypadków użycia; diagramów klas; diagramów obiektów; diagramów czynności; diagramów maszyny stanowej; diagramów interakcji; diagramów struktur połączonych; diagramów pakietów.

31 Modelowanie biznesowe Praktyczne zastosowanie Ze względu na specyfikę funkcjonowania rzeczywistych organizacji największe praktyczne zastosowanie mają następujące rodzaje diagramów biznesowych: biznesowe diagramy przypadków użycia; biznesowe diagramy klas; biznesowe diagramy czynności; biznesowe diagramy sekwencji; biznesowe diagramy pakietów.

32 Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych W przypadku modelowania biznesowego niezbędne stają się kategorie modelowania, które nie są elementami diagramów opisujących oprogramowanie. Kategorie te mają charakter stereotypów graficznych. Biznesowe diagramy stworzone w ramach modelowania biznesowego są transformowane w kolejnych fazach iteracyjno-przyrostowego cyklu RUP w analityczne lub systemowe diagramy języka UML. Transformacja diagramów biznesowych w systemowe nie zachodzi automatycznie. Do osiągnięcia ostatecznego efektu modelowania systemowego niezbędna jest praca analityczna i projektowa twórców systemu, stosownie do zaleceń UML i RUP.

33 Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych

34 Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych

35 Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych

36 Modelowanie biznesowe Biznesowy kontekst systemu księgarni

37 Modelowanie biznesowe Biznesowy diagram przypadków użycia systemu księgarni

38 Modelowanie biznesowe Mapa procesów biznesowych funkcjonowania księgarni

39 Modelowanie biznesowe Czynność przypadku Dokonaj zakupu

40 Modelowanie biznesowe Biznesowy diagram sekwencji

41 Modelowanie biznesowe Biznesowy diagram klas

42 Modelowanie biznesowe Biznesowy diagram klas z pracownikami biznesowymi

43 Modelowanie biznesowe Jednostki organizacyjne księgarni

44 Modelowanie biznesowe Zależność pomiędzy działami a pracownikami

45 Modelowanie biznesowe Koniec wykładu 10.

46 Modelowanie analityczne Wykład 11

47 Modelowanie analityczne Modelowanie analityczne

48 Modelowanie analityczne Znaczenie modelowania analitycznego Modelowanie analityczne to technika wspomagająca język UML, która słóży do dokumentowania wyników prac analitycznych i wczesnych prac projektowych. Diagramy modelowania analitycznego wspomagają dyscyplinę analizy i projektowania; zostały zaproponowane przez I. Jacobsona w metodyce OOSE [Jacobson-1992]. W praktyce diagramy te umożliwiają przejście od diagramów przypadków użycia oraz ich scenariuszy do diagramów klas oraz diagramów interakcji na poziomie konceptualnym i implementacyjnym.

49 Modelowanie analityczne Diagram modelowania analitycznego w procesie tworzenia systemu

50 Modelowanie analityczne Podstawowe kategorie pojęciowe oraz notacja graficzna Model analityczny (ang. analysislrobustness model), grupujący diagramy analityczne, można traktować jako rodzaj wstępnego projektu. Jego celem jest wspomaganie identyfikacji klas. Podstawowymi elementami diagramów modelowania analitycznego są: klasy analityczne; aktorzy; związki.

51 Modelowanie analityczne Notacja graficzna Diagramy analityczne modelowane są jako diagramy klas z zastosowaniem trzech stereotypowanych klas: granicznych (ang. boundary); sterujących (ang. control); przechowujących (ang. entity).

52 Modelowanie analityczne Notacja W praktyce podczas analizy scenariuszy przypadku użycia identyfikuje się obiekty analityczne, które podczas projektowania systemu ulegają przekształceniu w różne kategorie modelowania właściwe dla poziomu implementacyjnego, takie jak atrybuty klas, operacje lub same klasy. W związku z tym te kategorie modelowania analitycznego w literaturze przedmiotu określane są często mianem obiektów analitycznych.

53 Modelowanie analityczne Notacja oraz charakterystyka klas analitycznych

54 Modelowanie analityczne Notacja oraz charakterystyka klas analitycznych

55 Modelowanie analityczne Notacja oraz charakterystyka klas analitycznych

56 Modelowanie analityczne Notacja oraz charakterystyka W trakcie opracowywania diagramów modelowania analitycznego wykorzystywany jest również symbol aktora zaczerpnięty z diagramów przypadków użycia. Poszczególne typy klas są powiązane. Kluczowe znaczenie odgrywa w tym kontekście związek asocjacji, przy czym asocjacje te mogą być dwukierunkowe lub mieć przypisany kierunek nawigacji uszczegóławiający specyfikację sposobu przepływu informacji.

57 Modelowanie analityczne Diagram analityczny

58 Modelowanie analityczne Zasady obowiązujące w diagramach modelowania analitycznego Przyjmujemy nastepujce oznaczenia; symbol + oznacza, że elemanty wyszczególnione w danym wierszu i kolumnie mogą się łączyć; symbol - łączenie elementów wyszczgólnionych w danym wierszu i kolumnie jest niepoprawne.

59 Modelowanie analityczne Zasady obowiązujące w diagramach modelowania analitycznego

60 Modelowanie analityczne Proces tworzenia modelu analitycznego Tworzenie diagramów modelowania analitycznego poprzedzone jest w ramach iteracyjno-przyrostowego procesu RUP modelowaniem biznesu oraz specyfikacją wymagań tworzonego systemu w postaci systemowych diagramów przypadków użycia. Stąd proces ten można podzielić na następujące etapy: 1. wyselekcjonowanie, stosownie do złożoności dziedziny przedmiotowej, odpowiednich: diagramów modelu biznesowego, diagramu (diagramów) przypadków użycia oraz jego (ich) scenariuszy; 2. przeniesienie aktorów z diagramów przypadków użycia na diagramy analityczne; 3. identyfikacją klas analitycznych i określenie ich rodzajów; 4. integracją poszczególnych zidentyfikowanych elementów w formie diagramów analitycznych składających się na model analityczny.

61 Modelowanie analityczne Konwersja kategorii biznesowych na kategorie klas analitycznych W trakcie tego procesu obowiązują określone zasady konwersji z modeli biznesowych i systemowych diagramów przypadków użycia na kategorie diagramów modelowania analitycznego. Analogicznie, należy zauważć, że sporządzenie klas analitycznych na podstawie systemowych przypadków użycia nie polega na bezpośredniej zamianie notacji. Konwersja systemowego modelu przypadków użycia na modele analityczne obejmuje przekształcenie aktorów w klasy graniczne bądź ich bezpośrednie przeniesienie. Natomiast przypadki użycia są przekształcane w odpowiednie rodzaje klas analitycznych - graniczne, sterujące i przechowujące. W dalszych iteracjach RUP klasy analityczne przekształcane są w klasy systemu.

62 Modelowanie analityczne Konwersja kategorii biznesowych na kategorie klas analitycznych

63 Modelowanie analityczne Konwersja kategorii biznesowych na kategorie klas analitycznych

64 Modelowanie analityczne Model analityczny

65 Komputerowe wspomaganie modelowania systemu Komputerowe wspomaganie modelowania systemu

66 Komputerowe wspomaganie modelowania systemu Pakiety CASE wspomagajce UML i RUP Metodyki tworzenia systemów informatycznych są komputerowo wspomagane przez narzędzia CASE (Computer Aided Software Engineering). Firmy komputerowe oraz naukowe środowisko informatyczne opracowały wiele tego typu narzędzi modelowania systemów. Ich znaczenie rośnie wraz ze wzrostem zakresu projektu, co skutkuje rozbudowaną i niezwykle trudną w zarządzaniu dokumentacją. Zarówno metodyka RUP, jak i język UML są wspomagane przez narzędzia CASE.

67 Komputerowe wspomaganie modelowania systemu Pakiet CASE Zastosowanie narzędzi CASE pozwala na wykonanie następujących zadań w procesie tworzenia systemów: wspomaganie specyfikacji i dokumentowania projektów informatycznych; sprawdzanie semantycznej poprawności diagramów UML i modelu jako całości; wspomaganie iteracyjno-przyrostowego cyklu życia systemu; generowanie szkieletowego kodu źródłowego na podstawie modelu systemu; inżynierię zwrotną (ang. reverse engineering); synchronizację modelu systemu z kodem źródłowym; możliwość równoległego tworzenia oprogramowania przez wielu członków zespołu projektowego.

68 Komputerowe wspomaganie modelowania systemu Pakiety CASE Stopień akceptacji oprogramowania CASE, ukierunkowanego na język UML i metodykę RUP, jest w środowisku profesjonalnym zróżnicowany. W niektórych przypadkach jest ono traktowane jako nieodłączny element tworzenia oprogramowania, w innych wykorzystywane są jedynie poszczególne funkcje.

69 Komputerowe wspomaganie modelowania systemu Wybrane narzędzia CASE dla UML i RUP

70 Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML Wprowadźmy następujące oznaczenia: ud - diagram przypadków użycia; cld - diagram klas; sm - diagram maszyny stanowej; ad - diagram czynności; csd - diagram struktur połączonych;

71 Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML iod - diagram sterowania interakcją; sd - diagram sekwencji; cd - diagram komunikacji; cod - diagram komponentów; dd - diagram rozlokowania; td - diagram harmonogramowania.

72 Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML

73 Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML

74 Komputerowe wspomaganie modelowania systemu Generowanie szkieletowego kodu źródłowego Generowanie kodu jest jedną z fundamentalnych opcji w cyklu życia systemu i ważną cechą narzędzia CASE. Naturalnie w efekcie jej wykorzystania nie powstaje pełna, możliwa do natychmiastowego uruchomienia aplikacja. Generowany kod źródłowy jest określany jako szkieletowy - generowana jest struktura oprogramowania, w szczególności klasy, atrybuty wraz z ich właściwościami, sygnatury operacji, związki pomiędzy elementami modelu i komponenty. Zawartość poszczegłlnych operacji musi być następnie uzupełniona przez programistów.

75 Komputerowe wspomaganie modelowania systemu Zaletywykorzystania funkcji generowania kodu Zalety wykorzystania funkcji generowania kodu: pomaga w utrzymaniu przejrzystości jego struktury i eliminuje wiele pomyłek technicznych, które programiści mogą popełnić na wczesnym etapie kodowania; zasadniczo skraca czas tworzenia gotowego systemu. Należy jednak pamietać, że: nie wyręcza jednak twórcy systemu w czynnościach innych niż rutynowe, takich jak projektowanie interfejsu użytkownika (GUI); wymaga także konsekwentnego przestrzegania pewnych reguł modelowania; wskazane jest ponadto wykorzystywanie funkcji sprawdzania poprawności semantycznej modelu przed przejściem do generowania kodu, jeśli opcja taka oferowana jest przez narzędzie CASE.

76 Komputerowe wspomaganie modelowania systemu Zestawienie możliwości generowania kodu oferowanych przez wyselekcjonowane narzędzia CASE

77 Komputerowe wspomaganie modelowania systemu Zestawienie możliwości generowania kodu oferowanych przez wyselekcjonowane narzędzia CASE

78 Komputerowe wspomaganie modelowania systemu Zestawienie możliwości generowania kodu oferowanych przez wyselekcjonowane narzędzia CASE

79 Komputerowe wspomaganie modelowania systemu Inżynieria zwrotna Zdolność przeprowadzenia inżynierii zwrotnej to zdolność do utworzenia bądź modyfikacji modelu systemu na podstawie kodu źródłowego aplikacji. Inżynieria zwrotna, wykorzystywana w połączeniu z funkcją generowania kodu źródłowego, umożliwia zachowanie spójności kodu systemu względem jego modelu. Zależność ta jest dwukierunkowa i jest określana mianem inżynierii wahadłowej (ang. round-trip engineering). Dzięki inżynierii zwrotnej można zsynchronizować oba te artefakty, nawet jeśli w kodzie dokonano zmian, nie nanosząc przy tym poprawek w dokumentacji. Praktyka tworzenia systemów informatycznych dowodzi, że posiadanie aktualnego modelu systemu jest nie do przecenienia.

80 Komputerowe wspomaganie modelowania systemu Inżynieria zwrotna

81 Komputerowe wspomaganie modelowania systemu Inżynieria zwrotna

82 Komputerowe wspomaganie modelowania systemu Obsługiwane platformy Wysiłki producentów oprogramowania narzędziowego zmierzające do wydłużenia listy obsługiwanych platform zwiększają elastyczność zespołu projektowego. Wspieranie systemów z rodziny Windows można określić jako powszechną praktykę. Jest tak w przypadku wszystkich analizowanych narzędzi. Popularną platformą jest również Linux. Jedynie narzędzia AnyLogic oraz Enterprise Architect nie występują w wersji przeznaczonej dla tego systemu operacyjnego. ArgoUML, Poseidon for UML oraz Together występują ponadto w wersji przeznaczonej dla systemu operacyjnego MacOS.

83 Komputerowe wspomaganie modelowania systemu Koniec wykładu 11.

84 Integracja systemów informatycznych Wykład 12

85 Integracja systemów informatycznych Integracja systemów informatycznych Integrację definiuje się jako połączenie niejednorodnych składników w całość, tak że współdziałając w ramach tej całości wzmagają swoją skuteczność. Podkreślany jest ten synergistyczny efekt integracji. Termin integracja odnoszony jest także do integracji zarządzania organizacją jego systemu informacyjnego. W takim ujęciu oznacza przede wszystkim integrację systemu zarządzania i systemów informacji zorientowanych na wspomaganie podejmowania decyzji, z których każdy już przedstawia określony poziom integracji. Jako podstawowy cel integracji systemów informatycznych wymienia się często integrację biznesu. Ta integracja biznesu jest możliwa do osiągnięcia za pomocą integracji procesów biznesowych poprzez rekonstrukcję i integrację samych procesów oraz systemów informacji, które wspomagają te procesy.

86 Integracja systemów informatycznych Integracja systemów informatycznych Integracja systemów informatycznych jest też rozważana w kontekście koncepcji M. Portera - łańcucha tworzenia wartości, odnoszącego się do działalności jednej firmy, jak i tzw. ciągów gospodarczych obejmujących kilka wewnątrzfirmowych łańcuchów gospodarczych. Stąd kryteria oceny poziomu integracji odnoszą się do współdziałania partnerów w tworzeniu wartości w ramach przedsiębiorstwa oraz partnerów biznesowych na rynku, sięgając aż do klientów.

87 Integracja systemów informatycznych Integracja W literaturze rozważane są różne typy, czy też formy integracji. Przykładowo wymienia się: integrację systemową (ang. system integration); integrację aplikacji (ang. application integration); integrację biznesową (ang. business integration).

88 Integracja systemów informatycznych Integracja systemowa Integracja systemowa jest rozumiana jako taka integracja, która dotyczy komunikacji między systemami, tj. połączenia i wymiany danych za pomocą sieci komputerowych i protokołów komunikacyjnych.

89 Integracja systemów informatycznych Integracja aplikacji Integracja aplikacji dotyczy współdziałania aplikacji realizowanych na różnych platformach sprzętowych i oprogramowania, jak również wspólnego użytkowania danych przez różne aplikacje (common shared data). Integracja aplikacji jest realizowana za pomocą tworzenia środowisk przetwarzania rozproszonego, interfejsów programów użytkowych API (Application Program Interfaces) i standardów w zakresie wymiany danych.

90 Integracja systemów informatycznych Integracja biznesowa Integracja biznesowa dotyczy koordynacji procesów gospodarczych. Wymaga zrozumienia zasad działania biznesu i precyzyjnego zdefiniowania reguł operacyjnych biznesu.

91 Integracja systemów informatycznych Usługi integracyjne Wyróznia się następujące rodzaje usług integracyjnych odpowiadających różnym poziomom integracji: kompleksowe usługi doradczo-biznesowe, mające na celu przebudowę firmy (ang. /T total solution provider) - integracja na poziomie biznesu; kompleksowe usługi, mające na celu doprowadzenie do wdrożenia oprogramowania biznesowego (ang. TT solution provider) - integracja na poziomie aplikacji; usługi z zakresu instalacji oprogramowania komunikacyjnego, biurowego, systemów operacyjnych (ang. IT systems integrator) - integracja na poziomie systemowym; usługi z zakresu instalacji sieci ( IT network systems integrator) - integracja na poziomie systemowym.

92 Integracja systemów informatycznych Integrator Jako typową paletę usług integratora wymienia się: integrację systemów w postaci sprzętu, sieci i oprogramowania różnych producentów, konsultacje dotyczące różnych etapów cyklu życia systemu, tworzenie oprogramowania na zamówienie klienta, zarządzanie projektami informatycznymi, utrzymywanie systemu komputerowego klienta, zapobieganie i usuwanie skutków katastrof. Coraz częściej poleca się usługi integratora intenetowego.

93 Integracja systemów informatycznych Integracja Krokami prowadzącymi do osiągnięcia pełnej integracji w dziedzinie systemów informatycznych jest osiągnięcie komputerowo zintegrowanego wytwarzania (ang. Computer Integrated Manufacturing) oraz komputerowo zintegrowanego zarządzania (ang. Computer Integrated Management) oraz obu tych obszarów. Architektury i modele referencyjne, to narzędzia ułatwiające zintegrowane spojrzenie na systemy informatyczne przez pryzmat procesów gospodarczych. Pod pojęciem architektur i modeli referencyjnych rozumie się architektury i modele opracowane w oparciu o zebrane doświadczenia gospodarowania przedsiębiorstwami i wdrażania systemów informatycznych, zawierające ogólne rozwiązania, np. dla określonej branży lub dziedziny zastosowań, i stanowiące podstawę opracowywania architektur i modeli dla konkretnych - rzeczywistych sytuacji przedsiębiorstw lub dokonywania oceny konkretnych już wdrożonych architektur i modeli Używane tu słowo referencyjny pochodzi od łacińskiego słowa referre (odnosić się, informować, odwoływać się, rekomendować).

94 Integracja systemów informatycznych Architektura lub model referencyjny Architektura lub model referencyjny powinny być wzorcami powszechnie uznawanymi, które mogą zostać użyte jako rozwiązania wyjściowe przystosowywane do indywidualnych potrzeb. Architektury i modele referencyjne stwarzają podstawy integracji sfery biznesowej i sfery technologii informatycznych. Przykładami znanych architektur referencyjnych są: CIMOSA (Open System Architecture for Computer Integrated Manufacturing); GRAI/GIM (Graphes de Resultats et Actives Interrelies/GRAI Integrated Methodology); PERA (Purdue Enterprise Reference Architecture); GERAM (Generalized Enterprise Reference Architecture and Methodology); SOM (Semantic Object Model Architecture); IFIP (Information System Methodology Organizacji IFIP (International Federation for Information Processing).

95 Integracja systemów informatycznych Model referencyjny Przykłady znanych modeli referencyjnych: modele referencyjne ARIS; model referencyjny SAP R/3; modele Baan.

96 Integracja systemów informatycznych Architektury i modele referencyjne Architektury i modele referencyjne, opracowywane przez producentów oprogramowania, firmy wdrażające systemy informatyczne, ośrodki naukowe, konsorcja, firmy konsultingowe są stale modyfikowane i rozwijane. Powstają także całkiem nowe. Widoczne jest dążenie do ujęcia systemów informatycznych z różnych punktów widzenia, takich jak: dane, funkcje, organizacja, proces gospodarczy i na różnych poziomach opisu, odpowiadających fazom cyklu życia systemu: analiza i definiowanie wymagań użytkownika, projektowanie, wdrażanie, utrzymywanie systemu.

97 Integracja systemów informatycznych Wiedzę przedsiębiorstwa jako czynnik integrujący systemy informatyczne Wiedza jest traktowana jak zasób firmy, którym trzeba zarządzać, tak jak innymi zasobami. Zarządzanie wiedzą obejmuje jej identyfikację, archiwowanie, inwentaryzację, powiększanie (pozyskiwanie), wykorzystywanie. W organizacjach niezbędne jest zapewnienie możliwości współużytkowania wiedzy i swobodnego przepływu informacji (dystrybucja informacji i wiedzy). Wymaga to integracji narzędzi IT, takich jak systemy baz wiedzy, sieci neuronowe, systemy wspomagania decyzji grupowych (pracy grupowej), hurtownie danych, systemy pozyskiwania danych (data mining).

98 Integracja systemów informatycznych Organizacje wirtualne Wirtualne organizacje istnieją dzięki nowej technologii pracy w sieci, umożliwiającej rozproszoną pracę. Wirtualne przedsiębiorstwa działaj ą tak jak inne firmy, lecz nie mają osobowości prawnej. W organizacji wirtualnej procesy gospodarcze przebiegaj ą poprzez wiele zlokalizowanych w różnych miejscach punktów sprzedaży i produkcji, i sięgają do zewnętrznych partnerów przedsiębiorstwa (dostawcy i klienci). Nowa forma przedsiębiorstw skłania do poszukiwania odpowiedzi na pytanie o przydatność dla takich organizacji architektur i modeli, zapewniających integrację systemów informatycznych, utworzonych dla organizacji tradycyjnych i tworzenia odpowiednio dostosowanych.

99 Integracja systemów informatycznych Integracja Sposób rozumienia integracji zmienia się i pozostaje w ścisłej zależności od osiągniętego poziomu rozwoju w zakresie technologii IT i zarządzania. Towarzyszy temu rozwój całościowych koncepcji, takich jak komputerowo zintegrowane wytwarzanie (Computer Integrated Manufacturing), komputerowo zintegrowane zarządzanie (Computer Integrated Management), komputerowo zintegrowane przedsiębiorstwo - biznes (Computer Integrated Business), które przedstawiają wskazówki, co do realizacji integracji w dziedzinie systemów informatycznych. System informatyczny przedsiębiorstwa przestaje być uważany za odrębny element, wymagający samodzielnej integracji, ale coraz częściej jest uważany za immanentny składnik całościowo traktowanego przedsiębiorstwa, co znajduje swój wyraz m.in. w coraz powszechniejszym używaniu terminu zintegrowane przedsiębiorstwo zamiast zintegrowany system informatyczny.

100 Integracja systemów informatycznych Integracja systemów informatycznych Integracją systemów informatycznych nazywamy osadzanie istniejących i nowych systemów informatycznych w istniejącym środowisku informatycznym.

101 Integracja systemów informatycznych Integracja Integracja systemów informatycznych wymaga wiedzy o środowisku systemu informatycznego oraz jego otoczeniu. Integrowany system informatyczny osadzany jest w środowisku biznesowym i dlatego konieczna jest znajomość otaczających go procesów biznesowych. W celu umożliwienia efektywnego współdziałania systemu informatycznego z otoczeniem (tj. innymi systemami informatycznymi) należy skonstruować odpowiednie interfejsy.

102 Integracja systemów informatycznych Interfejs Komunikacja między systemami informatycznymi odbywa się za pośrednictwem interfejsów. W związku z tym interfejs jest podstawowym elementem modelu integracji systemów. Za jego pośrednictwem system informatyczny przesyła informacje do innego systemu informatycznego.

103 Integracja systemów informatycznych Integracja W konsekwencji można stwierdzić, że modelowanie integracji to inaczej modelowanie komunikatów wymienianych (przez interfejsy) między różnymi systemami informatycznymi oraz procesy niezbędne do tej wymiany komunikatów.

104 Integracja systemów informatycznych Poziom analizy Na potrzeby integraci systemów informatycznych musimy zdefiniować, które informacje mają być wymieniane oraz w jaki sposób. Z tego powodu model integracji systemów opisujemy biorąc pod uwagę różne punkty widzenia (perspektywy). Najogólniejszy podział związany z perspektywami wyodrębina, dwie perspektywy, tj. perspektywę procesu obrazującą aktywności podejmowane przez system informatyczny podczas wymiany komunikatów z innymi systemami informatycznymi; perspektywę statyczną opisującą zawartość i strukturę obiektów biznesowych podlegających wymianie (stanowiących komunikat).

105 Integracja systemów informatycznych Elementy perspektywy Aktywności, które muszą zostać wykonane w celu wymiany komunikatów między systemami informatycznymi, można opisać za pomocą diagramów sekwencji i diagramów aktywności: Diagram sekwencji opisuje chronologiczną kolejność wymiany komunikatów między systemami informatycznymi; Diagram aktywności opisuje przepływ działań. Obrazuje on zależności między indywidualnymi akcjami oraz przepływ obiektów biznesowych.

106 Integracja systemów informatycznych Perspektywa procesu Etapy konstrukcji perspektywy procesu: 1. Określenie interfejsów, czyli pomiędzy jakimi systemami informatycznymi odbywa się komunikacja? 2. Identyfikacja zaangażowanych systemów, czyli które systemy informatyczne wymieniają się informacjami? 3. Identyfikacja aktywności i przepływów, czyli co należy wykonać i kto jest za to odpowiedzialny? 4. Zidentyfikowanie komunikatów, czyli jakie komunikaty będą wymieniane? 5. Zdefiniowanie reguł, czyli od czego są uzależnione podejmowane akcje? 6. Weryfikacja perspektywy, czyli czy wszystko wydaje się działać?

107 Integracja systemów informatycznych Elementy perspektywy Do zilustrowania obiektów biznesowych w perspektywie statycznej modelu integracji systemów wykorzystać można diagramy klas.

108 Integracja systemów informatycznych Perspektywa statyczna Etapy konstrukcji perspektywy statycznej: 1. Zgromadzenie informacji niezbędnych dla obiektu biznesowego, czyli co chcemy przesyłać? 2. Skonstruowanie diagramu klas, czyli jaka jest struktura obiektu biznesowego? 3. Adaptacja klas i atrybutów z diagramu klas systemu informatycznego, czyli jakie informacje mają być uwzględnione na diagramie klas? 4. Pozyskanie innych elementów danych, czyli skąd wziąć pozostałe dane? 5. Zdefiniowanie klas i związków obiektu biznesowego, czyli jakie związki klas będą potrzebne? 6. Weryfikacja perspektywy, czyli czy wszystko wydaje się działać?

109 Integracja systemów informatycznych Integrowanie w przedsiebiorstwach Zastosowanie architektury obserwatora procesu pozwala na zintegrowanie rożnych systemów informatycznych w przedsiębiorstwie. Generalnie, idea obserwatora procesu polega na utworzeniu jednolitego, spójnego modelu danych bieżących (utworzenie obrazu bieżącego stanu całej produkcji) i udostępnianie go aplikacjom biznesowym według ich potrzeb poprzez międzynarodowe standardy komunikacji (standard OPC) i wymiany danych.

110 Integracja systemów informatycznych OPC Zastosowanie serwera OPC, w roli obserwatora procesu, do integracji systemów w przedsiębiorstwie pozwala na usystematyzowanie struktury połączeń z warstwą procesową i pozyskiwanie danych w jednorodny, zgodny z międzynarodowymi standardami komunikacyjnymi sposób. Raz pobrane dane, służą wielu różnym systemom informatycznym. To istotnie podnosi efektywność pozyskiwania i transferu danych w przedsiębiorstwie.

111 Integracja systemów informatycznych OPC OPC jest otwartym standardem komunikacyjnym stosowanym w automatyce przemysłowej i informatycznych systemach wyższych warstw, a mianowicie biznesowej i zarządzania, przedsiębiorstw przemysłowych. Interoperacyjność aplikacji jest zapewniona dzięki utworzeniu i utrzymywaniu specyfikacji otwartych standardów. Utrzymaniem i rozwojem standardu zajmuje się OPC Foundation. OPC powstał i został tak zaprojektowany, aby łączyć aplikacje bazujące na systemach operacyjnych ogólnego stosowania (np. Windows) ze sprzętem i oprogramowaniem aplikacyjnym automatyki przemysłowej (urządzenia procesowe), nadzorującym i sterującym procesem technologicznym. Jest to otwarty standard komunikacji, który pozwala używać jednolitych metod dostępu i opisu danych (interfejsu) dla procesu technologicznego. Metody te są niezależne od typu oraz źródła danych.

112 Integracja systemów informatycznych OPC Dla wielu pakietów oprogramowania serwer OPC dostarcza w jednolity sposób danych z urządzeń sterujących i nadzorujących proces technologiczny (dane procesowe) takich, jak sterowniki PLC, czy systemy DCS. Tradycyjnie, jeżeli jakieś oprogramowanie ma mieć dostęp do danych procesowych, musi zostać zaimplementowany specjalny sterownik. Zadaniem OPC jest zdefiniowanie wspólnego interfejsu, który utworzony raz - może być wykorzystywany przez dowolnego klienta biznesowego, oprogramowanie SCADA, HMI lub dowolny pakiet oprogramowania.

113 Integracja systemów informatycznych OPC Bazując na standardach Microsoft OLE (ang. Object Linking and Embedding), COM(ang. Component Object Model) i DCOM (ang. Distributed Component Object Model), technologia OPC definiuje interfejsy przeznaczone do komunikacji z urządzeniami przemysłowymi, przez co pozwala uniezależnić oprogramowanie monitorujące od różnorodnych rozwiązań stosowanych przez producentów sprzętu procesowego. Technologie COM/DCOM dostarczają infrastrukturę i środowisko programistyczne dla tworzenia i rozwoju oprogramowania. Obecnie są dostępne setki serwerów i klientów OPC.

114 OPC W ramach projektu zajmującego się standaryzacją OPC powstały różne specyfikacje, z których każda definiuje odrębną funkcjonalność. Wśród istniejących specyfikacji możemy wyróżnić: OPC Data Access (OPC DA) - umożliwia dostęp do aktualnych danych generowanych w czasie rzeczywistym. Przy pomocy OPC DA do serwera OPC kierowane są zapytania o aktualne wartości zmiennych procesowych - np. temperatur, ciśnień itp. Komunikacja z każdym serwerem odbywa się w taki sam sposób, z wykorzystaniem tego samego formatu. Klient nie musi wiedzieć w jaki sposób serwer komunikuje się z urządzeniem. Wielu klientów może korzystać jednocześnie z tych samych danych udostępnianych przez serwer. OPC Historical Data Access (OPC HDA) - umożliwia przeglądanie i analizę zgromadzonych danych historycznych, np w celu oceny wydajności systemu czy przewidywania błędów. Klient uzyskuje dostęp do zarchiwizowanych danych (odczytów jakiegoś urządzenia itp.) poprzez zgłaszanie zapytań do serwera OPC HDA. Modelowanie i analiza systemów informatycznych. Integracja systemów informatycznych

115 Integracja systemów informatycznych OPC OPC Alarms and Events (OPC AE) - służy do informowania o występujących w systemie zdarzeniach i zgłaszanych alarmach. Przez alarm rozumiany jest nienormalny stan jakiegoś obiektu, wymagający szczególnej uwagi. Zdarzenie może być związane ze stanem, jak np. zdarzenie przejścia danej wartości do poziomu alarmowego lub niezwiązane ze stanem, jak zmiany konfiguracji, czy błędy systemowe. Serwery OPC AE mogą pobierać dane bezpośrednio z urządzenia lub z serwera OPC DA. Serwer OPC AE może być samodzielnym modułem lub też wchodzić w skład serwera OPC DA. OPC Security - służy zapewnieniu bezpieczeństwa dostępu do danych oferowanych przez serwery OPC. Umożliwia poprawną weryfikację klienta, który chce uzyskać dostęp i poprawności transmisji (czy dane nie zostały zmienione).

116 Integracja systemów informatycznych OPC OPC Batch - zarządzanie produkcją wsadową; OPC Unified Architecture - jest niezależnym od platformy systemowej standardem, który pozwala na komunikację pomiędzy różnymi typami systemów i urządzeń poprzez wysyłanie wiadomości pomiędzy klientem a serwerem. OPC Unified Architecture, bazuje na ogólnie przyjętych komunikacyjnych protokołach takich jak TCP/IP, HTTP, SOAP, co zapewnia bardzo dużą skalowalność rozwiązań implementowanych w oparciu o tę technologię. OPC Unified Architecture umożliwia przesyłanie danych za pośrednictwem różnych formatów m.in. formatu opartego o XML i formatu binarnego.

117 Integracja systemów informatycznych OPC Unified Architecture Serwer OPC zbudowany w oparciu o Unified Architecture definiuje swoim klientom zestaw usług, jakie oferuje oraz format danych procesowych za pośrednictwem, którego ma odbywać się komunikacja. W poprzedniej wersji standardu OPC każda ze specyfikacji (np. OPC-DA, OPC-HDA) definiowała swoją własną przestrzeń adresową i swój własny zestaw usług. OPC Unified Architecture definiuje zunifikowaną przestrzeń adresową (ang. Address Space) oraz szereg usług (ang. Services), które mogą być udostępnione przez serwery OPC.

118 Integracja systemów informatycznych Koniec wykładu 12.

119 Integracja systemów informatycznych Bibliografia Włodzimierz Dąbrowski, Andrzej Stasiak, Michał Wolski, Modelowanie systemów informatycznych w języku UML 2.1 Wojciech Olejniczak, Zdzisław Szyjewski, Inżynieria systemów informatycznych w e-gospodarce. Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów informatycznych. Tańska Halina, Analiza sytsemów informatycznych. Kisielnicki J., Sroka H., Systemy informacyjne biznesu. Informatyka dla zarządzania, Placet, Warszawa 2005