Plattformer, utviklingsmiljøer og systemarkitektur jfr. Systemutvikling fra kjernen og ut, fra skallet og inn kapittel 3 Visjon På en enkel og effektiv måte kunne lage informasjonssystemer som er korrekte og pålitelige er lette å tilpasse nye behov I really hate this darn machine; I wish that they would sell it. It won't do what I want it to, but only what I tell it. - Programmer's Lament oppfattes som brukervennlige ivaretar behovene for sikkerhet og vern av data utnytter maskinvaren ikke har flaskehalser skalerer godt INF102-utvmiljø-1 INF102-utvmiljø-2 Noen definisjoner Plattform Den maskinvare (inklusive datanett) og programvare (utenom det aktuelle systemet) som må være tilstede for å kunne kjøre systemet Plattformen, utviklingset og systemet! inn ut Utviklingsmiljø Programvare som brukes under utvikling og vedlikehold av systemet Utviklings Informasjonssystem Bruker Arkitektur Oppdelingen av systemet i komponenter, samspill mellom komponenter, lokalisering av komponenter i et distribuert miljø. Plattform (programvare) Plattform (maskinvare) INF102-utvmiljø-3 INF102-utvmiljø-4
Hvordan håndtere kompleksitet Divide and conquer (splitt og behersk) Oppdelingsprinsipper o Ulike abstraksjonsnivåer o Ulike perspektiver o Modularisering horisontalt vertikalt (lagdeling) I praksis er disse tre aksene ikke uavhengig av Abstraksjon hverandre. Perspektiv Vi har nemlig arkitekturer, metoder og... Abstraksjon Abstrahere: Legge vekt på det vesentlige og se bort fra det uvesentlige Abstraksjoner må av og til konkretiseres, og da blir det før uvesentlige vesentlig Konkretiseringer kan være manuelle eller automatiske Et høynivå programmeringsspråk arbeider med abstraksjoner! Modularisering INF102-utvmiljø-5 INF102-utvmiljø-6 Perspektiv Modularisering Ta ett problem ad gangen, for eksempel Modell av interesseområdet Modularisering: Å dele opp totalsystemet i et antall samarbeidende programkomponenter (moduler) Utforming av brukergrensesnittet Hvordan gjøre dataene permanente Fordeling av programmene på flere maskiner i et nett Ansvarsforhold i organisasjonen Samarbeidet kan være o mellom likeverdige moduler (horisontal modularisering) o mellom over/underordnede moduler (vertikal modularisering, lagdeling se neste lysark) Samarbeidet bør skje gjennom veldefinerte grensesnitt (OBS: Standarder!) En modul bør ha o sterk kohesjon o svak kobling med andre moduler INF102-utvmiljø-7 INF102-utvmiljø-8
Lagdeling Kompleks programvare bygges gjerne opp i såkalte lag Figur 3-8. En trelags-arkitektur for et informasjonssystem Et bestemt lag benytter tjenester i laget under seg, og yter tjenester til laget over seg En modul skal ligge i kun ett lag Brukergrensesnitt! inn ut En modul skal ikke uoppfordret henvende seg til et overliggende lag Et modul i et overliggende lag o kjenner ikke til innmaten i tjenestene i det underliggende laget o vet bare hvordan tjenesten skal anropes, og hvilket resultat som kan forventes o kan stille krav til tjenestens kvalitet (hvor rask, hvor pålitelig, ) Kjør meg til Ifi! Utviklings Applikasjon Virkelighetsmodell Plattform (programvare) Plattform (maskinvare) Bruker INF102-utvmiljø-9 INF102-utvmiljø-10 Application Programming Interfaces -APIer Informasjonssystemets programmoduler Rutiner fra utviklingsmiljøets bibliotek Databasehåndteringssystem Operativsystem, datanettprogramvare Maskinvare og datanett jf. figur 3-1 API API // Et eksempel på bruk av Java APIet System.out.println( Hallo! ); API Informasjonssystem Plattform programvare Plattform maskinvare Typer av standarder de jure Vedtatt av offisielle standardiseringsorganer o ISO International Organization for Standardization o CEN Comité Européen de Normalisation de facto Allment akseptert, gjennom enighet eller markedstyngde o åpne dokumentasjon offentlig tilgjengelig o lukkede Standardiserte APIer er viktig for portabiliteten! INF102-utvmiljø-11 INF102-utvmiljø-12
Standardiseringsaktørene Internasjonale, offisielle standardiseringsorganisasjoner o ISO International Organization for Standardization www.iso.org o CEN Comité Européen de Normalisation Ideelle organisasjoner o W3C World Wide Web Consortium o Object Management Group o Object Data Management Group o Open Source o Apache Toneangivende produsenter/leverandører o Microsoft o Sun o IBM o Oracle Noen av de viktigste listen er ikke uttømmende! www.cenorm.be www.w3.org www.omg.org www.odmg.org www.opensource.org www.apache.org www.microsoft.com www.sun.com www.ibm.com www.oracle.com Utviklingsmiljø: Et programsystem som bl.a. Utviklingsmiljøer hjelper systemutvikleren med å holde orden på programtekster, kompilerte programmer og testdata forenkler innlegging av kall til rutiner i APIet forenkler kall på kompilator og kjøring av systemet kan generere deler av programkoden ut fra mer abstrakte beskrivelser av systemet INF102-utvmiljø-13 INF102-utvmiljø-14 Figur 3-6. Eksempel et enkelt utviklingsmiljø for Java Mer abstrakte beskrivelser alternativer til programtekst Eksempler: Opptegning av skjermbilde Veivisere med utfyllingsfelter Grafiske modeller (UML, ) OMG arbeider med OMG Model Driven Architecture MDA se http://www.omg.org/mda/ INF102-utvmiljø-15 INF102-utvmiljø-16
Opptegning av skjermbilde Visual J++ Veiviser med utfyllingsfelter MS Access INF102-utvmiljø-17 INF102-utvmiljø-18 Grafiske modeller Figur 3-7. Generell arkitektur for et utviklingsmiljø TAU UML Modelator Upper-CASE Repository, Utviklingsdatabase Lower-CASE Reverseengineering Dokumentasjon Brukersystem INF102-utvmiljø-19 INF102-utvmiljø-20
Hva er CASE? Computer-aided software/system engineering: Systemutvikling med støtte av data som er spesielt tilpasset utvikling og vedlikehold av informasjonssystemer Eller kort og godt: Datastøttet systemutvikling CASE-et har bl.a. følgende funksjonalitet: Fem krav til CASE- 1. Verktøyet må kunne generere mest mulig av systemet fullautomatisk 2. Verktøyet må passe til den oppgaven som skal løses 3. Verktøyet må være en behagelig samarbeidspartner 4. Verktøyet må være basert på aksepterte standarder 5. Bruken må lønne seg! Tar i mot beskrivelser av systemet i form av modeller og tekster Kontrollerer modellenes innbyrdes konsistens Genererer programtekster ut fra modellene INF102-utvmiljø-21 INF102-utvmiljø-22 1. Verktøyet må kunne generere mest mulig av systemet fullautomatisk Verktøy må dekke både nyutvikling og vedlikehold billig produksjon av feilfrie systemer enkel tilpasning av systemet til nye/endrede krav fra omgivelsene større muligheter for prøving og feiling muligheter for prototyping ingen vil fôre et system med opplysninger bare for dokumentasjonens skyld systemet stemmer med dokumentasjonen Nyutvikling Vedlikehold: Tilpassing til til nye nyebehov Tilpassing til til nye nyerammer Retting av av feil feil Mesteparten av ressursene brukes til vedlikehold og tilpassing av eksisterende systemer. Gjenbruk vil bidra til å forsterke denne situasjonen. Kostnadseffektive må derfor dekke både nyutvikling og vedlikehold! INF102-utvmiljø-23 INF102-utvmiljø-24
Systemgenerering Manuelle endringer Lower-CASE Programtekst kompilatorer o.l. Effektivt vedlikehold krever oppdaterte beskrivelser Den eneste realistiske måten å sikre at beskrivelsene stemmer med systemet, er å generere systemet fra beskrivelsene! Men Reverse engineering er en nødhjelp... databasehåndteringssystem operativsystem INF102-utvmiljø-25 INF102-utvmiljø-26 «Reverse Engineering» 2. Verktøyet må passe til oppgaven Her har vi et CASE- har vi noe å bruke det til? Repository, Utviklingsdatabase Brukersystem Reverseengineering Repository, Utviklingsdatabase Brukersystem Gjenvinning av utviklingsdatabasen fra brukersystemet Ambisiøst foretagende! Fullautomatisering i praksis umulig INF102-utvmiljø-27 INF102-utvmiljø-28
Bredde, metodestyrke eller begge deler? Geni Metodestyrke Teknikkorienterte Sterkt metodeorienterte 3. Verktøyet må være en behagelig samarbeidspartner en ved spaken Riktig arbeidsfordeling Verktøyets kontrollfunksjoner må kunne styres Godt brukergrensesnitt Generelle med liten "intelligens" Metoden Hvem skal kunne Metoden? Treskalle Fagidiot Tegne Generalist Faglig bredde CASE-Verktøy INF102-utvmiljø-29 INF102-utvmiljø-30 Standard modellbeskrivelser 4. Verktøyet må være basert på aksepterte standarder Upper-CASE Standard modellrepresentasjoner Repository, Utviklingsdatabase Lower-CASE Nytte Billigere systemproduksjon Billigere vedlikehold Mer tilpasningsdyktige systemer Muligheter for gjenbruk 5. Det må lønne seg! Kostnader Verktøyet Maskinen Databaser osv. Opplæring, tilvenning Reverseengineering Dokumentasjon Brukersystem Designware standard APIer, standard GUI INF102-utvmiljø-31 INF102-utvmiljø-32