scispace - formally typeset
Search or ask a question
Journal ArticleDOI

A brief history of the object-oriented approach

01 Mar 2003-ACM Sigsoft Software Engineering Notes (ACM)-Vol. 28, Iss: 2, pp 6
TL;DR: The road towards an object- oriented approach is described and several object-oriented programming languages are reviewed and a survey and a classification scheme for object oriented methodologies are presented.
Abstract: Unlike other fads, the object-oriented paradigm is here to stay. The road towards an object-oriented approach is described and several object-oriented programming languages are reviewed. Since the object-oriented paradigm promised to revolutionize software development, in the 1990s, demand for object-oriented software systems increased dramatically; consequently, several methodologies have been proposed to support software development based on that paradigm. Also presented are a survey and a classification scheme for object oriented methodologies.

Summary (2 min read)

1. INTRODUCTION

  • Over the past three decades, several software development methodologies have appeared.
  • Due to the increasing popularity of object-oriented programming, in the last twenty years, research on object-oriented methodologies has become a growing field of interest.
  • It has the goal of isolating those aspects that are important for an understanding of the application, and also suppressing those aspects that are irrelevant.
  • The trend to object-oriented graphical interfaces is evident in many areas of software development; experience suggests that user interfaces are significantly easier to develop when they are written in an object-oriented fashion.
  • If a good library of reusable components exists, browsing components to identify opportunities for reuse should take precedence over writing new ones from scratch.

2. THE BACKGROUND OF THE OBJECT-ORIENTED APPROACH

  • The notion of “object” naturally plays a central role in objectoriented software systems, but this concept has not appeared in the object-oriented paradigm.
  • The term “object” emerged almost independently in various branches of computer science.
  • Units of knowledge called frames, used for knowledge representation.
  • Simula was initially developed as a language for programming discrete-event simulations, and objects in the language were used to model entities in the real-world application that was being simulated.
  • Research on Smalltalk has continued and the Smalltalk language and the environment were by-products of that project.

3. CHARACTERISATION OF AN OBJECT-ORIENTED MODEL

  • There were many definitions about what precisely the term objectoriented meant.
  • The term meant different things to different people because it had become very fashionable to describe any software system in terms of object-oriented concepts.
  • Rentsch [10] defines object-oriented programming in terms of inheritance, encapsulation, methods, and messages, as found in Smalltalk.
  • The object-oriented paradigm was still lacking a well-known and profound theoretical understanding, then some research come out in this area.
  • Objects are autonomous entities that have a state and respond to messages; classes arrange objects by their common attributes and operations; inheritance serves to classify classes by their shared commonality.

4. COMPARISON BETWEEN “OBJECT-ORIENTED” LANGUAGES

  • At the beginning of programming language development, assembly languages only enabled programmers to write code based on machine instructions that manipulated the contents of memory locations .
  • Therefore the level of control and data abstraction achieved was very low.
  • Abstract data types are abstractions that may exist at a higher level than operands and operators, or variables and procedures separately.
  • The prominence of the object-oriented paradigm has influenced the design of other programming languages.
  • Concurrency adds the idea of simultaneously executing objects and exploiting parallelism.

5. CLASSIFICATION OF OBJECT-ORIENTED METHODOLOGIES

  • An important idea brought forward by software engineering is the concept of software life cycle models.
  • This process of refinement was known as the functional decomposition approach.
  • During the requirements and analysis phases, data flow diagrams, entity-relationship diagrams and a data dictionary are used to logically specify a software system.
  • Structured analysis appeared to be an attractive starting point to be followed by object-oriented design primarily because it was well known, many software professionals were trained in its techniques, and several tools supported its notations.
  • On the other side, there has also been a profusion of so-called “object-oriented” methodologies for analysis and design influenced by different backgrounds, and found in a variety of software life cycle models.

