Peter Chen

From Wikipedia, the free encyclopedia

Dr. Peter Pin-Shan Chen (Chinese: 陳品山) is an American computer scientistand

Professor of Computer Science at Louisiana State University, who is known for the
development of Entity-Relationship Modeling in 1976.

[edit]Biography

Born in Taichung, Taiwan Peter Chen received a B.S. in electrical engineering in 1968 at
the National Taiwan University, and a Ph.D. in computer science/applied mathematics at
the Harvard University in 1973. From 1974 to 1978 Chen as Assistant Professor at MIT
Sloan School of Management. From 1978 to 1984 he was Professor at the University of
California, Los Angeles (UCLA Management School). Since 1983 Chen has held the
position of M. J. Foster Distinguished Chair Professor of Computer Science at Louisiana
State University.[1]

Chen has received several awards in the fields of Information Technology.[2] He received
the Data Resource Management Technology Award from the Data Administration
Management Association in New York City in 1990. In 1998, he was inducted as a Fellow of
theAssociation for Computing Machinery. He won the Achievement Award in Information
Management in 2000 from DAMA International. He was an inductee into the Data
Management Hall of Fame in 2000. He received the Stevens Award in Software Method
Innovation in 2001. In 2003, Dr. Chen received the IEEE Harry Goode Award at the IEEE-
CS Board of Governors meeting in San Diego. Dr. Chen was presented with the ACM/AAAI
Allen Newell Award at the ACM Banquet in San Diego in June 2003. Dr. Chen is also the
recipient of the Pan Wen-Yuan Outstanding Research Award in 2004.[3]

[edit]Work

[edit]Entity-Relationship Modeling
The Entity-Relationship Model model serves as the foundation of many systems analysis
and design methodologies, computer-aided software engineering (CASE) tools,
and repository systems. The ER Model is the basis for IBM's Repository Manager/MVS
and DEC's CDD/Plus.

Dr. Peter Chen's original paper[4] is commonly cited as the definitive reference for Entity
Relationship Modelling. Chen did not in fact invent the concept; the basic ideas appear in
earlier papers especially by practitioners, such as that by A. P. G. Brown.[5] However, Chen
did more than anyone to formalize and popularize the model, and to introduce it to the
academic literature.

The ER Model was adopted as the meta model ANSI Standard in Information Resource
Directory System (IRDS), and the ER approach has been ranked at the top methodology for
database design and one of the top methodologies in systems development by several
surveys of Fortune 500 companies.[6]

[edit]Computer-Aided Software Engineering

Chen’s work is a cornerstone of software engineering,[6] in particular Computer-Aided
Software Engineering (CASE). In the late 80’s and early 90’s, IBM’s Application
Development Cycle (AD/Cycle) framework and DB2 repository (RM/MVS) were based on
the ER model. Other vendors’ repository systems such as Digital’s CDD+ were also based
on the ER model. Chen has had a significant impact on the CASE industry through his
research and his lecturing around the world on structured system development
methodologies. The ER model has influenced most of the major CASE tools,
including Computer Associates’ ERWIN, Oracle Corporation’s Designer/2000,
andSybase’s PowerDesigner (and even a general drawing tool like Microsoft Visio), as well
as the IDEF1X standard.[6]

The hypertext concept, which makes the World Wide Web extremely popular, is very similar
to the main concept in the ER model. Dr. Chen is currently investigating this linkage as an
invited expert of several XML working groups of the World Wide Web Consortium (W3C).

The ER model also serves as the foundation of some of the recent work on Object-
oriented analysis and design methodologies andSemantic Web. The UML modeling
language has its roots in the ER model.
[edit]

manipulators
Stream manipulators

Manipulators are functions specifically designed to be used in conjunction with the insertion (<<) and
extraction (>>) operators on stream objects, for example:
cout << boolalpha;

They are still regular functions and can also be called as any other function using a stream object as
argument, for example:
boolalpha (cout);

Manipulators are used to change formatting parameters on streams and to insert or extract certain
special characters.

Basic format flags

These manipulators are usable on both input and output streams, although many only have an effect
when applied to either output or input streams.

