ESRI's ArcWeb Services

ESRI's ArcWeb Services are a collection of tools that enable users to integrate mapping, routing, and geographic reporting into their Web sites, mobile devices, and desktop applications. As businesses grow and enterprise needs evolve, ArcWeb applications can be expanded without the need for additional tools or software reconfiguration. ArcWeb capabilities are built on ESRI's industry-leading GIS (Geographic Information System) software. ESRI, with decades of experience and proprietary knowledge in the GIS industry, provides sophisticated analytical GIS tools to solve spatial problems.

Developer resources are available to integrate ArcWeb services into any application. These services allow users to perform a variety of spatial query and proximity searches on a host of datasets provided by Tele Atlas, as well as on custom datasets uploaded and maintained by users. ArcWeb Services also allow users to create simple or multipoint routes, base maps and color-coded maps, and demographic reports. They also allow users to upload their own data, add it as a layer to an existing map service, and share it with other members of the enterprise.

Serial UART, an introduction

An UART, universal asynchronous receiver / transmitter is responsible for performing the main task in serial communications with computers. The device changes incomming parallel information to serial data which can be sent on a communication line. A second UART can be used to receive the information. The UART performs all the tasks, timing, parity checking, etc. needed for the communication. The only extra devices attached are line driver chips capable of transforming the TTL level signals to line voltages and vice versa.

To use the UART in different environments, registers are accessible to set or review the communication parameters. Setable parameters are for example the communication speed, the type of parity check, and the way incomming information is signalled to the running software.

Serial UART types

Serial communication on PC compatibles started with the 8250 UART in the IBM XT. In the years after, new family members were introduced like the 8250A and 8250B revisions and the 16450. The last one was first implemented in the AT. The higher bus speed in this computer could not be reached by the 8250 series. The differences between these first UART series were rather minor. The most important property changed with each new release was the maximum allowed speed at the processor bus side.

The 16450 was capable of handling a communication speed of 38.4 kbs without problems. The demand for higher speeds led to the development of newer series which would be able to release the main processor from some of its tasks. The main problem with the original series was the need to perform a software action for each single byte to transmit or receive. To overcome this problem, the 16550 was released which contained two on-board FIFO buffers, each capable of storing 16 bytes. One buffer for incomming, and one buffer for outgoing bytes.

A marvellous idea, but it didn't work out that way. The 16550 chip contained a firmware bug which made it impossible to use the buffers. The 16550A which appeared soon after was the first UART which was able to use its FIFO buffers. This made it possible to increase maximum reliable communication speeds to 115.2 kbs. This speed was necessary to use effectively modems with on-board compression. A further enhancment introduced with the 16550 was the ablity to use DMA, direct memory access for the data transfer. Two pins were redefined for this purpose. DMA transfer is not used with most applications. Only special serial I/O boards with a high number of ports contain sometimes the necessary extra circuitry to make this feature work.

The 16550A is the most common UART at this moment. Newer versions are under development, including the 16650 which contains two 32 byte FIFO's and on board support for software flow control. Texas Instruments is developing the 16750 which contains 64 byte FIFO's.

What is NMEA?

The National Marine Electronics Association is dedicated to the education and advancement of the marine electronics industry and the market which it serves.

It is a non-profit association composed of manufacturers, distributors, dealers, educational institutions, and others interested in peripheral marine electronics occupations (quoted from a promo in "NMEA News")

What is an NMEA standard?

For the purposes of this article, an NMEA standard defines an electrical interface and data protocol for communications between marine instrumentation. (They may also have standards for other things.)

More about NMEA?

NMEA 0183 (or NMEA for short) is a combined electrical and data specification for communication between marine electronics and also, more generally, GPS receivers.

The NMEA 0183 protocol is a means by which marine instruments and also most GPS receivers can communicate with each other. It has been defined by, and is controlled by, the US based National Marine Electronics Association.

The NMEA 0183 standard uses a simple ASCII, serial communications protocol that defines how data is transmitted in a "sentence" from one "talker" to one or more "listeners". The standard also defines the contents of each sentence (message) type so that all listeners can parse messages accurately:

• Each message starting character is a dollar sign.
• The next first five characters identify the type of message.
• All data fields that follow are comma-delimited.
• The first character that immediately follows the last data field character is an asterisk.
• The asterisk is immediately followed by a two-digit checksum.

NMEA is a standard protocol, use by GPS receivers to transmit data. NMEA output is EIA-422A but for most purposes you can consider it RS-232 compatible. Use 4800 bps, 8 data bits, no parity and one stop bit (8N1). NMEA 0183 sentences are all ASCII. Each sentence begins with a dollar sign ($) and ends with a carriage return linefeed (). Data is comma delimited. All commas must be included as they act as markers. Some GPS do not send some of the fields. A checksum is optionally added (in a few cases it is manatory). Following the $ is the address field aaccc. aa is the device id. GP is used to identify GPS data. Transmission of the device ID is usually optional. ccc is the sentence formatter, otherwise known as the sentence name.

