Uppgift 1 Ett programmeringsparadigm är i grund och botten ett sätt att arbeta, ett sätt att möta problem. Det finns flera olika paradigm där varje paradigm har sina egna styrkor och svagheter. Det som huvudsakligen kännetecknar ett programmeringsparadigm är hur koden struktureras och skrivs. Som jag har skrivit tidigare är alltså ett paradigm ett tillvägagångssätt, ett sätt att strukturera ett program, ett sätt att möta ett problem och till slut lösa detta. Värt att nämna är att olika problem ställer olika krav på utvecklaren, utvecklaren bör således välja ett paradigm lämpat för problemets domän. Vid val av programmeringsparadigm måste programmeraren veta vilket problem som skall lösas. När detta är klart kan denne fråga sig vilket verktyg och tillvägagångssätt som är bäst för att lösa problemet. För ett mindre problem skulle det procedurella paradigmet kunna vara lämpligt, för ett större projekt där detsutom flera utvecklare ansvarar för skapandet projektet bör med största sannolikhet det objektorienterade paradigmet väljas. Det procedurella paradigmet kännetecknas huvudsakligen av att dela upp problem i mindre delproblem, fokusera på problemet och skapa en effektiv problemlösnings strategi. Ett stort problem delas ner i mindre problem som tillsammans kan lösa det stora problemet utvecklaren har ställts inför. I procedurell programmering arbetar man med ett tydligt hurperspektiv, hur ska problemet angripas och hur ska det lösas. Med hjälp av funktioner och procedurer kan utvecklaren effektivt att dela upp olika delproblem i mindre segment som tillsammans löser det stora problemet. Approachen som används vid procedurell programmering kalls för 'Top down' - approach. Det procedurella paradigmet har precis som andra paradigm ett antal styrkor och brister. Det jag anser är fördelar med paradigmet är följande: +Återanvändbar kod Kod som har skrivits tidigare går att använda i andra program med enkelhet. Procedurella program delas upp i delprogram, dessa kodsegment går ofta att implementera i andra projekt, ibland utan större modifiering. Om en utvecklare till exempel behöver en funktion som sorterar en array med 100 värden skulle en sorteringsalgoritm kunna kopieras över från ett existerande projekt till det nya projektet. +Bra kontroll på kodflödet Det går med lätthet att hålla bra koll på kodflödet i procedurella program. +Enkel felsökning Felsökning sker enkelt i det procedurella paradigmet. Programkoden är uppdelad i delar som var för sig ansvarar för delproblem. Om något i dessa delproblem(funktioner/procedurer) inte skulle fungera som det är tänkt går det snabbt och enkelt att identifiera var den felande länken finns och där efter åtgärda dem. +Överskådlighet Normalt sätt blir ett program skrivet i det procedurella paradigmet överskådligt. Modifikationer på delproblem kan ske med lätthet. +Lättförståeligt Går med enkelhet att sätta sig in i vad programmet gör och vilket problem det förväntas att göra. -Lämpar sig inte för större projekt När en utvecklare behöver utveckla ett större projekt lämpar sig inte detta paradigmet. Större möjlighet till struktur krävs för att utvecklaren på ett effektivt sätt skall kunna ta sig an problemet som denne har ställts inför. -Brist på struktur Med detta menar jag främst avsaknaden av klasser och objekt. Skall en programmerare till exempel med programkod representera tre hus, dessa hus har fyra fönster, två dörrar och två våningar. Dessa egenskaper skall beskrivas. Hade programmeraren valt det objektorienterade paradigmet hade dessa egenskaper kunna definieras genom tre objekt som är instanser av en klass med dessa attribut. I det procedurella paradigmet skulle programmeraren vara tvungen att deklarera variabler för varje hus och dess egenskaper. Detta skulle direkt medföra mycket mer kod, större yta att göra del och mindre kontroll. Det objektorienterade paradigmet består av olika objekt som tillsammans bildar ett funktionellt program. De olika objekten byggs upp med hjälp av klasser. De olika klasserna interagerar med varandra för att utgöra den funktionalitet som önskas av utvecklaren / användaren. I det objektorienterade paradigmet arbetar man med en 'bottom up' approach, att med hjälp av objekt tillsammans bygga upp ett fullständigt program. Man måste tydligt fråga sig själv Vad ska vi lösa när det kommer till objektorienterad programmering. +Struktur Programkoden kan struktureras upp på ett effektivt och logiskt sätt. Med hjälp av klasser kan programmeraren lätt strukturera upp programmet på ett effektivt sätt. Strukturen inom detta paradigmet står i tydlig kontrast mot det procedurella paradigmet där klasser inte existerar enligt paradigmets regler och riktlinjer. Om en programmerare skulle vilja ha två ett spel med två tärningar skulle båda dessa tärningars egenskaper behöva definieras två gånger med det procedurella paradigmet medans man bara skulle behöva göra det en gång med det objektorienterade paradigmet. -Komplexitet. Programmets komplexitet ökar med det objektorienterade paradigmet. Det kan vara svårare att få en helt överskådlig blick över programkoden. Med införandet av klasser och objekt sker givetvis en komplexifiering av programkoden. -Klassehierarkier kan bli väldigt stora Klasshierarkier kan bli väldigt stora och beroende av varandra. Således kan det bli väldigt svårt att hitta fel i koden och ställa dem till rätta.
Det deklarativa paradigmet har en tydlig vad-approach, vad skall utföras. Detta används tex inom databas programmering. Till exempel, vad skall utföras? Hämta data från en tabell sorterat efter ett ID-nummer. Ett antal sanningar deklareras om problemdomänen, en mekanism tar emot förfrågningar om problemdomänen och beräknar svar på dessa frågor. Deklarationer byggda på logik används, som visar resultat på en funktion, inte hur det ska utföras. -Inte möjligt på samma sätt att definiera funktioner. -Brister i funktiondefinition. +Bra i databas-sammanhang. +Tydlig vad approach för problemhantering. +Vad som förväntas av en funktion, inte hur. Två språk som associeras med det procedurella paradigmet: BASIC och C. F, De tre olika konstruktionerna sekvens, selektion och iteration är byggstenar som frekvent används inom programmering. Det är dessa som huvudsakligen gör det möjligt att programmera och är således vitala för ett procedurellt programmeringsspråk(och andra paradigm för den delen). En sekvens är en steg för steg operation, att man metodiskt går igenom programkoden. Man skulle kunna beskriva en sekvens som en serie instruktioner som utförs en efter en. Selektion innebär att man gör vägval i programmet, tex, om värde 1 är större än 0 skall programmet utföra en viss algoritm, i annat fall skall programmet utföra något annat. Selektion är en väldigt viktig byggsten i programmering, oavsett vilket paradigm det gäller. Det är med hjälp av selektion vi gör våra vägval i programmet. I vissa fall vill vi att ett stycke kod skall upprepas ett visst antal gånger. Det är i detta skedet iteration kommer till användning. Det innebär helt enkelt att programmet upprepar ett visst antal gånger beroende på användarens krav som kommer att evalueras. 2, Analys, i den här fasen fastställs det vilket problem det är som skall lösas. Vilken funktionalitet programmet skall ha. De dolda antaganden som finns i programmet specificeras här. Det är i det här skedet som en kravspecifikation för projektet tas fram. Dolda antaganden, problem som ska lösas, krav från kundens sida, vad finns det för lösning på problemet, vilken input kommer programmet att få och slutligen vilken output kommer programmet att ha. Design, i det här skedet tas en systembeskrivning fram. Vilken plattform skall mjukvaran köras på, algoritmer som skall användas, vilket programmeringsspråk skall användas, vilka delsystem. Vad behövs och hur skall detta utföras? Allt detta sammantaget skall resultera i en systembeskrivning. Implementation, i detta skedet sker själva programmeringen av mjukvaran. Ut efter systembeskrivningen och kravspecifikationen är det programmeraren / programmerarnas uppgift att utveckla mjukvara som uppfyller de krav och specifikationer som har satts i tidigare skeden. Efter att denna fasen avslutas skall det finnas programkod och eventuellt testprotokoll. Testing, i det här skedet kompileras programmet och testas. Debugging kan även ske i den här fasen. Har allt skett godtyckligt är utvecklingen i stort sätt färdig. Betalning sker. Resultat från den här fasen skall vara ett testprotokoll. Kund får godkänna programmet. De moment som ingår i designfasen är analysera problemet som utvecklaren har ställts inför och hur dessa skall lösas. Identifiera delproblem Vilka delproblem existerar och måste lösas? Detta är en fråga som en utvecklare måste ställa sig själv för att kunna lösa det befintliga problemet. Den här punkten kan likställas med att identifiera de punkter som måste finnas till hands för att programmet i helhet ska kunna fungera önskvärt. I den här fasen identifieras de olika delproblemen som existerar och krav specificeras. Identifiera vilken plattform mjukvaran skall köras på? Att veta vilken plattform mjukvaran förväntas användas på är av den yttersta vikten då vissa begränsningar kan existera hos olika typer av hårdvara samt inkompatibilitet mellan diverse operativsystem. Utan att veta detta skulle det över huvud taget inte gå att utveckla mjukvara på ett rimligt sätt. En bra liknelse är att bygga en bil för att köra på vatten. Vilket programmeringsspråk skall användas? Det här kan jämföras med att välja rätt verktyg för jobbet. Beroende på vilken uppgift man ställs inför bör rätt språk väljas. Åter igen kommer jag använda mig av en liknelse: man hamrar inte i en spik med en skruvmejsel. Det går, men det är inte effektivt. Den här punkten handlar om att välja det verktyg som lämpar sig bäst för jobbet. Vilka algoritmer kan / skall användas? Detta handlar om att välja lösningar i programkoden som är effektiva för ändamålet. Om tex en array med heltal behöver
sorteras är inte bubble-algoritmen den mest effektiva sorteringsalgoritmen tillgänglig. Som sagt, det handlar om att implementera det som är det bästa för problemet i sig. Arbetet i den här fasen skall resultera i en systembeskrivning där resultatet av de olika underpunkterna sammanställs som i sig innehåller svaret på de identifierade delproblemen, vilka systemkrav som existeras vad gällande plattform, vilket programmeringsspråk som skall användas samt användandet av algoritmer. Programmet ska vara väl strukturerat rent kodmässigt. Koden bör vara lättläst och enkel att jobba med. Med detta menar jag att utvecklaren i fråga använder sig av funktioner, procedurer och även klasser om paradigmet tillåter användandet av detta. Detta tillåter en bättre läsbarhet och förståelse av koden. Detta är fördelaktigt om man skall fortsätta utveckla ett program. Kod skall vara indenterad för att man lätt skall kunna läsa programkoden. Läsbarheten blir avsevärt försämrad ifall programmeraren inte använder sig av indentering. I de allra flesta fall helt oläslig. Detta leder givetvis till utvecklingen sker mindre effektivt i framtiden. Programkoden skall inte bestå av fulhack eller fulkod, detta försämrar för framtida utvecklare av programmet. Koden skall vara lättläst, spaghettikod får inte existera då detta är i stort sätt omöjligt att arbeta med som ny programmerare i projektet. Skulle fulhack existera riskerar det även att försämra programmets pålitlighet då de inte alltid kan anses vara pålitliga. Koden bör vara väl dokumenterad och kommenterad för att man lätt skall kunna sätta sig in i vad aktuella algoritmer utför för funktion. Utan väl uppbygd dokumentation är det som utomstående svårt, om inte omöjligt att sätta sig in i en annan utvecklares tänk och sätt att bygga program. Om man är tvungen att arbeta med ett stort projekt och dokumentation inte finns tillgänglig kan det i värsta fall ta mer tid att sätta sig in i programmet än att skriva om det från scratch. Top down approach bygger på att man bryter ner problemet i mindre bitar som tillsammans möjliggör en lösning av problemet i fråga. Man bryter alltså ner ett problem i mindre delproblem tills det problemet löses av alla de mindre delprogrammen som representeras av funktioner och procedurer. Detta anses vara en effektiv problemslösningsstategi. Man har ett tydligt fokus på problemet i fråga. Den här approachen används flitigt inom det procedurella rogrammeringsparadigmet. Bottom up approach bygger på att man bygger upp ett större program av subsystem. Dessa subsystem kommer agera som delar av det stora programmet i helhet. Den här approachen används inom objektorienterad programmering. Skillnaden mellan dessa är att man i Top Down specifierar och identifierar de olika delproblemen som existerar och när detta är gjort kan arbetet att bygga programmet inledas. I Bottom up är det i stort sätt det motsatta. Man börjar i stort sätt direkt att börja bygga sina subsystem som tillsammans utgör det större programmet. I bottom up blir återanvändningen av kod bättre än i top down. Klasser går att återanvända i större utsträckning. Rapid prototyping innebär att man snabbt tar fram modeller för ett projekt och har en bra kontakt med kund. Man bör tidigt försöka påvisa för kunden vad som händer med projektet. Det kan lätt bli fel så att börja om kan lätt ske. Detta är dock något som ingår i modellen. Dock sker arbetet och modelleringen snabbt. Kontakten med kunden är viktigt då de är närvarande i framtagandet av modeller och avgör om dessa är godkända eller ej. 3 Det är viktigt att arbeta på ett strukturerat sätt för att ha bra koll på vad som sker i projektet och vad som behöver göras. Att arbeta från livscykelmodellen är av vikt. Att man först identifierar vilka krav som existerar, vad programvaran förväntas utföra, vilka delproblem som behöver lösas. Har man kommit underfund med det kan man skriva programmet på ett effektivt sätt. Problem kan lösas systematiskt. När detta väl har skett kommer arbetet att skötas mycket enklare. Har man dokumenterat projektet väl kommer man lätt kunna återgå till det ifall fel skulle uppstå och man kan ställa eventuella fel till rätta. Struktur är viktigt för att man som programmerare skall kunna jobba på ett effektivt sätt och producera korrekt och funktionell mjukvara. Detta innefattar även fall av debugging. Utan korrekt skriven mjukvara kommer processen att felsöka koden försvåras avsevärt. Syntaktiska fel innebär att något i programkoden är fel och programmet kan således inte kompileras. Det kan till exempel vara att en rad inte har blivit avslutat korrekt, eller att man helt enkelt har stavat fel vid något tillfälle. Exekveringsfel innebär att något går fel under programmets körning. Programmet kan tex försöka använda minne som inte tillhör programmet och ett segmenteringsfel uppstår.
Semantiska fel innebär att programmeraren har tänkt fel när programmet skrevs. Koden i sig kan vara rätt men utfallet blir helt fel vilket resulterar i att programmet inte fungerar önskvärt. Det kan till exempel vara fel i en uträkning av ett värde som genererar ett felaktigt resultat. Använder sig av metoden divide an conquer, i stort sätt eliminerar man tal som skiljer sig från det talet man letar efter. Man kollar först på talet som ligger i mitten av arrayen. Är det sökta talet mindre eliminerar man allt som är större än. Är det sökta talet större eliminerar man allt som är mindre. Är talet vi söker lika med talet i mitten av talserien har vi hittat det talet vi söker. På så sätt kan man söka igenom en talserie effektivt. Den här metoden är en väldigt effektiv sökmetod, dock förutsätter den att talföljden är sorterad. Genom att dela upp programkoden i funktioner kan man uppnå en större struktur av programmet. Denna struktur gör att man enklare kan utföra de delproblem som existerar. Det blir väldigt mycket enklare att arbeta om man vet att varje funktion fyller sin uppgift och gör det väl. Då kan man på ett effektivt strukturera upp programmet så det utför de steg man förväntar sig att det ska göra. Koden kommer även bli mycket renare om man väljer att använda sig av funktioner. Utan funktioner blir man tvungen att skriva sin kod i en enda stor härva. Denna härva kan lätt bli oöverskådlig, eventuella fel blir svåra att hitta så debugging kommer att ske ineffektivt. Om man är flera som arbetar på ett projekt kan man enkelt dela upp arbetet. Den ena utvecklaren kan tex bli tilldelad en funktion medans en annan utvecklare skriver en annan. Sedan implementeras dessa funktioner i huvudprogrammet. Kommentarer kan hjälpa till vid läsning och förståelsen av kod. Allt för ofta händer det att tex funktions funktionalitet glöms av och koden måste gås igenom för att komma på vad kodsegmentet utför. En kommentar kan beskriva funktionen och dess definition. Kommentarer kan även användas för att påminna en utvecklare om var denne avslutade arbetet senaste och var utvecklaren bör påbörja sitt arbete. Kommentarer kan även beskriva vad som krävs för att funktioner skall funka korrekt om en annan utvecklare bestämmer sig för att ändra i programmet. 4, Att strukturera data på ett ändamålsenligt sätt innebär att man använder skriver kod på ett sätt så man inte har onödiga variabler eller funktioner i programmet. Att överflödig kod undviks helt enkelt. Har man en funktion som utför en viss funktion behövs det med största sannolikhet inte en till funktion som utför en väldigt snarlik process eller rent av samma, då är det med största sannolikhet bättre att man använder sig av den befintliga funktionen för sitt syfte. Samma tänk kan användas vid användandet av variabler. En programmerare skulle kunna använda en variabel för att lagra ett visst värde för att sedan lagra ett uppdaterat värde av det ursprungliga värdet i en ny variabel. Detta är inte optimalt då programmeraren istället skulle utgå från den ursprungliga variabeln för att spara det nya värdet. Att använda olika datatyper är nödvändigt vid utveckling av mjukvara. Beroende på vilket beteende som eftersökt bör en korrekt datatyp väljas. Om ett program till exempel skall fråga efter en användares personnummer kan vi till exempel inte ha ett heltal eller int då den datatypen inte hanterar bindes-tecken som kommer att behövas när man matar in sitt personnummer(yyyymmdd-xxxx). Detsutom allokerar de olika datatyperna olika mycket minne. Att använda rätt typ kan då även optimera programmets resurskonsumption. Att använda olika datatyper blir således nödvändigt för att vi skall få ett funktionellt program. En array kan liknas vid en byrålåda som har flera olika lådor där information kan sparas. Detta kan vara väldigt användbart ifall man skulle vilja spara flera olika värden av samma typ på ett och samma ställe. En array kan ha flera element där varje element får ett index. Vi kan spara ett värde i varje element och nå det genom att kalla på arrayen och det index för elementet vi vill komma åt. Som jag skrev tidigare i punkten är detta väldigt användbart ifall man vill spara flera värden på ett ställe och slippa deklarera flera olika variabler för att spara de värdena. tal1 initieras och tilldelas värdet 5. tal2 initieras och tilldelas värdet 10 Pekare initieras och tilldelas värdet av Tal2 Tal1 tilldelas värdet av tal1 + tal2 pekartal tilldelas värdet av pekartal + pekartal, i och med att det pekar mot tal2 tilldeleas alltså tal2 värdet av tal2 + tal2. skriv ut tal1 och ny rad, skriv ut tal2 och ny rad, skriv ut pekartal och ny rad. Det som kommer att skrivas ut är 15 för tal 1, 20 för tal2 och 20 för pekartal. Fel 1: #include <iostream> Fel 2: string namn; Fel 3:
cout << "Välkommen till Casion 2012 " << "Vad heter du?" << endl; Fel 4: f( nummer < 18 ) { cout << "Du är för ung för att spela det här spelet" << endl; else { cout << "Du är välkommen, men tyvärr har vi stängt idag." << endl; Fel 5: return "Hej då"; Fel 6: saknas på slutet. Rättat kod nedan: #include <iostream> using namespace std; int main() { string namn; int nummer; cout << "Välkommen till Casion 2012 " << "Vad heter du?" << endl; cin >> namn; cout << "Hej " << namn << endl; cout << "Hur gammal är du? "; cin >> nummer; cout << "Du är " << nummer << endl; if( nummer < 18 ) { cout << "Du är för ung för att spela det här spelet" << endl; else { cout << "Du är välkommen, men tyvärr har vi stängt idag." << endl;