Component API Design Evaluation

five major issues, difficulties, and challenges in component API design
Major Issues:

 Define useful API’s characteristics: To define the key factors making API more helpful for coders .
 Define usable API’s characteristics: To define the key factors making the API document better on easiness, Learnability and rememberability.
 Making useful APIs: Follow the defined characteristics and make the APIs useful.
 Making usable APIs: Follow the defined characteristics and make the APIs usable.
 The factors affecting usable useful API: Check the defects of early design and optimize the document.


Difficulties:

When an API has such following troubles, the users will have difficulties to use this API:

 Bad Learnability: Loose organization, bad logic, and other things to make API difficult to learn.
 Bad Rememberability: A huge set of concepts or function lists will have the coders to search in the API document time by time.
 Hard to write client codes
 Hard to interpret client codes:
 Frequent misuse: Bad naming and misunderstanding description may cause the coders to select the wrong function and get in troubles.

five major causes which lead to poor component API usability

 Complex! : The number of functions exceed the need of users, and leads to the unnecessary complexity.
 Too simple! : Only a few words for a very complex function will not help the coders at all.
 Bad naming! : call1(), call2(), call3() are much more confused than callclient(), calladmin()…
 Ignorance of caller’s perspective! : APIs should be designed from the perspective of the caller , otherwise it may loose usability.
 Concept incorrectness! : If the definition itself is not correct, how can coders get correct function in this document?


five component API design tips to increase component API usability )


 Easy to learn.
 Easy to remember.
 Easy write client code.
 Easy to interpret client code.
 Difficult to misuse.

A Comparative Study: Component-based software engineering V.S. Service-oriented software engineering

A Comparative Study: Component-based software engineering V.S. Service-oriented software engineering






1 Project introduction 3
2 Component based software engineering 3
2.1 Definitions(Component based software engineering) 3
2.2 Concepts (Component, Module, Interface, Object) 3
2.3 Objectives 6
2.4 Benefits and disadvantages 6
2.5 Needs and Motivation 7
3 What is SOA-based software engineering? 7
3.1 Definitions 7
3.2 Concepts 8
3.3 Objectives 9
3.4 Benefits: 12
3.5 The future of SOA 13
4 What are the major differences and similarity between these two approaches? 15
5 What are the differences between service components and modern components? 20
5.1 What is service? 20
5.2 What is modern component? 21
6 Building SOA-based software system is same as building a component-based system using service components? 24
7 Tools and technologies for building service components 26
7.1 Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft 26
7.2 IBM Service Component Architecture Explorer Tool 26
8 Discussions and justification comments 27
8.1 What is SOA? Can we buy it? 27
8.2 What’s the base system of SOA? 27
8.3 How to design service contract? 28
9 A summary, conclusions, and future directions 31
Reference 32











1 Project introduction
There are people who start to accept the “new idea” and try to change their software product structure into component based, and there are also people who start to research on new concepts on software structure to replace the “nearly old fashioned and full of overestimate” – Service oriented architecture. Things might be worse under the current economic crisis as adopting new business architecture are lacking of funds, even some specialists pointed out “SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession” [1]. That’s the IT industry, which seems they never have the latest and the best technique in all kinds of areas.
Neutrally speaking, component based architecture is still enough for most of current requirements, despite of its “old” age of more than 20 years. And after the depression, SOA will still be the most prospective architecture within a few years, but there are already articles that doubt if SOA will be easily applied by most enterprises and easily get the expected positive results after applying SOA.
This paper will briefly compare component based software engineering and service oriented software engineering. The concepts, comparison, tools and methods will show how these two major software architectures play their roles in current enterprise software.
2 Component based software engineering
2.1 Definitions (Component based software engineering)
Component based software engineering (Abbreviation: CBSE), Component based development, Component based programming, are exactly the same thing in software industry. In Wikipedia, CBSE is defined as “a branch of the software engineering discipline, with emphasis on decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components”
This definition introduces the basic unit forming the CBSE – Component (Software component). The architecture is built by the relations between the components “decomposed” from the whole system. The interfaces enable these components communicate with each other and connected to form the whole system.
2.2 Concepts (Component, Module, Interface, Object)
To explain the concepts in component based software engineering and their functions, relationships, we would like to introduce a kind of toys which was very popular in our childhood – Electronic bricks, as the example. Each brick has outer plugs to be connected with other bricks, and have different functions: line, battery, bulb, diode… Under the instructions, players could build up a radio with easy functions or a speaker, etc.
 Component
A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.[2] Clement Szyperski lists three major properties of software component: a unit of independent deployment ; a unit of third-party composition ; no observable state (Encapsulated).
Let’s consider the CBSE as a set of Electronic Bricks. Here is what a single brick is designed in this toy: An opaque plastic shell, with sockets in the bottom, and outlets in the top, and a kind of electronic component or a set of circuit inside. The sockets and outlets are used to connect with other bricks or the main board to install these bricks. Players could only see the corresponding electronic symbol instead of the inside structure of the brick.
Let’s conclude the properties of this brick and compare them with the properties of CBSE to get the ones of CBSE much clearer and organized:

Figure 1 “Electronic bricks” – Components
Unit of independent deployment: a brick is the basic unit of setup any kind of “product”, so do the software component.
Third-party composition: The players are not the producers of these electronic bricks.
Encapsulated: The players could not see the inside structure of the bricks. They can only judge the function of the brick by its electronic sign on the top.
Communicating with other components: A brick could connect to others with its sockets and outlets.
Multiple use (Reusable): These bricks could be used by many times to setup many kinds of products.
 Component Interface
Return to the electronic bricks, the board which has specified placed outlets to install the bricks, is exactly playing the role of component interface.

Figure 2 “Bricks and board” - Components and interface
In CBSE, connecting and enable communication between components is not so easy as plug the bricks on the outlets. First of all, a good designed interface is required. An interface of software component could be defined as a specification of its access point.
The interface doesn’t offer any implementation of its operations, only provides the descriptions and protocols. Thus, it enables itself to replace implementation with interface changes, or add new interfaces and implementation without any change on implementation.
 Other concepts
Patterns : a pattern defines a recurring solution to a recurring problem. It could be employed in the design and documentation of a software component. It could be used to describe the low-level implementation details of the behavior and structure of the components, or the relationships between components in the context of a particular programming language.
Component model: A component model defines a set of standards and conventions used by the computer developer, whereas a component framework is a support infrastructure for the component model.
2.3 Objectives
There comes out the question, what should CBSE do after they are applied? Why the definitions of CBSE are clinched to those principles? Let’s list out those obvious things which will benefit the whole software production.
First of all, under CBSE the components could be reused many times, the designers don’t need to mess with the inside code of the component, just get it, setup on the interface, and then connect them together. CBSE has very specified detail document to provide support for these operations so that the designers would not confuse on the component functions.
Thus, applying component based software engineering should have these objectives :
To reduce system production cost and time by reusing existing reusable and high quality components
To provide support for the development of systems as assemblies of components
To support the development of components as reusable entities
To facilitate the maintenance and upgrading of systems by customizing and replacing their components
2.4 Benefits and disadvantages
By achieving these goals, CBSE has several advantages towards the old software architectures:
a) Lead time reduced : by building applications from reusable components
b) Cost reduced : Multiple reusing components could save the cost of developing new components
c) Higher quality: more times a component has been used, more times it has been tested. Retesting is one of the most powerful methods to enhance coding quality.
d) Easy Maintenance: easy updating with simply replace the old version components by new version, which could also save the maintenance cost.
Of course, CBSE is not the answer to every problems in software designing, that’s why SOA is grabbing more and more users. Before we talk about SOA, let’s see what the things CBSE lacks of are.
e) Difficult specification: it’s not easy to specify component standards during first time design.
f) Lacks of ideal component models: there are still many existing component models which are incomplete, inconsistent, and have problems during deployment. In one word, they are not standardized.
g) Life cycle problems: As components are not observable, there will be more problems during independent component development process.
Production from scratch is a very expensive undertaking. Suboptimal solutions in all but the local areas of expertise are likely. Maintenance and “chasing” of the state-of-the-art, such as incorporating web access, can become a major burden. Interoperability requirements further the burden, with other in-house systems and, more critically, also with business partners and customers. As a result, most large projects fail partially or completely, leading to a substantial risk. [3]
2.5 Needs and Motivation
CBD claims include reductions both in development costs and time and the increase of the developed software system’s overall quality [4]. These improvements result from reuse: building software from existing well tested building blocks is more effective than developing similar functionalities from scratch. It is important to analyze the reuse related improvement achieved through CBD. The bulk of component related research has been mainly focused on the functionality and composability of components, as well as their specification. The research niche of component quality assessment, with an emphasis on quantitative approaches , is fairly unexplored. The few existing evaluations are performed at a qualitative level, which makes the assessment of the true impact of the above-mentioned claims harder. In our research, we are particularly interested in the quantitative evaluation of software components and their impact on the systems they are integrated in.
3 What is SOA-based software engineering?
3.1 Definitions
It is hard to find an exact definition of the term SOA. The problem is not that there aren't any definitions; the problem is that there are many different definitions. To give you an idea of how they are similar and dissimilar, a selection of published definitions are sidebars in this chapter. You'll find some common phrases and attributes as you read them, but you will also find a lot of differences in the context, level of abstraction, and wording [5].
However, at least all definitions agree that SOA is a paradigm for improved flexibility. Here are some definitions
 A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
- OASIS (the Organization for the Advancement of Structured Information Standards)
 In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services. An SOA infrastructure allows different applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. [6] SOA separates functions into distinct units, or service [7]. which developers make accessible over a network in order that users can combine and reuse them in the production of business application [8]. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.
- Wikipedia
 SOA is not a concrete architecture: it is something that leads to a concrete architecture. You might call it a style, paradigm, concept, perspective, philosophy, or representation. That is, SOA is not a concrete tool or framework you can purchase. It is an approach, a way of thinking, a value system that leads to certain concrete decisions when designing a concrete software architecture.[9]
3.2 Concepts
Here are the key technical concepts of SOA that allow it to cope with the system characteristics just described [10]:
 Services
Software development is the art of abstraction. We have to abstract reality in such a way that only the relevant aspects of a problem are handled. However, we all know that we can abstract from different perspectives. SOA aims to abstract by concentrating on the business aspects of a problem. The fundamental term introduced here is service. In essence, a service is an IT representation of some business functionality. The goal of SOA is to structure large distributed systems based on the abstractions of business rules and functions.
This gives a clear structure to the IT systems we design and develop. Although internally they are, of course, technical systems, the external interfaces should be designed in such a way that business people can understand them. Externally, you should not see the technical details. The smart consequence of this approach is that at this level of abstraction, platform-specific details don't matter. Thus, platforms can be heterogeneous.
Besides this broad definition, it is not clear what exactly a service is or can be. There are very different opinions about the exact attributes a service must, can, or should have. I will discuss services in detail in the next chapter (presenting several different existing definitions for services as well). As a rule of thumb, however, you can consider a service to be the IT representation of self-contained business functionality, such as "create a customer," "get a customer's contracts," "transfer money," "turn on the radio," "calculate the best route for my car," and so on.
 Interoperability
With heterogeneous systems, the first goal is to be able to connect those systems easily. This is usually called "high interoperability." High interoperability is not a new idea. Before SOA, we had the concept of enterprise application integration (EAI), and regarding interoperability, SOA is nothing new.
However, for SOA, high interoperability is the beginning, not the end. It is the base from which we start to implement business functionality (services) that is spread over multiple distributed systems.
 Loose coupling
