Jan Bosch 3
Departmentof Computer Scienceand BusinessAdministration
Universityof Karlskrona/Ronneby
S-372 25, Ronneby,Sweden
E-mail: Jan.Bosch@ide.hk-r.se
WWW: http://www.pt.hk-r.se/~b osch
Abstract
Programminglanguagesandsoftwareengineeringmetho dsarehighlyrelatedinthatb oth
areimagesofanunderlyingparadigm. Inthispap erweinvestigatetheroleoftheparadigm,
thelanguagemo delandthesoftwaredevelopmentmetho dand de nerequirementsoneach
of the three concepts. Subsequently, we describ e the layered object model, an extended
object mo del which allows for rst-class representation of relations b etween objects and
constraintsontheb ehaviourofanobject,anddiscusshowitachievesparadigmextensibility,
i.e. extensibilityoftheparadigmandthesupp ortinglanguagemo del.
1 Introduction
Wheninvestigatingtherelationb etweenprogramminglanguagesandsoftwareengineeringmeth-
o ds one cannot avoidplacing this in a larger context. This context consists of the underlying
paradigm applied by the software engineer when mo delling a part of the real world, i.e. his
problem. Wede nea paradigmasarelatedsetofconceptswhich areusedtomo delpartof the
real world. The paradigm used bya softwareengineer is like the `glasses'he wearswhen mo d-
elling thereal world. Forexample, asoftwareengineer applying thefunctional paradigm views
his problem in terms of dataelementsand functions. However, a softwareengineer working in
anobject-orientedmannerwillviewthesameproblemintermsofobjectsandrelationsb etween
objects. Theparadigm applied bythesoftwareengineerplaysacentralrole inthewaysoftware
is constructed.
Inthis pro cess,wecan recognise severalmo dellingactivities. First,theunderlying paradigm
de nes a meta-mo del of thereal world, i.e. it de nes a set of conceptswhich are instantiated
bythesoftwareengineerwhen makinga mo deloftheworld. Referringtothepreviousexample,
the software engineer might have the concept object as part of the paradigm he uses, which
enables him to mo del an entityrecognised during the development pro cess as an object. The
softwareengineermusthavethis conceptaspartoftheparadigmheapplies, otherwisehewould
b eunableto`instantiate'it. Asin anyscience, thewayasoftwareengineerp erceivesrealityisa
modelof reality: it isnot realityitself. This iswhatmetaphysicsis tryingto makeus awareof:
ahumanb eing canneverp erceiverealityasawhole. Hemakesaselection, oranabstraction,of
theoverwhelmingamountofsensoryinformationandasso ciatespatternsofsensoryinformation
with concepts. In the same way this pro cess of p erception is a mo dellin g activity within the
3
Thisworkhasb eensupp ortedbytheBlekingeForskningsstiftel se.
frame of a cultural paradigm, is the mo delli ng of software bya software engineer a mo delling
activitywithin theframeofhis paradigm.
The second mo delli ng activity is the development of a programming language model sup-
p orting the paradigm as a, p ossibly executable, language which can conveniently express the
real-world mo del de ned by the software engineer when developing an application. The pro-
gramming language mo del again is a mo del, a re ection of the paradigm. For example, it is
therefore thatitisadvantageoustoimplement theresultof object-oriented analysisand design
in an object-oriented language. It can, up to a certain extent, also b e implemented in a third
generation language, but that language do es not re ect the object-oriented paradigm. This
requires the software engineer to translate the object-oriented mo del into a functional mo del
b efore it can b e implemented. In this case it is the software engineer who has to cover the
semantic gap b etweentheparadigms.
The third mo delling activity isthe developmentof amethod,i.e. the result ofmetho dology,
the science of metho ds, supp orting the development pro cess p erformed by the software engi-
neer. The metho dalso is are ection of theparadigm in that it, generally,de nes steps forthe
identi cationand sp eci cation ofinstances oftheconceptsthatarepart oftheparadigm. Con-
ventionally,metho dsoftende ne alternativemo delsthatcapturerepresentationsoftheproblem
domain that can not b e expressed in the programming languagemo del, but do havesome se-
mantics. Examplesof this aredata- and control- owdiagramsin thestructured metho ds.
In gure1,therelationb etweentheparadigm,thelanguagemo delandthemetho disshown.
Boththelanguagemo delandthemetho daremo delsoftheparadigmandhaveapassive(ellipse)
and an active(square) form. Forinstance, when de ning metho d, the metho d itself is passive
(ellipse). However, when the metho d is applied during application development themetho d is
active (square). This principle extends to theapplication. The application is rst de ned and
afterwardsitisactivated,indicated bytheellipseand squarerepresentationsoftheapplication.
2 e ole of t e aradig
Weuse theterm `paradigm'torefer toaset of related conceptswhich areusedbya p erson to
p erceivetherealworldorapartofit. Withinsoftwareengineering,thismeansthatthesoftware
engineeruses theconcepts within hisparadigm top erceivehis problem domain.
itsuseinphilosophy. Forexample,in[11]aparadigm isde ned as`auniversallyacceptedsetof
presupp ositions'. We generally are unaware of theparadigm, according to philosophy,b ecause
we are so familiar with our basic presupp ositions that we do not knowthem. It is only when
science changes its paradigm, e.g. the transition from Newtonian to Einsteinian mechanics,
that one b ecomes aware of his underlying paradigm. The collapse of a paradigm is, generally,
caused by an increasing set of anomalies asso ciated with that paradigm. Anomalies, in this
context,refer toasp ects of the studied domain that cannot b e expressed (conveniently)in the
paradigm. Scientists b ecome increasingly unsatis ed with the existing paradigm and a new
paradigm,chancelessduring the`normalscience' phase(see[9]),replaces theoldparadigm. The
new paradigm, although it might use some of the same terminology, replaces the whole set of
presupp ositions and it cannotb eb eexpressed in terms oftheformer.
Incomputerscience, thedi erentparadigms,orscho olsofthought,havereplacedeachother
relatively quickly. Also, weneverhad a situationwhere alarge majorityofcomputer scientists
acceptedaparadigmwithoutb eingawareofalternatives. Web elie veitisthereforethatsoftware
engineers are moreawareof their `presupp ositions'than their counterparts in, e.g. mechanical
engineering. Nevertheless,it still provestob e verydicult to re ectup on ones paradigm and
torecognise anomalies oftheparadigm.
The paradigmisthecommonfactorin analysis, designand implementation. Duringthehis-
toryofsoftwareengineering, onecan viewacirculardevelopmentinwhich rstanewparadigm
oraparadigmshiftisde ned,thenaprogramminglanguagesupp ortingthisnewparadigmisde-
ned and subsequently,a metho d(or metho dology)isde ned tosupp ort softwaredevelopment
based onthenew paradigm.
2.1 istorical verview of Paradigms in Software Engineering
The rst `real'paradigm werecognise is thefunctional approachtosoftwaredevelopmentwith
metho dsde nedby,amongothers,[10]. Inthisparadigmtheemphasisisonthesystemfunction
which isorganised asa hierarchyof functions(or pro cesses)connectedbydata ows.
The second paradigm| p erhapsb etter describ ed asa paradigmshift | istheentity-based
structured approachof which JacksonSystem Development(JSD) [7] is a go o d example. Ex-
p erience had shown that it wasnot sucient to fo cus only on functions, i.e. anomalies of the
functionalapproachwereidenti ed. Inthisnewparadigm,therefore,thedesignerfo cussedb oth
on relevantentities, in the system and on the system functions. However,these two werestill
seen as two separate dimensions, i.e. entities were structured but unencapsulated data and
functions werestill global.
The third paradigm, which is currently state of the art in industry, is the object-oriented
paradigm. Again,anomalies withtheprevious paradigmlead toa softwareindustry-wide frus-
tration which created the basis for intro ducing a new paradigm. Using the object-oriented
paradigm,theworldismo delled in termsofobjects,incorp oratingb oth dataandop erationson
that data. These objects represententities that are,by humans, p erceived asrelevant entities
in thereal world.
The general line of development, as one recognises, is that the paradigm used to make a
mo del of the real world has moved away from its ro ots in mathematics and shows more and
more resemblance with the way,we b elieve, humans to make a cognitive mo del of the world.
It seems that in the subsequent paradigms the semantic gap, referred to by several authors
e.g. [6], is decreasing. Also research from cognitive psychology, e.g. [12], indicates that the
object-oriented paradigmindeed mightb emoreintuitive thanconventionalapproaches.
Theobject-orientedparadigm,asanyparadigm,isnotthep erfect solution. Someauthorshave
identi ed anomalies or obstacles of the conventionalobject-oriented mo del, e.g. [1]. However,
assumingthedevelopmentofnewparadigmsdo esnotstopwithobjects,whatistob eexp ected?
nedirection aretheextended objectmo dels,which areobjectmo dels providingsomeform
of re ection. Re ection is de ned as the ability of a system to reason ab out and act up on its
internal representation. Examples of extended objectmo dels are L [8], comp osition- lters
objectmo del[2]andthelayeredobjectmodel(layom). Thelatterobjectmo delwillb eaddressed
in moredetailin section3.
In this section, we havefo cussed on the main-stream paradigms. We delib e rately excluded
less common approaches, like the `real' functional languages, e.g. iranda and L, or the
languages based on rst-order logic, e.g. rolog. Also, we did not address current, AI-based
approaches,like agent-oriented programming.
2.2 he Set of elated once ts
In theintro duction we de ned a paradigm as a set of related concepts. But whatconcept sets
are related to the paradigms discussed in the previous section? For the functional paradigm,
relevantconcepts include unction,variable and data ow. However,the unctionwasthe most
imp ortantconcept around which themetho dand theprogramming languagecentered.
Theentity-based,structuredparadigmconsistsofconceptslikeentity, unction,datastructure
anddata-andcontrol- ow. Theentityandthe unctionwereequallyimp ortantandwereviewed
astwoorthogonaldimensions ofthe system.
Theconventionalobject-orientedparadigm|wewilldiscussthisparadigmin moredetail|
consistsprimarilyofthefollowingconcepts: object,method,instancevariable(ornestedobject),
message,inheritanceand class.
Despiteourdescription,aparadigmisgenerallyonlyde nedabstractly. Itismorethroughits
representations,i.e. theprogramminglanguageandthedevelopmentmetho d,thattheparadigm
implici tlyisavailable. However,whenweinvestigatetheprogramminglanguagemo delsand the
metho ds forthevariousparadigms,weseethatoftenthesupp ortedsetsofconceptsarenotthe
equivalent. enerally,the programminglanguage supp ortsa subsetof the concepts supp orted
bythemetho d. Intable 1,weshowtheconcepts relatedtoeachparadigm.
Concluding, wecanstatethatthesoftwaredevelopmentpro cesscan b eseenasatranslation
of a part ofthe real world,consisting of a largeset of weaklyde ned, i.e. p ossibly ambiguous,
concepts into a mo del, expressed in the languagemo del, consisting of a very small set of very
precisely de ned concepts. The paradigm,in this view,is anintermediate representation,used
bythesoftwareengineer, consisting of a set in b etweenthe real-worldand the languagemo del
b oth in size and in thepreciseness in which eachconcept isde ned.
2. e uirements
Basedontheinterpretationpresentedinthispap er,anumb erofrequirementsup ontherelevant
entities insoftwaredevelopment,i.e. theparadigm,languagemodelandmethod,can b ede ned.
The general requirement is that the mo del in which the software engineer has to express his
application shouldb e asclose asp ossible tothewaythesoftwareengineer p erceives theworld.
The ab overequirement we b elieve tob e the main requirementof the paradigm usedby the
softwareengineer. We b elie ve the softwareengineer, as a human b eing, to p erceive the world
developmentmetho d languagemo del
functional
pro cess (function) function
data ow variable
variable
structural entity mo dule
pro cess function
relation structuredtyp e
data/control ow
abstractdatatyp e
object-oriented object object
message message
class class
reuse inheritance
metho d metho d
nested object instance variable
relations
constraints (e.g. concurrency)
Table1: Relation b etween aradigmsand Concepts
using a meta-mo del containing a largeset of concepts which often are weaklyde ned. During
softwaredevelopment,the softwareengineerhastoconvertthedomainashep erceived itusing
his p ersonal knowledge, into a mo del de ned by the concepts that are part of the paradigm.
From this view on the design pro cess we can deduce two requirements. First, the paradigm
should b e asclose asp ossible tothe waythesoftwareengineer p erceivesthe world,but not so
close thatitloses therequired preciseness ofthe concepts. Donotethatthe paradigmdo es not
havetob e unambiguous. Second, thesoftwareengineer should b eable toevolvetheparadigm,
i.e. extend the paradigm with new concepts and remove or rede ne existing ones. From the
historical overview we have learned that no paradigm, by itself, is a complete solution. It is
nothing but a `wor ing hypothesis' which is replaced when a b etter is found. Therefore, in
anticipationof extensions and changestotheparadigm, weshould explicitlysupp ort this.
Therequirementsrelatedtothelanguagemodelcanb eexpressedasfollows. Asthelanguage
mo delitselfisamo delfromtheparadigm,itshouldb easaccurateasp ossible. Accurate,inthis
context,meansthateachconcept partof theparadigm should relateto(exactly) onelanguage
mo del element. From this, a second requirementcan b e deduced: the language mo del should
b eextensible in order tore ectextensions and changestothe paradigm.
Finally,themethodalsoisare ectionoftheparadigm,butisalsoin uencedbythelanguage
mo del. The metho d is apro cess descriptionof thetransformationof thepart of thereal-world
into the language mo del. The metho d should supp ort the software engineer while expressing
the problem at hand in terms of the paradigm. enerally, this means the identi cation and
the sp eci cation of instances of concepts that are part of the paradigm and an ordering on
the identi cation of di erent concepts. Also the metho d should b e extensible to incorp orate
paradigm extensions.
Asdescrib ed in section2.1 theobject-oriented paradigmcurrently isthestateof theart in the
softwareindustry. ur research e ort, atthe Universityof arlskrona/Ronnebyin Sweden,is
to investigatetheconventionalobject-oriented paradigm in order to identify anomalies and to
prop oseevolutionaryextensions totheconventionalparadigmthatmightresolvetheanomalies
that we identi ed. ur research includes identi cation of anomalies related to the paradigm,
thelanguagemo del and thedevelopmentmetho d.
In the remainder of this section, we rst describ e our language mo del. Then we describ e
how weachieve paradigm extensibility, i.e. howthe softwareengineer can extend thelanguage
mo del. In thelastsubsection, ourapproachtode ning developmentmetho ds and toproviding
automatedsupp ort isdescrib ed.
.1 a ered ect odel
The languagemo del that we use as a `test vehicle'is layom, the layered object mo del, which
extends the conventional object mo del by encapsulating it with layers. A layer can, among
others, represent a relation with another object or a constraint, e.g. a concurrency or a real-
time constraint, on the b ehaviour of the object. To express a certain typ e of b ehaviour, e.g.
partial inheritance, a layerof typ e artial nheritanceis de ned and con gured to provide the
requiredb ehaviouroftheobject. Thesoftwareengineerisabletode nenewlayertyp esanduse
theminterchangeablywithother,prede ned,layertyp es. Donotethatthisisdi erentfromthe
conventional class de nition and instantiation. When de ning a new layertyp e, the software
engineerextendstheobjectmo delitsel ,i.e. theexpressivenessoftheobjectmo delisincreased.
Whende ninganewclassin theconventionalobjectmo del,theobjectmo delitselfremains the
same.
Thelayeredobjectmo del (layom)isanextendedobjectmo del,i.e. ittakestheconventional
objectmo delasabasisandextendsthattoimprovetheexpressivenessofthemo del. Anobject
in layom consists of ve major comp onents, i.e. variables (nested objects), methods, states,
conditions and layers. layom do es not supp ort inheritanceas a part of the mo del, but deals
withinheritance,delegation,part-o and manyother typ esof relationsb etweenobjects through
layers.
Thelayersencapsulatetheobjectsuchthatmessagessenttotheobjectorsentbytheobject
itself havetopass all layers. Eachlayercan change,delay,redirect or resp ondto a messageor
just let is pass. Currently we use layers for(1) representing relations the encapsulated object
has with other objects and (2) to de ned constraints on the b ehaviour of the object. Below,
layersarediscussed in moredetail.
The variables of the object arenested objects within the objectin which they are declared.
ariables aswellasmetho ds of theobjectarede ned asin most objectorientedlanguages.
A state,asde ned in layom,is adimension of the, externallyvisible, abstractobjectstate.
Eachdimension has a domain and the state expression `maps' the concrete object state (or a
partofit)tothedomainasso ciated withthestate. layomalsosupp ortsactive states. An active
state is de ned based on the static abstract statede ned for the object and can b e seen as a
derivate function of (a part of) the static abstract statein time. Client categories arede ned
in layom using conditions. A condition, just as a state, can b e seen as a sp eciali sation of a
metho d. A condition has a single (invisible) argumentmsg, which is themessage for which it
is determined whether its sender b elongs to the client category de ned by the condition. The
returnvalueoftheconditionisrestrictedtoclassboolean. Wereferto[ ]foradetaileddiscussion
ab out states andconditions.
The layers are the central concept in layom. As mentioned, a layer can mo del a relation
b etweentheobjectandanotherobjectoraconstraintontheb ehaviouroftheobject. Examples
of relation typ esthatcan b edirectlyrepresentedbya layerinclude inheritance,delegationand
part-o but also application sp eci c relations aswor s-or andis-author-o .
ayers can b e used to restrict access by certain clients but also to extend the interface of
theobject. Forinstance,a layerof typ e onditioncan b eused tode ne anew client category
which was not de ned within the object itself. From the p ersp ective of a layer, it makes no
di erencewhetheritisinb etweenotherlayers,themostouterorthemostinnerlayer. Aobject
is de ned suchthat attheoutsideof eachlayer,one `sees'an objectwitha interfaceconsisting
of metho ds,states andconditions.
A messagethatis senttotheobjecthastopassthelayersencapsulatingtheobject,starting
at the outermost layerand working his wayin. Each layerreceives the messageand insp ects
it in order todetermine whatit will do with themessage. A layercan delay the messageuntil
somepreconditionisful lled oritcan changethemessagecontents. ther p ossibil iti es arethat
the layer itself replies to the message or that it rejects the message, generating an exception.
Basically, each layer object has the opp ortunity to handle a message in virtually any way it
likes. However, in practice, a layer will just pass most messages on tothe next layerand only
interceptasubsetofthemessages. In gure2thestructureofanobjectin layomisillustrated.
Analogous to a messagesent tothe object, a messagesent by the objecthas topass all the
layers starting at the innermost layer. Again, each layer has the p ossibili ty to treat outgoing
messagesinanywayitseesappropriate. Donotethateachlayer,eitherinresp onsetoamessage
itneedstoevaluateorotherwise,can sendmessagestotheobjectitencapsulates. Forinstance,
a layercan request thevalue ofa stateora condition.
.2 E tending the ect odel
The original rationale for de ning the layered object mo del was to provide the object mo del
with theability of expressing relations b etween objects as rst-classentities. We consider this
veryimp ortantb ecause object-orientedmetho ds explici tlymo delrelations b etweenobjectsand
classify theserelations,i.e. giveeachrelation a certaintyp e. However,theconventional object-
orientedmo delonlysupp ortstheinheritanceandthepart-o relationwithinthemo del. Allother
relationsidenti ed duringanalysis anddesign havetob eimplementedon topo themo del, i.e.
implemented asmetho dco de and messagesends.
As describ ed in section 2.3, we b elieve that the language mo del should b e capable of rep-
resenting the concepts that are de ned within the paradigm. Thus, also relations should b e
layom allowsthe de nition of relations b etweenobjects aslayers encapsulating one of the ob-
jects. Also, the softwareengineer is able to de ne new layertyp es and use them as anylayer
typ e.
However,from thefurtherinvestigationofthelayeredobjectmo delwehavelearned thatthe
layer mechanism o ers a second, very imp ortant feature: extensibility o the paradigm itsel !
If the softwareengineer de nes a new layer typ e, then the object mo del is basically extended
b ecausethe b ehaviourde ned in the newlayertyp e,e.g. a relation typ e, which rst hadtob e
expressedontopofthemo delcannowb erepresentedwithinthemo delasa rst-classentity. An
analogywouldb etheimplementationofan object-orientedapplication usingathird generation
language. In that languagethe softwareengineer hasto express objects, messages,etc. on top
of the language, whereas in an object-oriented languagethese can b e expressed directly in the
language.
Therefore, we b elie ve tohave de ned a language mo del which supp orts extensibili ty of the
paradigm and the language mo del. Whenever the software engineer, as a result of re ective
thinking ab outtheunderlying paradigm,identi es anew concept thathadnotb een recognised
b efore, this new concept can b e adopted in the conceptual paradigm and extend thelanguage
mo del witha newlayertyp ethatimplements theb ehaviourof theconcept.
. evelo ment ethod
Therole of thedevelopmentmetho distoguide thesoftwareengineerin themo delling pro cess.
The real-world problem has to b e expressed in terms of the concepts in the paradigm and
the pro cess of achieving consists of a numb er of steps or phases. For instance, generally an
object-orientedmetho dconsistsofthefollowingsteps(1)requirementsanddomainanalysis, (2)
object and subsystem identi cation, (3) relation identi cation, (4) structuresp eci cation and
( )b ehavioursp eci cation. Thesesteps arep erformedin a sequentialorder, but iterations can
o ccuratanyp oint and donotnecessarily restartatthe rst step.
However, this typ e of development metho d is de ned from the p ersp ective of the software
engineer. This approach seems the most natural one from a conventional p ersp ective, but
we b elieve it not to b e the optimal approach. Esp ecially when developing complex and large
applications usingautomatedsupp ortforthedevelopmentpro cess,wehaveidenti edproblems
withtheconventionalsoftwareengineercentereddevelopmentpro cess. In[3],wedescrib e three
problems:
unctional approach to automated support: The conventional development metho d, de-
scrib ed ab ove, can b eseen as analogousto thethe functional paradigm in programming.
Hence,theto ols forautomatedsupp ort canb eseenasfunctionsop eratingonthepassive,
data-like design artifacts in which the analysis and design mo del is kept. This results in
problems analogoustotheproblemsthefunctionalparadigm hasinprogramming,i.e. (1)
lack of controlled accessto design artifacts, (2)artifacts changes haveglobal impact and
(3)changes tothemetho dologyare dicult toimplement.
Lac o initiative by the system: This `functional' approach toautomated supp ort leads
to the situation where the initiative always is on the side of the software engineer. The
paradigmdo esnotfacilitateconsequentautomationand,generally,theautomatedsupp ort
environmentdo es notprovideprocesssupport.
ausalconnectiongap: Intheconventionalapproachitisverydiculttomaintainacausal
connectionb etween the design artifactand a partof the application. The term `causally
b etween an entity and its meta-level representation. In the context of this pap er, this
referstothecausal connectionb etween anobjectin anapplication and its corresp onding
design artifact. roblemsresultingfrom thecausalconnection gaparethat(1)thedesign
rationale for an entity gets lost, (2) lack of control byan entity when b eing de ned and
(3)relation b etweena concept and its implementation disapp ears.
Inorder toaddresstheseproblems, ourapproachtoautomatedsupp ortistheopp osite from
the conventionalapproach. Rather than de ning a development metho d from the p ersp ective
ofthesoftwareengineer, wede ne itfromtheperspectiveo thedesignartiacts,i.e. theentities
under development. The development metho d is not de ned as one large description, but is
decomp osed into small development metho ds for each design artifact typ e. A design artifact
typ ecorresp onds,inour approach,toaconcept in theparadigm. Thus,foreachconcept in the
paradigm,thedevelopment stepsareexplicitl y de ned.
Each instance of a design artifact typ e (or concept) is an active object (or agent) that is
resp onsible forde ning itself and it communicateswith other design artifactobjects tocollect
informationconcerningitselfanditscontext. A designartifactobjectalwaysp erformsthesteps
in itsdevelopmentmetho dforwhich iscancollect sucient information. Ifcertaininformation
concerningtheobjectislacking,itturnstothesoftwareengineertorequestforthisinformation.
The ab ovedescription is verybrief and werefer to[3]for amoredetailed description. How-
ever,ourapproachtodevelopmentmetho dsand automatedsupp ortforthese metho dsdo es not
su er from the describ ed problems, b ecause (1) it is based on the object-oriented paradigm,
rather than on the functional paradigm, (2) each design artifact object will p erform as much
activities as p ossible b efore turning to the software engineer and (3) a design artifact object
corresp onds to exactly one concept in the paradigm, which is also an entity in the language
mo del.
onclu ion
Wehavediscussedtherelationb etweenthelanguagemo delandthesoftwareengineeringmetho d
and have recognised that it is the underlying paradigm which is the major factor. Both the
language mo del and the development metho d can b e viewed as re ections of the paradigm
used by the softwareengineer. Their quality is determined by the accuracy of the resp ective
`re ections'.
Based on this p ersp ective wediscussed thedi erent paradigmsthathistorically haveplayed
animp ortantrolein softwareengineering andconcludedthatthesubsequentparadigmsseemto
moveawayfrom their mathematical ro ots and b ecome closer tothe wayweb elieve humans to
p erceivetheworld. However,itisunrealistic toassumethatthedevelopmentofnew paradigms
willstopto dayandwementionedsomep ossibledevelopments. Toprovideguideli nes, wede ned
requirements that the paradigm, the language mo del and the metho d have to ful ll . These
requirements canb e summarisedasaccuracyand extensibility.
urapproachtoinvestigatingtheexpressivenessofobjectmo delsisthelayeredobjectmo del
(layom),anobjectmo delthatextends theconventionalobjectmo delwithlayersencapsulating
the object. These layerscan express relations, constraints and other typ es of b ehaviour of the
object as rst-classentities.
A secondimp ortantprop ertyof layomisthatit facilitatestheextensibili ty oftheparadigm
itself. The softwareengineeris able tode ne newconcepts and addthem tothelayeredobject
mo delintheformofnewlayertyp es. Weexp ectthatonlyacertainclassofparadigmextensions
we plan to investigate is related to design patterns. We b elieve it to b e p ossible to express
design patterns as rst-class entities, preferably layer typ es, within the object mo del. This
would facilitate averynaturalimplementation of a design patternbaseddesign in layom.
ur approachtode ning developmentmetho ds andproviding automatedsupp ort isuncon-
ventionalin that we de ne a development metho d from the p ersp ective of the design artifact.
Eachtyp eofdesignartifactreferstoaconcept intheparadigm. Thisapproachavoidsproblems
asso ciated withconventional,softwareengineercenteredapproaches.
c nowledgements
I wouldlike tothank ennart hlssonand Berthel Sutterfortheir commentson this pap er.
eference
[1] . Aksit, . Bergmans, \ bstacles in bject- riented Software Development," -
L ' roceedings,pp.341-3 8, ctob er 1992.
[2] . Bergmans, \Comp osing Concurrent bjects," h issertation, Department of Com-
puter Science, Universityof Twente,The Netherlands, 1994.
[3] J.Bosch,\SoftwareArtifactsasAutonomousAgents,"submittedtothe th nternational
onerenceon o tware ngineering - .Also ResearchRep ort6/94,Universityof
arlskrona/Ronneby,Septemb er1994.
[4] J. Bosch, \Relations as First-Class Entities in layom," or ing paper, Department of
Computer Science and Business Administration,Universityof arlskrona/Ronneby, cto-
b er 1994.
[ ] J. Bosch, \Abstracting bject State (preliminary title)," or ing paper, Department of
Computer Science and Business Administration,Universityof arlskrona/Ronneby, cto-
b er 1994.
[6] . Bo o ch, bject riented esign with applications , Benjamin/Cummings ublishi ng
Company,Inc.,1990.
[7] .Jackson,\SystemDevelopment," rentice all,1983.
[8] . ickzales, J. desRivieres,D. .Bobrow, he rto the etaobject rotocol,The IT
ress,1991.
[9] T.S. uhn, he tructureo cienti c evolutions,TheUniversityofChicago ress,1962.
[10] T.De arco,\StructuredAnalysis and System Sp eci cation," rentice-Hall,1979.
[11] I. arkova,\ aradigms,Thought,and anguage,"JohnWiley Sons td.,1992.
[12] .B. Rosson, S.R. Alp ert, \The Cognitive Consequences of bject- riented Design,"
uman- omputer nteraction, olume ,pp.34 -379,1990.
