Monday, May 17, 2004

 

Models

What is a model? The dictionary defines a model to be a miniature representation of something; also: a pattern of something to be made. It is common engineering practice to use models to facilitate the definition and design of a system being built. Booch points out that; unlike theorems, models are neither right nor wrong. Instead, models are judged to be more or less useful to the engineering process.

Why do we model? Models allow us to focus on some aspects of a structure while ignoring others. For example, a schematic lets us focus on the electronic properties of a circuit and ignore the physical layout of the components. When modeling requirements we want to ignore the implementation – concentrate on the “what” and ignore the “how”. In design we focus on the architecture, ignoring the yet to be implemented code.

By suppressing unwanted details, models make a system easier to understand. Because we are humans our models are often expressed in language or as drawings. This facilitated communication and discussion of proposals, which is another reason that we model. Diagrams, especially, make it possible to visualize a system. Simulations and prototypes allow us to experience a system before we have created a complete construction.

But models can do more than focus our attention or allowing us to visualize a system; in some cases the model provides a framework for thinking and reasoning about the system. A heat flow model of an electronic circuit allows quantitative evaluation of the thermal parameters associated with the component. UML Sequence Diagrams can be used to show precise timing among a set of system events.

Should we model the problem space or the solution space? Up to now Computer Aided Software Engineering (CASE) has focused on modeling the solution space. UML is used primarily to model software elements – classes, objects, interactions, states, etc. Model Driven Architecture (MDA) emphasizes transformations from one model to the next, presumably eventually arriving at a source code model. But it is unclear how (or even if) the MDA approach can cross that all-important chasm between models of the problem and models of the solution.


Monday, May 10, 2004

 

Clemens Vasters: Indigo'ed - Lightweight Transactions - A puzzle (I mean, really..)

Clemens Vasters: Indigo'ed - Lightweight Transactions - A puzzle (I mean, really..)

Despite the author's claim that writing resource managers is, hey, it's really trivial, I find this code difficult to understand. Though, it might be simple to write; understanding what's going on is hard. Yet, something tells me that his view is profound, since it supports both pessimistic and optimistic locking - or even a mixture.
 

Nag, nag, nag,...

Well, my son (devhawk.net) has been nagging me forever to start my own blog. With bolg.com it seems so easy that I guess I had better try. So, here goes...We'll see if I have enough to say to make it worth while.

A little background:

I've been around computing for a long time! My first job after getting my doctorate was at Bell Labs. In the Spring 1971 I installed my first Unix system - with Ken Thompson help. Because my thesis delt with compiler theory I was interested in C from the beginning - static routines was my suggestion.

Over the years I've worked on air traffice controls systems, case and office tools, handwriting recognition algorithms, to name a few. I am one of the authors of the Systems Engineering CMM.

Currently, I teach OO Programming, and OO Analysis & Design at Johns Hopkins University (part-time engineering school)

My current interests include Security & Enterprise Architectures for a large gov't agency; designing Service Orient Architectures; and software development tools.

I guess that's a start...

This page is powered by Blogger. Isn't yours?