Indrasmoro's World

Begin Use Case Names with a Strong Verb

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 13:47:28 PDT

Good use case names include Withdraw Funds, Register Student in Seminar, and Deliver Shipment because it is clear what each use case does. Use case names beginning with weak verbs such as “process,” “perform,” and “do” are often problematic. Such names often result in communication difficulties with your project stakeholders, people who are far more likely to say that they withdraw funds from accounts instead of process withdrawal transactions. These communication difficulties are likely to decrease your ability to understand their requirements. Furthermore, names such as Process Withdrawal Transaction or Perform Student Enrollment Request often indicate that the use case was written with a technically oriented view instead of a user-oriented view, and therefore may be at risk of not reflecting the actual needs of your project stakeholders.

UML Use Case Diagrams

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 13:49:39 PDT

A UML use case diagram shows the relationships among actors and use cases within a system. They are often used to provide an overview of all or part of the usage requirements for a system or organization in the form of an essential model (Constantine and Lockwood 1999; Ambler 2001) or a business model (Rational Corporation 2002), communicate the scope of a development project, and model your analysis of your usage requirements in the form of a system use case model (Cockburn 2001; Ambler 2001).

A use case model is comprised of one or more use case diagrams and any supporting documentation such as use case specifications and actor definitions. Within most use case models, the use case specifications tend to be the primary artifact, with UML use case diagrams filling a supporting role as the “glue” that keeps your requirements model together. Use case models should be developed from the point of view of your project stakeholders and not from the (often technical) point of view of developers.

Encapsulation

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 13:54:50 PDT

Encapsulation is the process of packaging an object's data together with its methods.

A powerful benefit of encapsulation is the hiding of implementation details from other objects. This means that the internal portion of an object has more limited visibility than the external portion.

The external portion of an object is often referred to as the object's interface, because it acts as the object's interface to the rest of the program. Because other objects must communicate with the object only through its interface, the internal portion of the object is protected from outside tampering. And because an outside program has no access to the internal implementation of an object, the internal implementation can change at any time without affecting other parts of the program.

Encapsulation provides two primary benefits to programmers:

Implementation hiding
Modularity

Implementation hiding refers to the protection of the internal implementation of an object.

An object is composed of a public interface and a private section that can be a combination of internal data and methods. The internal data and methods are the sections of the object that can't be accessed from outside the object. The primary benefit is that these sections can change without affecting programs that use the object.

Modularity means that an object can be maintained independently of other objects.

What's Perl

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 13:21:35 PDT

Perl is an acronym, short for Practical Extraction and Report Language. It was designed by Larry Wall as a tool for writing programs in the UNIX environment and is continually being updated and maintained by him.

For its many fans, Perl provides the best of several worlds. For instance:

Perl has the power and flexibility of a high-level programming language such as C. In fact, as you will see, many of the features of the language are borrowed from C.
Like shell script languages, Perl does not require a special compiler and linker to turn the programs you write into working code. Instead, all you have to do is write the program and tell Perl to run it. This means that Perl is ideal for producing quick solutions to small programming problems, or for creating prototypes to test potential solutions to larger problems.
Perl provides all the features of the script languages sed and awk, plus features not found in either of these two languages. Perl also supports a sed-to-Perl translator and an awk-to-Perl translator.

In short, Perl is as powerful as C but as convenient as awk, sed, and shell scripts.

Classes

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 13:54:36 PDT

A class is a template or prototype that defines a type of object.

A class is to an object what a blueprint is to a house. Many houses can be built from a single blueprint; the blueprint outlines the makeup of the houses. Classes work exactly the same way, except that they outline the makeup of objects.

In the real world, there are often many objects of the same kind. Using the house analogy, there are many different houses around the world, but as houses they all share common characteristics. In object-oriented terms, you would say that your house is a specific instance of the class of objects known as houses.

An instance of a class is an object that has been created in memory using the class as a template. Instances are also sometimes referred to as instantiated objects.

All houses have states and behaviors in common that define them as houses. When a builder starts building a new development of houses, he or she typically will build them all from a set of blueprints. It wouldn't be as efficient to create a new blueprint for every single house, especially when there are so many similarities shared between each one. The same thing applies in object-oriented software development; why rewrite a lot of code when you can reuse code that solves similar problems?

