sadd - software architecture design document · web view2013. 9. 8. · contents. introduction...

SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT

Contents1. Introduction ...........................................................................................................3

1.1 Scope ..................................................................................................................3

1.1.1 Document scope...........................................................................................3

1.1.2 Product scope...............................................................................................3

1.2 Member Details...................................................................................................4

1.3 Objective.............................................................................................................4

1.4 Traceability to requirements...............................................................................4

1.4.1 User Requirements.......................................................................................4

1.4.2 Functional Requirements..............................................................................5

1.5 Context Diagram................................................................................................5

2. Application Overview............................................................................................6

2.1 Design Discussion .............................................................................................6

2.2 Architecture Design............................................................................................6

2.2.1 Macintosh....................................................................................................7

2.2.2 Codex..........................................................................................................7

2.2.3 Objective C..................................................................................................7

2.2.4 Google API..................................................................................................8

3. Layout and Presentation........................................................................................8

3.1 Subclassing Notes...............................................................................................8

3.1.1 View Management......................................................................................9

3.1.2 Memory Management.................................................................................9

3.1.3 Handling view rotations.............................................................................10

4. Decision Log..........................................................................................................11

4.1 Colours..............................................................................................................13

4.2 Storyboard.........................................................................................................13

5. Architectural Framework....................................................................................21

5.1 Introduction to architectural framework...........................................................21

5.2 Cocoa-a brief note.............................................................................................22

5.3 Cocoa Environment...........................................................................................23

5.3.1 Introducing Cocoa......................................................................................23

5.4 How Cocoa Fits into OS X................................................................................25

5.5 Simple Cocoa Command-Line Tool.................................................................26

PROJECT


5.6 Adding Behaviour to a Cocoa Program............................................................28

5.7 Invoke or Override............................................................................................28

5.8 When to Make a Subclass.................................................................................29

6. Tier Web Architecture.........................................................................................31

6.1 The composition of three tier web architecture.................................................32

6.2 Three tier architecture for mobile development................................................33

6.3 Mobile apps often store their data via APIs......................................................34

6.4 Working with APIs we don’t control................................................................35

References.............................................................................................................36

List of diagrams/images:Context diagram........................................................................................................................5

Figure 3.1.................................................................................................................................10

Figure 4.2.1..............................................................................................................................13

Figure 4.2.2..............................................................................................................................14

Figure 4.2.3..............................................................................................................................15

Figure 4.2.4..............................................................................................................................16

Figure 4.2.5..............................................................................................................................17

Figure 4.2.6..............................................................................................................................18

Figure 4.2.7..............................................................................................................................19

Figure 4.2.8..............................................................................................................................20

Figure 4.2.9..............................................................................................................................21

Figure 5.1.................................................................................................................................26

Figure 5.2.................................................................................................................................29

Figure 5.3.................................................................................................................................30

Figure 5.4.................................................................................................................................31

Figure 6.1.................................................................................................................................32

Figure 6.2.................................................................................................................................34

1. Introduction:

PROJECT


1.1 Scope:

The scope of this project is to develop an application for the iOS mobile

devices on exploring a particular city. In this application the user can expect to search

for the traditional places to visit and the current happening events. The user can also

look for the other important and basic things like restaurants, hotels, navigations, cafe,

weather forecasts, etc.

1.1.1 Document scope:

The document scope is to elaborate the high end technical design of the

application in this project. This explains all the information and details in

developing the application. This documentation will not help anyone or a group in

coding; this is purposely framed for developing the software as a logical idea. The

SADD will be not sufficient for implementing the code. This document will

propose a message of how the system will perform accordingly.

1.1.2 product scope:

The scope of this product is to convey a convenient search place of all the

information about Sydney at single surf. This helps the user to extract all the

required information at one place and makes them more convenient. The

developing application will be accessed using the wireless internet or the cellular

data for the survival for the information.

PROJECT


1.2 Member details:

Student name Student number Email Mobile number

Raja Kandasamy 30102984 [email protected] 0451262824

Ren Zhu 30115339 [email protected] 0430212000

Sadah Suliman 30086830 [email protected] 0416942926

Raja Shekar Donti 30106226 [email protected] 0450150094

Divya Nalla 30107395 [email protected] 0420242311

1.3 Objective:

The objective of this project is to provide the clear and live information to the

user on their requirement. As we begin with the project, each member in the team will

