Chapter 13: Designing applications

LÆRINGSMÅL:

• Kan bruke verb/substantiv metoden til å finne ut
• Hvilke klasser du trenger for å løse et problem og hvilke metoder klassene skal ha
• Kan bruke scenarier (evt. med CRC kort) til å sjekke at du har funnet klassene og metodene du trenger
• Vet hva et design pattern er

VERB/SUBSTANTIV – METODE:

I virkelighetens liv er det vanskelig å finne ut av hvilke klasser vi trenger for å lage et prosjekt. Trinnene som brukes for å laget er Software-system kalles for analyse og design. Mer forklarende analyserer vi problemet, og designer en løsning.

Men for å kunne lage et Software-system må vi finne ut av hvilke klasser vi trenger, og hva klassene må inneholde for å kunne løse vårt problem.

For å oppdage og finne klasser, bruker vi verb-subjektiv-metoden. Deretter bruker vi noe som kalles for CRC-kort for å utføre designet.

Ved å ta i bruk kjennbare definisjoner som verb og substantiv ser vi at vi kan få hjelp til å løse programmeringsproblemet.

I en skildring av Software-programmet vil subjektivene referere til klasser og objekter, mens verbene vil referere til objektenes metoder (handlinger).

Her er en forklaring av et av mine prosjekt, som er et parkeringssystem:

Parkeringssystemet kan brukes i flere systemer og sammenhenger.  En bil skal kunne sjekkes inn i dette systemet. Hvert parkeringssystem har et sett med parkeringsplasser som er organisert etter felt- og plassnummer. Kunden kan parkere sin bil på flere selvvalgte og ledige parkeringsplasser.

Det som primært blir brukt som informasjonskapsel er kundens skiltnummer, men flere parameter må legges inn: bilmerke, bilmodell, farge, skiltnummer.

Parkeringsplassen skal være synlig – og en skal også har muligheten til å se om plassen allerede er reservert eller eid av en kunde. Når det er ønskelig skal kunden ha muligheten til å fjerne sin bil fra plassen, og sjekke ut av den.

Deretter må vi sortere verbene og subjektivene i klasser for seg selv.

VERB:                                                                          SUBJEKTIV:

Parkere                                                                       Parkeringssystem

Reservere                                                                   Bil

Eie                                                                               Parkeringsplasser

Fjerne                                                                         Plassnummer

Sjekke ut                                                                    Kunde

Skiltnummer

Bilmerke

Bilmodell

Farge

Det vil se ut som om vi har mange kandidater for klasser og metoder. Foreløpig bruker vi alle, og ekskluderer ikke noen kandidater. Akkurat nå er vi i en tidlig fase av utviklingen, og vi vet ikke hva vi har bruk for, og hva vi ikke har bruk for.

CRC-KORT og SCENARIOER:

Neste punkt er å ta i bruk CRC-kort. Disse kortene skal hjelpe oss med å  lage interaksjoner og forbindelser mellom klasser.

Det beste er å lage fysiske kort, og ikke lage illustrasjoner på PC  eller tegne useriøse tegninger på ark når du skal bruke CRC-kort.

Strukturen er følgende:

Tre ruter i ett kort; et areal i øverste, venstre rute som inneholder class name; et areal under første areal som inneholder responsibilities; en rute på høyre side langs rute én og to som inneholder collaborations (classer som denne bruker);

En ting som også er sentral i modul 5 er scenarioer. Et scenario er et eksempel på en oppgave som systemet skal kunne takle.

For eksempel:

En kunde sjekker bilen inn på parkeringssystemet, og finner en ledig plass. Kunden ser at plassen ikke eies av noen, men at den er reservert til en annen kunde. Kunden kjører videre til h*n finner en ledig plass.

Vi spør oss selv følgende: Hvordan kan du løse dette problemet?

Vi kan tenke slik: Det er i klassen ParkeringsSystem hele handlinger primært foregår. Før vi kan sjekke inn en bil er det viktig å lage et bil-objekt ut i fra klasse Bil: her legger vi inn nødvendige parameter. Når bilen da skal sjekkes inn, velger vi hvilken parkeringsplass bil-objektet skal plasseres på i klasse plass. Deretter får vi beskjed om at plassen i klasse plass er opptatt: dette kom fram ved å sammenlikne skiltnummeret til bi l- objektet og skiltnummeret som var lagret i plassen. Bilen går videre og finner en ledig plass.

Slike brukerscenarioer er vanlig å gjøre sammen i grupper, og hvert medlem har en egen «klasse», og forteller høyt hva den gjør, hva den mangler og hva den burde ha med.

Å lage scenarioer tar ofte veldig lang tid, men en får igjen for det.

Som nybegynner er det viktig at jeg tar meg tid til å fullføre og øve meg på slike scenarioer, og også se på hver eneste detalj – uansett om jeg mener den er viktig eller ikke.

