Inżynieria oprogramowania Wprowadzenie. WYKŁAD Piotr Ciskowski

Transkrypt

1 Inżynieria oprogramowania Wprowadzenie WYKŁAD Piotr Ciskowski

2 Creating a software system what the customer ordered what the analyst understood what the project described what the programmers developed after debugging and deploying what the customer payed for what the customer really needed

3 Inżynieria oprogramowania o tworzenie dobrych programów / systemów o Wikipedia: wszelkie aspekty produkcji oprogramowania analiza i określenie wymagań projektowanie i wdrożenie ewolucja gotowego oprogramowania informatyka = teoria inżynieria oprogramowania = praktyka informatyk człowiek znający się na komputerach

4 Inżynieria oprogramowania o tworzenie dobrych programów / systemów o Wikipedia o IEEE: zastosowanie - systematycznego, - zdyscyplinowanego, - ilościowego podejścia do - rozwoju, - eksploatacji - i utrzymania oprogramowania

5 Inżynieria oprogramowania o wymagania - projektowanie o walidacja - ewolucja o procesy zarządzanie o narzędzia interfejsy o metody formalne o systemy specjalne o komponenty o niezawodność M O D E L O W A N I E

6 Po co modelować? o by odzwierciedlać / upraszczać rzeczywistość o by zapanować nad złożonością o by sprostać potrzebom uchwycić wymagania o by ułatwić komunikację klient twórca twórcy o by skrócić czas: pomysł realizacja o by podnieść jakość oprogramowania niezawodność adaptacyjność

7 Po co modelować? o by ułatwić życie: zamawiającym i użytkownikom analitykom architektom programistom kierownikom projektów

8 Modelowanie o konstruowanie modeli o uproszczone kopie samochody, samoloty itp. urządzenia techniczne budynki bitwy bonzai o różne założenia: modele redukcyjne wygląd modele zdalnie sterowane zachowanie modele torów - wyścig

9 Modelowanie oprogramowania o różne dziedziny o różne wymagania o program = model odwzorowanie fragmentu rzeczywistości

10 Modelowanie oprogramowania o złożoność o zmienność rzeczywistość wymagania otoczenie (przedsiębiorstw) o abstrakcja wiele pojęć jedno pojęcie ogólne = wiele pojęć szczegółowych moduły modele - mapy

11 Modelowanie oprogramowania o złożoność o zmienność rzeczywistość, wymagania, otoczenie (przedsiębiorstw) o abstrakcja o modele struktura - zachowanie różne poziomy abstrakcji różni odbiorcy dostosowanie oprogramowania do środowiska, w jakim działa model środowiska tłumaczenie model systemu oprogramowania

12 Kryzys oprogramowania o niepowodzenia systemów informatycznych: rakieta Arianne 5 Taurus automatyczny system zawierania transakcji giełda w Londynie system obsługi bagaży na lotnisku w Denver system dysponowania karetkami pogotowia Londyn oprogramowanie urządzenia do radioterapii Therac-25

13 Dobry system o Powodzenie: mieści się w zaplanowanym budżecie mieści się w zaplanowanych ramach czasowych spełnia rzeczywiste potrzeby zamawiającego - złożone i zmieniające się otoczenie o Niepowodzenie: zaniechanie projektu, opóźnienie, przekroczenie budżetu produkt złej jakości, o uboższej funkcjonalności produkt nie odpowiadający na rzeczywiste potrzeby

14 Dobry system o Symptomy niepowodzenia: niezadowoleni zamawiający Nie o to nam chodziło Żaden pracownik tego nie zrozumie niezadowoleni wykonawcy Czego właściwie chcieliście? Przecież tyle nad tym siedzieliśmy kłótnie o zakres systemu Chcecie dwa razy więcej niż było w umowie Zrobiliście nie to, co było w umowie chaotyczna obsługa zmian wymagań Koledzy, dodajcie tu jeszcze taka małą tabeleczkę, przecież to prawie żadna zmiana

15 Dobry system o Przyczyny niepowodzenia: niedokładne specyfikowanie wymagań zła komunikacja brak precyzyjnej architektury brak opanowania złożoności systemu późne wykrywanie niespójności subiektywne oceny części systemu brak kontroli zmian późna weryfikacja zadowolenia klienta

16 Dobry system o Lekarstwo = metodyka: notacja - język modelowania U M L - poprawia komunikację w zespole - zapobiega niespójnościom - pomaga jednoznacznie zdefiniować architekturę - pomaga zapanować nad złożonością techniki proces - sposób postępowania w celu stworzenia modelu - poprawia jakość modeli - kolejność wykonywania działań - zapewnia kontrolę nad wymaganiami, zmianami, jakością - wymagania projekt wykonanie

17 projektowanie systemów o od lat 50 o podejście: strukturalne lata 80 - wiele koncepcji wojny metodologiczne - bałagan obiektowe - lata 90 - różnorodność i powszechność aplikacji - systemy czasu rzeczywistego i systemy wbudowane - multimedia w aplikacjach - dźwięk, głos, grafika, film

