Model og Metode til Programudvikling v/ Jens Dalsgaard Nielsen 1
Hvem er vi? Jens Dalsgaard Nielsen, Afd for Proceskontrol, I8 Distribuerede RT-Systems group Realtid, kerner, operativsystemer, netværk,.. Jeg kan findes på Fredrik Bajersvej 7C jdn@control.aau.dk http://www.control.aau.dk/~jdn/edu/courses/oo 2
Om... At give et indblik i Objektorientering analyse,design og lidt programmering Beskrivelsesmetoder dertil (UML) Indsigt i selve processen omkring udvikling af programmel Det er et STORT emneområde Man skal ikke forvente at være udlært herefter :-( Man vil støde på det senere i forløbene på AAU :-) 3
Dagens tekst Objekter, UML og Programmering Dagens mål: Introduktion til selve processen i SW udvikling Den basale UML drevne udviklingsprocess Aktiviteter i forbindelse med OO udvikling Rational Rose's objectory process - et eksempel Lidt om værktøjer: compilers,... For nogle er det her nyt, andre har haft det i forvejen ;-) 4
Problemet UML er blot en grafisk representationsmetode med en række anvendelsesregler Sige INTET om hvordan forløbet fra start til slut - også kaldet processen er. UML i sig selv er ikke en kvalitet Gælder også for andre representationsmetoder Det væsentligste er Processen - som også er det sværeste Har principielt INTET med programmeringssprog at gøre C, java, C++, C#, ADA,asm,... - nogle er nemmere end andre :-) 5
Processen I Processen: Hvad der skal gøres Hvornår Hvorfor! Resultat: Dokumentation!!!, programmer, en løsning :-) Modeller, beskrivelser, test specifikationer, accept kriterier,... Det er muligt til en vis grænse at dekomponere en proces Brugerinterviews, sub-system spec,.. Vi vil gerne have systematisk hjælp : metodik, tools, sprog,... 6
En proces Et problem har flere sider også SW udvikling Process Context problemdomæne område hvor processen kan bruges Process User guidelines for brug af aktuelle proces Process Steps beskrivelse af aktiviteter Process Evaluation Hvordan resultat debømmes (docs, progr) I det følgende gennemgås disse view angels på en Proces 7
Process Context / Problem Domain I hvilken sammenhæng kan denne proces metode bruges Eks: design af hjælpesystem i program mhp specifikke menuer En beskrivelse af problemdomænet (lyder det bekendt?) Hvad er problem område, hvad skal der løses af problemet Indflydelse på organisation, humans, maskineri, økonomi,... Omfatter derforogså bløde områder: Effektivitetsforbedringer Beskrivende metaforer: organismer, maskiner, social...,kultur,... politik,...kontrol strukturer Meget svær at afgrænse hvor man starter og stopper... 8
Context II Er et område hvor man ofte skærer hjørner som programmør Er ofte det der afgører om det man laver er godt set fra kundens side!!! Skal ses i sammen med de andre (doch) og især Process Evaluation Problemet er at beskrive en arbejdsgang(process) for at udføre dette der giver et komplet resultat. (dagens opgave?!?!) 9
Process User / Guidelines of Use I hvilken sammenhæng skal denne proces-metode bruges Mamn skal forholde sig til brugerprofil(er)/roller og deres evner/viden/færdigheder Typiske handlemønstre (patterns) Etik 10
Process Steps / Problem formulering Løsningsdesign Implementationsdesign (implementation, test,...) 11
... Problem Formulation Forståelse for relevante område Diagnosen: hvad er problemet? Giv en prognose for problemløsning (hønen og ægget problem) Hvad, hvorfor og hvornår time is money Definer problemog stepvis problemløsning i konkrete termer Goals, subgoals, Dokumenter vha notationssystem(uml :-) Her ser man at UML er ikke noget i sig selv... 12
... Solution Design Conceptual/logical design Uden hensyntagen til de fysiske love - sådan da Her benyttes et model sprog (UML, petri-net,vhdl, CSP,...) UML er på mange måder et godt valg idet det er context fri. Physical design Environments, maskiner, betjening,... (bla rige tegninger) 13
... Implementation Design Detail design Programmering Overlevering til kunden Manualer osv... 14
... Process Evalutation Hvordan gik det? Forløb Produkt Kundens reaktion Svarer det til hvad der var lagt op til?... 15
!!!! Kun een bullet hvor der stod programmering (slide 17) Det går nemt op i hat og briller ISO 9000 framework for dette her USA mil standard DOD-178 (frit efter hukommelsen) En god programmør laver her << 100 liner kode/dag Men der er ingen vej udenom hvis Det kan vedligeholdes og man er flere end sig selv At man kan overleve at mødes i sø og handelsretten Indenfor maritim verden lever systemer ofte 10-25 år!!! (SW fra 1978 skal vedligeholdes) Jeg har kommerciel SW i drift fra ca 1988 16
Basal UML Use-Case-Driven Models Requirements Use Cases Analysis Design Impl Test Component View Deployment View Use-Case View Logical View Concurrency View 17
2 B continued Det her kommer i mere detalie de næste gange... 18
Kort om Use-Case-Views På en måde kontrakten imellem bruger og leverandør Skitser typiske situationer/hændelser - over tid Er ligesom basis i hele OO metodikken Håndterer ikke petitesse situationer (som at slå landekoder fra i dvd player ;-) Prøver at beskrive brugen gennem en slags rollespil hvor aktører både kan være bruger og SW moduler. Lægger op til den første intuitive modularisering ER BASIS FOR RESTEN... 19
Use-Case's placering Component View Logical View Use-Case View Deployment View Concurrency View 20
En meget lille Case? hvad er klokken? osv SW modul 444... regner... Så det er en hel dialog bog hvor det er hvad og IKKE hvordan 21
Traditionel OO metode Analyse model Design model Implementation model Deployment model Set lige før 22
Nogle analyse aktiviteter... kort... Domæne viden erkendelse alt lige fra brugere over funktionalitet over til HW Udarbejdelse af formal requirements. Er en væsentlig del af kontrakten i projektet, herunder især Use-Cases Forfinelse af ovenstående som fører frem til en mere formel system/adfærds specifikation manualer,... Klasse begreb som er gruppering/clustering af funktionalitet og information Klasse afhængighed, arvede egenskaber (klasse diagrammer),..... og herefter kommer collab diagrams,...... som kommer senere i kurset 23
Nogle design aktiviteter Parallellitets vurdering eks flertrådet server/os Detail design af information (datastrukturer) Exceptions/fejlhåndtering ofte er det der kæden hoppper af (Gen)brug og design af standardkomponenter, biblioteker,... HUSK Sporbarhed Dokumentation som også er andet en rige tegninger/use Cases Enkelhed!!! og enkle interfaces/biblioteksfunktioner Og doku (til kode brug CVS,...) 24
Implemtation og test Nogle siger at kodning er for aber... NEJ Men man ser ofte programmer kodet af a... ;-) Smarte programmører (ofte set i C) vil gerne optimere gennem kodning -> ulæselige programmer Test er den anden side af implementation idet en test også ofte skal kodes Airbus case redundante systemer impl uaf i UK og Frankrig Skal selvfølgelig gennem samme tests Vil forhåbentlig ikke fejle de samme steder hvis design er OK!!! 25
Værktøjer Meget stor forskel i hvad man bruger GNU tools uden mus, ingen plastik Har kodet linux, o meget andet Høj produktivitet af den dygtige håndværker Integrerede tools Lauterbach, MS, borland, 4GL Har kodet W<xx>, og meget andet Høj produktivitet Nemmere at gå til Et spørgsmål om temperament men hold stilen... 26
Større projekter Management er næsten en større del end selve projektet ;-) Tools til Management Versionskontrol Dokumentation Builders Test!!... 27
SLUT eller næsten 28