Plan

1. OOSU Plan • Analyse af anvendelsesområde – Grænseflader • Design af arkitektur – komponenter • Extreme Programming (XP)

2. Analyse af anvendelsesområde III Grænseflader

3. OOSU Formål og principper • Formål • At fastlægge et systems grænseflader • Begreber • Grænseflade: Faciliteter, der gør model eller funktion tilgængelig for aktører • Brugergrænseflade • Systemgrænseflade • Principper • Skræddersy brugergrænsefladen til anvendelsesområdet • Ekperimentér og iterér • Identificér alle bestanddele i grænsefladerne • Resultater • For brugergrænseflade: • Dialog- og præsentationsformer • Liste af bestanddele • Vinduesdiagrammer • Navigeringsdiagram • For systemgrænseflade: • Klassediagrammer for ydre enheder • Protokoller for interaktion med andre systemer

4. OOSU Delaktiviteter

5. OOSU Brugbarhed? • Hvad er den bedst mulige brugergrænseflade? • Et kompromis… • Tilpasset anvendelse og teknologi… • Minimerer afstand mellem udførelse og evaluering… • Konsistens, feedback, læring, fortrydelse, genveje, hastighed, simpel, naturlig, konsistent, vinduer, look, feel, …?

6. OOSU Tilpasning til brug

7. OOSU Udforsk dialogmønstre • Menuvalg • Kort indlæring, få indtastninger, struktur, let at programmere • Fare for mange menuer, ikke hurtigt, pladsforbrug • Skemaudfyldelse • Simpel indtastning, begrænset træning, indeholder vejledning, let at programmere • Optager plads • Kommandosprog • Fleksibelt, hurtigt, bruger i kontrol, let at lave makroer • Ringe fejlhåndtering, omfattende træning, sværere at implementere • Direkte manipulation • Let at lære og huske, understøtter udforskning, subjektiv tilfredsstillelse • Vanskeligt at programmere, kræver grafisk skærm og pegeinstrument • Og mange andre • Naturligt sprog • Gestikulation • Taktilt input • …

8. OOSU Tekniske muligheder... • Hvilke dialogformer er teknisk mulige? • Hvilke muligheder og begrænsninger er der for svartider? • Hvilke muligheder er der for flerbrugeradgang? • Hvilke kommunikationsmuligheder?

9. OOSU Eksempel: Maersk Booking

10. OOSU Eksempel: Ideogramic UML

11. OOSU Valg af dialogform • Hvilken orientering? • Funktionsorienteret: Menuer med valg af funktioner er dominerende • Objekt-orienteret: Fremvisning af objekter fra modellen er dominerende • Hvilken kombination af dialogformer? • De grundlæggende dialogformer kan bidrage til begge “orienteringer” • Kriterier • Relaterer sig til arbejdssituationen • Enkel, naturlig og konsistent • Få krav til brugerens hukommelse • Feedback informativ og konstruktiv • Fejl forebygges

12. OOSU Udformning af brugergrænsefladen • Præsentation af model og funktioner • Præsentere objekter og klasser på en letforståelig måde • Idéer • Klasse: et vindue for klassen, attributter som felter • Klynge: vises ikke • Generalisering: forskellige varianter af det samme vindue • Aggregering: overblik over delobjekter i helhedsobjektets vindue • Associering: overgang til associerede objekter gennem sekundære vinduer • Funktioner i menuer (+acceleratorer), knapper, kommandoer • Koordinering af helhedens fremtræden • ...med udskrifter, brugervejledning og undervisning • Rapportgenerering bør også overvejes • periodiske rapporter • på brugerforanledning eller automatisk • beregningskriterier • layout • Afprøv konkrete forslag i form af prototyper/mock-ups

13. OOSU Resultater • Valg af dialogform og præsentationsformer • Vinduesdiagrammer, skitser • Navigeringsdiagram

14. OOSU Systemgrænseflade • Hvilke informationer sendes/modtages? • Hvilke forbindelser til konkrete objekter i problemområdet? • fysiske forbindelse fx til måleinstrumenter og kortlæsere • overførsel af data fra eksisterende databaser • Hvilke muligheder for kommunikation? • direkte kommunikation (DDE, DCOM/ActiveX, CORBA, TCP/IP sockets, ...) • overførsel af filer • ”screen scraping” • (gen)indtastning • Evaluering gennem reviews og eksperimenter • Eksperimenter kan være omfattende…

15. Design af arkitektur Komponenter

