Göm menyn

TDDI02 Programmeringsprojekt

Designspecifikation (obligatoriskt)


Hjälpmedel

Dokument rörande klasskonstruktion och objektorienterad analys och design, av Tommy Olsson. Väl värda att läsa igenom och använda.

Nedan instruktioner härrör från Olle Willen med en del förtydliganden och tillägg/justeringar av Klas A.

Designspecifikationen

Designdokumentet (-specifikationen) ska återspegla kravspecifikationen. Den ska utgöra en 'ritning' på hur systemet ska byggas, så att man i stort sett kan 'koda av' den (fast så enkelt är det givetvis inte). Men den ska i princip vara språkoberoende.

Specifikationen ska vara ett dokument i enlighet med någon standard för dokument. Inte 'lösa papper'. Följande delar ska ingå.

När är designspecifikationen klar? Hur mycket detaljer skall man skriva?

Det finns kanske inget riktigt specifikt svar då det varierar från fall till fall och beror av många faktorer. Designspecifikationen är ett försök att tydligt beskriva ett komplext system. Ert mål (som kanske inte nås i kursen) bör vara att kunna lämna er kravspecifikation och designspecifikation till en oberoende (oinsatt) utvecklare, som skall kunna skapa systemet såsom ni tänkt er. Hen skall inte behöva lägga till, ändra eller dra ifrån klasser eller metoder och hen skall inte behöva fråga er hur ni tänkt. Implementerar ni själva en del skall den gå byta ut mot samma del hen implementerat utan strul. Detta kräver naturligtvis att specifikationen är klar ned på metod och parameternivå för de delar av klasser som är publika. Privata delar behöver (kanske) inte specificeras då de (ofta) är upp till den enskilde utvecklaren.

Allmän dokumentstruktur

Försättsblad, innehållsförteckning och en inledning som kort presenterar uppgiften samt refererar till andra dokument av intresse för läsaren (= kravspecifikationen).

En arkitektur

  • Systemets/programmets indelning i större delsystem. Ett delsystem består då av ett antal mindre moduler såsom klasser eller andra funktionella delar.
  • En textuell beskrivning, översiktlig, av respektive delsystems uppgift(er). I bästa fall har ett delsystem bara "en" huvudsaklig uppgift, ett ansvar (som kan vara något stort eller abstrakt). Beskrivningen skall vara så pass omfattande att hela delsystemets ansvar blir tydligt, men samtidigt så översiktligt att det går snabbt och lätt att förstå. Inte för mycket detaljer alltså. En inledande översiktsfigur brukar säga tusen ord på ett enkelt sätt.
  • Relationer mellan delsystemen, hur använder de varandra och i vilken rikting går kommunikationen? Vilken modul initierar kommunikation och vilken svarar (för alla undermoduler som samarbetar)?

Detta tänkande appliceras nu rekursivt på varje delsystem för att på så vis steg för steg öka detaljnivån, tills önskad detaljnivå erhålls (t.ex. metoder och parametrar i klasser).

I nästa rekursionsnivå beskrivs t.ex. hur ett delsystem ser ut internt. Vilka klasser eller undermoduler finns i det, vilka klasser används av vilka, finns arv eller liknande? Se detaljerad teknisk specifikation nedan.

OBS! Ofta räcker tre nivåer: (1) en översiktsnivå över hela systemet, (2) en översikt över varje delsystem och (3) en detaljspecifikation av varje undermodul/klass i varje delsystem. Nivå 1 och 2 kallar vi arkitektur, och nivå 3 detaljerad teknisk specifikation (design).

Detaljerad teknisk specifikation

Här ingår en detaljerad (lågnivå) modulspecifikation, en per modul ('modulkontrakt'). "Modul" är här oftast att likställa med "klass", men behöver inte vara det i alla situationer:

  • Modulens namn, uppgift, ansvar. Är detta kopplat till något krav? Hänvisa till kravspecifikation, användningsfall eller scenarie om sådant finns (eller behöver det skapas?)
  • Dess 'ingångar', i allmän mening; det som kan hanteras på ytan (eller 'utifrån'), metoder (motsv.), variabler(?), ...
  • För var och en: namn, funktionalitet, parametrar, typer, värden, ..., och eventuella externa effekter (I/O).
  • I den händelse det kan behövas även 'ritningar' på särskilt komplicerade datastrukturer. Mer komplicerade än raka, länkade listor. I synnerhet om sådana ska 'delas' mellan flera moduler.

Det är här som namn på olika storheter slutligen fastställs, liksom det 'utlovade' interfacet mot andra moduler. Skilj alltså noga på det övergripande, dvs arkitekturen, och detaljerna, i specifikationen.

Specifikation av protokoll

