RSS
 

Archiwum - Październik, 2016

Podstawowe pojęcia baz danych

31 paź

Baza danych jest logicznie spójnym zasobem przechowywanych i udostępnianych danych w aspekcie określonego wycinka rzeczywistości.

Dane przechowywane w bazach danych zmieniają postać z tradycyjnych danych znakowych, tekstowych w stymulowane przez rozwój technologii internetowych baz danych multimedialne, zawierające poza tekstem obiekty graficzne, dźwiękowe, animacje i wideo.

System zarządzania bazą danych to system oprogramowania, który umożliwia tworzenie i użytkowanie bazy danych.

System baz danych stanowi powiązanie bazy danych z obsługującym go systemem zarządzania bazą danych.

Baza danych tworzy repozytorium danych niezbędnych dla eksploatacji danej aplikacji. Użytkowanie i modyfikacja tego zasobu są możliwe dzięki systemowi zarządzania baz danych.

Ten sam system zarządzania bazami danych może być użytkowany dla wielu baz danych.

Użytkownicy określonej bazy danych formułują zapytania w języku zapytań bądź wykorzystują programy obsługujące bazodanowe aplikacje. Zapytania te i aplikacje mogą być zrealizowane poprzez wykorzystanie drugiej warstwy systemu zarządzania danych, obsługującej dostęp do danych przechowywanych w bazie.

 
Brak komentarzy

Napisane w kategorii IX. Bazy danych

 

Podejście SOA

30 paź

SOA (Service-Oriented Architecture) oznacza dopasowanie do procesów biznesowych i użytkowników systemów luźno powiązanych pakietów oprogramowania, które pełnią funkcje usługowe wobec procesów i użytkowników. Zasoby oprogramowania są dostępne w sieci. Do realizacji swej funkcji SOA wykorzystuje szereg międzyoperacyjnych standardów, umożliwiających stabilną architekturę między różnymi platformami. Jest on niezależny od użytkowanej platformy. Architektura ta pozwala na powiązanie zasobów aplikacji, tak aby osiągnąć rezultaty stosownie do określonych systemów czy usług. OASIS (Organization for the Advancement of Structured Information Standards) podkreśla, że SOA jest paradygmatem skoordynowanego organizowania i użytkowania rozproszonych zasobów, które mogą być własnością różnych osób i instytucji.

 

MDA – modelowanie architektury systemu

29 paź

MDA to sposób organizowania i zarządzania architekturą przedsięwzięcia projektowego, wspomaganego zautomatyzowanymi narzędziami i usługami w celu zdefiniowania modeli i ułatwienia transformacji pomiędzy różnego rodzaju modelami. Model systemu jest tworzony w sposób niezależny od wspomagającej go platformy. Architektura systemu to specyfikacja części, składników, elementów systemu, związków między nimi, a także zasad interakcji pomiędzy tymi elementami.

MDA określa dwa rodzaje modeli, które mogą być użytkowane – PIM i PSM. Model PIM (ang. platform-independent model) przedstawia określony poziom niezależności od platformy, co w konsekwencji umożliwia dostosowanie modelu PIM do różnych platform. Z kolei PSM (ang. platform-specific model) łączy specyfikacje PIM z poszczególnymi typami platform PSM, które zawierają zestaw pojęć technicznych umożliwiających funkcjonowanie platform i jej usług. Platforma jest zestawem podsystemów i technologii, które zapewniają pożądaną funkcjonalność systemu poprzez interfejsy i wzorce. Niezależność platform oznacza niezależność modelu PIM od cech platform dowolnego typu.

Użytkowanie MDA polega na wykonaniu kolejno następujących czynności:
- opracowanie specyfikacji systemu w postaci modelu niezależnego od platformy PIM, na której będzie użytkowany,
- specyfikacja platform PSM,
- wybór właściwej platformy dla systemu,
- przekształcenie specyfikacji systemu PIM na wybraną platformę PSM.

