Software Architecture Document- Android Project

Track The Movement

Software Architecture Document

 

Version 1.0

 

 

 

 

Revision History

Date	Version	Description	Author
29/10/2010	1.0	Initial draft	Jayaprabath fernando

 

 

1.    Introduction    4

1.1    Purpose    4

1.2    Scope    4

1.3    Definitions, Acronyms, and Abbreviations    4

1.4    References    4

1.5    Overview    4

2.    Architectural Representation    4

3.    Architectural Goals and Constraints    5

3.1    Technical Platform    5

3.2    Security    5

3.3    Performance    5

4.    Use-Case View    6

4.1    Use-Case Realizations    6

5.    Logical View    6

5.1    Overview    6

5.2    Architecturally Significant Design Packages    6

6.    Process View    8

7.    Deployment View    8

8.    Implementation View    9

8.1    Overview    9

8.2    Layers    9

9.    Size and Performance    9

10.    Quality    10

Software Architecture Document

Introduction

This introductory part of the software architecture document (SAD) describes the organization of this document. It includes purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Software Architecture Document.

Purpose

This document provides a comprehensive architectural overview of the Movement Tracking System which is being developed to assist transport service providers to manage resources, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.

 

 

 

Scope

The scope of this SAD is to depict the architecture of the Movement Tracking System.

Definitions, Acronyms, and Abbreviations

RUP- Rational Unified Process

UML- Unified Modeling Language

SAD- Software Architecture Document

References

[RUP]:        The IBM Rational Unified Process

[RSA]:        IBM Rational Software Architect

 

[KRU41]:     The "4+1" view model of software architecture, Philippe Kruchten, November 1995,

 

Overview

This subsection describes what the rest of the Software Architecture Document contains and explains how the Software Architecture Document is organized

 

Architectural Representation

This document details the architecture using the views defined in the "4+1" model [KRU41], but using the RUP naming convention. The views used to document the Yummy Inc. application are:

 

Logical view

Audience: Designers.

Area: Functional Requirements: describes the design's object model. Also describes the most important use-case realizations.

Related Artifacts: Design model

 

Process view

Audience: Integrators.

Area: Non-functional requirements: describes the design's concurrency and synchronization aspects.

Related Artifacts: (no specific artifact).

 

Implementation view

Audience: Programmers.

Area: Software components: describes the layers and subsystems of the application.

Related Artifacts: (no specific articraft)

 

Deployment view

Audience: Deployment managers.

Area: Topology: describes the mapping of the software onto the hardware and shows the system's distributed aspects.

Related Artifacts: Deployment model.

 

Use Case view

Audience: all the stakeholders of the system, including the end-users.

Area: describes the set of scenarios and/or use cases that represent some significant, central functionality of the system.

Related Artifacts : Use-Case Model, Use-Case documents

 

Architectural Goals and Constraints

This section describes the software requirements and objectives that have some significant impact on the architecture

 

Technical Platform

• This system development is done based on Android Mobile platform and external features provided by Google to share data by using Google external library facility that supports android platform.
  

Security

• Sharing location data is done using services provided by Google and they do not allow any unauthorized access to any data. Therefore data access control would happen according to Google's' policies.
  

Performance

• A trade off has to be made between accuracy and availability due to the low capabilities of power supplies of client mobile devices. System administrator is responsible for making this decision based on recommendations provided by the developer.
  

 

 

Use-Case View

This section lists use cases or scenarios from the use-case model if they represent some significant, central functionality of the final system. The only use case which would have a significant roll in the system is the monitor function which would start monitoring the transporters of the organization. Other use cases such as adding employees viewing reports are implemented in a similar manner to all other common application and they are part of the admin device sub system.

 

 

 

Use-Case Realizations

Refers to section 5.2 to see how design elements provide the functionalities identified in the significant use-cases.

Logical View

This section describes the architecturally significant parts of the design model.

 

Overview

The architecture of the Movement Tracking System is based on Share Repository Architectural Model.

Architecturally Significant Design Packages

    Overall system view

 

    Abstract Machine Model of the Admin Device sub system

 

    Sequence diagram for monitor use case

 

 

Process View

There's only one process to take into account. It would run in isolation from presentation layer. Therefore there is no significant impact to the overall architecture of the system.

Deployment View

Global Overview

 

 

Details

• Local data of admin device subsystem would be handled using SQL Lite relation database
  
• Location detail management of client devices would be done at Google.
  

Implementation View

This section describes the overall structure of the implementation model, the decomposition of the software into layers and subsystems in the implementation model.

Overview

The Implementation view depicts the physical composition of the implementation in terms of Implementation Subsystems. This document would only concentrate on the most critical sub system of the movement tracker application, which is the Admin Device sub system. Section below describes the each layer of the sub system without going into the in-depth analysis of the implementation.

Layers

Presentation Layer

• The Presentation layer contains all the components needed to allow interactions with an end-user. It encompasses the user interface
  

Control Layer

• The Control layer contains all the components used to access the android system layer or directly the resources such as local database when this is appropriate.
  

Android System Layer

• The whole application runs on top of this layer, which is a standard mobile application platform.
  

Size and Performance

Volumes:

• Estimated number of monitored employees : max 20 employees
  

  Performance:
  

• Accuracy and performance trade off has to be made by the administrator based on the recommendation given by the developer due to low capabilities of client devices.
  

  
   

  Quality
  

  As far as the movement tracking application is concerned, the following quality goals have been identified:
  

  Compatibility:
  

  • Description: Ability to be reused with a newer version of the platform.
    
  • Solution: Android platform supports the forward compatibility.
    

  Security:
  

  • Description : Authentication and authorization mechanisms
    
  • Solution : sensitive data access would be controlled according to well established Google policies
    

Google Maps API Key

type this in the command prompt
           keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -validity 10000

follow the setup entering password etc. this will generate keys which are valid for 10000 days.

if the setup dose not proceeds check your environment variables..........

then type this in the command prompt

      keytool -list -alias alias_name -keystore my-release-key.keystore

 prompt will display the MD5 certificate
fingerprint

Go To The 

http://code.google.com/android/add-ons/google-apis/maps-api-signup.html

now you have an key to sign your applications

C source code to tell the day when the date is given

#include <stdio.h>
int main ( )
{
int y,m,d,a,b,f;
printf ("enter the date -:(YYYY MM DD)\n");
scanf ("%d %d %d",&y,&m,&d);
if (12>m&&m>0)
{
 if (m<3)
{
m=m+12;
y=y-1;
}
a=2*m+6*(m+1)/10;
b=y+y/4-y/100+y/400;
f=d+a+b+1;
f=f%7;
}
else
{
printf("error\n");
}
switch(f)
{
case 0:
printf ("sunday\n");
break;
case 1:
printf ("Monday\n");
break;
case 2:
printf ("Tuesday\n");
break;
case 3:
printf ("Wednesday\n");
break;
case 4:
printf ("Thursday\n ");
break;
case 5:
printf ("Friday\n");
break;
case 6:
printf ("Saturday\n ");
break;
}
return 0;
}

this source code is very simple you can implement this in any other language very easily. hope you'll like this. anxiously waiting for someones thoughts.

First Post

this is my first post. I'm a person who is interested in programming. so, i would basically use this blog  to share my thoughts about programming with java and android platform. i just want to see how this works. so, any kind of comments are warmly welcomed.
i'm also thinking about using my blog to share beauty of my motherland with all of you. some might have heard about SriLanka while others may not. But i can assure you that each of you can learn about history and proud culture of my country.
i hope this is a good start. if you feel this really stupid you can criticize.