1 Projektowanie obiektowe Wzorce projektowe Wprowadzenie do aplikacji biznesowych.

Prezentacja na temat: "1 Projektowanie obiektowe Wzorce projektowe Wprowadzenie do aplikacji biznesowych."— Zapis prezentacji:

1 1 Projektowanie obiektowe Wzorce projektowe Wprowadzenie do aplikacji biznesowych

2 2 Roadmap Aplikacje biznesowe Rodzaje aplikacji korporacyjnych Wydajność

3 3 Oprogramowanie to nie znaczy zawsze to samo… Rodzajów oprogramowania jest wiele Każde z nich ma swoje wyzwania i metody projektowania oraz implementacji Lista płac, dane pacjentów śledzenie dostaw, analiza kosztów obsługa kredytów, ubezpieczenia, zarządzanie łańcuchem dostaw, księgowość, obsługa klienta, obrót walutami System wtrysku paliwa, edytor tekstu, sterownik windy, automatyka fabryki opakowań plastikowych, centrala telefoniczna, system operacyjny, kompilator, gra

4 4 Aplikacje biznesowe… Lista płac, dane pacjentów śledzenie dostaw, analiza kosztów obsługa kredytów, ubezpieczenia, zarządzanie łańcuchem dostaw, księgowość, obsługa klienta, obrót walutami Enterprise applications czyli po naszemu: Aplikacje biznesowe Aplikacje dla przedsiębiorstw Aplikacje korporacyjne Systemy informacyjne Systemy informatyczne

5 5 Cechy aplikacji biznesowych Trwałe (ang. persistent) dane Operowanie na (często) złożonych danych, które: Muszą być dostępne pomiędzy kolejnymi uruchomieniami programu Muszą być utrzymywane przez wiele lat Zmienia się sprzęt, systemy operacyjne, kompilatory, … … a dane pozostają

6 6 Cechy aplikacji biznesowych Duża ilość danych Giga- (tera- ?) bajty informacji uporządkowanych w dziesiątki milionów rekordów. Współbieżny dostęp do danych Przedsiębiorstwo – kilkaset Internet – tysiące ++ Duża liczba ekranów UI Setki Różni użytkownicy bez dużej wiedzy technicznej Przetwarzanie wsadowe

7 7 Cechy aplikacji biznesowych Integracja z innymi aplikacjami W ramach przedsiębiorstwa Z systemami partnerów Różnice w procedurach biznesowych i dysonans pojęciowy Klient – osoba z którą podpisana jest ważna umowa Klient – osoba z którą podpisano umowę Klient – odbiorca produktów z pominięciem usług Klient - …

8 8 Cechy aplikacji biznesowych Złożona (nie)logika biznesowa Reguły biznesowe są narzucone z góry Setki (tysiące?) przypadków szczególnych typu: pewien handlowiec wynegocjował wnoszenie określonej rocznej płatności dwa dni później niż pozostałe, aby dopasować się do cyklu księgowego klienta, dzięki czemu firma zyskała kilka milionów dolarów Pewną rzeczą jest jedynie to, że logika będzie z czasem ulegać zmianom

9 9 Cechy aplikacji biznesowych Nie każda aplikacja dla przedsiębiorstwa jest dużym systemem Wiele małych projektów do których nie przywiązujemy większej uwagi (?) Duży projekt można przekształcić w mały – upraszczając architekturę i procedury

10 10 Rodzaje aplikacji biznesowych Aplikacje biznesowe różnią się między sobą Analiza wielu alternatywnych rozwiązań Przykłady typowych scenariuszy: Sprzedaż detaliczna online Automatyzacja przetwarzania umów leasingowych System śledzenia wydatków w małej firmie

11 11 Sprzedaż detaliczna online Obsługa bardzo dużej liczny użytkowników Efektywne wykorzystanie zasobów, skalowalność Typowy interfejs użytkownika Stosunkowo prosta logika dziedziny aplikacji Przyjmowanie zamówień System obsługi cen towarów i opłat za dostawy Powiadomienia o dostarczaniu Źródła danych: Baza zamówień System magazynowy (dostępność towarów)

12 12 Automatyzacja przetwarzania umów leasingowych Umiarkowana liczba użytkowników Skomplikowana logika dziedziny aplikacji Obliczanie wysokości rat leasingowych Obsługa przedwczesnych zwrotów, opóźnionych płatności Weryfikowanie danych przy wykupie Swobodne określanie reguł biznesowych Skomplikowany interfejs użytkownika Złożona interakcja z użytkownikiem Zaawansowane techniki prezentacji Obsługa transakcji Złożony schemat danych

