Dariusz on Software

OR(B, NOT(B)):

... that's the question.

Author: unknown.

I don't get UML designers. They skipped in UML very useful design tool: data flow diagrams (DFD) and placed cheap substitute called "activity diagram". Why? Because data flow is not object oriented (no encapsulation). Should we skip this useful tool and use only diagrams defined by UML? I don't think so.

On the other hand general problem with DFD (and any diagramming technique) is scalability. If you want to express many flows using DFD you have to make DFD hierarchical, thus overall picture may be hidden here. If you place too many (>9 items) details on one diagram you are lost again.

There's simple and very powerful, but forgotten technique called "CRUD tables". What's "CRUD"? It's a table (can be implemented by a spreadsheet) that for every process in a system defines it's interactions with main entities: Create, Read, Update, Delete. CRUD table was used mainly during database design, but I think this technique can be used for every data flow in a system (including external actors and entities).

I'll show you how you can utilize CRUD table to make initial design and get software complexity estimation.

First of all, a specification:

I need to sell products on my website. I'd like an order is created in my ERP system just after instant payments are finished.

Pretty short, but let's start design!

We can see how basic processes interacts with internal data (Product, Order, Item) and external entities (Payment, ERP Order). Let's check first rule:

Every process should have at least one input (R) and one output (CUD)

We can see rule is not valid for few processes, so let's add some Entities to fulfill this rule:

As you can see we added actor (Customer) to be a source (trigger) for some processes.

Now we can add estimation part. First: for every entity we can add complexity (we know that one entities can be more complicated than another), complexity of processes will result from used entities complexity:

Formula used for computation of "complexity" column:

=counta(C3)*$C$2+counta(D3)*D$2+counta(E3)*E$2+counta(F3)*F$2+counta(G3)*G$2+counta(H3)*H$2

So we know now that more complicated process will be sending order to an ERP system. If we added proper weights to operations (CRUD) and measure single activity we could estimate full effort needed to implement specified system.

Above CRUD translates into the following DFD:

I'd like to hear about your experience with CRUD modeling.

Sometimes you want your user-level program to be automatically started on every Linux reboot. Scared of complicated SYSV startup scripts? Don't panic, this task is easier than you think!

First of all you need root access on a machine to install startup script. Default startup scripts are placed in /etc/init.d directory and special symbolic link must be created under /etc/rc5.d (at least on Debian-based systems).

First let's create startup script for your "daemon"-like program:

/etc/init.d/myprogram:
----------------------
#! /bin/sh
PATH=/sbin:/bin
case "$1" in
  start)
    su -c /home/darek/bin/myprogram.sh darek &
    ;;
  restart|reload|force-reload)
    killall myprogram.sh
    su -c /home/darek/bin/myprogram.sh darek &
    ;;
  stop)
    killall myprogram.sh
    ;;
  *)
    echo "Usage: $0 start|stop" >&2
    exit 3
    ;;
esac

Note that "darek" is the user id that will be used for starting up the script.

Then: ensure it's executable and create symbolic link for default runlevel (5 on Debian):

chmod +x /etc/init.d/myprogram
cd /etc/rc5.d
ln -s ../init.d/myprogram S80myprogram

"S" means "start", "80" allows to ordered execution. Pretty simple!

SYSV init scripts are harded to setup than BSD-style, but are more flexible and easier to manage by installation tools (dpkg under Debian).