Neste fase er å gå fra CRC-kort og scenario til å designe Java-klassene

Jeg har nå tre klasser som jeg bruker: ParkeringSystem, Plass og Bil. Hver av disse inneholder constructors, metoder, og felt.  Å bruke CRC-kortene en gang til vil være til hjelp – denne gangen kan du spesifisere litt mer hva klassen skal inneholde, og så skrive det litt mer nøyaktig og etter programmerings-skikk. Dette vil føre til at du vil ha en mindre jobb å gjøre når disse klassene skal skrives i Java. På denne måten kan du tidlig unngå unødvendige feil.

DESIGN PATTERN:

Et design pattern er en beskrivelse av et felles eller gjentatt problem som ofte oppstår under programmering, og en beskrivelse av en løsning på dette problemet. Løsningen kan ofte brukes på flere forskjellige måter.

Løsningen er ofte beskrevet i en liten sammensetning av klasser og deres interaksjoner.

Design pattern dokumenterer for gode løsninger for problemer, så disse kan bli gjenbrukt av andre.

Design pattern har også egne navn slik at det ikke er vanskelig å bruke eller snakke om det.
Disse patterns er vanligvis laget slik at de inneholder et minimun-set av informasjon. Ikke bare om struktur av klasser, men også informasjon om problemet som blir adressert

En forklaring av patterns inneholder som oftest:

• Et navn som kan bli brukt for å snakke om patternet.  For eksempel: Singleton
• Et problem som patternet adresserer for. Dette er ofte delt opp i mindre seksjoner som: hensikt, motivasjon og egnethet.
• En forklaring på løsningen. Ofte listet opp i struktur, deltakere og samarbeid.
• Konsekvenser av å bruke patternet, inkludert resultater og kompromisser.

Link til modul 3: https://screencast.uninett.no/relay/student/tanjam14uia.no/2014/30.10/529600/Modul3_-_20141030_174115_36.html

Dette er det sammenlagte konseptet i kurset IS-109 som baserer seg på objektorienert programmering. I det følgende skal jeg fortelle litt om læringsmålene som er:

Å åpne, lagre og lukke prosjekter.
Lage objekter.
Kalle metoder i objektene, med og uten parametere.
Bruke editoren til å se på kildekoden til en klasse.
Kompilere et prosjekt. 

Jeg skal også kunne litt grunnleggende i java, som er følgende:
Kjenne igjen en klassedefinisjon.
Kjenne til forskjellige typer data.
Kalle metoder med et objekt som parameter.
Kalle metoder som returnerer en verdi.
Forskjellen mellom klasse og objekt. 

Jeg kan starte denne framføringen med å vise hvordan vi åpnerer, lagrer og lukker prosjekter. Du vil kjenne igjen framgangsåten fra tidligere erfaringer. I BlueJ klikker man på «Project», deretter klikker man må på «Open Project», og velger da hvilket prosjekt du ønsker å åpne. Når du skal lagre dette prosjektet klikker du igjen på «Project», og klikka da på «Save As», angir navn, og trykker på lagre. Skal du lukke dette prosjektet må du klikke på det røde krysset i høyre hjørne. 

Etter at du har åpnet dette prosjektet, ser du at at det finnes noen ruter på skjermen. Dette er klasser. Tar du pilen over denne klassen og høyreklikker, ser du at du får en mulighet til å lage noe som klasses for et objekt. Objektene vises fram i nedre firkant på BlueJ. Objektene representerer indiviuelle instanser fra en klasse. Det vil si at en klasse også kan defineres som en gruppe. Objektene er selve individene i klassen, og disse objektene kan få egne metoder og egenskaper. Eksempel: Du kan en klasse for bil -> Du lager flere forskjellige objekter som representerer forskjellige typer biler. 

Du kan kalle på metodene på forskjellige måter. Når du høyreklikker på objektet får du opp flere forskjellige muligheter. Når du kaller på en metode uten å måtte oppgi informasjon kaller du på en metode uten parametere, metoder der det er nøveding med informasjon for å kunne gjøre noe kalles metoder med parameteren.
En parameter lagrer informasjon om. 

Ved å dobbeltklikke på en klasse kan du komme til noe som kalles for kildekode. Her kan du se hvordan klassen er bygget opp, og hvilke egenskaper den har. Den øverste grønne delen gir oss litt informasjonon om klassen. Videre har du konstruktører som lager metoder og liknende. Den øverste delen, altså overskriften til en metode kalles for en sigratur. Her står det litt informasjon som er nødvendig for å kunne kalle på en metode. 

Helt i starten av kildekoden står det public class «...», her er en liten klassedefinisjon som gir opplysninger om hva denne klassen inneholder. 

