Group 24. (Testability) Amin Ben Karroum Magnus Raaum Sibte-Haider Syed Mari Asplem Hansen. Architecture Document. Android Sosial application

Transcription

1 Group 24 (Testability) Amin Ben Karroum Magnus Raaum Sibte-Haider Syed Mari Asplem Hansen Architecture Document Android Sosial application Konnichiwa

2 TABLE OF CONTENTS 1. Introduction 3 2. Architectural Drivers 3 3. Stakeholders and Concerns The developers The evaluators The end-users 3 4. Viewpoints Logical view Process view Scenario 4 5. Architectural patterns 4 6. Architectural tactics Availability Modifiability Security Testability 5 7. Views Class diagram State diagram Scenario S S S Consistency among views 9 9. Issues References Resources Error! Bookmark not defined Papers Error! Bookmark not defined.

3 1. INTRODUCTION After creating the functional requirements, defining the COTS constraints and formulating the quality requirements, we ve started to model the first edition of our architecture. The following paper contains architectural drivers, patterns and tactics as well as the specification of stakeholders and their individual concerns. The architecture is modeled through different viewpoints and notation. This paper will contain documented changes when the development process (iterative) allows us to revisit our modeling of the architecture in latter stages of the project. 2. ARCHITECTURAL DRIVERS 1. The program work on android Receive messages when the user is online 3. Send messages when user is online 4. Limited time 5. Lack of knowledge (MVC specifically) 3. STAKEHOLDERS AND CONCERNS 3.1 THE DEVELOPERS Members: Amin Ben Karroum, Magnus Raaum, Mari Asplem Hansen og Sibte-Haider Syed. Concerns: The concern of the developers is that the system is satisfiable and has good testability for the staff, as well as we want a good grade for the final delivery. 3.2 THE EVALUATORS Members: ATAM group and teaching staff. Concerns: The concern of the staff is that the system we are making will be well documented and the system shall have consistency with the document. While the concern for the ATAM group is that the document is well written so that they can undergo the ATAM evaluation with us. 3.3 THE END-USERS Members: Hypothetical end-users consisting of members from the development group and the ATAM group. Concern: A functional application that they find useful. 4. VIEWPOINTS 4.1 LOGICAL VIEW

4 Objective: To describe the functionality of the system by using UML or some other type of modeling language. Notation: Object classes, E-R diagrams, data-driven approach. We ve used class diagrams in our project. Stakeholders: The end-users and the evaluators. 4.2 PROCESS VIEW Objective: To describe non-functional requirements constraining performance, concurrency, integrity and availability. Notation: State, Activity and sequence. In our first iteration, we ve only used state. Stakeholders: The developers. 4.3 SCENARIO Objective: To use the other views and create scenarios which works towards validating the architectural choices. Notation: Scenarios, Scenario diagrams. Stakeholders: The developers, end-user, testers and evaluators. 5. ARCHITECTURAL PATTERNS Because we want a high testability, we are going to implement model-view-controller. The MVC makes testing easier, this is because we isolate GUI, controller and model from each other, this makes testing easier. The model will be implemented as the classes DBInterface, Conversation and Friend. The view will be the GUI class and the controller is Main as well as EventHandler, Settings, XML and NetworkHandler. Look at the logical view for class diagram and description. 6. ARCHITECTURAL TACTICS

5 6.1 AVAILABILITY - State storing - Exception handling RATIONALE Exception handling needed to have a user-friendly application. 6.2 MODIFIABILITY - Well documented - Readable code - Commented code RATIONALE These tactics are needed for a well presented project. 6.3 SECURITY - Authorization - Encryption - Store password hashed and salted - Penetration testing RATIONALE Some information will be stored locally on the phone, so it s important to encrypt the sensitive information. We will also do the penetration testing. Method used (we will see which of the 24 attacks that is relevant) is defined by Mike Andrews and James A. Whittaker in their book How To Break Web Security. See scenario TESTABILITY - Incremental development - Use a testing framework - Debugging - State storing - Input/output monitoring - Unit testing - Integration testing RATIONALE Incremental development will allow us to re-evaluate the architectural choices we ve done in earlier iterations. By using a testing framework we mean using tools like NUnit. This will allow us to create unit tests while programming (validating the class input and output). See scenario 1.