Pomiędzy modelami istnieją określone reguły odwzorowania (ang. mapping, które pozwalają na przekształcenie modelu źródłowego w wynikowy. Proces ten może być zautomatyzowany.

 

Metodyki adaptacyjne

28 paź

Metodyka adaptacyjna (ang. agile, agility – definiowanie, a następnie modyfikacja i adaptacja potrzeb informatycznych.

Podejście adaptacyjne zakłada zasadniczą trudność w zrozumieniu identyfikacji potrzeb informatycznych i założeń systemu, a w konsekwencji możliwość i akceptację och zmian, modyfikacji oraz adaptacji w procesie tworzenia systemu.

Podstawowe zasady podejścia adaptacyjnego są to stwierdzenia dotyczące przewagi:
- osób (jednostek) i interakcji nad procesami oraz narzędziami,
- efektywnie użytkowanego oprogramowania nad obszerną dokumentacją,
- współpracy z klientami nad negocjowaniem kontraktu,
- reakcji na zmiany nad realizacją planu.

Sygnatariusze Agile Manifesto nie podważają wartości drugiego członu w każdym z czterech powyższych wyrażeń, jednak akcentują większe znaczenie kategorii znajdujące się w pierwszym ich członie. Autorzy Agile Manifesto sformułowali 12 zasad, które powinny umożliwić wdrożenie tych wartości, a więc:
- najważniejszym priorytetem jest spełnienie oczekiwań i wymagań klienta poprzez wczesne i bieżące dostarczanie użytecznego oprogramowania,
- zmiana założeń i potrzeb systemu jest akceptowana nawet w końcowej fazie procesu TSI, procesy adaptacyjne włączają zmianę w osiąganie przewagi konkurencyjnej przez klienta,
- użyteczne, sprawne oprogramowanie musi być dostarczane przez zespół projektowy często, od kilku tygodni do kilku miesięcy, z tendencją do krótszych odcinków czasu,
- przyszli użytkownicy systemu odpowiedzialni za procesy biznesowe oraz zespół informatyków muszą współpracować w codziennej realizacji projektu,
- projekt powinien być tworzony przez zmotywowanych profesjonalistów, jeśli właściwe środowisko i wsparcie są zapewnione, twórcy systemu mogą być pewni wykonania swego zadania,
- najbardziej efektywną i skuteczną metodą przekazywania informacji w zespole jest bezpośrednia konwersacja,
- użyteczne oprogramowanie opracowane przez zespół jest podstawową miarą postępu prac,
- procesy adaptacyjne promują stały zrównoważony rozwój, sponsorzy, twórcy i użytkownicy powinni stale współpracować w sposób nieograniczony,
- uwaga nakierowana na techniczną doskonałość i poprawność projektu zwiększa zalety podejścia adaptacyjnego,
- prostota, oszczędność, czyli sztuka maksymalizacji zakresu pracy, która nie musi być wykonana, ma podstawowe znaczenie,
- najlepsze struktury, wymagania i projekty wynikają z samoorganizujących się zespołów,
- w regularnych odstępach czasu zespół ocenia i dokonuje projekcji, jak stać się bardziej skutecznym, a następnie reguluje, uzgadnia i dostosowuje odpowiednio swe działanie.

 

Pakiety CASE

27 paź

Pakiety CASE to narzędzia, które wspomagają zautomatyzowane tworzenie systemów informatycznych w trakcie cyklu życia systemu. Stanowią zastosowanie technologii komputerowej w odniesieniu do procesów, technik i metodyk tworzenia systemów informatycznych. Integrującym składnikiem pakietu CASE jest encyklopedia systemu, zwana również repozytorium projektu systemu.

Pozostałe składniki pakietu CASE:
- edytory diagramów różnorodnych metod i technik TSI,
- generator kodu programowego,
- moduł prototypowania systemów,
- moduł modyfikacji i adaptacji systemów,
- moduł eksportu/importu danych,
- moduł kontroli spójności systemu.

5 klas pakietów CASE:
- przechowywania danych,
- wspomagania cyklu życia systemu,
- adaptacji i modyfikacji systemów,
- kierowania realizacją projektów,
- bieżącego doskonalenia jakości systemu.

Najważniejsza z klasyfikacji dotyczy pakietów wspomagających cykl życia systemu, które można podzielić na pakiety CASE:
- planowania strategicznego o modelowania biznesu,
- wysokiego poziomu (ang. upper CASE lub front-end tools) – wspomaganie realizacji faz analizy i projektowania systemów,
- niskiego poziomu (ang. lower CASE lub back-end tools) – wspomaganie programowania, wdrażania oprogramowania i bazy danych, modyfikacji i użytkowania systemów informatycznych.

 

Diagramy przypadków użycia

26 paź

Diagramy przypadków użycia (DPU) wyznaczają podstawową perspektywę pozostałym diagramom języka UML. DPU zawierają następujące główne kategorie pojęciowe:
- przypadek użycia to specyfikacja ciągu akcji i ich wariantów, które system może wykonać poprzez interakcje z aktorami tego systemu,
- aktor to spójny zbiór ról odgrywanych przez użytkowników przypadku użycia w czasie interakcji z tym przypadkiem użycia, najczęściej przybiera on postać asocjacji,
- asocjacja to semantyczne powiązanie pomiędzy elementami modelu.

Kategorie te w każdym diagramie są ze sobą ściśle powiązane.

 

Diagramy przepływu danych

25 paź

Diagramy przepływu danych (DPD) zawierają cztery kategorie pojęciowe. Istnieje kilka konwencji graficznych, z których najczęściej użytkowane są dwie: Yourdona-DeMarco i Gane’a-Sarsona.

Podstawowe kategorie pojęciowe i odpowiadające im symbole graficzne to:
- proces (funkcja),
- przepływ danych,
- składnica (zbiór, magazyn),
- terminator (obiekt zewnętrzny).

ZNACZENIA POJĘCIOWE W DIAGRAMACH PRZEPŁYWU DANYCH
Znaczenia pojęciowe w diagramach przepływów danych

 

Rodzaje metod i technik TSI

24 paź

Spośród najbardziej popularnych metod warto wymienić w przypadku metodyk:
- strukturalnych – diagramy związków encji i diagramy przepływów danych, ocenia się, że istnieje ok. 100 diagramów strukturalnych metod i technik,
- obiektowych – 13 rodzajów diagramów UML, wśród których najważniejszą rolę odgrywają diagramy przypadków użycia,
- społecznych – tu wyróżnia się przede wszystkim tzw. wzbogacone wizerunki, definicje podstawowe i modele konceptualne.

Podejście adaptacyjne akcentuje przewagę efektywnie użytkowanego oprogramowania nad obszerną dokumentacją. Mniejszą rolę odgrywają w tym przypadku diagramy, a większą – narzędzia oprogramowania.

 

Iteracyjno-przyrostowy cykl życia systemu

23 paź

Koncepcja stopniowego, przyrostowego rozwoju systemu, tak aby określone jego moduły mogły być na bieżąco oprogramowane, wdrożone i użytkowane. Najbardziej uznany jest tu model iteracyjno-przyrostowy, opracowany w ramach metodyki RUP (Rational Unified Process). Ma on postać macierzową.

Cykl iteracyjno-przyrostowy opiera się na zależnościach pomiędzy dyscyplinami oraz fazami. Linia pozioma reprezentuje czas, a zatem dynamiczny aspekt procesu TSI, uwzględnia przede wszystkim fazy tworzenia systemu i związane z nimi iteracje oraz punkty przeglądu.

Zgodnie z metodyką RUP wprowadza się cztery fazy:
- rozpoczęcie
– wypracowanie ogólnej wizji przedsięwzięcia oraz osiągnięcie zrozumienia i akceptacji projektu przez wszystkich jego uczestników,
- opracowanie – ustalenie architektury systemu, stworzenie planu projektu oraz wyeliminowanie elementów wysokiego ryzyka z projektu,
- budowa – stworzenie systemu w oparciu o przyjętą architekturę,
- przekazanie – dostarczenie gotowego systemu użytkownikom czy klientom.

Iteracja w metodyce RUP to pojedynczy cykl w ramach fazy, polegający na realizacji zestawu wybranych, adekwatnych czynności z zakresu poszczególnych dyscyplin. Jej efektem jest kolejny przyrost funkcjonalności systemu. Szacuje się, że kolejnym czterem fazom odpowiadają procentowe udziały czasu tworzenia systemu informatycznego, odpowiednio: 10%, 30%, 50% i 10%.

Mechanizm funkcjonowania cyklu iteracyjno-przyrostowego polega na tym, że w każdej z tych iteracji użytkowane są adekwatne artefakty z poszczególnych dyscyplin. W każdej iteracji mamy tym samym do czynienia z minicyklem liniowym. W fazach cyklu życia RUP czynności poszczególnych dyscyplin często są wykonywane równolegle. Dzięki powstającym artefaktom określone funkcje systemu mogą być wdrożone i ocenione po wykonaniu kolejnych iteracji.

Linia pionowa odzwierciedla statyczny aspekt procesu TSI, tj. jego opis w kategoriach: dyscyplin i związanych z nimi szczegółowych czynności, artefaktów, ról i przepływów pracy. Dyscyplina, w rozumieniu metodyki RUP, stanowi kolekcję powiązanych czynności, artefaktów, ról oraz przepływów pracy, odpowiadających tematycznie głównym obszarom tworzenia systemów informatycznych. Występują dyscypliny podstawowe i wspomagające.

Dyscypliny podstawowe stanowią rdzeń procesu tworzenia systemu. Należą do nich:
- modelowanie biznesowe – zawierające wizję nowego procesu biznesowego czy wręcz docelowej organizacji, definicje występujących w jej ramach procesów, ról i zakresów odpowiedzialności, przedstawione w postaci diagramów biznesowych bądź diagramów przypadków użycia UML,
- specyfikacja wymagań – opracowanie wizji systemu, modelu przypadków użycia i zdefiniowanie wymagań niefunkcjonalnych,
- analiza i projektowanie z wykorzystaniem całego spektrum diagramów UML,
- programowanie – opracowanie kodu źródłowego w wybranym języku programowania oraz kompilacja kodu i integracja komponentów,
- testowanie – planowanie testów oraz ocena systemu poprzez wykonanie wielu testów,
- wdrożenie – instalacja oprogramowania systemu i formalna akceptacja kolejnych wersji systemu przez klienta czy użytkownika.

Dyscypliny wspomagające realizują funkcje zarządcze i konfiguracyjne w procesie tworzenia systemu. Można do nich zaliczyć:
- zarządzanie konfiguracją i zmianami – kontrola wersji artefaktów opracowanych podczas kolejnych iteracji,
- zarządzanie projektem – planowanie i kontrola realizacji projektu,
- przygotowanie środowiska – przygotowanie infrastruktury do skutecznej realizacji projektu.

 
 

Spiralny cykl życia systemu

22 paź

Model spiralny – poszczególne fazy cyklu życia są realizowane na zasadzie spirali, oznaczającej ich powtarzanie drogą doskonalenia kolejnych wersji systemu, będących rezultatem weryfikacji, oceny i eksperymentów w użytkowaniu jego coraz bardziej rozbudowanych prototypów.

I faza – plan systemu informatycznego o zakresie tematycznym zgodnym z merytoryczną treścią etapu planowania w cyklu liniowym, często nazywanym infoplanem.

II faza – analiza ryzyka – ocena finansowych i organizacyjnych konsekwencji zaprojektowania, analizy i wdrożenia infoplanu. W tej fazie cyklu spiralnego jest to czas na decyzję o kontynuowaniu tworzenia systemu bądź dokonaniu zmian i korekt, czy wręcz z rezygnacji z jego dalszego rozwoju.

III faza – projektowanie systemów informatycznych (przy pozytywnej decyzji) – opracowywanie kolejnych wersji prototypów, stopniowo udoskonalanych i uzupełnianych, aż do stworzenia wersji końcowej systemu.

IV faza – weryfikacja – dokonanie oceny funkcjonalności prototypu systemu w aspekcie sformułowanych przez niego założeń i wymagań systemu.