real life object oriented systems

7 6 I E E E S o f t w a r e M a r c h / A p r i l 1 9 9 8 0 7 4 0 - 7 4 5 9 / 9 8 / $ 1 0 . 0 0 © 1 9 9 8 I E E E

bject orientation”has become a popular catchphrase. We hear about OOuser interfaces, OO design, and OO languages. Managers expect certainbenefits from object orientation, including better user interfaces, reuseof code, and cheaper development costs. Despite the reputed advan-

tages, little has been published about real-life OO systems.My study of such systems began when some developers of business applications

told me they could not see the advantages their managers expected from object ori-entation. In contrast, developers of technical systems could detail real benefits aftersome trials. I subsequently published an article critical of object orientation in theDanish edition of ComputerWorld. The article sparked considerable debate andbrought me into contact with many developers who claimed to have successful OOprojects. Typically, these developers had long development experience and morethan four years of OO experience. From these successful claimants and other refer-ences to successful teams, I chose seven development groups to study. I mapped thedifficulties encountered by the groups and identified the best current practices.Details of the case studies and other observations can be found on the Web athttp://www.cbs.dk/~slauesen/OOcaseStudies/.

“O

The benef i t s o f ob jec t-or iented deve lopment a re d i f f i cu l tto obta in . The author s tud ied seven OO deve lopmentteams and found that they used one o f three bas icarch i tec tures. H ere he exp lores the advantages anddisadvantages o f each arch i tec ture wi th regard toconnec t ing databases, appl i cat ions, and sc reen objec ts.

Søren Lauesen, Copenhagen Business School

Real-Life Object-Oriented Systems

ED

ITO

R:

Wo

lfgan

g S

trig

el•S

oft

war

e Pr

od

uct

ivit

y C

entr

e• w

stri

gel

@sp

c.ca

.

M a r c h / A p r i l 1 9 9 8 I E E E S o f t w a r e 7 7

Object Orientation

According to the textbooks, OO developmentstarts with OO analysis, in which the problem do-main is modeled as a collection of objects. Duringdesign and implementation, these objects are trans-formed into other objects of slightly different shapethat make up the actual computerized system.1 Anobject contains data and operations that operateon that data. Objects cooperate by calling opera-tions in each other, that is, by sending messages.The data in an object is accessible only through theoperations; no object can access another object’sdata directly.

In a true OO system, data and functions existonly in the form of objects. We can distinguish twokinds of degenerate objects: an object without anydata, which is the same as a traditional subroutinelibrary, and an object with only trivial create, retrieve,update, and delete (CRUD) operations, which cor-responds to a traditional data structure in which thedata is visible to the entire system. A system com-posed entirely of degenerate objects is not a trueOO system. However, the business applications I ob-served consisted mainly of degenerate objects.

The expected advantages of OO systems relativeto traditional systems2,3 include

♦ a development process understandable tousers in that the objects model the real world,

♦ a seamless transition from analysis to final im-plementation,

♦ a graphical user interface where objects cor-respond to the user’s objects,

♦ easier maintenance as objects are modified

without changing the entire system, and♦ reuse of objects in other applications, because

objects encapsulate data and provide a service use-ful in other contexts.

Many developers concluded that OO designswere more complete than traditional designs. Butapart from this, my studies showed that expecta-tions were not fulfilled. In particular, business sys-tems were problematic. Companies usually investedin OO development for the following reasons:

♦ the hope that the claimed advantages wouldcome true;

♦ the need for GUIs and client-server tech-nology;

♦ satisfaction with the data modeling aspectof their chosen OO method, in case they had noprevious experience with data modeling.

Architectures

I have found three basic architectures in OO sys-tems: two for business applications and one fortechnical systems. An actual system might deviatesomewhat from the basic architectures or mix twoof them.

Simple business application architectureSimple architecture systems follow the three-

layer model shown in Figure 1. SQL queries typicallyaccess the top layer, which is a traditional database.The figure shows part of a simplified database fororder processing. The database contains customerrecords, product records, and order lines that de-

I’m sometimes amazed by how long it takes in our industry before new concepts find widespread acceptance in daily practice.

For example, the basic principles for using software engineering as a disciplined approach to software development have been in

print for almost two decades. But recent surveys show that most companies still operate at what is labeled the “initial level” (first of

five) by the Software Engineering Institute. A similar if less pronounced sluggishness in technology adoption is true for object-