Du har sikkert lagt merke til at du har muligheten til å trykke på «compile». Det betyr at du kan kompilerer prosjektet. Det betyr kort fortalt at du oversetter prosjektet fra Java-språk til PC-språk. En PC forstår ikke java, ettersom den benytter seg av et langt mer komplisert språk. Å kompilerer gjør det mulig å la PC-en forså prosjektet. Hver gang du gjør en endring på prosjektet må du kompliere før du kjører det. 

I java finnes det også flerer forskjellige typer data. De to typene vi blir berørt av hyppigst i modul 1 er typene String og int. String er en type som lagrer tektst. Å bruke String riktig vil si at du må skrive ordet/teksten med en stor forbokstav, og du må også da ha anførselstegnt både før og etter ordet/teksten. Int er en forkortelse for integer, og denne typen lagrer tall. Her er det ikke noen krav om anførselstegn. 

Når du kaller metoder er det også mulig å kalle metoder som returnerer verdi. Om en metode returnerer eller ikke returnerer verdi er spesifisert i signaturen til en metode. Står det for eksempel «String» foran så returnerer den verdi. Void returnerer ingen verdi. 

Dette er et sammendrag i kapittel to i læreboka som handler om modul 2. Vi skal nå gå litt vekk fra det grunnleggende, og vil gå dypere inn på kildekoden til moduler og programmering. I dette sammendraget skal jeg kunne om navn på klasser, hvilke felt de har og hvilke typer de har, og også forteller om hvilke metoder den har og hva metodene heter. Jeg skal beskrive parametere – med navn og type, og returverdi for alle metoder.  I Java skal jeg kunne forskjelen på forskjellige metoder: constructors, getter og setters. Jeg skal også vite hva de brukes til. Videre skal jeg kunne skrive en klassedefinisjon med felt og metoder i riktig rekkefølge og med metoder som bruker tilordning, if-setninger og utskrifter. 

Selve teksten til klassen kan du dele opp i to hoveddeler: outer-wrapping (class-header) som definerer kalssen, og inner-part som gjør selve kodearbeidet. Eks:

 Outer-wrapping --> public class TicketMachine {
                                                                                --->  Inner-part(kode) of the class
                                                                                         }

Klassenavn starter alltid med stor forbokstav. 

Feltene lagrer data inni et objekt, samtidig som konstruktøren er ansvalig for å sikre at et object er satt opp riktig når det ført er opprettet. Metodene implementerer oppførselen til et objekt: det danner det funskjonalitet. Eks:

public class Klassenavn
{
- Felt
- Konstruktør
- Metode
}

Når vi definerer felt-variabler i classer så vet vi at de:
Vanligvis starter med order «private».
De har inkludert en type «int/String/Person etc.»
De har inkludert et bruker-valgt navn for felt-variablen.
De slutter med semikolon.

Konstruktører lar bojekter bli satt opp riktig, og sørger for at objektet er klart til å blu brukt. Konstruktøren har det samme navnet som klassen de er definert i, i dette tilfellet: TicketMachine. Konstruktørens navn kommer etter ordet «public», uten annet innhold.
Vi burde forvente en nær sammenheng mellom det som skjer i «bodyen» i en konstruktør og i klassen sitt felt.
Parametere er som tidligere nevnt også en type felt som lagrer data. Eks: public Ticketmachine (int cost) = parameteret er cost av type int(integer). En parameter er også brukt som en kort og midlertidig beskjed. 

Å returnere en verdi betyr at en spesifisert type informasjon strømmer gjennom mellom to ulike deler av programmet. En del av programmet har etterspur informasjon om objektet via kalling av metoder, og den returnerte verdien er måten objektet gir over informasjonen tilbake til kalleren. 

Get-metoder returnerer verdi fra/til en av objektenes felt. 

Metoder som insertMoney og printTicket har en større rolle, først og fremst fordi de en drer verdien til en eller flere felt i objektet hver gang noen kaller på dem. Metoder som endrer «state of the object» kalles for mutator methods. 

Set-metoder tillater at objektet endrer «Sate of the object.»

I dette følgende skal jeg summere innholdet i kapittel tre. De seks viktigste punktene i dette kapitelet er: abstraksjon, modularisering, objekt-danning, objekt-diagram, metodekalling og debugging. 

Jo lenger ut i læreboka vi kommer, jo mer komplekse vil oppgavene bli. Derfor er det et pluss hvis en kan håndtere disse komplekse oppdavene del for del. 

Abstraksjon handler om å dele komplekse problemer inn i sub-problemer, og så dele sub-problemer inn i sub-sub-problemer. Hvis det er nødvendig kan du videre dele problemene inn i mindre problemer. Dette gjøres for å dele problemene inn i så små delere at de er lette å håndteres med. Når vi har løst ett av sub-problemene dveler vi ikke lenger ved dét problemer, men bruker denne løsningen som en blokk videre.
Denne teknikken kalles ofte for "divide and conquere". 

