Logikai architektúra és az UML komponens diagramok

Hasonló dokumentumok
Az Országos Nyugdíjbiztosítási Főigazgatóság főigazgatójának. 33/2010. számú utasítása. Az ügymenet-folytonosság biztosítási tervről

Rendszer szekvencia diagram

Nyilvántartási Rendszer

Szakterületi modell A fogalmak megjelenítése. 9. fejezet Applying UML and Patterns Craig Larman

Kölcsönhatás diagramok

ALKALMAZÁS KERETRENDSZER

Szolgáltatás Orientált Architektúra a MAVIR-nál

Elosztott rendszer architektúrák

Közigazgatási informatika tantárgyból

TOGAF elemei a gyakorlatban

Osztott Objektumarchitektúrák

Fejlesztés, működtetés, felügyelet Hatékony infrastruktúra IBM szoftverekkel

A J2EE fejlesztési si platform (application. model) 1.4 platform. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Számítógépes munkakörnyezet II. Szoftver

Üzleti architektúra menedzsment, a digitális integrált irányítási rendszer

Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár

Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Szolgáltatásintegráció (VIMIM234) tárgy bevezető

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

CCS Hungary, 2000 szeptember. Handling rendszer technikai specifikáció

NETinv. Új generációs informatikai és kommunikációs megoldások

Fogalomtár Etikus hackelés tárgyban Azonosító: S2_Fogalomtar_v1 Silent Signal Kft. Web:

Szoftver-technológia II. Architektúrák dokumentálása UML-lel. Irodalom. Szoftver-technológia II.

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

UML (Unified Modelling Language)

Komponens alapú fejlesztés

Osztott alkalmazások fejlesztési technológiái Áttekintés

Kérdés Kép Válasz HIBAS Válasz HELYES Válasz HIBAS Válasz HIBAS Kérdés Kép Válasz HIBAS Válasz HELYES Válasz HIBAS Válasz HIBAS Kérdés Kép Válasz

A Java EE 5 plattform

CRA - Cisco Remote Access

Adatbázis rendszerek. dr. Siki Zoltán

Intelligens közlekedési rendszerek (ITS)

BMEVIHIM134 Hálózati architektúrák NGN menedzsment vonatkozások: II. Üzemeltetés-támogatás és üzemeltetési folyamatok

A SZOFTVERTECHNOLÓGIA ALAPJAI

Utolsó módosítás:

A cloud szolgáltatási modell a közigazgatásban

1. Jogosultsági viszonyok mind az elektronikus rendszer mind hatósági jogviszony tekintetében Szerepkör és jogosultság tervezés

Informatikai alkalmazásfejlesztő Információrendszer-elemző és - tervező

J NEMZETGAZDASÁGI ÁG - INFORMÁCIÓ, KOMMUNIKÁCIÓ. 62 Információtechnológiai szolgáltatás Információtechnológiai szolgáltatás

Programozási technológia

Tartalomjegyzék. Bevezetés. 1. A.NET 3.5-keretrendszer 1. A korszerű alkalmazások felépítésének kihívásai... 2

Oracle9i Alkalmazás Szerver Üzleti folyamat integráció. Molnár Balázs Vezető értékesítési konzultáns Oracle Hungary

A szoftverfejlesztés eszközei

Történet John Little (1970) (Management Science cikk)

S04-2 Elosztott alkalmazások készítése

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

Felhasználók hitelesítése adatbiztonság szállításkor. Felhasználóknak szeparálása

Folyamatok rugalmas irányítása. FourCorm Kft.

Hálózati ismeretek. Az együttműködés szükségessége:

Nyílt forráskódú irodai programkomponensek vállalati környezetbe való integrációjának vizsgálata és implementációja

Fogalmi modellezés. Ontológiák Alkalmazott modellező módszertan (UML)

Space Invaders Dokumenta cio

Szoftverfejlesztő képzés tematika oktatott modulok

Microsoft SQL Server telepítése

Komponens alapú programozás Bevezetés

Számítástechnikai kommunikációs lehetőségek a QB-Pharma rendszerrel. Előadó: Bagi Zoltán Quadro Byte Kft. ügyvezető

Utolsó módosítás:

ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu

Vezetői információs rendszerek

Non-stop hozzáférés az üzleti információkhoz bárhol, bármikor és bármilyen eszközzel

JAVA webes alkalmazások

S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN. Structured Systems Analysis and Design Method

HRdoc+ Rendszerismertető. Számítástechnikai és Szolgáltató Kft. Tel.: H-2051 Biatorbágy, Viola u. 38.

Szolgáltatásintegráció (VIMIM234) tárgy bevezető

