Docstoc

Architecture Document template

Document Sample
Architecture Document template Powered By Docstoc
					Master of Software Engineering Studio                Team Hermes
Architecture Document for Bosch CA 2006/2007




Architecture Document
v.3.1
Bosch CA 2006/2007




                                                Team members
                                               Ed Yampratoom
                                                   Tadashi Tsuji
                                                 Fabian Hueppi
                                               Upeka Bulumulle
                                                   Hye Eun You



                                                      Page 1 of 18
Master of Software Engineering Studio                                                                                                      Team Hermes
Architecture Document for Bosch CA 2006/2007



Table of Contents
TABLE OF CONTENTS .................................................................................................................................. 2
1.       DOCUMENT INFORMATION ............................................................................................................ 3
2.       INTRODUCTION ................................................................................................................................. 4
     2.1          PURPOSE ...................................................................................................................................... 4
     2.2          DEFINITIONS .................................................................................................................................. 4
3.       PROJECT OVERVIEW ......................................................................................................................... 5
     3.1          PROJECT DESCRIPTION ................................................................................................................. 5
     3.2          PROBLEM STATEMENT .................................................................................................................... 5
     3.3          BUSINESS DRIVERS ......................................................................................................................... 5
4.       ARCHITECTURAL DRIVERS ................................................................................................................ 5
     4.1          HIGH-LEVEL REQUIREMENTS .......................................................................................................... 5
     4.2          PRIORITIZED QUALITY REQUIREMENTS.............................................................................................. 5
     4.3          CONSTRAINTS ............................................................................................................................... 7
5.       HIGH LEVEL ARCHITECTURE ............................................................................................................ 8
     5.1          COMPONENT & CONNECTOR VIEW............................................................................................. 8
     5.2          ELEMENT CATALOG FOR COMPONENT & CONNECTOR VIEW ...................................................... 9
     5.3          MODULE VIEW.............................................................................................................................. 9
     5.4          ALLOCATION VIEW ......................................................................................................................10
6.       DETAILED ARCHITECTURE ...............................................................................................................11
     6.1   XX ................................................................................................................................................11
        Component & Connector View .................................................................................................11
        Module View ....................................................................................................................................11
7.       ARCHITECTURAL DECISIONS .........................................................................................................12
     7.1    ARCHITECTURAL RECONSTRUCTION .............................................................................................12
     7.2    STYLES/PATTERNS USED ................................................................................................................12
     7.3    TACTICS USED ..............................................................................................................................13
     7.4    WRAPPER ....................................................................................................................................13
     7.5    ARCHITECTURAL ANALYSIS AND DESIGN DECISIONS .....................................................................13
        Scenario: xx ......................................................................................................................................13
8.       REFLECTION ON ARCHITECTURAL EVALUATION .......................................................................15
9.       APPENDIX A: ACDM EXPERIMENTS ..............................................................................................17
10.          REFERENCES ..................................................................................................................................18




                                                                                                                                             Page 2 of 18
Master of Software Engineering Studio                                       Team Hermes
Architecture Document for Bosch CA 2006/2007



1. Document information
Title             Architecture Document
Document          Upeka
Owner
Stored In         http://msesrv2a.mse.cs.cmu.edu/
Referenced        Hermes’s Software Requirement Specifications (SRS):
documents         http://msesrv2a.mse.cs.cmu.edu/Published/Requirements


Revision History
    #   Version       Date         Author                     Comments
1       1.0        03/03/2007   Team Hermes    X
2       1.1        04/12/2007   Upeka          X
3       2.0        05/02/2007   Upeka          X
4       2.1        05/24/2007   Upeka          X
5       3.0        10/16/07     Upeka          X
6       3.1        11/29/2007   Upeka          X




Credits
Inherently, some sections of this document, including some architectural diagrams and
descriptions are based on the Architecture document from Team Serendipity because
our project is an extension of that project. All our decisions for reuse and modification
have been documented in this document. The contents from the original source have
been thoroughly edited, added, removed, and inspected to ensure that this document
truly fit our needs.




                                                                             Page 3 of 18
Master of Software Engineering Studio                                       Team Hermes
Architecture Document for Bosch CA 2006/2007



