Your SlideShare is downloading. ×
  • Like
Soft arch archevol
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Soft arch archevol

  • 93 views
Published

 

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
93
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Software Architecture Tutorial #8 Dawand Sulaiman 110019756
  • 2. Architecture-Based Runtime Software Evolution
  • 3.  Air traffic control systems Telephone switching Unacceptable Increased cost delays Shut down & restart system Losing Any other? customers
  • 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. 1. Changes to system requirements2. Changes to system implementation Runtime Software Evolution supports both type of changes.
  • 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.  Corrective evolution  Remove software faults Perfective evolution  Enhance product functionality Adaptive evolution  To run in a new environment
  • 8.  Perfective evolution Observer design pattern State of the added component Example: Adobe Photoshop plug-in
  • 9.  Remove unneeded behavior Application-specific
  • 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.  Recombining existing functionality to modify overall system behavior Altering connector bindings Example: UNIX’s pipe and filter
  • 12.  Components Connectors
  • 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.  Connectors separate a component’s interfacing requirements from its functional requirements Connector purposes:  Specifying communication mechanism  Visualizing and debugging system behavior  Integrating tools
  • 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.  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.  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.  Java C2 class framework Fundamental C2 concepts: components, connectors, and messages Current implementation encapsulates architectural model in an Abstract Data Type (ADT)
  • 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.  Argo  Graphical depiction of the architectural model ArchShell  Textual, command-driven interface for specifying runtime modifications Extension Wizard  Deploy modifications to end-users
  • 21. A simple logistic system for routing incoming cargo to a set of warehouses
  • 22.  add component ClassName: c2.planner.RouterArtist Name? RouterArtistist weld Topentity: Connector1 Bottom entity: RouterArtist weld Topentity: RouterArtist Bottomentity: Connector4 start Entity: RouterArtistist
  • 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.