My Research Area
-
This page is under construction and replaces
a previous description
[ research.old.html ]
of my research area.
- CR::="Computer Reviews",
[ http://www.reviews.com/ ]
and
[ browse_reviewers.cfm?reviewer_id=115728 ]
Note: Research papers are colored green and blue.
Problem Statement
Why is it that John Roebling could design and construct a bridge that is still in use today despite problems with the quality of the supplied components and the unknown stability of some of its foundations, and yet our software seldom works for than a month at a time?
Many people have proposed ways to improve software development -- but how many of these have worked in practice?
Many people have managed to produce better software on budget, but what did they do right?
How do our notations, processes, methods, languages, and paradigms effect our productivity and the qualities of our software?
What is Known and Thought about Software Development
I have collected a large bibliography of papers and books about
developing software, and a repository of definitions, links,
and commentary on methods, languages, standards, tools, etc.
To search this resource try [ lab.html ] my research search engine.
(methods): See
[ samples/methods.html ]
(languages): See
[ samples/languages.html ]
(standards): See
[ samples/standards.html ]
(tools): See
[ samples/tools.html ]
(etc): See
[ samples/etc.html ]
MATHS
Because engineers use mathematics to design and evaluate solutions to problems I developed a way to encode mathematical and logical arguments and formula in ASCII.This turned out to be a useful way to develop technical web pages. This page and most other pages on this web site are written in this language and translated into HTML using tools that I have developed.
The language I use is called MATHS. See [ maths/ ] for details. The MATHS pages are colored blue.
I have many
[ samples/ ]
of how to use MATHS to document things.
The ROOT Project and UML
I have been instrumental in introducing object orientation
and the UML into the
CSUSB Computer Science department -- the ROOT project.
[ papers/rjb00a.ActiveROOT.html ]
[ papers/rjb99a.ROOT320.html ]
I proposed using the UML to express the semantics of programming languages: [ papers/rjb99b.sigplan.html ] [ papers/rjb99c.umlpl.html ] [ papers/rjb99c.umlpl.ps ] (postscript).
I have recently been working on the changes as UML has evolved
into
UML 2.0
[ papers/20050502Abstract.html ]
[ papers/20050502Body.html ]
[ papers/20050502Outline.html ]
Papers
[ papers/ ]
Publications
[ publications/ ]
Projects I Am Working On
For specific examples of projects and theses for graduate students see [ projects.html ] and [ theses.html ] on this web site.
(blog): To see what I'm doing on a day-to-day basis look at
[ blog.html ]
my Weblog.
Key Terms in my research area -- Software Development
[ map.gif ]
(Graphic) and
[ map.html ]
(Listing).
My Personal Theory of Software Development
One Size Does Not Fit All
Different processes and methods fit different situations: [ papers/rjb95b.one.size.html ]What niches exist? What works in them?
| Paradigm | Niche |
|---|---|
| Engineering | Expensive high quality products |
| MicroSoft | cheap mass produced and field debugged |
| XP | Medium scale evolving high quality code |
| ?? | ?? |
Think Outside the Box
There is more to good software than its code and function. See [ papers/rjb01a.pqrst.htm ] for a partly baked idea --- cooking for 25 years...It is a matter of the fitness of the software to it's environment. Hence: Software Evolution and co-evolution need to be studied in both theory [ papers/rjb02a.hack.html ] [ papers/rjb02a.hack.txt ] [ papers/rjb02bEvolve.pdf ] and practice.
Further, this implies that software developers must understand the world (domain?) in which their software will be running. For more see the writings of Michael A Jackson on Data Directed Design , Dynamic Analysis and Design , and understanding the realities of the outside world.
Somewhere between the World and new Software Things get Formal
Our software must survive in an informal, changing, continuous world
and yet it is expressed in formal languages, static, and discrete.
No Projects = No Problems
By continuously developing software, making small, evolutionary
changes we may end up getting more for the money, than if
we launch a large scale revolutionary project that changes
much of a system. Hence, we should avoid revolutionary projects
and design software to be evolving.
. . . . . . . . . ( end of section My Research Area) <<Contents | End>>