Analizy systemowe

Slajd nr 2

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie oprogramowania

Zawartość:



Prototypowanie w procesie tworzenia
oprogramowania



Metody błyskawicznego prototypowania



Prototypowanie interfejsu użytkownika

Slajd nr 3

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie oprogramowania



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



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



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



Inne cele:



Szkolenia użytkowników



Testowanie systemu

Slajd nr 4

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie oprogramowania

Establish

prototype

objectives

Define

prototype

functionality

Develop

prototype

Evaluate

prototype

Prototyping

plan

Outline

definition

Executable

prototype

Evaluation

report

Slajd nr 5

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie oprogramowania



Prototypowanie



Prototypowanie ewolucyjne

zaczyna się od zbudowania

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



Prototypowanie z porzuceniem

służy do udoskonalania i

wyjaśnienia specyfikacji. Po napisaniu specyfikacji
prototyp jest porzucany.



Cele



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



Celem prototypowania z porzuceniem jest zatwierdzenie
i dostarczenie wymagań.

Slajd nr 6

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie oprogramowania

Evolutionary

prototyping

Throw-away

Prototyping

Delivered

system

Executable Prototype +

System Specification

Outline

Requirements

Slajd nr 7

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie ewolucyjne



Zalety prototypowania ewolucyjnego



Przyspieszone dostarczenie systemu.



Włączenie użytkownika w budowę systemu



Wspólne cechy błyskawicznych metod
tworzenia oprogramowania:



Przeplatanie procesu specyfikowania, projektowania
i implementowania



System budowany jest w postaci ciągu przyrostów



Stosuje się narzędzia CASE i języki 4GL



Interakcyjna metoda budowy interfejsów.

Slajd nr 8

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie ewolucyjne



Problemy z prototypowaniem ewolucyjnym



Kłopoty z zarządzaniem

. prototypy ewoluują tak

szybko że nie nadąża się z dokumentacją.



Kłopoty z pielęgnacją

. Ustawiczne zmiany powodują

uszkodzenia struktury prototypowanego systemu.



Kłopoty z umową

. Zwykły model umowy klienta z

wytwórcą oprogramowania oparty jest na
specyfikacji systemu. Klienci nie znają zakresu prac.
Dostawcy nie chcą się zgodzić na stałą cenę.

Slajd nr 9

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie ewolucyjne

Build prototype

system

Develop abstract

specification

Use prototype

system

Deliver

system

System

adequate?

YES

Slajd nr 11

©Ian Sommerville 2000 - Inżynieria oprogramowania

Przyrostowy proces tworzenia

Validate

increment

Build system

increment

Specify system

increment

Design system

architecture

Define system

deliverables

System

complete?

Integrate

increment

Validate

system

Deliver final

system

YES

Slajd nr 12

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie z porzuceniem



Najczęściej stosowany przy budowie systemów
sprzętowych. Posługując się ‘komponentami z
półki’ sprawdzamy projekt przed podjęciem
decyzji o kosztownych zakupach.



Przy budowie oprogramowania prototyp nie
służy do oceny projektu ale pomaga w
opracowaniu wymagań. Prototyp najczęściej
tworzymy przy pomocy innych narzędzi niż
projekt. W prototypie porzucanym można
pominąć kryteria efektywności i jakości na
rzecz szybkiego rezultatu

Slajd nr 13

©Ian Sommerville 2000 - Inżynieria oprogramowania

Prototypowanie z porzuceniem

Outline

requirements

Develop

prototype

Evaluate

prototype

Specify

system

Develop

software

Validate

system

Delivered

software

system

Reusable

components

Slajd nr 15

©Ian Sommerville 2000 - Inżynieria oprogramowania

Języki programowania bazy danych



Języki 4-tej generacji 4GL (Narzędzia)



Języki zapytań do bazy danych



Generator interfejsów



Arkusz kalkulacyjny



Generator raportów

Slajd nr 16

©Ian Sommerville 2000 - Inżynieria oprogramowania

Języki programowania bazy danych

programming

language

