Modelowanie i analiza systemów informatycznych.math.uni.lodz.pl/~robpleb/wyklad10_14.pdf ·...

Modelowanie i analiza systemów informatycznych.

Modelowanie i analiza systemówinformatycznych.

dr Robert Plebaniak

2 grudnia 2013 roku


Metodyka RUP

Wykład 10


Metodyka RUP

Metodyka RUP


Metodyka RUP

Znaczenie iteracyjno-przyrostowego procesuprojektowania systemów

Metodyka (ang. methodology) tworzenia systemówinformatycznych (TSI) stanowi spójny, logicznie uporządkowanyzestaw metod i procedur o charakterze technicznym iorganizatorskim, pozwalających zespołowi projektowemu realizowaćcykl życia systemu.Ogólnie metodyki można podzielić na strukturalne, obiektowe ispołeczne.


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 unifikacjiobiektowego procesu tworzenia systemu nosiła nazwę USDP(Unified Software Development Process). Autorami USDP są l.Jacobson, G. Booch oraz J. Rumbaugh. Jest to metodykarodzajowa (ang. generic), stwarzająca możliwość opracowywaniaróżnych jej konfiguracji i implementacji.


Metodyka RUP

Metodyka rodzajowa

Do głównych cech tego podejścia należą:I ukierunkowanie na przypadki użycia;I potraktowanie architektury systemu jako centralnegozagadnienia w procesie tworzenia oprogramowania;

I iteracyjno-przyrostowy charakter procesu tworzenia systemu.


Metodyka RUP

RUP

RUP (ang. Rational Unified Process ) to metodyka tworzeniasystemów informatycznych oparta na paradygmacie obiektowości ijęzyku UML, zaproponowana przez korporację Rational Software.Jako kompletna metodyka RUP zawiera następujące elementy:

I przyrostowo-iteracyjny cykl życia systemu;I pojęcia, metody i techniki z zakresu języka UML i inne, w tymheurystyczne;

I zintegrowany pakiet narzędzi CASE, wspomagający stosowanieelementów metodyki;

I role zdefiniowane w zespole projektowym i proceduryzarządzania projektem;

I kryteria oceny i monitorowania postępu prac;I hipertekstową bazę wiedzy;I internetowy serwis wspomagający metodykę i jej użytkowników.


Metodyka RUP

RUP

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


Metodyka RUP

Rozwój metodyki RUP


Metodyka RUP

RUP

Najważniejsze obszary zmian w zakresie metodyki związane były z:I rozwijaniem poszczególnych dyscyplin, w tym przepływówpracy oraz dotyczących ich dokumentów;

I wprowadzeniem modułów dodatkowych (ang. plug-ins) RUPoraz integracją i włączaniem nowych narzędzi CASE,wspomagających metodykę RUP;

I reorganizacją układu hipertekstowej bazy wiedzy;I zdefiniowanymi w metodyce artefaktami - modelami idokumentami.


Metodyka RUP

USDP

Założenia rodzajowej metodyki USDP, iteracyjno-przyrostowy cyklżycia systemu, a także kategorie modelowania języka UMLwykorzystywane są przez inne, aktualnie rozwijane metodykiobiektowe. Do najbardziej interesujących należą:

I XP (Extreme Programming);I Agile;I Scrum,I DSDM (Dynamie Systems Development Method).


Metodyka RUP

Struktura RUP

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


Metodyka RUP

Struktura RUP

Linia pozioma reprezentuje czas, a zatem dynamiczny aspektprocesu TSI, uwzględniając:

I fazy;I iteracje;I punkty przeglądu.

Z kolei linia pionowa odzwierciedla statyczny aspekt procesu TSI, tj.jego opis w kategoriach:

I dyscyplin;I czynności;I artefaktów;I ról;I przepływów pracy.


Metodyka RUP

Struktura RUP


Metodyka RUP

Rola

Rola oznacza obowiązki i kompetencje osoby lub zespołuzaangażowanego w proces tworzenia systemu informatycznego lubjego wycinka. W wyniku realizacji roli powstają oczekiwaneartefakty. Spektrum ról, odpowiadających często współczesnymzawodom informatycznym, jest bardzo szerokie i wiąże się zmożliwościami zaawansowanych technologii informatycznych.Przykładami ról w metodyce RUP są: menadżer projektu, inzynierprocesu, 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órejpowstaje lub jest przetwarzany artefakt.