Unified Modeling: What, Why & How?

Executive Summary

The use of Unified Modeling Language (UML) has been taken as one of the most important parts of software developments in the last couple of years. It is supposed to be a big step towards sorting out silly conflicts over notation. It’s important to know that creating a UML diagram involves a cost, and a UML model is not something that fundamentally matters to a customer. Customers are always interested in the working software that meets its requirements, not pictures & models. Hence the cost of creating a UML model for the system is always bearable by the developing organization only. Yet it is important to avoid the silly mistakes in system analysis and to save resources & time by avoiding conflicts & inconsistencies. Being UML modeling so important, one needs to know the focus of modeling & how to meet this focus. This collection of words includes about how to move with UML for system analysis & deployment before jumping into its development.

What's a Model:

A model may be taken as a form of abstraction that omits undesired details and allows the designer to look into the more important aspects and elaborate them with proper consideration. A model allows a designer to look into all the aspects of the systems so that no important phase or point or detail is left without discussion and consideration that may cause failure of development in later stages where the remedy actions are either impractical or they are too costly & time consuming. A model is used for understanding a system properly before its actual implementation so that the product may be developed in a cost effective and efficient manner. Also the systems developed with proper understanding are much more maintainable and feed to user requirements for long time.

To build complex systems, they need to be simplified first so that they may be properly understood & then developed in a maintainable way. For this the designer needs to watch the system from different focus points with abstract details. These focus-points give different “Views” of the system. These views of the system give a “Model” of the system.

Why Modeling?

While designing a system, we need to analyze and understand it from different angles & view points. So many different conceptual, logical, physical and other types of complexities need to be solved. For this we use different design strategies and models. Modeling creates a base for implementation of the system and its testing. It gives specifications for its use by customer. It explains the design idea in a presentable form. A Model explains the system at different levels of abstraction. At a time, it provides a selective aspect study of the system. The designer can use it to explain the architecture to the professionals and abstract and relevant details to others. Modeling it a strong tool to plan the steps in development of the system and check the feasibility of ideas before final actions on it. Modeling also provides a base for testing and testability of the system before the system is actually implemented. Moreover, modeling reduces the complexity of the system and hence saves resources.

It is important to mention here that the design is only a concept that describes the system understanding of the designer. It tells the thinking of an experience-holder about the strategy to be adopted for development of the system in hand. Now all human does not think in the same way. Some may have better understanding in textual form while others may prefer graphic notations of the design. Here the model efforts to bring them on an almost common platform where the conflicts of the design may be resolved and some consistent design for implementation may be proposed. Model is also important to remove the silly mistakes while developing the system and also creates a scale for evaluation while development. Its output is something more than a simple software system with its better understanding, documentation and maintenance tips.

OOMD & UML

Object-Oriented Modeling & Designing (OOMD) is an innovation for Inception, Elaboration, Construction and Transition in Software Development Life Cycle (SDLC). This is a way for analyzing, designing and developing a software system using concepts having direct correspondence with the real world entities. We use graphic notations for Object-Oriented construction of systems. Visual Modeling is one way for generating these notations. Visual modeling creates Object-Oriented-Models (OOM) for a system under construction for its analysis, designing & implementation in an object-oriented language. We create OOMs for complex systems under construction for their better understanding and a better & efficient designing. We use different graphical notations with lots of documentations for a proper & unambiguous understanding of the system. For such modeling of the systems, we can use a globally accepted media known as Unified Modeling Language (UML). UML gives a set of graphical notations prescribed for different entities & terms used in Object Oriented Modeling of any system.

How to start: Static Analysis

The system development life cycle starts with a problem statement using which a use-case model is created which is important to state the understandability & usability of the system. Here the system is represented at the highest level of abstraction i.e. (generally) as a single unit that can be used for some purpose. It includes all possible conversations (termed as use cases) between a user (termed as actor) and an operator in the system during any task. Sequence of occurrence of the dialogues is not important to be mentioned in a use case model. Also it is not required to show how the system is performing its task. It only shows how a system interacts with its environment/user.

The Next Step

Once the system & its interaction with its environment are understood, the analysis part of system development life cycle (SDLC) is almost complete. The next step is for designing the system. This design is later implemented in terms of some high level codes, which are then to be converted into executable modules and installed in the environment of the system. Hence designing creates a base framework to move forward towards implementation. In unified modeling, class diagrams are created for this step of SDLC. The appropriate classes can be found from problem statements from the list of nouns used in the problem statement. These classes interact with each other in terms of message passing. The classes create templates for objects in the system and hence we need to show the attributes as well as methods involved in the template clearly. Class diagram creates a base for implementation of the system in any Object-Oriented language. Lacking a proper description of types or interactions of classes in the class-diagram not only can weaken the base of quality of the system but can also introduce many inconsistencies in the system. So we need to clearly describe all required templates and interactions between them. For more clarity this analysis is done on different levels of abstractions from top to bottom.