oriented technologies, as Søren Lauesen’s article indicates. The basic concepts of OO have also been known for about two decades,

but their acceptance is still not as widespread as the benefits of this technology would suggest.

In the case of OO, the unavailability of reliable support tools delayed widespread adoption until the late ’80s. Another reason for

industry hesitation is the somewhat complex nature of OO's underlying concepts. Lauesen’s article also shows that the acceptance

of OO technology comes in many flavors. Most users don’t use OO concepts in their originally intended, purest form. This practice is

somewhat encouraged by tools and languages that make it tempting to use the concepts to varying degrees. This is not necessar-

ily bad. The essential benefits of new technology can be realized in any of several ways; ultimately the users, not the inventor, decide

which to implement.

––Wolfgang Strigel

.

scribe products purchased by customers. I’ve omit-ted order records for simplicity.

The bottom layer contains the screen objects theuser sees. These objects include GUI windows, fields,guiding texts, lists, scroll bars, menus, buttons, andgraphical curves. The screen objects are nested asaggregates. The figure shows a customer window,an order entry window, and a sales window with alist of purchases for a given product. Order entry andsales windows reflect the order lines. Customernames appear in all three windows. The screen ob-jects are written in a GUI-oriented programming lan-guage, such as Visual Basic. Depending on the lan-guage used, the bottom layer might also containcontrol objects that handle user actions such as push-ing a button or editing a field.

The middle layer connects the database and thescreen windows. In the simple architecture, the mid-dle layer is a simple buffer for each window. Thebuffer holds data currently shown in the window.The GUI platforms require that screen objects aretrue objects, but all the other components of thesimple architecture are not true objects. Thus, thesesystems are not truly object-oriented.

Although the developers claimed that their de-velopment was object-oriented, this was not visiblein the final implementation. During analysis andpart of design, developers had considered morecomplex objects in the middle layer that did not sur-vive to implementation. On the other hand, the ar-

chitecture is simple to implement. Unfortunately, ithas difficulties handling two or more windows thatshare some data.

I have evaluated the simple architecture againstsome standard issues. These issues are not wellknown and require some explanation.

Commit. When will the data shown in a windowbe written back to the database? With the simplearchitecture, the system writes the data back to thedatabase either when the user closes the window orwhen the user explicitly asks for an “update.” Thesystem writes the buffer back through one or a fewSQL queries as a single transaction.

Integrity. The database must not be corrupted.With the simple architecture, however, some fieldsmight be stored in more than one buffer. If the useredits such a field and closes the window, the data-base will be updated, but the old field value remainsin a buffer for another window. When that windowis closed, the old value might be erroneously writ-ten to the database. The typical solution restricts thedialogue such that only one window allows editingof the field or only one window can be used at a time.Users often find such a dialogue inconvenient.

Data retrieval. How is data for a window re-trieved? When the user opens the window, data canbe efficiently retrieved from the database to thebuffer via one or a few SQL queries.

Distribution. When a user edits a field that ap-pears in several places, the changes are not reflectedin all those places. An inconvenient “refresh”buttonor menu point in each window allows the user toupdate the window if desired.

Callback. In the simple architecture, the initiativegoes from the screen to the database, so there is nocallback. This pattern simplifies programming.

Complex business application architectureThe complex architecture systems follow the

three-layer model shown in Figure 2. The top andbottom layers are similar to those in the simple ar-chitecture, but the middle layer differs.

Database wrappers mirror the traditional data-base. Wrapper objects get data from the traditionaldatabase and write modified data back to thedatabase. They serve as convenient buffers for fastupdating of screen objects. As wrapper objectscontain only CRUD operations, they are degener-ate objects.

Observer objects link wrapper objects to screenobjects that show the wrapper data. Only one wrap-per object handles a database record, but a record

7 8 I E E E S o f t w a r e M a r c h / A p r i l 1 9 9 8

Customer Order line ProductSQL database

Customerwindowbuffer

Customer

Name:Addr:

Orderwindowbuffer

Middle layer

Screen objects (GUI objects)

Saleswindowbuffer

Save

Order Sales

NNNN Date: ddd Product: xxxddd nn NNNNddd nn NNNNddd nn NNNNddd nn NNNN

NNNN xxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxx

Figure 1. The simple business system architecture. The middle

layer consists of degenerate user objects: a buffer for each window.

The arrows show calls between objects. Notice the one-way calls.

.