Metodyka RUP

Dyscypliny

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


Metodyka RUP

Dyscypliny podstawew

Dyscypliny podstawowe stanowią rdzeń procesu tworzeniasystemu. Należą do nich:

I modelowanie biznesowe;I specyfikacja wymagań;I analiza i projektowanie;I programowanie;I testowanie;I wdrożenie.


Metodyka RUP

Dyscypliny wspomagające

Dyscypliny wspomagające realizują funkcje zarządcze ikonfiguracyjne w procesie tworzenia systemu. Można do nichzaliczyć:

I zarządzanie konfiguracjami i zmianami;I zarządzanie projektem;I przygotowanie środowiska.


Metodyka RUP

Układ i zależności pomiędzy wymienionymidyscyplinami


Metodyka RUP

Podstawowy zakres merytoryczny dyscyplin w procesieRUP

Modelowanie biznesowe (ang. - business modeling) zawiera wizjęnowej, docelowej organizacji, definicje występujących w jej ramachprocesów, ról i zakresów odpowiedzialności. Informacje teprzedstawia się w postaci biznesowych diagramów.Specyfikacja wymagań (ang. requirements) - oznaczaopracowanie wizji systemu, modelu przypadków użycia izdefiniowanie wymagań niefunkcjonalnych.


Metodyka RUP


Analiza i projektowanie (ang. analysis and design ) - zawieraanalizę i projekt systemu z wykorzystaniem całego spektrumdiagramów UML.Programowanie (ang. implementation ) - pozwala na opracowaniekodu źródłowego w wybranym języku programowania orazkompilację kodu i integrację komponentów.Testowanie (ang. test) - oznacza planowanie testów oraz ocenęsystemu poprzez wykonanie szeregu testów.


Metodyka RUP


Wdrożenie (ang. deployment ) - dotyczy instalacji oprogramowaniasystemu i formalną akceptację kolejnych wersji systemu przezklienta czy użytkownika.Zarządzanie konfiguracjami i zmianami (ang. configuration andchange menagement) - obejmuje kontrole wersji artefaktówopracowanych podczas kolejnych iteracji.Zarządzanie projektem (ang. project menagement) - oznaczaplanowanie i kontrole realizacji projektu.Przygotowanie środowiska (ang. environment) - obejmujeprzygotowanie infrastruktury dla skutecznej realizacji projektu.


Metodyka RUP

Fazy

Fazą (ang. phase) w metodyce RUP jest okres między kolejnymipunktami przeglądu cyklu iteracyjno-przyrostowego, w którymzrealizowano niezbędne czynności i opracowano adekwatne artefakty.Metodyka RUP wprowadza cztery fazy:

I rozpoczęcie (ang. inception);I opracowanie (ang. elaboration);I budowa (ang. construction);I przekazanie (ang. transition).


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 integracjaartefaktó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; jejefektem jest kolejny przyrost systemu.


Metodyka RUP

Fazy w metodyce RUP i ich cele

Rozpoczęcie (ang. inception) - wypracowanie ogólnej wizjiprzedsięwzięcia oraz osiągnięcie zrozumienia i akceptacji projektu zestrony wszystkich jego uczestników.Opracowanie (ang. elaboration) - ustalenie architektury systemu,stworzenie planu projektu oraz wyeliminowanie elementówwysokiego ryzyka z projektu.Budowa (ang. construction) - stworzenie systemu na podstawieprzyjętej architektury.Przekazanie (ang. transition) - dostarczenie gotowego systemuużytkownikom czy klientom.


Modelowanie biznesowe




Znaczenie modelowania biznesowego

W procesie tworzenia systemu zgodnym z metodyką RUP pierwsządyscypliną iteracyjno-przyrostowego cyklu życia systemu jestmodelowanie biznesowe.Modelowanie biznesowe (ang. business modeling) jest sposobemodwzorowywania i dokumentowania procesów biznesowych. Wnawiązaniu do kategorii modelowania języka UML, wyróżnić można:

I modelowanie systemowe - ukierunkowane na tworzenie systemuinformatycznego, jego oprogramowania oraz infrastrukturysprzętowej;

I modelowanie biznesowe.



