Soft arch archevol


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Soft arch archevol

  1. 1. Software Architecture Tutorial #8 Dawand Sulaiman 110019756
  2. 2. Architecture-Based Runtime Software Evolution
  3. 3.  Air traffic control systems Telephone switching Unacceptable Increased cost delays Shut down & restart system Losing Any other? customers
  4. 4.  Shifts developer focus away from lines-of- code to coarse-grained components and overall interconnection structure. Enables system designers to focus on the “big picture” Explicit modeling of Govern interactions Minimize component among components interdependencies
  5. 5. 1. Changes to system requirements2. Changes to system implementation Runtime Software Evolution supports both type of changes.
  6. 6.  Postponing updates until the next scheduled downtime Web Servers to redirect traffic to a redundant host Modeling changes at the statement in imperative programming languages (redefine variables if affected by a change) Weaves (passing object references i.e., pointers)
  7. 7.  Corrective evolution  Remove software faults Perfective evolution  Enhance product functionality Adaptive evolution  To run in a new environment
  8. 8.  Perfective evolution Observer design pattern State of the added component Example: Adobe Photoshop plug-in
  9. 9.  Remove unneeded behavior Application-specific
  10. 10.  Two conditions are required:  The state of the executing component must be transferred to the new component  Both components must not be simultaneously active during the change
  11. 11.  Recombining existing functionality to modify overall system behavior Altering connector bindings Example: UNIX’s pipe and filter
  12. 12.  Components Connectors
  13. 13.  Treating components’ internal structure as a black box Components should not communicate by directly referencing one another Each component must provide a minimal amount of functional behavior to participate in runtime change
  14. 14.  Connectors separate a component’s interfacing requirements from its functional requirements Connector purposes:  Specifying communication mechanism  Visualizing and debugging system behavior  Integrating tools
  15. 15.  Layered, event-based architectural style C2 All communication among components occurs via connectors. Every C2 component has top and bottom sides, each side has a single port Every C2 connector has top and bottom sides, but the number of ports is determined by the components attached to it
  16. 16.  Explicit architectural model  Interconnection between components and connectors, and their mappings to implementation modules. Describing runtime change  Modification description uses operations for adding and removing components and connectors, replacing components and connectors, and changing the architectural topology
  17. 17.  Governing runtime change  Constrains play a natural role in governing change. Mechanisms governing runtime change should also contain when particular changes may occur Reusable runtime architecture infrastructure  Maintains the consistency between the architectural model and implementation as modifications are applied
  18. 18.  Java C2 class framework Fundamental C2 concepts: components, connectors, and messages Current implementation encapsulates architectural model in an Abstract Data Type (ADT)
  19. 19.  Correspondence between Architectural Model and Implementation Determines whether the modification is valid (architectural constraint mechanism or external analysis tool ) AEM of C2-style rules constrain changes
  20. 20.  Argo  Graphical depiction of the architectural model ArchShell  Textual, command-driven interface for specifying runtime modifications Extension Wizard  Deploy modifications to end-users
  21. 21. A simple logistic system for routing incoming cargo to a set of warehouses
  22. 22.  add component ClassName: c2.planner.RouterArtist Name? RouterArtistist weld Topentity: Connector1 Bottom entity: RouterArtist weld Topentity: RouterArtist Bottomentity: Connector4 start Entity: RouterArtistist
  23. 23. 1. All components and connectors must be written in Java C2 class framework.2. Components addition, removal and Architectural Model reconfiguration are supported by not Component Replacement.3. Only checks invariants derived from the C2- style rules.