A%20Seamless%20Model%20and%20Language

1
A Seamless Model and Language

• Stephen W. Liddle
• Brigham Young University

2
Outline

• Status of implementation
• Historical perspective
• Model-equivalent language

3
In the Beginning

• Vannevar Bush, As We May Think, proposed the
  memex in 1945
• Then we had hypertext systems
• HyperCard on the Macintosh was popular

4
Then Came the Web

• The World Wide Web was enabled by two very simple
  protocols
• HTTP (get, post, )
• HTML (head, body, title, strong, )
• Sites started as fairly simple repositories of
  pages
• Structure was basic sections, paragraphs, lists,
  tables, anchors, links, images
• Key simplification no annotation

5
Then Came Version 2.0

• And beyond
• Applets, cookies, Cascaded Style Sheets, XML,
  JavaScript, server-side includes, server-side
  scripting,
• Trend to more power, complexity
• How to we manage complexity?
• Abstraction (modeling)

6
The History of Semantic Data Models

• NIAM and ER in the mid 1970s
• For more than a decade, extensions proliferated
• People learned that too much notation got in the
  way, and data models tended to simpler concepts

7
The History of OO Models

• Built on semantic data models and software
  engineering methods
• By the early 90s were proliferating just like
  the semantic data models had
• Method Wars
• The negotiated peace settlement UML
• Clearly is a compromise
• Too much notation (my opinion)

8
Sustaining vs. Disruptive Technology Trajectories
Performance demanded by market
High end
Product Performance
Low end
Time
9
Our Experience with OSM

• Work began in the late 80s
• Book on Object-Oriented Systems Analysis (OSA) in
  the early 90s
• Since then our research has generally used this
  model as its core

10
Guiding Philosophy

• Take an ontological perspective
• See Yair Wands work, for example
• Take a model-driven approach
• Agnostic toward the methodology
• Instead emphasize clarity and purity of the
  modeling concepts
• Provide clear formal definitions

11
OSM Layers

• OSA (analysis)
• OSS (specification)
• OSD (design)
• OSI (implementation)
• OSE (evolution)
• All together we call this Object-oriented Systems
  Modeling, or OSM

12
My Task Implementation

• OSA was a nice start
• Did not provide a clean path to an implemented
  system, just to a naturally described system
• Did cleanly separate analysis from design
  features
• OSS, OSD, and OSI needed few changes to the basic
  model in OSA
• We called our central model OSM and viewed
  OSA/OSS/OSD/OSI as shifts in perspective

13
The State of Software Development Then

• Difficult and lossy transformations between
  models, languages, tools
• Inhibited communications (differing assumptions,
  definitions)
• Barriers to seamless tool development
• Multiple paradigms leading to complexity and lack
  of comprehensibility

14
Has Anything Changed?

• Only slightly
• We do emphasize standards now

15
Inherent Complexity

• Software development is innately complex because
  of
• Sheer size of application
• Number of users
• Variety/complexity of I/O mechanisms
• Originality of innovations created for a
  particular system
• Sophistication of algorithms required to address
  system tasks

16
Artificial Complexity

• Software development is artificially (and
  needlessly) complex because
• We do not have sufficient abstractions in
• Operating systems
• Languages
• Models
• Other tools
• Ad-hoc mixture of abstractions in our models,
  languages, tools is poorly integrated, poorly
  defined, redundant, and inconsistent
• We still have lossy transformations
• The Web has only made it worse