Reengineering

Modelowanie biznesowe można połączyć z reengineeringiemprocesów biznesowych (ang. Business Process Reengineering) - wskrócie BPR - w przypadku, gdy zamierza się dokonać radykalnejzmiany funkcjonowania organizacji i opracować modele nowychprocesów biznesowych.Modele biznesowe znajdują zastosowanie przede wszystkim wpierwszej fazie cyklu życia RUP, fazie rozpoczęcia, a w mniejszymzakresie także w kolejnych fazach (opracowaniu, budowie orazprzekazaniu).



Modelowanie biznesowe w procesie tworzenia systemu



Podstawowe kategorie pojęciowe oraz notacja graficzna

Model biznesowy, podobnie jak model systemu informatycznego,jest przedstawiany w postaci diagramów. Diagramy biznesowe są wujęciu czysto technicznym odpowiednikami diagramówsystemowych. Tak więc możliwe jest przystosowanie do potrzebmodelowania biznesowego większości diagramów wymienionych wspecyfikacji języka UML 2.0, czyli:

I diagramów przypadków użycia;I diagramów klas;I diagramów obiektów;I diagramów czynności;I diagramów maszyny stanowej;I diagramów interakcji;I diagramów struktur połączonych;I diagramów pakietów.



Praktyczne zastosowanie

Ze względu na specyfikę funkcjonowania rzeczywistych organizacjinajwiększe praktyczne zastosowanie mają następujące rodzajediagramów biznesowych:

I biznesowe diagramy przypadków użycia;I biznesowe diagramy klas;I biznesowe diagramy czynności;I biznesowe diagramy sekwencji;I biznesowe diagramy pakietów.



Podstawowe kategorie modelowania diagramówbiznesowych

W przypadku modelowania biznesowego niezbędne stają siękategorie modelowania, które nie są elementami diagramówopisujących oprogramowanie. Kategorie te mają charakterstereotypów graficznych.Biznesowe diagramy stworzone w ramach modelowania biznesowegosą transformowane w kolejnych fazach iteracyjno-przyrostowegocyklu RUP w analityczne lub systemowe diagramy języka UML.Transformacja diagramów biznesowych w systemowe nie zachodziautomatycznie. Do osiągnięcia ostatecznego efektu modelowaniasystemowego niezbędna jest praca analityczna i projektowa twórcówsystemu, stosownie do zaleceń UML i RUP.



Podstawowe kategorie modelowania diagramówbiznesowych



Biznesowy kontekst systemu księgarni



Biznesowy diagram przypadków użycia systemuksięgarni



Mapa procesów biznesowych funkcjonowania księgarni



Czynność przypadku ”Dokonaj zakupu”



Biznesowy diagram sekwencji



Biznesowy diagram klas



Biznesowy diagram klas z pracownikami biznesowymi



Jednostki organizacyjne księgarni



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



Koniec wykładu 10.


Modelowanie analityczne

Wykład 11



Znaczenie modelowania analitycznego

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



Diagram modelowania analitycznego w procesietworzenia systemu



Podstawowe kategorie pojęciowe oraz notacja graficzna

Model analityczny (ang. analysislrobustness model), grupującydiagramy analityczne, można traktować jako rodzaj wstępnegoprojektu. Jego celem jest wspomaganie identyfikacji klas.Podstawowymi elementami diagramów modelowania analitycznegosą:

I klasy analityczne;I aktorzy;I związki.



Notacja graficzna

Diagramy analityczne modelowane są jako diagramy klas zzastosowaniem trzech stereotypowanych klas:

I granicznych (ang. boundary);I sterujących (ang. control);I przechowujących (ang. entity).



Notacja

W praktyce podczas analizy scenariuszy przypadku użyciaidentyfikuje się obiekty analityczne, które podczas projektowaniasystemu ulegają przekształceniu w różne kategorie modelowaniawłaściwe dla poziomu implementacyjnego, takie jak atrybuty klas,operacje lub same klasy. W związku z tym te kategorie modelowaniaanalitycznego w literaturze przedmiotu określane są często mianemobiektów analitycznych.



Notacja oraz charakterystyka klas analitycznych



Notacja oraz charakterystyka

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



Diagram analityczny



Zasady obowiązujące w diagramach modelowaniaanalitycznego