As I've already mentioned, we live in a world ruled by marketing guys. We don't always have time to analyze, design, and implement carefully. We need fast times to market, so flexibility is often valued over quality. This leads to several problems.
Consider that at the same time we are integrating more and more systems, and implementing business processes by distributing them over different systems. In principle, data flows in such a way that processes run successfully in all the affected systems: we create a customer in all our systems, transfer money from one system to the other, or process a customer's order by shipping a product and sending a bill.
3.3 Objectives
The upcoming set of sections describes each of these strategic goals:
Overall goals [11]:
 Increased Intrinsic Interoperability
Interoperability refers to the sharing of data. The more interoperable software programs are, the easier it is for them to exchange information. Software programs that are not interoperable need to be integrated. Therefore, integration can be seen as a process that enables interoperability. A goal of service-orientation is to establish native interoperability within services in order to reduce the need for integration.
 Increased Federation
A federated IT environment is one where resources and applications are united while maintaining their individual autonomy and self-governance. SOA aims to increase a federated perspective of an enterprise to whatever extend it is applied. It accomplishes this through the widespread deployment of standardized and composable services each of which encapsulates a segment of the enterprise and expresses it in a consistent manner.
 Increased Vendor Diversification Options
Vendor diversification refers to the ability an organization has to pick and choose “best-of-breed” vendor products and technology innovations and use them together within one enterprise. It is not necessarily beneficial for an organization to have a vendor-diverse environment; however, it is beneficial to have the option to diversify when required. To have and retain this option requires that its technology architecture not be tied or locked into any one specific vendor platform (Figure 3).

Figure 3 A service composition consisting of three services.
 Increased Business and Technology Domain Alignment
The extent to which IT business requirements are fulfilled is often associated with the accuracy with which business logic is expressed and automated by solution logic. Although initial application have traditionally been challenging to keep applications in alignment with business needs when the nature and direction of the business changes.
Service-oriented computing introduces a design paradigm that promotes abstraction on many levels. One of the most effective means by which functional abstraction is applied is the establishment of service layers that accurately encapsulate and represent business models. By doing so, common, pre-existing representations of business logic can exist in implemented form as physical services
System goals [12]:
 Flexibility
 Scalability
 Fault tolerance
The key to fulfilling these goals is loose coupling. Loose coupling is the concept of minimizing dependencies. When dependencies are minimized, modifications have minimized effects, and the systems still runs when parts of it are broken or down. Minimizing dependencies contributes to fault tolerance and flexibility, which is exactly what we need.
In addition, loose coupling leads to scalability. Large systems tend to challenge limits. Therefore, it is important to avoid bottlenecks; otherwise, growing might become very expensive. Avoiding bottlenecks is important from both a technical and an organizational point of view. All large systems only work if the usual business can be done in as decentralized a manner as possible. One way to introduce loose coupling is to avoid introducing any more centralization than is necessary (unfortunately, you need some centralization to establish SOA because you need some common base).
 Needs:
Having read that the key technical concepts for SOA are services, interoperability, and loose coupling, you might conclude that all you have to do to enable SOA is to introduce services, interoperability, and loose coupling [13]:.
But as I stated earlier, you can't buy SOA. What's important is that you introduce these concepts in the appropriate fashion. That is, you have to find the right degree of centralization, you have to set up the corresponding processes, and you have to do your homework. A lack of these "ingredients" is what I most often find as the problem in real SOA projects. To establish SOA successfully, you have to care for your infrastructure, architecture, and processes (including the metaprocess, governance).
 Infrastructure
Infrastructure is the technical part of SOA that enables high interoperability. The infrastructure of a SOA landscape is called an enterprise service bus (ESB). This term is taken from enterprise application integration, where it was called the EAI bus or just enterprise bus.
The key feature of the ESB is that it enables you to call services between heterogeneous systems. Its responsibilities include data transformation, (intelligent) routing, dealing with security and reliability, service management, monitoring, and logging.
 Architecture
Architecture is necessary to restrict all the possibilities of SOA in such a way that it leads to a working, maintainable system. SOA concepts, SOA tools, and SOA standards leave room for specific decisions that you must make in order to avoid a mess. You have to classify different types of services, you have to decide on the amount of loose coupling, you have to restrict the data model of service interfaces, you have to define policies, rules, and patterns, you have to clarify roles and responsibilities, you have to decide on the infrastructure technology, you have to decide which (version of) standards to use, and so on.
 Processes
One thing that makes large systems complicated is that many different people and teams are involved in them. As a consequence, it is a long path from an initial business idea or requirement to a solution running in production mode.
 Governance
The metaprocess of all processes and a SOA strategy as a whole is governance. You have to set up the right process to establish SOA in your organization. This includes finding the right people who are able to combine all the different SOA ingredients to create a result that works and is appropriate. There is usually a central team (sometimes called the SOA competence center) that deals with infrastructure, architecture, and processes. This team is also responsible for establishing a common understanding, and doing the homework right. This requires management support, because in addition to time and resources, courage is required to deal with the organizational impacts of SOA Understanding, governance, management support, and homework are key factors for the success of SOA.
3.4 Benefits:
[14] An SOA can be evolved based on existing system investments rather than requiring a full-scale system rewrite. Organizations that focus their develop¬ment efforts around the creation of services, using existing technologies, combined with the component-based approach to software development will realize several benefits.
 Leveraging existing assets. This benefit is the first, and most important, of the requirements discussed earlier in this paper. You can construct a business service as an aggregation of existing components, using a suitable SOA framework and made available to your enterprise. Using this new service requires knowing only its interface and name. The service’s implementation specifics (such as its component architecture) or discrete functional components—as well as the complexities of the data flow through the components that make up the service—are transparent to callers. This component anonymity lets organizations leverage current investments, building services from a conglomeration of components built on different machines, running different operating systems, developed in different programming languages. Legacy systems can be encapsulated and accessed using Web services interfaces. More important, legacy systems can be transformed, adding value as their functionality is transformed into services.
 Infrastructure as a commodity. Infrastructure development and deployment will become more consistent across all your different enterprise applications. Existing components, newly developed components and components purchased from a range of vendors can be consolidated within a well-defined SOA framework. Such an aggregation of components will be deployed as services on the existing infrastructure. As a result, the underlying infrastructure becomes more of a commodity. Over time, as services become more loosely coupled from the supporting hardware, you can optimize the hardware because the service assembler is no longer dependent upon the hardware environment on which the service operates at run time.
 Faster time-to-market. Organizational Web services libraries will become your organization’s core assets as part of your SOA framework. Building and deploying services with these Web services libraries will reduce your time to market dramatically, as new initiatives reuse existing services and components, reducing design, development, testing and deployment time in the process. As services reach critical mass in your organization or trusted network, the larger ecosystem emerges — enabling you to assemble composite applications using services, rather than developing custom applications.
 Reduced cost. As business demands evolve and new requirements are introduced, the cost to enhance and create new services by adapting the SOA framework and the services library, for both existing and new applications, is greatly reduced. The learning curve for the development team is reduced as well, as they may already be familiar with the existing components.
 Risk mitigation. Reusing existing components reduces the risk of introducing new failures into the process of enhancing or creating new business services. You will also reduce the risk in the maintenance and management of the infrastructure supporting the services.
 Continuous business-process improvement. An SOA allows a clear representation of process flows identified by the order of the components used in a particular business service—and provides business users with an ideal environment for monitoring business operations. Process modeling is reflected in the business service. Process manipulation is achieved by reorganizing the pieces in a pattern (components that constitute a business service). This function allows you to change the process flows while monitoring the effects to facilitate continuous improvement.
3.5 The future of SOA
So far, this white paper discussion centers around the need to increase speed of business changes, and to improve business performance and efficiency. These requirements mandate a set of IT imperatives for flexibility where SOA becomes a key enabler. But what if a completely new model for application development emerges? Will the notion of an SOA still be meaningful or required? The answer is a resounding, yes. Two new, emerging concepts are beginning to be implemented: grid computing and on demand computing. While these models are distinct and have developed separately, they are closely related; and each makes the evolution to SOA even more imperative. Representing every application, resource or business capability as a service with a standardized interface allows you to quickly combine new and existing applications to address changing business needs and improve operational effectiveness — the essence of SOA. As a result, SOA becomes the DNA of grid computing and on demand computing.
 Grid computing
An in-depth discussion of grid computing is beyond the scope of this paper, but a couple of points are worth mentioning. First, grid computing is much more than just the application of large numbers of millions of instructions per second (MIPS) to effect a computing solution to a complex problem. It enables you to divide resources into multiple execution environments by applying one or more concepts, such as hardware or software partitioning, or time-sharing, machine simulation, emulation and quality of service. This virtualization, or on demand deployment, of all your distributed computing resources lets you use them wherever and however they are needed within the grid. Virtualization is simply a form of resource management for devices, storage, applications, services or data objects. Hence, applying SOA allows you to maximize resource utilization in a grid environment. You can deploy and migrate a services ecosystem onto appropriate nodes in a grid environment to respond efficiently to changes in your internal and external business environment.
 On demand computing
An in-depth discussion of on demand computing is also beyond the scope of this paper. But, again, SOA can be an essential prerequisite for on demand computing. SOA is an enabling architecture for on demand applications. Thus, applications must operate in an SOA to realize the benefits of on demand. Web service is an enabling technology for SOA. As a subset of on demand computing, Web services on demand is simply business services exposed using Web services standards.
On demand computing can cover a wide spectrum. One end of this spectrum focuses on the application environment; the other end focuses on the operating environment, which includes items like infrastructure and autonomic computing. Transforming your business means leveraging both the application and operating environments to create an on demand business. At the heart of your on demand business will be business services on demand where application-level services can be discovered, reconfigured, assembled and delivered on demand, with just-in-time integration capabilities.
The promise of Web services as an enabling technology is that it will enhance business value by providing capabilities such as services on demand, and over time, will transform the way IT organizations develop software. It could even transform the way business is conducted and the way you offer your products and services over the Web to your entire value chain. What if all of your applications shared the same transport protocol? What if they all under¬stood the same interface? What if they could participate in, and understood, the same transaction model? What if this were true of your partners? Then you would have applications and an infrastructure to support an ever-changing business landscape—and you would have become an on demand business. Web Services and SOA can make this possible for applications.
4 What are the major differences and similarity between these two approaches?
The increased speed and scale of IT-enabled processes has been met with a proportional increase in the demand to modify processes to meet changing conditions. IT has accelerated the speed at which citizens, businesses, and organizations both operate and change.
The major difference between Component-Based Engineering and Service-Oriented Engineering is different architecture, for different needs of customers, the fundamental shift that will allow these visions to be realized is a move to Service Component-Based Architecture (SCBA). Today, the IT industry has generally accepted Service Oriented Architecture (SOA) as the most promising architectural approach to-date. SCBA complements traditional SOA approaches and is designed to provide an optimal, long-term service-oriented approach aligned with the FEA that recognizes the value of component-based service delivery. SCBA builds upon SOA in three key ways:
• it is tightly integrated with the Federal Enterprise Architecture,
• it provides a description of what the architecture is (a collection of services designed and implemented to achieve an organization’s mission)
• It identifies the organizational, cultural, and process elements, as well as technological elements, that need to exist for these architectures to be successful.
SCBA also treats business processes and the IT systems in the same way, allowing both to be reused across organizations. In order for a business process or technical system to be a “Service Component,” and thus participate in the overall architecture, it must offer a well-defined interface with well-defined functionality. These two characteristics represent the minimum criteria needed for a business process or technical system to be reused. Service Components are intended be a subset of the “components” defined in the FEA SRM. The SRM does not require rigorous interface or functionality descriptions, only systems and processes with these descriptions are both SRM Components and SCBA Service Components. SCBA attempts to realize the potential of the SRM by requiring that business processes and IT systems be designed or modified to make them easy to reuse. Later sections of this document will describe SCBA in further detail.
In the mid-90s, an additional development emerged: component based development (CBD). CBD takes the concept of abstraction in a new direction. Rather than reducing lines of code, CBD separates various aspects of the functionality into isolated units that can be produced and managed independently of the other aspects. This again allows a developer or consumer of the functionality to deal with one aspect at a time – ignoring the other aspects. In a component-based architecture the various aspects are organized into layers, most commonly: presentation, orchestration, business logic, data management, security, and infrastructure.
Service-oriented architecture represents a generalization of the component model by dealing directly with what is offered, rather than how it is packaged. The tiered architecture enables components to be easily incorporated in solution architectures. The evolution of services standards (e.g., WSDL, UDDI, and SOAP) and the maturity of distributed computing architectures (e.g., Java Enterprise Edition and .Net) have enabled "single-copy reuse" via shared services. Thus, SOA is a tiered framework that empowers solution developers to employ abstraction techniques, at all architectural tiers, without having to struggle with many of the interoperability and multiple implementation challenges faced by previous generations of reuse proponents. The future of software development will likely consist of complete assembly of applications from services and components – often referred to as “true software manufacturing.”
Figure 4 Evolution of Reuse in Software Development
Software components are units of software that provide business or technical functionality. These units are independently deployable; that is, they are self-contained and can be deployed virtually anywhere on the network. Business components execute business logic, enforce business rules, and manage corporate data. Technical components provide the platform or infrastructure capabilities that the business components rely on such as messaging, error handling, security, etc.
 Components
