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 Page 1
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 2
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 3
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 4
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 5
Wireless network or the
mobile data
Mobile
interface
User options
Mobile
Application
Search results
User reads & taps on
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 6
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 7
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 8
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 9
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 10
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 11
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 12
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 13
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 14
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 15
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 16
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 17
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
Figure 4.2.6:
This page informs the local distance as preset and the long distance that user prefer to travel
around.
PROJECT Page 18
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 19
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
Figure 4.2.8:
The user selected the search result grabs the detailed information from the API for the user
required data.
PROJECT Page 20
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 21
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 22
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 23
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 24
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 25
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 26
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 27
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 28
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 29
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 30
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 31
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 32
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 33
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 34
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 35
SADD - SOFTWARE ARCHITECTURE DESIGN DOCUMENT
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 Page 36
Top Related