5.1 Adaptation

  • Adaptation proposes a framework to mix an object-oriented approach with existing structured methodologies.
  • These methodologies were used during a period of transition from structured development to object-oriented development as a compromise.
  • They did not permit the full advantages of an object-oriented approach.
  • Lastly, Alabiso [55] and Ward [56] combined object-oriented development with Structured Analysis [43], Structured Design [37] and the Entity-Relationship Model [41].
  • Many ideas about object-oriented design came out with the work of Abbott [57] and Booch [58].

5.2 Assimilation

  • In the 1980s and 1990s several object-oriented methodologies appeared but they covered only partially the software life cycle model.
  • Jacobson [70] claimed to have a full object-oriented development methodology named the ObjectOry, which combined a technique to develop large software systems termed block design [73] with conceptual modeling [74] and object-oriented concepts.
  • Jacobson stated that it was quite natural to unite these three approaches since they rely on similar ideas aiming at, among other things, the production of reusable software components.
  • Responsibilities are a way to apportion work among a group of objects that comprise a real-world application.
  • Introduced by Beck and Cunningham [75], was a technique that recorded design on cards, and which proposed the Class, Responsibility, and Collaboration (CRC) cards.

6. FINAL REMARKS

  • This paper has expanded upon the background of the objectoriented paradigm.
  • This is evident in the abundance of tools supporting all aspects of software development following this paradigm.
  • Object-orientation has needed an organized and manageable view of software development permeating all phases of the software life cycle model.
  • That demand has been met by the Unified Modeling Language (UML) [77] and by CASE tools such as Rational Rose.
  • After more than thirty years since the first object-oriented programming language was introduced, the debate over the claimed benefits of the object-oriented paradigm still goes on.

Did you find this useful? Give us your feedback

Content maybe subject to copyright    Report

