Architettura del software un approccio Agile, Web-cast Microsoft 2006
•Télécharger en tant que PPT, PDF•
1 j'aime•1,073 vues
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Architettura del software un approccio Agile, Web-cast Microsoft 2006
Similaire à Architettura del software un approccio Agile, Web-cast Microsoft 2006 (20)
Plus de Luca Minudel
Plus de Luca Minudel (20)
Architettura del software un approccio Agile, Web-cast Microsoft 2006
- 1. Architettura del software:Architettura del software: un approccio Agile.un approccio Agile.
- 2. Chi sono • http://blogs.ugidotnet.org/luka • http://wiki.ugidotnet.org • http://www.codeplex.com/NSK • http://www.guisa.org
- 3. FFar emergere l’Architettura gradualmente. IIl ruolo dell’Architettura nell'approccio Agile. GGli strumenti della Architettura Agile. UUna visione moderna dell’Architettura.
- 4. Il ruolo dell’Architettura nell’approccio Agile • Che funzione svolge l'architettura nello sviluppo software con un approccio Agile ?
- 5. Il ruolo dell’Architettura nell’approccio Agile La sfida: • Il sw è Flessibile & Intangibile • Complessità & Eterogeneità • Impatto Economico
- 7. Gli strumenti dell’Architettura Agile • Di quali pratiche e strumenti fa uso l’Architettura nell'approcio Agile? • In che modo si applicano durante lo sviluppo? • Quali competenze ed esperienze servono?
- 8. Gli strumenti dell’Architettura Agile • CRC Card [Wirf-Brock, 1990] Classe : nomi, oggetti, concetti del mondo reale Responsabilità : verbi e aggettivi Collaboratori : relazioni-dipend. con altre classi
- 9. Gli strumenti dell’Architettura Agile • Unit Testing / TDD [Beck, 1998] - aiuta a trovare un disegno semplice - promuove il disaccoppiamento - guida la distribuzione delle responsabilità • Refactoring [Fowler, 1999] - nuovo disegno stesso funzionamento
- 10. Gli strumenti dell’Architettura Agile GGli skill sulla Architettura, i presupposti: • OOP: paradigmi, idiomi, strumenti http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/ProgrammazioneObjectOriented • OOD: attributi, principi, pattern, modellaz. http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/DisegnoObjectOriented
- 11. Gli strumenti dell’Architettura Agile GGli skill sulla Architettura: http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/ArchitetturaObjectOriented http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/LibriSuObjectOrientedDesign – Requisiti funzionali e non-funzionali + Attributi di qualità del sw – Architettura != Disegno != Infrastruttura – Modelli di strutturazione e controllo – I Reference Models – Gli Enterprise Patterns
- 12. Gli strumenti dell’Architettura Agile GGli skill sulla Architettura: http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/ArchitetturaObjectOriented http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/LibriSuObjectOrientedDesign – Requisiti funzionali e non-funzionali + Attributi di qualità del sw – Architettura != Disegno != Infrastruttura – Modelli di strutturazione e controllo – I Reference Models – Gli Enterprise Patterns
- 13. La visione moderna dell’Architettura • Quali sono i principi della moderna Architettura del software? • Che ruolo ha l'architetto in un team Agile?
- 14. La visione moderna dell’Architettura • Ultimo momento responsabile [M. Poppendieck, 2003] • Principio di non reversibilità [E. Zaninotto, 2002] • Disegno continuo [Fowler, 1999]
- 15. La visione moderna dell’Architettura Nella visione Classica • Abstract Authority • Project Oriented Management • Comprehensive Documentation • Following a Plan • Governance • Rationalization • Outsourcing • NDA • Large Analyst Firms • Management • ERP for IT • ... Nella visione Moderna • Community • Strong Technical Leadership • Working Software • Responding to Change • Stewardship • Innovation • Open Sourcing • Declarative Living • Small Analyst Firms • Leadership • Burndown • ...
- 16. La visione moderna dell’Architettura • ... • CMMi • Best Practices • Reference Architectures • Time Accounting • Buy vs. Build • Project Oriented • Politics • Polarization • Buy-in • Restrictions • Cathedral Style Development • Process • ... • Agile Methods • Practical Considerations • Shared Vision • Functional Delivery Accounting • Buy vs. Build vs. Open • Service Oriented • Diplomacy • Dialog • Enlistment • Rights • Bazaar Style Development • People
- 17. La visione moderna dell’Architettura • i componenti più rilevantirilevanti per il successo del progetto • comprensione chiara e condivisa • contribuirecontribuire a disegnare questi componenti • questioni più rilevanti, opportunità a maggiore beneficiomaggiore beneficio • evita le scelte di disegno irreversibiliirreversibili • studi di fattibilità e raccolta requisiti comunicando • quantita minimaminima di disegno necessaria, la massima semplicitàsemplicità • contribuire alla crescitacrescita del team
- 18. Far emergere l’Architettura gradualmente • Come far emergere l’Architettura invece di stabilirla a priori? • Come migliorare l’Architettura invece di degradarla ad ogni modifica?
- 19. Far emergere l’Architettura gradualmente • Evolvere un sistema (legacy) migliorandolo • Decidere dove piuttosto che quanto • Miglioramenti piccoli e continui invece della perfezione • Feature & Refactoring
- 20. Far emergere l’Architettura gradualmente • Infrastruttura
- 21. Far emergere l’Architettura gradualmente • Disegno http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/ValutareIlDisegnoDiUnaApplicazione – Tipi raggruppti in Assembly – Tipi raggruppati in Namespace – Nomi tipi, membri, parametri pubblici – Ripartizione responsabilità tra i tipi – Non-classi di soli dati o sole funzioni – Dipendenze inutili e cicliche – Ereditarietà da cambiare in contenimento – Spezzare tipi e metodi troppo lunghi – Riorganizzare algoritmi lunghi e complicati http://wiki.ugidotnet.org/default.aspx/UGIdotNETWiki/CodeSmell
- 22. Q & A http://blogs.ugidotnet.org/luka/contact.aspx http://www.agileday.it - 1 Dic. Milano http://www.xp2007.org/ - Como
- 23. Visual Studio 2005 è disponibile: scegli il prodotto più giusto per te www.microsoft.it/msdn/vs2005/ – Visual Studio 2005 Team Edition • Visual Studio Team Edition (for Architects, Developers o Testers) con MSDN Premium • Visual Studio Team Suite con MSDN Premium – Strumenti professionali • Visual Studio 2005 Professional • Visual Studio 2005 Professional con MSDN Professional • Visual Studio 2005 Professional con MSDN Premium • Visual Studio 2005 Tools for Microsoft Office System – Strumenti di base • Visual Studio 2005 Standard • Visual Studio 2005 Express Edition – Altri strumenti • Visual SourceSafe 2005 • VisualFox Pro 9.0 Dove acquistare: www.microsoft.it/msdn/rivenditori/ Licenze individuali: 1 sviluppatore = 1 licenza Per informazioni: itamsdn@microsoft.com
Notes de l'éditeur
- Motivazioni I principi dell’architettura modern hanno radici nell’approccio agile Approccio agile lega Architettura in modo diretto al valore consegnato all’utente l’approccio agile permette di far emergere l’arhitettura in modo graduale da codice legacy
- - wiki strumento team agile, primo .net progettazione, Prog .NET10 anni fa db design, progettazione a componenti e infrastruttura fisica6 anni progettazione OO4 anni met. agili
- Intro 3 slide A ruolo arch 1+2 slide - svi vertivale B strumenti 1+4 slide – tecniche – skill C vis. Moderna 1+5 slide – principi – esper. Pratica – ruolo dell’architetto D graduale 1+3 slide – legacy - new
- - Meccanica -> elettronica anal. -> eletr. Dig. -> inform. Il sw è flessibile (telefononi e DVD, digi-sw)+ si adatta facilmente a nuove esigenze (tempi costi) + facile da aggiornare, si tele-trasporta + facilmente che un oggetto fisico- funziona in condizioni limite… (casa cane, grattacielo) è intangibile+ non sottostà a vincoli delle leggi fisiche, non ci sono limiti fisici alle potenzialità del sw+ esempio 1 giornale 1 pasto (*** stampa lsitato, run cincuiti elettrici, igor damiani epopea del bit) - non si percepisce facilmente lo stato di avanzamento e la qualità del bene prodotto (*** condomini, ponti, seggiovia, nave) Complessità nuova tecnologia eterogenità sistemi
- - a strati orizzontali ma verticale feature per feature - perchè ? 1 - aderenza ai bisogni reali degli utenti senza incomprensioni su quello che realmente serve 2 - misura reale stato avanzamento 3 - prima feature importanti, non feature non necessarie = Economicità -> flessibilità sui bisogni di busines - possibili grossi cambiamenti sul codice, bisognoa atrezzarsi!!! - in team XP tanto disgno, grossa opportunità di imparare facendo parte di un team xp con la guida del coach e facendo pair con i membri senior del team (*** appartamento, garage, tetto, giardino) ---------- - - - - - - - - - - - - - - -
- (*** orchestra sinfonica -> fiati, archi, perussioni arena di verona, la fenice di venezia, la scala di MI)
- 1-nel dominio app duranre la racc. Requisiti=user story 2-nella implementazione della user story a livello implementativo - Class Responsability Collaborators EDUP Nome degli oggetti responsabilità (chò che l’oggetto conosce e ciò che fa = UML att.prop) Collaboratori (dipendenze) Requisiti (dominio del problema) Planning (chirire req. E investigare soluzione) Disegno upfront pre-sviluppo x chiarire dubbi (dominio soluz.) Per fare il punto a un nuovo pair Fisicità – tavolo con utente/pair - Metafora (dominio della soluz.) 1 - GUI a finestre e menù, le cartelle 2 - semafori; sincronizzazione tramite scambio messaggi;code e pile
- TDD, sedimenta e capitalizza il lavoro che normalmente si fa sul debugger in modo volatile. (un test è come un diamante) - Nunit, MbUnit, TestDriven.NET, VS2005 Refactoring Migliorare il disegno con piccole modifiche al codice che non alterano il comportamento - tst scritti prima - non bug fix - no new feature - compilatore e errori compile-time OK, sln con i prj collegati ok- strong typing OK (interfaccie, generics, classi base OK! )- weak tiping ko (object/variant, reflection che introduce possibili fallimenti sono a run-time KO)- Resharper, VS2005 (*** orfeo/euridice; romeo e giulietta; paola e chiara – utest+refactoring)
- Architettura no arhitetto modellazione uml / crc (*** cavalieri di camelot, non investitura org/onore)
- Leggere e capire :Req. Funz = features-specifiche tecniche - Dom. Applic.Req. Non-funz. = vincoli spesso critici - considerano l’intero sistemaReq. Non-funz. = Attributi di Q del sw- in uso difficili da misurare (Q.ta esterna)- statici facili da mis (Q.tà interna ma relazione con Q.ester non univoca) usabilità - affidabilità e sicurezza - efficienza - manutenibilità - portabilità, interoperabilità, accessibilità - Arch <> Disegno <> Infrastruttura (tecnologia (ASP.NET o WinForm o Mobile; se Remoting o WS o TCP/IP; SqlServer Express o Workgroup o Standard o Enterprise; ) Distributed app - Fault Tolerance - Scalability - per - Administration
- Quali sono i principali modelli generici di strutturazione di una architettura? -modello a repository -modello client-server -modello a macchina astratta detto anche a livelli Quali sono i principali modelli generici di controllo del flusso di elaborazione di una architettura? -centralized - call-return - manager -event-driven - broadcast -interrupt driven - Reference Models (ISO OSI, tcp, http stateless, HCI) - Ent pattern
- La bussola che ci guida imentre attriaversiamo il pjt come una bussola ci guida nel mare durante una crociera
- Ultimo momento reponsabile - Economicità + Informazioni / esperienza + possibilità di evitare di ridurre le opzioni x il futuro dopo perderei una alternativa (il tmpo ha deciso x me) Es. disegno + esperto + investimento di disegno posso rimandare la domanda non è quanto ma x un arch. _Dove_ + import Principio di Non reversibilità -> semplicità- that one of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs. nessun limite teorico solo l’intuizionee Creatività Disegno sempre - Reagire non pianificare EDUP - imparare dall’esperienza - evita feature inutili (non si sa maii ke possa servire , cod. pubblic) - evita investimenti in flessibilità speculative- istinto, ragionamento, esperienza (ultim mom resp)
- James McGovern 2003 The pratical guide to enterprise architecture Capability Maturity Model® Integration – tolstoy -dostojeskij
- Quali attività sono utili x l’architettura? - No ruolo, resp e visione condivisa Quanto -> dove individuare i componenti del sistema che sono più importanti per il successo del progetto e quindi per la implementazione delle funzionalità richieste con la qualità attesa, entro i vincoli (tempi, costi, ...) fissati, per soddisfare i bisogni che hanno portato a commissionare lo sviluppo del software assicurarsi che tutto il team abbia una comprensione chiara e condivisa di questi compomenti e del loro disegno contribuire a disegnare questi componenti tenere sotto controllo le questioni più importanti, risolverle prima che diventino problemi seri e cogliere le opportunità per effettuare i cambiamenti che portano maggiore beneficio individuare le scelte di disegno irreversibili (quelle il cui costo del cambiamento è maggiore), posticiparle (e quindi beneficiare dei feedback, della maggiore comprensione ed esperienza del sistema maturata nel frattempo) all'ultimo momento responsabile utilizzando il disegno, l'esperienza, l'organizzazione e l'immaginazione per rendere la scelta reversibile contribuire agli studi di fattibilità e alla raccolta requisiti comunicando con linguaggio non tecnico le conseguenze tecniche e in termini di tempo e costi delle diverse scelte possibili e le coseguenze delle varie idee espresse avere sempre chiara la quantita minima di disegno necessaria per il successo del sistema, la massima semplicità applicabile e i punti del sistema che hanno bisogno di ulteriore disegno contribuire alla crescita del team aumentando la sua capacità di contribuire all'architettura del sistema.
- Legacy meglio di new (evolvere e semplificare) Dove ? Roi per il cliente Non degrado, no perfezione irraggiungibile Feature più refactoring Lavorare bene Test+refactoring Cosa subito cosa dopo
- - Big bang – day by day , fantasia realtàold Prj stabile anche se migliorabile (win/web/monile, remot/ws/tcp, sql exp/wg/std/ent, Distr fail safe/load bal/amm.centralizzata, cluster/grid comp - Infrastruttura (hw, tec) vertivale, prima feat imp e studio fattibilità, techn. Excellence - e se poi ci vuole + di quello che si pensava Federico(formaz, complex, svil) - sapere quello che non si sa e l’impatto - sensibilità ed esperienza - piccoli passi, misurare la velocità e calcolare ora arrivo, - forse poi non serve dopo aver visto feature + imp.
- - Assembly i tipi che solitamente vengono rilasciati e riutilizzati insieme ? evoluti e rilasciati insieme, stesso versioning, impostazioni di sicurezza; stessi tipi privati, niente dipendenze cicliche tra Assembly- Namespace i tipi logicamente correlati, namespace organizzati (nidificazione e distribuiti tra Assembly) secondo relazione logica, ridurre dipendenze tra namespace distinti- Nomi pubblici classi->oggetti/concetti, membri->azioni/verbi e parametri->ruolo, con dei nomi intuitivi a prima vista per un nuovo utilizzatore - Responsabilità ripartite tra classispostare membri di classe che non assolvono alle responsabilità individuando la classe più adatta. - Non-classi soli dati o funz. Eliminare ridistr. Stato/Comp.- Dipendenze inutili e cicliche - (ora tipi sensati..) disegnare ed eliminare- Ereditarietà da trasformre in contenimento (Is o Has, 0 o 2+ o sempre e solo uno, cambio stato? - Classi metodi troppo lunghi- Algoritmi troppo complessi (variabili, flusso, scomposizione) TOP DOWN _BOTTON UP