might be displayed in several screen objects at thesame time. Each display of the database record re-quires an observer object. Observer objects are de-generate objects, too, as they contain only create,update, and delete operations.

Service objects provide high-level operations butdo not contain data, therefore they are degenerateobjects, much like ordinary procedures or subrou-tines. For example, an operation for registering apurchase requires three parameters: the customer,the product, and the number of items purchased.When called, the operation would create an orderline object and link it to the customer and the prod-uct. It might also perform various checks to ensureconsistency of the database.

Because wrapper, observer, and service objectsare degenerate, the complex architecture is not trulyobject-oriented. Rather, it corresponds to a tradi-tional system in which data and functionality areseparate. In practice, deviations from the pure ar-chitecture exist, and we might find a few service ob-jects with data or some observer objects with non-trivial operations.

The complex architecture is difficult to implement.It solves problems with which the simple architec-ture had difficulties, but creates other problems.

Commit. When to write data back to the databasecannot be easily determined. When a user edits afield, the result must be stored in the correspondingwrapper object, as that is the only place where datais stored in this architecture. Usually the systemwrites the value back to the database when the win-dow is closed, but in some cases the value must bewritten back immediately or when closing the lastwindow that shows the value. Writing back all thewindow fields must be done as a single transaction,but that operation is foreign to the distributed logicof an OO system. These problems complicate thelogic in screen objects and wrappers.

Integrity. With each piece of data stored only inthe proper wrapper object, the integrity problemdisappears. Two different copies of a record cannotbe accidentally written back to the database.

Data retrieval. When a user opens a window, eachfield asks a wrapper class to retrieve the necessarydata from the database. The wrapper class mightdetermine that the field is already available in an ex-isting wrapper object, or it might create a new wrap-per object and retrieve data from the databasethrough an SQL query. However, a separate SQLquery retrieves each record—or maybe each field—which can cause serious performance problems,

particularly when retrieving a long list of recordsfrom a remote database. Ideally, the necessary datamust be retrieved with one SQL query, but that op-eration is also foreign to the distributed logic of anOO system.

Distribution. The complex architecture solves thedistribution problem with observer objects. A data-base field might be shown not only as a screen fieldbut also through graphics, colors, and the graying offields. The same record might be reflected in severalscreen objects of a complex dialogue, and a singlescreen object could reflect data from several records.Observer objects implement the necessary many-to-many relationship between screen objects andwrapper objects. Special logic is needed to updatefields with aggregate data such as totals or graphi-cal curves. Provision also must be made for time-consuming updates that should be done only atuser request. An observer object should be able to


Customer Order line ProductSQL database

Customer

NameAddress. . .GetName( )UpdName( ). . .

Database wrappers

Customer

Name:Addr:

Screen objects (GUI objects)

Save

Order Sales

NNNN Date: ddd Product: xxxddd nn NNNNddd nn NNNNddd nn NNNNddd nn NNNN

NNNN xxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxx

Order line

#Items. . .Get#Name( )Upd#Name( ). . .

Observerobject

Product

NamePrice. . .GetName( )UpdName( ). . .