Przyjmujemy nastepujce oznaczenia;I symbol ”+” oznacza, że elemanty wyszczególnione w danymwierszu i kolumnie mogą się łączyć;

I symbol ”-” łączenie elementów wyszczgólnionych w danymwierszu i kolumnie jest niepoprawne.



Zasady obowiązujące w diagramach modelowaniaanalitycznego



Proces tworzenia modelu analitycznegoTworzenie diagramów modelowania analitycznego poprzedzone jestw ramach iteracyjno-przyrostowego procesu RUP modelowaniembiznesu oraz specyfikacją wymagań tworzonego systemu w postacisystemowych diagramów przypadków użycia. Stąd proces ten możnapodzielić na następujące etapy:1. wyselekcjonowanie, stosownie do złożoności dziedzinyprzedmiotowej, odpowiednich:

I diagramów modelu biznesowego,I diagramu (diagramów) przypadków użycia oraz jego (ich)scenariuszy;

2. przeniesienie aktorów z diagramów przypadków użycia nadiagramy analityczne;

3. identyfikacją klas analitycznych i określenie ich rodzajów;

4. integracją poszczególnych zidentyfikowanych elementów wformie diagramów analitycznych składających się na modelanalityczny.



Konwersja kategorii biznesowych na kategorie klasanalitycznych

W trakcie tego procesu obowiązują określone zasady konwersji zmodeli biznesowych i systemowych diagramów przypadków użyciana kategorie diagramów modelowania analitycznego.Analogicznie, należy zauważć, że sporządzenie klas analitycznych napodstawie systemowych przypadków użycia nie polega nabezpośredniej zamianie notacji. Konwersja systemowego modeluprzypadków użycia na modele analityczne obejmuje przekształcenieaktorów w klasy graniczne bądź ich bezpośrednie przeniesienie.Natomiast przypadki użycia są przekształcane w odpowiednierodzaje klas analitycznych - graniczne, sterujące i przechowujące. Wdalszych iteracjach RUP klasy analityczne przekształcane są w klasysystemu.



Konwersja kategorii biznesowych na kategorie klasanalitycznych



Model analityczny


Komputerowe wspomaganie modelowania systemu




Pakiety CASE wspomagajce UML i RUP

Metodyki tworzenia systemów informatycznych są komputerowowspomagane przez narzędzia CASE (Computer Aided SoftwareEngineering). Firmy komputerowe oraz naukowe środowiskoinformatyczne opracowały wiele tego typu narzędzi modelowaniasystemów. Ich znaczenie rośnie wraz ze wzrostem zakresu projektu,co skutkuje rozbudowaną i niezwykle trudną w zarządzaniudokumentacją. Zarówno metodyka RUP, jak i język UML sąwspomagane przez narzędzia CASE.



Pakiet CASE

Zastosowanie narzędzi CASE pozwala na wykonanie następującychzadań w procesie tworzenia systemów:

I wspomaganie specyfikacji i dokumentowania projektówinformatycznych;

I sprawdzanie semantycznej poprawności diagramów UML imodelu jako całości;

I wspomaganie iteracyjno-przyrostowego cyklu życia systemu;I generowanie szkieletowego kodu źródłowego na podstawiemodelu systemu;

I inżynierię zwrotną (ang. reverse engineering);I synchronizację modelu systemu z kodem źródłowym;I możliwość równoległego tworzenia oprogramowania przez wieluczłonków zespołu projektowego.



Pakiety CASE

Stopień akceptacji oprogramowania CASE, ukierunkowanego najęzyk UML i metodykę RUP, jest w środowisku profesjonalnymzróżnicowany. W niektórych przypadkach jest ono traktowane jakonieodłączny element tworzenia oprogramowania, w innychwykorzystywane są jedynie poszczególne funkcje.



Wybrane narzędzia CASE dla UML i RUP



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;




iod - diagram sterowania interakcją;

sd - diagram sekwencji;

cd - diagram komunikacji;

cod - diagram komponentów;

dd - diagram rozlokowania;

td - diagram harmonogramowania.



Generowanie szkieletowego kodu źródłowego

