The Business Side of Objects: Breaking the Barrier between Users and I.T.
Objects for the programmer
At this time, the base classes,which includestructures,conductors,and devicesandprovidethe most generalized
viewof the objects defined,are decomposedinto class definitionsthat serve as applicationprogrammerobjects.
Reuse of these objects greatly improves development productivity in extendingand makingchangesto the system. It
is essential that the API’sare cataloged in such a way that the softwaredeveloperscan find what they needand
really reuse the codethat has been developed.It is ironicthat it will probablyrequirea subject oriented method
like HTMLto manageand best utilizethe object orientedprogramming resources.
We can best illustrate these concepts through use of an analogy. Take, for example,the domainof an airplane:
Purpose:
A system that transports people and equipment over long distances.
Behaviors:
Flying, landing, steering, loading cargo, eating, etc.
Objects:
Wings,seats, fuselage,engines,etc.
Ultimately:
The classesare definedand at the lowest level are the bill of materials(e.g., sheetmetal, machineparts, etc.)
and the assemblyinstructions(specificationsfor suppliers)whichare specifiedso that the basic materialsare
transformedinto componentssuch as wings, fuel tanks, t%selage,etc. Theseare the equivalentof programmer
objectsand the assemblyinstructionsare the class librariesand API’s.Theend users--pilots,flightattendants,
and passengers--donot needto knowhow to build the airplane,but they must be providedwith the flight
controls,seats,tray tables, lavatory,etc., to effectivelyuse the airplane.
Don't get ahead yourself
Following this process is critical. You should curb any tendencies to design the object model in advance of the
requirements. This breaks the traceability principle and likely will result in a system the user (the key beneficiary)
cannot use or even recognize. However, when done correctly, the knowledge acquisition process that is used to
speci~ object-oriented applications will capture the knowledge base, skills, and expertise that users have in the form
of desktop tools and business rules.These object oriented applications are built to be flexible and you can extend
and combine them with new functionality as your business processes evolveover time. The information technology
group, subject matter experts, and the users can leverage a common system methodology to ensure that the purpose
of the AM/FM/GIS system is being met.
Putting it all together
The core developersproducethe base classes,objects,and methodsand documentthem with API’s. Theapplication
programmersuse languagessuch as Java, Visual Basic or "C" along with the class libraries and API’sto build
applications for the user. The user takes the applications and desktop objects to perform the work that the system
was designed to do in the first place.
User acceptance
Using this method increases the probability that the system delivers the solution you need. Having users and
software developers speak the same language from the beginning of the project ensures the delivery of systems that
are usable and productive and provide a set of criteria that are the basis for user acceptance and satisfaction.
Everybody is happy
The end user, the software developers, and upper management are happy. The user has tools that enhance
productivity, the developer spends less time "reinventingthe wheel" and gets to play with new technology, and
management improves the bottom line.
Cautions
If you area programmer, don’t confuseend users by talking about API’s as if they were "real" business objects.
These are programming tools and are very interesting to programmers. However, you should use "real world"
language when conversing with users and when documenting the specifications. Programmer objects and user
objects are not the samething, but both are derived from the business problem as defined in the domain description.
Conversely, if you’re an end user, don’t try to be a software engineer.