Independent flags (switch on):

boolalpha Alphanumerical bool values (manipulator function)
showbase Show numerical base prefixes (manipulator function)
showpoint Show decimal point (manipulator function)
showpos Show positive signs (manipulator function)
skipws Skip whitespaces (manipulator function)
unitbuf Flush buffer after insertions (manipulator function)
uppercase Generate upper-case letters (manipulator function)
Independent flags (switch off):
noboolalpha No alphanumerical bool values (manipulator function)
noshowbase Do not show numerical base prefixes (manipulator function)
noshowpoint Do not show decimal point (manipulator function)
noshowpos Do not show positive signs (manipulator function)
noskipws Do not skip whitespaces (manipulator function)
nounitbuf Do not force flushes after insertions (manipulator function)
nouppercase Do not generate upper case letters (manipulator function)
Numerical base format flags ("basefield" flags):
dec Use decimal base (manipulator function)
hex Use hexadecimal base (manipulator function)
oct Use octal base (manipulator function)
Floating-point format flags ("floatfield" flags):
fixed Use fixed-point notation (manipulator function)
scientific Use scientific notation (manipulator function)
Adustment format flags ("adjustfield" flags):
internal Adjust field by inserting characters at an internal position (manipulator function)
left Adjust output to the left (manipulator function)
right Adjust output to the right (manipulator function)

Input manipulators
ws Extract whitespaces (manipulator function)

Output manipulators
endl Insert newline and flush (manipulator function)
ends Insert null character (manipulator function)
flush Flush stream buffer (manipulator function)

Parameterized manipulators
These functions take parameters when used as manipulators. They require the explicit inclusion of the
header file <iomanip>.

setiosflags Set format flags (manipulator function)

resetiosflags Reset format flags (manipulator function)
setbase Set basefield flag (manipulator function)
setfill Set fill character (manipulator function)
setprecision Set decimal precision (manipulator function)
setw Set field width (manipulator function)

Macros (C/C++)Preprocessing expands macros in all lines that are not

