Objektorienterad Analys och UML En animation i Powerpoint © Kenneth Norrgård 2002. Ingår i studieperioden ”Planering av datasystem” vid Vasa Yrkeshögskola.

En presentation över ämnet: "Objektorienterad Analys och UML En animation i Powerpoint © Kenneth Norrgård 2002. Ingår i studieperioden ”Planering av datasystem” vid Vasa Yrkeshögskola."— Presentationens avskrift:

1 Objektorienterad Analys och UML En animation i Powerpoint © Kenneth Norrgård Ingår i studieperioden ”Planering av datasystem” vid Vasa Yrkeshögskola UP för informationsbehandling Denna presentation visar en objektorienterad analysmetod baserad på boken ”Objektorienterad Analys och Design” av Lars Mathiassen m.fl. Genomgången tar minst 10 minuter (du kan dock själv bestämma takten) Den visar de viktigaste faserna i metoden, när olika UML diagram skall användas och hur resultatet av analysen dokumenteras i ett analysdokument. Förklarande text finns inlagt i speciella förklaringsrutor. I vissa förklaringsrutor har hänvisningar till kapitel och/eller sidor i boken lagts in för att hjälpa Dig att hitta mer fakta om respektive område.  Klicka med musen för att börja…

2 På detta område beskrivs analysen av användningsområdet
Funktionslista OOA metod och UML UseCaseD 7. Analysera aktör 8. Analysera användningsfall 5. Hitta aktörer 6. Hitta användningsfall 10. Hitta händelser 11. Bestäm funktioner Fönsterprototyper 9. Hitta objekt 1. Definiera PO 2. Definiera AO 3. Rita rik bild 4. VATOFA-kriteriet ObjectD objekt roll 12. Gör användargränssnitt Händelsetabell AO PO 13. Definiera teknisk plattform Hitta klasser Realisera funktionerna Datasystemet Datasystemet Datorn symboliserar här det datasystem Du håller på att planera På detta område beskrivs analysen av problemområdet 10. Hitta händelser 11. Analysera dynamiken ClassD Klass Attribut Oper ( ) 1..* o..* 1..3 Gränssnitt Funktioner Modell SequenceD objekt StateChartD Tillstånd Analysen av användningsområdet börjar med att analysera aktörer (=de personer som interakterar med systemet) och användnings- fall Detta görs i ett användnings- fallsdiagram – UseCase Diagram.  Klicka med musen Då inblandade aktörer och an- vändningsfall identifierats analy- serars de ett efter ett för att reda ut varför en viss aktör är intressant och vad som händer i resp. an- vändningsfall. Se boken kap – 6.3.  Klicka med musen Alla objekt tillhör en viss klass. Klassen beskriver objektets egen- skaper och beteende och relationer med varandra. Detta beskrivs i UML i ett klassdiagram – Class Diagram. Klassdiagrammet beskrivs litet senare.  Klicka med musen Nästa steg är att hitta väsentliga händelser i verksamheten. En händelse skall beskriva något väsentligt som måste vara utfört för att systemet skall fungera. En händelse skrivs alltid i en viss form t.ex. ”kund uppdaterad”  Klicka med musen Utifrån identifierade händelser härleds de funktioner som behövs i det planerade systemet för att få händelserna uträttade. Dessa arbetssteg ger en händelse- tabell (t.ex.fig. 3.1) och en funktionslista (t.ex. fig. 7.6.)  Klicka med musen UML står för Unified Modeling Language och är ett beskrivnings- sätt (=notation) för att visualisera och beskriva det system Du håller på att planera. UML och dess element finns beskrivna i kap. 18.  Klicka med musen Analysen delas upp i två olika processer – Analys av AO (blått) och analys av PO (grönt). Man brukar starta med AO, men dessa processer hänger förstås intimt ihop med varandra. Nu behöver vi UML till hjälp  Klicka med musen Nästa steg är att identifiera de objekt som är väsentliga för problemområdet. De UML diagram som binder ihop objekten kallas objektdiagram – Object Diagram. Detta finns inte nämnt i boken  Klicka med musen En analys startar med att Du de- finierar datasystemet som Du skall bygga. Definiera problem- och användningsområde, skapa dig en bra bild av verksamheten och definiera de krav som ställs på det planerade datasystemet  Klicka med musen Analysen dokumenteras alltså i analysdokumentets första kapitel i underkapitel enligt nedan. Dokumentationsstandarden är behandlad i kap. 16 i boken  Klicka med musen Objektdiagrammet borde visa hur de viktigaste objekten är samman- kopplade och borde ge en bild av verksamheten (problemområdet). Objekten kommer att ligga till underlag för klassdiagrammet.  Klicka med musen Analysen av klasser är den vikti- gaste delen av den objektoriente- rade analysen. Klassdiagrammet kommer att ligga till grund för datasystemets modellkomponent som är ”ryggraden” i systemet. Se kap. 3 och 4 i boken.  Klicka med musen Olika delar av analysen kommer att ligga till underlag för de olika komponenterna användargräns- snitt-, funktions- och modell- komponenten. Här symboliserat med gula linjer och en pil som visar vilken komponent som är i fråga.  Klicka med musen Analysen av problemområdet dokumenteras i analysdokumentets andra kapitel och efter det börjar man ha en ganska klar bild av det datasystem som skall realiseras och vad som skall finnas i de olika komponenterna. Kom ihåg fig. 1.2 i boken.  Klicka med musen Då analysen är gjord samman- fattas resultatet i kap. 4 i analys- dokumentet. Där kommenteras analysen och ekonomi och strategi och realiseringsbarhet diskuteras. Detta ligger som underlag till den efterföljande designen  Klicka med musen Analysen är gjord och grunden för det datasystem som finns på den första bilden (kom ihåg fig i boken) är lagd och utvecklingen fortsätter i den efter- följande objektorienterade designen (OOD)  Klicka med musen Presentationen är slut Tack för visat intresse och kom ihåg att läsa boken Klicka med musen De händelser som identifierats och grupperats i funktioner skall nu realiseras genom att skapa be- teendemönster. Det är fråga om processer där olika objekt sam- spelar med varandra. Klassernas beteende beskrivs i kap. 5.  Klicka med musen Besläktade klasser ”klumpas ihop” till komponenter (kluster) och klasserna attribut (objektens egen- skaper) och operationer (objektens beteende) definieras. Objektens tillstånd visas i tillståndsdiagram och objektens samspel i sekvens- diagram (och samarbetsdiagram).  Klicka med musen I detta skede bör man även de- finiera den tekniska plattformen som utvecklingen skall ske på och även den plattformen som sys- temet skall köras på då det sätts i drift.  Klicka med musen Resultaten av analysen av användningsområdet dokumente- ras i kap. 3 i analysdokumentet. Händelsetabellen kommer även att spela en väsentlig roll vid analysen av klasserna.  Klicka med musen För att systemets funktioner skall vara tillgängligt för dess användare behövs ett användargränssnitt. I detta skede görs prototyper på fönster, dialoger och navigering för att ge en bild av hur systemet kommer att se ut för användaren.  Klicka med musen Klasserna knyts ihop med rela- tioner som associationer, arv och aggregat. Du bör känna inne- börde och UML-notationen för dessa. I detta skede sker in- kapslingen, d.v.s. Du bestämmer vilka objekt (via sina klasser) som skall kunna ”se varandra”  Klicka med musen 5. Hitta klasser 6. Analysera klasser 7. Hitta strukturer 8. Hitta kluster/komponenter 9. Analysera tillstånd Dokumentera Definition av uppgiften Analys av AO Analys av PO Rekommendationer A.1.1 Syfte A.1.2 Systemdefinition A.1.3 Omgivning A.1.4 Definition av PO A.1.5 Definition av AO A.3.1 Användning A.3.2 Funktionsanalys A.3.3 Användargränssnitt A.3.4 Teknisk plattform A.2.1 Kluster A.2.2 Struktur A.2.3 Klasser A.2.4 Händelser A.4.1 Realiserbarhet A.4.2 Strategi A.4.3 Ekonomi Analysdokument © September 2002 Kenneth Norrgård

3 O som i Objekt Orienterat är COOOOOLT O som i Om man inte förstod, så tar man om det från början… O som i Om man inte förstod ett dugg, va dådå… O som i Ojdå tog det slut nu Nu är det slut Klicka med musen