1 / 35

Architectural Design

Architectural Design. CIS 375 Bruce R. Maxim UM-Dearborn. Software architecture representations enable software engineers to. Analyze the effectiveness of the design in meeting stated requirements Consider architectural alternatives

marionk
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 CIS 375 Bruce R. Maxim UM-Dearborn

  2. Software architecture representations enable software engineers 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

  3. Importance • Software architecture representations enable communications among stakeholders • Architecture highlights early design decisions that will have a profound impact on the ultimate success of the system as an operational entity • The architecture constitutes an intellectually graspable model of how the system is structured and how its components work together

  4. Data Warehouse Challenges - 1 • Subject orientation • data warehouse organized by business subjects rather than business processes or functions • Integration • data in the warehouse must exhibit consistent naming conventions, encoding structures, and physical attributes even when inconsistencies exist among application-oriented databases

  5. Data Warehouse Challenges - 2 • Time variancy • unlike transaction-oriented databases where data may only be accurate for short time periods, the time horizon for a data warehouse may be several years • Nonvolatility • data remains in the data warehouse once added and old data may only be purged every few years if ever

  6. Data Specification Principles - 1 • 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. • Low level design processes should be deferred until late in the design process.

  7. Data Specification Principles - 2 • 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.

  8. Architectural Style Elements • Set of components • Set of connections that enable communication, coordination, and cooperation among components • Constraints defining how components can be integrated to form the system • Semantic models that enable designers to understand the overall system properties by analyzing properties of its constituent parts

  9. Architectural Structures - 1 • Functional structure • components represent function or processing entities • connectors are interfaces that allow data access • Implementation structure • components are vehicles for packaging functionality (i.e. packages, classes, objects, functions, methods, etc.) • connectors include data sharing, control transfer, associations, etc.

  10. Architectural Structures - 2 • Concurrency structure • components are units of concurrency • connectors are execution or communications constraints • Physical structure • components are physical hardware that software is deployed on • connectors are the hardware interfaces

  11. Architectural Structures - 3 • Developmental structure • components are work products and required information sources • connectors are the relationships among the work products

  12. Architectural Styles - 1 • Data centered • file or database lies at the center of this architecture and is accessed frequently by other components that modify data • Data flow • input data is transformed by a series of computational components into output data • Call and return • program structure decomposes function into control hierarchy with main program invoking several subprograms

  13. Architectural Styles - 2 • Object-oriented • components of system encapsulate data and operations, communication between components is by message passing • Layered • several layers are defined • each layer performs operations that become closer to the machine instruction set in the lower layers

  14. Software Architecture Design - 1 • Software to be developed must be put into context • model external entities and define interfaces • Identify architectural archetypes • collection of abstractions that must be modeled if the system is to be constructed

  15. Software Architecture Design - 2 • Specify structure of the system • define and refine the software components needed to implement each archetype • Continue the process iteratively until a complete architectural structure has been derived

  16. Representing System - 1 • Use the architectural context diagram to model the manner in which the target system interacts with external entities • Superordinate systems – use the target system as part of some higher level processing scheme • Subordinate systems – used by the target system to provide data or processing needed to complete the target system • Peer level systems – producing or consuming information need by peers of the target system

  17. Representing System - 2 • Actors • people or devices that interact with the system to produce or consume information needed for requisite processing • Interfaces must be defined • All the data that flow into or out of the target system must be identified

  18. Refining Architecture - 1 • Process begins with an examination of the analysis classes for entities from the business domain that must be addressed in the software architecture • Infrastructure components needed to support the business functions are identified

  19. Refining Architecture - 2 • The interfaces depicted in the architecture context diagram may imply specialized components needed to process data that crosses the interfaces • Look for archetypes that reoccur in several components and create new components that service each repeating design pattern

  20. Architecture Design Assessment Questions - 1 • 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? • How are data communicated between components?

  21. Architecture Design Assessment Questions - 2 • 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?

  22. Architecture Tradeoff Analysis - 1 • 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

  23. Architecture Tradeoff Analysis - 2 • 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 changing in the architecture • Critique candidate architectures (step 3) using the sensitivity analysis (step 5)

  24. Architectural Complexity (Coupling) • Sharing dependencies • 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

  25. Mapping Requirements to Architecture - 1 • Establish type of information flow from DFD • 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 • Flow boundaries indicated • DFD is mapped into program structure

  26. Mapping Requirements to Architecture - 2 • Control hierarchy defined • Resultant structure refined using design measures and heuristics • Architectural description refined and elaborated

  27. DFD/CFD Level 0 - Part Number Analysis (PNA) System WKConnectors.XLS Spreadsheet Information CSV File Creation (WKConnectors.CSV) Display Monitor WKConnectors Delimited Text Information Report Results Table1.CSV PART NUMBER ANALYSIS (PNA) Tool File Table1 Delimited Text Information Report Results Table2 Delimited Text Information Report Results Table2.CSV Printer - Command - PN data User

  28. DFD/CFD Level 1 - Part Number Analysis (PNA) Tool WKConnectors Delimited Text information Report Results Validation Results Validate Data Process Report Table1 Delimited Text information Report Results Print / Save Data Report Results Table2 Delimited Text information - Command - PN data

  29. tbl_Classification • DFD/CFD Level 2 - Validate Data Make tbl_createdWKConn WKConnectors Delimited Text information Relevant WKConnector Records Category Reference ID Validation Results - Command - PN data Make WKConn tbl_createdWKConn WKConn field data • Component Remarks • Category ID tbl_createdT1 Analyze/Classify Data T1 Field data Relevant T1 Record(s) Print / Save Data Criteria: - dbs - strCriteria - strOrigPN Criteria: - dbs - strOrigPN Make tbl_createdT1 Table1 Delimited Text information T2 Field data Make tbl_createdT2 tbl_createdT2 Relevant T2 Record(s) Table2 Delimited Text information

  30. DFD/CFD Level 3 - Make tbl_createdT1 Criteria: - dbs - strCriteria - strOrigPN qry_Table1UniquePN Recreate tbl_createdT1 Table1 Delimited Text information Relevant T1 Record(s) Table1 Query Results • DFD/CFD Level 3 - Make tbl_createdT2 Criteria: - dbs - strOrigPN Recreate tbl_createdT2 qry_Table2PrelimUnique Table2 Delimited Text information Table2 Query Results Relevant T2Record(s)

  31. Transform Mapping - 1 • Review fundamental system model • Review and refine data flow diagrams for the software • Determine whether the DFD has transform or transaction characteristics • Isolate the transform center by specifying incoming and outgoing flow boundaries

  32. Transform Mapping - 2 • Perform first level factoring • Perform second level factoring • Refine the first iteration architecture using design heuristics for improved software quality.

  33. Transaction Mapping - 1 • Review fundamental system model • Review and refine data flow diagrams for the software • Determine whether the DFD has transform or transaction characteristics • Identify the transaction center and flow characteristics along each action path

  34. Transaction Mapping - 2 • 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

  35. 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

More Related