Embed Size (px)
Citation preview
Inżynieria
oprogramowaniaWprowadzenie
WYKŁAD © Piotr Ciskowski
Creating a software system…
what the customerordered
what the analystunderstood
what the projectdescribed
what the programmersdeveloped
after debuggingand deploying
what the customerpayed for
what the customerreally 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 = teoriainż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 = modelodwzorowanie 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ącyNie o to nam chodziłoŻaden pracownik tego nie zrozumie
• niezadowoleni wykonawcyCzego właściwie chcieliście?Przecież tyle nad tym siedzieliśmy
• kłótnie o zakres systemuChcecie dwa razy więcej niż było w umowieZrobiliś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 - sposób postępowania w celu stworzenia modelu- poprawia jakość modeli
• proces - 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 - każdy byt - pojęcie lub rzeczobject mający znaczenie w kontekście rozwiązania problemu
w danej dziedzinie
o klasa - uogólnienie zbioru obiektówclass które mają te same atrybuty, operacje, związki, znaczenie
o komunikat - wymiana informacji między obiektamimessage - zlecenie wykonania jakiejś operacji
o hermetyzacja - atrybuty + metodyencapsulation - różnicowanie / ograniczanie dostępu do obiektu
- ujawnianie otoczeniu tylko niezbędnych informacji
o polimorfizm - nadawanie tej samej nazwy różnym atrybutom i operacjompolymorphism - wykonywanie różnych akcji przez operacje o tych samych nazwach
o dziedziczenie - hierarchiczna zależność klasinheritance
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życiaklasczynnościsekwencjistanów
UML diagram
Structure diagram Behavior diagram
Class diagram
Object diagram
Composite structure
diagram
Deployment diagram
Package diagram
Profile diagram
Component diagram Use case diagram
Activity diagram
State machine diagram
Interaction diagram
Communication
diagram
Interaction
overview diagram
Sequence diagram
Timing diagram
our focus:
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 - zachowanie
• Logiczna - budowa systemu
• Komponentów - oprogramowanie
• Rozlokowania - sprzęt
Perspectives - views:
Use case view
Logical view
architecture
• class diagram
• object diagram• composite structure
diagram• package diagram
Dynamic View
Implementation View
Deployment View
system scope& functionality
•use case diagram• package diagram
software
• component diagram• package diagram
hardware
• deployment diagram• package diagram
behavior
• sequence diagram
• activity diagram
• state machine diagram
• interaction overview diagram
• communication diagram• timing 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 WyrzykowskiJę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ślankowskiUML 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
