🚀 go-pugleaf

In article <goochb.334.0015B418@rwi.com>, goochb@rwi.com says...
>
>Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
> 
>>The OO arena is a philosophical one. I don't particularly subscribe to the 
 
>>view
>>that there ought to be a naive correspondence between software entities and
>>some ``real world'' entities,  ....
>
>Nor do I.  The (apparently widespread) idea that such correspondence 
>is in some way significant to the basis of object-oriented <whatever>
>is, IMO, a gross misconception.  Object technology has a sound basis 
>without it, and in programming, one is rarely modelling the "real world"
>directly (except in UI, when building upon spatio-temporal "real world"
>metaphors to bridge the gap between the abstractions a program is 
>based on and the user, and even then, the models used are abstract).

Many cooked examples for OO tend to use hyperbolic real world correspondence 
which leads people with superficial understanding of OOA to assume that OO 
demands modeling 'real world' objects.  In some problem domains this is 
possible and convenient, but many problem domains are abtract and have no 
real world correspondences.

OOA however should produce a nomenclature and taxonomy for the problem domain 
that permits the problem to be described to people sophisticated in the 
problem domain but not in software development (violation to this rule is of 
course when the problem domain IS software development in some form).  This 
step is fundamental to communicating elements of the problem statement from 
users to developers using common and accepted terminology (rather than the 
jargon of either community) AND to limiting communication to the problem 
domain (and NOT the solution domain -- that is, how the problem is solved 
using software).

Since sound SE demands high traceability through analysis, design, 
implementation and even testing (OO or NOT), the nomenclature and taxonomy 
should appear in later stages of software development.  One should be able to 
pick out an entity in the analysis and trace through to see how it affected 
design and implementation, or conversely to pick a piece of implementation 
and trace up through design to the analysis that motivates that software.  
IME, A&D aren't much worth pursuing when they do not produce traceability.
(The A&D then are practically throw-away, and little use to enhancing and 
maintaining the software.)

The largest problem I see in SE A&D (and we still aren't speaking 
specifically to OO) is using A&D as alternate ways of describing 
implementation.  There is very little value in this and it is often 
frustrating to developers who in fact end up producing descriptions of the 
same thing several times, only the last of which compiles.  (As with most 
things the strongest criticisms for A&D and OO and OOA&D seem to arise from 
misunderstanding and abuse, rather than inherent flaws.)  This improper level 
of abstraction also leads to throw-away A&D, because it is IMPOSSIBLE to 
synchronize a high-level description of an implementation with an actual 
implementation.

(As this suggests, it is possible to commit or learn to OO in stages, 
although it would seem to be easier to start with analysis and move to 
implementation, while unfortunately most practioners go through the reverse 
and pick up bad habits along the way.)

Now back to OO.  Given that the developer (or even better, a domain 
specialist) has produced a sound analysis of the problem domain, it is fairly 
straightforward to move through OOD and OOP by converting the nomenclature 
and taxonomy into classes and a class hierarchy.  The problem, as mentioned 
earlier, is getting a good nomenclature and taxonomy that describes the 
problem domain.  If there is no real world correspondence that suggests a 
decomposition of the problem domain, then conventions from the problem domain 
or any appropriate metaphor can be employed (most problem domains have 
conventional terminology to describe 'entities' in that domain -- finding a 
good metaphor is more challenging and might even require a degree of 
imagination and creativity in the analyst).  A common metaphor, as mentioned 
by the previous poster, is 'windows' in the GUI domain (although most 
metaphors used in software are far from pure -- what has a 'mouse' to do with 
'windows', and how did 'menus' get mixed up with either!).

Two problems seem to appear here.  First, entities from the solution domain 
appear in an analysis of the problem domain, caused by anticipation (the 
analyst is subconsciously solving the problem domain in her head even as she 
analyses it), wrong expertise (using developers with high knowledge of the 
solution domain and low knowledge of the problem domain to perform analysis), 
and re-engineering (the problem and solution domains are so interwoven in 
legacy software that they are difficult to differentiate), or recursion (the 
problem domain is connected somehow with software engineering or 
development, and so it is difficult to separate terminology from the problem 
domain and solution domain -- most often the concept of META-languages or 
META-models becomes employed to differentiate the domains).  Second, when 
metaphors must be used in analysis, the analyst becomes obsessed with the 
metaphor and detaches from the problem domain (this problem seems most common 
to people who deal mostly in abstract domains, or have a tendency to try to 
make the world fit their aesthetically pleasing theoretical models -- 
symptomatically the analyst goes looking for something in the problem 
domain to correspond to some term suggested by the metaphor).

A naive and simplistic approach to *forcing* problem domains to be described 
in terms of unrealistic real world correspondences is wrong, and adds nothing 
to software engineering.  It may be easy to derive classes and a class 
hierarchy from such an analysis, but it won't aid understanding or 
communication of the problem or its solution.  Such misapplication of OOA I 
think results most often in criticism of OOA (and then when the poorly 
thought out classes and class hierarchy are converted to implementations, OOP 
et criticized for being puerile and simplistic).

In a nutshell, any anticipation of the solution domain pollutes analysis, to 
the worst case in which analysis is nothing more than an alternate way of 
describing implementation (ditto design).  OOP should generate objects which 
correspond to entities in the problem domain and the relationships suggested 
by a well defined taxonomy, and the quality of the classes and class 
hierarchy vary directly with the quality of analysis.  Puerile and 
simplisitic analysis based on inappropriate or forced correspondences usually 
results in crippled and incomprehensible classes and class hierarchies.

--

Brad Shapcott
Lockheed-Martin's Advanced Concepts Center, Ottawa, Canada
Ph: (613) 592-8744 x227 1-800-43-TRAIN