Generowanie kodu jest jedną z fundamentalnych opcji w cyklu życiasystemu i ważną cechą narzędzia CASE. Naturalnie w efekcie jejwykorzystania nie powstaje pełna, możliwa do natychmiastowegouruchomienia 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ązkipomiędzy elementami modelu i komponenty. Zawartośćposzczegłlnych operacji musi być następnie uzupełniona przezprogramistów.



Zaletywykorzystania funkcji generowania koduZalety wykorzystania funkcji generowania kodu:

I pomaga w utrzymaniu przejrzystości jego struktury i eliminujewiele pomyłek technicznych, które programiści mogą popełnićna wczesnym etapie kodowania;

I zasadniczo skraca czas tworzenia gotowego systemu.

Należy jednak pamietać, że:I nie wyręcza jednak twórcy systemu w czynnościach innych niżrutynowe, takich jak projektowanie interfejsu użytkownika(GUI);

I wymaga także konsekwentnego przestrzegania pewnych regułmodelowania;

I wskazane jest ponadto wykorzystywanie funkcji sprawdzaniapoprawności semantycznej modelu przed przejściem dogenerowania kodu, jeśli opcja taka oferowana jest przeznarzędzie CASE.



Zestawienie możliwości generowania kodu oferowanychprzez wyselekcjonowane narzędzia CASE



Inżynieria zwrotna

Zdolność przeprowadzenia inżynierii zwrotnej to zdolność doutworzenia 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ścikodu systemu względem jego modelu. Zależność ta jestdwukierunkowa 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 tympoprawek w dokumentacji. Praktyka tworzenia systemówinformatycznych dowodzi, że posiadanie aktualnego modelu systemujest nie do przecenienia.



Inżynieria zwrotna



Obsługiwane platformy

Wysiłki producentów oprogramowania narzędziowego zmierzającedo wydłużenia listy obsługiwanych platform zwiększają elastycznośćzespołu projektowego.Wspieranie systemów z rodziny Windows można określić jakopowszechną praktykę. Jest tak w przypadku wszystkichanalizowanych 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 wersjiprzeznaczonej dla systemu operacyjnego MacOS.



Koniec wykładu 11.


Integracja systemów informatycznych

Wykład 12




Integrację definiuje się jako połączenie niejednorodnych składnikóww całość, tak że współdziałając w ramach tej całości wzmagająswoją skuteczność.Podkreślany jest ten synergistyczny efekt integracji. Terminintegracja odnoszony jest także do integracji zarządzaniaorganizacją jego systemu informacyjnego. W takim ujęciu oznaczaprzede wszystkim integrację systemu zarządzania i systemówinformacji zorientowanych na wspomaganie podejmowania decyzji, zktórych każdy już przedstawia określony poziom integracji. Jakopodstawowy cel integracji systemów informatycznych wymienia sięczęsto ”integrację biznesu”. Ta integracja biznesu jest możliwa doosiągnięcia za pomocą integracji procesów biznesowych poprzezrekonstrukcję i integrację samych procesów oraz systemówinformacji, które wspomagają te procesy.




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



Integracja

W literaturze rozważane są różne typy, czy też formy integracji.Przykładowo wymienia się:

I integrację systemową (ang. system integration);I integrację aplikacji (ang. application integration);I integrację biznesową (ang. business integration).



Integracja systemowa

Integracja systemowa jest rozumiana jako taka integracja, któradotyczy komunikacji między systemami, tj. połączenia i wymianydanych za pomocą sieci komputerowych i protokołówkomunikacyjnych.



Integracja aplikacji

Integracja aplikacji dotyczy współdziałania aplikacji realizowanychna różnych platformach sprzętowych i oprogramowania, jak równieżwspólnego użytkowania danych przez różne aplikacje (commonshared data). Integracja aplikacji jest realizowana za pomocątworzenia środowisk przetwarzania rozproszonego, interfejsówprogramów użytkowych API (Application Program Interfaces) istandardów w zakresie wymiany danych.



Integracja biznesowa

Integracja biznesowa dotyczy koordynacji procesów gospodarczych.Wymaga zrozumienia zasad działania biznesu i precyzyjnegozdefiniowania reguł operacyjnych biznesu.



Usługi integracyjne

Wyróznia się następujące rodzaje usług integracyjnychodpowiadających różnym poziomom integracji:

I kompleksowe usługi doradczo-biznesowe, mające na celuprzebudowę firmy (ang. /T total solution provider) - integracjana poziomie biznesu;