13 13 System śledzenia wydatków Niewielka liczba użytkowników Prosta logika Kilka tabel w bazie danych jako źródło danych Krótki termin oddania projektu

14 14 Wydajność Trudny problem 1. Najpierw tworzymy działający system a potem optymalizujemy (w oparciu o pomiary wydajności) 2. Architektura może mieć duży wpływ na wydajność Mozę utrudniać późniejsze zmiany Zmiany w architekturze zawsze budzą obawy Nie ma recepty… Własne pomiary Dostosowanie do konkretnego środowiska

15 15 Terminologia wydajności Response time - czas odpowiedzi: Ilość czasu potrzebna na przetworzenie żądania Responsiveness – czas reakcji: Szybkość, z jaką system potwierdza odebranie żądania, niezależnie od przetwarzania Latency – latencja: Minimalna ilość czasu wymagana do otrzymania jakiejkolwiek odpowiedzi (systemy zdalne)

16 16 Terminologia wydajności Throughput – przepustowość: Ilość operacji, które można wykonać w jednostce czasu (bps, tps) Performance – wydajność: Przepustowość lub czas odpowiedzi w zależności od tego co jest dla systemu istotniejsze Load – obciążenie wytrzymałość systemu – liczba jednocześnie podłączonych użytkowników (kontekst dla innych wartości np. czasu odpowiedzi) np. Load 10 – Response Time 0,5 sek. Load 20 – Response Time 2 sek.

17 17 Terminologia wydajności Load sensivity – wrażliwość na obciążenie Jak zmienia się czas odpowiedzi, gdy rośnie obciążenie System A: Load 10 - 20 – Response Time 0,5 sek. System B: Load 10 – Response Time 0,2 sek. System B: Load 20 – Response Time 2 sek. System B ulega większej degradacji niż system A

18 18 Terminologia wydajności Efficiency – efektywność: Wydajność / liczba zasobów Efficiency A = 30 tps / 2 procesory Efficiency B = 40 tps / 4 procesory Efficiency A > Efficiency B Capacity – pojemność Największa dopuszczalna przepustowość lub obciążenie (wartość nieprzekraczalna lub taka przy której wydajność nie spełnia wymagań użytkowników)

19 19 Terminologia wydajności Scalability – skalowalność: Jak na wydajność wpływa dodawanie nowych zasobów (zazwyczaj) sprzętowych. Vertical Scalability – skalowalność pionowa Zwiększanie mocy pojedynczego serwera Horizontal Scalability (scaling out) – skalowalność pozioma (skalowanie wszerz) Dodawanie nowych serwerów do obsługi systemu

20 20 Ocena wydajności Na serwerze pracują dwa systemy System A – capacity 20 tps. System B – capacity 40 tps. Który z nich jest bardziej wydajny? Z całą pewnością może my powiedzieć tylko to, że System B jest bardziej efektywny (efficient) na pojedynczym serwerze. Który zapewnie wyższą wydajność? Który jest bardziej skalowalny?

21 21 Ocena wydajności Na serwerze pracują dwa systemy System A – capacity 20 tps. System B – capacity 40 tps. Dodajemy nowy serwer: System A – capacity 35 tps. System B – capacity 50 tps. System B ma dalej większą pojemność (capacity). A co ze skalowalnością?

22 22 Ocena wydajności Na serwerze pracują dwa systemy System A – capacity 20 tps. System B – capacity 40 tps. Dodajemy kolejne serwery: System A – zyskuje 15 tps. / serwer System B – zyskuje 10 tps. / serwer Wynik analizy: System A charakteryzuje się większą skalowalnością poziomą (horizontal scalability) System B jest bardziej efektywny przy liczbie serwerów < 5

23 23 Ocena wydajności I co z tego wynika? Wszystko zależy od konkretnej sytuacji Ogólnie: Skalowalność pozwala uzyskać większą wydajność gdy jest ona rzeczywiście potrzebna. Nowszy sprzęt jest często tańszy niż budowa nowego oprogramowania Jeżeli System B jest droższy niż System A a różnica odpowiada cenie kilku serwerów to system A będzie tańszy nawet wtedy gdy nie potrzebujemy więcej niż 40 tps.