Ofta kommunicerar olika delar med varandra. Vilken kommunikation som sker och de regler den följer är viktigt att specificera (eller hänvisa till befintlig specifikation). Alldeles speciellt om nu 'uppfinner' protokoll och olika personer skall implementera de delar som använder protokollet. Ett formulär på en webbsida skickar t.ex. med ett antal variabler med namn och värden till den mottagande modulen på servern, som både utvecklaren av webbsidorna och utvecklaren av servermodulen behöver vara överens om.

Design av användargränssnitt

I den händelse detta inte redan skett (krav från användare). Detta ska nu vara detaljerat. T.ex. menyers faktiska utseende, vilka kommandoorden är, dess parametrar. Eller utseendet av GUIs: vilka vyer (fönster) som finns och hur de hänger ihop (vilka knappar/användaraktiviteter leder till vilket fönster?). Gränssnittet är ofta ett delsystem i designspecifikationen, och det bör framgå hur klasser/moduler bär sig åt för att presentera olika delar av gränssnittet, vilka delar i koden som används (i vilken ordning?) för att sköta och representera olika vyer eller delar av gränssnittet.

Design av databas/filstrukturer

Behövs i de fall data måste lagras externt. Också tämligen i detalj.

Verifikation/validering

Ja, man behöver ju kolla, så långt det går, att denna specifikation verkligen är en 'avbild' av kravspecifikationen. Inget fråndraget, inget tillagt, all funktionalitet i enlighet med kravspecifikationen. Ställ dig frågorna "kan verkligen någon annan implementera hela programmet utifrån designdokumentet?" "skulle jag få samma system om jag lämnade designdokumentet till två olika utvecklare?".

Olle Willen (HTML-ifierat av Klas A.)

Lite mer tips av Klas A.

Hur tar man fram en teknisk arkitektur/design?

Att ta fram en bra arkitektur som fungerar effektivt för alla krav, och även för rimliga framtida utökningar är inte lätt. Först måste det finnas en bra förståelse av vad som skall utvecklas (= kravspecifikation).

Nästa steg är att bryta ned systemet i ett hanterbart antal (stora) delsystem, som kan fungera mer eller mindre oberoende av varandra. Ofta brukar det finnas någon form av "backend" som står för permanent lagring / filstrukturer och en "frontend" som hanterar de delar användaren av systemet ser (gränssnitt).

Dessa delar pratar med varandra på något sätt. Ibland med direkta funktionsanrop, ibland med databasfrågor (SQL), ibland via webbfrågor (http, json, etc). Specificera hur och vilken kommunikation som förekommer.

Varje delsystem består i sin tur av ett antal olika moduler eller klasser. Här kan med fördel objektorienterad analys (OOA) och design (OOD) användas för att komma fram till de klasser som behövs. Om detta finns mer information på kurshemsidan för TDDC76. En vanlig metod för OOA/OOD är CRC-metoden (Classes, Responsibilities, Collaborators) som ni kan läsa mer om annorstädes.

Det går även skapa enklare klassdiagram genom att skriva klassnamn på postit-lappar och klistra upp dem på ett större papper (A3). Under designen har det fördelen att det är lätt att ändra och flytta runt klasser. Är ni noggranna och har någon med prydlig handstil kan slutresultatet köras genom en kopiator för att enkelt få en översiktsbild av klassdiagrammet. Sedan kan närmare beskrivning av varje klass skrivas i dokumentet.

Hur kommer man fram till ett grafiskt gränssnitt?

Det är viktigt att faktiskt testa gränssnittet innan man sätter igång och kodar. Minst en en gång bör man testat vad kunden tycker om gränssnittet så man inte sätter igång och koda fel vyer. Det här kan låta som ett moment 22 - hur testar man gränssnittet innan man kodat det?

Även här går det med enkla metoder att utveckla ett gränssnitt utan att skriva en rad kod. Allt som behövs är ett antal papper och pennor (vid behov i olika färger). Rita upp de vyer/fönster ni direkt inser kommer att behövas för att uppfylla de viktigaste kraven. Fundera på hur användaren skall kunna flytta runt mellan dessa vyer. Det bör krävas ett minimum av klickande/knappande. Rita upp de knappar som behövs och vilka nya "vyer" (papper) de leder till. Välj en gruppmedlem som får testa att det fungerar. En annan gruppmedlem får byta vy (papper) efter hur testaren klickar. Övriga kan observera och tänka fram förbättringar. När ni är nöjda kan ett slutligt resultat testas på kund och dokumenteras. Även här kan möjligen ett mycket prydligt slutresultat scannas in och infogas som bilder i ett dokument.

Metoden kan kanske i viss mån användas även till textuella gränssnitt, speciellt om bibliotek som "ncurses" (står för new curses, men har inget med "nya svordomar" att göra). Det är ett bibliotek för att kunna placera markören fritt i terminalen och använda olika färger på text och bakgrund i terminalen. Ni har faktiskt använt det i kursen TDIU04, även om det mesta var givet i den laborationen. Med ncurses kan textuella fönster och vyer skapas.


Sidansvarig: Klas Arvidsson
Senast uppdaterad: 2012-10-09