1 / 30

Architectural Design

Learn about architectural design software architecture, including data design, architectural styles, and refining the design through analyzing and mapping data flow.

otisl
Download Presentation

Architectural Design

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. Architectural Design

  2. Software Architecture: What is it? • Structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them • Two Levels • Data Design • Architectural Design

  3. Software Architecture • The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: • Analyze the effectiveness of the design in meeting its stated requirements, • Consider architectural alternatives at a stage when making design changes is still relatively easy, and • Reduce the risks associated with the construction of the software.

  4. Importance? • Representations of software architecture are enablers for communication • The architecture highlights early design decisions • Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”

  5. Data Design: Architectural Level • Multiple Databases • Data mining: Knowledge Discovery in Databases (KDD) • Data Warehousing

  6. Data Design: Component Level • Focuses on representation of data structures that are directly accessed by software components • Best practices: • Develop data abstractions • Ensure relationships established • Simplify where possible

  7. Architectural Styles • Styles describe a category defined by: • A set of components that perform a function • Set of connectors that enable communication • Constraints on integration of components • Semantic models that help the understanding of overall properties of a system • Types of Architectures • Data-centered • Data flow • Call and Return ( Main Program/Subprogram and Remote Procedure Call) • Object Oriented • Layered

  8. Data-Centered Example?

  9. Data Flow Examples?

  10. Call and Return

  11. Layered

  12. Architectural Patterns • Concurrency: applications must handle multiple tasks in a manner that simulates parallelism • Persistence: Data persists if it survives past the execution of the process that created it. Two patterns are common: • DBMS Pattern • Application Level Persistence Pattern • Distribution: the manner in which systems or components within systems communicate with one another in a distributed environment

  13. Organization and Refinement • Assessing architectural style: • Control • How is control managed? • Does a hierarchy exist? • How is control transferred? • Data • How is data communicated? • Is flow continuous? Sporadic? • Component interaction with data? When might data flow be continuous? Sporadic?

  14. Architectural Design • Representing in context: interaction with target system • Superordinate Systems • Subordinate Systems • Peer-Level Systems • Actors • Archetypes: one element of the system • Nodes, Detectors, Indicators, Controllers • Refining: implementation of previously defined archetypes

  15. Architectural Context Example

  16. Archetype Example

  17. Components Example

  18. Refined Components Example

  19. Analyzing the Design • Collect scenarios • Elicit requirements, constraints, environment description • Describe architectural designs or patterns that have been chosen • Evaluate quality attributes in isolation • Identify the sensitivity of quality attributes to various attributes for a specific style • Critique candidate architectures

  20. Architectural Complexity • Sharing dependencies • Flow dependencies • Constrained dependencies

  21. Mapping Data Flow to Architecture • Transform Mapping • Review the fundamental system model. • Review and refine data flow diagrams for the software • Determine whether the DFD has transform or transaction flow characteristics. • 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.

  22. Flow Characteristics Transform flow Transaction flow

  23. Transform Mapping

  24. Factoring

  25. First Level Factoring main program controller output input processing controller controller controller First level factoring isTop-Down distribution of control.

  26. Second Level Factoring Second level factoring is begins at the transform center boundary and moving outward along incoming and then outgoing paths.

  27. Transaction Mapping Data flow model f e a mapping d b x1 t i g program structure h l k t b j m a x2 x4 x3 n n l x3.1 m g f h d e j i k

  28. Isolate Flow Paths error msg produce error msg command read command fixture setting format setting status determine setting validate command read fixture status invalid command raw setting command combined status determine type valid command read record robot control record calculate output values send control value values format report report assembly record start/stop

  29. Map the Flow Model

  30. Refining

More Related