Software architecture


Published on

Published in: Education
  • 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

Software architecture

  1. 1. ARCHITECTURAL DESIGN Software Architecture Data Design Architectural Style Analyzing Alternative Architectural Designs Mapping Requirements into a Software Architecture Transform Mapping, and Transaction Mapping Refining the Architectural Design 
  2. 2. Overview  Architectural design represents the structure of the data and program components required to build a computer-based system. A number of architectural "styles" exist. Architectural design begins with data design and proceeds to the derivation of one or more representations of the architectural structure of the system. The resulting architectural model encompasses both the data architecture and the program structure. The architectural model is subjected to software quality review like all other design work products.
  3. 3. Software architecture ——a representation that enables a software engineer to Analyze the effectiveness of the design in meeting stated requirements  Consider architectural alternatives  Reduce the risk associated with the construction of the software  Examine the system as a whole  Why is Architecture Important?
  4. 4. Data Design Data Design at Application Level  Data Design at Business Level  Data Modeling, Data Structure, Database, and the Data Warehouse   Subject oriented  Integration  Time Variance  NonVolatility
  5. 5. Data Design Principles Systematic analysis principles applied to function and behavior should also be applied to data.  All data structures and the operations to be performed on each should be identified.  Data dictionary should be established and used to define both data and program design. 
  6. 6.     Low level design processes should be deferred until late in the design process. Representations of data structure should be known only to those modules that must make direct use of the data contained within in the data structure. A library of useful data structures and operations should be developed. A software design and its implementation language should support the specification and realization of abstract data types.
  7. 7. Architectural Styles  Data centered - data store (e.g. file or database) lies at the center of this architecture and is accessed frequently by other components that Client modify data software Client software Data store Client software (Repository or Client software blackboard) Client software Client software
  8. 8.  Data flow - input data is transformed by a series of computational or manipulative components into output data Filter Filter Filter Filter Filter Filter Filter Pipes Filter (a) Pipes and filters Filter Filter Filter (b) Batch sequential Filter
  9. 9.    Call and return - program structure decomposes function into control hierarchy with main program invokes several subprograms Object-oriented - components of system encapsulate data and operations, communication between components is by message passing Layered - several layers are defined, each accomplishing operations that progressively become closer to the machine instruction set
  10. 10. Architecture Design Assessment Questions       How is control managed within the architecture? Does a distinct control hierarchy exist? How do components transfer control within the system? How is control shared among components? What is the control topology? Is control synchronized or asynchronous?
  11. 11.        How are data communicated between components? Is the flow of data continuous or sporadic? What is the mode of data transfer? Do data components exist? If so what is their role? How do functional components interact with data components? Are data components active or passive? How do data and control interact within the system?
  12. 12. Architecture Trade-off Analysis Method    Collect scenarios Elicit requirements, constraints, and environmental description Describe architectural styles/patterns chosen to address scenarios and requirements (module view, process view, data flow view)
  13. 13.    Evaluate quality attributes independently (e.g. reliability, performance, security, maintainability, flexibility, testability, portability, reusability, interoperability) Identify sensitivity points for architecture (any attributes significantly affected by variation in the architecture) Critique candidate architectures (from step 3) using the sensitivity analysis (conducted in step 5)
  14. 14. Architectural Complexity (similar to coupling)    Sharing dependencies - represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers Flow dependencies - represent dependence relationships between producers and consumers of resources Constrained dependencies - represent constraints on the relative flow among a set of components
  15. 15. Mapping Requirements to Software Architecture  Establish type of information flow  transform flow - overall data flow is sequential and flows along a small number of straight line paths  transaction flow - a single data item triggers information flow along one of many paths
  16. 16. Transaction Transaction center Action Path T Transaction Flow Action Path Transform Flow
  17. 17.      Flow boundaries indicated DFD is mapped into program structure Control hierarchy defined Resultant structure refined using design measures and heuristics Architectural description refined and elaborated
  18. 18. Program Architecture
  19. 19. •Partitioning the Architecture • “horizontal” and “vertical” partitioning are required
  20. 20. •Horizontal Partitioning • define separate branches of the module hierarchy for each major function • use control modules to coordinate communication between functions function 3 function 1 function 2
  21. 21. •Vertical Partitioning: Factoring • design so that decision making and work are stratified • decision making modules should reside at the top of the architecture decision-makers workers
  22. 22. Why Partitioned Architecture? • results in software that is easier to test • leads to software that is easier to maintain • results in propagation of fewer side effects • results in software that is easier to extend
  23. 23. Transform Mapping Review fundamental system model  Review and refine data flow diagrams for the software  Determine whether the DFD has transform or transaction characteristics 
  24. 24. Isolate the transform center by specifying incoming and outgoing flow boundaries  Perform first level factoring  Perform second level factoring  Refine the first iteration architecture using design heuristics for improved software quality 
  25. 25. Transform Mapping a b d e h g f i c j data flow model x1 x2 b x4 x3 c a "Transform" mapping d e f g i h j
  26. 26. Factoring direction of increasing decision making typical "decision making" modules typical "worker" modules
  27. 27. First Level Factoring main program controller input controller processing controller output controller
  28. 28. Second Level Mapping main D C control B A A B C mapping from the flow boundary outward D
  29. 29. Transaction Mapping Review fundamental system model  Review and refine data flow diagrams for the software  Determine whether the DFD has transform or transaction characteristics 
  30. 30. Identify the transaction center and flow characteristics along each action path  Map the DFD to a program structure amenable to transaction processing  Factor and refine the transaction structure and the structure of each action path  Refine the first iteration architecture using design heuristics for improved software quality 
  31. 31. Transaction Flow incoming flow action path T
  32. 32. •Transaction Mapping Principles isolate the incoming flow path define each of the action paths by looking for the "spokes of the wheel" assess the flow on each action path define the dispatch and control structure map each action path flow individually
  33. 33. Transaction Mapping Data flow model x1 f program structure e a d b t t b mapping i g a h l x2 x4 x3 k j m n d e f g l x3.1 h j i k m n
  34. 34. Isolate Flow Paths error msg command produce error msg read command validate commandcommand fixture setting status invalid command valid command determine type robot control send control value start/stop format setting determine read setting fixture raw setting status combined status read record record calculate output values values format report assembly record report
  35. 35. Map the Flow Model process operator commands command input controller read command validate command determine type produce error message fixture status controller report generation controller send control value each of the action paths must be expanded further
  36. 36. Refining Architectural Design       Processing narrative developed for each module Interface description provided for each module Local and global data structures are defined Design restrictions/limitations noted Design reviews conducted Refinement considered if required and justified
  37. 37. Refining the Structure Chart process operator commands command input controller read command validate command read fixture status determine type produce error message determine setting fixture status controller format setting report generation controller read record send control value calculate output values format report