Dynamic Analysis

Static analysis is followed by analysis of dynamic behavior of the system. Here the unified-model members include sequence diagrams & state diagrams. For software implementation point of view, the state diagram may not be of direct use but they serve for understanding the system dynamicity in terms of some finite number of states. This finite state analysis helps the developer to avoid many inconsistencies and exceptions at run-time. The state diagram clearly state the transitions of states on occurrence of some event or message passing between two classes. State diagram is highly important in concurrent processing or multithreading system designing & enhancing their performance.

Next in System Dynamics

System dynamic analysis includes another important analysis what we call ‘sequence analysis’. Sequence analysis talks about sequence of occurrence of events & operations. Sequence analysis gives direct information for implementation of a function or method. While creating a sequence diagram for a task or some function, it should be kept in mind that sequence analysis might be taken as the boundary of designing & implementation phases of SDLC from where we might be able to see both sides of the boundary. This means that a sequence diagram should be able to describe the direct mapping for the design to its coding in the programming language. Hence the sequence diagram can be understood like a graphical representation of the algorithm to implement a task in the system. The sequence analysis is important for each and every task. At the lowest level of abstraction, all the functions and methods included in a class are analyzed for occurrence of sequences of operations in it. This sequence can then be taken as it is and implemented in the chosen high level (Object-Oriented) programming language for the required function. The best sequence diagrams are expected to describe all the required programming instructions in the form of message-passing events.

Unified Modeling for System Deployment

After static & dynamic analysis and designing of the system, the software is implemented for the system in programming language. After that, the system needs to be installed in its working-environment including other interacting software, hardware and user interfaces. To analyze it before system implementation, deployment views in UML are used to show other interfaces, software & hardware, communication media and communication buses present in the environment. In deployment diagram, the information about the type of communication buses, server configuration, database architectures, type of interfaces with other used hardware and software etc. should be clearly mentioned.

Closure

No doubt that designing is one of the most crucial and resource consuming phase in SDLC and that’s too the one which has nothing of direct interest of the consumer. The developing organization itself is expected to bear the net cost of designing & modeling. In such a scenario, Unified Modeling has rapidly become the standard notation for modeling software-intensive systems. Companies today are interested in the entire project development life cycle and how it ties into the Unified Modeling. In most cases, the various methodologies will easily adapt to it. Unified Modeling provides a complete modeling at almost every stage of SDLC right from the beginning of requirement analysis till deployment of the system covering implementation model and dynamic behavior model also. For those of us who have built software and designed databases for many years, unified modeling will also remove additional risk from the development process. Although the unified modeling is not a SDLC process, it offers a concise and workable notation that can be applied to any domain.

UML definitions

Introduction

Some general definitions to key concepts in the process space.

Activity

A unit of work a role may be asked to perform.

Activity diagram

Represents a special case of a state machine that is used to model processes involving one or more classifiers.

Actor

Represents someone or something, outside the system, that interacts with the system.

Aggregation

Shows an association that models a whole-part relationship between an aggregate (the whole) and its parts.

Analysis & design

A discipline in the Unified Process, whose purpose is to show how the system's use-cases will be realized in implementation; (general) activities during which strategic and tactical decisions are made to meet the required functional and quality requirements of a system.

Analysis class

An abstraction of a role played by a design element in the system, typically within the context of a use-case realization. Analysis classes may provide an abstraction for several roles, representing the common behavior of those roles. Analysis classes typically evolve into one or more design elements; for example, design classes and/or capsules, or design subsystems.

Application Programming Interface (API)

Represents a software interface that enables applications to communicate with each other. An API is the set of programming language constructs or statements that can be coded in an application program to obtain the specific functions and services provided by an underlying operating system or service program.

Architecture

Represents the highest-level concept of a system in its environment. The architecture of a software system (at a given point in time) is its organization, or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces. Architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components, and subsystems.

Artifact

A piece of information that:

1. Is produced, modified, or used by a process,

2. Defines an area of responsibility, and

3. Is subject to version control.

An artifact can be a model, model element, or document. A document can enclose other documents.

Association

Represents a relationship that models a bi-directional semantic connection among instances.

Boundary class

A class used to model communication between the system's environments and its inner workings.

Business actor

Represents someone or something, outside the business, that interacts with the business.

Business entity

A business entity represents a significant and persistent piece of information that is manipulated by business actors and business workers.

Business use-case

A business use-case defines a set of business use-case instances, where each instance is a sequence of actions a business performs that yields an observable result of value to a particular business actor. A business use-case class contains all main, alternate workflows related to producing the "observable result of value".

Business use-case model

A model of the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization.

Class

A description of a set of objects that share the same members.

Component

It represents a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function. A component should conform to and provides the realization of a set of interfaces.

Component diagram

A diagram that shows the organizations and dependencies that exist among components in a system.

Composition

Represents a form of aggregation association with strong ownership and coincident lifetime as part of the whole.