Infor PM10 Üzleti intelligencia megoldás

Novell ZENworks Configuration Management. Néhrer János konzultáns Novell PSH Kft.

S01-7 Komponens alapú szoftverfejlesztés 1

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

Alkalmazások architektúrája

Book Template Title. Author Last Name, Author First Name

Crossplatform mobil fejlesztőkörnyezet kiválasztását támogató kutatás

Programozás I. 2. gyakorlat. Szegedi Tudományegyetem Természettudományi és Informatikai Kar

Digitális írástudás kompetenciák: IT alpismeretek

SZOFTVERES SZEMLÉLTETÉS A MESTERSÉGES INTELLIGENCIA OKTATÁSÁBAN _ Jeszenszky Péter Debreceni Egyetem, Informatikai Kar jeszenszky.peter@inf.unideb.

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

Intelligens biztonsági megoldások. Távfelügyelet

Az előadás célja. Információrendszer fejlesztés módszertana, Dr. Molnár Bálint egyetemi docens 1

Szoftver újrafelhasználás

IV.4. FELHŐ ALAPÚ BIZTONSÁGOS ADATTÁROLÁSI MÓDSZER ÉS TESZTKÖRNYEZET KIDOLGOZÁSA

Elosztott rendszerek. Az elıadás. Az elosztott rendszer definíciója. Köztesrétegként felépülı elosztott rendszer

Adatbázis rendszerek 7. előadás State of the art

Prolan Zrt. fejlesztéseiben. Petri Dániel

Tartalom. Történeti áttekintés. Történeti áttekintés Architektúra DCOM vs CORBA. Szoftvertechnológia

Elnevezési rendszerek. 7. előadás

ADATBÁZISOK ADATBÁZIS-KEZELŐ RENDSZEREK. Debrenti Attila

01. gyakorlat - Projektalapítás

Információ-architektúra

1. tétel. A kommunikáció információelméleti modellje. Analóg és digitális mennyiségek. Az információ fogalma, egységei. Informatika érettségi (diák)

Követelmény meghatározás. Információrendszer fejlesztés módszertana, Dr. Molnár Bálint egyetemi docens 1

Szoftver-technológia I.

Adatbázisok elleni fenyegetések rendszerezése. Fleiner Rita BMF/NIK Robothadviselés 2009

SDL Trados szervermegoldások. Szekeres Csaba SDL Trados partner M-Prospect Kft.

Funkciópont elemzés: elmélet és gyakorlat

INTERNET. internetwork röviden Internet /hálózatok hálózata/ 2010/2011. őszi félév

Autóipari beágyazott rendszerek Dr. Balogh, András


Private Cloud architektúra keretrendszer

Bárányfelhő vagy viharfelhő? A felhő alapú megoldások biztonsági kérdései. Császár Rudolf Műszaki fejlesztési vezető Digital Kft.

gyakorlatban Nagy Gusztáv

Átírás:

Logikai architektúra és az UML komponens diagramok UML és az architektúra mintázatok alkalmazása 1

Experience is that marvelous thing that enables you to recognize a mistake when you make it again. F. P. Jones A tapasztalat az a csodálatos dolog, amely lehetővé teszi azt, hogy felismerjük a tévedésünket akkor, amikor újra elkövetjük. 2

Logic is the art of going wrong with confidence. Joseph Wood Krutch Logika az a tudomány, amelyben feltétel nélkül bízva teljesen félrevezető eredményre jutunk. 3

Definíció (Meghatározás) Szoftver architektúra: Több formája van. A közös vonás az, hogy a nagy léptékű, Nagy gondolatok, ötletek megfogalmazása jellemzi, az egész rendszer és a jelentősebb részrendszerek tekintetében: rendszerszervezés, az architektúrát befolyásoló szempontok, stílus/megközelítés, mintázatok, felelősségek, együttműködés, kapcsolatok és motivációk 4

A definíció variációi A szoftver fejlesztésben az architektúra szót mint egy fogalomra utaló főnevet illetve mint a tervezési cselekményre utaló igét is használják (architektúra tervezés). Az architektúra fogalma mint főnév magában foglalja a rendszer jelentősebb elemeinek szerkezeti összefüggéseit és szervezését. Mint cselekmény részben a vizsgálódásra, elemzésre részben a a tervezési munkára utal. 5

Definíció (Meghatározás) Architektúra vizsgálata, elemzése: a rendszer tervét befolyásoló funkcionális és nem funkcionális követelmények elemzését tartalmazza. Néhány elem: Piaci tendenciák, teljesítmény, költség és a fejlődés töréspontjai. Architektúra tervezés: a fentebbi követelmények, szempontok, mozzanatok összehangolása és összeegyeztetése, a szoftver tervezésében. 6