2. Introduction
2.1 Purpose
The purpose of this document is to describe the architectural solution that Hermes team
will use to extend the Configuration Assistant. The initial version of the Configuration
Assistant was created by Serendipity team, Bosch-MSE 2005/06. The audience of this
document is the Client, the owners of the project and the programmers or developers,
which will implement the components in the architecture, or will modify it in the future.

2.2 Definitions
This architectural document uses the following definitions:

General terms
    Bosch: Robert Bosch Corporation's Research and Technology Center in Pittsburgh,
      Pennsylvania
    CA: Acronym for Bosch’s Configuration Assistant tool
    Bosch customers: Dr. Charles Shelton
    Client: Synonym for Bosch
    Project mentors: The project's mentor team comprises of Dave Root and Grace
      Lewis
    Statement of work (SOW): This document describes the tasks that both parties will
      perform
    Software Requirements Specifications (SRS): This document describes the
      requirements for the Bosch CA in detail.
    Team Hermes: The team comprises of Ed Yampratoom, Tadashi Tsuji, Fabian
      Hueppi, Upeka Bulumulle and Hye Eun You
    Team Serendipity: The 2005/2006 MSE team who built the initial version of the
      Bosch CA.

Technical terms
    Xx: xxx




                                                                             Page 4 of 18
Master of Software Engineering Studio                                               Team Hermes
Architecture Document for Bosch CA 2006/2007



3. Project Overview
3.1 Project Description
xxx.


3.2 Problem Statement
xxx

3.3 Business Drivers
xxx:


4. Architectural Drivers
4.1 High-level Requirements
This section gives a brief description of each major functional requirement.

R1. x: xx.


R10. x: xxx.

4.2 Prioritized quality requirements
A quality attribute utility tree is used to document quality requirements of the system. This
utility tree is represented as a table with the scenarios prioritized by the stakeholders
(client, studio team) of the system in terms of client importance and implementation
difficulty. The utility tree has three levels: quality attribute, attribute concern, and scenario.

       ID        Attributes      Concerns                        Scenarios                     Priority(I,D)*
  QA1
                                                                                                     H,L

  QA2

                                                                                                     H,M

               Adaptability/
  QA3           Extensibility
                                                                                                     H,L

  QA4


                                                                                                     M,L




                                                                                     Page 5 of 18
Master of Software Engineering Studio                      Team Hermes
Architecture Document for Bosch CA 2006/2007


   ID        Attributes        Concerns        Scenarios            Priority(I,D)*
  QA5

                                                                          H,M


  QA6


          Usability/Intuiti                                               M,L
             veness



  QA7

                                                                          M,L


  QA8

                                                                          M,L


  QA9

            Scalability                                                   M,L


 QA10

                                                                          M,L


 QA11

                                                                          H,M


 QA12
            Reliability/
                                                                          H,L
            Availability

 QA13

                                                                          M,L


 QA14
            Accuracy/
                                                                          H,M
           Predictability




                                                           Page 6 of 18
Master of Software Engineering Studio                                           Team Hermes
Architecture Document for Bosch CA 2006/2007


   ID        Attributes        Concerns                         Scenarios                 Priority(I,D)*
 QA15

                                                                                                M,L


 QA16

                                                                                                L,M


 QA17

                                                                                                H,M


*(I,D) = (Client importance, Implementation difficulty)

4.3 Constraints
ID        Type                 Constraint                             Impact               Flexibility
C1      Technical   Inherently all extensions have        Additions and modifications     Not flexible
                    to be performed on the                have to make the maximum
                    existing CA, and we must to           use of legacy architecture.
                    avoid rework.                         Further, we must learn and
                                                          use Jess and security
                                                          visualization tool.
C2      Technical                                                                         Not flexible
C3      Technical   The product must run on               Minimal impact                  Not flexible
                    Microsoft Windows XP
C4      Technical                                         Dependency on Bosch             Not flexible
                                                          developer
C5      Business    Team Hermes has only four             Scope has to be closely         Not flexible
                    members.                              monitored.
C6      Business    The product must be delivered         All nice-to-have                Not flexible
                    at the end of the summer              requirements may not be
                    semester.                             complete.




                                                                                 Page 7 of 18
Master of Software Engineering Studio          Team Hermes
Architecture Document for Bosch CA 2006/2007



5. High Level Architecture
5.1 Component & Connector View




                                               Page 8 of 18
Master of Software Engineering Studio                                               Team Hermes
Architecture Document for Bosch CA 2006/2007