Interface

generator

Spreadsheet

Report

generator

Database management system

Fourth-generation language

Slajd nr 17

©Ian Sommerville 2000 - Inżynieria oprogramowania

Scalanie komponentów i programów
użytkowych

Component

composition

framework

Executable

prototype

Reusable

software

components

Control and

integration code

Slajd nr 20

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne

Zawartość:



Strukturalizacja systemu



Modele sterowania



Rozkład na moduły



Architektury charakterystyczne dla różnych
dziedzin

Slajd nr 21

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Wielkie systemy są zwykle podzielone na
podsystemy, które oferują pewien zbiór
powiązanych z sobą interfejsów.



W początkowej fazie procesu projektowania
identyfikuje się podsystemy, ustala się zrąb
sterowania oraz komunikacji pomiędzy
podsystemami. Faza ta jest nazywana

projektowaniem architektonicznym

. Produktem

tej fazy jest opis architektury oprogramowania.



Przypomnimy jak wygląda model procesu
projektowania

Slajd nr 22

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne

Specyfikacja

wymagań

Projektowanie

architektury

Projektowanie

interfejsów

Projektowanie

komponentów

Projektowanie

struktur danych

Projektowanie

algorytmów

Specyfikowanie

abstrakcyjne

Architektura

systemu

Specyfikacja

oprogramowania

Specyfikacja

interfejsów

Specyfikacja

komponentów

Specyfikacja

struktur danych

Specyfikacja

algorytmów

Produkty projektowania

Czynności projektowe

Slajd nr 23

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Czynności procesu projektowania:



Projektowanie architektury. Identyfikuje i dokumentuje
podsystemy tworzące system oraz związki między nimi.



Specyfikowanie abstrakcyjne. Opracowuje się
abstrakcyjną specyfikację usług i ograniczeń każdego
podsystemu.



Projektowanie interfejsów. Projektuje się i dokumentuje
interfejsy każdego podsystemu z innymi podsystemami.
Specyfikacja musi być jednoznaczna ponieważ
umożliwia korzystanie z podsystemów bez znajomości
ich działania.



Projektowanie komponentów. Przypisuje się usługi do
różnych komponentów i projektuje interfejsy tych
komponentów.

Slajd nr 24

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Czynności procesu projektowania:



Projektowanie struktur danych. Szczegółowo
specyfikuje się i projektuje struktury danych użyte w
implementacji systemu.



Projektowanie algorytmów. Szczegółowo specyfikuje
się i projektuje algorytmy służące do realizacji
usług.

Slajd nr 25

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Model architektoniczny jest punktem
początkowym do specyfikowania rozmaitych
części systemu.



Proces projektowania architektonicznego
polega na ustaleniu podstawowego zrębu
systemu.



Obejmuje identyfikację najważniejszych
komponentów systemu i komunikację między
nimi.

Slajd nr 26

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Zalety jawnego projektowania i
dokumentowania architektury oprogramowania:



Komunikacja z uczestnikami

. Architektura jest

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



Analiza systemu

. Ujawnienie architektury systemu we

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

Slajd nr 27

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Zalety jawnego projektowania i
dokumentowania architektury
oprogramowania c.d.:



Użycie wielokrotne w wielkiej skali

. Architektura

systemu jest zwartym i łatwym do opanowania
opisem organizacji systemu i współpracy jego
komponentów. Architekturę można przekazać innym
systemom, które mają podobne wymagania. Pomaga
to w użyciu wielokrotnym oprogramowania.

Slajd nr 28

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Wspólne czynności dla wszystkich procesów
projektowania architektonicznego:



Strukturalizacja systemu

. System jest dzielony na

kilka podstawowych podsystemów. Podsystem jest
niezależną jednostką oprogramowania. Identyfikuje
się komunikację między podsystemami.



Modelowanie sterowania

. Określa się ogólny model

związków sterowania między częściami systemu.



Podział na moduły

. Każdy zidentyfikowany

podsystem jest dzielony na moduły. Architekt musi
wskazać typy modułów i ich połączenia.