16. OOSU Formål og principper • Formål • At strukturere et system • Begreber • Kriterium: En ønsket egenskab ved en arkitektur • Komponentarkitektur: En strukturering af et system i indbyrdes forbundne komponenter • Procesarkitektur: En strukturering af et systems udførelse i indbyrdes afhængige processer • Principper • Fastlæg og prioriter kriterier • Byg bro mellem kriterier og teknisk platform • Afprøv design så tidligt som muligt • Resultat • En strukturering af et systems komponenter og processer

17. OOSU Delaktiviteter

18. OOSU Hvad er arkitektur? • Strukturerne af et system i form af komponenter, deres eksterne egenskaber og deres sammenhæng • En overordnet forståelse af system, der styrer dets udvikling og brug • Strukturer og metaforer • Eksterne egenskaber og overordnet forståelse

19. OOSU Hvorfor se på arkitektur? • Indeholder overordnede designbeslutninger • Kan og bør evalueres tidligt • Uhensigtsmæssige valg har store konsekvenser • Ramme for udvikling • Strukturerer et system i dele • Opfylder bestemte designkriterier • Alle systemer har en arkitektur • Basis for overordnet forståelse • Bør respekteres under vedligehold

20. OOSU To forskellige syn

21. OOSU Komponenter • Komponentarkitekturen opdeler systemet i komponenter • Komponent: En samling af programdele, der udgør en helhed og har et veldefineret ansvar • Klasse <= komponent <=system • Lav kobling • Høj samhørighed

22. OOSU Proces • Reducer kompleksitet gennem ansvarsfordeling • Indtænk stabile strukturer fra omgivelserne • Genbrug komponenter

23. OOSU Mønster: Lagdeling • Lag: beskriver en komponents ansvar ved hvilke operation, der tilbydes opad og hvilke der udnyttes nedefra • Del: Ingen væsentlig interaktion med andre dele i samme lag • Lukket arkitektur: kun anvende operationer på det umiddelbart under-liggende lag • Åben arkitektur: anvende alle underliggende lag • Eksempel: ISO OSI

24. OOSU Mønster: Grundarkitektur • Grundarkitekturen afspejler opdelingen af omgivelserne i problem-område og anvendelses-område • “Teknisk platform” er en udvidelse og indkapsling af den underliggende tekniske platform • Eksempel: Maersk

25. OOSU Mønster: Client/Server • Optimere udnyttelse af klienters ressourcer og netværkskapacitet

26. OOSU Opdeling i komponenter

27. OOSU Resultater • Klassediagram med komponenter • Specifikation af komplekse komponenter

28. Extreme Programming Highsmith (2002)

29. OOSU ”Advarsel” • White paper – ikke videnskabelig artikel: • Udgivet af en organisation (Cutter Consortium) • Skal uddanne industrifolk, ikke overbevise videnskabsfolk • Intet ”peer review”, ikke gennemlæst og bedømt af kolleger • Generelt problem med ”proces-artikler”

30. OOSU Extreme Programming • Motivation • Deliver functionality quickly • Keep up with near-continuous change • People don’t enjoy requirements gathering, documentation, testing, … • Current processes are hard to learn and execute • Extreme Programming (XP) • Lightweight software development method • Small teams (2-10 people) • Changing requirements • Focus on programming Beck, K. (1999) Extreme Programming Explained. Embracing Change. Addison-Wesley Longman. Reading, Massachusetts.

31. OOSU Agile Software Development • Manifesto made by the Agile Alliance in 2001 • Four values: • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan • Covers a number of development processes • Ideas not new • go back to the early days of participatory design in the seventies (Nygaard and Bergo)

32. OOSU Some Key Agile Methods • Adaptive Software Development (Jim Highsmith) • speculate-collaborate-learn, focus on learning, larger projects • Agile Modeling (Scott Ambler) • modelling “add-on” to processes, combination of methods • Crystal Family (Alistair Cockburn) • JIT method construction, process anthropology • Dynamic Systems Development Method (Jennifer Stapleton) • RAD-based, focus on user involvement • Extreme Programming (Kent Beck) • system of (fixed) practices, emergence • Feature Driven Development (Peter Coad, Jeff De Luca) • feature-focus, simplicity, traceability • Lean Development (Bob Charette) • minimality, needs-based • Rational Unified Process… (Philippe Kruchten) • framework, large range of methods • Scrum (Jeff Sutherland, Ken Schwaber) • chaos as outset, tacit knowledge-focus

