Inżynieria oprogramowania Wprowadzenie WYKŁAD Piotr Ciskowski
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
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
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
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
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ść
Po co modelować? o by ułatwić życie: zamawiającym i użytkownikom analitykom architektom programistom kierownikom projektów
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
Modelowanie oprogramowania o różne dziedziny o różne wymagania o program = model odwzorowanie fragmentu rzeczywistości
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
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
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
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
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
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
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
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
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
modelowanie obiektowe o 1989 1994 - ponad 50 metodologii zgoda o James Rumbaugh - OMT Object Modeling Technique 1991 - notacja diagramów UML - analiza i projektowanie o Grady Booch - OOAD Object Oriented Analysis and Design 1991 - analiza i projektowanie o Ivar Jacobson - OOSE - Object Oriented Software Engineering 1992 - modelowanie biznesowe - przypadki użycia o 1994 1995 - Rational Software - trzej muszkieterowie - trzej amigos
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
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
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
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
Perspektywy: Przypadków użycia - zakres i funkcjonalność systemu - kluczowa, dominująca Dynamiczna Logiczna Komponentów Rozlokowania - zachowanie - budowa systemu - oprogramowanie - sprzęt
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
Diagramy przykład - pralka: UML 1.4 o diagram klas o diagram obiektów o diagram przypadków użycia o diagram stanów
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
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
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
UML Unified Modeling Language o jest językiem modelowania o nie jest językiem programowania
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
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
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
Literatura strony, fora, blogi itp. o www.uml.com.pl 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 http://www.sparxsystems.com/uml-tutorial.html o http://www.visual-paradigm.com/training/ o www.goldenline.pl/forum/inzynieria-oprogramowania
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