Az architektúra dimenziói és nézetei Az általános dimenziók a következők. A logikai architektúra a rendszerszervezésének mikéntjét szakmai terminológia fogalmaival írja le: rétegek, komponensek, osztályok, (adat)kapcsoló felületek és részrendszerek. Az üzembe helyezett, letelepített architektúra a rendszert a rendszer folyamatok értelmében, a folyamatok és az adatfeldolgozó egységek (kiszolgáló gépek, CPU stb.) valamint a hálózati elemek összerendelése révén. 7

Mit tekintünk rétegnek? A réteg az osztályok, komponensek vagy részrendszerek olyan durva felbontású csoportosítása, amely a rendszer bizonyos fontosabb jellemzőinek kohéziójáéért felel. A magasabb szintű rétegek az alacsonyabb szintű rétegek szolgáltatásait veszik igénybe. 8

Rendszer, funkció belső kapcsolatának, kohéziójának erőssége Kohézió gyenge foka Esetleges Logikai Időbeli Kommunikációs Eljárási Funkcionális Kohézió erős foka 9

Kohézió foka Esetleges kapcsolat: a rendszert alkotó részeket nem köti össze semmi felismerhető kapcsolat. Logikai kapcsolat: a rendszer részei, tevékenységei ugyanolyan típusúak, de valahányszor a rendszert aktiválják, mindig csak az egyik részét jelölik ki végrehajtandónak. Időbeli kapcsolat: a rendszer részeit, tevékenységeit ugyanakkor kell végrehajtani, vagy ugyanakkor kell kezdeni, de mind különböző jellegű. Kommunikációs kapcsolat: a rendszer részei, tevékenységei mind ugyanazt a dolgot ('entitást') használják. Eljárási kapcsolat: a rendszer részeit, tevékenységeit mindig egy előre rögzített sorrendben kell végrehajtani. Funkcionális kapcsolat: a rendszer részei, tevékenységei mind ugyanazt a célt szolgálják. 10

Csatolás: a függetlenség kritériumai Tartalmi Külső Vezérlési Közös rendszer Adat / információ Erős csatolás Gyenge csatolás 11

A csatolás ( coupling ) Tartalmi csatolás: a rendszer egy részét egy másik rendszer vagy részrendszer hívja meg és hajtatja végre a saját céljaira. Ennek megtételéhez vezérlési információk szükségesek, amelynek alapján a vezérlés a helyes időben tér vissza a kezdeményező rendszerhez. Külső csatolás: az egyik rendszer vagy bizonyos rendszerek meg tudják változtatni egy másik rendszer működését az előbbiek irányítása alatt. Ezek a rendszerek nem közlik a megváltoztatott rendszerrel, hogy mi történik. Vezérlési csatolás: a rendszer működését, tevékenységeinek végrehajtását egy vagy több rendszer irányítja. Az irányított rendszernek tudni kell, hogy kinél van a vezérlés pillanatnyilag. Közös rendszer: két vagy több rendszer használ egy másik rendszert, aki viszont saját maga rendelkezik a saját erőforrásai felett. Adat / információ csatolás: Ez a lehető leggyengébb csatolás. A rendszerek közti kapcsolat kimerül adat és / vagy információ cserében (esetleg valami anyag átadásában). 12

Architektúra mintázatok és mintázat kategóriák Architektúra mintázatok: A nagyléptékű, nagy vonalú terv elkészítéséhez kapcsolódik, és tipikusan a fejlesztési folyamat korai iteratív lépéseiben alkalmazzák (a kidolgozás fázisában) A tervezési mintázatok: az objektumok és az átfogó keretrendszerek közepes-léptékű és kis-léptékű terv készítéséhez kapcsolódnak. Idiómák: a nyelvhez illetve az alacsony szintű, a megvalósításhoz kötődő tervekhez, megoldásokhoz kapcsolódnak. 13

Architektúra mintázatok : Rétegek ( layer ) A réteg mintázatok mögött meghúzódó elképzelés: Szervezzük a rendszer nagy-léptékű logikai szerkezetét elkülönülő, az egymásért felelősséget viselő elemeket összefogó rétegekbe, amelyek világosan, és kohézív módon elhatárolják az illetékességeket úgy, hogy az alsóbb rétegek alacsony-szintű és általános szolgáltatásokat nyújtanak, a magasabb szintű rétegek sokkal alkalmazás specifikusabbak. A rétegek közötti együttműködés és csatolás a magasabb szintű rétegektől az alacsonyabb szintű rétegek felé halad. 14