Slajd nr 29

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Rozróżnienie między podsystemami i
modułami:



Podsystem

jest systemem na swoich własnych

prawach; jego usługi nie zależą od usług
oferowanych przez inne podsystemy. Podsystemy
składają się z modułów i mają interfejsy używane do
komunikacji z innymi podsystemami.



Moduł

jest zwykle komponentem systemu, który

oferuje co najmniej jedną usługę innym modułom.
Nie traktujemy go jako oddzielnego podsystemu.
Moduły są zbudowane z kilku innych, prostszych
komponentów systemu.

Slajd nr 30

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Wynikiem procesu projektowania
architektonicznego jest dokumentacja
projektu architektonicznego , składająca się z
graficznych przedstawień modelu systemu
oraz tekstu opisowego.



Dokumentacja ta powinna zawierać opis
systemu jako struktury złożonej z
podsystemów i każdego podsystemu jako
struktury złożonej z modułów.



Modele graficzne mogą przedstawiać różne
perspektywy systemu.

Slajd nr 31

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Zakres modelu architektonicznego:



Statyczny model strukturalny

obejmuje komponenty

lub podsystemy, które można zbudować jako
niezależne jednostki.



Model dynamiczny procesu

, w którym przedstawia

się podział systemu na procesy wg. czasu
wykonania. Najczęściej różni się od modelu
statycznego.



Model interfejsów

, w którym definiuje się usługi

oferowane przez każdy podsystem za
pośrednictwem jego interfejsu publicznego.



Model związków

, który obejmuje związki takie jak

przepływ danych między podsystemami.

Slajd nr 32

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Architektura systemu ma wpływ na efektywność,
niezawodność, łatwość pielęgnacji, ... . Wybrany dla
danego zastosowania styl i struktura mogą więc
zależeć od wymagań niefunkcjonalnych systemu:



Efektywność

. Jeśli efektywność jest krytycznym

wymaganiem to prawdopodobnie należy tak zaprojektować
architekturę, aby umieścić krytyczne operacje w niewielkiej
liczbie podsystemów komunikujących się między sobą w
niewielkim stopniu. Oznacza to użycie komponentów

gruboziarnistych

co umożliwia zmniejszenie komunikacji

między nimi.



Zabezpieczenie

. Jeśli zabezpieczenie jest krytycznym

wymaganiem to należy zastosować architekturę warstwową
i najbardziej krytyczne zasoby zabezpieczyć w najniższych
warstwach.

Slajd nr 33

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie architektoniczne



Architektura systemu c.d.:



Bezpieczeństwo

. Jeśli bezpieczeństwo jest krytycznym

wymaganiem, to należy tak zaprojektować architekturę

aby operacje dotyczące bezpieczeństwa znalazły się w

jednym podsystemie lub w niewielkiej ich liczbie.

Zmniejszy to koszty i kłopoty związane z zatwierdzeniem

bezpieczeństwa.



Dostępność

. Jeśli dostępność jest krytycznym

wymaganiem, to w architekturze należy uwzględnić

komponenty nadmiarowe, tak aby można było podmieniać

i modyfikować komponenty bez zatrzymania systemu.



Zdolność do pielęgnacji

. Jeśli zdolność do pielęgnacji jest

krytycznym wymaganiem to architektura powinna się

składać z

drobnoziarnistych

samodzielnych komponentów,

które można łatwo zmieniać.



Niestety między architekturami często występują

konflikty.

Slajd nr 35

©Ian Sommerville 2000 - Inżynieria oprogramowania

System sterowania robotem pakującym
przedmioty

Vision

system

Object

identification

system

Arm

controller

Gripper

controller

Packaging

selection

system

Packing

system

Conveyor

controller

System

wizyjny

System

identyfikacji

przedmiotów

Sterownik

ramienia

Sterownik

chwytacza

System

wyboru

opakowania

System

pakujący

Sterownik

taśmociągu

Slajd nr 36

©Ian Sommerville 2000 - Inżynieria oprogramowania

Model repozytorium