be the client on different aspects. Each expect unique information from the same

application what they are looking for. This helps us to develop innovative ideas and

implement on the application about to be developed.

1.4 Traceability to requirements:

1.4.1 User requirements:

ID User requirements Forward tractability

U1 User taps the screen to enter home screen F1

U2 User selects the options to find their requirements F1

U3 Search result is available to the user F2

U4 The user looks into the results F3,F4

U5 User looks into the another result (optional) F3,F4

U6 Taps the result for final information F5

U7 Reads the information and it navigates the user F5,F6.F7

PROJECT

mailto:[email protected]






1.4.2 Functional requirements:

ID Functional requirement Backward traceability

F1 Touch interface reacts to the user U1

F2 Menu should be displayed with options U2

F3 The interface will be idle till the user selects the

options

U2

F4 The application will search for the entered results

in web

U3

F5 The results will be displayed on screen for the user U4

F6 Collects the information on web for user selected

result

U5

F7 Updates the information if the systems is idle U6,U7

1.5 Context diagram:

2. Application overview:

PROJECT

Wireless network or the

mobile data

Mobile

interface

User options

Mobile

Application

Search results

User reads & taps on


The project that we are developing is to be withheld on the mobile application

that is very popular and used by the most number of people in the world or in the city in

which the people are about to use this application. This mobile application we are

developing has number of the information available for the user. The user can search for

and also to interact with the user in different environment as if the wireless data or the

cellular data is connected to the mobile.

2.1 Design discussion:

The resolution of the application adapts to the iOS mobile devices like iPad,

iPhone, iPod. This is because of the reasonable necessity of the iOS mobile device

users. The application will have four different pages like

Home page

Search screen with search bar

Dropdown list boxes

Button

The data is obtained from the internet for the accurate data that are in current.