5.2 Element Catalog for Component & Connector View
Element               Type      Description
Name
System              Domain1     This domain represents a boundary that the system will
Domain                          address. To consider the system’s interactions with its
                                environment, refer to its context diagram (Figure 1)


5.3 Module View




    The term domain refers a logical grouping of objects working together for a common purpose
1




                                                                                     Page 9 of 18
Master of Software Engineering Studio                                       Team Hermes
Architecture Document for Bosch CA 2006/2007

Element Catalog for Module View
Element Name           Responsibility

Frontend                 This logical grouping contains all code modules that implement the
                         user interface and the eclipse plug-in. The legacy system puts this
                         code under a project named UserInterface.

Interpretations



5.4 Allocation View


Our system will run on a single standalone computer with the above minimal hardware
requirements.




                                                                            Page 10 of 18
Master of Software Engineering Studio                    Team Hermes
Architecture Document for Bosch CA 2006/2007



6. Detailed Architecture
6.1 xx
xx.

Component & Connector View

Element Catalog
Component Name                   Type          Purpose




Module View

Element Catalog

External interfaces:




Classes:




                                                         Page 11 of 18
Master of Software Engineering Studio                                             Team Hermes
Architecture Document for Bosch CA 2006/2007



7. Architectural Decisions
7.1 Architectural Reconstruction
As stated in section 4.3, C1 is the biggest constraint on this architecture. Since the
functionalities provided by Serendipity’s legacy system are extensive, we must build on
that system. Further, to minimize work performed by our four-member team, we will try to
minimize modification to the existing system

Therefore, in order to make effective architectural decisions we performed extensive
analysis of the legacy code and existing documentation. Since ACDM is our process, we
performed this analysis through experiments.

We also performed many experiments using GEF, in relation to the functional
requirements R5 and R6.

The experiments are:
 ID     Name             Area                               Purpose




All the experiments are documented in Appendix A.

7.2 Styles/Patterns Used
The legacy architecture highly constrains our choices. To keep the architecture
coherent, newly developed modules will try to follow existing styles as much as possible.

Call-Return Pattern
     It is used for most of the system and implemented as object-oriented Java classes.
     It is shown as main program/subroutines with layers from a code perspective.
     Quality attribute promoted
            o Extensibility: it will promote extensibility of adding new elements to the
               system if elements are well encapsulated and their interfaces are defined
               with few calls/returns.
     Quality attributes inhibited
            o Availability: The system has a central element that governs all
               communications among other elements. This inhibits performance and
               also availability because the central element is a single point of failure;
               especially, availability is one of the quality attributes that must be satisfied.

Explicit Event Pattern
    xx

Shared Information Pattern
    Data repository is used for managing data.



                                                                                  Page 12 of 18
Master of Software Engineering Studio                                            Team Hermes
Architecture Document for Bosch CA 2006/2007

        It is shown as a database from a run-time perspective.
        Quality attributes promoted




7.3 Tactics Used

Tactics related to quality attribute scenarios

        Availability/Reliability
            o xx

        Usability/Intuitiveness
            o xx


Tactics related to development best practices

        Testability
             o Separate interface from implementation: Components only interact with
                 other components via their interfaces. This allows us to stub objects to test
                 existing implementation.

        Modifiability
           o We use the "maintain existing interfaces" tactic in the user interface. We
                don't change the interface of the original business data, but instead
                added an adapter (UI data modules) in the UI. With this, our modifications
                to the UI don't ripple to the business modules and all the modules that
                depend on their interfaces.

7.4 Wrapper
We had to decide whether to treat the existing architecture as a black box and build a
wrapper around it, or to modify the legacy architecture directly. We decided on the
latter because of the following reasons:
     Since our client will continue to build on our delivered product, they need to
        understand the architecture and the design much more than normal clients.
     By not wrapping the legacy system inside a black box, we can create a clearer
        and more straightforward architecture. We can also get a better performance.
     Quality attributes promoted: modifiability, performance
     Since our modification is more extensive than the wrapper approach, we need to
        test more extensively. Fortunately, Serendipity also provided us with their test
        suites that we can reuse to ensure regression test conformance.

7.5 Architectural Analysis and design decisions

Scenario: xx

Scenario ID             17

Priority(I,D)           (H, M)

Scenario



                                                                                 Page 13 of 18
Master of Software Engineering Studio                                           Team Hermes
Architecture Document for Bosch CA 2006/2007