Rétegek közötti és komponensek között csatolás A rétegek és a komponensek közötti kapcsolatok érzékeltetésére a logikai architektúra nézetet ábrázoló diagramot érdemes készíteni 15

A komponensek közötti részleges csatolás Felhasználói felület Swing Értékesítés folyamat KERETE Szakterület Értékesítés Nyilvántartás Értékesítés Árazás Szolgáltatás elérése Szolgáltatás nyújtás (Factory) Készletgazdálkodás interface KészletG Adapter Fizetések Bankkártyás fizetés POSSzabályGép POSSzabályGépFaçade interface BankkártyaAutorizáció Service Adapter Adók AdóKalkulátor Adapter Informatikai szolgáltatások Perzisztencia Adatbázis Façade BCE, Információrendszer NaplóJávára (Log4J) tanszék, Dr. Molnár JESS SOAP 16

Rétegek közötti és komponensek közötti kölcsönhatás A rétegekben elhelyezkedő objektumok, rétegeken átívelő kapcsolatainak és kommunikációinak a dinamikáját hangsúlyozza. A kölcsönhatás (interaction diagram) diagram a logikai nézetre helyezi a hangsúlyt, a rétegek között együttműködésre és a komponensek határaira. Façade : Homlokzat, olyan adatkapcsolati felület, amely eltakarja azt, hogy bizonyos körülményektől függően az adatfeldolgozás más jellegű lehet. 17

Komponens diagramok Az UML komponens diagram gyakran jelzi a komponensek tartalmát, JAVA nyelvben, programozási környezetben ezt gyakran csomagnak (package ) hívják. A komponensek, csomagok természetesen egymásba ágyazhatók. 18

Komponens diagram Felhasználó felület Szakterület Swing Web Értékesítés 19

Logikai kontra folyamat kontra üzembe helyezett architektúra Az architektúra rétegek az architektúra logikai nézetét érzékeltetik. Nem az üzembe helyezett, letelepített elemek és folyamatok viszonyát testesítik meg. Az informatikai platformtól függően, az összes architektúra réteget ugyanabba a folyamatba, egy azon csomópontra is lehet telepíteni. Vagy sok számítógép csomópontra szétosztva. 20

Terminológia: szint (tier), réteg (layer) és partíció A szint a fizikai csomópontokra vagy csomópontok fürtjére utal, például ügyfél (kliens) szint Az architektúra rétegei az architektúra vertikális ( vízszintes ) metszeteit érzékeltetik. A partíciók a réteg viszonylag párhuzamos részrendszereinek horizontális ( függőleges ) felosztását ábrázolják. 21

Rétegek és partíciók Szakterület POS Készletgazdálkodás Adó Vertikális partíció Informatikai szolgáltatások Perzisztencia Biztonság WEB AlkalmazásiKeretrendszer (AppFrame) Horizontális partíció 22

Hogyan tervezzük meg az alkalmazási rendszer logikáját objektumokkal? Készíthetünk egyetlen egy osztályt, amelye a teljes alkalmazás logikát tartalmazza, azonban ez alapjaiban sérti az objektum-orientált tervezés szellemét. Létrehozhatunk olyan objektumokat, amelyeket a való világ alapján nevezünk el, és az alkalmazás logikájának megvalósítását rábízzuk. Sok ügyességet és tapasztalatot igényel a megfelelő objektumok kiválasztása, és felelősségek kijelölése 23

Szakterület rétege és a szakterület modellje Ezek nem ugyanazok a dolgok. A szakterület modell a való világ modelljét ábrázolja, míg a szakterület rétege a szoftver architektúrát. Azonban a szakterület modellje inspirálja a szakterület réteget, és a fogalom alkotás forrása, valamint az osztály elnevezések kiindulópontja. Ne keverjük össze a probléma megfogalmazását, a megoldással 24

Információrendszerek Az információrendszerek architektúra rétegeit a három-szintű architektúra (three-tier architecture) fogalmával írták le. A három-szintű architektúra az adatkapcsolati felületből, az alkalmazási logikából és az adattárolási szolgáltatásokból áll. A három-szintű architektúra minőségi jellegzetessége: Az alkalmazási logikai leválasztása egy elkülönített köztes logikai szintbe. Az adatkapcsolati, felhasználó felület et ezzel megszabadítják az alkalmazási logikához köthető feldolgozási feladatoktól. Az adattárolási szolgáltatások az adatok tartós, perzisztens, adatbázis jellegű megőrzését jelentik. 25