[If some junk follows this signature, pls e-mail me -- this is the first time 
I've used this particular posting program.] 
; winvn.ini
[Personal]
UserName=dbshapco
MailAddress=dbshapco@fox.nstn.ca
Organization=iSTAR Navigator User
ReplyTo=dbshapco@fox.nstn.ca
[Communications]
UseSocket=1
NNTPHost=news.nstn.ca
SMTPHost=fox.nstn.ca
NNTPService=nntp
MailDemandLogon=1
MailForceType=2
DebugComm=1
GenSockDLL=genasync.dll
ConnectAtStartup=1
[Authorization]
NNTPUserName=
NNTPPassword=
NNTPSavePassword=0
[Preferences]
EnableThreading=1
SignatureFile=C:\NAVIGATR\NEWS\WinVn.ini
EnableSignature=1
MailLog=0
MailLogFile=MAIL.LOG
PostLog=0
PostLogFile=POST.LOG
DoList=2
FullNameFrom=1
ArticleThreshold=50
ShowUnsubscribed=1
ShowReadArticles=1
ConfirmBatchOps=1
NewWndGroup=1
NewWndArticle=0
SaveArtAppend=1
ConnectAtStartup=1
ConfirmExit=1
ConfirmReplyTo=1
CcByMail=0
ThreadFullSubject=0
GroupMultiSelect=0
ShowUnreadOnly=0
[Coding]
CodingStatusVerbose=0
DumbDecode=0
ArticleSplitLength=50000
EncodingTable=
SubjectTemplate=%s  -  %f [%p/%t]
MIMEBoundary=*-*-*- Next Section -*-*-*
BlankBeforeMIME=0
DecodePath=C:\NAVIGATR\NEWS\download
BlockCodingStatusAlwaysOnTop=0
ReviewAttach=1
AttachInNewArt=0
ExecuteDecodedFiles=0
KeepArticleHeaderVisible=0
UseSmartFiler=1
EncodingType=Base-64
GenerateMIME=1
MIMEUsageSuggestions=1
MIMEUUType=x-uue
MIMEXXType=x-xxe
MIMECustomType=x-custom3to4
DefaultContentType=Other
AlsoDecodeOpenArticles=0
MinimizeStatusWindows=0
[Interface]
ListFontFace=Courier
ListFontSize=10
ListFontStyle=Regular
ArticleFontFace=Courier
ArticleFontSize=10
ArticleFontStyle=Regular
StatusFontFace=Times New Roman
StatusFontSize=11
StatusFontStyle=Regular
PrintFontFace=Arial
PrintFontSize=12
NetUnSubscribedColor=0,0,200
NetSubscribedColor=0,0,0
ArticleUnSeenColor=0,0,0
ArticleSeenColor=0,0,200
ArticleTextColor=0,0,0
StatusTextColor=0,0,0
ArticleBackgroundColor=255,255,255
ListBackgroundColor=255,255,255
StatusBackgroundColor=255,255,255
ThumbTrack=1
WinVnFontFace=MS Sans Serif
WinVnFontSize=8
WinVnFontStyle=Bold
CompositionFontFace=Courier
CompositionFontSize=10
CompositionFontStyle=Regular
UseInverseSelections=0
[winvn]
Notice1=**** The [winvn] section is no longer needed unless    ****
Notice2=**** you want compatibility with old versions of WinVn ****
[Admin]
Newsrc=C:\NAVIGATR\NEWS\NEWSRC
Version=WinVN 0.93.14
[Searches]
LastArticleTextFind=
LastArticleHeaderFind=
LastGroupNameFind=
[Smart Filer]
OnDupeName=0
OnNameTooLong=0
MaxFileNameLen=8
MaxFileExtLen=3
EnableExtensionConversion=1
[Mail Addresses]
Address1=dbshapco@fox.nstn.ca
[Logging]
MailLog=0
MailLogFile=MAIL.LOG
PostLog=0
PostLogFile=POST.LOG
[Confirmation]
ConfirmBatchOps=1
ConfirmDisconnect=0
ConfirmSaveOnExit=0
ConfirmReplyTo=1
[Group List]
DoList=2
ShowUnsubscribed=1
GroupListMultiSelect=0
UsenetWindowPos=0,0,400,540
[Article List]
ArticleThreshold=50
MinArticlesToRetrieve=50
FullNameFrom=0
EnableThreading=1
ShowUnreadOnly=0
NewWndGroup=0
ThreadFullSubject=0
ThreadDepthIndicator=
SaveArtAppend=1
ArtListMultiSelect=1
GroupWindowPos=1,0,800,300
[Article]
NewWndArticle=0
WrapIncomingArticleText=0
WrapIncomingArticleTextLength=80
TrimHeaders=1
ScrollPastHeaders=1
ItalicizeQuotes=1
ArticleWindowPos=130,259,640,362
[Compose]
WordWrap=1
PrefillCcAddress=1
ShowOrgHdr=0
ShowReplyToHdr=0
ShowKeywordsHdr=0
ShowSummaryHdr=0
ShowDistributionHdr=0
ShowFromHdr=0
FollowupSaysTemplate=In article %i, %a says...
ReplySaysTemplate=In article %i, you say...
SignatureFile=C:\NAVIGATR\NEWS\WinVn.ini
EnableSignature=1
[Attachments]
DefaultAttachInNewArt=0
ArticleSplitLength=50000
SubjectTemplate=%s  -  %f [%p/%t]
GenerateMIME=1
MIMEUsageSuggestions=1
MIMEBoundary=*-*-*- Next Section -*-*-*
MIMEUUType=x-uue
MIMEXXType=x-xxe
MIMECustomType=x-custom3to4
DefaultEncodingType=Base-64
DefaultContentType=Other
EncodingTable=