In object-oriented programming, as in construction, it's also common to have many objects of the same kind that share similar characteristics. And like the blueprints for similar houses, you can create blueprints for objects that share certain characteristics. What it boils down to is that classes are software blueprints for objects.

As an example, the class for the car object discussed earlier would contain several variables representing the state of the car, along with implementations for the methods that enable the driver to control the car. The state variables of the car remain hidden underneath the interface. Each instance, or instantiated object, of the car class gets a fresh set of state variables. This brings you to another important point: When an instance of an object is created from a class, the variables declared by that class are allocated in memory. The variables are then modified via the object's methods. Instances of the same class share method implementations but have their own object data. Classes can also contain class data.

Object data, or instance data, is the information that models an object's state. Each object in memory has its own set of instance data, which determines what state the object is in.

Class data is data that is maintained on a class-wide basis, independent of any objects that have been created.

There is only one instance of class data in memory no matter how many objects are created from the class. Class data is typically used to store common information that needs to be shared among all instances of a class. A common example of class data is a count of how many instantiated objects exist of a particular class. When a new object is created, the count is incremented, and when an existing object is destroyed, the count is decremented.

Objects provide the benefits of modularity and information hiding, whereas classes provide the benefit of reusability. Just as the builder reuses the blueprint for a house, the software developer reuses the class for an object. Software programmers can use a class over and over again to create many objects. Each of these objects gets its own data but shares a single method implementation.

Objects

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 13:54:20 PDT

Objects are bundles of data and the code, or procedures, that act on that data.

The procedures in an object are also known as methods. The merger of data and methods provides a means of more accurately representing real-world objects. Modeling a real-world problem through traditional programming constructs, without objects, requires a significant logical leap. Objects, on the other hand, enable programmers to solve real-world problems in the software domain much more easily and logically.

As evident by the name, objects are at the heart of object-oriented technology. To understand how software objects are beneficial, think about the common characteristics of all real-world objects. Lions, cars, and calculators all share two common characteristics: state and behavior.

The state of an object is the condition that the object is in, as defined by its attributes.

The behavior of an object is the collection of actions that the object can take.

For example, the state of a lion might include color, weight, and whether the lion is tired or hungry. Lions also have certain behaviors such as roaring, sleeping, and hunting. The state of a car includes the current speed, the type of transmission, whether it is two- or four-wheel-drive, whether the lights are on, and the current gear, among other things. The behaviors for a car include turning, braking, and accelerating.

Just like real-world objects, software objects possess two common characteristics: state and behavior. To relate this back to programming terms, the state of an object is determined by its data and the behavior of an object is defined by its methods. By making this connection between real-world objects and software objects, you begin to see how objects help bridge the gap between the real world and the world of software living inside your computer.

Because software objects are modeled after real-world objects, you can more easily represent real-world objects in object-oriented programs. You could use the lion object to represent a real lion in an interactive software zoo. Similarly, car objects would be very useful in a racing game. However, you don't always have to think of software objects as modeling physical real-world objects; software objects can be just as useful for modeling abstract concepts. For example, the standard Java API provides a thread object that represents a stream of execution in a multithreaded program.

What's OOP

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 13:53:55 PDT

OOP is an approach to programming that attempts to bridge the gap between problems in the real world and solutions in the computer programming world. Prior to OOP, a conceptual stumbling block always existed for programmers when trying to adapt the real world into the constraints imposed by a traditional programming language. In the real world, people tend to think in terms of "things," but in the pre-OOP programming world people have been taught to think in terms of blocks of code (procedures) and how they act on data. These two modes of thinking are very different from each other and pose a significant problem when it comes to designing complex systems that model the real world. Games happen to be very good examples of complex systems that often model the real world.

OOP presents an approach to programming that allows programmers to think in terms of objects, or things, much like people think of things in the real world. Using OOP techniques, a programmer can focus on the objects that naturally make up a system, rather than trying to rationalize the system into procedures and data. The OOP approach is a very natural and logical application of the way humans already think.

The benefits of OOP go beyond easing the pain of resolving real world problems in the computer domain. Another key issue in OOP is code reuse, when you specifically design objects and programs with the goal of reusing as much of the code as possible, whenever possible. Fortunately, it works out that the fundamental approaches to OOP design naturally encourage code reuse, meaning that it doesn't take much of an extra effort to reuse code after you employ standard OOP tactics.

