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

Made available under EPL v1.0 1

OpenUP/Basic 1.0 Architecture Content

Jim Ruehlin

Mark Dickson

Denise Cook


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


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


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


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


Clarifying some concepts


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


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


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


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”


• 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


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.


Modifying OpenUP/Basic Inception

Does this need to beproven in software?

Yes, if it is a new or unprecedented system


Show me the software…

There are no DevelopmentTasks here

Determine ArchitecturalFeasibility

We are removing these…


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)


OpenUP/Basic Elaboration

For requirements within context


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


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

https://bugs.eclipse.org/bugs/show_bug.cgi?id=165258






Thankyou

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

Documents

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