preprocessor directives (lines that do not have a # as the first non-white-space character)
and in parts of some directives that are not skipped as part of a conditional compilation.
"Conditional compilation" directives allow you to suppress compilation of parts of a source
file by testing a constant expression or identifier to determine which text blocks are passed
on to the compiler and which text blocks are removed from the source file during
preprocessing.

The #define directive is typically used to associate meaningful identifiers with constants,
keywords, and commonly used statements or expressions. Identifiers that represent
constants are sometimes called "symbolic constants" or "manifest constants." Identifiers
that represent statements or expressions are called "macros." In this preprocessor
documentation, only the term "macro" is used.

When the name of the macro is recognized in the program source text or in the arguments
of certain other preprocessor commands, it is treated as a call to that macro. The macro
name is replaced by a copy of the macro body. If the macro accepts arguments, the actual
arguments following the macro name are substituted for formal parameters in the macro
body. The process of replacing a macro call with the processed copy of the body is called
"expansion" of the macro call.

In practical terms, there are two types of macros. "Object-like" macros take no arguments,
whereas "function-like" macros can be defined to accept arguments so that they look and
act like function calls. Because macros do not generate actual function calls, you can
sometimes make programs run faster by replacing function calls with macros. (In C++,
inline functions are often a preferred method.) However, macros can create problems if you
do not define and use them with care. You may have to use parentheses in macro definitions
with arguments to preserve the proper precedence in an expression. Also, macros may not
correctly handle expressions with side effects. See the getrandom example in The #define
Directive for more information.

Once you have defined a macro, you cannot redefine it to a different value without first
removing the original definition. However, you can redefine the macro with exactly the same
definition. Thus, the same definition can appear more than once in a program.

The #undef directive removes the definition of a macro. Once you have removed the
definition, you can redefine the macro to a different value. The #define Directive and The
#undef Directive discuss the #define and #undefdirectives, respectively.
n C++, all data types, including those defined by the user, can be declared const, and const-correctness
dictates that all objects should be declared as such unless they need to be modified. Such proactive use
of const makes values "easier to understand, track, and reason about,"[1] and it thus increases the
readability and comprehensibility of code and makes working in teams and maintaining code simpler
because it communicates information about a value's intended use.

[edit]Simple data types

For simple non-pointer data types, applying the const qualifier is straightforward. It can go on either side
of the type for historical reasons (that is, const char foo = 'a'; is equivalent to char const foo
= 'a';). On some implementations, using conston both sides of the type (for instance, const char
const) generates a warning but not an error.

[edit]Pointers and references

For pointer and reference types, the syntax is slightly more subtle. A pointer object can be declared as
a const pointer or a pointer to a const object (or both). A const pointer cannot be reassigned to point
to a different object from the one it is initially assigned, but it can be used to modify the object that it points
to (called the "pointee"). Reference variables are thus an alternate syntax for constpointers. A pointer to
a const object, on the other hand, can be reassigned to point to another object of the same type or of a
convertible type, but it cannot be used to modify any object. A const pointer to a const object can also
be declared and can neither be used to modify the pointee nor be reassigned to point to another object.
The following code illustrates these subtleties:
void Foo( int * ptr,
int const * ptrToConst,
int * const constPtr,
int const * const constPtrToConst )
{
*ptr = 0; // OK: modifies the pointee
ptr = 0; // OK: modifies the pointer

*ptrToConst = 0; // Error! Cannot modify the pointee

ptrToConst = 0; // OK: modifies the pointer

*constPtr = 0; // OK: modifies the pointee

constPtr = 0; // Error! Cannot modify the pointer

*constPtrToConst = 0; // Error! Cannot modify the pointee

constPtrToConst = 0; // Error! Cannot modify the pointer
}
To render the syntax for pointers more comprehensible, a rule of thumb is to read the declaration from
right to left. Thus, everything to the left of the star can be identified as the pointee type and everything to
the right of the star are the pointer properties. (For instance, in our example above, int const * can be
read as a mutable pointer that refers to a non-mutable integer, and int * const can be read as a non-
mutable pointer that refers to a mutable integer.)

References follow similar rules. A declaration of a const reference is redundant since references can
never be made to refer to another object:
int i = 42;
int const & refToConst = i; // OK
int & const constRef = i; // Error the "const" is redundant

Even more complicated declarations can result when using multidimensional arrays and references (or
pointers) to pointers; however, some have argued[citation needed] that these are confusing and error-prone and
that they therefore should generally be avoided or replaced with higher-level structures.

C/C++ also allows the following syntax:

const int* ptrToConst; //identical to: int const * ptrToConst,
const int* const constPtrToConst;//identical to: int const * const
constPtrToConst
[edit]Methods

In order to take advantage of the design-by-contract strategy for user-defined types (structs and classes),
which can have methods as well as member data, the programmer must tag instance methods
as const if they don't modify the object's data members. Applying the const qualifier to instance
methods thus is an essential feature for const-correctness, and is not available in many other object-
oriented languages such as Java and C# or in Microsoft's C++/CLI or Managed Extensions for C++.
While const methods can be called by const and non-const objects alike, non-const methods can
only be invoked by non-const objects. The const modifier on an instance method applies to the object
pointed to by the "this" pointer, which is an implicit argument passed to all instance methods. Thus
having const methods is a way to apply const-correctness to the implicit "this" pointer argument just like
other arguments.

This example illustrates:

class C
{
int i;
public:
int Get() const // Note the "const" tag
{ return i; }
void Set(int j) // Note the lack of "const"
 { i = j; }
};

void Foo(C& nonConstC, const C& constC)

{
int y = nonConstC.Get(); // Ok
int x = constC.Get(); // Ok: Get() is const

nonConstC.Set(10); // Ok: nonConstC is modifiable

constC.Set(10); // Error! Set() is a non-const method and constC is a
const-qualified object
}

In the above code, the implicit "this" pointer to Set() has the type "C *const"; whereas the "this"
pointer to Get() has type "const C *const", indicating that the method cannot modify its object
through the "this" pointer.

Often the programmer will supply both a const and a non-const method with the same name (but
possibly quite different uses) in a class to accommodate both types of callers. Consider:
class MyArray
{
int data[100];
public:
int & Get(int i) { return data[i]; }
int const & Get(int i) const { return data[i]; }
};

void Foo( MyArray & array, MyArray const & constArray )

{
// Get a reference to an array element
// and modify its referenced value.

array.Get( 5 ) = 42; // OK! (Calls: int & MyArray::Get(int))

constArray.Get( 5 ) = 42; // Error! (Calls: int const & MyArray::Get(int)
const)
}

