Pathfinder Design Proposal

ICU-CMU (Carnegie Mellon University) Software Development Studio MSE Program 2006

Stargate
Design Proposal Version 1.1 December 14, 2005

Pathfinder Team
Wangbong Lee Jihye Eom Youngseok Oh Il-Seok Suh

Pathfinder Design Proposal

Document Revisions Revision 0.1 Date 10/14/05 Contributor Wangbong Lee Jihye Eom Youngseok Oh Il-Seok Suh Jihye Eom Jihye Eom Jihye Eom Comments Initial darft

0.2 0.3 1.0

10/17/05 12/7/05 12/8/05 12/1405

Add context Approach, methods Add review process in Analysis section Modify Analysis

Pathfinder Design Proposal Table of Contents

1 INTRODUCTION...............................................................................................................3 2 CONTEXT..........................................................................................................................4 2.1 PROJECT OVERVIEW ...........................................................................................................4 2.2 TEAM NAME.....................................................................................................................4 2.3 TEAM MEMBERS...............................................................................................................4 2.4 PROJECT DIMENSION.........................................................................................................4 2.5 DOCUMENT SCOPE............................................................................................................4 3 APPROACHES...................................................................................................................5 3.1 METHODS, TECHNIQUES, AND STRATEGIES USED..................................................................5 3.2 ARTIFACTS......................................................................................................................5 3.3 REFERENCES....................................................................................................................5 4 ANALYSIS...........................................................................................................................5 4.1 APPROACH VERIFICATION AND VALIDATION..........................................................................5 4.2 ARTIFACTS......................................................................................................................6 4.3 REFERENCES....................................................................................................................6 5 REFLECTION.....................................................................................................................6

Pathfinder Design Proposal

1 Introduction
MSE studio project requires the student to establish proposals. The entire proposals consist of problem definition, design, implementation, operation, plan and legal. Among those proposals, the first three have technical aspects and the rest are related with people and process. Each proposal helps student define the approaches, analysis, and reflection. Those definitions should describe the methods, techniques, strategies, verification, validation and reflection that the students are going to apply across the project. The suggested Design proposal must have information as below table. At the beginning, the proposal provides the approach and analysis. After the approach and analysis section, the team will add the final section that discusses their reflection upon the approaches and analysis techniques and methods that they selected. Concern: Technology Dimension: Design Definition This refers to designing a solution to the problem. This encompasses all levels of design abstraction (architectural to detailed design). Approaches Select methods, techniques, and strategies for defining and documenting the designs. (Examples include: UML/OOD, Structured Design, Attribute Driven Design (ADD), Box-and-line diagrams, Model Driven Design (MDA)). Analysis Verify that the designs meet the needs of the client. (Examples include: design reviews, ATAM, SAAM, ARID) Reflection How well did these methods work? Faced with a similar situation, what would you do next time?

Pathfinder Design Proposal

Context

2.1 Project overview Refer to chapter 1.1 of SOW 2.2 Team name

Pathfinder 2.3 Team members

Wangbong Lee Jihye Eom Youngseok Oh Il-Seok Suh 2.4 Project Dimension Refer to chapter 1.2 of SOW 2.5 Document scope The Design Proposal describes designing a solution to the problem. This encompasses all levels of design abstraction (architectural to detailed design).

Pathfinder Design Proposal

3 Approaches
3.1 Methods, Techniques, and Strategies Used To prove that the design of the data structure appropriate, we propose two levels of detail, one conceptual and one concrete. The conceptual level will provide an overall understanding of the data structures architecture that is suitable for customers needs. The concrete level will be intended more for developer to use and will contain class diagrams and other implementation-focused views. Pathfinder team will use UML for functional design and the Attribute Driven Design (ADD) method for non-functional design. To refine and specify the problem definition elicited by use-case diagram, UML is the best suitable tool. Therefore the class diagram and sequence diagram can be developed from the use case diagram. Pathfinder team will implement the project by Java, in this case the design of UML is easy to understand and convert explicitly. Moreover the relation between use cases and classes is very obvious and clear to trace. To facilitate in the creation of this conceptual architectural design, we are proposing to utilize the Attribute Driven Design (ADD) method. The ADD method is perfectly suited to our needs because the final conceptual architectural design as described by the ADD process is derived directly from the functional requirements and quality attributes as dictated by the customer. Once the conceptual architectural design is complete, it will be necessary to derive a design that is more concrete for use by the developers in guiding the implementation by UML. The sequence diagrams and design level class diagrams ensure proper architectural implementation and make it possible for the functionality of every design component to be directly traced back to one or more functional requirements. 3.2 Artifacts Context Diagram High-level Data Flow Diagram Class diagram Verification and Validation Plan

3.3 References [1] Software Architecture in Practice, Second Edition. .Bass, L.; Clements, P.; & Kazman R. Boston, MA: Addison-Wesley, 2003.

4 Analysis
4.1 Approach verification and validation To achieve the verification and validation Pathfinders design approach, two review methods will be used. First, for the design of functional requirement Pathfinder team will review the design document class diagram - and for the design of non-functional requirement Pathfinder team will follow the process of ATAM review process.

Pathfinder Design Proposal The Pathfinder teams functional design review will begin after releasing the first drafts of the diagrams, models, vision, user environment design, architecture, prototype, or document. Once a draft or revised version of a design releases, it will be transmitted to the responsible person for the design and he/she will review until the final release of the design. When a responsible person finds any defects in the design, he/she will mention the defects at the weekly status meeting. If the defects are serious, so should be handled immediately, he/she can convoke a design review session. Design review process will be continued until the team will start coding of the system. The goal of the Pathfinder project is to develop a data structure that can be changeable and efficient as necessary. Therefore we propose an analysis process based on a scaled-down version of the Architecture Tradeoff Analysis MethodSM (ATAM). This project should meet the not-functional requirement such as flexibility for adding and deleting category and changeability for searching order of the POI field. Therefore w e wish to have respect to the architectures adherence to the customers designated quality attributes, these adherences will be ensured via comparison of the architecture against a requirements traceability matrix. The matrix will map all functional requirements to our data structure so that the responsibilities of classes will be clear. 4.2 Artifacts

The artifacts produced by this analysis will be the artifacts dictated by the ATAM (i.e. refined quality attribute descriptions, tradeoff points, sensitivity points, etc.). 4.3 References

[1] Kazman, Klein, Clements; ATAM: Method for Architecture Evaluation; CMU/SEI2000-TR-004; 2000.

5 Reflection
1. How well were we able to reason about quality requirements using our architecture? 2. How effective is ADD and UML in terms of creating the architecture that HMC wants? 3. Can we identify the problem that the team is trying to solve with the architecture design? 4. Have we achieved designing an architecture that will solve the given problem?