33. OOSU The Crystal Family • Alistair Cockburn (2002). Agile Software Development. Addison Wesley • different kinds of projects need different kinds of methods • the project changes as people changes • effective communication and frequent delivery essential • Methods need to be chosen based on multiple factors large military system banking system medium-sized productivity tool small utilities

34. OOSU Four Variables of XP • An XP project controls four variables • Cost • Time • Quality • Scope • Scope is the most important variable • fix date, quality, and cost • adjust scope

35. OOSU Four (Social) Values • Communication • lack of communication within a project is a root cause of problems • programming practices should enforce communication • Simplicity • do the simplest thing that could possibly work • risks and the low cost of change makes this feasible • Feedback • tests provide immediate feedback about code • the system is put into early production • Courage • change systems in production, throw code away • supported by the other values

36. OOSU Basic Principles • The values are distilled into concrete principles • Rapid feedback • crucial in learning • Assume simplicity • economics of software as options favour this • Incremental change • problems are solved in the smallest steps that make a difference • Embracing change • preserve options while getting work done • Quality work

37. OOSU The Technical Premise of XP • The cost of a design change does not necessarily increase exponentially • technology and programming practice make the cost raise slowly cost of change cost of change time time

38. OOSU Balancing design and refactoring Anticipatory Design Refactoring Refactoring Anticipatory Design Lower  Rate of Change  Higher Lower  Rate of Change  Higher

39. OOSU XP practicesRefactoring • (noun): a (small) change that preserves semantics made to a program in order to improve its structure • (verb): to restructure a program through a series of refactorings • Adding new functionality and refactoring are two different activities • Design and architecture can be constructed through a series of test-code-refactor cycles Fowler, M. (1999). Refactoring. Improving the Design of Existing Code.. Addison-Wesley Longman. Reading, Massachusetts.

40. OOSU XP practices • Use with small co-located teams • Tendency towards minimalism • Rules <-> Guidelines • Situated (depends on project/people/…) • Which to pick and which to discard?

41. OOSU XP practicesPlanning game - Roles • XP • Components Stories Business Development Estimates Abstract Stories • Dragon • Time boxing Business Development Concrete stories, constraints MoSCoW

42. OOSU XP practicesPlanning game - Players • XP Development Business All decision makers All Responsible Dragon Development Business Responsibility is taken rather than given All decision makers 1-2 Responsible Development Business All decision makers + Business Reps Transparency Commitment All Developers

43. OOSU XP practicesContinued … • Small releases • Small as possible • Most valuable • Provide sense of accomplishment • Metaphor • Overall coherent theme (‘one-stop-shopping’) • Metaphors, stories, and architecture

44. OOSU XP practicesContinued … • Simple design • Design for what has been defined, not potential future functionality • Create the best design that can deliver that functionality • Put in what you need when you need it • Testing • “Test and then code” • Listen -> Test -> Code -> Design

45. OOSU XP practicesContinued … • Pair programming • Extreme of inspections/walkthroughs/reviews • 2 people programming with 1 keyboard, 1 mouse, 1 monitor • Pairs typically change a couple of times a day • Prevents rather than detects defects • Collective ownership • Anyone may change any code at any time

46. OOSU XP practicesContinued … • Continuous integration • Frequent builds every couple of hours • 40-hours-week • “Overtime is the time in office where you don’t want to be there”? • On-site customer • Full time, on-site, user/customer involvement • Coding standards • Hand in hand with collective ownership

47. OOSU SummaryIteration Cycles Testing • Supported by the practices of XP • Analysis • Metaphor, On-Site Customer, The Planning Game, ... • Testing • Continous Integration, Short Releases, Simple Design, ... • Coding • Coding Standards, Pair Programming, 40-Hour-Week, ... • Design • Refactoring, Simple Design, Pair Programming, Collective Ownership, ... Analysis Coding Design

48. OOSU User Involvement • XP • User(s)/customer(s) in development team • Application in use • Dragon • User(s) in development team • User site (and dev. team on user site) • Extended reviews • Workshops at sites in Europe, Asia, America • Demos at sites in Europe, Asia, America

49. OOSU Metaphors • XP • One overarching metaphor • Contracts, customers, endorsement • Like a spreadsheet • … • Dragon • Many metaphors on various levels • The Dragon Garment story • One-Stop shopping • A product • Bremerhaven • Algeciras • … Easy to understand Ping-Pong “Travels” Re-constructs

50. OOSU Evolution • Software systems evolve • Requirements change over time • Problem domain understanding increases • Understanding of technical ways to realise the system increases • XP • Architectural evolution is handled through series of refactorings • Dragon • Explicit focus on architecture & architectural restructuring