Software components are the reusable building blocks for application development. A software component typically consists of: (1) a specification (process and data model representing the user or consumer’s view) that defines what the component does, (2) an implementation which is the internal design for the component, (3) an executable (run-time) module that gets deployed, (4) one or more interfaces that provide access to the component’s functionality. The key concept behind components is that the implementation is hidden behind the interface – the consumer of the component does not need to know the details of the implementation to exploit the capabilities offered. Thus, in general components are an approach to provisioning capabilities that are highly flexible. Component-based reuse is illustrated in Figure 5.

Figure 5 Illustration of Component-Based Reuse
 Services
Services are focused on satisfying business or technical requirements based on a provider/consumer model. Services represent a broader concept than components. They are the activities executed in response to a request (or an event) in order to deliver some result. Both concepts employ the notion of an interface that defines the set of activities (or services) offered. However, whereas all components offer functionality as services, not all services are implemented as components. Figure illustrates the distinction between services and components – services are driven from business requirements, whereas components are a method of providing services. For example, one way to implement a service is to put an interface on some legacy functionality. The legacy system may be very unstructured (and not divided into independent components), yet the interface may offer the services required by other and new applications. As discussed in the roadmap section below, creating interfaces to access services from legacy systems is one common way to begin to implement an SOA.

Figure 6 Differences between Services and Components
Services and components enable reuse, although with slightly different twists. Components are typically designed to be redeployed or integrated into multiple different applications. In fact, commercial-off-the-shelf (COTS) components are typically licensed to be embedded in applications. Reuse is achieved by producing multiple instances of the component and building them into applications. Services can be exploited in this way, but also offer the possibility of shared-services – running a single instance of a service that can be called by other applications across the network, as shown in figure 6.
An important additional concept is service discovery, or the ability to find (either manually at design-time or automatically at run-time) and access existing services. Many technologies exist today that enable this, and a coordinated strategy for identifying and categorizing services across the enterprise is critical. In the Federal government, the FEA provides the first step in implementing this strategy. Since services may be thought of as an abstraction of components, it is not too difficult to consider them both when describing reusable government-wide assets.


Figure 7 Illustration of Service-Based Reuse
A summary of the key concepts in CBSE and SOSE is listed in Table 1.
Table 1 Comparison of key concepts in CBSE and SOSE Concepts CBSE SOSE
Concepts CBSE SOSE
Module Component Service
Specification Component Contract Service description
Interface Component interface Service interface
Assembly Component
composition Service
composition
 Module.
In CBSE, components are the building blocks that can be deployed independently and are subject to composition by third party [10]. Based on the formulation by Clemens Szyperski [7], a software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. It can be both fine-grained providing specific functionality and coarse-grained encompassing complicated logics.
In SOSE, services are the building blocks that can be reused and offer particular functionalities. They are generally implemented as coarse-grained discoverable software entities [6], operating on larger data sets, encapsulating business functionality and exposing the functionality to any source that requests the functionality through well-defined interfaces. Thus, the services can be reused and accessed at various levels of the enterprise application and even across enterprises boundaries.
 Specification.
In CBSE, the component specification provides for the clients the definition of the component’s interface, i.e. the operations and context dependencies. Furthermore, an abstract definition of the component’s internal structure is specified for the component providers [10].
In SOSE, the service description is a service contract that advertises the following information: (i)service capabilities - stating the conceptual purpose and expected results of the service; (ii) interface - describing the service signatures of a set of operations that are available to the service requester for invocation; (iii) behavior - describing the expected behavior of a service during its execution; and (iv) quality - describing important functional and nonfunctional service quality attributes [9].
 Interface.
Although both CBSE and SOSE are interface-based in the sense that interfaces are the specifications of access points, the separation between service descriptions and service implementation is more explicit than the separation between component specification and implementation.
 Assembly.
In CBSE, component composition is the process of assembling components using connectors or glue code to form an assembly, a larger component or an application. The components are assembled through the component interfaces and the composition is made out of several component instances that are connected and interact together.
In SOSE, the composite services are built by composing service descriptions. The realization of the service composition is during run time when the service providers are discovered and bound.

Table 1 Summary of similarities and differences of CBSE and SOSE
CBSE SOSE
Process Building system from preexisting components.
Separate development process
of components and system.
More activities involved in design time Building systems from pre-existing services.
Separate development process of services and system. More activities involved in run time
Technology Constrained by component models. Ranging from white box, gray box to black box. Static and dynamic binding between components. Dynamic discoverability is not a major concern Platform independency. Black box. Only dynamic binding between services. Dynamic discoverability
Quality Interoperability concern between heterogeneous components. Achieve component substitutability through explicit specifications. Better predictability Interoperability through universally accepted standards. Achieve service substitutability through service descriptions.
Predictability issue
Composition Homogenous composition. Design time and run time composition and design time composition allows for optimization. Pipe and filter; event mechanism etc. Composition is made out of several component instances Heterogeneous composition. Services are composed at run time.
Pipe and filter; orchestration etc.
Composite services are built by composing service descriptions
5 What are the differences between service components and modern components?
5.1 What is service?
The OASIS SOA Reference Model states [14]:
The noun "service" is defined in dictionaries as "The performance of work (a function) by one for another."
This can mean everything or nothing. As with the term SOA, it is hard to find an exact, useful definition of the term "service" because so many definitions exist. Again, I have collected some of these definitions. You'll find some common phrases and attributes as you read them, but you will also find a lot of differences in the context, level of abstraction, and wording.
 SOA is focused on business processes. These processes are performed in different steps (also called activities or tasks) on different systems. The primary goal of a service is to represent a "natural" step of business functionality. That is, according to the domain for which it's provided, a service should represent a self-contained functionality that corresponds to a real-world business activity. In other words, business people should be able to understand what a service does [6].
 Services exist as physically independent software programs with distinct design characteristics that support the attainment of the strategic goals associated with service-oriented computing. Each service is assigned its own distinct functional context and is comprised of a set of capabilities related to this context [10].
5.2 What is modern component?
Let us review some of the important definitions of software components given by the experts. One of the earliest definitions is given by Gready Booch [15]:
A reusable software component is a logically cohesive, loosely coupled module that denotes a single abstraction.
This definition captures the idea that a reusable component is an encapsulated software module consisting of closely related component elements. Later, Clement Szyperski presented his well-known definition of a software component at the 1996 European Conference on Object-Oriented Programming [16]:
A software component is a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties.
This definition is well accepted in the component-based software engineering community because it highlights the major properties of software components that are not addressed in traditional software modules, such as context independence, composition, deployment, and contracted interfaces. In 2000, a broader, more general notion of software components was defined by Alan W. Brown [17]:
An independently deliverable piece of functionality providing access to its services through interfaces.
A similar idea is also expressed in the unified modeling language (UML) definition [18]:
A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.
Recently, Bill Councill and George T. Heineman gave a new definition to emphasize the importance of a consistent component model and its composition standard in building components and component-based software [19]:
A software component is a software element that confirms to a component model and can be independently deployed and composed without modification according to a composition standard.
To simplify the concept of software components, we classify the notion of software components into three types: (1) reusable modules, (2) reusable components, and (3) composite building blocks [20].
 A reusable module is an independent and deliverable software part that encapsulates a functional specification and implementation for reuse by a third party.
 A reusable component is an independent, deployable, and replaceable software unit that is reusable by a third party based on the unit’s specification, implementation, and well-defined contracted interfaces.
 A composite building block is a reusable component that is developed as a building part to conform a well-defined component model and the accompanying composition standards.
The differences between service components in SOA and modern components in CBSE.
 Comparison in properties[16], [6], [20].
Table 2 Comparison in properties
Properties Software Components in CBSE Services in SOA
Encapsulation: Each component encapsulates a set of closely related data elements and implements coherent functional logic to perform a specific task. Services are abstractions that hide implementation details from the consumers.
Stateless Sometimes, the components are stateful, sometimes are stateless. Sometimes, services are defined as being (ideally) stateless.
Reusable Reusability of software components is the key to the success of component-based software engineering. SOA leads to better reusability because all systems that need a certain functionality just call the same one.
Composable Components are composite if they are developed based on a standard composition method to support component composition. Kinds of business functionality can be broken into smaller steps, which are themselves services.
Vendor-Diverse Hard to reach Vendor- Diversification. Because there maybe some different frameworks or languages among components which are hard to be cohesive systems are usually very heterogeneous. Being able to use different platforms and different products for implementing services.
Interoperable Components are interoperable if they are developed based on standard communication channels and data exchange mechanisms defined in a component model. High interoperability is a core requirement of SOA. In the sense that services can be called from any other systems, they are inherently interoperable.
Independency Software components must be delivered as independent parts that can be replaced under certain conditions. The goal is to minimize dependencies so that a SOA is appropriate for distributed systems with different owners.
Contract-based interfaces An interface between software components defines a contract between the client of an interface and a provider of an implementation for the interface. Communication among services components is based on service contract which is implemented by Web service at the most time.
Deployable Software components are known as deployable if a well defined
deployment approach has been built inside a component to support its deployment Service components are deployable if service contracts among them are well developed to support them for working together.
From the comparison in properties we could infer that:
i. There are some excellent properties the two shard, they are: Encapsulation Composable, Reusable, Interoperable, Independency, Contract-based interfaces and Deployable.
ii. Obviously there are some differences between them including: Status, Vendor-Diverse.
 Comparison in different perspectives
