Projektowanie aplikacji w Accessie
Baza MS Access jest zbiorem obiektów: tabel, kwerend, formularzy, raportów, stron, makr i modułów.
Aplikacja - wszystkie obiekty są połączone w jedną spójną całość umożliwiającą użytkownikowi skupienie się na realizacji zamierzonych funkcji bizensowych a nie na operowaniu obiektami przy pomocy standardowego interfejsu.
Obiekty aplikacji:
Etapy prac projektowych nad systemem informacyjnym (aplikacją bazodanową) - metodyka strukturalna:
1. Strategia (analiza wstępna)
2. Analiza szczegółowa
3. Projektowanie systemu
4. Implementacja (z tworzeniem dokumentacji i testowaniem)
5. Wdrożenie
6. Eksploatacja
(1) Analiza - określa cel i zakres aplikacji.
W oparciu o rozmowy z użytkownikami, następuje sporządzenie listy zadań, jakie aplikacja ma realizować.
Analizuje się kopie używanych papierowych formularzy i raportów.
Identyfikuje się, jakie dane są przetwarzane i jakie są między nimi związki (diagram związków encji).
(2) Projektowanie, protypowanie i implementacja - jakie obiekty (tabele, kwerendy, formularze, raporty, strony, moduły) będą tworzyć projektowaną aplikację.
Projektowanie aplikacji może się odbywać albo metodą z góry w dół (top-down) albo metodą z dołu w górę (bottom-up) albo za pomocą połączenia obu tych metod.
W pierwszej kolejności należy zaplanować tabele i powiązania między nimi.
Przy użyciu narzędzia CASE (jak MS Visio), z diagramu związków encji można automatycznie otrzymać schemat bazy danych.
Następnie zgodnie z metodą z góry w dół projektujemy strukturę aplikacji w postaci drzewa (lub ogólniej grafu).
Wierzchołkami są planowane formularze, raporty, strony i procedury.
Strzałki reprezentują przejścia między nimi.
Wyróżniony wierzchołek początkowy (korzeń drzewa) stanowi formularz, który jest wyświetlany na samym początku.
Strzałkom i wierzchołkom przyporządkowuje się odpowiednie własności jak np.
wierzchołkom
- typ obiektu w wierzchołku np.
formularz, raport;
jeśli formularz to jakiego rodzaju:
panel
sterowania, informacyjny, do wprowadzania danych, do modyfikowania danych,
do wyświetlania danych, do filtrowania danych w innym lub tym samym
formularzu). Każdemu rodzajowi operacji na danych (wyszukiwanie,
wprowadzanie, modyfikowanie) powinien odpowiadać osobny formularz. Później w
uzasadnionych przypadkach - jak względy efektywności lub wygody użytkownika
można połączyć dwa (lub więcej) formularzy w jeden.
strzałkom
czy z powrotem sterowania po danej strzałce,
co robić z obiektem, od którego zaczyna się strzałka np. czy uczynić go niewidzialnym na ekranie.
Po utworzeniu drzewa (grafu) aplikacji buduje się wstępny prototyp aplikacji, na którym przedstawia się strukturę kontrolną aplikacji (jeszcze bez realizacji konkretnych funkcji) oraz zasady interfejsu użytkownika.
Prototypy pokazuje się użytkownikom do akceptacji testowanych rozwiązań projektowych. Mają one charakter próbny i powinny zostać później zastąpione przez bardziej dojrzałe, lepiej dopasowane do potrzeb i wyobrażeń użytkownika wersje.
Stosując metodę z dołu w górę kolejno projektuje się formularze i raporty, zaczynając od zapytań wybierających mających być ich źródłami wierszy oraz następnie sam formularz lub raport.
Z kolei należy utworzyć kwerendy i procedury potrzebne do odpowiedniego działania formularza.
Należy przetestować formularz (raport) sprawdzając, czy przy jego użyciu można we właściwy sposób wykonywać operacje na danych.
Formularze i raporty należy z kolei zintegrować ze sobą, projektując przejścia między nimi (wykorzystując zdarzenia, przyciski na formularzu lub na dostosowanych paskach menu).
Dokumentacja projektowa
Podstawa do zatwierdzenia kolejnego etapu tworzenia systemu jak i do wytyczenia planu kolejnego etapu.
Środek komunikacji wiedzy o projekcie między ludźmi (klientami, użytkownikami, analitykami, projektantami, programistami itd.).
Prowadzi do zmniejszenia złożoności, usystematyzowania wiedzy o aplikacji.
Łączy użytkowników i ich potrzeby z samą aplikacją i jej uwarunkowaniami.
Niezbędna przy wprowadzaniu zmian (w fazie eksploatacji systemu).
Dokumentacja projektowa (całkowicie lub częściowo) jest przechowywana w repozytorium narzędzia CASE.
Najpierw: dokument definiujący zadanie projektu - TOR - Terms Of Reference. TOR powinien zidentyfikować potrzeby posiadania systemu bazy danych wspomagającego biznes:
Nazwa projektu
Kontekst opisuje otoczenie, w którym bierze się pod uwagę możliwość powstania aplikacji bazy danych.
Potrzeby wyjaśniają dlaczego baza danych jest potrzebna, dlaczego jest bez niej źle, jak również uzasadniają, że spodziewane korzyści przewyższą przewidywane koszty.
Diagram związków encji oraz lista opisów znaczenia encji, atrybutów i związków.
Spis definicji funkcji biznesowych ze wskazaniem, które mają być realizowane w ramach aplikacji bazy danych.
Spis grup użytkowników, którzy będą korzystać z systemu - z zaznaczeniem funkcji, które będą wykorzystywać.
1. schemat projektowy bazy danych (tabele, kolumny, klucze główne i obce),
2. diagram i spis modułów systemu (formularze, raporty, powiązania między nimi).
W fazie implementacji systemu (łącznie z testowaniem) powstają:
aplikacja,
instrukcja posługiwania się aplikacją przez użytkowników oraz
dokumentacja programistyczna (dla osób, które w przyszłości będą administrować i/lub zmieniać aplikację).
Faza wdrażania systemu obejmuje jego instalację, szkolenie użytkowników i wprowadzanie danych.
Faza eksploatacji systemu połączona z wprowadzaniem do niego zmian wymaga powrotu do dokumentacji przygotowanej w poprzednich fazach i jej modyfikacji.
Cechami charakterystycznymi faz projektowania aplikacji jest przetwarzanie informacji zebranych w poprzedzającej fazie:
Ogólna specyfikacja danych przechodzi w diagram związków encji, który z kolei przechodzi w schemat bazy danych, a następnie w bazę danych.
Ogólna specyfikacja funkcji przechodzi w spis funkcji, a następnie w diagram i specyfikację modułów systemu i następnie w aplikację i jej opis w dokumentacji użytkownika i w dokumentacji programistycznej.
Inną cechą procesu tworzenia aplikacji jest używanie prototypów – próbnych aplikacji - do zbierania informacji na długo przed tym jak rozpocznie się implementacja systemu. W wyniku analizy działania tych próbnych aplikacji można uzyskać potwierdzenie prawidłowego zrozumienia wymagań użytkowników co do reprezentowanych danych, realizowanych funkcji i interfejsu ekranowego aplikacji.
Ważną cechą procesu tworzenia aplikacji jest użycie narzędzi CASE umożliwiających automatyzację pewnych procesów projektowych:
1. Skoncentrowane na komputerowym wspomaganiu etapów analizy i projektowania oraz bezpośrednim użyciu ich rezultatów w fazie implementacji.
2. Centralne pojęcie to repozytorium projektowe – baza danych zawierająca wszystkie obiekty (w tym dokumenty) używane wspólnie przez cały zespół projektowy przez cały okres działalności projektowej:
diagramy np. diagramy związków encji;
elementy diagramów np. encja, funkcja, proces, moduł, tabela;
projektowe reprezentacje obiektów bazy danych poziomu fizycznego np. indeksy, przestrzenie tabel, segmenty wycofań;
dokumenty projektowe jak terminologia biznesu, cele, krytyczne czynniki powodzenia.
3. Repozytorium projektowe jest dzielone na części – systemy aplikacyjne, foldery.
Obiekty projektowe mogą być:
tranformowane między kolejnymi poziomami projektowymi np. można dokonać transformacji encji na tabelę a także tabeli na encję;
wersjowane – kolejnym wersjom obiektu repozytorium przypisuje się numer wersji;
poddawane generowaniu (forward engineered) do obiektów aplikacji jak tabele w bazie danych, formularze aplikacji;
wprowadzane wstecz (backward engineered) – tworzone na podstawie istniejących obiektów jak tabele w bazie danych, formularze aplikacji;
współdzielone między różnymi projektami w tym także na zasadzie wypożyczania i zwracania z/do repozytorium projektowego.
5. Narzędzie CASE jest w stanie automatycznie produkować raporty projektowe (w tym produkty kończące etapy projektowania) na podstawie zawartości repozytorium projektowego. Np. w MS Visio z menu "Database -> Report":
Przykład dokumentacji projektowej Oferty pracy
I. TOR
Nazwa projektu: Oferty pracy
Kontekst: W prasie i internecie pojawia się wiele ogłoszeń firm poszukujących pracowników na stanowiska informatyczne. W PJWSTK jest wielu studentów, którzy szukają pracy. Władze szkoły chciałyby dysponować danymi o aktualnych ofertach pracy. Są gotowe wyznaczyć osobę do wprowadzania ofert pracy do bazy danych.
Potrzeby: Dobrze by było, aby studenci mogli wyszukiwać interesujące ich oferty pracy - w oparciu o rodzaj działalności firmy bądź w oparciu o wymagania. Dla władz szkoły istotna jest znajomość trendów na rynku pracy. Może to znaleźć odzwierciedlenie w przygotowywanym programie studiów jak i programach poszczególnych zajęć.
II. Diagram związków encji Oferty pracy
III. Spis funkcji systemu informatycznego Oferty pracy
IV. Podstawowe moduły
Główny panel sterowania (f) (moduł rozpoczynający i kończący wykonywanie aplikacji)
Wprowadź/wyświetl firmy (f)
Wprowadź oferty (f)
Administracja słownikiem wymagań (f)
Backup na dyskietkę (m)
Wyświetl oferowane stanowiska (f)
Wyszukuj według wymagań (f)
Ranking wymagań (r)
Zestaw stanowisk według wymagań (r)
Typy modułów:
f – formularz
r – raport
m - makro
V. Spis modułów projektowanego systemu Oferty pracy (przykłady)
1. Główny panel aplikacji (f)
Funkcje: Kierowanie użytkownika do modułów realizujących odpowiednie funkcje. Zakończenie aplikacji.
2. Wprowadź_wyświetl firmy (f)
Funkcje: Wprowadzanie, wyświetlanie i aktualizacja danych o firmach.
Postać: Pojedynczy formularz.
Źródło danych: Tabela Firmy.
Powiązania: Dostępny z modułów Główny panel aplikacji i Wprowadź_aktualizuj oferty.
3.Administracja słownikiem wymagań (f)
Funkcje: Przeglądanie i wprowadzanie nowych kategorii oraz pozycji słownika wymagań (w podziale na kategorie). Aktualizacja i usuwanie pozycji słownika wymagań.
Postać: Formularz z podformularzem.
Źródło danych: Tabela Kategorie wymagań dla formularza głównego oraz tabela Słownik wymagań dla podformularza.
Powiązania: Dostępny z modułów Główny panel aplikacji i Wprowadź_aktualizuj oferty. Powrót po śladzie.
4. Wprowadź_aktualizuj oferty (f)
Funkcje: Wprowadzanie ofert pracy: informacji o ogłoszeniu, stanowiskach w ogłoszeniu, obowiązkach i wymaganiach związanych z danym stanowiskiem.
Postać: Formularz z podformularzem i z formularzem wyskakującym (połączonym z podformularzem).
Źródło danych: Tabela Oferty dla formularza głównego, tabela Stanowiska w ofercie dla podformularza, tabela Wymagania dla formularza wyskakującego. Oprócz tego przez odnośnik jest połączenie z tabelą Firmy (z formularza głównego) oraz przez listę rozwijaną oraz odnośnik z tabelami Słownik Wymagań oraz Kategorie wymagań (z formularza wyskakującego).
Powiązania: Dostępny z modułów: Główny panel aplikacji, Wprowadź_wyświetl firmy, Wyświetl ogłoszenia (powót do Główny panel aplikacji).
5. Wyświetl oferowane stanowiska (f)
Funkcje: Przeglądanie pełnych ogłoszeń, które ukazały się po podanej dacie.
Postać: Formularz z podformularzem i z formularzem wyskakującym (uruchamianym z podformularza).
Źródło danych: Kwerenda Firmy i oferty (złączenie tabel Firmy i Oferty) dla formularza głównego, tabela Stanowiska w ofercie dla podformularza oraz kwerenda Kategorie i wymagania (złączenie tabel Wymagania, Słownik wymagań i Kategorie wymagań).
Powiązania: Dostępny z modułu Główny panel aplikacji.
6. Wyszukaj według wymagań (f)
Funkcje: Wyszukiwanie oferowanych stanowisk pracy według wybranego wymagania i takich, których ogłoszenia ukazały się po wybranej dacie.
Postać: Formularz z podformularzem.
Źródło danych: Kwerenda Wszystko (złączenie tabel Firmy, Oferty, Stanowiska w ofercie, Wymagania, Słownik wymagań i Kategorie wymagań) dla głównego formularza (tu wyszukuje się oferty względem nazwy wymagania) oraz kwerenda Wymagania i słownik wymagań (złączenie tabel Wymagania i słownik wymagań).
Powiązania: Dostępny z modułu Główny panel aplikacji.
7. Zestaw stanowisk względem wymagań (r)
Funkcje: Zestawienie firm i stanowisk względem kategorii i nazwy wymagania - z przeznaczeniem do wydrukowania lub wyświetlenia na ekranie.
Źródło danych: Kwerenda Wszystko.
8. Ranking wymagań (r)
Funkcje: Ile razy dane wymaganie występuje w ofercie na stanowisko.
Źródło danych: Kwerenda „Ranking wymagań”.
9. Backup danych (m)
Funkcje: Skopiowanie danych do pliku .mdb o ścieżce podanej przez użytkownika.
Ad.1 Formularz realizujący moduł „Główny panel aplikacji”.
Ad.4 Formularz realizujący moduł „Wprowadź oferty”.
Ad.6. Formularz realizujący moduł „Wyszukaj według wymagań”
Organizacja prac projektowych - Microsoft Solutions Framework (MSF)
Zbiór wskazówek postępowania pogrupowanych wokół podstawowych aspektów prowadzenia prac projektowych:
Model zarządzania ryzykiem (Risk Management Model)
Model procesów (Process Model)
Model zespołu projektowego (Team Model)
Model architektury przedsiębiorstwa (Enterprise Architecture Model)
Model procesu projektowania (Design Process Model)
Model aplikacji (Application Model)
Model zarządzania ryzykiem
Ryzyko - problem, zagrożenie, które może się urzeczywistnić.
Aktywne zarządzanie ryzykiem (proactive risk management) – identyfikowanie potencjalnych przyczyn niepowodzenia projektu i podejmowania działań w celu zapobieżenia lub minimalizowania wpływu ryzyka na projekt.
Model procesów
Model określający kolejność działań w projekcie od początku do zakończenia projektu.
Podstawowe modele procesów projektowych:
Model kaskadowy (watefall model) – każdy zestaw zadań musi zostać zakończony przed rozpoczęciem kolejnej fazy.
Używane są punkty kontrolne nazywane kamieniami milowymi (milestones) jako punkty przejścia i oceny. Są podstawą dla cyklu życia prowadzenia projektu opartego na zadaniach (task-driven development life cycle),
zwykle różne zespoły projektowe prowadzą różne fazy,
każda
faza musi zostać dokładnie udokumentowana, aby następny zespół miał pełną
informację
krytyczne decyzje zapadają wcześnie,
testowanie
odbywa się w ostatniej fazie projektu
komunikacja pomiędzy ludźmi jest ograniczona do dokumentacji pisanej – można utracić krytyczną informację, istotny kontekst może zostać nie przekazany,
informacja o
potrzebach klienta może być utracona
na początku
koncentracja na potrzebach klienta a nie na wizji co dostępna technologia może
dać użytkownikowi.
Model spiralny (spiral model) – ciągła potrzeba poprawiania wymagań i oszacowań projektowych.
Oparty na więzi pomiędzy zespołem projektowym a klientem.
Opiera się na kolejnych
iteracjach w celu wprowadzania ulepszeń. Nie ma wyraźnie określonych kamieni milowych.
Model procesów MSF łączy ze sobą zasady oparte na kamieniach milowych i etapach projektowania z iteracją w jeden model.
Cykl życia projektu oparty na kamieniach milowych:
Wprowadza dyscyplinę realizowania zadań projektowych
z zachowaniem elastyczności i iteracyjności (do wprowadzania zmian).
Kamienie milowe to punkty kontrolne, przeglądowe, synchronizujące, nie są to punkty martwe, zamrożone.
Pozwalają zespołowi oceniać postęp w pracach i dokonywać poprawek.
Struktura planowania projektu oparta na 4 fazach. Każda faza kończy się zewnętrznie widocznym kamieniem milowym.
Wyróżniamy dwa rodzaje kamieni milowych:
Główne kamienie milowe.
Pośrednie kamienie milowe.
Główne kamienie milowe reprezentują osiągnięcia zespołu i zgodę klienta na kontynuację prac.
Produkty prac projektowych „dostawy” (deliverables) są fizycznym dowodem na to, że zespół osiągnął kolejny kamień milowy.
Faza 1 (Faza określania wizji) Zespół projektowy razem z klientem określają wymagania biznesowe i ogólne cele projektu. Kończy się kamieniem milowym akceptacji wizji co wskazuje, że zespół projektowy i klient zgadzają się na opracowany kierunek projektu.
Faza 2 (Faza planowania) Kończy się kamieniem milowym akceptacji planu.
Faza 3 (Faza tworzenia) Kończy się gdy produkt projektu (np. oprogramowanie) jest gotowy i może zostać poddany wdrożeniu (deployment).
Faza 4 (Faza stabilizacji) Projekt kończy się akceptacją produktu, wypuszczeniem go na rynek lub wdrożeniem.
Wersjonowanie zwalnianych "wypuszczanych” produktów (versioned releases)
Dzielenie dużego projektu na wiele wersjonowanych wydań, gdzie:
pierwsze wydanie dostarcza głównego produktu;
następne wersje dodają kolejne cechy aż produkt spełnia opracowaną w pierwszej fazie wizję projektu.
To co najważniejsze jest dostarczane szybciej.
Wersjonowane wydania umożliwiają zespołowi projektowemu szybsze reagowanie na zmiany zakresu, planu i ryzyka podczas tworzenia produktu.
Zarządzanie trójkątem zależności
Zmienne projektowe:
zasoby (resources) jak ludzie, pieniądze,
harmonogram (schedule) i
cechy produktu, funkcje (features).
Zachodzą między nimi wzajemne zależności (tradeoff). Gdy jedna zmienna ulega zmianie, inne muszą być uaktualnione.
Kluczem do sukcesu projektu jest wyważenie proporcji między nimi.
Projekt jest udany gdy klient uważa, że zespół
dokonał prawidłowych wyborów. Zespół powinien pytać klienta o priorytety jak
najwcześniej i jak najczęściej.
„Żywe dokumenty projektowe”
Dokumenty, które odzwierciedlają aktualny stan prac projektowowych.
Dzięki nim mamy strukturalny proces kontroli zmian (zarządzania zmianami).
Zaczynamy prace nad nimi jak najwcześniej (baseline early), zamykamy jak najpóźniej (freeze late).
Model zespołu projektowego
Zespół składa się z sześciu ról:
Kierownik produktu
Kierownik programu (administrator projektu)
Wytwórca
Tester
Edukacja użytkownika
Kierownik logistyki
Kierownik produktu, zarządzanie produktem (product management)
prowadzenie zespołu w kierunku realizacji oczekiwań klienta,
reprezentowowanie zespołu przed klientem,
określanie zakresu projektu,
opracowywanie i realizowanie planu komunikacji z klientem i użytkownikami.
Kierownik programu prac projektowych, zarządzanie pracami projektowymi (program management)
kierowanie, koordynacja ogólnym procesem projektowym,
zarządzanie harmonogramem, zasobami, ograniczeniami projektu,
odpowiedzialność za dostarczenie właściwego produktu we właściwym czasie,
odpowiedzialność za zakres produktu i specyfikację,
tworzenie raportów o stanie prac projektowych,
zarządzanie alokacją zasobów,
organizacja komunikacji wewnątrz zespołu projektowego, łagodzenie konfliktów,
kierowanie podejmowaniem krytycznych decyzji.
Wytwórca, budowa produktu (development)
budowa i testowanie produktu spełniającego wymagania i oczekiwania klienta,
uczestnictwo w projektowaniu produktu,
szacowanie czasu i pracy do wykonania produktu,
konsultacja w sprawach technologii,
pomoc przy instalacji i wdrożeniu produktu,
tworzenie, konfigurowanie i dostosowywanie produktu do klienta (customization).
Tester, Testowanie (Testing)
opracowanie strategii, planów i skryptów testowania,
kontrola procesu i stanu budowy produktu: co jest źle, co jest już dobrze,
przeprowadzanie testów,
uczestniczenie w określaniu kryteriów jakości.
Edukacja, szkolenie użytkowników (User Education)
uczenie użytkowników sprawnego posługiwania się produktem,
zarządzanie oczekiwaniami użytkowników,
przygotowanie materiałów szkoleniowych/instrukcji sprawnego posługiwania się systemem (w tym on-line help, wizards),
reprezentowanie oczekiwań użytkowników przed zespołem projektowym,
uczestniczenie w zbieraniu wymagań użytkowników.
Kierownik logistyki, logistyka (Logistics Management)
kontakt ze służbami wspomagającymi (działem operacyjnym),
zapewnienie że produkt jest wdrażalny, zarządzalny i że w firmie będzie wspomagana jego eksploatacja,
uczestnictwo przy projektowaniu, wspomaganie testów beta produktu,
wspomaganie działu operacyjnego przy konfigurowaniu środowiska i samego produktu.
Zasady zespołu projektowego MSF (team of peers)
Wspólna wizja projektu.
Pełna współpraca.
Uczenie się na doświadczeniach zdobytych w poprzednich projektach.
Wspólne zarządzanie projektem oraz podejmowanie decyzji. Bez jednego, głównego kierownika projektu.
Wspólna praca członków projektu w jednym miejscu.
Podział pracy w dużych zespołach na mniejsze.
Podsumowanie
Rola | Cel |
Kierownik produktu |
Zadowolony klient |
Kierownik programu | Dostarczenie produktu w ramach ograniczeń projektowych |
Wytwórca |
Dostarczenie produktu zgodnego ze specyfikacją |
Tester |
Sprawdzenie wszystkich potencjalnych problemów |
Edukacja użytkownika |
Sprawne użycie systemu przez użytkowników |
Kierownik logistyki |
Sprawne wdrożenie produktu |
Model architektury przedsiębiorstwa (Enterprise Architecture Model) - BAIT
Obraz działalności firmy podzielony na cztery aspekty.
Reprezentuje dynamiczne środowisko w jednej chwili czasu.
Jedna architektura, ale cztery perspektywy:
biznes - napęd działania przedsiębiorstwa,
aplikacje, informacje (środki do osiągnięcia celów i zadań biznesu) i
technologia (fundament, baza).
Biznes
Cele i zadania: na czym polega biznes w organizacji?
Organizacja: kto jest odpowiedzialny?
Procesy biznesowe: jak organizacja wykonuje swój biznes?
Klient: kim jest klient?
Dostawcy/sprzedawcy: z kim współpracuje organizacja?
Działania biznesowe w tym:
jak są dostarczane produkty i usługi,
jak biznes współdziała z klientami i dostawcami,
struktura organizacyjna firmy,
procesy biznesowe.
Aplikacje
zautomatyzowane usługi, które wspierają procesy biznesowe,
identyfikacja redundancji między departamentami.
Informacja
co organizacja musi wiedzieć (dane, informacje, wiedza) aby prowadzić procesy i operacje biznesowe,
zasady zarządzania danymi,
opisy wzorców konsumpcji i produkcji informacji w organizacji.
Technologia
wspomaganie sprzętowe, programistyczne i techniczne,
standardy, wskazówki (guidelines) potrzebne aby osiągnąć misje biznesu,
określa usługi technologiczne potrzebne do realizacji misji biznesu:
środowiska budowy systemów,
specyfikacje techniczne,
warstwy sprzętowe,
systemy operacyjne,
platformy sieciowe,
biblioteki kodu,
dokumenty ze standardami,
wskazówki projektowe.
Model procesu projektowania (Design Process Model)
Trzy perspektywy (ustawione w sekwencję wielokrotnie iterowaną):
koncepcyjne projektowanie
perspektywa użytkownika: co robi i co potrzebuje aby to robić,
identyfikacja potrzeb biznesowych,
modele które są łatwo zrozumiałe zarówno dla klienta jak i projektanta (jak zgrubne szkice i scenariusze tworzone przy projektowaniu domu);
logiczne projektowanie
perspektywa użytkownika zastosowana do budowy produktu, który spełnia potrzeby biznesowe,
organizuje szczegóły budowanej aplikacji, która ma spełnić potrzeby biznesu i wymagania użytkowników,
struktura rozwiązania i ścieżki komunikacyjne między elementami. (Plan pięter, elewacji, związki między nimi)
projektowanie fizyczne
perspektywa technologii, której będzie używać użytkownik systemu,
celem jest zastosowanie ograniczeń technologicznych świata rzeczywistego do rezultatów projektowania logicznego takich jak rozważania implementacyjne i dotyczące efektywności działania systemu (plany fizycznych elementów struktury jak odrutowanie, hydraulika, system ogrzewania, wentylacji).
Model aplikacji (Application Model)
Aplikacja - logiczna sieć współpracujących, rozproszonych serwisów.
Wielokrotne użycie oznacza, że pojedyncze rozwiązanie biznesowe może wchodzić w skład wielu faktycznych aplikacji.
Funkcje modelu aplikacji:
1.Ustalenie definicji, reguł i związków, które będą tworzyć strukturę aplikacji.
Służy jako baza wymiany idei podczas logicznego projektowania aplikacji.
Nacisk jest na poziom logiczny nie fizyczny - jaką strukturę ma aplikacja a nie jak będzie implementowana.
2.Stanowi/umożliwia spójne podejście do projektowania i budowy aplikacji.
Model buduje wspólne rozumienie aplikacji i określa robocze słownictwo do tworzenia aplikacji.
3.Używa projektowania komponentowego opartego na serwisach.
Model aplikacji oparty o serwisy
3-warstwowy logiczny model projektowania wielowarstwowych, rozproszonych aplikacji, które obejmują trzy kategorie serwisów:
użytkownika,
biznesowe i
dotyczące danych.
Serwis użytkownika – dotyczący interfejsu użytkownika:
wizualny bądź programowy interfejs – użytkownik może być albo osobą albo aplikacją,
prezentacja informacji i zbieranie danych od użytkownika.
Serwis biznesowy
sterowanie operacjami biznesowymi, realizacja reguł biznesowych, zapewnienie integralności transakcyjnej,
transformacja danych na informacje przez zastosowanie reguł biznesowych.
Serwis danych – najniższy widoczny poziom szczegółów używanych do operowania na danych:
utrzymywanie trwałych danych aplikacji,
dostarczenie możliwości definiowania, tworzenia, odczytywania, aktualizacji i usuwania danych.