The const-ness of the calling object determines which version of MyArray::Get() will be invoked and
thus whether or not the caller is given a reference with which he can manipulate or only observe the
private data in the object. The two methods technically have different signatures because their "this"
pointers have different types, allowing the compiler to choose the right one. (Returning a constreference
to an int, instead of merely returning the int by value, may be overkill in the second method, but the
same technique can be used for arbitrary types, as in the Standard Template Library.)
[edit]Loopholes to const-correctness
There are several loopholes to pure const-correctness in C and C++. They exist primarily for compatibility
with existing code.

The first, which applies only to C++, is the use of const_cast, which allows the programmer to strip
the const qualifier, making any object modifiable. The necessity of stripping the qualifier arises when
using existing code and libraries that cannot be modified but which are not const-correct. For instance,
consider this code:
// Prototype for a function which we cannot change but which
// we know does not modify the pointee passed in.
void LibraryFunc(int *ptr, int size);

void CallLibraryFunc(int const *ptr, int size)

{
LibraryFunc(ptr, size); // Error! Drops const qualifier

int *nonConstPtr = const_cast<int*>(ptr); // Strip qualifier

LibraryFunc(nonConstPtr, size); // OK
}

However, any attempt to modify an object that is itself declared const by means of const_cast results
in undefined behavior according to the ISO C++ Standard. In the example above, if ptr references a
global, local, or member variable declared as const, or an object allocated on the heap via new const
int, the code is only correct if LibraryFunc really does not modify the value pointed to by ptr.

Another loophole applies both to C and C++. Specifically, the languages dictate that member pointers and
references are "shallow" with respect to the const-ness of their owners — that is, a containing object that
is const has all const members except that member pointees (and referees) are still mutable. To
illustrate, consider this code:
struct S
{
int val;
int *ptr;
};

void Foo(const S & s)

{
int i = 42;
s.val = i; // Error: s is const, so val is a const int
s.ptr = &i; // Error: s is const, so ptr is a const pointer to int
*s.ptr = i; // OK: the data pointed to by ptr is always mutable,
// even though this is sometimes not desirable
}

Although the object s passed to Foo() is constant, which makes all of its members constant, the pointee
accessible through s.ptr is still modifiable, though this may not be desirable from the standpoint
of const-correctness because s might solely own the pointee. For this reason, some[who?] have argued
that the default for member pointers and references should be "deep" const-ness, which could be
overridden by a mutable qualifier when the pointee is not owned by the container, but this strategy
would create compatibility issues with existing code. Thus, for historical reasons[citation needed], this loophole
remains open in C and C++.

The latter loophole can be closed by using a class to hide the pointer behind a const-correct interface,
but such classes either don't support the usual copy semantics from a const object (implying that the
containing class cannot be copied by the usual semantics either) or allow other loopholes by permitting
the stripping of const-ness through inadvertent or intentional copying.

Finally, several functions in the C standard library violate const-correctness, as they accept
a const pointer to a character string and return a non-const pointer to a part of the same
string. strtol and strchr are among these functions. Some implementations of the C++ standard
library, such as Microsoft's[2] try to close this loophole by providing two overloaded versions of some
functions: a "const" version and a "non-const" version.

[edit]Volatile-correctness

