210 likes | 443 Views
Concrete Architecture of PostgreSQL. S-Queue-L Khurrum A Mujeeb, Adam Abu Hijleh, Adam Ali Stephen McDonald, Wisam Zaghal. CISC 322 - Fall 2010. Overview. Derivation Process Conceptual Architecture Revisited High Level Conceptual Dependencies
E N D
Concrete Architectureof PostgreSQL S-Queue-L Khurrum A Mujeeb, Adam Abu Hijleh, Adam Ali Stephen McDonald, Wisam Zaghal CISC 322 - Fall 2010
Overview • DerivationProcess • Conceptual Architecture Revisited • High LevelConceptualDependencies • High LevelObservedDependencies (Concrete Architecture) • Expose highlevelunexpected inter-dependencies • Utilities • Intradependencies • Interdependencies • Final Arcihtecture Style & Conceptual Modification • Use Case Revisted • Concurrency & Team Issues • Limitations • LessonsLearned • Conclusion
DerivationProcess • Map components to our proposed conceptual architecture • Withaid of OpenGrok online source code browser, Software Landscape Editor, online PostgreSQLManual, and source code decomposition • Analysis of dependencies for the now-grouped components, making note of missing & unexpecteddependencies • Investigate gaps between conceptual dependencies & extractedconcretedependencies (ReflextionAnalysis)
Reflexion Analysis - Conceptual Propose Extracted source dependencies Conceptual subsystems Dependencies between SubSystems Mapping source entities to subsystems Conceptual Architecture Concrete Architecture Compare Gaps Figure 1 Investigate
Conceptual Architecture Revisited - Layered Legend Expected Dependency Figure 2
Expected Subsystem Interdependencies Legend Expected Subsystem Interdependency Figure 3
Reflexion Analysis - Concrete Propose Extracted source dependencies Conceptual subsystems Dependencies between SubSystems Mapping source entities to subsystems Conceptual Architecture Concrete Architecture Compare Gaps Figure 4 Investigate
Unexpected Subsystem Interdependencies Legend Expected Subsystem Interdependency Unexpected Subsystem Interdependency Figure 5
Unexpected Subsystem Interdependencies Legend Expected Dependency Unexpected Dependency Figure 6
Miscellaneous pl snowball test tsearch bin tutorial regex include port tools foreign
Utility Inter-Subsystem Dependencies Query Processor Catalog Nodes/List Process Manager Client Communication GeneralUtils Access Storage Manager Unexpected Dependencies Query Processor dependency All External Subsystems Depend on Expected Dependency Utility Component Process Manager Subsystems Client Comm. Dependency Figure 7 Storage Manager
Utility Intra-Subsystem Dependencies Catalog Nodes/List GeneralUtils Access Unexpected Dependencies Utility component Figure 8
General Utilities Intra-Subsystem Dependency Backend Utilities Time zone Library Numeric.c Unexpected Dependencies Utility component Figure 9
Reflexion Analysis – Investigate Gaps Propose Extracted source dependencies Conceptual subsystems Dependencies between SubSystems Mapping source entities to subsystems Conceptual Architecture Concrete Architecture Compare Gaps Investigate Figure 10
Architecture Style Revisited Initially: Layered–Each layer onlytalks to the layer above or below Maybe: Minimallylayered ? - toomuchcoupling Now: Object Oriented–Function calls within and acrossvarioussubsystems
High Level Conceptual Remodeling – Object Oriented New Expected Dependencies Subsystem Figure 11
Client Library Interface Server Parser Stage Rewriter Planner/ Optimizer Executor Storage Manager Catalog General Utilities Nodes Legend: Request to Log in Components Request to Log in Logged in Server Requested Server and communi- cation channel created Data Flow Query Sent Query Sent Query Sent Function Call Copy node tree function called Query Sent Node tree returned Duration of running component Semantics lookup Semantics retrieved Grammar rules and actions looked up Grammar rules and actions retrieved Format type function called SQL format language returned User Tree manipulation function called Parsed Tree Manipulated tree returned Modified Tree Tree comparison function called Comparison results returned Tree manipulation function called Most Efficient Tree sent Manipulated tree returned Access & Modify Tree Data Sent back Executed Query Returned Executed Query Returned Executed Query Returned Executed Query Returned Current execution state of the query Figure 12
Concurrency &Team Issues Team Issues • CommitFests • Review and commit patches if up to par • If not committed, feedback given and changes made Concurrency • MVCC • snapmgr.c (Utils - time) • Snapshot of data • proc.c (Storage – Lock Manager) • Frees lock associated with current transaction
Limitations • Software Landscape Editor, althoughpowerful, was primitive – hard to use • Determining how to map source files in accordance with our conceptualarchitecture • Lack of documentation on important code fragments • Wasdifficultto conslidate utilities into one shared component, as utilities werescatteredthroughout the variouslevels of the system
LessonsLearned • Best way to understand High Leveldependenciesis to understandtheirorigins on the lowerlevels • Importance of clear and efficient commenting • Group effort neededatevery stage • Divide and Conquerproved to bemuch more difficultgiven the nature of the contain files and Lsedit • Working in pairs of 2 at a time per taskproved to bemost effective
Conclusions • All components weremuch more intertwinedthanoriginallysuspected • Importance of reflexionanalysis • Wenowbelieve the architecture to be Object-Orientated