Slashdot Mirror

You might want to consider a career in one of the intersection fields between IT and business such as Enterprise Architecture. EAs don't program typically, but a good fundamental knowledge of IT is highly valued. EAs need to understand both their company's business and the supporting technologies equally. Most EAs I know make 6 figures. Good first steps include reading an EA book, practicing modeling using something like IBM's System Architect, and understanding some of the leading EA frameworks.

Straight-up UML seems to be a bad match for most embedded systems - embedded systems tend to be built on procedural design principles, and matching them to object-oriented principles is often an exercise in frustration. Bruce Powell Douglas ( Doing Hard Time , Real Time UML ) seems to have the best handle on which core diagram types make sense for most of the embedded systems out there - I can't recommend his work highly enough.

There is no definitive diagram standard for the embedded systems industry - the industry is still trying things out. In my corner of aerospace, Matlab Simulink is rapidly becoming our de facto standard for low-level algorithm requirements and design, with Rhapsody UML diagrams used everywhere else.

Whatever you decide on, make sure it is a technology that will be around when you need to re-visit your code. Many legacy programs are littered with the remnants of the diagrams from the SASD movement (structured analysis, structured design) which paved the way to UML. If you need to maintain your diagram system in-house, that's fine - the only reason I see people gravitating towards UML-type diagrams is the warm fuzzy feeling that UML is a well-documented diagram system that will be understood in two decades' time.

There are a number of commercial UML solutions for embedded and real-time systems. e.g. Rhapsody which with IBM's acquisition of telelogic becomes the natural upgrade path for system development with UML.

We use Telelogic's Doors It's good for large projects with multiple systems. It supports requirements tracability and revision history to the object (typically a paragraph). After you're done you can export it to MS Word and you can customize this process using a scripting language and Word templates. I work for a government contractor and the systems we develop include hardware and software efforts on multiple independent processors. It might be overkill for what you need.

Brian

I'm surprised nobody's mentioned DOORS (It's by TeleLogic). It's a requirements matrix system that's extensible, powerful, and reasonably cheap if you're a mid-size (or larger) business. ..on a side note there's a modified Wiki by a Edgewall called Trac. I've not used it personally but it looks like the right stuff...

May I suggest Continuus?

It has a steep learning curve. The ideology behind it is bizarre at best. The windows UI is crap. I also strongly suspect it is sentient because of it's unexpected behaviour.

It is 'professional' and fucking expensive, so it must be good.

It's been done.

Software, even software written in text, even OSS, is already visually designed. It always has been. Flow charts, diagrams, screenshot mockups -- shit, I've gotten specs that were nothing more than a drawing on a paper plate.

The only difference is that Bill forsees getting rid of the intermediate step of writing code to represent the visual system.

In Univ, we did a couple of exercises. The task was to write a simple SIP client (just session establishment, nothing transferred) and server. We did it first in C using some standard libraries. Then we did the same thing with Telelogic's SDL Suite. We basically drew the state machines in a flowchart (only the application layer). We then hit "generate" and it created a bunch of C code that went through gcc.

With the SDL, I could practically convert RFC to a working protocol stack in a few hours. Of course, there was no transport layer or anything - I guess they supply a set of standard protocols like TCP/IP-stack, but we never got around to check it out. The application-layer endpoints were directly connected.

Oh, and I don't consider myself a coder. I know C++ and can write some shell scripts. I basically want the computer to DO some things, and not spend time telling it how to do it. Back in the 80's on my C-64 I told the computer "10 PRINT "Hello!":GOTO 10...we have not gotten too far from those days yet.

If someone invents a programming language that includes a way to tell computer "do what I meant it to do and stop complaining about irrelevant crap", I might consider programming as a way to make living :)

Software, even software written in text, even OSS, is already visually designed. It always has been. Flow charts, diagrams, screenshot mockups -- shit, I've gotten specs that were nothing more than a drawing on a paper plate.

The only difference is that Bill forsees getting rid of the intermediate step of writing code to represent the visual system.