Aby efektywnie współpracować, podsystemy
wchodzące w skład systemu muszą wymieniać
między sobą informacje:



Wszystkie współdzielone dane znajdują się w jednej
bazie danych



Każdy podsystem prowadzi swoją bazę danych.
Dane są przekazywane innym podsystemom przez
wysyłanie komunikatów

Slajd nr 37

©Ian Sommerville 2000 - Inżynieria oprogramowania

Architektura zintegrowanego zestawu
narzędzi CASE

Project

repository

Design

translator

Program

editor

Design

editor

Code

generator

Design

analyser

Report

generator

Repozytorium

przedsięwzięcia

Translator

projektów

Edytor

programów

Edytor

projektów

Generator

kodu

Analizator

projektów

Generator

raportów

Slajd nr 38

©Ian Sommerville 2000 - Inżynieria oprogramowania

Model repozytorium



Wady i zalety współdzielonego repozytorium:



Efektywny sposób współdziałania dużych ilości danych.

Nie ma potrzeby jawnej transmisji z jednego podsystemu

do drugiego.



Twórcy podsystemów muszą uzgodnić model danych

repozytorium. Prowadzi to do kompromisów między

specyficznymi potrzebami każdego narzędzia. Integracja

może być trudna



Podsystemu produkujące dane nie muszą zajmować się

sposobem użycia tych danych przez inne podsystemy.



Ewolucja może być trudna, ponieważ duże ilości

informacji powstają zgodnie z ustalonym modelem danych



Łatwość tworzenia kopii zapasowych, sterowanie

zabezpieczeniami i dostępem przy pomocy menedżera

repozytorium

Slajd nr 39

©Ian Sommerville 2000 - Inżynieria oprogramowania

Model repozytorium



Wady i zalety współdzielonego repozytorium
c.d.:



Różne podsystemy mogą mieć odmienne
wymagania stawiane zabezpieczeniom oraz inne
strategie odtwarzania z kopii zapasowych



Model współdzielenia jest widoczny przez schemat
repozytorium. Integracja nowych narzędzi jest
bardzo łatwa o ile jest zgodna z przyjętym modelem
danych



Proces rozproszenia repozytorium po kilku
narzędziach może być trudny

Slajd nr 40

©Ian Sommerville 2000 - Inżynieria oprogramowania

Model klient-serwer



Architektoniczny model klient-serwer jest
modelem rozproszonym systemu w którym dane
i przetwarzanie jest rozproszone między zbiór
procesorów. Główne komponenty systemu:



Zbiór samodzielnych procesorów oferujących usługi
innym podsystemom. Przykładami są systemy
realizujące usługi drukowania, serwery plików,
serwery kompilujące.



Zbiór klientów, którzy korzystają z usług oferowanych
przez serwery. Zwykle same w sobie są podsystemami.
Może być kilka współbieżnie działających programów
klient.



Sieć dająca klientowi dostęp do serwerów

Slajd nr 41

©Ian Sommerville 2000 - Inżynieria oprogramowania

Biblioteka filmów i zdjęć

Catalogue

server

Catalogue

Video

server

Film clip

files

Picture

server

Digitized

photographs

Hypertext

server

Hypertext

web

Client 1

Client 2

Client 3

Client 4

Wide-bandwidth network

Sieć ethernet

Klient 1

Klient 2

Klient 3

Klient 4

Katalo

Serwer

katalogu

Katalo

Serwer

filmów

Katalo

Serwer zdjęć

Katalo

Serwer hiper-

txt

Slajd nr 42

©Ian Sommerville 2000 - Inżynieria oprogramowania

Model maszyny abstrakcyjnej



Model maszyny abstrakcyjnej (zwany czasami modelem
warstwowym) opisuje sprzęganie podsystemów.



Układa system w ciąg warstw, z których każda oferuje
pewne usługi.



Każda warstwa , jest maszyną abstrakcyjną, której język
maszynowy ( usługi oferowane przez tę warstwę ) służy
do implementacji następnego poziomu maszyny
abstrakcyjnej.



