Plan Analyse af anvendelsesområde – Grænseflader OOSU 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 Begreber Principper Resultater 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

OOSU Delaktiviteter

Brugbarhed? Hvad er den bedst mulige brugergrænseflade? 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, …?

Tilpasning til brug Opgaver Krav Teknologi Rutineopgaver OOSU Tilpasning til brug Opgaver Krav Teknologi Rutineopgaver Faste, velstrukturerede opgaver Hurtig betjening Sikker betjening Aktivering af funktioner Fast defineret dialog Menu- og kommando-drevet manipulation Simple skærme Sagsbehandling Varierende. problemløsende opgaver Fleksibelt i brug Let at lære nye funktioner Manipulering af objekter Løst defineret dialog Direkte manipulation Grafiske skærme

Udforsk dialogmønstre 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 …

Tekniske muligheder... Hvilke dialogformer er teknisk mulige? 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?

Eksempel: Maersk Booking OOSU Eksempel: Maersk Booking

Eksempel: Ideogramic UML OOSU Eksempel: Ideogramic UML

Valg af dialogform Hvilken orientering? 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

Udformning af brugergrænsefladen OOSU 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

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

Systemgrænseflade Hvilke informationer sendes/modtages? 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…

Design af arkitektur Komponenter

Formål og principper Formål Begreber Principper Resultat 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

OOSU Delaktiviteter

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

Hvorfor se på arkitektur? 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

OOSU To forskellige syn

Komponenter Komponentarkitekturen opdeler systemet i komponenter 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

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

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

Mønster: Grundarkitektur 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

Mønster: Client/Server OOSU Mønster: Client/Server Optimere udnyttelse af klienters ressourcer og netværkskapacitet Klient Server Arkitektur B B+F+M Distribueret præsentation F+M Lokal præsentation B+F Distribueret funktionalitet M Centraliserede data Distribuerede data

Opdeling i komponenter OOSU Opdeling i komponenter

Resultater Klassediagram med komponenter OOSU Resultater Klassediagram med komponenter Specifikation af komplekse komponenter

Extreme Programming Highsmith (2002)

”Advarsel” White paper – ikke videnskabelig artikel: 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”

Extreme Programming Motivation Extreme Programming (XP) 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.

Agile Software Development 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)

Some Key Agile Methods Adaptive Software Development (Jim Highsmith) 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

The Crystal Family large military system banking system 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

Four Variables of XP An XP project controls four variables 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

Four (Social) Values Communication Simplicity Feedback Courage 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

Basic Principles The values are distilled into concrete principles 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

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

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

XP practices Refactoring OOSU (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.

XP practices Use with small co-located teams 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?

XP practices Planning game - Roles OOSU Stories XP Components Business Development Estimates Abstract Stories Dragon Time boxing Business Development Concrete stories, constraints MoSCoW

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

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

XP practices Continued … OOSU 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

XP practices Continued … OOSU 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

XP practices Continued … OOSU 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

Summary Iteration Cycles OOSU Testing Analysis Coding Design 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, ...

User Involvement XP Dragon User(s)/customer(s) in development team 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

Metaphors XP Dragon Easy to understand Ping-Pong “Travels” 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

Evolution Software systems evolve XP Dragon 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

MAD: Multiperspective… OOSU MAD: Multiperspective… Before and while coding: Discuss “metaphor” and its implications on design with participatory designer, on-site customer and/or ethnographer Division of work according to architecture and/or business domain Consulting other programmers: code-dependency responsibility expertise

MAD: Multiperspective… OOSU MAD: Multiperspective… Culture and environment: Your place or mine? Open workspace 80 hour week 