UML står för "Unified Modeling Language" och är ett objektorienterat språk för modellering av alla typer av system. Som en arketiekt som har metoder för att rita en byggnad så har systemutvecklare, programvarukonstruktörer, testingenjörer UML för att rita upp system, språket användas främst inom programvarukonstruktion men kan användas även till att modellera affärsprocesser. Genom att skapa en modell av systemet som skall konstrueras blir det enklare att förstå och bygga det.
Vad är ett bra system?
• Nyttigt och användbart – mjukvaran måste förenkla eller förbättra tillvaron för användarna på något sätt.
• Pålitligt – få buggar, förväntat beteende.
• Flexibelt – användarens behov förändras med tiden och mjukvaran måste kunna matcha dessa förändringar. Underhåll är det som sker efter att mjukvaran levererats.
• Rymmas i budgeten – användaren måste ha råd att köpa mjukvaran samt att underhålla den.
• Tillgängligt
– Det måste gå att köra systemet på tillgänglig
hårdvara, med tillgängliga operativsystem o.s.v.
– Mjukvaran måste finnas – projekt som utvecklar
Informationsmängd
En människa kan bara förstå en viss mängd
information åt gången. Vi kan hålla 5-7 separata
informationsdelar i tanken samtidigt och förstå
dessa. Fler än så, så börjar vi tappa förståelse.
Detta innebär att vi för stora system måste dela
upp modellen och koden i olika delar där varje
del i sig blir förstålig. De olika delarna av en
modell kan ha olika detaljdjup som gör att vi kan
minska mängden information och få en överblick
som vi kan förstå.
• Man utgick tidigt från att om man ändrade en rad
så skulle problem som denna ändring gav
upphov till finnas på rader i närheten. Alltså
behövde man bara förstå den närliggande koden
för att säkerställa att ändringen inte gav upphov
till buggar. Detta antagande var FEL!
• ”Spaghetti code” var ett uttryck som myntades
på 60-talet för att beskriva system vars kod var
så full i beroenden mellan olika delar att det inte
gick att förstå den.
Så man bör alltså dela upp sin kod i
moduler. Moduler kan vara
– Filer
– Subrutiner
– Biblioteksfunktioner
– Klasser om objektorienterat språk
– Moduler i vissa språk/system
– Oberoende delsystem eller program
Alla moduler är dock inte lämpliga utan
konsten ligger i att se vilka moduler som är
lämpliga.
Begrepp – beroende
Modul A är beroende av modul B och det är
möjligt att någon ändring i B kan medföra
att det även behövs en ändring i A.
Man kan även säga att A är en klient till B
eller att B är en server till A.
Om två moduler har varandra som klienter
så har man ett cirkulärt beroende.
Cirkulära beroenden bör alltid undvikas.
Begrepp - coupling
Coupling – koppling är ett begrepp som
används för att beskriva beroenden mellan
moduler.Om ett system har hög koppling (high
coupling) så har systemet många
beroenden. Om ett system har få
beroenden så har systemet låg koppling.
Vi vill sträva efter så låg koppling som
möjligt mellan moduler.
Begrepp – gränssnitt
Gränssnitt (interfaces) möjliggör att man kan ändra en
moduls interna utseende utan att detta påverkar klienter
till modulen. Gränssnitt kan vara allt från kommentarer till
en fil till Javas interface-kod.
Gränssnitt kan ge två typer av fel:
– Syntax-fel som uppkommer på grund av att man frångår ett gränssnitt.
– Semantiska fel som uppstår på grund av att man inte använder gränssnittet så som det var avsett.
Gränssnitt har ofta i sig beroenden av andra gränssnitt eller moduler och dessa beroenden bör dokumenteras
på något sätt i gränssnittet. En modul kan ha flera gränssnitt.
Begrepp - inkapsling
Gränssnitt är ett sätt att kapsla in en modul.
Ett bra system består av inkapslade
moduler.Inkapsling innebär att en klient inte kan
veta mer än vad gränssnittet säger.
Begrepp - abstraktion
Abstraktion innebär att gränssnittet strävar
efter att ge en bild av modulen som är så
klart som möjligt genom att abstrahera de
delar som är svåra att implementera till
något som är lätt att använda.
Man abstraherar det som det inte är
nödvändigt för klienten att veta.
Abstraktion innebär att en klient inte
behöver veta mer än nödvändigt.
Begrepp - cohesion
Moduler som abstraherar det som det inte är
nödvändigt för klienten att förstå sägs ha
hög cohesion eller sammanhållning.
Objekt
Ett objekt är något som man kan interagera
med genom att sända meddelande till det.
Objekt är en sak. Detta behöver dock inte
vara en fysisk sak utan kan vara ett
konceptuellt begrepp i systemet.
Ett objekt har ett tillstånd som bestäms av
den data som objektet inkapslar – dess
attribut. Vissa attribut kan ändras, andra inte.
I de flesta språk så kan inte antalet attribut
ändras under ett objekts livstid men det
finns undantag.
Ett objekt har ett beteende som bestämmer
hur objektet reagerar på meddelanden.
Hur ett objekt reagerar på ett meddelande
kan bero på dess tillstånd.
Ett objekt har även en identitet. Denna
identitet är inte det samma som ett objekts
namn eller den referensvariabel som
refererar till objektet.
Ett objekt kan ha flera namn men har endast
en identitet.
Inga kommentarer:
Skicka en kommentar