Implementowanie języka często polega na kompilowaniu
opisu na tzw. ‘język maszyny idealnej’ a następnie na
kod maszynowy.



Podejście warstwowe ułatwia podejście przyrostowe



Wadą jest wolny dostęp do warstw wewnętrznych i
zmniejszenie przez to wydajności.

Slajd nr 44

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele sterowania



Modele do strukturalizacji

opisują podział

systemu na moduły .



Aby podsystemy pracowały jako jeden system
system, należy nimi

sterować

, tak aby ich

usługi były dostarczane we właściwe miejsce i
we właściwym czasie.



Modele strukturalne

nie obejmują informacji o

sterowaniu.



Modele sterowania

na poziomie

architektonicznym opisują przepływy
sterowania między podsystemami.

Slajd nr 45

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele sterowania



Możemy wyróżnić dwa ogólne podejścia do
sterowania:



Sterowanie scentralizowane

. Jeden podsystem jest całościowo

odpowiedzialny za sterowanie; to on uruchamia i zatrzymuje
inne podsystemy. Może przekazać sterowanie innemu
podsystemowi, ale będzie oczekiwał zwrotu
odpowiedzialności za sterowanie.



Sterowanie zdarzeniowe

. Informacja o sterowaniu nie jest

wbudowana w podsystem, ale każdy system może może
reagować na zdarzenia zachodzące na zewnątrz. Te zdarzenia
mogą występować w innych podsystemach lub w otoczeniu
systemu.



Wszystkie powyższe modele struktury mogą być
zorganizowane za pomocą sterowania
scentralizowanego jak i zdarzeniowego.

Slajd nr 46

©Ian Sommerville 2000 - Inżynieria oprogramowania

Sterowanie scentralizowane



W modelu scentralizowanym jeden z podsystemów
jest wybrany do roli sterownika systemu i
odpowiada za działanie innych podsystemów.
Modele te dzielimy na dwie klasy w zależności od
tego czy systemy są sekwencyjne czy współbieżne.



Model call-return.

Jest to dobrze znany model

podprogramów, w którym sterowanie zaczyna się na
wierzchołku hierarchii podprogramów i przez wywołania
podprogramów przechodzi do niższych poziomów
drzewa. Model ten można zastosować jedynie do
systemów sekwencyjnych.
Model przedstawiony na następnym slajdzie

nie jest

modelem strukturalnym

. Podprogram 1.1 nie musi być

częścią składową programu 1.

Slajd nr 47

©Ian Sommerville 2000 - Inżynieria oprogramowania

Model call-return

Routine 1.2

Routine 1.1

Routine 3.2

Routine 3.1

Routine 2

Routine 3

Routine 1

Main

program

Slajd nr 48

©Ian Sommerville 2000 - Inżynieria oprogramowania

Model menedżera



Model scentralizowany c.d.:



Model menedżera

. Stosowany jedynie do systemów

współbieżnych. Jeden z komponentów systemu jest
wybierany do roli menedżera systemu i steruje
rozpoczynaniem, zatrzymywaniem i koordynacją
innych procesów. Proces jest podsystemem lub
modułem, który może działać równolegle z innymi
procesami.
Model często używany do systemów real time (czasu
rzeczywistego).

Slajd nr 49

©Ian Sommerville 2000 - Inżynieria oprogramowania

Model sterowania dla systemów Real-
time

System

controller

User

interface

Fault

handler

Computation

processes

Actuator

processes

Sensor

processes

Slajd nr 50

©Ian Sommerville 2000 - Inżynieria oprogramowania

Systemy sterowane zdarzeniami



Istnieje wiele rodzajów oprogramowań
sterowanych zdarzeniami.



Zdarzenia w tych modelach najczęściej
przychodzą z zewnątrz.



Zdarzenie nie oznacza po prostu binarnego
sygnału. Może to być sygnał przyjmujący
pewien zakres wartości.



Różnica między zdarzeniem i zwykłymi
danymi wejściowymi polega na tym, że proces
obsługujący zdarzenie nie decyduje o czasie
jego zajścia.