In Univ, we did a couple of exercises. The task was to write a simple SIP client (just session establishment, nothing transferred) and server. We did it first in C using some standard libraries. Then we did the same thing with Telelogic's SDL Suite. We basically drew the state machines in a flowchart (only the application layer). We then hit "generate" and it created a bunch of C code that went through gcc.

With the SDL, I could practically convert RFC to a working protocol stack in a few hours. Of course, there was no transport layer or anything - I guess they supply a set of standard protocols like TCP/IP-stack, but we never got around to check it out. The application-layer endpoints were directly connected.

Oh, and I don't consider myself a coder. I know C++ and can write some shell scripts. I basically want the computer to DO some things, and not spend time telling it how to do it. Back in the 80's on my C-64 I told the computer "10 PRINT "Hello!":GOTO 10...we have not gotten too far from those days yet.

If someone invents a programming language that includes a way to tell computer "do what I meant it to do and stop complaining about irrelevant crap", I might consider programming as a way to make living :)

I have found that most code generation tools (the kind you program boubles and arrows in, like this one) will give you C code that looks like it's been obscurified on purpose.
E.g. all states and variables are in an array called n[][] and the program is basically a big loop.

Quite impossible to know whats going on

Some folks at MyCorp use DOORS from Telelogic for this purpose.

If your workflow is fairly predictable, then perhaps the burden of learning how to use The System would be tolerable. I sat through a short training course for it once; as a programmer I could see how everything was essentially just an object in a big system, exchanging messages as deadlines pass and responsibilities shift from one person to another.

These kinds of tools can be either a great help or fodder for Dilbert. Again, it depends on how easily your workload can be mapped into the system and, of course, corporate culture, management support, etc.

If I remember correctly, it cost somewhere between US$500-US$1000 per seat, I could be wrong, but I know that it was definitely not cheap. It had an Informix database backend (where it stored everything - RDMS is definitely the way to go for a sophisticated CM tool like that), which we were running on a Sun E4000, and most of the client machines were NT. We had one guy full-time to administrate the system.

Continuus (http://www.continuus.com) redirects to Telelogic.com because Continuus (Irvine CA USA)was just purchased for $42 by Telelogic (Malmo Sweden).

I did a white paper on configuration management while a consultant at a ... fortune 500 retailer Se**s.com (home of cr****man tools and Ken***e appliances). I evaluated version control and bug tracking combined ('config management' embodies these two functions).

In any large software project, the issues of bug tracking and version control are very, very tightly interwound. With 100+ developers and 20+ quality assurance (qa) testers, we'd get lots of both bugs and fixes. The trouble was how to associate the two. I built some tools for short term use (that are still in use) using (ugg!) PVCS (not polyvinyl chloride :-) ) and a custom built bug database. We'd associate a checkin of several files with a bug number, promote them to(copy 'em into) the qa dir, send a email to qa, and allow qa to approve the change by bug number not by file number, which promoted (copied) them to the production-level directory. Its a pretty smooth system for something we developed in-house, but it would have been nice to have a web interface, and all the bells and whistles that a purchased product would provide.

Building this was a pain in the butt. Continuus does this, as does Rational, but they are both hideously expensive ($300 - $500 per seat). There were some also-rans (close competitors that didn't quite work right or satisfy the criteria).

The big deal was getting something in house fast. The more money it cost, the more time management took to decide (they still haven't). What we (in the open source community, and Linux in particular) need is a toolset that integrates bug tracking and version control tightly. It really multiplies programmer productivity because the time they don't spend copying files for a custom build. QA is happy because they're assured a bug goes away, and that the tests they run can be regressively associated with a bug number and therefore with a set of files that work together, not one at a time.

If I get time, I'll post the white paper that I wrote specifying all the criteria for config management. There's a bunch of config managment links on my homepage at justanyone.com.

As we're all experts here, I should point out that content management seems to be just a new buzzword for boring old configuration management with bells and whistles on.

Runs on Windows, Solaris, Linux, etc. etc. etc.