The other qualifier in C and C++, volatile, indicates that an object may be changed by something
external to the program at any time and so must be re-read from memory every time it is accessed. The
qualifier is most often found in code that manipulates hardwaredirectly (such as in embedded
systems and device drivers) and in multithreaded applications (though often used incorrectly in that
context; see external links at volatile variable). It can be used in exactly the same manner as const in
declarations of variables, pointers, references, and member functions, and in fact, volatile is
sometimes used to implement a similar design-by-contract strategy which Andrei
Alexandrescu calls volatile-correctness,[3] though this is far less common than const-correctness.
Thevolatile qualifier also can be stripped by const_cast, and it can be combined with
the const qualifier as in this sample:

// Set up a reference to a read-only hardware register that is

// mapped in a hard-coded memory location.
const volatile int & hardwareRegister = *reinterpret_cast<int*>(0x8000);

int currentValue = hardwareRegister; // Read the memory location

int newValue = hardwareRegister; // Read it again

hardwareRegister = 5; // Error! Cannot write to a const location

Because hardwareRegister is volatile, there is no guarantee that it will hold the same value on two
successive reads even though the programmer cannot modify it. The semantics here indicate that the
register's value is read-only but not necessarily unchanging.

[edit]const and immutable in D

In Version 2 of the D programming language, two keywords relating to const exist.
[4]
The immutable keyword denotes data that cannot be modified through any reference.
The const keyword denotes a non-mutable view of mutable data. Unlike C++ const,
Dconst and immutable are "deep" or transitive, and anything reachable through
a const or immutable object is const orimmutable respectively.

Example of const vs. immutable in D

int[] foo = new int[5]; // foo is mutable.
const int[] bar = foo; // bar is a const view of mutable data.
immutable int[] baz = foo; // Error: all views of immutable data must be
immutable.

immutable int[] nums = new immutable(int)[5]; // No mutable reference to

nums may be created.
const int[] constNums = nums; // Works. immutable is implicitly convertible
to const.
int[] mutableNums = nums; // Error: Cannot create a mutable view of
immutable data.

Example of transitive or deep const in D

class Foo {
Foo next;
int num;
}

immutable Foo foo = new immutable(Foo);

foo.next.num = 5; // Won't compile. foo.next is of type immutable(Foo).
// foo.next.num is of type immutable(int).
[edit]final in Java
In Java, the qualifier final states that the affected data member or variable is not assignable, as below:

final int i = 3;
i = 4; // Error! Cannot modify a "final" object

It must be decidable by the compilers where the variable with the final marker is initialized, and it must
be performed only once, or the class will not compile. Java's final and C++'s const keywords have the
same meaning when applied with primitive variables. Afinal reference in Java means the same as
the const pointer in C++ above.

Foo *const i; // this C++ declaration

final Foo i; // is the same as this Java declaration

Unlike C++ where one can declare a "pointer to a const type" above, there is no such mechanism in
Java.
const Foo *bar; // pointer to a const type; no equivalent in Java

There is no way to declare that code will not modify the object pointed to by a reference through that
reference in Java. Thus there are also no const methods. Const-correctness cannot be enforced in
Java, although by use of interfaces and defining a read-only interface to the class and passing this
around, one can ensure that objects can be passed around the system in a way that they cannot be
modified.

Methods in Java can be declared "final", but that has a completely unrelated meaning - it means that
the method cannot be overridden in subclasses.

Interestingly, the Java language specification regards const as a reserved keyword — i.e., one that
cannot be used as variable identifier — but assigns no semantics to it. It is thought that the reservation of
the keyword occurred to allow for an extension of the Java language to include C++-style const methods
and pointer to const type.[citation needed] An enhancement request ticket for implementing const correctness
exists in the Java Community Process, but was closed in 2005 on the basis that it was impossible to
implement in a backwards-compatible fashion.[5]

[edit]const and readonly in C#

In C#, the qualifier readonly has the same effect on data members that final does in Java and
the const does in C++; The constmodifier in C# has an effect similar (yet typed and class-scoped) to
that of #define in C++. (The other, inheritance-inhibiting effect of Java's final when applied to
methods and classes is induced in C# with the aid of a third keyword, sealed.)

Unlike C++, C# does not permit methods and parameters to be marked as const. However one may also
pass around read-only subclasses, and the .NET Framework provides some support for converting
mutable collections to immutable ones which may be passed as read-only wrappers.