Update( )Purchase (customer, product, #items)

Service object

Figure 2. The complex business system architecture. The middle

layer consists of degenerate objects. The database wrappers serve

as buffers for screen updating. The arrows show calls between ob-

jects. Notice the callback from Sales through Product and the

Observer object back to sales.

.

connect any wrapper class with any screen objectclass. In C++, this connection leads to severe bind-ing problems, multiple inheritance, and a huge classhierarchy in real systems.4 In practice, developersmake more or less ad hoc solutions to all these dis-tribution problems.

Significantly, the only complete and general ar-chitecture I saw was based on SmallTalk, whichdoes not have the binding problems of C++.ObjectDesign,5 a small software house, developedand marketed the solution. They have developedseveral large business applications with their ar-chitecture. SmallTalk has a built-in distribution-observer mechanism, MVC (Model-View-Control),which is inefficient for larger systems, soObjectDesign built its own observer system. Thisarchitecture also has efficient solutions for most ofthe other architectural problems.

Callback. The initiative goes both ways: Thescreen objects call the middle layer for retrievingand updating data, and the wrapper objects call the

screen objects—through the observer objects—fordistributing changes. This situation requires carefulhandling of concurrency to avoid deadlocks andendless recursions.

Technical system architectureThe technical architecture does not use a tradi-

tional database. Instead, domain objects, which re-flect the physical system controlled by the computer,store data. Usually the domain objects are not sim-ple record structures, but highly structured data oraggregates of subobjects. The domain objects oftenhave high-level operations corresponding to somephysical action to take place. Service objects mightbe added for convenience. Observer objects can beused to distribute data changes to the screen ob-jects. As the data is found only in the domain objectsand not in a traditional database, the domain ob-jects are simpler to implement than wrapper objects.

The domain objects make the architecture trulyobject-oriented, which probably explains the suc-cess of object orientation in such technical systemsas complex equipment and process control. To someextent, analysis objects can be traced to the domainobjects, although some developers said there waslittle traceability.

The implementation of the architecture would besimple if we could ignore the distribution problem.

Commit. The system writes data back to the do-main objects as soon as the data has been edited.But even in technical systems, there might be caseswhere a group of fields must be committed at thesame time. Typically, a closed dialogue in which noother user updates of the domain objects take placesolves this problem.

Integrity. With data stored only in the domain ob-jects, two different screen copies cannot be storedback to the domain objects. However, technical sys-tems are often variations of process control systems,giving rise to another type of integrity problem:concurrent threads might try to update the samedata at the same time. This problem can be resolvedby letting the domain object do the entire updatethrough an asynchronous operation. The domainobject becomes a separate thread that can handleonly one message at a time. Alternatively, locks andsemaphores can be used.

Data retrieval. Data to be shownon the screen is simply retrievedfrom the domain objects. The per-formance penalty for retrieving thedata in several small chunks rather

than one big chunk is small compared with thetime it takes to update screen displays.

Distribution. Observer objects connect the screenobjects to the domain objects, so that a change in adomain object can be distributed to the screen ob-jects showing the data. The solution approximatesthat of complex business applications and requiresthe same careful implementation. However, thetechnical architecture faces an additional problem:how to reference data in a uniform way. In the com-plex business architecture, data in the wrapper ob-jects can be addressed uniformly because the wrap-per objects are an extract of a relational database. Ascreen object must specify a wrapper class and a keyfor the record in that class. The uniform addressesmake all observer objects similar. In contrast, datamaintained by domain objects cannot be addresseduniformly, because the data inside a domain objectcan be structured in many ways with arrays andrecords at various levels. Thus, there are even moreobserver object classes in technical systems.Furthermore, it can be difficult to extend the systemto show data in ways that cross-reference data fromdifferent domain classes. It might be necessary toextract data from inside the complex domain ob-jects, and new operations in the domain objects


In practice, developers make more or less ad hoc solutions to distribution problems.

.

could be needed for that.Callback. The technical architecture has the same

problems with two-way initiative as the complexbusiness architecture.

Would OO databases help resolve thesedevelopment problems?

Several OO researchers claimed that most of thedevelopment problems would disappear with OOdatabases. Although OO databases could reasonablybe expected to solve the integrityproblem and implement wrapperobjects, OO databases would prob-ably not solve problems with com-mit, bulk retrieval of remote data,distribution, and callback. The few groups that hadtried OO databases found performance problemswith data retrieval and immature locking mecha-nisms for multiuser databases.

Developmentand Usability

To what extent did the OO approach ease devel-opment and improve usability of the final system?

Seamless transitionIn technical systems, there was often a clear trace

from analysis to final implementation, but in thebusiness applications the object operations did nottransfer seamlessly. While the technical systems haddomain objects with nontrivial functionality, thefinal business applications consisted primarily of de-generate objects. There are three likely causes forthis difference.

♦ First, the technical systems model a physicalworld consisting of equipment with various parts.This world can be reflected as objects with a com-plex data structure, or as aggregations of objects, inwhich each object belongs to only one aggregate.Furthermore, the interface to a physical part canmap well into operations in the corresponding ob-ject. In contrast, business applications handle datathat does not aggregate naturally but relates to eachother in many ways. In an order form modeled asan aggregation of an order heading and a list oforder lines, the order lines also appear in other “ag-gregates” such as sales reports. For this reason, thebasic entities must be modeled as separate objectsand linked to several other objects.

♦ Second, because we must model the business

data in this way, we have no natural place to put ahigh-level operation such as Purchase. It could belongto the customer object, the product object, or theorder heading object. As a result, it seems convenientto avoid an arbitrary decision and instead put the op-eration in a service object, or a degenerate objectwithout data of its own. Another argument for sepa-rating high-level operations from the objects6 derivesfrom GTE’s experience with large OO systems. GTE didnot succeed until it put control flow and business

processes—high-level operations—outside class be-havior. If built into the classes involved, it was impos-sible to get an overview of the control flow. It was like“reading a road map through a soda straw.”

♦ Finally, developers with experience in tradi-tional structured analysis and structured design re-port that information models (data models) transferwell from analysis to the final system. In contrast, thefunctional aspects can be described in the analysis(as dataflow diagrams, for example) but do not trans-fer well into the final system. If this observation hasa counterpart in OO development, it might be thereason why operations in particular do not transferwell to implementation. As a trivial example, consideran operation moving a customer to a new address:

Customer.Move(newAddress)

This operation might seem natural during analy-sis, but at runtime no “Move” menu point exists.Instead, the user handles the operation by editingthe customer’s address field. In general, the usercarries out most tasks through editing or other low-level database operations.

Does this mean that true OO business applicationscannot be made? I found it telling that those devel-opers with the most experience and many successfulsystems behind them accepted the largely degener-ate models as the best solutions for business appli-cations. We seem to lack evidence for a true OO busi-ness application. Even if it exists, experienced peoplequestion whether it can be easily maintained.

User involvement during developmentTo what extent could users understand the OO

approach and contribute during development?According to some approaches,1 the analysis and


GTE did not succeed until it put control flowand business processes outside class behavior.

.

design start with object diagrams that use a nota-tion similar to the entity-relationship model shownin Figure 2. All designers using this approach re-ported that the diagrams did not make sense tousers. In other approaches,7 an object interactiondiagram shows the messages passed between ob-jects. One group reported that this gave some basisfor discussion with users, but users seemed to thinkof the boxes as functions rather than as sets of ob-jects. The diagrams were used more as traditionaldataflow diagrams.

In general, what OO analysts call objects mightnot be natural objects to users. In our example, cus-tomers might be natural objects as they performsome action, but a user is confused if we talk aboutan order as something that can perform operationsand have responsibilities.8

Some groups found that initial user involvementwas successful if based on traditional requirementspecifications, including use cases (task descrip-tions) in plain text and on a rather high level. Userscould readily comment on such descriptions andadd further tasks to be supported.9 Later user in-volvement was successful if based on prototypes,either computerized or simple paper mock-ups. Inconclusion, object orientation did not ease user in-volvement, but supplementary techniques, such asuse cases and prototypes, did.

User interfaceI have focused primarily on analysis and design

of internal system functionality, but the user seesonly the screen objects. I saw a general pattern inscreen object development for business applica-tions. In most cases, the developers had no clear ex-planation of how the screen windows were de-signed. Their attitude was that the system mustsomehow show the contents of the database.

In the actual systems, most screen windows weredatabase oriented; they corresponded to simpledatabase records or to simple records with an asso-ciated list of related records. The customer windowin Figure 2 shows a simple record in a window, whilethe order and sales report windows are examples ofrecords with associated lists. These windows can beeasily generated by many fourth-generation tools.10

Although this user interface is close to the datamodel found during analysis, it causes problemsfor the user:

Few windows for frequent tasks. Database-oriented windows might force the user to accessmany screens when carrying out a frequent task. Forexample, in a system for recording hospital patients’blood pressure and temperature—two different ob-ject types—the system used one screen for enter-ing blood pressure and another for entering tem-perature, although the measurements usually weremade at the same time.

One remedy for such problems is to design morecomplex windows in which the necessary data fora user task is collected. This remedy requires screendesigns that explicitly consider efficient task sup-port.11 OO methods combined with use casesshould have a potential for matching tasks andscreen design, but it is not current practice. Twogroups systematically made complex windows forefficient task support, but they did it as prototypeexperiments in close cooperation with users, notbased on an OO method.

Easy perception of structure. The database-oriented screen design can show a lot of data in acondensed form as lists and fields, but it is difficultto perceive patterns and structure in the data.12

Figure 3 shows an example of the list approachcompared with an approach where data forms pat-terns. The example concerns registration of timespent on various development and overhead ac-tivities. Each entry shows the activity, the date, andthe number of hours worked on that date. In thematrix presentation of the same data, it is easy tosee patterns. We can visually check that lunch is reg-


Time registration Init: MBH

Activity102 Lunch715 Design DXP812 Cust. meeting102 Lunch715 Design DXP808 Review SPA102 Lunch715 Design DXP808 Review SPA

Date290595290595290595300595300595300595310595310595310595

Hours0.54.03.00.53.04.50.55.02.5

Time registration Init: MBH Week: 22 Year: 95

Activity102 Lunch715 Design DXP808 Review SPA812 Cust. meeting901 CourseTotal

Mo0.54.0

3.0

7.5

Tu0.53.04.5

8.0

We0.55.02.5

8.0

Th

7.57.5

Fr0.53.0

3.5

7.0

Sa

4.5

4.5

Su Tot2.0

19.57.06.57.5

42.5

Figure 3. Data shown in a traditional list form and as a matrix that

enables easy perception of patterns.

.


istered every day, that certain activities take a fullday, or that work on an activity occurred every day.

The OO approach does not encourage such ef-forts. Only two of the business groups studiedpaid attention to this issue and could produce ad-vanced pictures.

Modifiability and reusabilitySystematic information about maintenance and

reuse was sparse. Many developers agreed, how-ever, that the OO design was much more completeand detailed than traditional designs they hadmade. Some also believed that the OO program waseasier to modify.

There was little experience with reuse. One groupsaid that they had expected to reuse classes in otherprojects in the company, but it turned out to be im-possible. However, the group felt that object orien-tation had allowed it to agree on concepts and ter-minology across many teams. Other groups reusedthe architecture they had developed and commonparts of the wrapper objects. The ObjectDesigngroup could reuse all the classes implementing its ar-chitecture, and marketed that package as a product.

Much work must yet be done in designing andimplementing one or more solid architec-

tures or in finding a good existing solution.However, the ideal of true object orientation pre-sented in most textbooks is unrealistic and some-times even harmful. Object orientation alone doesnot provide all the expected benefits; other tech-niques and methods must be used as well. ❖

REFERENCES1. J. Rumbaugh et al., Object-Oriented Modeling and Design,

Prentice Hall, Upper Saddle River, N.J., 1991.

2. “How To Overcome the Object Technology Learning Curve,”I/S Analyzer, M. I. Kramer, ed., Vol. 33, No. 8, Aug. 1994, pp. 1-16.

3. S. Henry and M. Humphrey, “Object-Oriented versusProcedural Programming Languages: Effectiveness in ProgramMaintenance,” J. Object-Oriented Programming, June 1993, pp.41-49.

4. A. Jaaksi, “Implementing Interactive Applications in C++,”Software—Practice and Experience, Vol. 25, No. 3, Mar. 1995, pp.271-289.

5. ObjectDesign (now DanishObject), http://www.danishobject.dk.

6. B. Maring, “Object-Oriented Development of LargeApplications,” IEEE Software, May 1996, pp. 33-40.

7. R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object-Oriented Software, Prentice Hall, Upper Saddle River, N.J., 1990.

8. M.B. Rosson and S.R. Alpert, “The Cognitive Consequences ofObject-Oriented Design,” Human-Computer Interaction, Vol. 5,1990, pp. 345-379.

9. A. Cockburn, “Structuring Use Cases with Goals,” http://members.aol.com/acockburn/papers/usecases.htm, Feb. 1996.

10. H. Balzert, “From OOA to GUIs: The JANUS System,” J. Object-Oriented Programming, Feb. 1996, pp. 43-47.

11. S. Lauesen, M.B. Harning, and C. Grønning, “Screen Design forTask Efficiency and System Understanding,” Proc. OZCHI 94, S.Howard and Y.K. Leung, eds., IEEE Computer Soc. Press, LosAlamitos, CA, pp. 271-276.

12. E. Nygren et al., “The Art of the Obvious,” CHI ’92, pp. 235-239.

Address questions about this article to Lauesen atCopenhagen Business School, Howitzvej 60, DK-2000Frederiksberg, Denmark; [email protected].

Søren Lauesen is a professor atCopenhagen Business School. Hecofounded the school’s combinationprogram in business and computer sci-ence. Lauesen’s research focuses onhuman-computer interaction, require-ment specification, object-oriented de-sign, quality assurance, systems devel-

opment, marketing and product development, andcooperation between research and industry.

Lauesen received an MSc in math and physics from theUniversity of Copenhagen and a B.Com. in business and finan-cial accounting from Copenhagen Business School. He is amember of the Danish Academy of Technical Sciences.

About the Author

.

real life object oriented systems

Documents