Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introductie slides Agile Software Architecture


Published on

De introductie slides voor de cursus Agile Software Architecture, die gegeven wordt door het Nederlands Instituut voor de Software Industrie.
Voor meer informatie, kijk op

Published in: Software
  • Be the first to comment

  • Be the first to like this

Introductie slides Agile Software Architecture

  1. 1. Agile Software Architecture Course 2017-1 Slinger Jansen Sjaak Brinkkemper Jan Vlietland Garm Lucassen
  2. 2. NISI • Course is part of the Netherlands Institute for theSoftware Industry • NISI is a spin-off of Utrecht University • Mission: “make (scientific) knowledge useful for practice, to advance the software industry, by means of courses and consultancy” • With the results we fund new scientific research
  3. 3. NISI Core Team
  4. 4. Course Team • Prof. dr. Sjaak Brinkkemper, Utrecht University • Dr. Jan Martijn van der Werf, Utrecht University • Dr. Slinger Jansen, Utrecht University • Drs. Michiel Overeem, Senior Architect, AFAS Software • Drs. Martijn Cox, Senior Architect, ARS • Dr. Jan Vlietland, Director, NISI • Drs. Garm Lucassen, PhD Student, lecturer
  5. 5. Who am I? Dr. Slinger Jansen, assistant professor, Utrecht University, the Netherlands Author of several books Acquired funding in excess of 2mln euro Software ecosystems “expert”
  6. 6. Goal of the Course • Promoting thinking from junior architects to senior architects through – State of the Art education resources – Practical cases (AFAS, Netflix, Chrome, etc.) – Discussion of current architecture – Exchange of experiences and ideas
  7. 7. Program: Session 1 Agile Architecture • Management decisions • Software product management and architecture • Agility in Architecture Design • Runtime monitoring • Collaboration in Architecture Design • Homework: send 2 slides introducing yourself to
  8. 8. Program: Session 2 Architecture as a Platform for Decision Making • Making decisions in architecture • Traceability of decisions • Decision documentation • Architecture erosion • Architecture “smells” • Homework: Describe three decisions made about your architecture in three slides. – One decision that is obvious and adopted well – One decision that needs to be explained repeatedly – One decision that is being ignored
  9. 9. Program Session 3: Architecture Perspectives, Styles, and Patterns • Modelling architecture • Documenting architecture • Web architectures • Simulating architecture • Green Software • Homework: Send three slides to describing how your software could be greener.
  10. 10. Program Session 4: Quality Attributes • ISO-standard 9001 • Evaluation of quality attributes • Safety, privacy, and security • Architecture evaluation and the TIOBE index • Architecture evaluation methods • Homework: What are the issues you encounter regarding privacy, safety, and security? Max 5 slides.
  11. 11. Program Session 5: Feedback and Monitoring in Architecture • Monitoring as architecture aspect • Mechanisms for Feedback • Who watches the watchmen? • Distributed systems and Microservices • Performance engineering • Read the supplied architecture document. Suggest 3 possible improvements in an email to to the architecture. Max 2A4.
  12. 12. Program Session 6: Architecture Evolution • Evolvability of an Architecture • From technical debt to technical surplus • Transitioning to Cloud • Internet of Things Architectures • Homework: How could parts of your architecture be transitioned to the cloud? Explain in 3-5 slides and send to
  13. 13. Program Session 7: Evaluation in Practice • How to evaluate an architecture in practice? – Case: Chrome – Case: Netflix • Homework: Present your own architecture.
  14. 14. Program Session 8: Evaluation in Practice II • Evaluate each other’s architectures • Exam • Diploma ceremony
  15. 15. Preparing questions • What is your role? • Software development, software architecture (support) or a business role? • How many years of experience do you have with architecture? • Which products are developed in your company / unit and for which markets? • How often would you like to release new product versions to the market? • How large is your company (and your unit)? • What is your largest customer network and how big is your network? • Can you briefly describe the IT landscape?
  16. 16. Participants Various roles: • Senior Software Developer • Junior software architect • Senior software architect • Technical software product manager
  17. 17. Participants Average years of experience with architecture: • None to little • 1 year • 2-5 years • 5+ years
  18. 18. Participants Product & Services: • Consulting (1) • Public Transport (2) • Enterprise Resource Planning (4) • Public sector (2) • Finance (1) • Health care (1)
  19. 19. Participants Company size • >1.000 • 100 – 1000 • 10 – 100
  20. 20. Participants Used technology:
  21. 21. Participants Needs • What is your biggest Architecture impediment? • What do you hope to find in this course? • As many needs as participants!
  22. 22. Today’s Program (Cont’d) Agile Software Architecture • What are management decisions in architecture? • Software product management and architecture • Agility in Architecture Design • Openness in Architecture • Collaboration in Architecture Design
  24. 24. Motivation for Architecture • Software systems are rapidly and continuously growing in size and complexity • Techniques and tools for developing and maintaining such systems typically play catch-up • To deal with this problem, many approaches exploit abstraction – Ignore all but the details of the system most relevant to a task (e.g., developing the user interface or system-level testing) – This greatly simplifies the model of the system – Apply techniques and tools on the simplified model – Incrementally reintroduce information to complete the “picture” • Software architecture is such an approach – Applicable to the task of software design
  25. 25. What is Architecture? • A high-level model of a thing – Describes critical aspects of the thing – Understandable to many stakeholders • architects, engineers, workers, managers, customers – Allows evaluation of the thing’s properties before it is built – Provides well understood tools and techniques for constructing the thing from its blueprint • Which aspects of a software system are architecturally relevant? • How should they be represented most effectively to enable stakeholders to understand, reason, and communicate about a system before it is built? • What tools and techniques are useful for implementing an architecture in a manner that preserves its properties?
  26. 26. The architecture of a packing robot control system
  27. 27. Architecture: Our Definition • An abstraction for a software part (system, program, package, class) that focuses on uses, structure, issues, and risks • Uses: How users (people and other software) interact with a part and how the part responds • Structure: The collection of parts and their interactions and dependencies • Issues: Things that developers are concerned about, like complexity for a large system, ease of use, robustness • Risks: Potential for unwanted results, often related to performance, safety, and financial and security threats
  28. 28. Intent • When we develop software, we want our software to have an architecture developed explicitly, not accidentally. • Its purpose is to allow us to think critically about a product we are developing before committing to code. • For large systems an architecture may be represented by a, possibly large, document. • For smaller systems and programs it may be presented on a web page or small collection of diagrams and notes, bound together in some form of accessible container.
  29. 29. Architecture Level • Systems: – We usually think of an architecture as describing some large, distributed system. • Packages: – But packages also have architectures: uses, users, structure, and issues. – Package structure relates to the package’s classes and how they interact. • Classes – Even a class has an architecture defined by its methods, data structures, and how they interact.
  30. 30. The organization of the Model-View-Controller Chapter 6 Architectural design 30
  31. 31. Web application architecture using the MVC pattern
  32. 32. What Is Software Architecture? • The architecture of a software system captures major features and design ideas for a software development project. • Describes relationship of users with the system • Describes structure and organizing principles of the system – Major partitions within the system and their interfaces – Responsibilities of, and resources needed by, each partition – Design concepts: data structures, algorithms, data flows that help developers understand and implement their piece of the system • Identifies major threads of execution • Identifies critical timelines and risk areas – A timeline is a time-based budget for critical threads. – A risk area identifies objectives and requirements that will be difficult to meet under the current architectural and design concept or susceptibility to threats.
  33. 33. Architectural Concerns • Goals: Main objectives of the system • Uses: How people and other software will interact with the system • Tasks: Activities for a system and its major partitions • Partitions: Subsystems, packages, and classes that make up the system; responsibilities • Interactions: The relationships and data flows between partitions, and assumptions that partitions have about each other • Events: Any occurrence that affects system activities • Views: Appearance of the system to users and its designers • Performance: Efficient use of computer resources—processor cycles, network bandwidth, memory
  34. 34. The software architecture of an ATM system
  35. 35. Excerpt, slides deliberately left out
  37. 37. Architectural design • An early stage of the system design process. • Represents the link between specification and design processes. • Often carried out in parallel with some specification activities. • It involves identifying major system components and their communications.
  38. 38. Architectural abstraction • Architecture in the small is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components. • Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies.
  39. 39. Advantages of explicit architecture • Stakeholder communication – Architecture may be used as a focus of discussion by system stakeholders. • System analysis – Means that analysis of whether the system can meet its non- functional requirements is possible. • Large-scale reuse – The architecture may be reusable across a range of systems – Product-line architectures may be developed.
  40. 40. The architecture of a language processing system Chapter 6 Architectural design 40
  41. 41. Architectural design decisions • Architectural design is a creative process so the process differs depending on the type of system being developed. • However, a number of common decisions span all design processes and these decisions affect the non-functional characteristics of the system.
  42. 42. Architectural design decisions • Is there a generic application architecture that can be used? • How will the system be distributed? • What architectural styles are appropriate? • What approach will be used to structure the system? • How will the system be decomposed into modules? • What control strategy should be used? • How will the architectural design be evaluated? • How should the architecture be documented?
  43. 43. Architecture reuse • Systems in the same domain often have similar architectures that reflect domain concepts. • Application product lines are built around a core architecture with variants that satisfy particular customer requirements. • The architecture of a system may be designed around one of more architectural patterns or ‘styles’. – These capture the essence of an architecture and can be instantiated in different ways.
  44. 44. A repository architecture for an IDE
  45. 45. Overview A framework for architectural knowledge management (domain models, rule engine, and visualization components) - Automatic annotation of architectural-significant elements - Population & recommendation of architecture alternatives and software solutions to realize architectural design decisions - Extract architectural decisions (focus on technical decisions) from issue management system - Classify them as either structural, behavioral, or banned decisions - Extract – who raised the concern, who took the decision and when was the decision made from the issue management system (what is implicit) - Build user profiles based on the above information Use the AKM model, user model, and a set of simple heuristics to predict the possible architectural decisions that will be taken by an architect
  46. 46. Architecture design decision model 170217 Manoj (© Florian Matthes, 2016) 46
  47. 47. • Existing work on ADD models do not consider user preferences, project context, and heuristics to support the decision making process • AIM • Extract who took the decision, how long did it take to implement, complexity of tasks involved based on source code changes • Extract a decision makers’ preferences related to technologies and types of issues handled to build user profiles. • RESULT • Combining user profiles with the ADD model should support the recommendation of • Who should be responsible to address a specific concern? • What is the cost of addressing a specific concern? Who did what, and when? • Who did what and when? • Use issue management system as the main input source • Focus on a specific domain (e.g. analytics domain) and system (e.g. component-based) ?
  48. 48. Example • Sensitive case information…
  50. 50. Architecture Openness • Architectural Openness Model • Architectural Openness Factors • Openness in Five Main Mobile Platforms
  51. 51. Results: Architectural Openness Model Applications Middleware Kernel Extended ApplicationsNative Applications App 1 App 2 App 3 App N... (Services, Libraries, Frameworks …) (Device Drivers, Memory Management, Power Management, Security …) App 1 App 2 App 3 App M... 51 Platform Architecture Symbian Architecture Android Architecture + Platform Accessibility Integrate Extend Modify Integrate Extend Modify Integrate Extend Modify Integrate Extend Modify Architecture (Cho and Jeon, 2007) iPhone Architecture
  52. 52. Results: Architectural Openness Factors Layer Factor Possibility statuses If possibleLicensing statuses Extended applications Integrate extended applications Possible/ Possible for some components/ Not possible Permission is not needed/ In some situation permission is needed/ Permission is always needed Extend extended applications Modify extended applications Native applications Integrate native applications Extend native applications Modify extended applications Middleware Integrate middleware Extend middleware Modify middleware Kernel Integrate kernel Extend kernel Modify kernel
  53. 53. Results: Openness in Five Main Mobile Platforms Android Applications Middleware Kernel Extended ApplicationsNative Applications Home Contacts Phone Browser... App1 App2 App3 AppN... Application Framework Libraries Android Runtime Activity Manager Windows Manager Content ProvidersPackage Manager Telephony Manager Resource Manager View System Location Manager Notification Manager Device Drivers (Display, Camera, IPC, Flash Memory, Audio, WiFi, Keypad…) Power Management Surface Manager Media Framework SQLite OpenGL | ES FreeType WebKit SGL SSL Core Libraries Dalvik Virtual Machine Integrate Extend Modify Integrate Extend Modify Integrate Extend Modify Integrate Extend Modify Security Memory Management ... Possible / Permission is not needed Possible for some components / Permission is not needed Possible / In some situation permission is needed Possible for some components / In some situation permission is needed
  54. 54. Results: Openness in Five Main Mobile Platforms iPhone Applications Middleware Kernel (Core OS) Extended ApplicationsNative Applications App 1 App 2 App 3 App N... Integrate Extend Modify Integrate Extend Modify Integrate Extend Modify Integrate Extend Modify ... App 1 App 2 App 3 App M... Core Services Drivers Security Framework CFNetwork Accessory Framework ... Address Book Core Data Framework Core Location Framework SQLite Core Foundation Framework ... In App Email Map Kit Framework Address Book UI Framework UIKit Framework Apple Push Notification Service ... Cocoa Touch Graphics Framework Audio Framework Video Framework Media Possible / Permission is always needed Possible for some components / Permission is always needed Not possible
  55. 55. Comparison Factor Android Symbian Windows Mobile Blackberry iPhone P L P L P L P L P L Integrate extended applications Extend extended applications Modify extended applications Integrate native applications Extend native applications Modify native applications Integrate middleware Extend middleware Modify middleware Integrate kernel Extend kernel Modify kernel P - Possibility: Possible (Green), Possible for Some Components (Yellow), Not Possible (Red) L - Licensing: Permission is Not Needed(Green), In some cases permission is needed(Yellow), Permission is Always Needed(R), N/A(Gray)
  56. 56. Conclusions • Proposed architectural openness model shows how the openness strategies of mobile platform suppliers affect the software architecture of the platforms • Proposed architectural openness factors shows how open the mobile software platforms are • Based on the model and the factors, the openness degree of five main mobile platforms is identified • Qualitative interviews validate the previous conclusion • Interviews show application developers don’t care about architectural openness of their favorite platforms • Interview with Some Device Manufacturers, and Mobile Suppliers is recommended
  57. 57. Discussion: How could Android be more open?
  58. 58. Group discussion: How open is eSDK? EMUI?
  59. 59. Excerpt, slides deliberately left out
  60. 60. Course website You will receive the slides by mail or via the website
  61. 61. Information For more information about the course you can contact • Slinger Jansen • • 06 – 19884880 Don’t forget to submit your homework! +31(0)30 - 268 5398 Copyright © 2017 Netherlands Institute for the Software Industry (NISI) and Utrecht University