hallo reader, now i can give review about the journal of "Meaningful modeling
what the Semantics of semantics" . i hope you can understand it. keep enjoy!
Title: "Meaningful modeling
what the Semantics of semantics".
Author : David Harel
Pages: 9
- Demograph
The Authors is a
students of University of
Weizmann Institute of Science, Computer
Science and Applied Mathematics, Faculty Member. Published by the IEEE Computer Society
on October 2004.
2. Background
This Paper discussed The Unified Modeling Language (UML) is a complex collection of
mostly diagrammatic notations for software modeling, and its standardization
has prompted an animated discussion about UML's semantics and how to represent
it.
3. Result
He
has set out to clarify some of the notions involved in defining modeling
languages, with an eye toward the particular difficulties arising in defining
UML.The result:
The Unified Modeling
Language (UML) is a complex collection of mostly diagram-matic
notations for software modeling, and its standardization has prompted an animated discussion about UML’s seman-tics
and how to represent it. As the “Wrong Ways to
View Semantics” sidebar describes, authors have quite different ideas of
what constitutes semantics for UML subsets and adaptations. Worse, implicit assumptions
often influence these definitions and results.
Comparing published research on UML semantics is thus very difficult,
since the compari-son must take into account the subsets dealt with, the kind of systems assumed, the relationships among
constructs, the definitions’ detail level, and the notations and representations
used. Obviously, a multitude of concepts
surround the proper definition of complex modeling languages, and many people are confused about what these concepts—both crucial and marginal—really mean and
how to understand and use them. This confu-sion
is particularly apparent in the context of UML ,a multifaceted effort whose
followers are ever grow-ing, but it is also characteristic of other
modeling approaches.We have thus set out to
clarify some of the notions involved in defining modeling languages, with an eye toward the particular difficulties arisingin
defining UML. We are primarily interested in dis-tinguishing a language’s
notation, or syntax,
fromits
meaning, or semantics,
as well as recognizing the differences between variants of syntax and seman-tics in
their nature, purpose, style, and use.
ELEMENTS
OF A LANGUAGE DEFINITION
Much has been said about
the distinction between the purist notion of information and its syntactic representation as data. The literature
gen-erally agrees that data is used to communicate, but extracting or understanding the information
behind it requires an
interpretation—a mapping that assigns a meaning to each (legal) piece of
data. A major source of confusion is the mixing of the data and information notions. In one case, two pieces of data
might encode the same information, for
example, “June 20, 2000” and “The last day of the first spring in the second millennium.” In another case, the same piece of data might have
sev-eral meanings and therefore denote different infor-mation for different people or applications. The information the reader derives from “John’s
birth-day,” for example, depends on the context. Deeply understanding
the difference between syntax and semantics helps avoid confusion. Just as
people use natural languages to commu-nicate
with each other, machines use machine-read-able languages for
communication. Both kinds of language—whether
they are natural, artificial, pro- gramming, or hardware description
languages—contain a great variety of meaningful language ele-ments. Communication stakeholders must thus agree
on the language, which in turn fixes the dataset that they can communicate. Accordingly,
a language consists of a syntactic notation
(syntax), which is a possibly infinite set of legal elements,
together with the meaning of those elements,
which is expressed by relating the syntax to a semantic domain. Thus, any
language defini-tion must consist of the syntax semantic domain and semantic mapping from the syntactic elements to
the semantic domain.
Syntax
Depending on the
language type, syntactic ele-ments can be words, sentences, statements, boxes, diagrams, terms, models, clauses, modules, and soon.
In our description and the “Two Language Examples”
sidebar, we use “expression” to repre-sent these terms. Textual languages
are symbolic in spirit, and their basic syntactic expressions are put together in
linear character sequences. In contrast, the basic expres-sions in
iconic languages are small pictorial signs that visually depict elements. An
iconic language can be more intuitive than
a textual language, but only if the designer resists abusing the icons. In
diagrammatic languages, or visual for-malisms,
1basic expressions
include lines, arrows, closed curves and boxes, and composition mecha-nisms
involve connectivity, partitioning, and “in-sideness.” Despite some well-known
critiques,
2,3 diagrammatic
languages are proving extremely helpful in
software and systems development. In a theoretical sense, textual languages and
visual or diagrammatic ones have no principal difference, but when rigor and formality are called for,
prop-erly defining diagrams seems much harder. Moreover, although semantics
actually describes a language’s meaning, computer tools make it impossible
to manipulate semantics directly. Instead, everything on paper or the screen is
a syn-tactic representation. This is also
true of the machine’s internal representation, the so-called abstract
syntax or metamodel. Because a rigid syntax is critical to correct lan-guage interpretation, any attempt to compromise
it could be disastrous. Writing
read(data) in a lan-guage in which the input commands
are of the form input(data)
will result in a
syntax error, forexample. And a computer can’t exactly recognize the command, “How about getting me a value for “K?” Thus, a formal, concise, and rigid set of syn-tax.
Wrong Ways to View Semantics
It is an understatement to say that different
people view semantics differently across software and systems engineering.
After listening to numerous presentations and reading even more papers, we have
iden-tified both specializations of the general concept and downright mis-uses.
The following are some common erroneous views, many in the context of UML.
Semantics
is the metamodel.
This is a common
misuse of the term. The metamodel is but a way to describe the language’s
syntax; it is a crucial precursor, but it
is not the semantics itself. Knowing what a lan-guage looks like does
not equate with understanding what it means.
·
Semantics
is the semantic domain.
Some
people use the word seman-tics
as shorthand for the statement, “The semantics is given in terms of a
particular semantic domain or maps the syntax into that domain.”Using semantics
and semantic domain interchangeably is erroneous, since it avoids the most crucial part of the semantics—the semantic
map-ping.
·
Semantics
is the context conditions.
This
use of the term has its roots in
compiler theory, where everything beyond the basic context-free grammar is
viewed as semantics. It seems to have had a great influence on the way Object
Constraint Language constraints are used on top of UML’s metamodel. This use of the term semantics is also erroneous, as it
does not entail either a semantic domain or a semantic mapping. It sim-ply
further constrains the syntax. In the UML standardization docu-ments, “static
semantics” is used instead of “context conditions.”
·
Semantics
is dealing with behavior.
Some of the most
intricate lan-guages deal with behavior,
especially reactive behavior. Their semantics must prescribe the
system’s behavior for each allowed program/model/ expression, so that for such languages, behavior and semantics are closely related. However, structure description
languages, for example, don’t talk about behavior, but they still need
semantics. Hence, seman-tics and behavior are not to be confused.
·
Semantics is being
executable
Taking the previous
point one step further, some people equate having semantics with being
executable. Clearly, if a language is executable, it probably has an adequate
seman-tics, although that semantics might not have been given an adequately clear representation. However, not all languages
specify behavior, and not all those that do so are (or need to be)
executable. Also, even if the language is meant to be executable, it can have a
non executable, deno-tational semantics. Thus, in general, having adequate
semantics has lit-tle to do with a
language’s ability to be executed.
·
Semantics
is the behavior of a system.
Sometimes people talk
about the semantics of a particular system—the way it behaves, its reaction time,
and so on. This is quite different from the semantics of the lan-guages used to
describe that system.
·
Semantics
is the meaning of individual constructs.
People
often refer to the semantics of
some part of the language, even just one construct. Clearly, there is much more
to semantics than that.
Semantics
means looking mathematical . When some people see that parts of a language
definition have mathematical symbols, they are con-vinced that it is probably also precisely
defined. This is simply not true.
·
Semantics is ________
Some people simply
give a buzzword to indi-cate something about
how the semantic definition goes, as in “the semantics is given by
message-passing.” This prompts others to think that the language is properly endowed with semantics. Sadly, the worst cases
are when the people making this kind of statement actually believe it
themselves.
The
strengthness
This journal provide very complete explanation with key word or
instruction, that can make the reader more understand.
The Weakness
this journal used decode decipher that make the reader become confused
and do not make the example in each explanation, so the reader cannot understand
this journal clearly.
So, Semantics have many function in context of Unified Modeling
Language.
