1 / 40

Designing, Implementing and Dynamically Changing Applications

Designing, Implementing and Dynamically Changing Applications. an approach based on software architectures. Richard N. Taylor Institute for Software Research University of California, Irvine taylor@uci.edu www.ics.uci.edu/~taylor. Outline. Architecture-based software engineering

codym
Download Presentation

Designing, Implementing and Dynamically Changing Applications

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. Designing, Implementing and Dynamically Changing Applications an approach based on software architectures Richard N. Taylor Institute for Software Research University of California, Irvine taylor@uci.edu www.ics.uci.edu/~taylor

  2. Outline • Architecture-based software engineering • Architectural styles • Dynamic change • Engineering environment • Current projects

  3. Architecture-Based Software Engineering • Requirements and domain engineering precede • OOD may supplement; coding follows “An approach to software systems development which uses as its primary abstraction a model of the system’s components, connectors, and interconnection topology”

  4. Examples • Compilers • Unix-style pipe-and-filter applications • A family of video games • Guidance-navigation-control systems for rotorcraft • An open software development environment

  5. Intellectual control over complexity via abstraction via well-understood patterns of composition Communication of system design via explicit description of system structure and properties Basis for controlled, predictable, dynamic adaptation via separation of computation from communication Reduced costs and improved time to market via reuse of components, families, and domain knowledge via better focused testing Higher quality products via reuse of trusted components via early analysis capabilities Improved chances for interoperability via explicit, exposed interfaces via separation of computation from communication Benefits

  6. What’s Needed to Support It? • Appropriate descriptive formalisms • Architecture description languages (ADLs) • Tools • to carry out analyses, support editing, generate code, support run-time dynamism, etc. • Processes • to create or recover architectures • to integrate architecture-based development into the broader development and organizational contexts

  7. So What’s New? • The degree to which architectures are made explicit, and how they are described • Using the description as the basis for evolution (static and dynamic) • it is not a throw-away model • The degree to which communication is separated from computation • The prominence given to connectors

  8. Outline • Architecture-based software engineering • Architectural styles • Dynamic change • Engineering environment • Current projects

  9. Architectural Styles • “Walk like this!” • “Why should I walk like that?” • Canonical structures and rules • provide context • focus attention • promote shared understanding • carry hard-won domain knowledge and proven solution techniques

  10. Classical Styles • Pipe-and-filter • Blackboard • Client-server • “Three tier” • State machine

  11. The C2 Style • Autonomous components • own thread and non-shared address space • All communication is by asynchronous events which must pass through a connector • connectors may be complex and powerful • Some additional rules to promote reuse • (A variety of implementation techniques)

  12. Intellectual Heritage • Domain-specific software architectures • concurrent, loosely coupled, distributed, dynamic apps • Smalltalk’s model-view-controller paradigm • Field’s event-based integration • Abstraction and separation of concerns • OO typing • Lisp, et.al.s dynamic properties

  13. A Second Look at the C2 Style • Asynchronous, event-based communication among autonomous components, mediated by active connectors • No component-component links • Event-flow rules: • Hierarchical application Connector Notifications fall “pull” Requests rise Component “push” Connector

  14. Clocklogic StatusADT ChuteADT WellADT PaletteADT Next tileplacing logic Tile matchlogic Relative poslogic Statuslogic Statusartist Wellartist Chuteartist Paletteartist Tileartist Layoutmanager Graphicsbinding A Simple Example: KLAX • KLAX™ game • 16 components, approx. 4k SLOC, 100kb compiled • implemented from scratch inthe C2 architectural style[TMA+96]

  15. High scoreADT ClientADT Clocklogic StatusADT ChuteADT WellADT PaletteADT Next tileplacing logic Tile matchlogic Relative poslogic Next letterplacing logic Word matchlogic High scorelogic Statuslogic Statusartist Wellartist Chuteartist Paletteartist High scoreartist Clientartist Tileartist Letterartist Layoutmanager Graphicsbinding KLAX: Adaptability • Spelling KLAX • spell words from falling letters • replaces 3 components • High score list • adds 3 new components • Multi-player networked KLAX • a match adds a tile toopponents’ chute

  16. High scoreADT ClientADT Clocklogic StatusADT ChuteADT WellADT PaletteADT Next tileplacing logic Tile matchlogic Relative poslogic Next letterplacing logic Word matchlogic High scorelogic Statuslogic Statusartist Wellartist Chuteartist Paletteartist High scoreartist Clientartist Tileartist Letterartist Layoutmanager Graphicsbinding KLAX: Combinations • Spelling KLAX • spell words from falling letters • replaces 3 components • by “the team” • High score list • adds 3 new components • by ICS 125b team • Multi-player networked KLAX • a match adds a tile toopponents’ chute • by ICS 125b team

  17. Rolling Your Own Style • What goals is the style designed to help you achieve? • performance? • initial development time? • understandability? • long term adaptability? • It’s a bit of a tricky business… • rules, methods, consistency, well-defined, over-constrained

  18. Outline • Architecture-based software engineering • Architectural styles • Dynamic change • Engineering environment • Current projects

  19. Dynamic Change • Why? • Reasons for change: errors, improvements • Dynamic: may have no choice • Where? • What’s the abstraction level of the concept being changed? • What levels do the mechanisms available offer? • How?

  20. Conceptual View of Architecture-Based Runtime Change Consistency

  21. Internet add-on request Dynamic Change Example

  22. add-on install script add-oncomponents& connectors(compiled) public void performInstall(ExtensionWizard ew) { ew.send( ArchADTC2.defineType("Planner", IArchADT.COMPONENT_TYPE, "Planner") ); ew.send( ArchADTC2.defineType("Planner", IArchADT.COMPONENT_TYPE, "PlannerArtist") ); ew.send( ArchADTC2.setAttribute("Planner", IArchADT.COMPONENT_TYPE, "Planner", ArchADTComponent.C2_IMPLEMENTATION_MODULE, "Planner.class") ); ew.send( ArchADTC2.setAttribute("Planner", IArchADT.COMPONENT_TYPE, "PlannerArtist", ArchADTComponent.C2_IMPLEMENTATION_MODULE, "PlannerArtist.class") ); ew.send( ArchADTC2.addInstance("Planner", "Planner", "planner") ); ew.send( ArchADTC2.addInstance("Planner", "PlannerArtist", "plannerArtist") ); ew.send( ArchADTC2.weld("Planner", "Bus1", ArchADTComponent.BOTTOM_PORT, "planner", ArchADTComponent.TOP_PORT) ); ew.send( ArchADTC2.weld("Planner", "planner", ArchADTComponent.BOTTOM_PORT, "Bus2", ArchADTComponent.TOP_PORT) ); ew.send( ArchADTC2.weld("Planner", "Bus3", ArchADTComponent.BOTTOM_PORT, "plannerArtist", ArchADTComponent.TOP_PORT) ); ew.send( ArchADTC2.weld("Planner", "plannerArtist", ArchADTComponent.BOTTOM_PORT, "Bus4", ArchADTComponent.TOP_PORT) ); ew.send( ArchADTC2.setAttribute("Planner", IArchADT.COMPONENT, "planner", ArchShellComponent.ARCHSHELL_RUNNING, ArchShellComponent.RUNNING_TRUE) ); ew.send( ArchADTC2.setAttribute("Planner", IArchADT.COMPONENT, "plannerArtist", ArchShellComponent.ARCHSHELL_RUNNING, ArchShellComponent.RUNNING_TRUE) ); } Clocklogic PortsADT VehiclesADT WarehousesADT Planner Next shipmentlogic query &modify Portartist Warehouseartist Vehicleartist Graphicalrouter Router Graphicsbinding Dynamic Change Example

  23. Architecture-Based Dynamism • Component and connector addition, removal, replacement, and reconnection • Requires consistency maintenance • some guaranteed by a priori analysis • on-the-fly constraint enforcement • faithful architectural model • mapping changes to the implementation • Requires minimal disruption • state preservation, replication, migration • near-continuous service availability • reverting to reliable configurations

  24. Key Facilitator: Connectors • Traditionally used in system modeling • explicit in design, indiscrete in implementation • Provide a critical abstraction for dynamism • should remain discrete, flexible entities in the implementation • mediate communication between components • specify communication mechanism independent of component behavior • encapsulate change application policy • boundaries for confining change scope • Communication using asynchronous messages • reduces component communication dependencies • how stateful is an event?

  25. Outline • Architecture-based software engineering • Architectural styles • Dynamic change • Engineering environment • Current projects

  26. Architecture-Based Engineering Environment • Functional areas: • Architecture development and analysis • From model to implementation • Evolution: static and dynamic • Rationale capture • Multi-model support • Our approach: bootstrapping

  27. Multi-model Support: xADL • XML-based representation of ADLs • core model • C2-specific additions • extensions done for Darwin, ACME, SADL • Available at http://www.ics.uci.edu/pub/arch/papers/KGOMT-SE.pdf

  28. Outline • Architecture-based software engineering • Architectural styles • Dynamic change • Engineering environment • Current projects

  29. Research Hypotheses • Software architecture is an appropriate basis for supporting adaptation • C2 provides important advantages as the architectural basis Experience with C2 has validated these hypotheses for software in “unconstrained” environments

  30. What Are The Constraints? (I) “Know the Size” • In C2 terms … • Determining appropriate component granularity for adaptive changes • Determining effect of variation in component size on characteristics of on-board architectural model • Tradeoff size against other performance constraints • Example: memory usage vs. compression/decompression overhead

  31. What Are The Constraints? (II) “Know the Time” • In C2 terms … • Establishing real-time guarantees for delivery of C2 requests & notifications • Establishing real-time guarantees for handling sensor interrupts • Establishing minimum times for making an adaptive change • Determining maximum simultaneity of actions • Predicting and maximizing connector throughput

  32. What Are The Constraints? (III) “Know the Overhead” • In C2 terms … • Minimizing overhead of adaptations • Minimizing overhead of maintaining on-board architectural model • Establishing failure semantics and overhead of failure recovery • Minimizing other contributors to overhead • power consumption, communication protocols, …

  33. The Silicon Nanosatellite

  34. d14 c14 a14 d13 b13 c13 a13 d12 b12 c12 a12 d11 b11 c11 a11 d10 b10 c10 a10 d9 b9 c9 a9 Nanosatellite Constellations • Dense LEO constellations • 500 to 1000 satellites at ~700 km altitude • at least 2 satellites always above 30o elevation for all surface locations • one satellite always within 1000 km range • Local clusters (“platooning”) • co-orbiting clusters up to 10 km diameter in LEO • arbitrary “formation flying” up to 10 km diameter in GEO • “rigid array” orbits • Adaptation • general-purpose versus specialized nanosatellites • changes in orbital configuration • failure and threat recovery

  35. Ad-hoc Networks • No pre-existing network infrastructure • self configuring • node discovery • routing discovery • multihop • spontaneous networks • highly portable • short lived • membership diversity and tenure • Highly fault tolerant • Routing tensions • per-node volume of routing data • latency of route discovery • route discovery overhead

  36. Power consumption power per bit network longevity On-the-air format RF spectrum frame encoding error correction Antenna diversity Burst communications Geospatial routing Semantic protocols Adaptation in Ad-hoc Networks

  37. Demonstration • Architecture-based adaptation for ad-hoc network nodes • dynamic adaptation using microprotocols • reconstitute open source protocols as embedded C2 microprotocols • AX.25 (media access and link layer) • DSR (Dynamic Source Routing) • run protocol stack in emulated RF environment • BLT simulates satellite uplink/downlink bit error and latency • SPANNER simulates ground RF losses and noise • protocol stack will adapt to changing RF conditions and/or battery reserves

  38. Summary of the C2 Project • An architectural style (“the C2 Style”) • Asynchronous, event-based communication among autonomous components, mediated by active connectors • Descriptive formalisms • C2SADEL & graphical notations • Supporting tools • Architecture development and analysis • From model to implementation • Evolution: static and dynamic • Multi-model support

  39. Summary • Architecture-based software engineering addresses the core issue of system design • takes some old and mainstream ideas and makes them better • design notations, domain knowledge rep. • leverages event-based interaction paradigm • leverages results in middleware • provides a viable basis for software reuse? • provides a viable basis for dynamic adaptation

More Related