Slajd nr 51

©Ian Sommerville 2000 - Inżynieria oprogramowania

Systemy sterowane zdarzeniami



Omówimy dwa modele sterowania
zdarzeniowego:



Modele rozgłaszania

. W takich modelach zdarzenie

jest w zasadzie ogłoszeniem dla wszystkich
podsystemów. Każdy podsystem, który może
obsłużyć to zdarzenie reaguje na nie.



Modele z przerwaniami

. Są używane najczęściej w

systemach czasu rzeczywistego, gdzie zewnętrzne
przerwania są wykrywane przez obsługę przerwań.
Następnie są przekazywane do innego komponentu,
który je przetworzy

Slajd nr 52

©Ian Sommerville 2000 - Inżynieria oprogramowania

Model sterowania z rozgłaszaniem

Sub-system

Event and message handler

Sub-system

Procedura obsługi zdarzeń i komunikatów

Podsystem 1

Podsystem 2

Podsystem 3

Podsystem 4

Slajd nr 53

Model sterowania z przerwaniami

Handler

Process

Interrupts

Interrupt

vector

Slajd nr 54

Rozkład na moduły



Po zaprojektowaniu architektury strukturalnej
następnym procesem projektowania architektonicznego
jest podział podsystemów na moduły.



Na tym poziomie można zastosować modele omówione
na początku dzisiejszego wykładu. Ponieważ
komponenty modułów są mniejsze niż podsystemy
możemy zastosować inne modele dla podzielonego
systemu:



Model obiektowy

. System jest dzielony na zbiór

porozumiewających się obiektów.



Model przepływu danych

. System jest dzielony na moduły

funkcjonalne, które pobierają dane wejściowe i przetwarzają je
na dane wyjściowe. Model ten bywa nazywany modelem
potokowy.

Slajd nr 55

Modele obiektowe



Model obiektowy architektury systemu dzieli
się na zbiór luźno uzależnionych od siebie
obiektów z dobrze zdefiniowanymi interfejsami.



Obiekty korzystają z usług oferowanych przez
inne obiekty.



Na następnym slajdzie pokazano przykład
architektonicznego modelu obiektowego dla
systemu fakturowania. System wystawia
klientom faktury, przyjmuje zapłaty, drukuje
pokwitowania płatności i upomnienia o
niezapłaconych fakturach.

Slajd nr 56

Model obiektowy w systemie
fakturowania

issue ()

sendReminder ()

acceptPayment ()

sendReceipt ()

invoice#

date

amount

customer

Invoice

invoice#

date

amount

customer#

Receipt

invoice#

date

amount

customer#

Payment

customer#

name

address

credit period

Customer

Slajd nr 57

Model przepływu danych



W modelu przepływu danych przekształcenia

funkcyjne przetwarzają dane wejściowe na dane

wyjściowe.



Dane przepływają od do drugiego procesu i są

przekształcane w miarę swej wędrówki przez cały

ciąg.



Każdy krok przetwarzania jest implementowany jako

przekształcenie.



Dane wejściowe przepływają przez te przekształcenia

do chwili wytworzenia z nich danych wyjściowych.



Przekształcenia mogą działać sekwencyjnie lub

równolegle.



Przekształcenie może przetwarzać dane jedna po

drugiej lub w postaci wsadu.

Slajd nr 58

Model przepływu danych

USED AT:AUTHOR: PIOTR GRENIEWSKI

DATE:

REV:

PROJECT: rent-DFD

2003-10-30

2003-11-08

NOTES: 1 2 3 4 5 6 7 8 9 10

WORKING

DRAFT

RECOMMENDED

PUBLICATION

READER

DATE CONTEX T:

A-0

NODE:

TITLE:

NUMBER:

Rent a Car

Zlecenia

Info o
p³atnoœciach

Info o
wydaniu

Nazwa klienta,
adres klienta

Faktury, p³atnoœci,
ponaglenia

Samochód

Nazwa klienta,
adres klienta

Tworzenie zleceń

Zlecenia

Samochód

Przetwarzanie

zleceñ

