Software Architecture of Oviedoof University Software taxonomies Patterns, styles, tactics,... Science Computer of of Course 2018/2019 Jose E. Labra Gayo School Software Architecture Software taxonomies of Oviedoof Construction & Maintenance University Configuration management Modularity Decomposition at building time Runtime Components and connectors Integration Allocation Science Packaging, distribution, deployment Business and enterprise environment Computer of of School Software Architecture of Oviedoof University Software construction & maintenance Science Computer of of Course 2018/2019 Jose E. Labra Gayo School Software Software School of Computer Science University of Oviedo maintenance Software construction & Configuration management Architecture Software Architecture Software: product or service of Oviedoof Software as a Product (SaaP): University Software deliverable Commercial model: software is sold to clients Software distributed or downloaded Example: Microsoft Office Software as a Service (SaaS): Software deployed Commercial model: clients subscribe to it Software usually available at some URL Science Example: Google docs Computer of of School Software Architecture Software configuration management of Oviedoof Managing the evolution of software University Manages all aspects of software construction Especially, how software evolves and changes Aspects: Identifying baselines and configuration items Baseline: A work product subject to management It contains configuration items: documents, code files, etc... Configuration control & auditing Version control systems Science Building management and automation Computer Teamwork of of Defect and issues tracking School Software Architecture Software construction of Oviedoof Overview of methodologies University Traditional, iterative, agile Construction tools Languages, tools, etc. Science Computer of of School Software Architecture Incremental piecemeal of Oviedoof Development by need University Codification without following the architecture Throw-away software Budget constraints Science Computer of of School Software Architecture Waterfall of Oviedoof Software development life cycle (SDLC) University Waterfall model identified as antipattern in 1970s Requirements Design Implementation Verification Science Computer of of Maintenance School Software Architecture V Model of Oviedoof Detail University Level Requirements Aceptance Testing Low System Analysis Testing Integration Design Testing Project Definition Object Unit Design Testing Project Science Test and High Implementation Integration Computer of of School Time Software Architecture Big Design Up Front of Oviedoof Anti-pattern of traditional models University Too much documentation that nobody reads Documentation different from developed system Architecture degradation Software implemented but unused Science Computer of of School Software Architecture Iterative Models of Oviedoof University Based on Prototypes Risk assessment after each iteration Requirements Analysis & Initial Design Planning Planning Implementation Deployment Science Evaluation Computer of of Testing School Software Software School of Computer Science University of Oviedo Architecture Software Architecture Agile methodologies of Oviedoof Lots of variants University RAD (www.dsdm.org, 95) SCRUM (Sutherland & Schwaber, 95) XP - eXtreme Programming (Beck, 99) Feature driven development (DeLuca, 99) Adaptive software development (Highsmith, 00) Lean Development (Poppendieck, 03) Crystal Clear (Cockburn, 04) Agile Unified Process (Ambler, 05) Science . Computer of of School Software Architecture Agile methods of Oviedoof University Agile Manifesto (www.agilemanifesto.org) Individuals and Processes and over interactions Tools Working Comprehensive over Software Documentation Customer over Contract Science Collaboration Negotiation Computer of of Responding over Following a School to change Plan Software Architecture Agile methods of Oviedoof Feedback University Changes of code are OK during development Minimize risk Software in short intervals Iterations of days Each iteration takes all the development cycle Science Computer of of School Software Architecture Some agile principles (XP) of Oviedoof 1. Adapt to change University 2. Testing 3. Pair programming 4. Refactoring 5. Simple design 6. Collective code ownership 7. Continuous integration 8. On-site customer Science 9. Small releases 10.Sustainable pace Computer of of 11.Coding standards School Software Architecture Adopt change of Oviedoof University After each iteration, update plans Requirements through user stories Short descriptions (size of a card) Goals ordered by usnig according to priority Risk and resources estimated by developers User stories = acceptance testing Wellcome changing requirements Science Original plan Computer of of Current plan School Software Architecture TDD - Test driven development of Oviedoof Write a test before coding University Initially, code will fail Goal: pass the test Result: Automated set of tests Easier refactoring Science Computer of of School Software Architecture Different types of testing of Oviedoof Unit testing University Check each unit separately Integration testing Smoke testing Acceptance testing Check with user stories Performance/capacity testing: Load testing Regression testing Check that new changes don’t introduce new bugs, or Science regressions Computer of of School Software Architecture Types of testing of Oviedoof University Business facing Automated Manual Showcases Functional Acceptance Usability testing Critique project Testing Exploratory testing Unit testing Nonfunctional Integration testing Acceptance testing System testing (capacity, security,…) Support Support programming Automated Manual/ Automated Science Technology facing Computer of of School Source: Continuous delivery, J Humble, D. Farley, 2010 Software Architecture Acceptance testing of Oviedoof Behavior-driven development (BDD) University Tests come from user stories They can be written collaboratively with the client Tools: Cucumber, JBehave, Specs2,... Tests act as contracts Can also be used to measure progress Feature: Buscar cursos Para mejorar el uso de los cursos Los estudiantes deberían ser capaces de buscar cursos Scenario: Búsqueda por asunto Science Given hay 240 cursos que no tienen el asunto “Biología” And hay 2 cursos A001, B205 que tienen el asunto “Biología" When Yo busco el asunto “Biología" Computer Then Yo debería ver los cursos: of of | Código | | A001 | School | B205 | Software Architecture Testing: FIRST Principles of Oviedoof University F - Fast Execution of (subsets of) tests must be quick I - Independent: No tests depend on others R - Repeatable: If tests are run N times, the result is the same S - Self-checking Test can automatically detect if passed Science T - Timely Tests are written at the same time (or before) code Computer of of School Software Architecture Test doubles of Oviedoof University Dummy objects: Objects that are passed but not used Fake objects: Contain a partial implementation. Stubs: contain specific answers to some requests Spies: stubs that record information for debugging Mocks: mimic the behavior of the real object Mocks may contain assertions about the Science order/number of times methods are called Computer Fixtures: Tools that support tests of of Testing databases, some files, etc. School Software Architecture Environments of Oviedoof University Development Testing Production environment Environments Environment Testing Server Production Server Version Science Server farm Control Integration Server Computer of of A staging environment is also used School Software Architecture Pair programming & Code reviews of Oviedoof 2 software engineers work together University Driver manages keyboard and creates implementation Observer identifies failures and gives ideas Roles are exchanged after some time Pull requests: Before accepting changes, code can be reviewed Science Computer of of School Software Architecture Simplicity of Oviedoof Favor Simple design University Reaction to Big Design Up Front Obtain the simpler design that works Automated documentation JavaDoc and similar tools Science Computer of of School Software Architecture Refactoring of Oviedoof Improve design without changing functionality University Simplify code (eliminate redundant code) Search new opportunities for abstraction Regression testing Based on the test-suite Science Computer of of School Software Architecture Collective ownership of code of Oviedoof Code belongs to the project, not to some engineer University Engineers must be able to browse and modify any part of the code Even if they didn't wrote it Avoid code fragments that only one person can modify Science Computer of of School Software Architecture Continuous Integration of Oviedoof Frequently integrating one's new or changed code University with the existing code repository Running all unit and integration tests Merge all developer working copies Goals Help Test Driven Development Maintain all programmers code up to date Avoid integration hell Science Computer of of School Software Architecture of Oviedoof Continuous Integration University Best practices: Maintain code repository Automate the build Make the build self testing Everyone commits to the baseline Every commit should be built Keep the build fast Test in a clone of the production environment Make it easy to get the latest deliverables Science Everyone can see the results of the latest build Automate deployment Computer of of