Deployment diagram

A diagram that shows the configuration of run-time processing nodes and the components, processes, and objects that live on them.

Development case

The software-engineering process used by the performing organization. It is developed as a configuration, or customization, of the Unified Process product, and adapted to the project's needs.

Discipline

A discipline is a collection of related activities that are related to a major 'area of concern'. The disciplines in RUP include: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.

Document

A document is a collection of information that is ‘intended to be represented’ on paper, or in a medium using a paper metaphor. Web pages may serve as documents.

Elaboration

Represents the second phase of the Unified Process where the product vision and its architecture are defined.

Entity class

A class used to model information that has been stored by the system, and the associated behavior. It typically defines a set of entity objects, which participate in several use-cases and typically survive those use-cases.

Environment

Represents a discipline in the software-engineering process, whose purpose is to define and manage the environment in which the system is being developed. Includes process descriptions, configuration management, and development tools.

Executable architecture

An executable architecture is a partial implementation of the system, built to demonstrate selected system functions and properties, in particular, those satisfying non-functional requirements.

Extend-relationship

An extend-relationship from a use-case class A to a use-case class B indicates that an instance of B may include (subject to specific conditions specified in the extension) the behavior specified by A. Behavior specified by several extenders of a single target use-case can occur within a single use-case instance.

Feature

An externally observable service provided by the system which directly fulfills a stakeholder needs.

Inception

The first phase of the Unified Process, in which the seed idea, request for proposal, for the previous generation is brought to the point of being (at least internally) funded to enter the elaboration phase.

Layer

A layer represents a horizontal slice through an architecture.

Milestone

Represents the point at which a given iteration formally ends.

Model

Represents a description of a system from a particular perspective, which describes the system in such a way that no additional information is required to understand the system (from that perspective).

Model element

Represents an element that is an abstraction drawn from the system being modeled.

Node

A node is a classifier that represents a run-time computational resource, which generally has at least a memory and often processing capability. Run-time objects and components may reside on nodes.

Package

Represents a general-purpose mechanism for organizing elements into groups.

Refinement

Depicts a relationship that represents a fuller specification of something that has already been specified at a certain level of detail.

Relationship

Represents a semantic connection among model elements.

Requirement

A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed documents.

Risk

Represents an ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones.

RUP

Rational Unified Process

Scenario

Represents a specific sequence of actions that illustrates behaviors.

Service-Oriented Architecture (SOA)

A service-oriented architecture is a conceptual description of a the structure of a software system in terms of its components and the services they provide, without regard for the underlying implementation of these components, services, and connections between components.

Software requirement

A specification of an externally observable behavior of the system; for example, inputs to the system, outputs from the system, functions of the system, attributes of the system, or attributes of the system environment.

Stakeholder

Represents an individual who is materially affected by the outcome of the system.

Stakeholder need

Represents the business or operational problem (opportunity) that must be fulfilled in order to justify purchase or use.

Template

Represents the predefined structure for an artifact.

Traceability

The ability to trace a project element to other related project elements.

Use-case

Represents a description of system behavior, in terms of sequences of actions.

Use-case diagram

Represents a diagram that shows the relationships among actors and use-cases within a system.

Vision

The user's view of the product to be developed specified at the level of key stakeholder needs and features of the system.

Enterprise Application Solution: A Component Based Approach

1. INTRODUCTION

The trend of Information Technology has taken a big aspect over the whole world. It has got the trust of various types of users, especially of business organizations by offering the way to optimize the business processes.

To achieve high performance with respect to information technology, it’s obvious that a company should contain a well organized computer based information system, containing an application solution that reflects the business strategies, business processes, business models and core processes derived from these strategies. Since in real business world, business processes and models changes frequently, so the computer application solution must be designed in a manner that, it can also be changed quickly to meet the current business requirement [6].
Each business organization contains some strategic goals, on which the organizational decisions made by the proper positioned person. To do that certainly s/he should get the correct, appropriate and relevant information at the right time. Besides focusing on core business, the authority desires proper support for customer and partner contact management, monitoring employee’s activities and improving relationship with them. Considering these facts, a computer application solution should offer a great deal of performance and business application integration.
Enterprise Business Application is $200 billion industry and growing. 10,000+ companies are providing solutions that cost $0-$1 million.

2. ENTERPRISE ARCHITECTURE

2.1 What is Enterprise Architecture?

Enterprise architecture identifies the core components of the organization or a sub-set of it (such as its information systems) [1, 9]. Considering the target as the defined business objective, these components work together. These components contain staff, business processes, technology, information, financial and other resources, etc. If the architecture is engineered enough to ensure the selection of the desired components and to specify how they will operate together smoothly and efficiently, the corresponding enterprise will be benefited [1, 4, 9]. But if the overall architecture is not well engineered enough, the result is likely to be duplication of effort and resources, poor coordination and control, problems with management and business performance, inability to share important resources such as information, and inefficiencies in operation [3, 5].