Table 3 Comparison in different perspectives
Perspectives Software Components in CBSE Services in SOA
Base units of system Component-based system consists of composite components. System based on SOA is comprised of composite services.
Component design Component selection, creating, evaluation and testing. Service connection, creation, evaluation and testing.
Contract design Function implementation à Interface connection. Interface design à Function implementation.
Implemented by Various programming languages, frameworks and technologies or something like that is permitted. Mainly Web Service and related technologies.
Development process A dedicated component engineering process is in place to control and manage the construction of components. A service-oriented development process is used to control and manage module development.
Reuse scopes Large reuse scopes encompassing different projects, product lines, organizations or even the programming endeavors of the general public. Reuse of almost every service in the system and the scope of services could be extended by plug-in other services following the same standards.
From the comparison in different perspectives we could infer that:
i. These two design paradigms are all based on reusable, independent, interoperable component. One is software component, the other the service.
ii. Connections among the components are contracts. However the design processes is different, or we could say they are inverse.
iii. They have large scale of reuse and reach a high level of flexibility and interoperability.
iv. Different components are implemented by various technologies.
6 Building SOA-based software system is same as building a component-based system using service components?
I think there are no large differences of the lifecycles between them. We can assume that the service is definitely a unit in the system, like a component, too. Therefore, actually, we are able to adopt the lifecycle processing of component based system which will work effectively in service-oriented system too. There are some effective lifecycle models of component-based system, such as, V development process, Y development process and component-based waterfall development process. Obviously they are suitable for SOA-based software system design. The only potential variations between them are the unit – one is the component, the other the service, and in detail, is the phase of integration of units.
The main emphasis is put on component selection and its integration into the system. This process can require additional efforts. First the selection process should ensure that appropriate components have been selected with respect to their functional and extra-functional properties. This requires verification of the component specification, or testing of some of the component’s properties that are important but not documented. Second, it is a well known fact [8] that even if isolated components function correct, an assembly of them may fail, due to invisible dependencies and relationships between them, such as shared data shared resources. This requires that components integrated in assemblies are tested before they are integrated into the system. At last, the combination of these assemblies must be testes again, since all combined assemblies of correct ones maybe incorrect although the assembly oneself are correct [7].
One of the main reasons is that Particular component model requires a particular architectural framework, and the application is supposed to use this framework. This directly has impact on architectural decisions. For example if the component model requires a client-server architecture style, it is obvious that the application will use that style and not another (for example pipe-filter) [12]. This will put limitations on the system design.
Things seem better in SOA based architecture. Because avoiding normal data transmission among components, we only need to transfer an XML info, which is carried by SOAP and Http, for them to communicate. The pattern of XML info complies a standardized principle. Therefore we are easier to control transmission among different services. In this way, consideration about frameworks like we should consider in the component-based system is not necessary in that no matter what inner framework it is, the output and input is always the standardized XML (Figure 8). Services could send and receive them easily.
However, all these are based on well developed service contracts. Before the information sent out by service, it has to be translated via specific service contract. Then all the information are definitely in a same, concrete and standardized pattern, which will certainly improve the overall effectiveness of the system, because of the time of transformation has been saved.

Figure 8 Role of Web service and service contracts and their relationship.
7 Tools and technologies for building service components
7.1 Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft
In computer programming, a Visual Basic Extension (commonly abbreviated VBX) or custom control was the component model used in Microsoft Visual Basic versions 1.0 to 3.0. It is still supported in the 16-bit version of version 4.0, but was made obsolete by OCXs. VBX has also been supported in some versions of Borland Delphi.
The VBX specification was created so that developers could extend Visual Basic. According to rumor, Bill Gates reviewed the first version of Visual Basic before release and told the development team that it must have an extensibility mechanism. Since at the time Visual Basic was an interpreted language with limited power compared to C, VBXs which were most often written in C or C++ provided the ability to create very powerful and efficient software which could easily be hooked up to form based user interfaces.
Visual Basic 4.0 added support for the newer OLE Controls or OCXs (which became ActiveX controls), implicitly deprecating VBX controls. OCXs are based on the Component Object Model.
Each version of Visual Basic has come with many controls. By incorporating VBX controls into Visual Basic, Microsoft spawned the first commercially viable market for reusable software components. Third parties have created a large market of custom controls for resale.
VBX components were called "custom controls" because the Microsoft development team envisioned them as visual "control" components like a toggle switch or button. Enterprising third party software component developers saw opportunities to use the VBX specification for non-visual components, such as components for creating ZIP files, manipulating low-level system settings and communicating with TCP/IP.
7.2 IBM Service Component Architecture Explorer Tool
A metadata explorer that presents information about the service component architecture (SCA) services available in a given WebSphere Enterprise Service Bus server or WebSphere Process Server.
SCA Explorer presents information about the SCA services available in a given WebSphere® Enterprise Service Bus (ESB) server or a WebSphere Process Server (WPS). This information includes details such as how to locate and invoke such services (for example, when developing a new application that intends to re-use existing services in the enterprise).
SCA Explorer presents a Web page with tree widgets that allow the user to select an SCA module and "drill down" to see the components inside, their available interfaces, the operations available on such interfaces, the structure of the input and output Service Data Objects (SDOs), and any exceptions that can be raised by such operations. SCA Explorer also displays information about the imports, exports, and references used by such services; binding information, such as EJB JNDI names (Enterprise Java Beans, Java Naming and Directory Interface), Web service ports and endpoints, resource adapters, Java Message Service (JMS) destinations, etc.; and information about the implementation of such services.
With SCA, metadata is expressed via the Service Component Definition Language (SCDL), and an SPI exists that allows one to query this SCDL information. SCA Explorer is a JSP (Java Server Pages)-based application that demonstrates the use of this SPI to obtain information about the available SCA services and display it via HTML. Also included is a command line J2SE version that prints the same information to System.out and a command line tool that uses Eclipse Modeling Framework (EMF) to generate an XML file containing such information. [5]
8 Discussions and justification comments
8.1 What is SOA? Can we buy it?
SOA is not a concrete architecture: it is something that leads to a concrete architecture. You might call it a style, paradigm, concept, perspective, philosophy, or representation. SOA establishes an architectural model that aims to enhance the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing [5]. Therefore, SOA is not a concrete tool or framework you can purchase. It is an approach, a way of thinking, a value system that leads to certain concrete decisions when designing concrete software architecture.
This aspect of SOA has a very important consequence: you can't buy SOA. There is no tool or recipe you can use to make everything work. While applying this paradigm to your concrete situation, you must make specific decisions that are appropriate for your circumstances [11].
8.2 What’s the base system of SOA?
Of course, flexibility is dealt with very differently on different layers and in different components. So, one important question is which kinds of software systems this paradigm is appropriate for. As it turns out, SOA copes well with many difficult-to-handle characteristics of large systems [1].
 Distributed Systems
As businesses grow, they become more and more complex, and more and more systems and companies become involved. There is constant integration and constant change. SOA is well suited to dealing with complex distributed systems. According to the OASIS SOA Reference Model (see [OasisSoaRM06]), it is a paradigm for "organizing and utilizing distributed capabilities."
SOA allows entities that need certain distributed capabilities to locate and make use of those capabilities. In other words, it facilitates interactions between service providers and service consumers, enabling the realization of business functionalities.
 Different Owners
The OASIS SOA Reference Model's definition of SOA continues by stating that those distributed capabilities "may be under the control of different ownership domains." This is a very important point that is often suppressed in SOA definitions. You won't find it in any of the other definitions quoted in this chapter, but it is the key for certain properties of SOA, and a major reason why SOA is not only a technical concept.
SOA includes practices and processes that are based on the fact that networks of distributed systems are not controlled by single owners. Different teams, different departments, or even different companies may manage different systems. Thus, different platforms, schedules, priorities, budgets, and so on must be taken into account. This concept is the key to understanding SOA and large distributed systems in general.
 Heterogeneity
