OR(B, NOT(B)):
… that’s the question.
Author: unknown.
I don’t understand 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.
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:
Powered by WordPress