The OOP design approach revolves around the following major concepts:

Objects
Classes
Encapsulation
Messages
Inheritance

What J2ME Isn’t

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 13:05:55 PDT

The hype about any technology can cause misperceptions about the capabilities of an evolving technology, and J2ME isn’t immune to such misunderstandings. Therefore, it is important to understand the limitations of J2ME. Although J2ME is J2SE without some classes, developers shouldn’t assume that existing Java applications would run in the J2ME environment without requiring modification to the code. The write-once-run-anywhere philosophy of Java is a bit
overstated when it comes to J2ME because of resource constraints imposed by small computing devices.
Some J2SE applications require classes that are not available in J2ME. Likewise, resources required by the J2SE application may not be available on the small computing device. This means that developers must expect to test existing J2SE applications in the J2ME environment and probably pare down the application to run using limited resources. Another misconception about J2ME is the Java Virtual Machine implementation on the small computing device. Small computing devices use one of two Java Virtual Machine implementations. Devices that use the CDC configuration use the full Java Virtual Machine implementation, while devices that use the CLDC configuration use the KJava Virtual Machine implementation.
AMIDlet is not invoked the same way as a J2SE application is invoked because many small computing devices don’t have a command prompt. MIDlets are controlled by application management software (AMS). The manufacturer of a small computing device provides AMS, although third-party vendors might also create AMS. AMS interacts with native operations of a small computing device and controls the life cycle of a MIDlet.
The life cycle consists of installation and upgrades as well as version management and uninstalling the application. Likewise, AMS is responsible for starting, managing
execution, and stopping the MIDlet.

Configurations for J2ME

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 13:06:28 PDT

There are two configurations for J2ME as of this writing. These are Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The CLDC is designed for 16-bit or 32-bit small computing devices with limited amounts of memory. CLDC devices usually have between 160KB and 512KB of available memory and are battery powered. They also use an inconsistent, small-bandwidth network wireless connection and may not have a user interface. CLDC devices use the KJava Virtual Machine (KVM) implementation, which is a stripped-down version of the JVM. CLDC devices include pagers, personal digital assistants, cell phones, dedicated terminals, and handheld consumer devices with between 128KB and 512KB of memory.
CDC devices use a 32-bit architecture, have at least two megabytes of memory available, and implement a complete functional JVM. CDC devices include digital set-top boxes, home appliances, navigation systems, point-of-sale terminals, and smart phones.

Optimizing Loops

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 12:59:02 PDT

A very common performance mistake in PHP is creating loops that iterate over an array without caching the number of elements in the array. For example, consider Listing 1. The first loop can be optimized to perform about 50 percent faster by caching the value of count($arr) in a variable instead of calling count over and over again. You can even get the count inside the for loop's initialization step. Wherever possible, see if you can take static code, which is invariant of the loop's iterator, out of the loop.

Listing 1 Count array elements once

   //setup sample array
   $arr = array("Cosmo" , "Elaine", "George", "Jerry");

   //loop over elements, recounting each time
   for ($i=0; $i < count($arr); $i++)
   {
       print $arr[$i];
   }

   //loop over elements, make count first
   $n = count($arr);
   for ($i=0; $i < $n; $i++)
   {
       print $arr[$i];
   }

   //put count into init step
   for ($i=0, $n = count($arr); $i < $n; $i++)
   {
       print $arr[$i];
   }
?>

Don't Use Regular Expressions Unless You Must

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 12:57:06 PDT

PHP features a very large library of string functions, some of which are extremely powerful. However, in many situations two or more functions can be used to perform the same task, but with great differences in performance.

Perhaps the most commonly overused functions are ereg_replace and preg_replace. These regular-expression-based pattern-replacing functions are often used even when the replacement pattern is completely static and there's no need for compiling a complex regular expression. For instance,

$str = ereg_replace("sheep", "lamb", "Mary had a little sheep");

can be up to 10 times slower than the equivalent

$str = str_replace("Mary had a little sheep", "sheep", "lamb");

Use regular expressions only when you absolutely have to!

If you do have to use a regular expression, try to use the Perl-compatible functions, such as preg_match and preg_replace instead of the older regular expression functions, such as ereg and ereg_replace. Besides being more powerful, the Perl-compatible functions are typically quicker than the old, POSIX regular expressions.