I kompleksowe usługi, mające na celu doprowadzenie dowdrożenia oprogramowania biznesowego (ang. TT solutionprovider) - integracja na poziomie aplikacji;

I usługi z zakresu instalacji oprogramowania komunikacyjnego,biurowego, systemów operacyjnych (ang. IT systemsintegrator) - integracja na poziomie systemowym;

I usługi z zakresu instalacji sieci ( IT] network systemsintegrator) - integracja na poziomie systemowym.



Integrator

Jako typową paletę usług integratora wymienia się:I integrację systemów w postaci sprzętu, sieci i oprogramowaniaróżnych producentów,

I konsultacje dotyczące różnych etapów cyklu życia systemu,I tworzenie oprogramowania na zamówienie klienta,I zarządzanie projektami informatycznymi,I utrzymywanie systemu komputerowego klienta,I zapobieganie i usuwanie skutków katastrof.

Coraz częściej poleca się usługi integratora intenetowego.



IntegracjaKrokami prowadzącymi do osiągnięcia pełnej integracji w dziedziniesystemów informatycznych jest osiągnięcie komputerowozintegrowanego wytwarzania (ang. Computer IntegratedManufacturing) oraz komputerowo zintegrowanego zarządzania(ang. Computer Integrated Management) oraz obu tych obszarów.Architektury i modele referencyjne, to narzędzia ułatwiającezintegrowane spojrzenie na systemy informatyczne przez pryzmatprocesów gospodarczych. Pod pojęciem architektur i modelireferencyjnych rozumie się architektury i modele opracowane woparciu o zebrane doświadczenia gospodarowaniaprzedsiębiorstwami i wdrażania systemów informatycznych,zawierające ogólne rozwiązania, np. dla określonej branży lubdziedziny zastosowań, i stanowiące podstawę opracowywaniaarchitektur i modeli dla ”konkretnych” - rzeczywistych sytuacjiprzedsiębiorstw lub dokonywania oceny ”konkretnych” jużwdrożonych architektur i modeli Używane tu słowo referencyjnypochodzi od łacińskiego słowa referre (odnosić się, informować,odwoływać się, rekomendować).



Architektura lub model referencyjnyArchitektura lub model referencyjny powinny być wzorcamipowszechnie uznawanymi, które mogą zostać użyte jako rozwiązaniawyjściowe przystosowywane do indywidualnych potrzeb.Architektury i modele referencyjne stwarzają podstawy integracjisfery biznesowej i sfery technologii informatycznych. Przykładamiznanych architektur referencyjnych są:

I CIMOSA (Open System Architecture for Computer IntegratedManufacturing);

I GRAI/GIM (Graphes de Resultats et Actives Interrelies/GRAIIntegrated Methodology);

I PERA (Purdue Enterprise Reference Architecture);I GERAM (Generalized Enterprise Reference Architecture andMethodology);