This data is stored in the cache memory for the user`s information after the search

option. Later maximum of five recent search results will be stored in the mobile

device data memory. This memory space is allocated with in the application while it

is developed.

2.2 Architecture design:

The iOS application has a minimal requirement regarding the development

languages. This application has a requirement of Macintosh operating system as a

basic feature, the application Codex is to be installed for developing and testing the

code. The Codex is installed with the simulator, which will be more reliable during

the every execution part of the developed code.

The architectural design for this application development has the following

requirement criteria’s.

PROJECT


Macintosh

Codex

Objective c

Google API

2.2.1 Macintosh:

Macintosh is an operating system, that adapts and work on the apple

computers, the latest version is Mountain Lion in which the application is about to

be developed.

2.2.2 Codex:

Codex is the free available application in the mac app store. This needs to be

installed for the development of the application. This software occupies 1.65 GB of

memory in the Mac operating system in which it will be installed. The Codex

application has a default simulator the iOS mobile devices, so that the developer can

execute the codes simultaneously while working on the development.

2.2.3 Objective C:

The “Objective C” is the programming language that has a dedicated software

development of the application for the iOS mobile devices. The objective c is an

object oriented programming language that adapts the Codex application as the initial

requirement. This language can communicate with the internet to retrieve the

information from the Google API.

PROJECT


2.2.4 Google API:

The Google API is the most helpful data for the application that are about to be

developed by our team. This helps the application to acquire the required information’s

like

Weather

Location services

Map directions

Recent searches

Related search results

Favourite places

3. Layout and presentation:

In the case of layout and presenting the software product in the iOS is predefined

according to the default screen size of the mobile devices. The UIViewController is the

keyword that determines the appropriate user interface in the devices. The main use of

this control is to

Control the content of the page accordingly.

Visualise the resized layouts

It tends to act instead of the real time visual as virtual view.

3.1 Subclassing notes:

The iOS application has the sub class notes for different types of interactions between the

user and the device. These subclasses defines and customs the behaviour of the application.

This leads to meet the all basic requirement of the user expects in a particular application.

PROJECT


3.1.1 view management:

The user can define a new subclass of UIViewController; you must specify the

views to be managed by the controller. A typical view hierarchy consists of a view

with flexible bounds a reference to which is available in the view property of this

class and one or more sub views that provide the actual content. The size and position

of the root view is usually determined by another object that owns the view controller

and displays its contents. The view controller determines the positions of any sub

views it owns based on the size given to its root view by the owning object. A view

controller is usually owned by a window or another view controller. If a view

controller is owned by a window object, it acts as the window’s root view controller.

The view controller’s root view is added as a sub view of the window and resized to

fill the window. If the view controller is owned by another view controller, then the

parent view controller determines when and how the child view controller’s contents

are displayed.

3.1.2 memory management:

Memory is a critical resource in iOS, and view controllers provide built-in

support for reducing their memory footprint at critical times. The

UIViewController class provides some automated techniques of haw to handle the

low memory interfaces on the mobile devices are

its didReceiveMemoryWarning method, which releases unneeded memory.

Prior to iOS 6, when a low-memory warning occurred,

the UIViewController class purged its views if it knew it could reload or recreate

them again later. If this happens, it also calls the viewWillUnload and

viewDidUnload methods to give your code a chance to relinquish ownership of

any objects that are associated with your view hierarchy, including objects loaded

from the nib file, objects created in your viewDidLoad method, and objects

created lazily at runtime and added to the view hierarchy. On iOS 6, views are

never purged and these methods are never called. If your view controller needs to

PROJECT


perform specific tasks when memory is low, it should override

the didReceiveMemoryWarning method.

3.1.3 Handling view rotations:

In iOS 6, your app supports the interface orientations defined in your

app’s Info.plist file. A view controller can override

theSupportedOrientationInterface method to limit the list of supported orientations.

Generally, the system calls this method only on the root view controller of the

window or a view controller presented to fill the entire screen; child view controllers

use the portion of the window provided for them by their parent view controller and

no longer participate in directly in decisions about what rotations are supported.

Figure 3.1

PROJECT


4. Decision log:

Decision logs for the work done and work to be done in this project:

ID Title Description Assign

to

Assign

date

Target

date

status comments

1 Training

team

Educating the team

members with the clear

idea about the project

and tools used for the

project

Raja 29/7 5/8 Done

2 Tools to be

accessed

Trained about the tools

used to accomplish this

project successfully.

Ren 29/7 29/7 Done

3 Collecting

internet data

The required data for the

project to be accessed

through the Google API

Divya 31/7 20/9 Hold

4 Collecting

informative

details about

Sydney

The tourists places and

some of the live

happening events and the

date and timing of those

events to be collected

and updated through the

application

Ren

Sadah

5/8 15/9 Hold

5 Increase in

the meeting

To looks after in more

detail about the meeting

minutes and keep

updated with the

discussed information for

the later reference and

usage

Raja

Sadah

29/7 Week

12

On

progre

ss

6 Tools

required

The tools like Mac book,

CodeX software for

development of the app

Raja

Ren

29/7 31/7 Done

PROJECT


7 Team website Create a team website for

the record of the future

information. This will be

updated with the

completed document and

the ongoing document

and the coding work

regarding the project.

Sadah

Rajashe

kar

5/8 30/8 Done

8 Review

software

versions

Make sure the

application about to be

developed is been

recorded with its entire

version for the

maintainability of the

software in future.

Divya 4/8 Week

12

Hold

8 Team review

meetings

Send the team meeting

reviews for everyone as

the proof and reference

on regarding for the

future purpose.

Raja

Shekar

29/7 7/8 Done

9 Create story

boards

To create the story

boards for the application

is to be developed and

clears the logical design,

UID colour combinations

and more things for the

project knowledge

Ren 2/9 4/9 Done

10 Colours,

fonts, layouts

To discuss the logical

and the physical design

features of the

developing application

Ren

Raja

2/9 6/9 Done

4.1 colours:

PROJECT


Apple Inc always uses the predefined set of physical layouts for its application even that are

developed by their non-user. This includes

Buttons

Colour (blue)

Fonts (can be selected with the predefined options)

Menu design

Dropdown boxes (this can be customised by the user)

Search bars (by default)

4.2 Storyboards:

Figure 4.2.1

PROJECT


Figure 4.2.2

This is the second page of the application. This shows the categories of application to be

chosen by the customer.

PROJECT


Figure 4.2.3

The application also provide the users to share their locations along with the applications

name in the social networking accounts like Facebook, Twitter, Google+.

PROJECT


Figure 4.2.4:

This page in the application provides the information for the user with the search bar to

search their desired place and retrieve the detailed information from the search results.

PROJECT


Figure 4.2.5:

This page displays the bulletin points of the relevant searches from the user, as the Google

API point of view and the information.

PROJECT


Figure 4.2.6:

This page informs the local distance as preset and the long distance that user prefer to travel

around.

PROJECT


Figure 4.2.7:

The search results are queued up according to the distance from the short to long according to

the available data.

PROJECT


Figure 4.2.8:

The user selected the search result grabs the detailed information from the API for the user

required data.

PROJECT


Figure 4.2.9:

Maps navigating the user to reach the final destination from the search result.

5. Architectural Framework

5.1 Introduction to architectural framework:

To a developer new to it, Cocoa might seem like a vast, uncharted new world

of technology. The features, tools, concepts, designs, terminology, programming

interfaces, and even programming language of this development environment may all

be unfamiliar. Cocoa Fundamentals Guide eases the initial steps to Cocoa proficiency.

It provides an orientation to the technological landscape that is Cocoa. It introduces its

features, basic concepts, terminology, architectures, and underlying design patterns.

PROJECT


Cocoa applications can be built for two platforms: the OS X operating system

and iOS, the operating system for Multi-Touch devices such as iPhone, iPad, and iPod

touch. Cocoa Fundamentals Guide presents Cocoa-related information for both

platforms, integrating the information as much as possible and pointing out platform

differences when necessary. The intent is that, as you become familiar with Cocoa for

one platform, it will become easier to transfer that knowledge to software

development for the other platform.

Cocoa Fundamentals Guide is structured to lead gradually to a general

understanding of what Cocoa development is all about. It starts with the most basic

information and ends with an examination of its major architectures. Each chapter

builds on what was explained in previous chapters. Each section gives the important

details about a subject, yet describes it at only a high level. A section frequently refers

you to another document that offers a more comprehensive description.

In the set of Cocoa developer documentation, Cocoa Fundamentals Guide is

the conceptual entry-point document. It is prerequisite reading for other essential

Cocoa guides, such as Cocoa Drawing Guide, View Programming Guide, and iOS

App Programming Guide. Cocoa Fundamentals Guide assumes little in terms of

prerequisite reading, but readers should be proficient C programmers and should be

familiar with the capabilities and technologies of the platform they will be developing

for. For OS X, you can acquire this familiarity by reading Mac Technology Overview;

for iOS, read iOS Technology Overview.

5.2 Cocoa-a brief note:

Cocoa is an application environment for both the OS X operating system and

iOS, the operating system used on Multi-Touch devices such as iPhone, iPad, and

iPod touch. It consists of a suite of object-oriented software libraries, a runtime

system, and an integrated development environment.

PROJECT


This chapter expands on this definition, describing the purpose, capabilities,

and components of Cocoa on both platforms. Reading this functional description of

Cocoa is an essential first step for a developer trying to understand Cocoa.

5.3 Cocoa Environment:

Cocoa is a set of object-oriented frameworks that provides a runtime

environment for applications running in OS X and iOS. Cocoa is the preeminent

application environment for OS X and the only application environment for iOS.

(Carbon is an alternative environment in OS X, but it is a compatibility framework

with procedural programmatic interfaces intended to support existing OS X code

bases.) Most of the applications you see in OS X and iOS, including Mail and Safari,

are Cocoa applications. An integrated development environment called Codex

supports application development for both platforms. The combination of this

development environment and Cocoa makes it easy to create a well-factored, full-

featured application.

5.3.1 Introducing Cocoa:

As with all application environments, Cocoa presents two faces; it has a

runtime aspect and a development aspect. In its runtime aspect, Cocoa applications

present the user interface and are tightly integrated with the other visible components

of the operating system; in OS X, these include the Finder, the Dock, and other

applications from all environments.

But it is the development aspect that is the more interesting one to

programmers. Cocoa is an integrated suite of object-oriented software components

that enables you to rapidly create robust, full-featured OS X and iOS applications.

These classes are reusable and adaptable software building blocks; you can use them

as-is or extend them for your specific requirements. Cocoa classes exist for just about

every conceivable development necessity, from user-interface objects to data

PROJECT


formatting. Where a development need hasn’t been anticipated, you can easily create

a subclass of an existing class that answers that need.

iOS Note: Cocoa for iOS supports only application development and not

development of any other kind of executable.

You can use several programming languages when developing Cocoa

software, but the essential, required language is Objective-C. Objective-C is a

superset of ANSI C that has been extended with certain syntactical and semantic

features (derived from Smalltalk) to support object-oriented programming. The few

added conventions are easy to learn and use. Because Objective-C rests on a

foundation of ANSI C, you can freely inter mix straight C code with Objective-C

code. Moreover, your code can call functions defined in non-Cocoa programmatic

interfaces, such as the BSD library interfaces in /user/include. You can even mix C++

code with your Cocoa code and link the compiled code into the same executable.

The most important Cocoa class libraries come packaged in two core

frameworks for each platform: Foundation and AppKit for OS X, and Foundation and

UIKit for iOS. As with all frameworks, these contain not only a dynamically sharable

library (or sometimes several versions of libraries required for backward

compatibility), but header files, API documentation, and related resources. The

pairing of Foundation with AppKit or UIKit reflects the division of the Cocoa

programmatic interfaces into those classes that are not related to a graphical user

interface and those that are. For each platform, its two core frameworks are essential

to any Cocoa project whose end product is an application. Both platforms additionally

support the Core Data framework, which is as important and useful as the core

frameworks.

OS X also ships with several other frameworks that publish Cocoa

programmatic interfaces, such as the Web Kit and Address Book frameworks; more

Cocoa frameworks will be added to the operating system over time. See “The Cocoa

Frameworks” for further information.

PROJECT

https://developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Conceptual/CocoaFundamentals/WhatIsCocoa/WhatIsCocoa.html#//apple_ref/doc/uid/TP40002974-CH3-SW10

https://developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Conceptual/CocoaFundamentals/WhatIsCocoa/WhatIsCocoa.html#//apple_ref/doc/uid/TP40002974-CH3-SW10


5.4 How Cocoa Fits into OS X:

Architecturally, OS X is a series of software layers going from the foundation

of Darwin to the various application frameworks and the user experience they

support. The intervening layers represent the system software largely (but not

entirely) contained in the two major umbrella frameworks, Core Services and

Application Services. A component at one layer generally has dependencies on the

layer beneath it. Figure 1-1 situates Cocoa in this architectural setting.

Figure 5.1: Cocoa in the architecture of OS X

Cocoa Objects

To say that Cocoa is object-oriented is to invite the question, what is a Cocoa

object and what is its relation to the primary programming language for such objects,

Objective-C? This chapter describes what is distinctive about Objective-C objects and

what advantages the language brings to software development in Cocoa. It also shows

you how to use Objective-C to send messages to objects and how to handle return

values from those messages.

PROJECT


5.5 Simple Cocoa Command-Line Tool:

Let’s begin with a simple command-line program created using the

Foundation framework for OS X. Given a series of arbitrary words as parameters, the

program removes redundant occurrences, sorts the remaining list of words in

alphabetical order, and prints the list to standard output.

Listing 5.1 Output from a simple Cocoa tool

localhost> SimpleCocoaTool a z c a l q m z

A

C

L

M

Q

Z

Listing 5.2 shows the Objective-C code for this program.

Listing 5.2 Cocoa code for the Simple Cocoa Tool program

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

NSArray *param = [[NSProcessInfo processInfo] arguments];

NSCountedSet *cset = [[NSCountedSet alloc] initWithArray:param];

NSArray *sorted_args = [[cset allObjects]

PROJECT


sortedArrayUsingSelector:@selector(compare:)];

NSEnumerator *enm = [sorted_args objectEnumerator];

id word;

while (word = [enm nextObject]) {

printf("%s\n", [word UTF8String]);

}

[cset release];

[pool release];

return 0;

}

This code creates and uses several objects: an auto release pool for memory

management, collection objects (arrays and a set) for “uniquing” and sorting the specified

words, and an enumerator object for iterating through the elements in the final array and

printing them to standard output.

The first thing you probably notice about this code is that it is short, perhaps much

shorter than a typical ANSII C version of the same program. Although much of this code

might look strange to you, many of its elements are familiar ANSI C. These include

assignment operators, control-flow statements (while), calls to C-library routines (“printf”),

and primitive scalar types. Objective-C obviously has ANSI C underpinnings.

PROJECT


5.6 Adding Behaviour to a Cocoa Program:

When you develop a Cocoa program in Objective-C, you won’t be on your

own. You’ll be drawing on the work done by Apple and others, on the classes they’ve

developed and packaged in Objective-C frameworks. These frameworks give you a

set of interdependent classes that work together to structure a part.

Figure 5.2

The main function in almost all Cocoa applications is extremely simple. In OS

X, it consists of only one function calls (see Listing 3-1). The NSApplication Main

function creates the application object, sets up an auto release pool, loads the initial

user interface from the main nib file, and runs the application, thereby requesting it to

begin handling events received on the main event loop.

5.7 Invoke or Override:

The framework methods you override in a subclass generally won’t be ones

that you’ll invoke yourself, at least directly. You simply implement the method again

and leave the rest up to the framework. In fact, the more likely you are to write an

application-specific version of a method, the less likely you are to invoke it in your

own code. There’s a good reason for this. In a general sense, a framework class

declares public methods so that you, the developer, can do one of two things:

PROJECT


Invoke them to avail yourself of the services the class provides

Override them to introduce your own code into the program model

defined by the framework

Sometimes a method falls into both these categories; it renders a valuable

service upon invocation, and it can be strategically overridden. But generally, if a

method is one that you can invoke, it’s fully defined by the framework and doesn’t

need to be redefined in your code. If the method is one that you need to implement in

a subclass again, the framework has a particular job for it to do and so will invoke the

method itself at the appropriate times.

Figure 5.3

5.8 When to Make a Subclass:

Just as important as knowing which methods of a class to override—and

indeed preceding that decision—is identifying those classes to inherit from.

Sometimes these decisions can be obvious, and sometimes they can be far from

simple. Few design considerations can guide your choices.

First, know the framework. You should become familiar with the purpose and

capabilities of each class in the framework. Maybe there is a class that already does

what you want to do. And if you find a class that does almost what you want done,

you’re in luck. That class is a promising superclass for your custom class. Subclassing

PROJECT


is a process of reusing an existing class and specializing it for your needs. Sometimes

all a subclass needs to do is override a single inherited method and have the method

do something slightly different from the original behaviour. Other subclasses might

add one or two attributes to their superclass (as instance variables), and then define

the methods that access and operate on these attributes, integrating them into the

superclass behaviour.

There are other considerations that can help you decide where your subclass

best fits into the class hierarchy. What is the nature of the application, or of the part of

the application you’re trying to craft? Some Cocoa architecture imposes the own

subclassing requirements. For example, if yours is a multiple-document application in

OS X, the document-based architecture defined by AppKit requires you to

subclass NSDocument and perhaps other classes as well. To make your Mac app

scriptable (that is, responsive to AppleScript commands), you might have to subclass

one of the scripting classes of AppKit, such as NSScriptCommand.

Figure .5.4

PROJECT


6. Tier Web Architecture

Figure 6.1

The 3 Tier Web Architecture is that unique system of developing web database

application which works around the 3 tier model, comprising of database tier at the bottom,

the application tier in the middle and the client tier at the top. This comprehensive 3 tier

architecture module is the framework for most Web Applications on the Internet. This system

helps to separate the Business Logic from the Application, Data Storage and database. Our

team of experienced and highly efficient technical staff develop the most unique and

exclusive Web Application Development in the web 3tier architecture to enhance our clients

businesses.

The three tier Web Architecture is designed to provide a greater degree of flexibility

and increased security that can be designed for each service at each level. This unique system

of framework for web application development with the 3tier web architecture also ensures

that there is increased performance as the task is shared between servers. Web 3-tier

architecture is a connection and composition of the three links that facilitates the smooth

functioning of the website.

PROJECT


6.1 The composition of three tier web architecture:

The first tier in this 3tier web architecture framework for efficient web

application development is the client tier. This tier includes usually is a web hosting

that includes the HTML recourses that has the necessary user interfaces to enhances

the client‘s experience, as it is the computer that requests the resources, equipped with

the most attractive user interface in adherence to the client’s taste depending on the

industry of this business website. The first tier in the three tier system of architecture

comprises of web browsers for HTTP clients that efficiently interacts and co-ordinates

with the Web servers using the most convenient and standardised protocols. In this

3tier web architecture web application development module, the client is very often

referred to as the tier since very little application logic resides in this particular tier.

This tier also has the necessary built-in feature system which efficiently has more

rich-features than the essential display html page. This tier essentially interacts with

the client by displaying data of various kinds. Only few of the application logic in

form of java script are essentially executed by browser, nevertheless having limited

feature and usage. The sole feature benefit and technical advantage of the 3tier

architecture is that it does not have to depend on any operating platform and neither

on any added or additional software.

The second or the middle tier comprises of the most magnificent and the most

important part of the application logic. It essentially plays the role of bringing

together the three layers of the three tier web architecture. While technically

processing the various inputs and selections received by the clients it plays the role of

interaction with the vast database present in the third tier. The middle or the second

tier in the three tier web architecture contains the web server, the web scripting

language and the scripting language engine. The Web server most often processes the

HTTP requests and formulates reciprocation in the scripting language running on the

scripting engine. This tier has the technical efficiency to deal and comprehend the

dynamic content and built-in libraries that accentuates the faster access of the

database to extract results.

PROJECT


The third tier of the database tier in the 3 tier system is made up of the DBMS

in other words the database management system and the database. This complex

application layer consists of the application logic while exchanging data in between

tiers in the three tier Web Application, making the top tier mostly a thin client or a

browser. The first tire is therefore the data server, providing clients an application

server with all the necessary data that it may require in order to function.

6.2 Three Tier Architecture for Mobile Development:

It is important to at least support 2 platforms so that I would learn how to

design apps with cross-platform in mind from the start. So the 3 tier architecture,

this kind of architecture is familiar for mobile application development that interacts

with the internet to composite the information from the Google API and updates the

results for the user searched or required. This results can also be stored in cache

memory.

Figure 6.2

PROJECT

http://msdn.microsoft.com/en-us/library/ff648105.aspx


The basic idea is that the core of the application would reside in the domain

layer. The interface to the domain and service layers would stay constant so that the

domain layer can be easily translated to a new language on a different platform. The

UI layer could interact directly with the service layer if there is no application logic in

the operation. For example, the UI might show a list of items and can get that directly

from a DAO (data access object) but if that list needs to be processed first it should be

done in the logic section rather than the DAO or UI layer.

The UI layer consists of things like, on iOS, view controllers and on Android

activities. You have to be careful to keep application logic out of this layer as much as

possible.

In the domain layer, the model section contains your POJOs (plain old Java

objects) and the logic section would use DAOs and other services from the services

layer and return data to the UI layer.

The service layer would abstract features of the device like database access,

network access, location etc. for the domain and UI layers. It would not only be a

wrapper on the device specific API but it could also simplify access to the feature so

the domain layer can concentrate on the application logic. For example a location

service might deal with different ways of getting one’s location either using GPS or

cell towers but the other layers don’t have to know about that implementation detail.

6.3 Mobile apps often store their data via APIs:

The leading mobile apps are iOS and Android. However, there are some really

interesting new mobile development platforms like PhoneGap, Sencha and

TRIGGER.IO, which allow developers to build apps with the standard presentation

tier tools they know - like HTML5, JavaScript and CSS – yet package them up as

native mobile apps.

PROJECT

http://en.wikipedia.org/wiki/Plain_Old_Java_Object

http://en.wikipedia.org/wiki/Data_access_object


6.4 Working with APIs we don't control:

As app developers who have been working with APIs quickly realize, they

don’t own all the APIs. Sometimes app development just stops as a result. Why?

Some APIs return XML but not JSON, which is what JavaScript wants.

An API may not support cross origin scripting, which is required for a

JavaScript-powered web app.

An API might return big chunks of data that drown the network capacity

of a mobile app.

PROJECT


References:

https://developer.apple.com/library/ios/DOCUMENTATION/iPhone/Conceptual/

iPhoneOSProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/

TP40007072

https://cloud.google.com/resources/articles/mobile-application-solutions

https://developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Conceptual/

CocoaFundamentals/AddingBehaviortoaCocoaProgram/AddingBehaviorCocoa.html#//

apple_ref/doc/uid/TP40002974-CH5-SW1

http://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/

CollectionViewPGforIO

PROJECT

https://developer.apple.com/library/ios/DOCUMENTATION/Cocoa/Conceptual/CocoaFundamentals/AddingBehaviortoaCocoaProgram/AddingBehaviorCocoa.html#//apple_ref/doc/uid/TP40002974-CH5-SW1



https://cloud.google.com/resources/articles/mobile-application-solutions

https://developer.apple.com/library/ios/DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007072



sadd - software architecture design document · web view2013. 9. 8. · contents. introduction...

Documents