2.2 Advantages of Enterprise Architecture:

Computer based enterprise architecture should be considered as an investment for the future. From the point of view of a paying client of an application solution, initially it may seem costly but considering long term duration, it will provide some real benefits. The facts that considered as the advantages of enterprise architecture can be described as follows [5-10].

· It provides efficient, appropriate and timely support for business processes - including achieving fast time to market or operation for new business endeavors.

· It facilitates the interoperability between separately developed application systems both within and outside the enterprise (e-business, joined-up government).

· Necessary business process re-engineering becomes easier.

· Maximum longevity/reuse of infrastructural components can be ensured

· It maximizes the opportunities for exploitation of corporate information/data assets (such as for customer relationship management or improved decision-making).

· Ensuring the survivability of information/data

· Ensuring suitable support to users, whether internal or customers, including appropriate availability and ease of use

· Reduces the cost of execution.

2.3 Real-Time Enterprise Architecture:

Although in developed countries, many organizations started to get the benefit of Enterprise Architecture, but most company processes today are not integrated, rather run in separate process. Feedback from one process to another is costly. An organization may contain a software system that independently process whatever has to be concerned with in the corresponding department: purchasing concentrates on purchasing, production on production, and so on.
To survive competitively it is essential to know one's customers' needs and be able to respond to these quickly. This requires an overall integration of all business processes.

Organizations who can support not just separate business information processing, but who can also achieve consistent business process integration in a flexible way with suppliers, partners and customers, even across whole organization boundaries, can be denoted as real-time enterprises [1-3]. A real-time enterprise can respond to customer needs and market changes effectively and quickly. It concentrates on its core objectives, while extensively integrated, strategic partners focus on selected activities. The high availability and security of the business-critical applications gets the considerable attention [1, 4].

2.4 Key Features:

Considering Web-based solutions, the key features of modern, enterprise-wide application architecture include [8- 10]:

· Dividing the application into several tiers, at least for presentation, business logic and data storage tier (n-tier concept).

· Use of Web browsers (for stationary and some special mobile terminals) and WAP micro browsers (for mobile terminals) as a primary user interface with support for the standards HTTP and HTML or WAP and WML, respectively.

· Use of de facto and Internet standard based protocols and data formats, such as TCP/IP, FTP, SMTP, SQL, ODBC, LDAP, SSL, etc.

· Component technologies such as Microsoft COM+ Services/ .NET Enterprise Services and Enterprise JavaBeans (EJBs) can be used.

· Dedicated, function-optimized server technologies such as Web Servers, Portal Servers, Contact Servers, Application Servers, Integration Servers, Database Servers and Directory Servers can be used.

3. COMPONENT BASED MODEL: A CASE STUDY

We know, “Cost ¥ Software Customization” - that is cost is proportional to customization with respect to software development, which tells that the more you want to customize software according to your company strategy, you have to consider more cost.
The corresponding software manufacturer can further extent the component for the user, who is able to provide more money and want to customize software according to exactly, fit their whole business process.
By surveying several corporate computer users, according to their requirements, here are some key facts that should reside in a real-time enterprise application solution component.
A typical enterprise organization consists of the following major section:

· Human Recourse Management (HRM)
· Supply Chain Management (SCM)
· Customer Relationship Management (CRM)
· Accounts

These four facts are briefly described below:

3.1 Human Recourse Management (HRM):

In any organization or company a number of people are involved to achieve the desired goal or target of the organization. In an enterprise company there are more than hundred to thousand peoples are employed. So from this view we can say Human Resource Management (HRM) is a very important part of the organization that is concerned with the working people in that organization. So the Human Resource is one of the driving force for product as well as service oriented organization.

The main objective of HRM department is to make a good balancing way to distribute all employees in the company in such way so that right person is on right position.
Since in future a company may need more employees or to change its employees depends on the requirement or situation, the HRM procedure is ongoing procedure that always tries to fulfill the requirement of human resource in the enterprise organization.

Basic features of HRM are as:

· Recruitment and Selection
· Training and Development Skills
· Performance appraisal
· Maintenance and Motivation

3.2 Supply Chain Management (SCM):

Supply Chain Management is the process which keeps track of the products that are imported, the supply of the product that’s produces by the current company. The SCM section will provide the facility that keeps track of information how the product supply, keep track of current status of goods etc.

3.3 Customer Relationship Management (CRM):

For a business organization customers plays a very important role. So, the goal of a CRM strategy is to create a long term, profitable relationships with the customer. This can be achieved when company understand who their customers are, what their needs in different segment and economical means to meet the needs of each segment. CRM includes a series of business function that contribute to the successful management of the customer and company relationships. The basic functionality provided by the CRM section is let the employees see the behavior of the customer and organize their time better, identify opportunity and turn them into close deals, account history is used to check out previously purchased products, to check how the customers satisfy with the level of service or the quality of products, to analyze and making perfect decision.

3.4 Accounting:

Generally each company contains account section, which summarizes the financial data about the business and organizes this information into useful form. The facts that are relevant to an account section are making Balance Sheet, Income Statement, Share Statement, Yearly profit or loss, etc. by dealing with paying salary to all employee, rent charge, production cost, total amount of money by selling goods or service, total due in the market, equipment cost and wages, paying taxes, advertisement cost, purchase discount, purchase return, investment, inventory, account payable & receivable, net income, net loss and other relevant tasks.

4. UTILIZING BEST PRACTICES

Business organizations can be benefited from low cost pre-built solutions that are based on industries best practices. A best practice is a business process with demonstrated ability to achieve superior results. For Example sales forecasting is a business, while triangulated sales forecasting is best practice business process. Best practices can be derived only from successful, extensive experience in selling, marketing and service. Usually to use such systems requires just business skills and management of such systems is also simple. Mainly users adopt their business and learn to do the business that every one agrees. Organization achieves maximum business impact from ERP/CRM implementation by applying best practices to their business process. Since the internet thing is emerging one can participate just by utilizing ERP/CRM. A new genre of business consultant will emerge by learning and utilizing industries best practices.

5. CONCLUSION

In several cases, the customized software’s that ware built to meet the requirements of business organizations, by software manufacturers, contains several bugs and some sort of inefficiency to process and provide information. The cause that lies beneath this problem is lack of proper awareness of well engineered software application solution that contains proven design methodologies and architecture. Developing a well engineered real-time enterprise application solution component is a challenging task. The best approach for such activity will be to participate in a mature open source project. There are several open source projects available that uses different programming platforms like PHP, Java or .NET. Some of the tools are even free. Universities could take lead for such research and development activities. Industries participation will definitely strengthen our commitment to IT development and establishing high tech call centers even in remote places in our country.

Requirement Analysis Steps while Developing Software

Introduction

This article provides a basic outline to discover, document requirement documents for a given software project. Some of the steps can be ignored if the application requirements are pretty simple or small.

The Steps

Research on Application Requirements

This document includes the URL’s that are the web application and similar to the current project, which will be used to elicit the requirements. It also contains the necessary user name and password for the research sites, along with the research report where required. This type of document can also include the user questionnaires interviews if necessary.

Research on Technical Issues [developer view]

This document includes the list of technical issues that are relevant to the current project, along with the useful URL and the research report.

Application Basic Features [user view – top level]

This document includes the basic key features for the current project. This describes the application from very top level point of view, so that any one can understand about the system very quickly and easily. It also helps the developer to identify and articulate the development process from very early stage.

Use Cases [user/developer view – top level]

This includes text and diagrams that illustrate how all the application features and sub-features are acting and communicating thru various stage of usage and work flow. It helps the user and developer to understand and identify system process from basic, initial and top level point of view.

User Interface Specification [user/developer view – mid level]

This document is useful while building the application. Thru this specification the client get an initial idea about what the system is and it comes easy for the client to verify and confirm whether they are going to get all the required features. We can use Microsoft doc (for wire frames) or simply static html lay-outs to illustrate the UI.

User Requirements Specification [user/developer view – low level]

This document includes the detail specification of the application. Basically this is the detail description of the basic features that has been identified.

Architecture

· Security model

· Skinning and page settings

· Global data transfer among pages

· Identifying the modules & module boundaries [top level]

It describes the basic, core modules that are being considered to be developed. This is especially useful while working with large scale projects. Although this is used to define the system boundaries from top level view, by defining the sub-modules as well as, makes the future development process more requirement specific and makes the complex task to integrate the modules and identity the module communication in the design time easy.

Data Fields [user/developer view – low level]

The data fields of the application have been identified in this step. Database schema, relation and data fields are recognized and validated with the client to ensure the current requirement analysis grabs all the required things.

Time Estimation [manager view]

• According to modules
• According to development steps
• According to developer expert level
• According to logical tiers (as well as level of engineering)