Western University
Scholarship@Western
Electrical and Computer Engineering Publications Electrical and Computer Engineering Department
3-2003
A Brief History of the Object-Oriented Approach
Luiz Fernando Capretz
University of Western Ontario, lcapretz@uwo.ca
Follow this and additional works at: h<ps://ir.lib.uwo.ca/electricalpub
Part of the Other Computer Sciences Commons, and the So;ware Engineering Commons
Citation of this paper:
@article{DBLP:journals/sigso;/Capretz03, author = {Luiz Fernando Capretz}, title = {A brief history of the object-oriented
approach}, journal = {ACM SIGSOFT So;ware Engineering Notes}, volume = {28}, number = {2}, year = {2003}, pages = {6}, ee =
{h<p://doi.acm.org/10.1145/638750.638778}, bibsource = {DBLP, h<p://dblp.uni-trier.de} }

A Brief History of the Object-Oriented Approach
Luiz Fernando Capretz
University of Western Ontario
Department of Electrical & Computer Engineering
London, ON, CANADA, N6G 1H1
lcapretz@acm.org
ABSTRACT:
Unlike other fads, the object-oriented paradigm is here to stay. The
road towards an object-oriented approach is described and several
object-oriented programming languages are reviewed. Since the
object-oriented paradigm promised to revolutionize software de-
velopment, in the 1990s, demand for object-oriented software sys-
tems increased dramatically; consequently, several methodologies
have been proposed to support software development based on that
paradigm. Also presented are a survey and a classification scheme
for object-oriented methodologies.
1. INTRODUCTION
Over the past three decades, several software development meth-
odologies have appeared. Such methodologies address some or all
phases of the software life cycle ranging from requirements to
maintenance. These methodologies have often been developed in
response to new ideas about how to cope with the inherent com-
plexity of software systems. Due to the increasing popularity of
object-oriented programming, in the last twenty years, research on
object-oriented methodologies has become a growing field of in-
terest.
There has also been an explosive growth in the number of software
systems described as object-oriented. Object-orientation has al-
ready been applied to various areas such as programming lan-
guages, office information systems, system simulation and
artificial intelligence. Some important features of present software
systems include:
Complexity
: the internal architecture of current software sys-
tems is complex, often including concurrency and parallelism.
Abstraction in terms of object-oriented concepts is a technique
that helps to deal with complexity. Abstraction involves a se-
lective examination of certain aspects of an application. It has
the goal of isolating those aspects that are important for an
understanding of the application, and also suppressing those
aspects that are irrelevant. Forming abstractions of an applica-
tion in terms of classes and objects is one of the fundamental
tenets of the object-oriented paradigm.
Friendliness
: this is a paramount requirement for software
systems in general. Iconic interfaces provide a user-friendly
interaction between users and software systems. An icon is a
graphical representation of an object on the screen, with a cer-
tain meaning to its observer, and is usually manipulated with
the use of a mouse, a process that has come to be known as
WYSIWYG (What You See Is What You Get) interaction. In
such interfaces, windows, menus and icons are all viewed as
objects. The trend to object-oriented graphical interfaces is
evident in many areas of software development; experience
suggests that user interfaces are significantly easier to develop
when they are written in an object-oriented fashion. Thus the
object-oriented nature of the WYSIWYG interfaces maps
quite naturally into the concepts of the object-oriented para-
digm.
Reusability
: reusing software components already available
facilitates rapid software development and promotes the pro-
duction of additional components that may themselves be re-
used in future software developments. Taking components
created by others is better than creating new ones. If a good
library of reusable components exists, browsing components
to identify opportunities for reuse should take precedence over
writing new ones from scratch. Inheritance is an object-
oriented mechanism that boosts software reusability.
The rapid development of this paradigm during the past ten years
has important reasons, among which are: better modeling of real-
world applications as well as the possibility of software reuse dur-
ing the development of a software system. The idea of reusability
within an object-oriented approach is attractive because it is not
just a matter of reusing the code of a subroutine, but it also en-
compasses the reuse of any commonality expressed in class hierar-
chies. The inheritance mechanism encourages reusability within an
object-oriented approach (rather than reinvention!) by permitting a
class to be used in a modified form when a sub-class is derived
from it [1, 2, 3, 4].
2. THE BACKGROUND OF THE OBJECT-ORIENTED
APPROACH
The notion of “object” naturally plays a central role in object-
oriented software systems, but this concept has not appeared in the
object-oriented paradigm. In fact, it could be said that the object-
oriented paradigm was not invented but actually evolved by im-
proving already existing practices. The term “object” emerged
almost independently in various branches of computer science.
Some areas that influenced the object-oriented paradigm include:
system simulation, operating systems, data abstraction and artifi-
cial intelligence. Appearing almost simultaneously in the early
1970s, these computer science branches cope with the complexity
of software in such a way that objects represent abstract compo-
nents of a software system. For instance, some notions of “object”
that emerged from these research fields are:
Classes of objects used to simulate real-world applications, in
Simula [5]. In this language the execution of a computer pro-
gram is organized as a combined execution of a collection of
objects, and objects sharing common behavior are said to con-
stitute a class.
Protected resources in operating systems. Hoare [6] proposed
the idea of using an enclosed area as a software unit and in-
troduced the concept of monitor, which is concerned with
process synchronization and contention for resources among
processes.
Data abstraction in programming languages such as CLU [7].
It refers to a programming style in which instances of abstract
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 1

data types (i.e. objects) are manipulated by operations that are
exclusively encapsulated within a protected region.
Units of knowledge called frames, used for knowledge repre-
sentation. Minsky [8] proposed the notion of frames to capture
the idea that behavior goes with the entity whose behavior is
being described. Thus a frame can also be represented as an
object.
All these influences have been gathered together and the object-
oriented paradigm has been seen as a way to converge them, as
shown in Figure 1. The common characteristic of these ideas is
that an object is a logical or a physical entity that is self-contained.
Clearly, other belated items could be added to that list, such as
innovations in programming languages, as demonstrated in Ada;
and advances in programming methods, including the notion of
modularization and encapsulation. Nevertheless, Simula was the
first programming language that had objects and classes as central
concepts. Simula was initially developed as a language for pro-
gramming discrete-event simulations, and objects in the language
were used to model entities in the real-world application that was
being simulated.
Despite the early innovation of Simula, the term “object-oriented”
became prominent from Smalltalk [9]. The Smalltalk language,
first developed in 1972 in the Learning Research Group at Xerox
Palo Alto Research Center, was greatly influenced by Simula as
well as by Lisp. Smalltalk was the software half of an ambitious
project known as the Dynabook, which was intended to be a pow-
erful personal computer. Research on Smalltalk has continued and
the Smalltalk language and the environment were by-products of
that project. From Smalltalk, some common concepts and ideas
were identified and they gave support, at least informally, to the
object-oriented paradigm. Because of the evolution and dissemina-
tion of programming languages like Smalltalk, this new paradigm
has evolved, and new languages, methodologies, and tools have
appeared.
3. CHARACTERISATION OF AN OBJECT-ORIENTED
MODEL
Although object-oriented programming has its roots in the 1970s,
there were many definitions about what precisely the term object-
oriented meant. The term meant different things to different people
because it had become very fashionable to
describe any software system in terms of ob-
ject-oriented concepts. To some, the concept
of object was merely a new name for abstract
data types; each object had its own private
variables and local procedures, resulting in
modularity and encapsulation. To others,
classes and objects were a concrete form of
type theory; in this view, each object is con-
sidered to be an element of a type which itself
can be related through sub-type and super-
type relationships.
To others still, object-oriented software sys-
tems were a way of organizing and sharing
code in large software systems. Individual
procedures and the data they manipulate are
organized into a tree structure. Objects at any
level of this tree structure inherit behavior of higher level objects;
inheritance turned out to be the main structuring mechanism which
made it possible for similar objects to share program code. Despite
many authors being concerned with providing precise definitions
for the object-oriented paradigm, it was difficult to come up with a
single generally accepted definition.
Rentsch [10] defines object-oriented programming in terms of
inheritance, encapsulation, methods, and messages, as found in
Smalltalk. Objects are uniform in that all items are objects and no
object properties are visible to an outside observer. All objects
communicate using the same mechanism of message passing, and
processing activity takes place inside objects. Inheritance allows
classification, sub-classification and super-classification of ob-
jects, which permits their properties to be shared.
Pascoe [11] also presents object-oriented terminology from the
Smalltalk perspective. Pascoe defines an object-oriented approach
in terms of encapsulation, data abstraction, methods, messages,
inheritance, and dynamic binding for object-oriented languages.
Pascoe also affirms that some languages that have one or two of
these features have been improperly called object-oriented lan-
guages. For instance, Ada could not be considered an object-
oriented language because it does not provide inheritance.
Other authors, such as Robson [12] and Thomas [13], emphasize
the idea of message passing between objects and dynamic binding
as fundamental to object-oriented programming. There is no doubt
those authors have also been influenced by the Smalltalk language,
wherein the message passing mechanism plays a fundamental role
as the way of communication among objects. On the other hand,
Stroustrup [14] claims that object-oriented programming can be
seen as programming using inheritance, and that message-passing
is just an implementation technique, not at all an inherent part of
the paradigm.
Nygaard [15] discusses object-oriented programming in terms of
the concept of objects in Simula. In that language an execution of
a computer program is organized as the joint execution of a collec-
tion of objects. The collection as a whole simulates a real-world
application, and objects sharing common properties are said to
constitute a class. Madsen and Moller-Pedersen [16], like Nygaard
[15], sees object-oriented programming as a model that simulates
the behavior of either a real or imaginary part of the world. The
System
Simulation
Operating
Systems
Data
Abstraction
Artificial
Intelligence
Classes +
Objects
Monitors
Abstract Data
Types +
Encapsulation
Frames
Object-Oriented
Paradigm
Figure 1: The Background of the Object-Oriented Paradigm.
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 2

model consists of objects defined by attributes and actions, and the
objects simulate phenomena. Any transformation of a phenomenon
is reflected by actions on the attributes. The state of an object is
expressed by its attributes and the state of the whole model is the
state of the objects in that model.
The object-oriented paradigm was still lacking a well-known and
profound theoretical understanding, then some research come out
in this area. Cardelli and Wegner [17], for example, with formal
methods that used denotational semantics, described the essential
features of the object-oriented paradigm, such as abstract data
types, objects, classes and inheritance.
Lastly, Wegner [18] characterized an object-oriented approach in
terms of objects, classes and inheritance. Objects are autonomous
entities that have a state and respond to messages; classes arrange
objects by their common attributes and operations; inheritance
serves to classify classes by their shared commonality. Thus: ob-
ject-orientation = objects + classes + inheritance. The characteriza-
tion of an object-oriented approach proposed by Wegner has been
the most accepted one.
As it has been described, there are many different interpretations
of the object-oriented paradigm. Nevertheless, one thing that all
definitions have in common, not surprisingly, is the recognition
that an object is the primitive concept of the object-oriented para-
digm. The object is an encapsulation of protected data along with
all the legal operations that act on that hidden information.
4. COMPARISON BETWEEN “OBJECT-ORIENTED”
LANGUAGES
At the beginning of programming language development, assem-
bly languages only enabled programmers to write code based on
machine instructions (operators) that manipulated the contents of
memory locations (operands). Therefore the level of control and
data abstraction achieved was very low. A great leap forward oc-
curred when the first higher-level languages, e.g. Fortran and Al-
gol, appeared. The operators turned into statements and operands
into variables and data structures. The traditional view of programs
in these languages is that they were composed of a collection of
variables that represented some data and a set of procedures that
manipulated those variables. The majority of traditional program-
ming languages supported this data-procedure paradigm. That is,
active procedures operate upon passive data that is passed to them.
Things happen in a program by invoking a procedure and giving to
it some data to manipulate. Through a sequence of statements and
procedures, early higher-level languages had reasonable support to
implement actions; however, they had shortcomings to represent
abstract data types.
Abstract data types are abstractions that may exist at a higher level
than operands and operators, or variables and procedures sepa-
rately. Some languages provided a construct that allowed both
variables and procedures to be defined within a single unit; for
instance the cluster construct in CLU, which satisfies the definition
of abstract data types. The same idea can also be found in Ada
through the package construct. Nevertheless, if two abstract data
types are similar but not identical, there is no means of expressing
their commonality conveniently in a programming language that
supports only abstract data types.
The object-oriented paradigm goes a step further than abstract data
types; that is, object-oriented languages allow similarities and dif-
ferences between abstract data types to be expressed through in-
heritance, which is a key defining feature of the object-oriented
paradigm. Therefore it would be better to characterize the evolu-
tion of object-oriented languages based on the support for both
abstract data types and inheritance; in this case the immediate an-
cestor of object-oriented languages was Simula, which was an
Algol-based language. Simula was the first language to introduce
the concept of class and to allow inheritance to be expressed, and
it should be recognized as the “mother” of a few object-oriented
programming languages. Besides, because object-oriented con-
cepts have also arisen from the artificial intelligence community, it
is not surprising that Lisp has influenced a number of object-
oriented languages. For instance, Flavors [19], Loops [20] and
CLOS [21], have all borrowed ideas from Lisp and Smalltalk.
The prominence of the object-oriented paradigm has influenced
the design of other programming languages. There are languages
that incorporate object-oriented constructs into the popular C, Pas-
cal and Modula-2, resulting in the hybrid languages Objective-C
[22], C++ [23], ObjectPascal [24] and Modula-3 [25]. The inclu-
sion of object-oriented concepts into traditional languages sophis-
ticated them, in that programmers had the flexibility to use or not
to use the object-oriented extensions and benefits. Although these
hybrid languages became more complex, those extensions enabled
programmers who had considerable experience with those tradi-
tional procedure languages to explore incrementally the different
concepts provided by the object-oriented paradigm. Nevertheless,
when using a hybrid language, programmers had to exercise more
discipline than when using a pure object-oriented language be-
cause it was too easy to deviate from sound object-oriented princi-
ples. For instance, C++ allows global variables, which violates the
fundamental principle encapsulation.
As far as concurrency is concerned, objects can also be viewed as
concurrent agents that interact by message passing, thus emphasiz-
ing the role of entities such as actors and servers in the structure of
a real-world application. The main idea behind object-oriented
languages that support concurrency is to provide programmers
with powerful constructs that allow objects to run concurrently.
Concurrency adds the idea of simultaneously executing objects
and exploiting parallelism. Languages to which this applies in-
clude: Actor [26], ABCL [27], POOL-T [28], Orient84 [29] and
ConcurrentSmalltalk [30].
Other languages influenced basically by Simula and CLU, such as
Beta [31] and Eiffel [32] have also appeared and are believed to
give good support for the object-oriented paradigm. Although Eif-
fel and Smalltalk seem to be coherent object-oriented languages
with integrated programming environments, C++ has become the
most used object-oriented programming language, due to the in-
fluence of UNIX and the popularity of the C language from which
C++ derived. Finally, Java [33] should look familiar to C and C++
programmers because Java was designed with similar but cleaner
constructs; it also provides a more robust library of classes. Java is
rapidly gaining territory among programmers, and it is expected to
become the most popular object-oriented language. Analyzing the
evolution of all those languages over time leads to the dependency
graph shown in Figure 2.
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 3

A programming language is called object-based if it permits the
definition of objects as abstract data types only, whereas, a lan-
guage is called object-oriented if it allows the definition of objects
and supports the inheritance mechanism. According to this classi-
fication, the set of object-based languages includes Ada and CLU.
This is so because objects in Ada are defined as packages and ob-
jects in CLU are instances of clusters. The set of object-oriented
languages is smaller than the set of object-based languages, and
excludes Ada and CLU but includes Smalltalk and C++ because
the latter two support inheritance. Table 1 shows a comparison
between some of the programming languages mentioned above.
When serious programming is mentioned, it is not just about the
language, it is also about library support that has been built around
a language, forming a platform that helps to develop software sys-
tems.
It can be concluded that, despite the possibility of following an
object-oriented fashion using languages (e. g. Ada and CLU) with
less or more difficulty, direct language support is beneficial in
facilitating as well as encouraging the use of the object-oriented
tenets such as in Eiffel or Java. Not only do these languages sup-
port the object-oriented paradigm, but also they enforce it because
the main language constructs dealt with are related to objects,
classes and inheritance. The danger in trying to force object-
oriented concepts into a language that does not provide inheritance
is that weird constructions may be produced, impairing software
development and jeopardizing the quality of the resulting software.
Table 1: Comparing Languages
Features
X
Languages
Abstract
Data
Types
Inheritance
Support
Dynamic
Binding
Extensive
Library
Simula yes yes yes no
CLU yes no yes no
Ada yes no no yes
Smalltalk yes yes yes yes
ObjectiveC yes yes yes yes
C++ yes yes yes yes
CLOS yes yes yes no
Obj.Pascal yes yes yes no
Beta yes yes yes no
Eiffel yes yes yes yes
Actor yes yes yes no
Java yes yes yes yes
Ada
Lisp
Assembly
Algol
Simula
Smalltalk
Flavors
Loops
CLOS
Actor
POOL-T
ABCL
Orient84
Objective-C
ObjectPascal
Modula-3
Beta
C++
CLU C
Pascal
Modula-2
Java
60s
50s
70s
80s
90s
Fortran
Eiffel
Figure 2: Language Evolution.
ACM SIGSOFT Software Engineering Notes vol 28 no 2 March 2003 Page 4

Citations
More filters
Journal ArticleDOI
Gill Smith1

567 citations

Journal ArticleDOI
TL;DR: A process-centered template is used for summarizing the object-oriented software development methodologies, highlighting the activities prescribed in the methodology while describing the modeling languages used (mainly diagrams and tables) as secondary to the activities.
Abstract: We provide a detailed review of existing object-oriented software development methodologies, focusing on their development processes. The review aims at laying bare their core philosophies, processes, and internal activities. This is done by using a process-centered template for summarizing the methodologies, highlighting the activities prescribed in the methodology while describing the modeling languages used (mainly diagrams and tables) as secondary to the activities. The descriptions produced using this template aim not to offer a critique on the methodologies and processes, but instead provide an abstract and structured description in a way that facilitates their elaborate analysis for the purposes of improving understanding, and making it easier to tailor, select, and evaluate the processes.

118 citations


Cites background from "A brief history of the object-orien..."

  • ...Even though object-oriented software development methodologies suffer from various kinds of problems, they are still considered state of the art, and research aimed at improving them is an ongoing evolutionary process [Capretz 2003; Boehm and Turner 2004; Booch et al. 2007]....

    [...]

  • ...The Road Ahead Even though object-oriented software development methodologies suffer from various kinds of problems, they are still considered state of the art, and research aimed at improving them is an ongoing evolutionary process [Capretz 2003; Boehm and Turner 2004; Booch et al. 2007]....

    [...]

Proceedings ArticleDOI
26 Jun 2004
TL;DR: The use of UML in control and automation is examined and the proposed approach integrates UML with the already well accepted by control engineers FB construct, to cover the analysis and design phases of the development process.
Abstract: The function block (FB) has been defined by the International Electro-technical Commission as the basic construct for the development of reusable, interoperable, distributed control applications. However, the FB does not exploits recent advances in software engineering. The Unified Modeling Language (UML) is the new industry standard for modeling software-intensive systems. UML brings in the development process the best software engineering practices. In this paper, we examine the use of UML in control and automation and describe the use of a hybrid approach in the development process of distributed control systems. The proposed approach integrates UML with the already well accepted by control engineers FB construct, to cover the analysis and design phases of the development process. A model driven approach is adopted to move from analysis through design, to implementation. The applicability of the UML profile for schedulability, performance and time, to the proposed development process, is also examined

100 citations


Cites background from "A brief history of the object-orien..."

  • ...The great advantage of the OO paradigm, which has been gradually accepted during the last decade, is the conceptual continuity across all phases of the software development process [7]....

    [...]

Journal Article
TL;DR: This paper develops Brinch-Hansen's concept of a monitor as a method of structuring an operating system, introduces a form of synchronization, describes a possible method of implementation in terms of semaphores and gives a suitable proof rule.
Abstract: This paper develops Brinch-Hansen's concept of a monitor as a method of structuring an operating system. It introduces a form of synchronization, describes a possible method of implementation in terms of semaphores and gives a suitable proof rule. Illustrative examples include a single resource scheduler, a bounded buffer, an alarm clock, a buffer pool, a disk head optimizer, and a version of the problem of readers and writers.

79 citations

References
More filters
Book
Bjarne Stroustrup1
01 Jan 1985
TL;DR: Bjarne Stroustrup makes C even more accessible to those new to the language, while adding advanced information and techniques that even expert C programmers will find invaluable.
Abstract: From the Publisher: Written by Bjarne Stroustrup, the creator of C, this is the world's most trusted and widely read book on C. For this special hardcover edition, two new appendixes on locales and standard library exception safety have been added. The result is complete, authoritative coverage of the C language, its standard library, and key design techniques. Based on the ANSI/ISO C standard, The C Programming Language provides current and comprehensive coverage of all C language features and standard library components. For example: abstract classes as interfaces class hierarchies for object-oriented programming templates as the basis for type-safe generic software exceptions for regular error handling namespaces for modularity in large-scale software run-time type identification for loosely coupled systems the C subset of C for C compatibility and system-level work standard containers and algorithms standard strings, I/O streams, and numerics C compatibility, internationalization, and exception safety Bjarne Stroustrup makes C even more accessible to those new to the language, while adding advanced information and techniques that even expert C programmers will find invaluable.

6,795 citations

Book
01 Jan 1999
TL;DR: In The Unified Modeling Language User Guide, the original developers of the UML provide a tutorial to the core aspects of the language in a two-color format designed to facilitate learning.
Abstract: In The Unified Modeling Language User Guide, the original developers of the UML--Grady Booch, James Rumbaugh, and Ivar Jacobson--provide a tutorial to the core aspects of the language in a two-color format designed to facilitate learning. Starting with a conceptual model of the UML, the book progressively applies the UML to a series of increasingly complex modeling problems across a variety of application domains. This example-driven approach helps readers quickly understand and apply the UML. For more advanced developers, the book includes a learning track focused on applying the UML to advanced modeling problems.With The Unified Modeling Language User Guide, readers will:Understand what the UML is, what it is not, and why it is relevant to the development of software-intensive systemsMaster the vocabulary, rules, and idioms of the UML in order to "speak" the language effectivelyLearn how to apply the UML to a number of common modeling problemsSee illustrations of the UML's use interspersed with use cases for specific UML features, andGain insight into the UML from the original creators of the UML.

6,634 citations

Book ChapterDOI
01 Jun 1974
TL;DR: The enormous problem of the volume of background common sense knowledge required to understand even very simple natural language texts is discussed and it is suggested that networks of frames are a reasonable approach to represent such knowledge.
Abstract: : A partial theory is presented of thinking, combining a number of classical and modern concepts from psychology, linguistics, and AI. In a new situation one selects from memory a structure called a frame: a remembered framework to be adapted to fit reality by changing details as necessary, and a data-structure for representing a stereotyped situation. Attached to each frame are several kinds of information -- how to use the frame, what one can expect to happen next, and what to do if these expectations are not confirmed. The report discusses collections of related frames that are linked together into frame-systems.

5,812 citations

Book
01 Jan 1990
TL;DR: This book discusses Object Modeling as a Design Technique, Object Diagram Compiler, and the Future of Object-Oriented Technology.
Abstract: 1. Introduction. I. MODELING CONCEPTS. 2. Modeling as a Design Technique. 3. Object Modeling. 4. Advanced Object Modeling. 5. Dynamic Modeling. 6. Functional Modeling. II. DESIGN METHODOLOGY. 7. Methodology Preview. 8. Analysis. 9. System Design. 10. Object Design. 11. Methodology Summary. 12. Comparison of Methodologies. III. IMPLEMENTATION. 13. From Design to Implementation. 14. Programming Style. 15. Object-Oriented Languages. 16. Non-Object-Oriented Languages. 17. Databases. 18. Object Diagram Compiler. 19. Computer Animation. 20. Electrical Distribution Design System. 21. Future of Object-Oriented Technology. Appendix A: OMT Graphical Notation. Appendix B: Glossary. Index.

5,408 citations


"A brief history of the object-orien..." refers background or methods in this paper

  • ...Rumbaugh et al. [ 72 ] developed the Object Modeling Technique (OMT), which focused on object modeling as a software development technique....

    [...]

  • ...Several authors tried to fit the object-oriented paradigm into this framework: Lorensen [69], Jacobson [70], Wirfs-Brock et al. [71], Rumbaugh et al. [ 72 ] and Booch [62] can be considered good ex-...

    [...]

Journal ArticleDOI
TL;DR: An outline is given of the process steps involved in the spiral model, an evolving risk-driven approach that provides a framework for guiding the software process and its application to a software project is shown.
Abstract: A short description is given of software process models and the issues they address. An outline is given of the process steps involved in the spiral model, an evolving risk-driven approach that provides a framework for guiding the software process, and its application to a software project is shown. A summary is given of the primary advantages and implications involved in using the spiral model and the primary difficulties in using it at its current incomplete level of elaboration. >

5,055 citations


"A brief history of the object-orien..." refers background in this paper

  • ...Several models have been proposed in order to systematize the several stages that a software system goes through [34, 35, 36]....

    [...]

Frequently Asked Questions (1)
Q1. What have the authors contributed in "A brief history of the object-oriented approach" ?

Object-Oriented approaches this paper have been proposed to support software development based on the object-oriented paradigm.