Przetwarzanie

p³atnoœci

Wydawanie

samochodów

1 Faktury

Zlecenia

wypo¿yczenia

3 Klienci

Klienci

Ustalenia

Klienci

Slajd nr 59

Model przepływu danych system
fakturowania

Read issued

invoices

Identify

payments

Issue

receipts

Find

payments

due

Receipts

Issue

payment

reminder

Reminders

Invoices

Payments

Slajd nr 60

Model przepływu danych system
fakturowania



Zalety modelu przepływu danych:



Umożliwia użycie wielokrotne przekształceń



Jest intuicyjna dla wielu ludzi, którzy myślą o swojej
pracy w kategorii przetwarzania wejścia i wyjścia.



Ewolucja systemu polegająca na dodawaniu nowych
przekształceń jest bardzo łatwa.



Ta architektura jest łatwa do zaimplementowania
zarówno jako system sekwencyjny jak i współbieżny.

Slajd nr 61

Architektury charakterystyczne dla
różnych dziedzin



Istnieją dwa rodzaje modeli
architektonicznych charakterystyczna dla
dziedziny:



Modele ogólne

, które są abstrakcjami systemów

takich jak: modele architektoniczne, systemy
gromadzenia danych, systemy monitorowania, itd.



Modele odniesienia

, które są jeszcze bardziej

abstrakcyjne i opisują większe klasy systemów.

Slajd nr 62

Modele ogólne



Najbardziej znanym przykładem architektonicznego modelu
ogólnego jest model kompilatora. Moduły kompilatora:



Analizator leksykalny

, który pobiera symbole języka wejściowego

i przekształca je w postać wewnętrzną.



Tabela symboli

budowana przez analizator leksykalny

przechowuje informację o nazwach i typach użytych w
programie.



Analizator składniowy

, który sprawdza składnie kompilowanego

języka. Korzysta z definicji gramatyki i buduje drzewo składni.



Drzewo składni

, które wewnętrzną strukturą danych

reprezentującą kompilowany program.



Analizator znaczeniowy

, który korzystając z informacji drzewa

składni i tabeli symboli sprawdza znaczeniową poprawność
programu wejściowego



Generator kodu

, który przechodzi drzewo składni i generuje kod

maszynowy.

Slajd nr 63

Model przepływu danych kompilatora

Lexical

analysis

Syntactic

analysis

Semantic

analysis

Code

generation

Symbol

table

Analiza

leksykalna

Generowanie

kodu

Analiza

składniowa

Analiza

znaczeniowa

Tabela

symboli

Slajd nr 64

Model repozytorium systemu
przetwarzania języka

Syntax

analyser

Lexical

analyser

Semantic

analyser

Abstract

syntax tree

Grammar

definition

Symbol

table

Output

definition

Pretty-

printer

Editor

Optimizer

Code

generator

Repository

Generator

prezentacji

Edytor

Optymalizator

Analizator

znaczeniowy

Analizator

składniowy

Analizator

leksykalny

Generator

kodu

Drzewo

składni

abstrakcyjnej

Definicja

wyniku

Definicja

gramatyki

Tabela

symboli

Slajd nr 65

Modele odniesienia



Ogólne modele architektoniczne

odzwierciedlają

architekturę istniejących systemów.



Modele odniesienia

są natomiast wynikami badań dziedziny

zastosowania. Reprezentują wyidealizowane architektury
obejmujące wszystkie udogodnienia jakie system
potencjalnie może oferować.



Architektury odniesienia mogą służyć jako podstawa
implementacji systemu. Taki był motyw powstania modelu
referencyjnego OSI (Zimmerman, 1980) do komunikacji
systemów otwartych. Ten model był z założenia standardem.



System zgodny z tym modelem powinien móc się
skontaktować z innymi zgodnymi systemami.



Model OSI jest siedmiowarstwowym modelem komunikacji
systemów otwartych.

Slajd nr 66

Architektura modelu OSI

Application

Presentation

Session

Transport

Network

Data link

Physical

Communications medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

Aplikacja

Document Outline