17
Typical Web Application
18
Typical Web Page
lt?php _at_conn mysql_pconnect("localhost",
"userid", "passwd") _at_mysql_select_db("my_databa
se", conn) if (!empty(UserID)
!empty(Password)) sql "SELECT FROM
Person WHERE UserID'UserID' AND " .
"PasswordPASSWORD('Password')" result
mysql_query(sql, conn) if (result)
include("main_menu.php") exit
?gt ltHTMLgt ltHEADgt ltTITLEgtSample Login
Pagelt/TITLEgt ltSTYLE TYPE"text/css"gt BODY,
P, TD, TH font-family arial, geneva,
helvetica, sans-serif
font-size 10pt TH text-align left
H1 text-align center font-size 18pt
H2 text-align center font-size 14pt
lt/STYLEgt ltSCRIPT LANGUAGE"JavaScript"gt lt!--
function trim(fld) temp fld.value
if (temp ! "") re /(\s)(.\s)(\s
)/ result re.exec(temp) fld.value
result2 //--gt lt/SCRIPTgt lt/HEADgt
PHP Script
Style Sheet
JavaScript
ltBODYgt ltH1 ALIGN"CENTER"gtPlease Log Inlt/H1gt
ltFORM NAME"frmLogin" METHOD"POST"
ACTION"login.php"gt ltTABLE BORDER0
ALIGN"CENTER"gt ltTRgtltTHgtUser IDlt/THgt
ltTDgtltINPUT TYPE"TEXT" NAME"UserID"
VALUE"lt? UserID ?gt"
SIZE15 ONBLUR"trim(this)"gtlt/TDgt lt/TRgt
ltTRgtltTHgtPasswordlt/THgt ltTDgtltINPUT
TYPE"PASSWORD" NAME"Password" SIZE15gtlt/TDgt
lt/TRgt ltTRgtltTD COLSPAN2
ALIGN"CENTER"gtltINPUT TYPE"SUBMIT"
VALUE"Log
In"gtlt/TDgt lt/TRgt lt/TABLEgt lt/FORMgt
ltHRgt Page generated lt? date("d M Y Hi")
?gt lt/BODYgt lt/HTMLgt
HTML Form
19
OSM Is Seamless
Object Set

• Single modeling and development environment
• Resolves impedance mismatches
• Structural/behavioral
• Imperative/declarative
• Visual/textual
• Reifies abstract objects
• Accessible, formal metamodel
• First-class high-level elements

Person
P1 P2 P3
20
Model Equivalent Language

• The semantics of the model and language are
  one-to-one
• Programming is merely a shift in perspective to
  focus on efficient algorithms and structures
• A program is simply an alternative view of a
  model
• Iteration is quite simple

21
Why OSM Is Suitable Foundation

• Highly expressive
• Computationally complete
• Formally defined (with so-called tunable
  formalism that allows varying levels of formality
  and completion)
• Provides many different kinds of views

22
Organization of OSM

• Object-Relationship Model
• ORM describes structure (summary)
• Object-Behavior Model
• State nets describe object behavior (summary)
• Object-Interaction Model
• Interaction diagrams show how objects interact
  (synchronize and communicate) (summary)
• Emphasis on fully reified high-level constructs
  (views)

23
Harmony, the OSM Language

• Fully textual version of graphical OSM
• Both have same underlying formal foundation
• Adds convenient syntactic features
• In the same way graphical models add convenient
  notations
• Examples
• Figures A, B, C

24
Our Model/Language Features

• Multiple paradigms
• Declarative, imperative
• Nested transactions
• Variable has set semantics, not scalar
• Type-complete persistence
• No impedance mismatches

25
BUT

• No commercial-quality implementation

26
Proposal for Web Application Modeling

• Begin with a core conceptual model that is
  formal, executable
• Ideally, it would have a model-equivalent
  language behind it
• Need to add navigation and presentation
  (interface) layers
• Use frameworks and architectures in the sense
  of design patterns and subsystems

27
Adhere to Guiding Principles

• Ontological perspective
• Model-driven, not method-driven
• Clear, formal definitions

28
Open Problems

• Identification of sufficient, concise set of Web
  application modeling constructs
• Complete, formal, ontological semantics for our
  chosen Web application model
• What is navigation, really?
• Comprehensive tools to tackle all aspects without
  introducing lossy transformations
• Tools that are good enough to take care of
  performance tuning issues
• No more database administrators?

29
References

• Embleys OSA and OODB Design books
• CRC Press Handbook of Object Technology
• Papers linked to the IWWOST Web site
• http//osm.cs.byu.edu