Tools M et hods
Process A qualit y focus
communication, requirement
analysis, design
modeling, program construction, testing, and support.
3. Tools It provides automated or semiautomated support for the
process and the methods.
Figure 2.1 Software Engineering Layers
2.4. System Engineering
Based on Pressman 2005, Software Engineering occurs as a consequence of a process called system engineering. Instead of
concentrating solely on software, system engineering focuses on a variety of elements, analyzing, designing, and organizing those elements into a system
that can be a product, a sevice, or a technology for the transformation of information or control.
Based on Forsberg and Mooz 1995, System Engineering is responsible for involving key personnel to address human factors, safety,
producibility, inspectibility, reliability, maintainability,logistics, etc. at each
step, starting with risk analyses andfeasibility studies in the Concept Definition phase.
2.5. System Modeling
Based on Pressman 2005, as a software engineer, it is very important to pay attention in system modeling. System modeling is an important
element of the system engineering process. The focus is on the world view or the detailed view, the engineer creates models that: define the processes
that serve the needs of the view under consideration and represent the behavior of the processes and the assumptions on which the behavior is
based.
2.6 OOAD Process Model 2.6.1
Understanding of Object Oriented
Object is something that always exists around us, both concrete and conceptual. An object has a state and behavior. State
an object is the object conditions stated in the attribute, while the behavior of an object defines how an object to act and to react.
Behavior of an object expressed in the operation. Here is a brief description about the object complete
with attributes and operations.
Figure 2.2 Understanding the attributes and the operations
will make objects become real.
2.6.2 Basic Principles of Object Oriented
Here are some basic principles of Object-Oriented concepts. 1. Inheritance
As described above, the object is an example of a class. This has important consequences as an instance of a class; an
object has all the characteristics of its class. This is called inheritance. Thus, the object will have any attribute and
operation derived from its class.
Figure 2.3 Example of Understanding Inheritance. Kitchen
Equipment and Furniture is inherited from House wares.
2. Encapsulation The term encapsulation is often used interchangeably with
information hiding. Not all agree on the distinctions between the two though; one may think of information hiding as being
the principle and encapsulation being the technique. A software module hides information by encapsulating the information into a
module or other construct which presents an interface. 3. Message Sending
In object oriented systems, objects are mutually communicated each other by sending messages. An object
sends a message to another object to perform an operation and the object that receive will give the response to run the
operation. 4. Association
Association is the relationship between objects that need each other. This relationship can be one-way or multiple ways.
5. Aggregation Aggregation is a special form of association that
describes all parts of an object is part of another object.
2.6.3 The Concept of Object Oriented Analysis and Design OOAD
Object Oriented Analysis and Design or OOAD is a collection of general guidelines for carrying out analysis and design. It must therefore
be tailored to your organization and project. To make our method more
usable, writer designed it so that adaptations, improvements, and part substitutions would be easy to implement.
Based on Mathiassen 2000, OOAD reflects four central perspectives on a system and its context: the system’s information
contents, how the system will be used, the system as a whole, and the system’s components. The perspectives are connected to OOAD main
activities: problem-domain analysis, application-domain analysis, architectural design, and component design, respectively. Each activity
leads to specific results, which are subsequently included in the analysis and design documentation.
2.6.4 Rich Picture
Based on Mathiassen 2000, Rich picture is an informal drawing that presents the illustrator’s understanding of a situation. A rich picture
focuses on important aspects of the situation, which are determined by the illustrator. However, the rich picture should give a broad description
of the situation that enables several alternative interpretations.
2.6.5 Experiments with Prototype
Based on Mathiassen 2000, Although a prototype is less complex that the target system, it helps us talk about and evaluate system
properties. Prototype limitations can be manifold. Also, prototypes rarely represent components completely.
2.6.6 Development Cycle with OOAD
Figure 2.4
Development Cycle OOAD Based on Mathiassen 2000, There are four main activities that are used
for Unified Software Deployment in using OOAD, there are:
1 Problem Domain Analysis
Problem domain analysis focuses on a key question: what information should the system deal with? The answer to this question is so
important during all analysis activities, because the problem-domain model provides a language for expressing requirements to the system.
The aim of problem domain analysis is to develop such a model. To this end, writer employ an object-oriented focus on the key concepts
that users apply to describe the phenomena they administrate, monitor or control.
The primary starting point for problem domain analysis is a system definition. The objects element of the system definition provides the basic
criterion for selecting objects, classes, and events.
1 Classes
Classes Describes how writer approach the task of defining a system’s information content. Writer define and characterize
the problem domain by selecting classes and events. The classes define the relevant parts of the problem domain, and
since writer view this domain as being dynamic, writer are especially aware of the events of the events associated with
objects.
2 Structure
Structure deals with structural relations between classes and objects. Writer describe relation in the problem domain as
either static, abstract structures between classes or dynamic, concrete structures between objects. The structure activity
results in a class diagram that shows the selected classes and the relevant structural relationship between classes and objects.
3 Behavior
Behavior deals with object behavior and interaction. In this activity, writer describe the dynamic properties and attributes
for each of the selected classes. The description of behavior and attributes creates a more precise characterization of each object
in the problem domain.
2 Application Domain Analysis
Application-domain analysis focuses on a question: How will the target system be used? The purpose in asking it is to define requirements for the
system’s functions and interfaces.
1 Usage
Content: How does the system interact with people and systems in the context?
Concepts: Use case and actor.
2 Functions
Content: what are the system’s information processing capabilities?
Concepts: Function.
3 Interface
Content: What are the system’s information requirements? Concepts: Interface, user interfaces, and system interface.
3 Architectural Design
Architectural design is oftern considered an all or nothing question. Wither you build the system from scratch, in which cas all the architectural
issues must be addressed; or you adapt the system to an existing architecture, in which case many architectural decisions have already been
made.The architecture structures a system according to parts and satisfies certain design criteria. To describes a system in a way that eliminates all
essential uncertainties. Creterion a preferred property of an architecure.
Table 2.1 Activities in architectural design
Activity Content
Concepts
Criteria
Components
Process What are the conditions
and criteria for design? How
is the
system structured
into components?
How are the system’s process distributed and
coordinated? Criterion
Component architecture and component
Process architecutre
and process
1. Criteria
In this step, writer look at criteria for object-oriented design and offer simple technique to help you set design priorities.
Table 2.2
Criteria Measure
Criterion Measure of
Usable
Secure
Efficient The system’s adaptability to the organizational,
work-relatived, and technical contexts.
The precautions against unauthorized access to data and facilities.
The economical exploitation of the technical platform’s facilities.
Correct Reliable
Maintainable
Testable
Flexible
Comprehensible
Reusable The fulfillment of requirements.
The fulfillment of the required precisions in function execution.
The cost of locating and fixing system defects. The cost of modifying the deployed system.
The effort needed to obtain a coherent
understanding of the system. The potential for using system parts in other
related systems. The cost of moving the system to another
technical platform. The cost of coupling the system to other systems.
2. Components
Good component architecture makes a system easier to understand, organizing the design work and reflecting the stability of the system’s
context. A class diagram describes the component architecture’s core. UML’s
diagram contains
packages denoting
components, and dependencies between packages denoting component connection.
3. Process
The process architecture brings us closer to the system’s physical level. Writer focus on distribution and execution, and work with processes
and objects as opposed to components and classes. Writer also deal with
the physical devices that the system will be executed on and consider whether writer need to coordinate shared resources.
4 Component Design
The starting point for component design is the architectural specification and the system requirements. The result of this activity is
specification of the connected components. The component design builds on two general principles. The first is
respect the component architecture; the second is adapting component designs to the technical possibilities.
2.7 Object-Oriented Design and Modeling Using the UML Unified Modeling Language
2.7.1 Basic Concept of UML
Based on Munawar 2005, UML is a language with a very broad scope that covers a large and diverse set of application
domains. Not all of its modeling capabilities are necessarily useful in all domains or applications. This suggests that the language
should be structured modularly, with the ability to select only those parts of the language that are of direct interest. On the other hand,
an excess of this type of flexibility increases the likelihood that two different UML tools will be supporting different subsets of the
language, leading to interchange problems between them. Consequently, the definition of compliance for UML requires a
balance to be drawn between modularity and ease of interchange.UML is the work of a consortium of various
organizations that successfully used as a standard in OOAD. Contributions to the UML have been generated from many
reputable companies. As a programming language, UML can translate the diagram into the code that is ready to run.[19]
Five types of diagrams used in this thesis are:
1 Use Cases Diagram
Use cases are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system,
that is, what a system is supposed to do. The key concepts associated with use cases are actors, use cases, and the subject. The
subject is the system under consideration to which the use cases apply. The users and any other systems that may interact with the
subject are represented as actors. Actors always model entities that are outside the system. The required behavior of the subject is
specified by one or more use cases, which are defined according to the needs of actors. Strictly speaking, the term “use case” refers to
a use case type. An instance of a use case refers to an occurrence of the emergent behavior that conforms to the corresponding use case
type. Such instances are often described by interaction specifications.
2 Statechart Diagram
State machines can be used to specify behavior of various model elements. For example, they can be used to model the behavior of
individual entities e.g., class instances. The state machine formalism described in this sub clause is an object-based variant of
Harel statecharts.
3 Activity Diagram
The focus of activity modeling is the sequence and conditions for coordinating lower-level behaviors, rather than which classifiers
own those behaviors. These are commonly called control flow and object flow models. The behaviors coordinated by these models
can be initiated because other behaviors finish executing, because objects and data become available, or because events occur
external to the flow.
4 Class Diagram
The Classes package contains sub packages that deal with the basic modeling concepts of UML, and in particular classes and their
relationships.
5 Sequence Diagram
The most common kind of Interaction Diagram is the Sequence Diagram, which focuses on the Message interchange between a
numbers of Lifelines. A sequence diagram describes an Interaction by focusing on the sequence of Messages that are exchanged, along
with their corresponding Occurrence Specifications on the
Lifelines. The Interactions that are described by Sequence Diagrams are described in this clause.
6 Deployment Diagram
Deployment diagrams show the allocation of Artifacts to Nodes according to the Deployments defined between them.
2.8. Various Platform 2.8.1. Blackberry
BlackBerry is a line of mobile e-mail
and smartphone
devices developed and designed by
Research In Motion RIM since
1999.BlackBerry phones function as a personal digital assistant
andportable media player. They are primarily known for their ability to send and receive
push Internet e-mail wherever
mobile network service coverage is present, or through
Wi-Fi connectivity. They support
a large array of instant messaging features, including BlackBerry
Messenger .
2.8.2. Symbian
Symbian is a mobile operating system
OS and computing
platform designed for
smartphones and currently maintained by
Nokia .
The Symbian platform is the successor to Symbian OS and Nokia Series
60 ; unlike Symbian OS, which needed an additional
user interface system,
Symbian includes a user interface component based on S60 5th Edition. The latest version, Symbian, was officially released in Q4 2010, first used
in the Nokia N8
. In May 2011 Symbian Anna was officially released on
two new phones the Nokia X7 and E6. Nokia announced Symbian Anna will come to all Symbian phones.
2.8.3. Android
Based on Steele and To 2011, Android is the first complete, open, and free mobile platform. Developers enjoy a comprehensive software
development kit, with sample tools for developing powerful, feature-rich applications. The platform is open source, relying on tried-and-true open
standards developers will be familiar with. And best of all, there are no costly barriers to entry for developers.
2.8.3.1. Data Storage Methods
Based on Steele and To 2011, Complicated and robust Android applications often need to utilize some type of data storage. Depending
on the situation, different data storage methods are available to the developer:
Shared Preferences for lightweight usage, such as saving application settings and theuser interface UI state.
A built-in SQLite database for more complicated usage, such as saving application records.
The standard Java flat file storage methods: InputFileStream and OutputFileStream.
2.8.3.2. SharedPreferences
Based on Steele and To 2011, SharedPreferences is an interface that an application can use to quickly and efficiently save
data in name-values pairs, similar to a Bundle. The information is stored in an XML file on the Android device. For example, if the
application com.cookbook.datastorage creates a shared preference,
the Android system creates a new XML file under the data data com. cookbook. datastorage
shared_prefs directory. Shared
preferences are usually used for saving application settings such as user settings, theme, and other general application properties. It can
also save login information such as username, password, auto-login flag and remember-user flag. The shared preferences data is
accessible by every component of the application which created it.
2.8.3.3. SQLite Database
Based on Steele and To 2011, For more complex data structures, a database provides a quicker and more flexible access
method than flat files or shared preferences. Android provides a built-in database called SQLite that provides full relational
database capability utilizing SQL commands. Each application that uses SQLite has its own instance of the database, which is by
default accessible only from the application itself. The database is
stored in the datadatapackage_namedatabases folder of an
Android device. A Content Provider can be used to share the database information between applications. The different steps for
utilizing SQLite are: 1. Create a database.
2. Open the database. 3. Create a table.
4. Create an insert interface for datasets. 5. Create a query interface for datasets.
6. Close the database.
2.10. File Saving and Loading
