Plan Analyse af anvendelsesområde – Grænseflader

Præsentationer af emnet: "Plan Analyse af anvendelsesområde – Grænseflader"— Præsentationens transcript:

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

2 Analyse af anvendelsesområde III
Grænseflader

3 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

4 OOSU Delaktiviteter

5 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, …?

6 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

7 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 …

8 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?

9 Eksempel: Maersk Booking
OOSU Eksempel: Maersk Booking

10 Eksempel: Ideogramic UML
OOSU Eksempel: Ideogramic UML

11 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

12 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

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

14 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…

15 Design af arkitektur Komponenter

16 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

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 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

20 OOSU To forskellige syn

21 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

22 Proces Reducer kompleksitet gennem ansvarsfordeling
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 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

25 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

26 Opdeling i komponenter
OOSU Opdeling i komponenter

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

28 Extreme Programming Highsmith (2002)

29 ”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”

30 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.

31 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)

32 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

33 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

34 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

35 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

36 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

37 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

38 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

39 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.

40 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?

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

42 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

43 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

44 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

45 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

46 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

47 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, ...

48 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

49 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

50 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

51 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

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