E. Stemposz. Rational Unified Process, Wykład 10, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 10 Przepływ.

Slides:



Advertisements
Podobne prezentacje
Projektowanie systemowe
Advertisements

Projektowanie w cyklu życia oprogramowania
Złożoność procesu konstrukcji oprogramowania wymusza podział na etapy.
Część 2 OiZPI Iteracyjny przyrostowy model cyklu życiowego Rational Unified Process™ w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów.
OiZPI Część 5 narzędzia CASE w materiałach wykorzystano:
Wykład 8 Przepływ prac: Modelowanie biznesowe
Tomasz Pieciukiewicz Rafał Hryniów
1 / 47 WARSZAWA 2005 Przemysław Siekierko Stanisław Andraszek Rational Unified Process.
Architektura systemu Gra strategiczna „Strusia Jama”
UML Unified Modeling Language
Propozycja metodyki nauczania inżynierii oprogramowania
Co UML może zrobić dla Twojego projektu?
Tomasz Jabłoński Michał Ziach
Cykle życia oprogramowania
Diagram czynności (Activity Diagrams)
Rational Unified Process
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Modele baz danych - spojrzenie na poziom fizyczny
Projektowanie - wprowadzenie
Analiza, projekt i częściowa implementacja systemu obsługi kina
Wykład 4 Analiza i projektowanie obiektowe
Wykład 5 UML - Unified Modeling Language
Wykład 2 Cykl życia systemu informacyjnego
Projekt i implementacja aplikacji wspomagającej testowanie
C.d. wstępu do tematyki RUP
Kontrola spójności modeli UML za pomocą modelu przestrzennego DOD
Model przestrzenny Diagramu Obiegu Dokumentów
Źródła: podręcznikopracował: A. Jędryczkowski.
MDA – Model Driven Architecture
Wykład 6 Przypadki użycia a proces
Zarządzanie projektami
POŚREDNIK Jak reprezentowana jest informacja w komputerze? liczby – komputer został wymyślony jako zaawansowane urządzenie służące do wykonywania.
Podsumowanie metodologii OMT
Rational Unified Process Implementacja Aleksandra Reiman, gr. I-52.
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
1 Każdy obiekt jest scharakteryzowany poprzez: tożsamość – daje się jednoznacznie wyróżnić; stan; zachowanie. W analizie obiektowej podstawową strukturą
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Wprowadzenie do UML dr hab. inż. Kazimierz Subieta profesor PJWSTK.
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
Model obiektowy bazy danych
Komputerowe wspomaganie projektowania
Diagram aktywności (czynności)
Diagram klas Kluczowymi elementami są: klasy (class)
Walidacja danych alina suchomska.
Zarządzanie zagrożeniami
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Michał Sipek Piotr Kapciak
PODSTAWY SIECI KOMPUTEROWYCH - MODEL ISO/OSI. Modele warstwowe a sieci komputerowe Modele sieciowe to schematy funkcjonowania, które ułatwią zrozumienie.
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
ZINTEGROWANE SYSTEMY ZARZĄDZANIA
Eksploatacja zasobów informatycznych przedsiębiorstwa.
Platforma .Net.
Struktura systemu operacyjnego
Model warstwowy ISO-OSI
E. Stemposz. Rational Unified Process, Wykład 1, Slajd 1 Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 1 Najlepsze praktyki Wykładowca:
Studia Podyplomowe IT w Biznesie Analiza dynamiczna w UML
E. Stemposz. Rational Unified Process, Wykład 11, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 11 Typowe.
E. Stemposz. Rational Unified Process, Wykład 2, Slajd 1 Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 2 Krótka charakterystyka RUP.
MAS Rafał Hryniów. Agenda  Zasady  Referaty  Projekt  Kolosy.
Cykle życia oprogramowania oraz role w zespole projektowym Autor: Sebastian Szałachowski s4104.
Inżynieria systemów informacyjnych
PROJEKTOWANIE APLIKACJI INTERNETOWYCH
Inżynieria Oprogramowania Laboratorium
IEEE SPMP Autor : Tomasz Czwarno
JavaBeans by Paweł Wąsala
Modele baz danych - spojrzenie na poziom fizyczny
Zapis prezentacji:

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 10 Przepływ prac: Analiza i projektowanie Wykładowca: dr inż. Ewa Stemposz Polsko-Japońska Wyższa Szkoła Technik Komputerowych Warszawa

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 2 wrzesień 2002 Powrót Zagadnienia Analiza kontra projektowanie Pracownicy Artefakty Przepływ prac: Analiza i projektowanie Wsparcie narzędziowe Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 3 wrzesień 2002 Powrót Analiza kontra projektowanie (1) Podstawowym celem przepływu prac Analiza i projektowanie jest zamiana wymagań w specyfikację sposobu implementowania systemu. Podstawowym zadaniem jest „określenie najlepszej strategii dla sposobu implementowania systemu”, co osiąga się poprzez:  ustanowienie stabilnej architektury − bazy dla budowy systemu łatwego do zrozumienia i rozwijania,  przystosowanie projektu do środowiska implementacji,  uwzględnienie własności systemu, takich jak: używalność, niezawodność, wydajność, wsparcie dla pielęgnacji, itp. Analiza: Zadaniem analizy jest transformacja wymagań na system w postać, która jest dobrze mapowana do obszaru zainteresowań projektantów, czyli do zbioru klas i podsystemów. Ta transformacja opierana jest w RUP o przypadki użycia i wymagania niefunkcjonalne. Analiza skupia się na funkcjonalności systemu i ignoruje zarówno wymagania niefunkcjonalne, jak i ograniczenia środowiska implementacji. Można powiedzieć, że analiza prowadzi do uzyskania „prawie idealnego” obrazu systemu.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 4 wrzesień 2002 Powrót Analiza kontra projektowanie (2) Projektowanie: Zadaniem projektowania jest przystosowanie wyników analizy do wymagań niefunkcjonalnych i ograniczeń środowiska implementacji. Projektowanie jest uszczegółowieniem analizy. Aktywności skupione są na optymalizacji projektu systemu, w konkretnym środowisku implementacji, z jednoczesnym zapewnieniem pełnego pokrycia dla funkcjonalności. Jak szczegółowy powinien być projekt systemu?  Projekt powinien być „szczegółowy na tyle”, by w trakcie implementacji nie powstawały niejednoznaczności. Stopień szczegółowości jest uzależniony od doświadczenia programistów i złożoności projektu. Uwaga: Projekty bardzo szczegółowe, implementowane poprzez bezpośrednie transformacje konstrukcji projektu w kod, pozwalają na znaczne zmniejszenie liczby błędów (zostaje usunięty jeden krok transformacji).

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 5 wrzesień 2002 Powrót Pracownicy (1) Architekt Model analityczny Model projektowy InterfejsDokument architektury oprogramowania Artefakty systemów czasu rzeczywistego Zdarzenie Sygnał Protokół odpowiedzialny za

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 6 wrzesień 2002 Powrót Pracownicy (2) Realizacja przypadku użycia: opis sposobu realizacji przypadku użycia (w oparciu o istniejący model projektowy), z reguły w terminach współpracujących obiektów. Projektant Realizacja przypadku użycia Klasa Pakiet projektowy Podsystem odpowiedzialny za Projektant kapsuł Systemy czasu rzeczywistego odpowiedzialny za Projektant bazy danych Model danych odpowiedzialny za Kapsuła: wzorzec projektowy reprezentujący kompletny wątek w systemie. Kapsuły komunikują się między sobą za pośrednictwem portów. Protokół: określa zasady komunikowania się w obrębie pewnego zbioru portów: porządek portów, wymieniane komunikaty, itd. Kapsuła

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 7 wrzesień 2002 Powrót Pracownicy (3) Architekt: Do zadań architekta należy specyfikacja każdej z perspektyw architektonicznych, dekompozycja na elementy składowe, grupowanie elementów i określenie interfejsów między najważniejszymi zgrupowaniami. W przeciwieństwie do innych rodzajów pracowników, ogląd architekta jest raczej „szerszy niż głębszy”. Projektant: Definiuje odpowiedzialności, atrybuty, operacje i związki jednej lub kilku klas i określa, jak te elementy będą realizowane w środowisku implementacji. Ponadto, projektant może być odpowiedzialny za jeden lub kilka pakietów projektowych czy pakietów podsystemów. Inni pracownicy zaangażowani w aktywności związane z przepływem prac Analiza i projektowanie, to projektant bazy danych i projektant kapsuł. Projektant bazy danych: Potrzebny, gdy projektowany system zawiera bazę danych. Projektant kapsuł: Potrzebny, gdy projektowany system ma być systemem czasu rzeczywistego − odpowiada za używane technologie (dobór właściwych technologii i odpowiedni sposób ich wykorzystywania).

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 8 wrzesień 2002 Powrót Artefakty (1) Główne artefakty przepływu prac Analiza i projektowanie: Model projektowy, Opis architektury systemu. Model projektowy: Składa się z klas, pakietów (w tym pakietów podsystemów). Pakiety podsystemy traktowane są jako rodzaj środka organizacyjnego pozwalającego na zmniejszenie złożoności modelu wynikowego. Model analityczny: Artefakt, efekt aktywności związanych z analizą. Będąc rodzajem abstrakcji (generalizacji modelu projektowego), skupia się wyłącznie na funkcjonalności systemu. Dalsze uszczegóławianie modelu jest przeprowadzane w trakcie projektowania. Interfejsy: Specyfikują zbiór operacji możliwych do wykonania na elemencie modelu. Interfejsy specyfikowane są poprzez sygnatury operacji dostępnych dla danego elementu modelu. Sygnatura każdej operacji jest opisywana przez listę argumentów oraz typ wartości zwracanej. Artefakty dla systemów czasu rzeczywistego: kapsuły.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 9 wrzesień 2002 Powrót Przepływ prac: Analiza i projektowanie (1) Definiuj potencjalną architekturę [Wczesne iteracje fazy opracowywania] Uszczegóławiaj architekturę Analizuj zachowania Projektuj komponenty Projektuj komponenty czasu rzeczywistego Projektuj bazę danych [Dla czasu rzeczywistego] [Pozostałe] [Opcjonalnie] [Iteracje w fazie Opracowywania]

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 10 wrzesień 2002 Powrót Przepływ prac: Analiza i projektowanie (2) Aktywności przepływu prac Analiza i projektowanie różnią się nieco w zależności od fazy: w iteracjach należących do fazy opracowywania definiowana jest architektura − rozwijane są obszary najważniejsze dla projektu ze względu na funkcjonalność i mitygację największych ryzyk. Późniejsze aktywności, w iteracjach należących do fazy konstrukcji, są poświęcone rozwijaniu innych obszarów, tak aby uzyskać maksymalnie stabilną platformę architektoniczną. Definiuj potencjalną architekturę: Podstawowym celem jest utworzenie szkieletu architektonicznego poprzez określenie (1) wstępnego zbioru elementów istotnych architektonicznie, stanowiących podstawę dla dalszych rozważań, ustalenie (2) wstępnego zbioru mechanizmów architektonicznych oraz (3) wstępnej propozycji dla podziału na warstwy (ogólnie − wstępnej propozycji organizacji systemu), (4) tych przypadków użycia, które będą podlegały dalszym pracom w danej iteracji. W oparciu o wybrane przypadki użycia, należy zidentyfikować klasy modelu analitycznego zaangażowane w ich realizację − analiza interakcji między klasami może wpłynąć na modyfikację realizacji.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 11 wrzesień 2002 Powrót Przepływ prac: Analiza i projektowanie (3) Uszczegóławiaj architekturę: Można tu wyróżnić aktywności wykonywane przez architekta (identyfikuj mechanizmy architektoniczne, identyfikuj elementy projektowe w oparciu o już istniejący zbiór elementów, opisz architekturę czasu wykonania, opisz rozmieszczenie elementów) i aktywności związane z przeglądami architektury, za które jest opowiedzialny recenzent architektury. Główne cele aktywności Uszczegóławiaj architekturę:  Zapewnienie przejścia − w możliwie jak najbardziej naturalny sposób − z aktywności związanych z analizą do aktywności związanych z projektowaniem, poprzez identyfikację elementów projektowych z elementów analitycznych oraz identyfikację mechanizmów projektowych z odpowiednich mechanizmów analitycznych.  Zapewnienie spójności i integralności architektury przez dbanie o to, by elementy zidentyfikowane w danej iteracji były integrowane z elementami zidentyfikowanymi wcześniej i by komponenty (czy inne elementy projektowe o odpowiednio wysokim potencjale ponownego użycia) były wykrywane możliwie jak najwcześniej, tak by zredukować nakłady na projektowanie.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 12 wrzesień 2002 Powrót Przepływ prac: Analiza i projektowanie (4)  Określenie organizacji modelu implementacji tak, by przejście z modelu projektowego do modelu implementacji było bezszwowowe.  Opisanie organizacji systemu czasu wykonania. Analizuj zachowania: Składa się z aktywności wykonywanych przez projektanta (analizuj przypadki użycia), przez architekta (identyfikuj elementy projektowe) i przez recenzenta (związane z przeglądami projektu). Główny cel: transformacja opisu zachowania systemu dostarczonego w postaci przypadków użycia na zbiór elementów stanowiących bazę dla modelu projektowego − nacisk jest tu położony na wymagania funkcjonalne. Projektuj komponenty: Składa się z aktywności wykonywanych przez projektanta (projektuj przypadki użycia, projektuj klasy, projektuj podsystemy), i przez recenzenta (związane z przeglądami projektu). Projektuj komponenty czasu rzeczywistego: Cel tej aktywności jest podobny do aktywności poprzedniej, lecz włączane są aktywności związane z projektowaniem kapsuł, tak by zdefiniować współbieżne wątki w systemie i określić protokoły wymiany informacji.

E. Stemposz. Rational Unified Process, Wykład 10, Slajd 13 wrzesień 2002 Powrót Przepływ prac: Analiza i projektowanie (5) Projektuj bazę danych: Składa się z aktywności wykonywanych przez projektanta bazy danych (projektuj bazę danych), przez projektanta (projektuj klasy) i przez recenzenta (związane z przeglądami projektu). Cel: identyfikacja trwałych klas, zaprojektowanie odpowiedniej dla tych klas struktury bazy danych oraz określenie mechanizmów wspierających przechowywanie i dostęp do trwałych danych tak, by spełniać ograniczenia nakładane na wydajność. Wsparcie narzędziowe:  UML − język do opisu modeli. Narzędziem wspierającym pozyskiwanie, zarządzanie i prezentowanie modeli jest Rational Rose. Rational Rose wspiera kilka wybranych języków programowania, pozwalając na synchronizację projektu i kodu. Rose Real Time umożliwia prezentację wykonania zaimplementowanego fragmentu projektu.  SoDa pozwala na automatyczne tworzenie i formatowanie dokumentów i raportów poprzez wydobywanie informacji z kilku innych narzędzi, np. z Rational Rose czy Requisite Pro.