The Business Object Hierarchy Tree [For those who can't code or design]

Introduction

Identifying objects and classes in a business application is often a cumbersome task that starts with the analysis of the requirements given. Requirements tend to be incomplete, unclear and forever changing. During the analysis there could be problems like misunderstanding of the requirements, poor documentation, new ideas and limitations of the proposed design. Therefore a lot of time and effort is spent before finalizing an application's objects and the relationships between objects. Even in good conditions designing objects is a tedious and iterative process. This article attempts to make designing easier by creating a hierarchy tree for all the business objects in the application.

Background

A well-known class in dotnet framework is that the System.Object class which is the ultimate base class of all the classes in dotnet. This class provides basic functionality so that all the dotnet objects have some common mandatory behaviour. In the same way we could have an ultimate base business class for all business objects in a business application so that all business objects have common business functionality and attributes. I have named this class as System.BObject. Here the word 'System' is an alias for the software application being developed and not the System namespace used in the dotnet framework.

Why a base business class?

Business objects are used to implement workflows, business rules, or represent real world objects in an application. Non-business objects usually end up as part of the application's framework where they provide data access, exception handling, event handling, logging and similar functionality. Non-business objects are at times reusable across applications whereas business objects are application specific.

All business objects within a given business application are related to each other, as they are members of the same business application. Therefore they could have an ultimate base class that provides some behaviour common across business objects. By deriving objects from the base object we create an object hierarchy tree. By trying to fit in objects in the hieraarchy tree makes it easier understand their purpose and helps to justify the application's design. If an object cannot be fitted into the hierarchy tree, it would indicate that need for the object has not been understood properly or that the design is flawed in some way.

Advantages of creating the hierarchy tree

Each class would have ready methods and attributes from classes higher up the hierarchy. Whenever required the child classes could either override or shadow methods in its base class(es).

Optionally we could create a hierarchy tree using interfaces. By using interfaces we could easily shift classes between components within an application. The classes implementing the interfaces would have to have its own implementation of the interface methods and properties.

At this stage of design it doesn’t really matter whether you go with classes or interfaces, as the main purpose here is to identify the objects and their attributes, properties and methods.

By placing all business objects within a hierarchy tree we could also up cast and downcast objects. This means we can handle the base object dynamically depending upon what type it can be downcast to. It also allows for parent types to be assigned to the child object similar to what is done using dotnet framework objects.

eg. System.Object o = new System.OutOfMemoryException();

In the above line any derived class of the System.Object class can be assigned to a System.Object type.

Once a hierarchy tree has been created it is easier to identify probable associations between the objects. If we simply defined objects without placing them in the hierarchy tree, it would difficult to even perceive that a relationship could have existed between some of the objects.

For example if we created objects called company, services, customers, users, offers, policies, and departments without putting them in the hierarchy tree it would not be clear how these objects are associated with each other (if at all). A hierarchy tree would not show associations either but it would be easier to identify possible relationships just by studying the tree.

Another advantage of building the tree is that if helps in finalizing the requirements. If the business analysts were to do this exercise along while writing workflows and use cases it would ease their understanding of the scope of the application to be developed and identify shortcomings in their documentation.

Estimation of the application would become easier too. The number of man hours to develop each object in the tree could also be worked out by studying the number of public methods in each object's class or interface. For more information on estimation read the articles 'How to estimate a software project' and estimate man-hours.

How to build the tree?

A few simple steps shown below should get the ball rolling.

· First start by suggesting business objects for your application after analyzing the requirements.

· Then place these object in your tree and show them all as directly deriving from a base object say BObject.

· Identify as many objects however trivial they may seem.

· Once you have a dozen or more objects try to see if any of them share common attributes or have similar features.

· Then place the common features into an intermediate base object which is placed between the BObject and your specific business object.

· Continue doing the above steps and you should have acceptable hierarchy tree in a few hours.

· In case the tree is getting to be too big it could be split up into several diagrams. The first diagram would have only those business objects that are higher up the hierarchy. The derived objects could then be shown in separate lower level trees.

Objects that do not fit into this tree could be framework objects like those used for exception handling, database access, emails etc. These objects would usually inherit from some dotnet framework class or interface while a business object would not. In case one cannot fit all business objects in the tree then treat such objects in utility objects or generalized objects.

A fictitious business application

In the above figure we have a top-level class (ultimate base class) namely the BObject class. Most business objects would normally have an unique identification number or code, a name, a description and an activated status. Let us name the corresponding attributes as ID, Name, Desc and ActivatedStatus. Therefore these attributes could be placed in the BObject class and because of inheritance all the derived classes of BObject would also have these attributes.

Inheritance

Next let us identify some attributes for the Registration class other than those already provided in the BObject class. To register a user we usually have a user name, password, first name, last name, email, address, state, country and telephone. To register a business enquiry we could have customer name, contact person name, email, address, state, country, telephone and requirement details. Requirement details could be another business object having its own class (including derived classes). To register a sale we could have customer name, contact person name, email, address, state, country, telephone, invoice/order number, bill number and receipt number. By observation we can have the email, address, state, country, telephone as the common attributes for the registration class. As the (person/contact/user) name attribute is common across the classes we could create a new class called Name for handling different types of names. The Name class could have properties called username, firstname, lastname, customername, contactname, companyname etc. This would help prevent the base Registration class from getting cluttered with too many attributes and also avoid having to name separate set of attributes in the derived classes. In the same way we could go on identifying and placing common features for a set of related classes.

But the key issue is that without the object hierarchy tree figuring out what objects to create and how these objects fit into the design would be a more difficult task. By first creating the tree using the System.Business.Object as the ultimate base class we can derive the business classes/objects and create the hierarchy tree. This makes it easier understand and justify where they fit in and how to separate out the parent and child classes.

Associations

Another useful feature of creating the hierarchy tree is that we can identify the possible relationships between classes more easily. Looking again at the figure above the following relationships are possible,

Class BObject.Organisation.Division.Department.Team.Member and the BObject.User.Staff [Operator, Visitor, Admin] have a one to one relationship. i.e. one team member can map to only one type of user.

Class BObject.Report.Internal.Sales and the BObject.Registration.RegisterSale could have a one is to many relationship. i.e. the sales report may use several instances of the RegisterSale object to gather details for the report.

Class BObject.Registration.RegisterSale and the BObject.Report.Enternal.Bill could have a one is to many relationship. Here one sale could involve several bills as a sale to a customer could be extended in case the customer requires more items after the first set of items were finalized.

Class BObject.Report.Internal and the BObject.Organisation could have a many is to many relationship. Here the internal report could involve several features of the organization and again an organization could require several types of internal reports.

The RegisterEnquiry class may be functionally more suitable to the user or the Organization but its real parent would be the Registration class. The RegisterEnquiry adds more definition to the Registration class and is related to other classes derived from the Registration class. But it doesn’t add more meaning to the Organization class. Instead it would be an attribute of the Organization class or its derivatives.

The Services and User classes could be an attribute of the Organization class.

Thanks to the hierarchy tree it is easier to understand and finalize the relationships between the objects.

Conclusion

Each business object is related to other business objects for a given system. Once the hierarchy tree has been created for a system's business objects it is easier to understand how the business objects fit into the system and how they interact with each other.

The hierarchy tree represents the entire structure of the business application in a object format.

Extreme Designing

Introduction

I had attended a session on design and architecture recently. One of the topics of discussion was on how design cannot be implemented strictly during the coding stage and so is it really worth spending too much effort on design. This got me thinking. I come from a civil engineering background where nothing gets done right including the estimate, contract terms and execution unless the design is thorough.

I mean you can’t build a new and complex machine/bridge/railway system without a design in place. Design is where the requirements become tangible. The real weakness is that we don't come out with clear design and the shortcomings usually show up while coding. It should be clear to the developers who have to churn out the code. Just drawing some UML diagrams to explain how issues are handled in generic terms is not enough. 'A picture says a thousand words'. But somebody has to now clearly understand it and write those words to recreate the picture in script, plus some.

So I decided to focus on how best to improve the design phase of software development rather than treat it as a necessary evil.

Background

It's true that, in many projects by the time of coding, there is usually a lot of disparity with the design. This happens mainly because we focus only on providing a high level design but never focus on what the developer needs to achieve the expected output. To solve this issue, what we need to do is put more details into the design and not less. The fine detailing (ask a building architect what this means) should be done.

To achieve a pukka design, the real need would be to find a way to test the design and prove that it implements the application requirements and the coding requirements. After all, we test our code so why not the design too. Perhaps the low level design could be compared against the test cases.

Designing extended

To ensure a more complete design, try some of the following in a suitable sequence:

• Put in the pseudo code.

By doing so, the designer is actually trying to implement the design. During this process, shortcomings in the design from the coding point of view could be realized. Even programming bits like class fields, properties, constants, enumerators, helper/private functions to do some specific tasks all could be identified while doing the pseudo code. In fact, during coding stage the developer would mostly write language specific code to implement the pseudo code.

This means we now have a two stage design process. First, do a high level design to implement the general architecture. So design patterns, identifying domain entities, relationship between domain entities and all the normal design work is done first. Then an experienced developer would take the design further by trying to implement the pseudo code for it. This can be considered as a kind of unit testing.

• Create a traceability matrix

Map each requirement/specific rules to our design classes/methods. This will help ensure that most issues have been considered in the design. It will also help identify what was left out. Create flow charts and map each node in the chart to your design elements. Again this could be a two stage process. First, the high level business related flow charts are created and the high level design (abstract classes or interfaces) is mapped to it. Then the lower level flow charts are created and specific concrete classes/methods are mapped to it. This can be thought of as a kind of integration testing.

• Documentation.

Yes, this is a cumbersome process but it does clear lot of confusion when writing the code for them. So every class, variable, property, method and event's existence/usage is explained so that the coder knows exactly what to do with it. In this way even developers new to the project could get going without having to know in detail the business process and project specific nuances involved.

• White box testing

Explain the classes support the workflow/process to your peers and developers involved in the project. This way the designer gets a better understanding of the developer's expectations.

• Black box testing

Have people who haven’t got much information about the project to read your design, explain what they have understood from it and how they would implement it.

• And last but not least, make sure that the coding does not include anything significant that isn’t reflected in the design.

The design document should be the only reference for coding. Even usage of other coding components, DLLs that are part of the project must be mentioned in the design by referring to the specific design document.

Bottom line

Of course, to ensure that the code does what it was required to do can only be proved during testing. A test driven development process would ensure that your output is right (it doesn’t ensure that you developed it the right way). To take that further, if test driven code was the best way to do things then why not code driven design, design driven requirements and requirements driven customers.

Changes to requirements and design do happen all the time and have to be accepted (within limits). Use UML to explain the design and put in the pseudo code. And pair designing would give greater value than pair coding.