Runtime Errors

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 12:51:44 PDT

The second category of errors are runtime errors, which are exactly what they sound like: errors that occur while the script is running. These errors result from JavaScript that has the correct syntax but that encounters some sort of problem in its execution environment. Common runtime errors result from trying to access a variable, property, method, or object that does not exist or from attempting to utilize a resource that is not available.

Some runtime errors can be found by examination of source code. For example,

window.allert("Hi there");

results in a runtime error because there is no allert() method of the Window object. This example constitutes perfectly legal JavaScript, but the interpreter cannot tell until runtime that invoking window.allert() is invalid, because such a method might have been added as an instance property at some previous point during execution.

Other kinds of runtime errors cannot be caught by examination of source code. For example, while the following might appear to be error-free,

var products = ["Widgets", "Snarks", "Phasers"];

var choice = parseInt(prompt("Enter the number of the product you are

interested in"));

alert(“You chose: " + products[choice]);

what happens if the user enters a negative value for choice? A runtime error indicating the array index is out of bounds.

Although some defensive programming can help here,

var products = ["Widgets", "Snarks", "Phasers"];

var choice = parseInt(prompt("Enter the number of the product in which 

you are interested"));

if (choice >>= 0 && choice << products.length)  

 alert("You chose: " + products[choice]);

the reality is that you cannot catch all potential runtime errors before they occur.

Syntax Error in JavaScript

noreply@blogger.com (indrasmoro79) — Tue, 23 Sep 2008 12:50:26 PDT

Of the three types of errors, syntax errors are the most obvious. They occur when you write code that somehow violates the rules of the JavaScript language. For example, writing the following,

var x = y + * z;

is a syntax error because the syntax of the * operator requires two expressions to operate upon, and “y +” does not constitute a valid expression. Another example is

var myString = "This string doesn't terminate

because the string literal isn’t properly quoted.

Syntax errors are generally fatal in the sense that they are errors from which the interpreter cannot recover. The reason they are fatal is that they introduce ambiguity, which the language syntax is specifically designed to avoid. Sometimes the interpreter can make some sort of assumption about what the programmer intended and can continue to execute the rest of the script. For example, in the case of a non-terminated string literal, the interpreter might assume that the string ends at the end of the line. However, scripts with syntax errors should, for all intents and purposes, be considered incorrect, even if they do run in some manner, as they do not constitute a valid program and their behavior can therefore be erratic, destructive, or otherwise anomalous.

Luckily, syntax errors are fairly easy to catch because they are immediately evident when the script is parsed before being executed. You cannot hide a syntax error from the interpreter in any way except by placing it in a comment. Even placing it inside a block that will never be executed, as in

if (false) { x = y + * z }

will still result in an error. The reason, as we have stated, is that these types of errors show up during the parsing of the script, a step that occurs before execution.

Service-Oriented Architecture

noreply@blogger.com (indrasmoro79) — Mon, 22 Sep 2008 08:52:20 PDT

Opportunity is missed by most people because it is dressed in overalls and looks like work.

—Thomas Edison

Service-Oriented architecture (SOA) is an architectural style that formally separates services, which are the functionality that a system can provide, from service consumers, which are systems that need that functionality. This separation is accomplished by a mechanism known as a service contract, coupled with a mechanism for providers to publish contracts and consumers to locate the contracts that provide the service that they desire. Rather than coupling the consumer with the service in terms of technical aspects of invoking the service, SOA separates the contract from the component or implementation of that contract. This separation produces an architecture in which the coupling between the consumer of the service and the modules that produce the work is extremely loose and easily reconfigured.

Download Service-Oriented Architecture PDF, PP97-2003, PP2007, OpenOffice

Human Interface Principles

noreply@blogger.com (indrasmoro79) — Mon, 22 Sep 2008 08:49:50 PDT

Usability Principle 1: Systems must provide a way to aggregate data and commands.
Usability Principle 2: Systems should allow users to cancel commands.
Usability Principle 3: Systems should allow concurrent use of applications.
Usability Principle 4: Systems should check for correctness.
Usability Principle 5: Systems should allow recovery from systemic failure.
Usability Principle 6: Systems should allow retrieval of forgotten information.
Usability Principle 7: Systems should provide good help.
Usability Principle 8: Systems should allow reuse of existing information.
Usability Principle 9: Systems should leverage users' existing knowledge.
Usability Principle 10: Systems should allow easy modification of interfaces.
Usability Principle 11: Systems should allow navigation from within a single view.
Usability Principle 12: Systems should display the system state.
Usability Principle 13: Systems should allow working at the user's pace.
Usability Principle 14: Systems should predict task duration.
Usability Principle 15: Systems should support Undo, whereby a user may use the Undo command to revert to the state prior to an action.
Usability Principle 16: Systems should help users working in an unfamiliar context.
Usability Principle 17: Systems should verify resources before initiating an operation.
Usability Principle 18: Systems should operate consistently across views.
Usability Principle 19: Systems should support appropriate visualization.
Usability Principle 20: Systems should support comprehensive searching.
Usability Principle 21: Systems should provide ways to evaluate the system.

Download full article.

Web Database

noreply@blogger.com (indrasmoro79) — Sat, 20 Sep 2008 11:04:28 PDT

Web Database dapat diartikan sebagai tempat penyimpanan (repositories) database atau kumpulan informasi yang berinteraksi dengan halaman web secara dinamis. Dapat juga diartikan sebagai sebuah metode penyimpanan content www, dalam format yang terstruktur atau usable, yang terhubung baik secara statis maupun dinamis dengan database lain. Metode ini membantu komunikasi antara web server dan database serta memungkinkan pemakai menerbitan atau mengumpulkan infomasi dari sumber manapun.
Penggunaan web database ini bertujuan sebagai berikut :

menyediakan jalan/cara remote access ke database server melalui browser
menggabungkan web server (http) dengan database server
menggunakan semua metodologi web design standar dalam menyediakan kemudahan pemakaian front end GUI ke database

Contoh aplikasi yang menggunakan web database antara lain e-Commerse, resource libraries, catalogs, diretories (Yellow Page), online Shopping, online Autions, Training Courses, survey, dan analisis keuangan.

Download artikel selengkapnya di sini.

Strenght and Weakness of MySQL Database Server

noreply@blogger.com (indrasmoro79) — Mon, 22 Sep 2008 09:04:24 PDT

Strengths:
■ Speed
■ Reliability
■ Low system resource requirements
■ Scalability
■ Platform diversity
■ Support for a large number of host languages
■ ODBC support
■ Free or low-cost licensing
■ Inexpensive commercial support
■ Strong user community backing
■ Availability of the source code
Weaknesses:
■ Lack of certain SQL features
■ Lack of thorough testing on certain platforms
■ Difficulty of working with the source code

Download article for detail explanation.

Differences between Open Source and Freeware

noreply@blogger.com (indrasmoro79) — Thu, 18 Sep 2008 11:23:37 PDT

Open Source means that all source code are available for all user and free. Freeware means that the software is free but not necessary to give the source code. And, freeware can have limit access.
To be Open Source has some rules :
• Free Redistribution, means that software can be gave and be sold
• Source Code Available, means that the source code has to be opened and can be get free, but not allowed for obsfucator
• Derived Works, means that source can be develop for distribution again
• Integrity of the autor’ source code, means that all the change of source have include the first source’s maker and there are date, time, by and version when modified
• No Discrimation againts people or groups, means that no difference for everyone
• No Discrimation againts fields of Endeavor, means that commercial user allowed too
• Distribution of License, means that all users can use the program without license signature from the third
• License must not be specific to a product, means that the program can not be licensed as a part from bigger. So, smaller software has own distribution
• License must not restrict other software, means that license can not adjust the other program to be open source

Richard Stallman describes freeware based on Four Freedoms for users :

The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbour (freedom 2).
The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

The Role of a Software Architect

noreply@blogger.com (indrasmoro79) — Mon, 22 Sep 2008 08:39:56 PDT

most difficult jobs

Have to confidence of all the stakeholders

able to communicate with varied constituencies

excellent design skills

technology skills

understanding of software engineering best practices

navigate through organizational politics to get the project done correctly and on time

be a leader, a mentor, and a courageous decision maker

Download :
Software Architecture's article for Power Point 97-2003
Software Architecture's article for Power Point 2007
Software Architecture's article for OpenOffice
Practical Guide to Enterprise Architecture, A