Another very important difference between small and large systems is the lack of harmony. We all know this from experience (although we might not agree about whether it's a natural phenomenon or the result of bad design). Large systems use different platforms, different programming languages (and programming paradigms), and even different middleware. They are a mess of mainframes, SAP hosts, databases, J2EE applications, small rule engines, and so on. In other words, they are heterogeneous.
In the past, a lot of approaches have been proposed to solve the problem of integrating distributed systems by eliminating heterogeneity: "Let's harmonize, and all our problems will be gone," "Let's replace all systems with J2EE applications," "Let's use CORBA everywhere," Let's use MQ series," and so on. But we all know that these approaches don't work. Large distributed systems with different owners are heterogeneous. This is a fact, and therefore something we must accept when designing large distributed solutions.
8.3 How to design service contract?
It is worth singling out Decoupled Contract at this stage because a Web service contract is essentially an implementation of this pattern. When building services as Web service. Service contracts are positioned as physically separate parts of the service architecture (Figure 9). This allows us to fully leverage the technologies to design and develop these contracts independently from the logic and implementations they will eventually represent.

Figure 9 The Web service contract is a physically separated part of a Web service implementation.
To design and develop service contracts is a huge project. So let’s introduce it briefly.
A service contract needs to have the following components [13]:
• Header
o Name - Name of the service. Should indicate in general terms what it does, but not be the only definition
o Version - The version of this service contract
o Owner - The person/team in charge of the service
o RACI
 Responsible - The role/person/team responsible for the deliverables of this contract/service. All versions of the contract
 Accountable - Ultimate Decision Maker in terms of this contract/service
 Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision.
 Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.
o Type - This is the type of the service to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include:
 Presentation
 Process
 Business
 Data
 Integration
• Functional
o Functional Requirement (from Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished.
o Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides.
o Invocation - Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for internal and external clients each with a different invocation means and interface. Examples:
 SOAP
 REST
 Events Triggers
• Non-Functional
o Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke.
o Quality of Service - Determines the allowable failure rate
o Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that?
o Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions
o Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service
o Process - Describes the process, if any, of the contracted service
One of the most challenging questions for component based software engineering is that, has CBSE really been out-fashioned? This could be separated into several sections :
Could SOA solve all the disadvantages of CBSE?
If so, is the cost acceptable?
Are those disadvantages really defective enough to have the users changing the system into new one with SOA?
9 A summary, conclusions, and future directions
For components to be independently deployable, their granularity and mutual dependencies have to be carefully controlled from the outset. For large systems, it becomes clear that components are a major step forward from objects (classes). This is not to say that objects are to be avoided. On the contrary, object technology, if harnessed carefully, is probably one of the best ways to realize component technology. In particular, the modeling advantages of object technology are certainly of value when constructing a component. On the flip side, modeling of component-based systems is still a largely unsolved problem, although there have been some recent inroads (for example, D’Souza and Wills, 1999, and Cheeseman and Daniels, 2000). UML, for instance, is still ill equipped to model component-based designs, though improvements in this area are one of the major goals for the UML 2.0 definition (still in its early phases in early 2002). Under the constant pressure of Moore’s law, the world of software has been expanding to take advantage of exponentially more powerful hardware resources. The resulting solutions reach into ever more areas of business and society, leading to new requirements, new markets, and new overall dynamics at a rapid pace. Software technology responded with a very dynamic evolution. However, components are hard to establish in a world of extreme dynamics. While much in the world of software needs to continue to progress rapidly, certain aspects need to evolve more gradually at a more controlled pace. These include the foundations of software components, including component models and basic technologies. The significant market advantage that can be gained from having third-party component backing for any platform creates the necessary feedback loop. To grow and sustain any such third-party communities, the major drivers of software technology, such as Sun and Microsoft, need to maneuver carefully. Players focusing on supplying components can only be viable if investments can be amortized (and profits drawn) before the rules change again.














Reference
[1] http://www.itworld.com/soa/60169/soa-gets-obituary
[2] C. Szyperski, Component Software. Addison-Wesley Professional, November 2002.
[3] Wikipedia, Service-oriented architecture, http://en.wikipedia.org/wiki/Main_Page.
[4] Ivica Crnkovic1, Stig Larsson2, Michel Chaudron, Component-based Development Process and Component Lifecycle, Information Technology Interfaces, 2005. 27th International Conference on June 20-23, 2005.
[5] CBSE: a Quantitative Approach Miguel Goulão Departamento de Informática – FCT/UNL 2825-114 Monte de Caparica, Portugal
[6]. Nicolai Josuttis, SOA in practise, 1st edition, O’Reilly media, Inc. Aug, 2007, ISBN: 978-0-596-52955-0
[7]. Newcomer, Eric; Lomow, Greg (2005). Understanding SOA with Web Services. Addison Wesley. ISBN 0-321-18086-0.
[8]. Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. pp. 3. ISBN 978-0-470-14111-3.
[9]. Erl, Thomas (2005). Service-oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-185858-0.
[10]. Erl, Thomas, SOA: Principles of Service Design, Prentice Hall, 2007, ISBN: 978-0-13-234482-1
[11]. Kishore Channabasavaiah, Kerrie Holley, Edward M. Tuggle, Jr., Migrating to a service-oriented architecture, IBM CorporationSoftware Group, 2007
[12]. Ivica Crnkovic, Michel Chaudron, Stig Larsson, Component-based Development Process and Component Lifecycle, Software Engineering Advances, International Conference on Oct. 2006
[13] Kurt Wallnau, “Dispelling the Myth of Component Evaluation” in Ivica Crnkovic and Magnus Larsson (editors), “Building Reliable Component - Based Software Systems”, Artech House Publisher, 2002.
[14]. http://www.eu-orchestra.org/TUs/SOA/en/html/Unit4_learningObject1.html, OASIS Definition of SOA, 2007, Orchestar.
[15]. Booch, G., Software Components with Ada: Structures, Tools, and Subsystems, 3rd ed.,
Reading, MA: Addison-Wesley, 1993.
[16]. Szyperski, C., Component Software—Beyond Object-Oriented Programming, Reading,
MA: Addison-Wesley, 1999.
[17]. Brown, A. W., Large-Scale, Component-Based Development, Englewood Cliffs, NJ:
Prentice Hall, 2000.
[18]. OMG Unified Modeling Language Specification, Version 1.4, Object
Management Group, 2000.
[19]. Heineman, G. T., and W. T. Councill, (eds.), Component-Based Software
Engineering: Putting the Pieces Together, Reading, MA: Addison-Wesley, 2001.
[20]. Jerry Zeyu Gao, H.-S. Jacob Tsao, Ye Wu, Testing and Quality Assurance for
Component-Based Software, ARTECH HOUSE, INC., 2003, ISBN 1-58053-480-5

Social-networking sites share breaking newsStory Highlights

Social-networking sites share breaking newsStory Highlights
More people are turning to social networking sites for breaking news

Sites like Twitter, Facebook and Flickr provide firsthand accounts of disasters

Users enjoy the speed and immediate access of those posting

Professor: Citizen journalism sometimes happens accidentally





By Lisa Respers France
CNN

(CNN) -- Janis Krums was heading to New Jersey on a ferry when he clicked a snapshot with his iPhone of US Airways Flight 1549 partially submerged in the Hudson River. He uploaded the picture to his Twitter account and then forgot about it as he assisted in the rescue of the plane's passengers.


iReporter Julie Pukelis used a camera and a telescope to get this view of the scene in Hudson River.

The deluge of image views crashed the servers of TwitPic, the application that allows Twitter users to send photos with their Twitter updates or "tweets."

"I posted it because I thought 'That's pretty newsworthy' and I wanted to share it with the people who follow me on Twitter," Krums said. "I was letting some of the survivors use my phone and it wasn't until later that I looked and saw that I had quite a few messages."

More people are turning to social networking sites like Twitter, Facebook and Flickr when news breaks to share stories and pictures.

In an era when even the president of the United States has a Facebook page and spectators texted and tweeted about Inauguration Day, the power of online and digital social networking is clear.

Barack Obama tapped into the stream for his grass-roots presidential campaign and the Israeli Consulate in New York used its Twitter account to disseminate information during the recent Israeli-Palestinian conflict in Gaza.


Twitter doesn't release figures on the total number of registered users, but according to Compete, which offers analytics on Web sites, the site had more than 4.4 million unique visitors as of December 2008. Facebook has more than 150 million active users and Flickr has more than 34 million registered users worldwide.

Accounts of the deadly attacks last fall in Mumbai, India, the May 2008 earthquake in China and last week's plane crash show what used to be just a virtual gathering place to communicate pet peeves or plans for the weekend has evolved into a go-to spot for eyewitness news -- sometimes even before mainstream media has had time to crack the story.

Twitter co-founder Biz Stone said Twitter users were the first to alert others last summer after an earthquake hit Southern California. "The earthquake struck at 11:42 [a.m.] PST and at 11:42 PST people started twittering," he said.

Twitter allows its users to post messages, or tweets, to their accounts that are then distributed to those who are "following" that user online. Stone noted that there was an Associated Press story on the quake that he saw posted nine minutes later on their site and said that during those nine minutes there were more than 3,600 tweets.

"That's when it sort of struck home for me," he said. "With Twitter, we have this real-time feed of what people around the world are seeing, thinking and feeling."

Such citizen journalism is in some cases happening almost accidentally, said Susan Jacobson, an assistant professor at Temple University in Philadelphia, Pennsylvania, who researches the impact of technology on journalism.

"Most people are just sending this information off to their friends," Jacobson said. "The main thing to take from sites like Twitter and Facebook is that they are informal modes of news dissemination."

Part of that informality includes brevity -- tweets have a maximum capacity of 140 characters, and Facebook statuses can only be a few lines -- and the possibility of inaccurate information. Jacobson said users, especially those who have grown up in the digital age, are very much aware of that.

"Young people, I think, have an innate radar about what is legitimate and what is not," she said. "They realize that not everything they read and see on the Web is true."

Stephen Hultquist, a Boulder, Colorado, consultant who gets a great deal of his breaking news from Twitter, said traditional media sources also make mistakes or give skewed reports.

"If anything, Twitter reminds me that everyone is human and they all have their own views and a paradigm through which they see the world," said Hultquist who had a unique appreciation of the quick, firsthand tweets that came after the earthquake in China last year.

"I was five miles from the epicenter of the earthquake in 1989 that happened right before a World Series game and I noticed that the media that was reporting on it wasn't getting it all right," he said.

Immediacy, said iReporter Jim Davidson, is one reason he posted his images of the downed plane in the Hudson on Flickr in addition to CNN.com. "When something like this happens, it's an easy way to syndicate it," said Davidson, who lives two blocks from the Hudson in Hoboken, New Jersey.

Social networking sites also enable spry reactions to news. Rob Reale of New York City started a Facebook group soon after the crash for the "Fans of Sully Sullenberger -- and the crew of Flight 1549" to celebrate the pilot who is being hailed as a hero for deftly landing the plane. The group quickly swelled to more than 27,000 members, some of whom posted video and photos and provided information that Reale used to update the page.

"I felt like the Facebook group was an opportunity to spread the good news," Reale said of the crash, which all survived. "Part of it was getting the word out and part of it was keeping that good feeling going."

Chris Krewson, executive online editor for the Philadelphia Inquirer, has a personal Twitter account in addition to posting tweets for his paper. Mainstream media is learning to better utilize online social networking to connect with its audience, he said.

"People are already talking about the news," Krewson added. "This is just a way for us to involve ourselves in the conversation

巴萨遍世界

http://www.sport.es/planetabarsa.asp

里面的源代码用的GOOGLE MAP API，今后相关东西可以借鉴。
PS：严厉谴责起变量名还用西班牙语的行为。

SOA全攻略（转）

原帖：http://soft.chinabyte.com/246/7571246.shtml


面向服务的体系结构(Service-Oriented Architecture，SOA)是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。 　　面向服务的体系结构(Service-Oriented Architecture，SOA)是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

　　这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

　　对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需(On demand)业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

　　虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构(Common Object Request Broker Architecture，CORBA)，它已经出现很长时间了，其定义的概念与 SOA 相似。

　　然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言(eXtensible Markup Language，XML)为基础的。通过使用基于 XML 的语言(称为 Web 服务描述语言(Web Services Definition Language，WSDL))来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言(Interface Definition Language，IDL)可比了。

　　Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件(Message-Oriented Middleware)系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。

　　此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。

　　最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。

　　我可以用面向服务的体系结构做什么?

　　对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。

　　下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。

　　另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店(store-in-store)的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。

　　为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。

　　垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。

　　正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言(Universal Modeling Language，UML)，并且描述成模型驱动的体系结构(Model-Driven Architecture，MDA)。

　　对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑(business logic)或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用。NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。

　　SOA有以下特性

　　SOA服务具有平台独立的自我描述XML文档。Web服务描述语言(WSDL， Web Services Description Language)是用于描述服务的标准语言。

　　SOA 服务用消息进行通信，该消息通常使用XML Schema来定义(也叫做XSD， XML Schema Definition)。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。

　　在一个企业内部，SOA服务通过一个扮演目录列表(directory listing)角色的登记处(Registry)来进行维护。应用程序在登记处(Registry)寻找并调用某项服务。统一描述，定义和集成(UDDI， Universal Description， Definition， and Integration)是服务登记的标准。

　　每项SOA服务都有一个与之相关的服务品质(QoS， quality of service)。QoS的一些关键元素有安全需求(例如认证和授权)，可靠通信(译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。)，以及谁能调用服务的策略。

　为什么选择SOA?

　　不同种类的操作系统，应用软件，系统软件和应用基础结构(application infrastructure)相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程(business processes)，因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构(application infrastructure)的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务(organic business)的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。

　　如图1的例子所示，一个使用SOA的企业，可以使用一组现有的应用来创建一个供应链复合应用(supply chain composite application)，这些现有的应用通过标准接口来提供功能。

　　服务架构

　　为了实现SOA，企业需要一个服务架构，图2显示了一个例子：

　　在图2中， 服务消费者(service consumer)可以通过发送消息来调用服务。这些消息由一个服务总线(service bus)转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎(business rules engine)，该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础(service management infrastructure)，用来管理服务，类似审核，列表(billing)，日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求(regulatory requirement)，例如Sarbanes Oxley(SOX)，并且可以在不影响其他服务的情况下更改某项服务。

　　SOA基础结构

　　要运行，管理SOA应用程序，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标准，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。

　　SOAP， WSDL， UDDI

　　WSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务;UDDI用来注册和查找服务;而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表(registry)查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。

　　WS-I Basic Profile

　　WS-I Basic Profile，由Web服务互用性组织(Web Services Interoperability Organization)提供，是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。

　　J2EE 和 .Net

　　尽管J2EE和。NET平台是开发SOA应用程序常用的平台，但SOA不仅限于此。像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。新的规范，例如 JAXB(Java API for XML Binding)，用于将XML文档定位到Java类;JAXR(Java API for XML Registry)用来规范对UDDI注册表(registry)的操作;XML-RPC(Java API for XML-based Remote Procedure Call)在J2EE1.4中用来调用远程服务，这使得开发和部署可移植于标准J2EE容器的Web服务变得容易，与此同时，实现了跨平台(如。NET)的服务互用。

　　服务品质

　　在企业中，关键任务系统(mission-critical system，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比如，电话系统对于一个电话促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。)用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始采用服务架构作为工具来进行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质(QoS，quality of services)。与QoS相关的众多规范已经由一些标准化组织(standards bodies)提出，像W3C(World Wide Web Consortium)和OASIS(the Organization for the Advancement of Structured Information Standards)。下面的部分将会讨论一些QoS服务和相关标准。

　　安全

　　Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换， 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，例如，SAML(as Security Assertion Markup Language)来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定。

　　可靠

　　在典型的SOA 环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”( once-and-only-once delivery)，“最多传送一次”( at-most-once delivery)，“重复消息过滤”(duplicate message elimination)，“保证消息传送”(guaranteed message delivery)等特性消息的发送和确认，在关键任务系统(mission-critical systems)中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准现在都由OASIS负责。

　　策略

　　服务提供者有时候会要求服务消费者与某种策略通信。比如，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。这些要求被定义为策略断言(policy assertions)。一项策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的策略通信。

　　控制

　　当企业着手于服务架构时，服务可以用来整合数据仓库(silos of data)，应用程序，以及组件。整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标准化。在SOA中，进程是使用一组离散的服务创建的。BPEL4WS 或者 WSBPEL(Web Service Business Process Execution Language)是用来控制这些服务的语言。WSBPEL目前也由OASIS负责。

　　管理

　　随着企业服务的增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。WSDM(Web Services for Distributed Management)规定了任何根据WSDM实现的服务都可以由一个WSDM适应(WSDM-compliant)的管理方案来管理。

　　其它的qos特性，比如合作方之间的沟通和通讯，多个服务之间的事务处理，都在WS-Coordination 和 WS-Transaction 标准中描述， 这些都是OASIS 的工作。

　　SOA 不是Web服务

　　在理解SOA和Web服务的关系上，经常发生混淆。根据2003年4月的Gartner报道，Yefim V. Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是Web服务和SOA的根本联系。”从本质上来说，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用Web服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的Web服务规范，你会取得更好的通用性。

　　SOA的优势

　　SOA的概念并非什么新东西，SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标准，为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创建应用;SOA能够使客户或服务消费者免予服务实现的改变所带来的影响;SOA能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。总而言之，SOA以借助现有的应用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。

Software usability testing

专业写作一篇，博客存档

关键词: software testing, usability testing, usability verification

RVL

----

SOFTWARE USABILITY TESTING

1. Introduction:

As the standard for modern software testing is more and more advanced, the requirements for all aspects of software testing, both horizontally and longitudinally, are also raising. That’s why we often say that the potential of software testing development is bonded with general software market. Every single aspect in software testing is important. In such a fierce competition environment, customers won’t consider much about the detail source of the bugs in your product, 2-3 serious bugs are enough for them to turn to other products and leave you alone, though your product may be perfect in other 99.9% aspects. Thus, what the software designers should do, is to avoid these negative effects before the product is released. “0% bugs” is impossible, of course, but “0% fatal bugs” is basically possible. Vulgarly speaking, after a company released their “version 1.0”, how could they convince their customers again and again by telling “our version 1.01 would have no bugs”, “our version 1.02 would have no bugs”… ?

If everything is done before version 1.0, that’s the deal. But the detail tasks of software testing are not so easy to describe. Among those systematically connected aspects, software testing engineers would follow the schedule to finish every part. But there is one part , which starts from the beginning, and finish in the very end, being done time by time. Besides, software engineers are only supporting roles in this part, the protagonists are the customers, which may even not know the difference between .net and java, or the concept of “exception”.

So that comes out Software Usability Testing. What‘s the meaning? What’s the object of this testing? How?... That’s what I would talk about in this article.

2. Basic Concepts of Software Usability testing

Software usability testing is a complex concept. In order to summarize it out, It is necessary to introduce the two basic component of this concept at first: Software Usability, Usability Testing.

In the wikipedia, the definition of usability is as following:

Usability is a qualitative attribute that assesses how easy user interfaces are to use. The word "usability" also refers to methods for improving ease-of-use during the design process.
-- Wikipedia: Usability

To deepen this concept to the software designing field, Usability could also be defined as “Usability measures the quality of a user's experience when interacting with a product or system—whether a Web site, a software application, mobile technology, or any user-operated device.[1]” . This definition is more accurate for the Usability in software field.

And what’s Usability Testing? Usability testing is a technique used to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practise, since it gives direct input on how real users use the system [2]. And according wikipedia, “this is in contrast with usability inspection methods where experts use different methods to evaluate a user interface without involving users. – Wikipedia : usability testing”

Combining these concepts and the general idea of software testing, I could define Software Usability Testing as : “A systematic series of testing activities to evaluate the product’s quality on user’s experiences during interaction with this product. ”


3. Software Usability

3.1 Definitions and assortment of software usability

So what’s the standard to judge if a software product has GOOD usability? Or not so good? Of course, Software Usability does contain several parameters to evaluate it. Two experts on usability research, Jakob Nielsen and Ben Shneiderman have both agreed that there are five attributes in usability in their books separately. Their view is also the most authoritative and is recorded in wikipedia:

Learnability: How easy is it for users to accomplish basic tasks the first time they encounter the design?

Efficiency: Once users have learned the design, how quickly can they perform tasks?

Memorability: When users return to the design after a period of not using it, how easily can they re establish proficiency?

Errors: How many errors do users make, how severe are these errors, and how easily can they recover from the errors?

Satisfaction: How pleasant is it to use the design?

Some other experts have different opinion, another popular assortment is “Easy to learn, Easy to use, Easy to satisfy” [3]. But if the topic is about testing, the characters of different attributes should be more clear in order to discuss. So this article will mainly based on the assortment of wikipedia.

3.2 Examples on software usability attribute

Back to the five attributes of software usability, as these concepts may seem too generalized, it would be easier to understand these concepts by several examples. Let’s suppose that a software company has been designing a product “soccer players stats analysis system (SPSAS)” for a soccer club “FC San Jose (FCSJ)”. So how to make the roles of these five attributes clear in this case?

Learnability: The users of SPSAS are the coaches and data analyzers of FCSJ. Maybe the data analyzers , who have professional computer backround, would be easy to handle this system on computers. But for those coaches, especially for the 62 years old head coach, Rex, who even have many difficulties on learning to send or receive emails, how could he deal with this system? Will it be easy to learn for Rex in his limited spare time?

Efficiency: Now let’s suppose that every necessary person in FCSJ has acquainted with this system. And during the pre-season training camp, the coaches need to acquire every player’s latest physical status as soon as possible, in order to work out the detail plan of pre-season training. So how could they analyze the data gathered from examinations and first trainings? And more important in this factor, how fast could they finish a well organized and systematic report on all players?

Memorability: And during the season, whenever the coaches want to use this system to evaluate a player’s recent performance, or working out a new short-term plan, they need to remember the basic functions and controls of this system, or at least easy to recollect.

Errors : During operating this system SPSAS, if there are bugs on analyzing players data, the coaches may have problem on fixing the problems and undo all works. To be even worse, if Rex selected a player with bad form according to the wrong data, and the player became a nightmare on the pitch, or injured. Afterwards if the coaches found out why, the software company will be in big trouble. So could this product avoid these bad situations?

Satisfaction : this seems to be more comprehensive than the four ones above. Will the FCSJ coaches want to use this system to help their work in the next season? Does Rex feel convenient? Are the results better than before? It’s very easy to summarize these questions : Are they satisfied with SPSAS?

3.3 Usability patterns and properties (arch-patterns)

As if we refer these software usability attributes during examination and further testing, it would be too vague and general. In fact, during practicing, there are still two levels below the usability attribute level: property level, and pattern level. Connecting with these two levels, the details of software usability would be shown to users, who are the main participant during software usability testing (which will be introduced later).

Usability properties are defined as the usability characteristics to be improved in a system. Usability properties can also be seen as the requirements of a software system for it to be usable (for example, provide feedback to the user, provide explicit user control, provide guidance to the user, etc). [4]

The second level was envisaged to identify specific mechanisms that might be incorporated into a software architecture to improve the usability of the final system. These mechanisms have been called usability patterns and they address some need specified by a usability property. Note that usability patterns do not provide any specific software solution to be incorporated into a software architecture, they just suggest some abstract mechanism that might be used to improve usability (for example, undos, alerts, command aggregations, wizards, etc.).[5]

As the table shows, the usability patterns are in charge for their parts of improving work in the application interface. And the relationships between these components and the property items are to provide solutions and mechanism to this software architecture. And during usability testing , these connections and functions would be more clear.

4. Software usability testing -- Goals

After introducing the knowledge structure of software usability, we can start the main topic of this paper : software usability Testing.

In the general assortment of software testing, software usability testing belongs to Quality assurance., as usability is one of the six important attributes of software quality. In the ISO 9126 standard, it provides six high-level quality attributes: functionality, reliability, efficiency, usability.[6]

4.1 Who are in charge for software usability testing (SUT)?

Basically, many experts consider users as the most effective testers on usability testing. Because whether the testing specialists have great level or not, whether their testing methods and technologies are advanced or not, they are not the ones who will use this product for long time. The most important factor in usability is user’s satisfaction. Thus, users should lead the SUT and do most of the work.

Is there any filter to these users? Of course. The company should select suited users to finish usability testing. They should be comprehensive, representative, and neutral with the company. The company should not cheat themselves with selecting users they “desire” to get a good result. If so, in the end the biggest loser would be the company itself, especially the testing department.

And besides users, testing specialists still should participate in SUT as important assistants. Users should do the testing under their planned direction in order to get the data they need. In some testing methods (such as monitor), testing specialists should stay with the users in the whole process. The details are on later chapters.

In order to filter the testers more effectively, the company should bring these questions while facing the testers.

n Are these testers able to complete the task scenarios successfully?
Keywords: basic ability, time.

n How fast would these testers finish each task?
Keywords: experience.

n How many clicks does it take to complete each task?
Keywords: testing plan.

n Do these testers perform well enough to meet the original objectives?
Keywords: evaluation

n How satisfied are the testers (users only) with the product?
Keywords: satisfaction

n What changes are needed to make the product to enable more users performing more successfully?
Keywords: improvement.



4.2 Objectives and Major focuses of software usability testing

In wikipedia, the “usability goals” defines these following objectives of usability testing :

“During usability testing, the aim is to observe people using the product to discover errors and areas of improvement. Usability testing generally involves measuring how well test subjects respond in four areas: efficiency, accuracy, recall, and emotional response. The results of the first test can be treated as a baseline or control measurement; all subsequent tests can then be compared to the baseline to indicate improvement.

Performance -- How much time, and how many steps, are required for people to complete basic tasks? (For example, find something to buy, create a new account, and order the item.)

Accuracy -- How many mistakes did people make? (And were they fatal or recoverable with the right information?)

Recall -- How much does the person remember afterwards or after periods of non-use?
Emotional response -- How does the person feel about the tasks completed? Is the person confident, stressed? Would the user recommend this system to a friend?”

And in software products, the usability testing is even more important than the ones in other fields. As software engineers need to use usability testing to find out the problems in their product and relative service as soon as possible, and if any phase of the product has usability problems, the whole product would be seriously affected.

During the software usability testing, all the testers, including the users who have been selected for SUT, and the leading testing engineers, will try to give out suggestions to improve the product in limited schedule and fund. This purpose is also the final objective for other testing phases in the whole design process.

For example, if the company is testing a web-based product (a web-based platform, or a commercial website, etc..)And during the process, testers would mainly focuses on following questions :
n Do testers click to pages or do they use search?
n What keywords do they use most when searching?
n Is the search textbox in a good location?
n Is the search textbox large enough for most of the words used?
n Do the search results provide leads to quick answers to the questions from users?
n If so, are these answers usually on the first page of results?
n Does the search do a good job of detecting and helping to resolve typing errors?
n Are the testers (users only) satisfied with the search engine in all?

4.3 When?

When will be fittest time to do the usability testing? The answer doesn’t contain any accurate time. The software usability testing is a process, starting in the very beginning of the design. As since started, designers need to collect suggestions from users to help them fix the goals and improve the design. During the whole designing process, this process is combined with the main process and executed time by time. Of course, it is still not the real process of software usability testing, but important foundation preparing for software usability testing. But generally, the process of collecting suggestions and opinions from users is the first phase in the SUT process.

Even a non-expert on software designing would know that designing a software product would be obviously related with the opinions of users. But they may don’t know the opinions are collected from different stages. If there are only suggestions around the end of designing, the product would definitely fail if they have been away from the users request since the beginning, as the relationship between the improvement the users could affect and the time used is inverse proportion.

So when should the testers do usability testing? To summarize it in one sentence: Test early; test often . Usability testing lets the design and development teams identify problems before they get "set in concrete." The earlier those problems are found and fixed, the less expensive the fixes are. As the project progresses, it becomes more and more difficult and expensive to make major design changes. The more you test and change based on what you learn, the more confident you can be that the site will meet your objectives and your users' needs when it is launched. [7]

5. Software usability verification methods

As it’s said in the above that survey (collecting suggestions from users) is important preparation for software usability testing, here comes a new question: what’s the real first step of software usability testing?

If we consider everything related with SUT as a whole process, the first phase is survey in the beginning (which will be executed also in next phases time by time), the second phase is verification, and the third phase is evaluation.

Now it’s time to introduce the basic knowledge of verification.

5.1 Concepts

After collecting results from the survey results analysis , requirements analysis, and brief evaluation of potential use-related hazard, the usability testers should develop usability specification which specifies the intended use and purpose of the product. The usability specification should be integrated into the design specification and provides a basis for the usability verification and validation. [8]

The usability verification checks the conformity of design results with the usability specifications. As soon as usability specification is finished, usability verification takes place, and provides an early usability evaluation. A lot of usability engineering techniques that involve experts or users could be applied for usability verification. Verification should be conducted with sufficient efforts in early design stages to avoid serious usability problems being brought up in later design stages.

Different levels of the design could be verified by using suitable usability engineering techniques. The conceptual ideas can be verified by checking descriptive material such as scribbles or drawings, task descriptions and interface mock-ups. Functional models and prototypes could be analyzed in a more profound and advanced method.

And about usability validation, it would take place in the final stage of the whole process, as it needs at least one functional prototype to use. The objective of usability validation is also to analyze if the design really fulfils the requirements of the specified applications. If sufficient usability verification efforts have been executed, the serious usability problems to be discovered by the final usability validation could be minor.[9]

Some methods consider verification as a part of testing methods, and define it as verification testing : a verification test is used to determine the overall usability of a product after implementation has taken place.

5.2 Criteria

As software usability verification is also a kind of verification activity, there is also a series of criteria for software usability. Both verification phases and evaluation phases will be authorized only if their usability testing is based on the criteria.

Now generally speaking, the most authorized criteria on usability is ISO 9241. The following passage is brief introduction of ISO 9241 on wikipedia.

“ISO 9241 is a multi-part standard covering a number of aspects for people working with computers. Although originally titled Ergonomic requirements for office work with visual display terminals (VDTs) it is being retitled to the more generic Ergonomics of Human System Interaction by ISO. As part of this change, ISO is renumbering the standard so that it can include many more topics. The first part to be renumbered was part 10 (now renumbered to part 110).

“Part 1 is a general introduction to the rest of the standard. Part 2 addresses task design for working with computer systems. Parts 3–9 deal with physical characteristics of computer equipment. Parts 110 and parts 11–19 deal with usability aspects of software, including Part 110 (a general set of usability heuristics for the design of different types of dialogue) and Part 11 (general guidance on the specification and measurement of usability).

“The 17 parts of the standard are:

Part 1: General introduction
Part 2: Guidance on task requirements
Part 3: Visual display requirements
Part 4: Keyboard requirements
Part 5: Workstation layout and postural requirements
Part 6: Guidance on the work environment
Part 7: Requirements for display with reflections
Part 8: Requirements for displayed colors
Part 9: Requirements for non-keyboard input devices
Part 10: Dialogue principles
Part 11: Guidance on usability
Part 12: Presentation of information
Part 13: User guidance
Part 14: Menu dialogues
Part 15: Command dialogues
Part 16: Direct manipulation dialogues
Part 17: Form filling dialogues ”


As it introduces, in ISO9241, from part 10 (now renamed to 110) to part 17 are the detail criteria of usability in ISO standard. Among them, part 110 and part 11 are the two most cited parts in the articles on usability. Part 110 deals with general ergonomic principles which apply to the design of dialogues between humans and information systems: suitability for the task, suitability for learning, suitability for individualization, conformity with user expectations, self descriptiveness, controllability, and error tolerance. And part 11 deals with detailed specifications on usability, including standards on effectiveness, efficiency and satisfaction. In the end of part 11, there are also some appendices on practical examples on background and usability testing, as well as differences with other criteria (such as ISO 9126, which also has a definition of usability)

Part 12- 17’s focuses are listed below: (from wikipedia)

ISO 9241-12

(1998) Presentation of information This part contains specific recommendations for presenting and representing information on visual displays. It includes guidance on ways of representing complex information using alphanumeric and graphical/symbolic codes, screen layout, and design as well as the use of windows.

ISO 9241-13

(1998) User guidance. This part provides recommendations for the design and evaluation of user guidance attributes of software user interfaces including Prompts, Feedback, Status, On-line Help and Error Management.

ISO 9241-14

(1997)Menu dialogues. This part provides recommendations for the ergonomic design of menus used in user-computer dialogues. The recommendations cover menu structure, navigation, option selection and execution, and menu presentation (by various techniques including windowing, panels, buttons, fields, etc.).

ISO 9241-15

(1998) Command language dialogues. This part provides recommendations for the ergonomic design of command languages used in user-computer dialogues. The recommendations cover command language structure and syntax, command representations, input and output considerations, and feedback and help.

ISO 9241-16

(1999) Direct manipulation dialogues. This part provides recommendations for the ergonomic design of direct manipulation dialogues, and includes the manipulation of objects, and the design of metaphors, objects and attributes. It covers those aspects of Graphical User Interfaces that are directly manipulated, and not covered by other parts of ISO 9241.

ISO 9241-17

(1998) Form-filling dialogues. This part provides recommendations for the ergonomic design of form filling dialogues. The recommendations cover form structure and output considerations, input considerations, and form navigation.

Actually design and process standards are different from these technical criteria. Technical standards tend to be written for a specific technology and to be very detailed in how to create a product that meets the standard. (such as ISO 9241-12 ~ 17).
" Process standards tell us how to work, which methods to use, and how to integrate with other processes. They describe methods and outline what should be done, in what order, to succeed in a project.

" Design standards set rules for good design. Corporate rules for the use of a logo are design standards, as are guidelines for use of color, layout, navigation or interaction.

Both are difficult to both write and enforce. Even when there is general agreement on a design principle, the diversity of industry practice and content has made it difficult to create strong standards to embody usability knowledge. Both have to find the line between vague principles and excessive detail. [10]


6. Software usability testing methods

6.1 Scope and definition

As the standard for usability verification is included in the criteria for the whole usability related activities, it is necessary to make clear the scope and basic definition for usability in this series of criteria. As there are many parts dealing with usability in ISO 9241, I choose part 11 as an example.


6.1.1 scope

ISO 9241-11 defines usability and explains how to identify the information which is necessary to take into account when specifying or evaluating usability of a visual display terminal in terms of measures of user performance and satisfaction. Guidance is given on how to describe the context of use of the product (hardware, software or service) and the relevant measures of usability in an explicit way. The guidance is given in the form of general principles and techniques, rather than in the form of requirements to use specific methods.

The guidance in ISO 9241-11 can be used in procurement, design, development, evaluation, and communication of information about usability .ISO 9241-11 includes guidance on how the usability of a product can be specified and evaluated. It applies both to products intended for general application and products being acquired for or being developed within a specific organization.

ISO 9241-11 also explains how measures of user performance and satisfaction can be used to measure how any component of a work system affects the whole work system in use.

The guidance includes procedures for measuring usability but does not detail all the activities to be undertaken. Specification of detailed user-based methods of measurement is beyond the scope of ISO 9241-11, but further information can be found in Annex B and the bibliography in Annex E.

ISO 9241-11 applies to office work with visual display terminals. It can also apply in other situations where a user is interacting with a product to achieve goals. ISO 9241 parts 12 to 17 provide conditional recommendations which are applicable in specific contexts of use. he guidance in this Part of ISO 9241 can be used in conjunction with ISO 9241 Parts 12 to 17 in order to help identify the applicability of individual recommendations.

ISO 9241-11 focuses on usability and does not provide comprehensive coverage of all objectives of ergonomic design referred to in ISO 6385. However, design for usability will contribute positively to ergonomic objectives, such as the reduction of possible adverse effects of use on human health, safety and performance.

ISO 9241-11 does not cover the processes of system development. Human-centered design processes for interactive systems are described in ISO 13407. [11]

6.1.2 Definitions

For the purposes of this part of ISO 9241, the following definitions apply:

Usability: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. NOTE- See Annex D for other approaches to usability.

Effectiveness: Accuracy and completeness with which users achieve specified goals.

Efficiency: Resources expended in relation to the accuracy and completeness with which users achieve goals.

Satisfaction: Freedom from discomfort, and positive attitudes towards the use of the product.

Context of use: Users, tasks, equipment (hardware, software and materials), and the physical and social environments in which a product is used.

Work system: System, consisting of users, equipment, tasks and a physical and social environment, for the purpose of achieving particular goals. ( The context of use consists of those components of the work system which are treated as given when specifying or measuring usability. )


User: Person who interacts with the product.

Goal: Intended outcome.

Task: Activities required to achieve a goal. ( These activities can be physical or cognitive. Job responsibilities can determine goals and tasks. )

Product: Part of the equipment (hardware, software and materials) for which usability is to be specified or evaluated.

Measure (noun): Value resulting from measurement and the process used to obtain that value. [12]

6.2 Methods and techniques

Usability testing can be performed with developers, HCI experts, or representative end users. Some authors distinguish between "testing," which they limit to empirical end-user oriented methods, and "evaluation," which utilizes HCI professionals' expertise.[13]

6.2.1 Peer to peer testing

In this kind of software usability testing, there are a tester (presider or his/her assistant) and a target user. The target user will finish a series of tasks accompanied with the tester. This process will be shot if the target user agrees. The tester will observe the target user continuously, in order to acquaint with the user’s operations , thoughts and relative parameters such as mistakes, time cost, clicks per task…The tester needs to follow these actions , record the problems the user have faced and analyze them.

6.2.2 Heuristics evaluation

Heuristic evaluation is a usability testing method to find the usability problems in user interface design, in order to mark these problems in next stages to get improved. This method requires more users, according to Nielson’s theory, five evaluators would be enough to find out 75% usability problems. This would be the ideal number of target users under the proportion of market value and remaining balance.

So generally, heuristics evaluation will have 5 users (at most 8 users) to help the testers evaluating the human-computer interaction, find out the problems and suggest improvement plans under the usability criteria.

6.2.3 focus groups

This method is basically considered as an assistant method for usability testing. 6 – 12 people, including experts on this field, designers and users, group together and have a creative and active meeting. Under the presider’s direction, the group will discuss on specific topic and motivate each other for useful thoughts. There should be also at lease one staff to record useful messages and generate a meeting report.

6.2.4 User models

User models method is to simulate the human – computer interaction process, which is considered as the key solutions to the problems. Human is supposed to have their purpose while using software system, and a large purpose could be separated into several small purposes. To finish one small purpose, users have many different choices on actions and methods to take. Thus, each small process could cost some time which could be calculated, and the sum of these time costs, is the model time total cost. Then tester could foresee the total time the user could cost.

This method is very useful for some special products which could not invite users to attend usability testing (such as dangerous product or highly precise products). The most famous model in human computer interaction field is GOMS (Goals, Operators, Methods, Selections).

GOMS reduces a user's interaction with a computer to its elementary actions (these actions can be physical, cognitive or perceptual). Using these elementary actions as a framework an interface can be studied. There are several different GOMS variations which allow for different aspects of an interface to be accurately studied and predicted.

For all of the variants, the definitions of the major concepts are the same. Goals are what the user intends to accomplish. Operators are actions that are performed to get to the goal. Methods are sequences of operators that accomplish a goal. There can be more than one method available to accomplish a single goal, if this is the case then selection rules are used to describe when a user would select a certain method over the others. Selection rules are often ignored in typical GOMS analyses. There is some flexibility for the designers/analysts definition of all of these entities. For instance, one person's operator may be another’s goal. The level of granularity is adjusted to capture what the particular evaluator is examining. [14]

6.2.5 Survey

In chapter 4, I introduced the basic concepts of survey and when to do it , how to do it. In this chapter I will focus on its methods. Survey includes paper surveys and conversation surveys.

6.2.6 Thinking Aloud Protocol

Think aloud protocol is a method used to gather data in usability testing in product design and development, in psychology and a range of social sciences. The think-aloud method was developed by Clayton Lewis while he was at IBM, and is explained in C. Lewis and J. Rieman, "Task-Centered User Interface Design: A Practical Introduction".[15] The purpose of this method is to make explicit what is implicitly present in subjects who are able to perform a specific task.


Think aloud protocol includes a series of specified tasks for participants. Among them, the users are asked to tell whatever they are thinking, doing, looking at, and feeling during their tasks. And the testers, who play the roles “observers” in this method, would be able to see the process of task completion as early as possible. The test sessions are often audio and video taped so that developers can review what the participants did and reacted. This method could be used in any stage of development. So it’s a cheap way to get a lot of good qualitative feedback during testing.


6.2.7 Co-Discovery Method


In Co-discovery method , there would be two participants who would attempt to perform tasks together under observation. Thus, it would be very useful for testers to observe their interaction, as they could bring out more insights than a single participant does.

During this performance, tester should provide the product and a scenario of tasks to perform to the two users under observation. They should be asked to perform the tasks using the product and explain what they are thinking about while working with different parts of the interface. The tester should direct the two users to help each other in the same manner and working together to accomplish a common goal.

This technique can be used during any phase of development. It is ideal for Computer-Supported Cooperative Work (CSCW) products, groupware, and other products designed to be used by workers in team environments.

6.2.8 Eye Tracking

Eye tracking is a complex usability testing technique which allows testers to identify what participants look at during the course of a usability test. It involves several kinds of equipments and different technologies. Some known technologies are marked contact lenses, image processing cameras, skin electrodes and reflector trackers.

The reflector trackers are most popular and useful in eye tracking technique. As it doesn’t require physical contact with the user’s eye , more users would be glad to accept to participate the test. It uses a beam of light to project onto the eye. a sophisticated camera picks up the difference between the pupil refection and known reference points to determine what the user is looking at.

But the eye tracking system equipment is too expensive to be popular in small companies, so a usability lab that purchased eye tracker would be helpful for those companies who cannot afford the maintenance.

Use this technique when you absolutely have to identify what a person looks at during a usability test. For most products, regular inspection or testing methods will identify enough usability problems to the point that eye tracking isn't necessary.

6.3 Other concepts

6.3.1 Usability latitudes

Usability latitudes refers to a set of parameters in usability testing, including following ones :

n Probability of success of task operation.
n Task operation efficiency
n Task operation expectation (user)
n User estimate after task operation
n User satisfaction
n Probability of failure in each task
n Probability of success of task operation after repeat operation again
[19]
6.3.2 Usability documents

Here is some documents that could be used in software usability testing.

n User screener
n Testing schedule
n User profile
n User concert form & DNA
n Testing script
n Pre-test questionnaire
n Post-test questionnaire
n Task cards
n Checklists
n Reports
n DVD
[20]

7. Software usability testing organizations
Basically, most of usability testing organizations are very famous for their software usability testing techniques and authority. Here are some brief introductions of these organizations.
Usability Net - http://www.usabilitynet.org/home.htm
Long history, many basic knowledge on the website, good for new usability testers. Need proxy in China mainland.
Usability News – http://www.usabilitynews.com/UsabilityNews offers a facility for the publication of news articles, jobs, events and calls for papers for users involved within the HCI and usability community. Frequently update.
HFES-Human Factors and Ergonomics Society - http://www.hfes.org/ A professional human-computer engineering organization locates on UK. The Society's mission is to promote the discovery and exchange of knowledge concerning the characteristics of human beings that are applicable to the design of systems and devices of all kinds.

The Society furthers serious consideration of knowledge about the assignment of appropriate functions for humans and machines, whether people serve as operators, maintainers, or users in the system. And, it advocates systematic use of such knowledge to achieve compatibility in the design of interactive systems of people, machines, and environments to ensure their effectiveness, safety, and ease of performance.

The Society was founded in 1957. It has 23 technical groups and numerous local and student chapters. See our history page for a discussion of the Society's growth and development.
ACM SIGCHI - http://www.acm.org/sigchi/
ACM SIGCHI, the ACM's Special Interest Group on Computer-Human Interaction, brings together people working on the design, evaluation, implementation, and study of interactive computing systems for human use. ACM SIGCHI provides an international, interdisciplinary forum for the exchange of ideas about the field of human-computer interaction (HCI).
Usability.gov http://usability.gov/
The website maintained by the health and human service department of USA. Also includes some expertise information on usability.
Usability.gov is the primary government source for information on usability and user-centered design. It provides guidance and tools on how to make Web sites and other communication systems more usable and useful. Topics include:
· a step-by-step guide on how to plan, analyze, design, and usability test a highly usable Web site;
· quick access to the latest usability methods;
· an introduction to usability, how to get started, and what it costs;
· the latest research-based Web design guidelines;
· templates and examples for assessing audience needs, writing a usability test report;
· and much more.


8.Applications

By now, commercial software for professional software usability testing have already been applied and established mature market. Here are some good commercial tools on software usability testing. (Introductions are from their advertisements)

ErgoLight Usability Software (ErgoLight Usability Software Ltd.)

Comprehensive GUI quality solutions ? for the professional Windows application developer. ErgoLight offers solutions for developers of Windows applications for testing and evaluating their usability

WebMetrics Tool Suite National Institute of Standards and Technology

Tool Suite contains rapid, remote, and automated tools to help in producing usable web sites. The Web Static Analyzer Tool (WebSAT) checks the html of a web page against numerous usability guidelines. The output from WebSAT consists of identification of potential usability problems, which should be investigated further through user testing. The Web Category Analysis Tool (WebCAT) lets the usability engineer quickly construct and conduct a simple category analysis across the web.

Bobby Center for Applied Special Technology

Bobby is a web-based public service offered by CAST that analyzes web pages for their accessibility to people with disabilities as well as their compatibility with various browsers.


DRUM Serco Usability Services

DRUM is a software tool, which has been developed by close cooperation between Human Factors professionals and software engineers to provide a broad range of support for video-assisted observational studies.

Form Testing Suite Corporate Research and Advanced Development, Digital Equipment Corporation

Provides a test suite developed to test various web browsers. The test results section provides a description of the tests.

9. References

[1] Usability.gov , “learn more about usability testing ” http://www.usability.gov/refine/learnusa.html

[2] Nielsen, J. (1994). Usability Engineering, Academic Press Inc, p 165

[3] Microsoft Corporation (2000). The usability in software designing.
Jing Xiangdong, Meng Li. (2000). Brief talks on software usability. <>(2000.6, CHN) ISSN:1008-0775.0.2000-06-000

[4][5]Natalia Juristo, Marta Lopez, Ana M. Moreno, M. Isabel Sánchez (2003) “Improving software usability through architectural patterns” School of Computing - Universidad Carlos III de Madrid, Spain

[6] Jerry Zeyu Gao, H. -S. Jacob Tsao, Ye Wu. (2003) Testing and quality assurance for component-based software .(P 336) ISBN 1-58053-480-5.

[7] Usability.gov , “learn more about usability testing ” http://www.usability.gov/refine/learnusa.html

[8] Waldemar Karwowski. (2006) International Encyclopedia of Ergonomics and Human Factors. (P 1724). ISBN : 041530430X

[9] Waldemar Karwowski. (2006) International Encyclopedia of Ergonomics and Human Factors. (P 1725). ISBN : 041530430X

[10] Whitney Queensberry (2004) “Can usability standards help improve practice around the world?”

[11] ISO 9241-11:1998 “Ergonomic requirements for office work with visual display terminals (VDTs) -- Part 11: Guidance on usability” Chapter 1

[12] ISO 9241-11:1998 “Ergonomic requirements for office work with visual display terminals (VDTs) -- Part 11: Guidance on usability” Chapter 3

[13] Michael D. Levi and Frederick G. Conrad ” Usability Testing of World Wide Web Sites” http://stats.bls.gov/ore/htm_papers/st960150.htm

[14] Wikipedia, “GOMSl” http://en.wikipedia.org/wiki/GOMS
Page related references :
Dix, A., Finlay, J., Abowd, G., Beale, R., Human Computer Interaction , Prentice Hall, 1993
Lecture Notes, Abowd, G., CS6751, Georgia Institute of Technology, November-1997
Kieras, D., John, B., The GOMS Family of Analysis Techniques: Tools for Design and Evaluation, CMU-HCII-94-106, 1994
Kieras, D., John, B., Using GOMS for User Interface Design and Evaluation: Which Technique?, June-1996
Kieras, D., John, B., The GOMS Family of User Interface Analysis Techniques: Comparison and Contrast
Lecture Notes, CS5724, Virginia Tech, Fall 1996

[15] Wikipedia, “think aloud protocol” http://en.wikipedia.org/wiki/Think_aloud_protocol
Page related references :
Ericsson, K., & Simon, H. (May 1980). "Verbal reports as data". Psychological Review 87 (3): 215–251. doi:10.1037/0033-295X.87.3.215.
Ericsson, K., & Simon, H. (1987). "Verbal reports on thinking", in C. Faerch & G. Kasper (eds.): Introspection in Second Language Research. Clevedon, Avon: Multilingual Matters, 24–54.
Ericsson, K., & Simon, H. (1993). Protocol Analysis: Verbal Reports as Data, 2nd ed., Boston: MIT Press.

[16] Ronan Fitzpatrick , Strategies for Evaluating Software Usability
[17] Ronan Fitzpatrick , Strategies for Evaluating Software Usability
[18] Genise, Pauline. “Usability Evaluation: Methods and Techniques: Version 2.0” August 28, 2002. University of Texas.
[19] Pear @ studez.com, “UI – Usability testing” http://www.uml.org.cn/Test/200803054.asp
[20] Pear @ studez.com, “UI – Usability testing” http://www.uml.org.cn/Test/200803054.asp