6 Integration testing will be prioritized due to the fact that we have 4 developers. So integration can stir up some problems. 7. VIEWS 7.1 CLASS DIAGRAM XMPP INTRODUCTION XMPP is open-source technology used for real-time communication. Some of the functionality includes: Instant messaging, multi-party chat, voice and video calls. It uses XML as data notation. We will not test this 3 rd party software any more than simple black-box testing CLASS DESCRIPTION GUI: The user interface. The class will be updated by the controller. Eventhandler: Listens for events on the GUI. Main: The controller class from the MVC pattern. XML: Help class for network. Makes the communication with XMPP possible and easy (e.i parses XML). NetworkHandler: Handles the internet communication. Receives and sends information to XMPP. Conversation: A model for a conversation. It s used by the controller. Friend: A model for a friend. It can be used in a conversation. The class will be managed by the controller. DBInterface: Handles the communication with the DB. Closes, opens, reads and writes to the database. The database is the one included in the Android SDK DIAGRAM

7 7.2 STATE DIAGRAM 7.3 SCENARIO Scenario: 1 Stimilus: Performs unit test (class test). Response: Tester controls the unit behavoir, and the unit's output can be observed. Response Measure: Percent of predictable output. Scenario: 2 Stimilus: Performs integration test (multiple class test). Response: Tester controls the behavoir/state of the integrated component, and the components output can be observed. Response Measure: Percent of predictable output. Scenario: 3 Stimilus: Performs system test (multiple class test). Response: Tester controls the behavoir/state of the the whole system, and system output can be observed. Response Measure: Percent of predictable output. Scenario: 4 Stimilus: Receive messages when user is online. Response: Wait for messages. Response Measure: Percent of confirmed messages received. Scenario: 5 Stimilus: Send messages when user is online. Response: Send message to online user. Response Measure: Percent of confirmed messages sent. Scenario: 6 Stimilus: Contact list updates. Response: The GUI is updated when a new user is online. Response Measure: Time from logon to updated UI on the users screen.

8 Scenario: 7 Attribute: Security Stimilus: Penetration testing Response: Try to get sensitive information from the application Response Measure: Amount of information acquired. The scenarios mentioned below will be used as system tests performed by the end-user S1 1. The user starts the app and opens the account information window. 2. The user then adds all the necessary information needed about his gmail account. 3. When the information is now saved, he can now create a new contact. He opens the contactlist. 4. The user then presses the add new contact button. 5. After filling in the necessary information, the save contact button is pressed and he returns to the contactlist page. 6. After adding the contact, he can now open the conversation window by clicking his name. 7. An editbox appears and he can send his first message S2 1. The user enters the contactlist. 2. He presses a button called delete contact and gets the list of all contacts. 3. After clicking on the name, he gets a confirmation box before the contactlist removes the contact S3 1. The user presses a name on the contactlist.

9 2. This opens the conversation window. 3. The app connects to the users inbox. 4. The app then downloads all the previous s from and to this contact. 5. The app parses and displays the s in the conversation window. 6. An edittext box appears and the user can send an to the contact. 8. CONSISTENCY AMONG VIEWS In our first iteration, we ve decided to use the logical and process view (together with scenarios). When going from logical to process, we ve extracted the agent tasks from the class diagram to create a state diagram. The logical and process views are consistent in the sense that our tasks are represented by classes and processes in the individual views. The link between our scenarios and class diagram would be that our unit testing and implementation testing will happen according to the class diagram (unit testing on classes, implementation testing on the different components (model, view, controller). Our scenarios are also described as models using classes from our class diagram. The scenario notation was based architectural choices made in the former views. 9. ISSUES We had some trouble meeting this week, so we haven t had a good discussion about the more specific details of our architecture (especially the class diagram). We do expect changes in the notation of our views in the next iterations. 10. REFERENCES - Slides - Architectural Blueprints The 4+1 View Model of Software Architecture by Philippe Kruchten. - IEEE Standard CHANGES Changed our architecture drivers.

10 Removed pair programming Updated class diagram Updated architectural driver