Információrendszerek (folyt.) A középső szint kommunikál az adattráolási és háttér réteggel. Egy példa a 3-szintű architektúrára 26

Példa: 27

Két-szintű architektúra terv Ebben az architektúra tervben, az alkalmazási logika az ablakok definíciójában helyezkedik el, és ez azt jelenti, hogy közvetlenül olvassa és írja az adatbázist. Nincs köztes réteg, amely elválasztaná az alkalmazási logikától. 28

A modell-nézet elválasztásának elve Az alapelv szerint: a modell (szakterületi) objektumoknak nem lehet közvetlen ismerete a nézet (megjelenítési) objektumokról. Továbbá, a szakterület fogalom osztályainak magukba kell foglalniuk az alkalmazási logikához kapcsolódó információkat és az ebből származó viselkedési szabályokat. 29

A modell-nézet elválasztásának szükségessége A modell definíció kohézióját kell támogatni az elválasztásnak, amely a szakterület folyamataira koncentrál és nem felhasználói, adatkapcsolati felületre. A modell és a felhasználói felület fejlesztésének elválasztását lehetővé kell tenni. A felhasználói felületre vonatkozó követelmények változásának hatását lehetőleg mérsékelni kell a szakterület architektúra rétegére. Az újabb rendszer nézetek megjelenése esetén azok könnyedén hozzákapcsolhatók legyenek a már létező szakterület architektúra réteghez anélkül, hogy befolyásolnák a szakterület architektúra rétegét. 30

Folytatás.. Ez a megközelítés lehetővé teszi azt, hogy egyszerre, egy időben több szimultán nézeten keresztül lehessen látni a modell objektumait. A modell rétegben a folyamatok végrehajtása a felhasználó felülettől függetlenül történhet. A modell réteg könnyen hordozható más, felhasználói felületet megvalósító keretrendszert használó környezetbe. 31

SOA jellegű architektúra 32

33

Az informatikai szolgáltatások logikai architektúrális sajátosságainak jellemzése Információ rendszer: Alkalmazási rendszer típusa: Szervezeti szintű alkalmazás Informatikai szolgáltatás kategória Alkategória Szüksége s-e Megvalósító/támogató technológia Adatkezelés Adatbázis kezelő rendszer Igen Bevált adatbáziskezelő rendszer / OEP stratégiai döntés alapján kiválasztott Biztonsági szolgáltatások Címtár és szolgáltatás lokalizáció szolgáltatás Repozitórium (Adatszótár) Személyazonosítási és hitelesítési szolgáltatások Auditálási lehetőségek biztosítása Hozzáférés ellenőrzés, nyomon követés, kézben tartás Igen Igen PKI infrastruktúra, X.509 tanúsítvány, SAML Security Assertion Markup Language egy XML, XACML - extensible Access Control Markup Language (XACML), SPML a Service Provisioning Markup Language (SPML), SOAP -a SOAP (Simple Object Access Protocol), Minősített és fokozatt biztonsági szint Igen Igen LDAP, Szerep-alapú jogosultság kezelés (RBAC) Biztonságirányítás Igen ISO/IEC 27000, ISO/IEC TR 13335 Címtár szolgáltatások Igen LDAP, Szolgáltatási minőség Rendelkezésre állás Igen 24/7/365, 99,95% Adaptálhatóság Igen Skálázhatóság, kiszolgáló gépek 34

Hálózati szolgáltatások Adat kommunikáció Igen TCP/IP Elektronikus levél Távoli eljárások (Remote processes) Elosztott adatbázis kezelés Nem Nem Nem Tranzakció feldolgozás Tranzakciókezelése Igen Felhasználói felületek Karakter alapú Nem Ablakos, grafikus rendszer Igen MS Windows Adatcsere Dokumentum Nem Grafikus, digitális kép elem Nem Elektronikus adat Igen Grafikus és digitális kép szolgáltatások Grafikus objektum kezelés Nem Rajzolás Nem Rendszer és hálózatfelügyelet Hálózat felügyelet Igen Hálózatfelügyeleti szoftver Teljesítmény kezelés Igen Hálózatfelügyeleti szoftver Konfiguráció kezelés Nem Manuális Meghibásodások kezelése Igen Hálózatfelügyeleti szoftver Mentés, visszaállítás Igen Manuális Biztonságirányítás Igen Manuális Felhasználói felület készítési szolgáltatások Igen 35

Operációs rendszer Kernel szolgáltatások Igen szabványos operációs rendszer Szoftver tervezési szolgáltatások Programozási nyelvek Specifikáció, tervezési, kivitelezési, rendszerépítési szolgáltatások Igen Igen 36