I SOM (Semantic Object Model Architecture);I IFIP (Information System Methodology Organizacji IFIP(International Federation for Information Processing).



Model referencyjny

Przykłady znanych modeli referencyjnych:I modele referencyjne ARIS;I model referencyjny SAP R/3;I modele Baan.



Architektury i modele referencyjne

Architektury i modele referencyjne, opracowywane przezproducentów oprogramowania, firmy wdrażające systemyinformatyczne, 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 zróżnych ”punktów widzenia”, takich jak: dane, funkcje, organizacja,proces gospodarczy i na różnych poziomach opisu, odpowiadającychfazom cyklu życia systemu: analiza i definiowanie wymagańużytkownika, projektowanie, wdrażanie, utrzymywanie systemu.



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 jejidentyfikację, archiwowanie, inwentaryzację, powiększanie(pozyskiwanie), wykorzystywanie. W organizacjach niezbędne jestzapewnienie możliwości współużytkowania wiedzy i swobodnegoprzepływu informacji (dystrybucja informacji i wiedzy). Wymaga tointegracji narzędzi IT, takich jak systemy baz wiedzy, siecineuronowe, systemy wspomagania decyzji grupowych (pracygrupowej), hurtownie danych, systemy pozyskiwania danych (datamining).



Organizacje wirtualne

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



Integracja

Sposób rozumienia integracji zmienia się i pozostaje w ścisłejzależności od osiągniętego poziomu rozwoju w zakresie technologiiIT i zarządzania. Towarzyszy temu rozwój całościowych koncepcji,takich jak komputerowo zintegrowane wytwarzanie (ComputerIntegrated Manufacturing), komputerowo zintegrowane zarządzanie(Computer Integrated Management), komputerowo zintegrowaneprzedsiębiorstwo - biznes (Computer Integrated Business), któreprzedstawiają wskazówki, co do realizacji integracji w dziedziniesystemów informatycznych.System informatyczny przedsiębiorstwa przestaje być uważany zaodrębny element, wymagający ”samodzielnej” integracji, ale corazczęściej jest uważany za immanentny składnik całościowotraktowanego przedsiębiorstwa, co znajduje swój wyraz m.in. wcoraz powszechniejszym używaniu terminu zintegrowaneprzedsiębiorstwo zamiast zintegrowany system informatyczny.




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



Integracja

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



Interfejs

Komunikacja między systemami informatycznymi odbywa się zapośrednictwem interfejsów. W związku z tym interfejs jestpodstawowym elementem modelu integracji systemów. Za jegopośrednictwem system informatyczny przesyła informacje do innegosystemu informatycznego.



Integracja

W konsekwencji można stwierdzić, że modelowanie integracji toinaczej modelowanie komunikatów wymienianych (przez interfejsy)między różnymi systemami informatycznymi oraz procesy niezbędnedo tej wymiany komunikatów.



Poziom analizy

Na potrzeby integraci systemów informatycznych musimyzdefiniować, które informacje mają być wymieniane oraz w jakisposób. Z tego powodu model integracji systemów opisujemy biorącpod uwagę różne punkty widzenia (perspektywy).Najogólniejszy podział związany z perspektywami wyodrębina, dwieperspektywy, tj.

I perspektywę procesu obrazującą aktywności podejmowaneprzez system informatyczny podczas wymiany komunikatów zinnymi systemami informatycznymi;

I perspektywę statyczną opisującą zawartość i strukturę obiektówbiznesowych podlegających wymianie (stanowiącychkomunikat).



Elementy perspektywy

Aktywności, które muszą zostać wykonane w celu wymianykomunikatów między systemami informatycznymi, można opisać zapomocą diagramów sekwencji i diagramów aktywności:

I Diagram sekwencji opisuje chronologiczną kolejność wymianykomunikatów między systemami informatycznymi;

I Diagram aktywności opisuje przepływ działań. Obrazuje onzależności między indywidualnymi akcjami oraz przepływobiektów biznesowych.



Perspektywa procesu

Etapy konstrukcji perspektywy procesu:

1. Określenie interfejsów, czyli pomiędzy jakimi systemamiinformatycznymi odbywa się komunikacja?

2. Identyfikacja zaangażowanych systemów, czyli które systemyinformatyczne 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żnionepodejmowane akcje?

6. Weryfikacja perspektywy, czyli czy wszystko wydaje się działać?



Elementy perspektywy

Do zilustrowania obiektów biznesowych w perspektywie statycznejmodelu integracji systemów wykorzystać można diagramy klas.



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 obiektubiznesowego?

3. Adaptacja klas i atrybutów z diagramu klas systemuinformatycznego, czyli jakie informacje mają być uwzględnionena 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 jakiezwiązki klas będą potrzebne?

6. Weryfikacja perspektywy, czyli czy wszystko wydaje się działać?



Integrowanie w przedsiebiorstwach

Zastosowanie architektury obserwatora procesu pozwala nazintegrowanie rożnych systemów informatycznych wprzedsiębiorstwie. Generalnie, idea obserwatora procesu polega nautworzeniu jednolitego, spójnego modelu danych bieżących(utworzenie „obrazu bieżącego stanu całej produkcji) iudostępnianie go aplikacjom biznesowym według ich potrzebpoprzez międzynarodowe standardy komunikacji (standard OPC) iwymiany danych.



OPC

Zastosowanie serwera OPC, w roli obserwatora procesu, dointegracji systemów w przedsiębiorstwie pozwala nausystematyzowanie struktury połączeń z warstwą procesową ipozyskiwanie danych w jednorodny, zgodny z międzynarodowymistandardami komunikacyjnymi sposób. Raz pobrane dane, służąwielu różnym systemom informatycznym. To istotnie podnosiefektywność pozyskiwania i transferu danych w przedsiębiorstwie.



OPC

OPC jest otwartym standardem komunikacyjnym stosowanym wautomatyce przemysłowej i informatycznych systemach wyższychwarstw, a mianowicie biznesowej i zarządzania, przedsiębiorstwprzemysłowych. Interoperacyjność aplikacji jest zapewniona dziękiutworzeniu i utrzymywaniu specyfikacji otwartych standardów.Utrzymaniem i rozwojem standardu zajmuje się OPC Foundation.OPC powstał i został tak zaprojektowany, aby łączyć aplikacjebazujące na systemach operacyjnych ogólnego stosowania (np.Windows) ze sprzętem i oprogramowaniem aplikacyjnym automatykiprzemysłowej (urządzenia procesowe), nadzorującym i sterującymprocesem 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żneod typu oraz źródła danych.



OPC

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



OPC

Bazując na standardach Microsoft OLE (ang. Object Linking andEmbedding), COM(ang. Component Object Model) i DCOM (ang.Distributed Component Object Model), technologia OPC definiujeinterfejsy przeznaczone do komunikacji z urządzeniamiprzemysłowymi, przez co pozwala uniezależnić oprogramowaniemonitorujące od różnorodnych rozwiązań stosowanych przezproducentów sprzętu procesowego. Technologie COM/DCOMdostarczają infrastrukturę i środowisko programistyczne dlatworzenia i rozwoju oprogramowania. Obecnie są dostępne setkiserwerów i klientów OPC.



OPCW ramach projektu zajmującego się standaryzacją OPC powstałyróżne specyfikacje, z których każda definiuje odrębnąfunkcjonalność. Wśród istniejących specyfikacji możemy wyróżnić:

I OPC Data Access (OPC DA) - umożliwia dostęp doaktualnych danych generowanych w czasie rzeczywistym. Przypomocy OPC DA do serwera OPC kierowane są zapytania oaktualne wartości zmiennych procesowych - np. temperatur,ciśnień itp. Komunikacja z każdym serwerem odbywa się w takisam sposób, z wykorzystaniem tego samego formatu. Klient niemusi wiedzieć w jaki sposób serwer komunikuje się zurządzeniem. Wielu klientów może korzystać jednocześnie ztych samych danych udostępnianych przez serwer.

I OPC Historical Data Access (OPC HDA) - umożliwiaprzeglądanie i analizę zgromadzonych danych historycznych, npw celu oceny wydajności systemu czy przewidywania błędów.Klient uzyskuje dostęp do zarchiwizowanych danych (odczytówjakiegoś urządzenia itp.) poprzez zgłaszanie zapytań do serweraOPC HDA.



OPC

I OPC Alarms and Events (OPC AE) - służy do informowania owystę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ązaneze stanem, jak np. zdarzenie przejścia danej wartości dopoziomu alarmowego lub niezwiązane ze stanem, jak zmianykonfiguracji, czy błędy systemowe. Serwery OPC AE mogąpobierać dane bezpośrednio z urządzenia lub z serwera OPCDA. Serwer OPC AE może być samodzielnym modułem lub teżwchodzić w skład serwera OPC DA.

I OPC Security - służy zapewnieniu bezpieczeństwa dostępu dodanych oferowanych przez serwery OPC. Umożliwia poprawnąweryfikację klienta, który chce uzyskać dostęp i poprawnościtransmisji (czy dane nie zostały zmienione).



OPC

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



OPC Unified Architecture

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



Koniec wykładu 12.



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ówinformatycznych w e-gospodarce.

Stanisław Wrycza, Bartosz Marcinkowski, KrzysztofWyrzykowski, Język UML 2.0 w modelowaniu systemówinformatycznych.

Tańska Halina, Analiza sytsemów informatycznych.

Kisielnicki J., Sroka H., Systemy informacyjne biznesu.Informatyka dla zarządzania, Placet, Warszawa 2005

Modelowanie i analiza systemów informatycznych.math.uni.lodz.pl/~robpleb/wyklad10_14.pdf ·...

Documents

Transcript of Modelowanie i analiza systemów informatycznych.math.uni.lodz.pl/~robpleb/wyklad10_14.pdf ·...