Quality Attribute    Accuracy/Predictability

Attribute Concern    Metric accuracy

                     Stimulus

                     Stimulus Source

Scenario             Environment
Refinement           Artifact

                     Response

                     Response Measure

Architectural        The results must be verified to ensured correctness. We will submit
Decisions and        the calculation methods and rules to the expert clients for
Reasoning            verification as well.

                     The calculation performed may be incorrect. We mitigate this by
                     having the expert clients verify the methods and rules. Our
Risks
                     incremental deliveries will also give us time to rework if the
                     calculations are incorrect.

                     Verification of methods (by reviewing algorithms & rules) and of
Tradeoffs            actual solutions (by testing) take time of both us and the clients. This
                     tradeoff is necessary because the correctness of our solution is vital.




                                                                                Page 14 of 18
Master of Software Engineering Studio                                        Team Hermes
Architecture Document for Bosch CA 2006/2007



8. Reflection on Architectural Evaluation
We evaluated our architecture in two phases:

Phase 1: ACDM-based evaluation
During this phase, we used the evaluation process described in stage 4 of the ACDM
process. This evaluation was performed only among team members without expert help.
When we had the high-level overall system architecture ready, we conducted this
ACDM-based evaluation for one session before MOSP.

Positive points:
 By going through the quality attribute scenarios, we could see that our architecture
    actually satisfy these quality attributes. We could then proceed with subsequent
    design activities.
 By stepping through the scenarios and the responsible architectural elements, team
    members who were not familiar with that part of architecture could gain a good
    understanding of the system.
 The review helped us identify some problematic or uncertain points in the
    architecture. These issues guided us to perform experiments to ensure that the
    designed architecture could actually be implemented in the existing system.

Negative points:
 Since it was the first architecture review for all team members, we spent too much
   time looking up the steps of the review and verifying that we adhered to these steps.
 It was not easy to decide if we should count something as an actual defect or just as
   an issue that needed further investigation.

Phase 2: ATAM-based evaluation
The ATAM-based evaluation was done under the guidance of Tony Lattanze. This phase
turned out not to be a traditional ATAM, but more an informal review of the architecture
guided by questionings and answers.

First the lead architect explained the scope of the project and the business drivers. Then
we looked at the quality attribute scenarios and tried to identify their impact on the
architecture. After that, the team presented their architectural drawings and explained
how user actions influenced the different parts of the architecture. From this point
onwards, Tony asked many questions to verify our understanding of the design. He also
checked for consistency between the high-level view of the architecture and the
detailed component-level views.

We performed two ATAM-based evaluations with Tony. This was mostly due to the fact
that a single session was too short to look at all designs. The two sessions where split
according to the finished dates of the architectural portion that would be reviewed. The
first session was five weeks before the end of semester; the second one was two weeks
before the end of semester.

Positive Points:
 Tony identified inconsistencies between the overall architecture and the detailed
    component-level views.
 The informal style allowed everyone to ask many clarifying questions about how to
    document the architecture in the best way.




                                                                             Page 15 of 18
Master of Software Engineering Studio                                        Team Hermes
Architecture Document for Bosch CA 2006/2007

   Tony also found additional problems that were not visible from the architectural
    drawings, such as the choice of algorithm for one of our main functional
    requirements.

Negative Points:
 There was not enough time to ask all the hard questions. We should manage time
   better in an informal setting so that we don’t waste time on minor issues.


In practice we would prefer two sessions with different characteristics. The first session
should be informal with a lot of questions and answers where we can discuss various
issues about our architecture draft with an expert. The second session should then be a
formal inspection of the updated architecture. This inspection should be based on the
quality attribute scenarios. Preferably multiple stakeholders should attend this second
session as well.




                                                                             Page 16 of 18
Master of Software Engineering Studio          Team Hermes
Architecture Document for Bosch CA 2006/2007



9. Appendix A: ACDM Experiments




                                               Page 17 of 18
Master of Software Engineering Studio                               Team Hermes
Architecture Document for Bosch CA 2006/2007



10. References
 [ACDM]            Lattanze, A.; Architecture Centric Development Method (ACDM)
                   Version 2.0; 2004




                                                                    Page 18 of 18

				
DOCUMENT INFO
Categories:
Tags:
Stats:
views:14
posted:7/30/2012
language:English
pages:18