Post on 27-Mar-2015
transcript
Made available under EPL v1.0 1
OpenUP/Basic 1.0 Architecture Content
Jim Ruehlin
Mark Dickson
Denise Cook
Made available under EPL v1.0 2
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
Made available under EPL v1.0 3
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
Made available under EPL v1.0 4
What’s 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– It’s job is to describe significant aspects of the BUILD product
Made available under EPL v1.0 5
What’s 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
Made available under EPL v1.0 6
Clarifying some concepts
Made available under EPL v1.0 7
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
Made available under EPL v1.0 8
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
Made available under EPL v1.0 9
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.15am3.20pm
Made available under EPL v1.0 10
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 architecture’s 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 it’s worth explaining, then it’s probably part of the architecture”
Made available under EPL v1.0 11
• The only mechanism is the “architectural mechanism”• A mechanism goes through three states – analysis and
design and implementationAnalysis: PersistenceDesign: 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
Made available under EPL v1.0 12
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 ifYou 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.
Made available under EPL v1.0 13
Modifying OpenUP/Basic Inception
Does this need to beproven in software?
Yes, if it is a new or unprecedented system
Made available under EPL v1.0 14
Show me the software…
There are no DevelopmentTasks here
Determine ArchitecturalFeasibility
We are removing these…
Made available under EPL v1.0 15
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
act Determine Architectural Feasibility
Analyse ArchitecturalRequirements
Dev elop the Solution
Validate Build
Produces a shared vision of the solution & architectural priorities
Refines the architecture & proves it with working software.Demonstrates working development environment.
Validates the build against requirements.Demonstrates working test environment.Not necessarily production-ready software.
End
Inception iteration(s)
Made available under EPL v1.0 16
OpenUP/Basic Elaboration
For requirements within context
Made available under EPL v1.0 17
What’s 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
Made available under EPL v1.0 18
Related Bugzillas
https://bugs.eclipse.org/bugs/show_bug.cgi?id=165258https://bugs.eclipse.org/bugs/show_bug.cgi?id=165217https://bugs.eclipse.org/bugs/show_bug.cgi?id=165217https://bugs.eclipse.org/bugs/show_bug.cgi?id=165245https://bugs.eclipse.org/bugs/show_bug.cgi?id=172250
Made available under EPL v1.0 19
Thankyou
Made available under EPL v1.0 20
Made available under EPL v1.0 21
Made available under EPL v1.0 22