1 / 52

Plan

Plan. Analyse af anvendelsesområde – Grænseflader Design af arkitektur – komponenter Extreme Programming (XP). Analyse af anvendelsesområde III. Grænseflader. Formål og principper. Formål At fastlægge et systems grænseflader Begreber

malia
Download Presentation

Plan

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related