Group 24
(Testability)
Amin Ben Karroum
Magnus Raaum
Sibte-Haider Syed
Mari Asplem Hansen
Architecture Document
Android Sosial application
TABLE OF CONTENTS
1. Introduction 3
2. Architectural Drivers 3
3. Stakeholders and Concerns 3
3.1 The developers 3 3.2 The evaluators 3 3.3 The end-users 3 4. Viewpoints 3 4.1 Logical view 3 4.2 Process view 4 4.3 Scenario 4 5. Architectural patterns 4 6. Architectural tactics 4 6.1 Availability 5 6.2 Modifiability 5 6.3 Security 5 6.4 Testability 5 7. Views 6 7.1 Class diagram 6 7.2 State diagram 7 7.3 Scenario 7 7.3.1 S1 8 7.3.2 S2 8 7.3.2 S3 8
8. Consistency among views 9
9. Issues 9
10. References 9
10.1 Resources Error! Bookmark not defined.
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 2.1
2. 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
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.1 AVAILABILITY
-
State storing- Exception handling
6.1.1 RATIONALE
Exception handling needed to have a user-friendly application. 6.2 MODIFIABILITY
- Well documented
- Readable code
- Commented code
6.2.1 RATIONALE
These tactics are needed for a well presented project. 6.3 SECURITY
- Authorization
- Encryption
- Store password hashed and salted
- Penetration testing
6.3.1 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 7. 6.4 TESTABILITY
- Incremental development
- Use a testing framework
- Debugging - State storing - Input/output monitoring - Unit testing - Integration testing 6.4.1 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.
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
7.1.1 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 3rd party software any more than simple black-box testing.
7.1.2 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.
7.1.3 DIAGRAM
7.2 STATE DIAGRAM
7.3 SCENARIO Scenario: 1
Attribute: Testability
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
Attribute: Testability
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
Attribute: Testability
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
Attribute: Testability
Stimilus: Receive messages when user is online. Response: Wait for messages.
Response Measure: Percent of confirmed messages received.
Scenario: 5
Attribute: Testability
Stimilus: Send messages when user is online. Response: Send message to online user.
Response Measure: Percent of confirmed messages sent. Scenario: 6
Attribute: Testability
Stimilus: Contact list updates.
Response: The GUI is updated when a new user is online.
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.
7.3.1 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.
7.3.2 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.
7.3.2 S3
2. This opens the conversation window.
3. The app connects to the users email inbox.
4. The app then downloads all the previous emails from and to this contact.
5. The app parses and displays the emails in the conversation window.
6. An edittext box appears and the user can send an email 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 1417-2000.
11. CHANGES
04.03.2010
Removed pair programming. 15.03.2010
Updated class diagram.
23.04.2010
