1 / 22

OpenUP/Basic 1.0 Architecture Content

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.

trella
Télécharger la présentation

OpenUP/Basic 1.0 Architecture Content

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 3.20pm 9.25am 11.15am 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 writing code. 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) “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. 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. Architectural Mechanisms • 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? Made available under EPL v1.0

  12. Architectural Discovery Initial (PoC) Envisioned Architecture Final Executable Architecture Objective Not Met 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. Made available under EPL v1.0

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

  14. Show me the software… Determine Architectural Feasibility There are no Development Tasks here 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 Made available under EPL v1.0

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

  17. 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 What’s Different? Made available under EPL v1.0

  18. 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=165217 https://bugs.eclipse.org/bugs/show_bug.cgi?id=165245 https://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. Made available under EPL v1.0

More Related