Języki i metodyka oprogramowania Automatyka i Robotyka sem.2 (część I) Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Literatura A. Januszkiewicz. Inżynieria oprogramowania. Helion 1997. W. Dąbrowski, A. Stasiak, M. Wolski. Modelowanie systemów informatycznych w języku UML2.1. PWN S.A. 2007. G. Booch, J.Rumbaugh, I.Jacobson. UML przewodnik użytkownika. WNT 2001, 2002. (Seria: inżynieria oprogramowania). F. P. Brooks: The Mythical Man-Month. Addison Wesley Publishing Company. 1995 (Anniversary Addition) (jest polskie tłumaczenie). J. Hunt. The Unified Process for Practitioners. Object Oriented Design, UML and Java. Springer, 2000. JIMO 2010/2011 2 Kariera zawodowa Kariera zawodowa w informatyce: Programista (tester), Projektant (projektant testów), Analityk. Kierownik (osoba zarządzająca): Zadaniem, Projektem (coraz większym). JIMO 2010/2011 3 1
Inżynieria oprogramowania a dobre oprogramowanie Inżynieria oprogramowania jako nauka praktyczna mówiąca o sposobie (metodyce) tworzenia dobrego oprogramowania. Cechy dobrego oprogramowania: Zgodne z wymaganiami użytkownika, Niezawodne, Efektywne, Łatwe w konserwacji, Ergonomiczne. JIMO 2010/2011 4 Dobre oprogramowanie Dlaczego jest trudno zrobić dobre oprogramowanie? Duża złożoność systemów informatycznych. Niepowtarzalność poszczególnych przedsięwzięć. Nieprzejrzystość procesu budowy oprogramowania (trudność w ocenie stopnia zaawansowania prac). Co to znaczy, że prace są zaawansowane w 90%? Jak mierzyć postęp w realizacji przedsięwzięcia? Pozorna łatwość wytwarzania produktu i dokonywania poprawek (1 dzień 100 linii, 10 dni 1000 linii, 100 dni 10.000 linii, 10 osób razy 100 dni 100.000 linii). JIMO 2010/2011 5 Inżynieria oprogramowania Inżynieria oprogramowania opisuje między innymi: Sposoby prowadzenia przedsięwzięć informatycznych, Techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć informatycznych, Metody analizy i projektowania systemów, Techniki zwiększania niezawodności oprogramowania, Sposoby testowania systemów i szacowania niezawodności, Sposoby przygotowania dokumentacji technicznej i użytkowej, Procedury kontroli jakości, Metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń), Techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy. JIMO 2010/2011 6 2
Modele cyklu życia oprogramowania Model kaskadowy, Realizacja sterowana dokumentami (ang. document driven). Prototypowanie, Programowanie odkrywcze, Realizacja przyrostowa, Montaż z gotowych elementów, Model spiralny. JIMO 2010/2011 7 Strategia, Cykl życia oprogramowania (fazy) Model wodospadowy Określenie wymagań. Analiza (modelowanie). Projektowanie. Implementacja. Dokumentacja (produkcyjna, użytkownika). Testowanie. Instalacja, szkolenie. Konserwacja oprogramowania. JIMO 2010/2011 8 Narzędzia wspomagające Narzędzia wspomagające tworzenie oprogramowania (narzędzia CASE): Do zarządzania całym cyklem życia (OracleCASE, RUP - IBM). Do analizy i projektowania z wykorzystaniem UML, (Posejdon, wtyczki do NetBeans, Eclipse). Do kodowania, uruchamiania, testowania (Eclipse, NetBeans, JBuilder). Rozwój graficznych metod tworzenia oprogramowania, aż do pełnej generacji kodu. JIMO 2010/2011 9 3
Podstawowe wiadomości o UML (Unified Modelling Language) Diagramy (rysunki) tworzące model systemu. Do diagramów konieczne są definicje, opisy, słowniki. Zespół diagramów daje całkowity opis systemu (miejmy nadzieję). UML jest językiem przeznaczonym do: Wizualizacji, Specyfikacji, Opisu, Dokumentacji oprogramowania. JIMO 2010/2011 10 UML podstawowe diagramy Diagram przypadków użycia (ang. use case diagram), Diagram klas (ang. class diagram), Diagram obiektów (ang. object diagram), Diagram działania (ang. activity diagram), Diagram sekwencji (ang. sequence diagram), Diagram współpracy (ang. collaboration diagram), Diagram przejść stanów (ang. state charts), Diagram składowych (ang. component diagram) Diagram rozmieszczenia (ang. deployment diagram). JIMO 2010/2011 11 Tradycyjny sposób tworzenia oprogramowania Projekt przebiega według modelu wodospadowego, w kolejności wykonując wymagania, analizę, projekt, implementację, a następnie utrzymując system. Projekt ma tylko jeden cykl. Projekt ma tylko jedną iterację w jednym kroku (przykładowo w analizie). JIMO 2010/2011 12 4
Wada tradycyjnego sposobu wytwarzania oprogramowania Podstawowym problemem (wadą) modelu kaskadowego (wodospadowego) jest to, że wymagania są analizowane raz, powinny być więc dobrze zdefiniowane na początku. W takim procesie nie ma miejsca na zmiany w wymaganiach, czyli odbiorca może otrzymać produkt niedostosowany do zmienionych (w czasie budowy systemu) warunków. JIMO 2010/2011 13 Podstawowe wiadomości o Rational Unified Process (RUP). Hierarchiczna struktura RUP Cykle (ang. Cycles) Fazy (ang. Phases) Iteracje (ang. Iterations) Prace (ang. Workflows) Czynności (ang. Activities) Cztery fazy RUP Inception -> Elaboration -> Construction -> Transition JIMO 2010/2011 14 Rational Unified Process (RUP) Inception - Definiuje zakres projektu i cel tego przedsięwzięcia w terminach biznesowych. Określa możliwość wykonania projektu (ang. feasibility). Elaboration - Opisuje i analizuje wymagania funkcjonalne, specyfikuje wymagania niefunkcjonalne, ustala podstawową architekturę systemu. Construction - Wytworzenie produktu (systemu). Transition - Przeniesienie produktu do środowiska produkcyjnego. JIMO 2010/2011 15 5
Rational Unified Process (RUP) JIMO 2010/2011 16 Rational Unified Process (RUP) JIMO 2010/2011 17 Rational Unified Process (RUP) Inception (olśnienie, pomysł). Faza ta koncentruje się na wygenerowaniu opisu z punktu widzenia potrzeb użytkownika (business case), oceny czy jest to wykonalne i opłacalne. Zdefiniowane są tu przypadki użycia, zakres działania systemu, a także nowe, ryzykowne bądź trudne elementy systemy, mogące mieć wpływ na końcowy sukces. W fazie tej powstaje koncepcja architektury (na najwyższym poziomie), dla oceny stopnia komplikacji. Należy też ocenić wykonalność projektu oraz oszacować nakłady czasu, siły roboczej, finansowe. Podstawową pracą są tu prace nad wymaganiami, jednakże by rzetelnie ocenić architekturę konieczne są pewne prace analityczne, projektowe, a nawet implementacyjne. Podstawowym pytaniem jest jednak wykonalność przedsięwzięcia. JIMO 2010/2011 18 6
Rational Unified Process (RUP) Elaboration (podstawowa architektura zarys systemu) Podstawowym zadaniem tej fazy jest zrozumienie (i formalne zapisanie) jak wymagania przekładają się na podstawową architekturę systemu i jak mogą przebiegać dalsze prace. Wszystkie przypadki użycia powinny być dokładnie opisane. Zidentyfikowane powinny być elementy obarczone ryzykiem (nieznane). Powinny one być opracowane jako pierwsze w następnej fazie (construction). Rozważeniu powinny podlegać też zagadnienia związane z niezawodnością oraz szybkością działania. Odpowiednio wysokie wymagania mogą mieć istotny wpływ na architekturę systemu. W fazie tej powinna być zaprojektowana, zaimplementowana i przetestowana przewidywana architektura systemu. Jak w każdej fazie powinny być określone elementy o najwyższym ryzyku (najwyższej trudności). JIMO 2010/2011 19 Rational Unified Process (RUP) Construction (w pełni funkcjonalna wersja beta) Produktem końcowym tej fazy jest w pełni funkcjonalna wersja beta systemu. Może ona zawierać pewne błędy, wymagać pewnych niedużych poprawek. Poprawki te nie powinny zmieniać podstawowej funkcjonalności. Powodzenie tej fazy zależy głównie od rozwiązania problemów wykrytych we wcześniejszych fazach. Faza ta zawiera prace głownie projektowe i implementacyjne, chociaż prace nad wymaganiami i analityką są dopuszczalne. JIMO 2010/2011 20 Rational Unified Process (RUP) Transition (produkt końcowy - wersja produkcyjna) Faza ta zaczyna się instalacji beta wersji systemu, uzyskaniu opinii użytkownika i wprowadzeniu żądanych zmian i usprawnień. Mogą być tu prowadzone prace projektowe i implementacyjne. Faza ta kończy się oddaniem wersji produkcyjnej systemu. JIMO 2010/2011 21 7
Rational Unified Process (RUP) Faza (ang. Phase) Czas trwania Zużycie zasobów Inception 10-20% 5-10% Elaboration 30-40% 20-25% Construction 40-50% 60-65% Transition 5-10% 5-10% JIMO 2010/2011 22 Rational Unified Process (RUP) Liczby iteracji dla projektu o średnim stopniu złożoności: Inception. Jedna iteracja, składająca się głównie z prac nad wymaganiami. Elaboration. Dwie iteracje, pierwsza identyfikująca przypadki użycia i zarys architektury, druga uszczegółowiająca przyjętą architekturę. Construction. Trzy, cztery lub pięć iteracji w zależności od wykrytych zagrożeń i złożoności systemu. Każda z iteracji zawiera prace projektowe, implementacyjne i testowanie. Mogą też wchodzić prace analityczne (wprowadzanie zmian). Transition. Jedna lub dwie iteracje w zależności od sukcesu wersji beta. JIMO 2010/2011 23 Metodyka SCRUM SCRUM to iteracyjny, przyrostowy sposób budowy/rozwoju produktu. Po każdej iteracji powinien powstać produkt o nowej funkcjonalności, gotowy do przekazania zamawiającemu. Cechy charakterystyczne metodyki SCRUM: SCRUM jest zwinną metodyką zarządzania produkcją oprogramowania, SCRUM obejmuje (zawiera) istniejące (stosowane) metodyki, SCRUM jest metodyką dla zespołu wytwarzającego produkt, którego wymagania zmieniają się gwałtownie, SCRUM jest procesem, który uwzględnia i rozwiązuje konfliktowe sytuacje, SCRUM jest sposobem na poprawę komunikacji w zespole i osiągnięcie dobrej współpracy. SCRUM jest sposobem na eliminację przeciwności w procesie tworzenia produktu. SCRUM jest sposobem zwiększenia produktywności zespołu, SCRUM jest skalowany, od pojedynczych produktów do całych organizacji, SCRUM powoduje, że każdy członek zespołu czuje się przydatny. JIMO 2010/2011 24 8
Metodyka SCRUM JIMO 2010/2011 25 Zarządzanie metodyką SCRUM JIMO 2010/2011 26 Metodyka SCRUM i extreme programmning JIMO 2010/2011 27 9
Obiektowy sposób myślenia Języki programowania, rys historyczny kod maszynowy, języki asemblera, języki wysokiego poziomu, języki generacyjne. Programowanie strukturalne i obiektowe. Obiektowy sposób myślenia ang. object - oriented analysis, design, programming (OOA - OOD OOP) JIMO 2010/2011 28 Wymagania przypadki użycia (ang. use cases) Wyniki zastosowania przypadków użycia to: Opis wszystkich interakcji z systemem, Aktorzy, którzy współdziałają z systemem, Inne artefakty (takie jak GUI i wymagania niefunkcjonalne). Podstawowe czynności analizy przypadków użycia: Znaleźć i opisać aktorów występujących w systemie, Znaleźć wszystkie przypadki użycia, Właściwie opisać przypadki użycia, Opisać cały model przypadków użycia, Przygotować słownik terminów. JIMO 2010/2011 29 Przypadki użycia (przykład) JIMO 2010/2011 30 10
Przypadki użycia (przykład) JIMO 2010/2011 31 Przypadki użycia - aktor Aktor to cokolwiek, co współdziała (ma interakcję) z naszym systemem. Aktor nie reprezentuje konkretnego użytkownika, reprezentuje jedynie rolę użytkownika. Aktor może mieć dodatkowe cechy jak identyfikatory, dozwolone operacje, znaczniki (ang. tagged values), ograniczenia. JIMO 2010/2011 32 Przypadki użycia - aktor Aktor - jak go znaleźć trzeba poszukać odpowiedzi na pytania: Kto jest zainteresowany systemem? Kto potencjalnie będzie używał systemu? Kto będzie czerpał korzyści z działania systemu? Kto dostarcza informację do systemu? Kto otrzymuje informację z systemu? Kto pielęgnuje informację w systemie? Gdzie jest miejsce systemu w organizacji? JIMO 2010/2011 33 11
Przypadki użycia Reguły, które muszą być spełnione przy poszukiwaniu aktorów: Zawsze powinien być przynajmniej jeden użytkownik dla każdego aktora. Role poszczególnych aktorów powinny być rozłączne. Przypadki użycia specyfikują sekwencję akcji z wariantami, które system może wykonać i które w rezultacie dają wymierny (obserwowalny) rezultat dla aktora. JIMO 2010/2011 34 Przypadki użycia Przypadki użycia zawierają (opisują): Sekwencję wykonywanych akcji, Opcjonalny zbiór jednej lub wielu alternatywnych sekwencji akcji, Krótką definicję przyczyny przypadku użycia, Sposób komunikacji z jednym lub wieloma aktorami, Ograniczenia w użyciu. JIMO 2010/2011 35 Przypadki użycia Przypadki użycia i sposób ich zidentyfikowania. Zbiór wszystkich przypadków użycia definiuje funkcjonalność systemu i stanowi postawę do ustalenia testów końcowych (!). Identyfikacja przypadków użycia bazuje na identyfikacji aktorów. Każdy aktor musi posiadać przynajmniej jeden przypadek użycia. JIMO 2010/2011 36 12
Przypadki użycia W identyfikacji przypadków użycia pomocne mogą być odpowiedzi na pytania: Jakie są główne zadania każdego aktora? Czy aktor zapisuje, odczytuje lub zmienia informację w systemie? Czy rozpatrywany przypadek użycia powoduje utworzenie, zapamiętanie, zmianę, usunięcie, odczytanie informacji? Dla każdego aktora: Czy aktor ma informować system o zmianach na zewnątrz? Czy aktor chce być informowany o zmianach na zewnątrz? Czy przypadki użycia zawierają utrzymanie systemu? Czy wszystkie wymagania funkcjonalne dla systemu są zawarte w aktualnych przypadkach użycia? JIMO 2010/2011 37 Przypadki użycia Nazwy przypadków użycia muszą mieć znaczące nazwy. Do poprawnego zidentyfikowania przypadków użycia pomocne są techniki: Wywiadów z aktualnymi lub przyszłymi użytkownikami systemu, Tablice poglądowe (rysunki w dużej skali), Seminaria połączone z burzą mózgów nad możliwymi scenariuszami zdarzeń w systemie. JIMO 2010/2011 38 Przypadki użycia Zdarzenia w przypadkach użycia: Warunki wstępne do użycia przypadku (logowanie). Kiedy i jak przypadek zaczyna się i kończy się? Jakie interakcje przypadku użycia występują z aktorami? Jakie dane są potrzebne do przypadku użycia? Jaki jest normalny ciąg (sekwencja zdarzeń)? Jakie są sekwencje alternatywne bądź związane z obsługą wyjątków? Jakie są warunki po zakończeniu przypadku użycia? JIMO 2010/2011 39 13
Przypadki użycia Doskonalenie modeli przypadków użycia. Model nie powinien być zbyt mały bądź zbyt obszerny. Celem jest zrozumiałość modelu. Model powinien być kompletny i zwarty. Nie powinien odwoływać się do dodatkowego materiału, by móc określić jego funkcjonalność. Przypadki użycia powinny dostarczać wartość dodatkową dla użytkowników systemu (aktorów). Każdy przypadek użycia musi być skojarzony z przynajmniej jednym aktorem. Przypadek użycia bez aktora nigdy nie będzie użyty. JIMO 2010/2011 40 Przypadki użycia Słowniki (konieczne definicje). Opisy (konieczne objaśnienia), Projekty interfejsów : Interfejsy graficzne z użytkownikiem (GUI), dla języka Java pakiet Swing, Interfejsy z innymi systemami (budowane na zamówienie specyfikacja). Interfejsy oparte na standardach wymiany informacji (np. XML, webmethods). JIMO 2010/2011 41 14