Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 1999


GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997 |  
Sessions

Business Applications

Data Development and Evolution

Data Distribution and Access

Engineering and Design Applications

Enterprise Integration

Enterprise Resource Planning

Exploiting Field and Mobile Technologies

Invited Track

Operations Support

People Issues

System Architecture

User Perspectives

Work Management


GITA 1999


Business Applications
Printer Friendly Format

Page 1 of 6
| Next |


The Business Side of Objects: Breaking the Barrier between Users and I.T.

Stewart Asbury
Vice President
Byers Engineering Company
6285 Barfield Road
Atlanta, GA 30328


Why use object oriented methods?
  • To develop systems that solve real world problems
  • To develop systems that can be maintained and enhanced efficiently
  • To improve the productivity of knowledge workers
  • To improve the productivity of I.T. professionals
  • To avoid the high cost of requirements errors
"A successful software project is one whose deliverables satisfy and possibly exceed the end user's expectations, was developed in a timely and economical fashion, and is resilient to change and adaptation."
--Grady A. Booth

In essence, object oriented methods attempt to replace the "real world" software evolution process which is Piecemeal and arbitrary with software design that is intentional, comprehensive, and better supports the enterprise's business processes.

How does this happen?
The first step in developing a solution is to state the purpose of the system. Next, define the overall domain of the Problem and catalog all objects, i.e. poles, cables, etc., and behaviors such as engineering design or planning that are within that scope. Then, all actors (users)are identified and the behaviors(business logic) that are necessary to perform the work are listed. Information needed to do the job is also identified at this time. Within this context, the functionality of the system is stated through scenarios called Use Cases and Sequence Diagrams. This documentation provides the basic elements that define the criteria from which the project' success will be evaluated. Thus, the result of this exercise is a high-level system requirements document containing the overall project scope, domain description, and functionality. This also serves as the basis for user acceptance testing.

Once full buy-in has been achieved, sofiware developers take the user specification and look for patterns in the scenarios. This is then decomposed into a database design (features, properties, and relationships)and a class definition of system functions (methods such as placing features or querying Jneeded to build the AM/FMIGIS object model. The classes are documented through application programming interfaces(API's). Business rules are used to capture the existing expertise and knowledgebase of the most productive workers in the enterprise. These can be stored in the form of program code as methods, and configured with meta data, subsets of information similar in theory to an index or card catalog file that is used for locating other, more vast sets of information.

At this stage, you should be using an object-oriented CASE tool like Rational Rose and the Unified Modeling Language(UML)to document the requirements of the system. This is done by decomposing Use Cases into Sequence Diagrams that look at workflow, Class Diagrams and ultimately into physical components. This process ensures that the system design can be traced back to the original requirements. By defining the problems and opportunities that will be addressed in the use cases, the economics for the business case are also identified and affirmed.

Objects for the user
An object orientationtowarduser interfacedesign is equally important. This is achievedby performanceof an indepth interviewingand observationprocessof the end user. Then, one must analyzeand understandhowthe users are currentlyperformingtheirjobs, andthen anticipatingthe best techniquesfor completingthejob usingnew technology.

It is essentialto provide a graphicaluser interfacethat the user immediatelyacceptsand feels comfortablewith. Userdesktop objects(artifacts)are the fi,mctionsthat comprisea set of tools easilyrecognizableto the user, such as spatialquery, networktrace, etc. Theseuser objects are assembledtogetherto build applicationsthat meetthe specificneeds of the disparateuser groupswithin the enterprise. Someof the sametools that an engineeruses to designwork ordersmaybe used in an applicationdesignedfor the long-rangeplanner. By definingthe workflow for eachtype of user, differentapplicationsare constructedfrom a groupofjimctional components to maximizeeach user’sproductivity.

Page 1 of 6
| Next |

Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book