Modularisering er å dele problemet inn i selsvendige moduler/individer, for så å sette ulike personer til å løse og arbeide med de ulike modulene/individer. Deretter settes disse sammen igjen til en helhet. 

Modularisering og abstraksjon fullfører hverandre. Modularisering er prosessen der du deler store problemer inn i mindre deler, mens abstraksjon er evnen til å ignorere detaljer for å fokuserer på det større bildet. 

Vi kan lage flere objekter fra samme klasse. Klassediagram viser statisk tilstand. Objektdiagram viser den dynamiske tilstanden. Objektidiagrammet viser en viktig ting: Når en variabel er lagret i et objekt, er ikke objektet lagret direkte i variablen, men heller objektreferance. I et diagram er variablen vist i en hvit boks, mens objektet vises i en egen rute med referansebil. 

--------------------------------------------------------------------------------------------------------------------
Logic operators operate on boolean values(true or false) and produce a new boolean value as a result. The tree most important logical operators are and, or and not. They are written in Java as:

&& (and)
|| (or)
! (not)

The expression: a &&(and) b = Is true if both a and b are true, and false in all other cases.
The expression: a ||(or) b = Is true if either a or b or both are true, and false if they are both false.
The expression: !(not)a = Is true if a is false and false is a is true.
--------------------------------------------------------------------------------------------------------------------

The modulo operator(%).
Modulo operatøren beregner resten av et heltall dividert. For eksempel resultatet av divisjonen:
27/6
kan uttrykkes i heltallsantall som
result = 6, remainder = 3 

Modulo-operatøren returnerer bare den resterende del av en slik inndeling. Således, ville resultatet av uttrykket (27% 4) være 3.

Kilden jeg har brukt er boka «Objects First with Java» av David J. Barnes og Michael Kölling.

Har vært dårlig med blogging på denne siden – har måtte prioritere andre kurs og oppgaver.

Status for denne uken er: Godt begynt på modul 3, regner med å være ferdig i løpet av neste uke.

Plan videre: Jobbe med modul 3, og sørge for at jeg kan kapittel 3 godt før jeg starter på kapittel 4.

I uke 37 jobbet jeg med å lese meg gjennom kapittel 3 i læreboka, samt å plukke opp viktige stikkord, definisjoner etc.

Denne uka har jeg jobbet med akkurat det samme. I løpet av uka skal jeg begynne på det praktiske i modulen og skrive den ned!

I uke 36 ble jeg ferdig med modul to, jeg har enda ikke fått  første og andre modul godkjent, men skal nå avtale møte med min hjelpelærer slik at jeg kan få de godkjent i løpet av uke 38. Nå har jeg lært meg hvordan man skriver metoder og lager objekter og klasser. Det var veldig spennende og gøy å faktisk få laget noe selv!

I denne uka (37) har jeg begynt på modul tre. Merker dette kapittelet er litt vanskeligere enn de to forrige! Til nå har jeg lært meg litt om abstraksjon, modularisering, primitive typer og objektive typer. Jeg har også sett litt på prosjektene som ligger i tredje kapittel, men vil ikke gjøre noe selv før jeg kan teorien godt nok.

I uke 35 jobbet jeg med førte kapittel i læreboka. Jeg har gått gjennom alle oppgavene i kapittelet, og har laget tankekart med relevante begreper og uttrykk som blir tatt opp.

Jeg har lært meg det grunnleggende i BlueJ -> Hvordan man åpner og lukker prosjekter, forskjellen på klasse og objekt, hva parametere er, skille mellom ulike typer data og returnering av verdi.  Jeg har fullført første modul som snart skal inn til godkjenning.

Videre har jeg allerede begynt på kapittel to og skal arbeide med andre modul.

Så langt har det gått smertefritt, men jeg er forberedt på komplikasjoner og frustrasjonen som garanter kommer til å ta meg igjen senere i kurset. 🙂

Hei!

Jeg går første året på UiA – fakultetet for samfunnsvitenskap – hvor jeg studerer bachelor i IT- og informasjonssystemer. Jeg har dermed fått i oppgave å poste ukentlige innlegg på denne læringsbloggen. Bloggen brukes i kurset IS – 109 – 1: Objektorientert programmering 1, og skal også brukes i kurset IS-100 – 1: Introduksjoner til informasjonssystemer.

Studiet går over tre år, og etter planen skal jeg være uteksaminert våren 2017.

Ønsker du å lese mer om studiet kan du gjøre det her: http://old.uia.no/portaler/student/studierelatert/studiehaandbok/14-15/it_og_informasjonssystemer_bachelorprogram