1. Made available under EPL v1.01 OpenUP/Basic 1.0 Architecture Content Jim Ruehlin Mark Dickson Denise Cook

2. Made available under EPL v1.02 Why are we here? Architecture in OpenUP/Basic is turning into something different from RUP for Small Projects and BUP. The Architecture content needs to be smoothly integrated with the rest of OpenUP/Basic, and be consistent with it. We need to establish a common understanding and validate the approach with the rest of the team to move forward with confidence for OpenUP/Basic 1.0

3. Made available under EPL v1.03 OpenUP/Basic Architecture Aspects to discuss Small, agile teams must be able to do architecture and get to software quickly, with quality results –quickly agree big ticket items (Big Picture Up Front) –address discrete areas for requirements in context during development OpenUP/Basic promotes a just enough architecture or barely enough architecture philosophy –Traditionalist reading of RUP/UP can imply lots of up-front architectural analysis –OpenUP/Basic encourages just enough up-front analysis to get started, complemented by continuous evaluation and improvement throughout development The Architect Role is shared in a small agile team – architecture is a collective activity –Small teams encourage role sharing, especially amongst peers –It becomes specialized in larger teams, where there is less fluidity in role assignment The Architectural mechanism is a simple concept that is becoming difficult to explain (!) Analysis, design, implementation mechanisms

4. Made available under EPL v1.04 Whats the proposal? (1/2) Up front architectural analysis is minimal but complete –Just enough to enable development –Driven by requirements –Quickly performed –Proven in software Early architecture work provides a shared mental model for development –Illustrated where appropriate –Prioritizes architecturally significant development There is ONE architecture product – the Architecture Description –Its job is to describe significant aspects of the BUILD product

5. Made available under EPL v1.05 Whats the proposal? (2/2) The architecture of the software evolves throughout the project and is software-centric and is proven through increments of the BUILD product Architecture Mechanisms simplified as a single concept, represented by states –Mechanisms are an aspect of the Architecture Description The Architect ROLE is shared by team members –Small teams can, do (and often must) share roles Collaboration across ROLES is demonstrated through capability patterns (Activities) –Proving the architecture through software is a DEVELOPMENT activity

6. Made available under EPL v1.06 Clarifying some concepts

7. Made available under EPL v1.07 Clarifying some Concepts (1) – Architectural Analysis What is the objective of Architectural Analysis? –manufacture analysis models as a step towards design and code? NO! –understand the architecturally significant requirements so that an appropriate architecture can be derived and communicated? - YES The Task name has evolved over time –RUP : Architectural Analysis –BUP : Analyse the Architecture –OpenUP/Basic 0.9 : Analyse Architectural Requirements The name is *really* important –The principal work is analysing the significant requirements –The principal output is the Architecture product (not a Build) Could there be a clash of concepts here between analysis of requirements and Analysis models? –We could consider renaming the Task to Identify Candidate Architecture –But the work is rooted in examining and responding to requirements

8. Made available under EPL v1.08 Comprehension Gap (2) Roles not People OpenUP/Basic is aimed at small teams –4-6 people? –up to 10 people? OpenUP/Basic has 5 roles –(not including Any Role) In this context, roles are highly likely to be shared amongst team members But we seem to keep confusing the roles with people –This is a classic RUP anti-pattern! Maybe this is why EssUP dropped Roles for Competencies? –Amounts to the same thing but de-emphasises JOB

9. Made available under EPL v1.09 Small Team Scenario Janet is a Developer. See Janet writing code. Oh. says Janet, I need some code to authenticate the user. See Janet look at the requirements and make some sketches. Janet is an Architect. Janet writes the first draft code for the mechanism. Janet is a Developer again. Janet discusses the Authentication mechanism with John and shows him some code. I like this, says John, We should apply this consistently across the software. John is an Architect. Janet is an architect too. See them communicate the authentication mechanism to the team. Janet is a Developer. See Janet re-factoring the authentication code. See Janet integrate the code with the Build. See Janet run a test case against the new software. Janet is a Tester. (Run Janet, Run) 9.25am 11.15am 3.20pm

10. Made available under EPL v1.010 One Architecture Artifact Architecture Description: The description of the architecture as it should be (or as it as after the implementation) – will include one or more of the following: Architectural mechanisms Architectural decisions and constraints Models of architectures structure & behavior References to architecturally significant requirements Critical interface descriptions Component list Concept: Executable Architecture: A base-lined BUILD that proves a subset of the architecture can fulfill its purpose, as defined by the architectural objectives of a particular iteration –Developed against requirements in context, during an iteration –Is produced by Development Tasks, against architecturally significant requirements The design can be rendered to or from an existing system The architecture explains the motivation for decisions and constraints –If its worth explaining, then its probably part of the architecture

11. Made available under EPL v1.011 The only mechanism is the architectural mechanism A mechanism goes through three states – analysis and design and implementation Analysis: Persistence Design: A DB2 relational database with the following needs/constraints… Implementation – the code (diagrams can help wrote the code for more complex mechanisms) Question: If the implementation (pattern) is code, which Role creates it? Architectural Mechanisms

12. Made available under EPL v1.012 Architectural Discovery Initial (PoC) Objective Not Met Final Executable Architecture Envisioned Architecture The architecture of software can (and probably will) evolve into something that we did not expect at the beginning of the project. This is entirely normal and is called Learning (or adaptive software development if You want to impress your friends). If you have a documented architecture and it does not match the software (and the software is good), you probably need to change your document.

13. Made available under EPL v1.013 Modifying OpenUP/Basic Inception Does this need to be proven in software? Yes, if it is a new or unprecedented system

14. Made available under EPL v1.014 Show me the software… There are no Development Tasks here Determine Architectural Feasibility We are removing these…

15. Made available under EPL v1.015 Determine Architectural Feasibility The big difference between this and Elaboration is that we seek to prove that the software has the basis of a sound architecture We do this with working software This is roughly speaking the equivalent of an XP spike The work does not have to be of finished quality The results are refined through future phases

16. Made available under EPL v1.016 OpenUP/Basic Elaboration For requirements within context

17. Made available under EPL v1.017 Whats Different? No architectural PoC –The PoC is the first/early state(s) of the Build –It evolves over time into production quality software Development can happen in Inception! Project iterations have architectural objectives as well as functional objectives More of the architecture is defined through evolution rather than analysis –Identifying fragile/critical areas –Architectural enforcement –Validating & discovering specific strategies One Architecture product: Architecture Description –Can be a document or just some sketches Team members are more involved in architectural decisions through Role sharing –Objectives –Abstractions/Analysis classes –Defining internal behavior –Architectural mechanisms Content structure for Architecture Mechanisms is simplified –But meaning and approach is retained

18. Made available under EPL v1.018 Related Bugzillas https://bugs.eclipse.org/bugs/show_bug.cgi?id=165258 https://bugs.eclipse.org/bugs/show_bug.cgi?id=165217 https://bugs.eclipse.org/bugs/show_bug.cgi?id=165245 https://bugs.eclipse.org/bugs/show_bug.cgi?id=172250

19. Made available under EPL v1.019 Thankyou

20. Made available under EPL v1.020

21. Made available under EPL v1.021

22. Made available under EPL v1.022