University of Southern California Center for Systems and Software Engineering Design-Code Review Preparation Pongtip Aroonvatanaporn CSCI577b Spring 2012 April 2, /2/20121(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Outline Problems & Motivation Faithful vs. Unfaithful Preparation and Review Process Grading Guidelines 4/2/20122(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Motivation To aid with successful transition Ensure that implementation is faithful to the design –Or at least consistent Sufficient documentation for maintenance period –Ease software understanding –Enable evolutionary development 4/2/20123(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Problems When implementation and design are different –The only way to understand implementation is to read through code –Documented artifacts appear useless –Wasted efforts and time Ultimately, Lose-Lose situation –Unhappy clients –Unhappy developers bugged by clients –Unhappy maintainers 4/2/20124(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Architectural Drift Classic problem in software engineering and software maintenance Often happen slowly during implementation –Developers feel changes are minor –Effects of changes multiply 4/2/20125(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Requirements-to-Code Elaboration Impact factor from one step to the next Increase in number of “statements” Clearly, significant impact when changes made to early stages Objective Shall Statements Use-Case Use-Case Steps SLOC x 2.46 x 0.89 x 7.06 x * Ali Afzal Malik, Supannika Koolmanojwong, Barry Boehm. “An Empirical Study of Requirements-to-Code Elaboration Factors 4/2/20126(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Outline Problems & Motivation Faithful vs. Unfaithful Preparation and Review Process Grading Guidelines 4/2/20127(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Faithful Implementation The definition Structural elements  Source code –All should be there Source code must not utilize new major computational elements not specified in architecture Source code must not contain new connections not found in architecture Can we deviate from this? 4/2/2012(C) USC-CSSE8

University of Southern California Center for Systems and Software Engineering Unfaithful Implementation The implementation has its own architecture –Implementation is the architecture Impacts of failure to recognize distinction between designed and implemented architecture –Ability to reason about application’s architecture in future –Misleading (what they think vs. what they have) –Evolution strategies based on documented architecture doomed to failure 4/2/2012(C) USC-CSSE9

University of Southern California Center for Systems and Software Engineering Two-Way Mapping This is what should have been done Changes can be discovered during design or implementation phases –What to do? –How to effectively handle? 4/2/201210(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Design to Implementation Decide to first visit the design –Update the design –Review the changes –Implement according to the new design Always have a “blue print” to refer to Architects may have more understanding on impact of design changes –Easier to foresee future impacts 4/2/201211(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Implementation to Design Changes made to the implementation immediately –Then trace back to design –Update design to reflect new implementation Easier from developers perspective Many changes may have been missed in design update Difficult to foresee future effects –Unless highly experienced 4/2/201212(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Outline Problems & Motivation Faithful vs. Unfaithful Preparation and Review Process Grading Guidelines 4/2/201213(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Preparation Source code files –As implemented SSAD and UML models Personnel –Must be present: Developer (coder) Architect(s) –Optional Other team members 4/2/201214(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Review Process Mainly done with code tracing and walkthrough Design patterns / Architecture frameworks –Which is specified in SSAD? –Meet the standards? Design classes vs. Implemented classes –Consistent attributes –Consistent operations Use-case tracing –Consistency between use-case behavior and implementation 4/2/201215(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Outline Problems & Motivation Faithful vs. Unfaithful Preparation and Review Process Grading Guidelines 4/2/201216(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Grading Guidelines Total = 15 points (3) Faithfulness to design patterns / architecture frameworks (5) Faithfulness in design classes to implemented classes mapping (5) Accuracy of implemented Use-Case behaviors (2) Overall 4/2/201217(C) USC-CSSE

University of Southern California Center for Systems and Software Engineering Questions? 4/2/201218(C) USC-CSSE