18 modelowanie obiektowe o obiekt object o klasa class o komunikat message - każdy byt - pojęcie lub rzecz mający znaczenie w kontekście rozwiązania problemu w danej dziedzinie - uogólnienie zbioru obiektów które mają te same atrybuty, operacje, związki, znaczenie - wymiana informacji między obiektami - zlecenie wykonania jakiejś operacji o hermetyzacja - atrybuty + metody encapsulation - różnicowanie / ograniczanie dostępu do obiektu - ujawnianie otoczeniu tylko niezbędnych informacji o polimorfizm - nadawanie tej samej nazwy różnym atrybutom i operacjom polymorphism - wykonywanie różnych akcji przez operacje o tych samych nazwach o dziedziczenie - hierarchiczna zależność klas inheritance

19 modelowanie obiektowe o ponad 50 metodologii zgoda o James Rumbaugh - OMT Object Modeling Technique notacja diagramów UML - analiza i projektowanie o Grady Booch - OOAD Object Oriented Analysis and Design analiza i projektowanie o Ivar Jacobson - OOSE - Object Oriented Software Engineering modelowanie biznesowe - przypadki użycia o Rational Software - trzej muszkieterowie - trzej amigos

20 UML = diagramy o graficzna reprezentacja tworzonego systemu o logicznie powiązane ze sobą diagramy o statyka dynamika systemu o współpraca różnych grup zawodowych przy tworzeniu systemu właściciele, zamawiający, menedżerowie, użytkownicy analitycy, projektanci programiści, testerzy wizjonerzy - most - realizatorzy wizja system

21 UML = diagramy o graficzna reprezentacja tworzonego systemu o logicznie powiązane ze sobą diagramy o statyka dynamika systemu abstrakcyjne struktury, dynamiki, interakcji, wdrożeniowe konkretne - przypadków użycia klas czynności sekwencji stanów

22 our focus: UML diagram Structure diagram Behavior diagram Class diagram Component diagram Use case diagram Interaction diagram Object diagram Deployment diagram Activity diagram Sequence diagram Composite structure diagram Package diagram State machine diagram Communication diagram Profile diagram Interaction overview diagram Timing diagram

23 UML = diagramy spojrzenie na system o z różnych perspektyw o w różnych kontekstach o na różnym poziomie szczegółowości o na różnych etapach wymagania projekt wykonanie

24 Perspektywy: Przypadków użycia - zakres i funkcjonalność systemu - kluczowa, dominująca Dynamiczna Logiczna Komponentów Rozlokowania - zachowanie - budowa systemu - oprogramowanie - sprzęt

25 Perspectives - views: architecture class diagram object diagram composite structure diagram package diagram Logical view Use case view Dynamic View behavior sequence diagram activity diagram state machine diagram interaction overview diagram communication diagram timing diagram package diagram system scope & functionality use case diagram package diagram Deployment View Implementation View software component diagram package diagram hardware deployment diagram package diagram

26 Diagramy przykład - pralka: UML 1.4 o diagram klas o diagram obiektów o diagram przypadków użycia o diagram stanów

27 Diagramy przykład - pralka: UML 1.4 o diagram klas o diagram obiektów o diagram przypadków użycia o diagram stanów o diagram sekwencji

28 Diagramy przykład - pralka: UML 1.4 o diagram klas o diagram obiektów o diagram przypadków użycia o diagram stanów o diagram sekwencji o diagram czynności

29 Diagramy przykład - pralka: UML 1.4 o diagram klas o diagram obiektów o diagram przypadków użycia o diagram stanów o diagram sekwencji o diagram czynności o diagram kooperacji

30 UML Unified Modeling Language o jest językiem modelowania o nie jest językiem programowania

31 Urządzenia / systemy / programy / procesy są dla ludzi o ekspres do kawy o termostat o system obsługi uczelni o program do obsługi plików o program do gry na giełdzie o baza danych o bank internetowy o zakładanie firmy o prowadzenie firmy o zapisy do szkoły o wypełnianie PITa o produkcja o sklep internetowy o fora, blogi, portale o sprzęt AGD RTV o bankomat o robot

32 Plan wykładu o diagramy przypadków użycia klas czynności sekwencji pozostałe o modelowanie procesów biznesowych wymagań użytkownika klas dynamiki o metodyki

33 Literatura - książki o Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych o Stanisław Wrycza i in. UML 2.1. Ćwiczenia o Stanisław Wrycza, Bartosz Marcinkowski, Jacek Maślankowski UML 2.x. Ćwiczenia zaawansowane o Michał Śmiałek. Zrozumieć UML 2.0. Metody modelowania obiektowego o Joseph Schmuller. UML dla każdego o Martin Fowler, Kendal Scott. UML w kopelce o Grady Booch, James Rumbaugh, Ivar Jacobson. UML. Przewodnik użytkownika o P. Stevens. UML. Inżynieria oprogramowania o P. Graessle i in. UML 2.0 w akcji. Przewodnik oparty na projektach o W. Dąbrowski i in. Modelowanie systemów informatycznych w języku UML 2.1 w praktyce o R. Maksimchuk. UML dla zwykłych śmiertelników

34 Literatura strony, fora, blogi itp. o o wazniak.mimuw.edu.pl/index.php?title=inżynieria_oprogramowania o msdn.microsoft.com o Visual Studio Application Lifecycle Management o Modeling the Application o channel9.msdn.com/blogs/clinted o o o

35 Narzędzia o kartka papieru o MS Visio o diagram modelu UML o UML 2.2 Stencils and Template o MS Visual Studio o Ultimate! o IBM Rational o Software Architect o Sparx Enterprise Architect o trial desktop professional corporate - suites o Visual Paradigm - UML o community modeler standard professional - enterprise o Business Project Visual Architect o Agilian