Utvecklingsmetoder och processer. UML och OCTUPUS en kort introduktion Objektorienterad Realtidsprogrammering 2000 Utvecklingsmetoder och processer. UML och OCTUPUS en kort introduktion

Utvecklingsmetoder ... Problem 70-talet Svårt att utveckla system 80% underhåll Vi vill ha formalism fast enkel och användbar Kommunikation mellan inblandade Många anser att kostnaden för förändring av ett system ökar exponentiellt över tiden. Fast inte säkert sant med dagens metoder. 70-talet Flödesdiagram Strukturerad programmering Top-down, bottom-up och middle-out Flera objektorienterade metoder blev populära på 80-talet och dominerar idag OMT, ObjectOry, Booch, Shlaer-Mellor, Coad-Yourdon ... kostnad Svårt att utveckla system krav design test analys implem- entation produktion Strukturerad programmering Flera metoder

… UML ... Unified Modeling Language UML 90-talet Förening av tre dominerande metoder Booch OMT Objectory ”Standard”, OMG (Object Management Group) med fler än 600 intressenter Mer notation än metod (än så länge) Ej (för) stringent = användbart Det finns möjligheter till vissa egna utvidgningar, bla via så kallade stereotyper UML är de facto standard

Design och utveckling Vilken typ av projekt kan vara avgörande för hur man går tillväga Programmera i det lilla kod skapas av en eller få programmerare. En enskild person kan ha överblick och vara insatt i alla delar av projektet. huvudproblem (mjukvara): designa och utveckla algoritmer Programmera i det stora mjukvaran tas fram av ett stort team. Vissa personer kan specificera eller designa andra kan koda vissa komponenter, slutintegration/applikationen görs kanske av en tredje grupp, osv. Ingen person har möjlighet att sätta sig in alla delar av projektet. Få utvecklare Många utvecklare

Utvecklingsprocess typiskt tillvägangångsätt Kravanalys - beskriv och validera vad systemet skall göra Analys - identifiera systemets struktur så att systemet är enkelt att modifiera om kraven förändras Design - beskriv hur systemet skall realiseras Implementation - implementera systemet och utför enhetstester Testning - verifiera systemet Krav Analys Design Implemen- tation Test

Hitta potentiella aktörer Proceduren Hitta potentiella aktörer Namnge och gör kortfattad beskrivning av varje aktör Begränsa systemet Sammanställ gloslista (så att vi kan enas om vokabulär) För varje aktör: Hitta nödvändiga användningsfall Namnge och gör kortfattad beskrivning av varje användningsfall Granska aktörer och användningsfall och iterera Missade aktörer eller användningsfall? Duplikat? Identifiera gemensamma delar, strukturera modellen, iterera Beskriv varje användningsfall Granska beskrivningarna och iterera Missad eller felaktig funktionalitet? Granska, validera och godkänn modellen

Vad är (objektorienterad) analys? Den tidiga fasen i systemutvecklingen då en abstrakt modell av systemet skapas, utan att gå in på detaljer i den tekniska implementationen En modell av centrala objekt och relationer mellan objekten Analysen utförs utan hänsyn till tekniska lösningar eller begränsningar Syftet är att skapa en förståelse för den verksamhet systemet skall hantera Används som grund för att i en designfas konstruera systemet i detalj och välja teknisk lösning

Analys: vanliga aktiviteter Insamla underlag kravspecifikationer, önskemål, beskrivningar av verksamheten eller befintligt system, intervjuver. Problemdomän definieras Definiera användningsfall dvs hur systemet kommer användas Sök objektkandidater tex mha CRC-kort eller annan brainstormingliknande teknik Klassificera objekt klassnamn, ansvarsområde och eventuellt karaktäristiska attribut och metoder Relationer mellan objekt mha klass- och objektdiagram Slutdokumentation av analysfasen skrivbordstest där olika användningsfall gås igenom, relationer mellan klasser och objekt testas. Valda namn på klasser värderas. Dokumenteras mha grafiska diagram med kompletterande text.

Perspektiv Konceptuellt Specifikations Implementations I detta perspektiv ritar man diagram över koncept i domänen. Dessa koncept avbildas ofta på klasser som implementerar dem, men ofta är så inte fallet. En konceptuell modell ritas med liten eller ingen hänsyn till den mjukvara som skall användas vid implementationen Specifikations I detta perspektiv tittar vi i första hand på gränssnitten för mjukvaran, inte implementationen. Vi tittar snarare på typer än klasser Implementations I detta perspektiv har vi verkligen klasser och implementationen görs tydlig

Processen Påbörjande Utformande Konstruktion Överföring bestäm strategi och mål med projektet kalkylera kostnader konstruera systemet i en serie av iterationer Påbörjande Utformande Konstruktion Överföring samla detaljerade krav och gör analys och design på en hög nivå för att konstruera en grundarkitektur och planera konstruktionen. analysera risker (krav, teknik, skicklighet och politiska) testa, prestandaoptimera, träna användare

Vattenfallsmodellen Traditionell idealiserad modell av utvecklingsprocessen Analys Design Implementation Testning Underhåll

Spiralmodellen Boehms spiralmodell

Utvecklingsprocessen, olika konfigurationer Implementation Kravanalys Design Implementation Testning Kravanalys Analys Design Implementation Testning

Nyare (kontroversiell?) metod för systemutveckling eXtreme Programming (XP), av Kent Beck, inne och hett Tillvägagångsätt (12 grundpelare) Planeringsspel planera snabbt förutsättningarna för nästa release; prioritera, teknikkrav Små releaser släpp nya versioner ofta Metafor hitta en enkel bra metafor Enkel design gör designen så enkel som möjligt Testa testa koden kontinuerligt. Måste lyckas innan utvecklingen går vidare Omstrukturera ("refactoring") strukturera om ofta; ta bort onödig kod, förenkla osv Parprogrammering två programmerare per maskin Kollektivt ägande av koden alla äger och kan ändra i koden Kontinuerlig integration integrera och bygg systemet flera gånger per dag 40-timmarsvecka jobba som regel inte mer än 40 timmar per vecka Inkludera en "kund" i teamet inkludera en "riktig användare" på full tid Följ kodstandard vilket förenklar kommunikation

UML (en kort introducerande översikt) Unified Modeling Language UML är de facto standard används i bla utvecklingsmetoder designmönster Massor av litteratur se tex "standardverken" av Booch, Rumbaugh och Jacobson börja förslagsvis med "The Unified Modeling Language User's Guide"

Vi bryter ner systemet och ser på det på olika sätt Användningsfallsdiagram: Sätt gränser Uppdatera konto Redovisnings- system Analysera risker Chefsförhandlare «uses» Prisför- handla «uses» Värdera Handlare Slut avtal aktör «extends» Försäljare användningsfall Gränserna överskridna

Klassdiagram (Enheter och relationer)

...Klassdiagram (med arv, dvs bla specialiseringar och generaliseringar)

Sekvensdiagram (samarbete mellan delar)

Tillståndsdiagram:

Aktivitetsdiagram (beskriver parallella förlopp) Exempel: "Person::ordna dryck" [inget kaffe] Hitta dryck [ingen cola] [kaffe hittat] [cola hittad] Kaffe i filtret Häll i vatten Hämta koppar Filtret i bryggaren Hämta cola Slå på bryggaren ^kaffepanna.slåPå slå av lampan Brygg Drick Häll upp kaffe

Samarbetsdiagram

Hello world-exempel Javakod för en applet import java.awt.Graphics; class Hello extends java.applet.Applet { public void paint(Graphics g) { g.drawString(”Hallå!”, 10, 10); }

… Hello klassdiagram ... Hello g.drawString(”Hallå!”, 10, 10); paint()

… Hello ... Applet Hello paint() Graphics

… Hello ... ImageObserver Object Component Container Panel Applet

… Hello paketering ... java Hello applet awt lang

… Hello sekvensdiagram ... :Thread :Toolkit :ComponentPeer target:Hello run run callbackLoop handleExpose paint

… Hello komponenter Hello.class Hello.java Hello.html Hello.jpg -----

OCTOPUS-metoden en översikt Objektorienterad Hanterar viktiga problem i realtidssystem som parallellitet synkronisering kommunikation avbrottshantering ASICs (Application-Specific Integrated Circuit), kundanpassad hårdvara på chip hårdvarugränssnitt responstider I huvudsak för icke hårda realtidssystem Utgår från OMT och Fusion

Olika faser, en översikt systemkravfas struktur via kontextdiagram funktionalitet och dynamiskt beteende mha användingsfallsdiagram och användningsfall kan kompletteras med scenarier systemarkitekturfas systemstruktur via delsystemdiagram delsystem analysfas görs för varje delsystem delsystem designfas delsystem implementationsfas

Utvecklingsprocessen: mjukvarusystem Systemkravsfas Användningsfall och kontextdiagram Systemarkitektur Delssystem och gränssnitt Delsystem analys Delsystem analys Hårdvaru- wrapper Delsystem design Delsystem design Delsystem implementation Delsystem implementation Delsystem program Delsystem program Wrapper program Systemprogram