Modeling Unix

[fyreman]

Hello,

As an exercise in studying UML and as a method of learning more Unix, I'm attempting to create UML to model the various elements of Centos 5 that I am encountering.  In doing this I'm encountering quite a few conceptual problems re: how UML works.

As an initial example for discussion, consider the "tar" command.  Using whereis I can find the executable file, a .h file, and a file for man.  My approach with this has been:

1.  I create three use cases:
"I want to run the command"
"I want to include the .h in a program"
"I want to RTFM".

2.  I create three artefacts named
/bin/tar
/usr/include/tar.h
/usr/share/man/man1/tar.1.gz,
and connect them to the use cases via realization links.

My rational is that the use cases are things a user of this program clearly would want to do.  The three files are artifacts and their existence realizes the functionality of the use cases.

I put this on a Composite Structure diagram because this is the least worst choice.  Although I don't have any specific problem with using this diagram type, I don't have sufficient judgement about these diagrams to feel comfortable with the choice.

Next, I have a 4th use case "I want to install this program."  My intention here is to document where this program comes from, not so much as to actually install it.  

This leads me to deployment diagrams.  The DD is good for showing that I have some artefacts deployed, but doesn't answer the question about how those artefacts get there in the first place?  

My general thinking is that use case "i want to install this program" is realised by some element "install the OS" which is perhaps linked to an activity diagram that shows that the specific files are  copied and linked to the deployment diagram as well.  I don't know how to say this in UML and that's what stumping me.

Very grateful for any tips and advice for how to approach these issues.

[qwerty]

You shouldn't start mixing things. Step one: learn writing use cases (if you need to). The Pope is Cockburn (Writing Effective Use Cases). Then you can go deeper. A lot of hurdles to take.

However, if you want a fast approach I really (!!) can recommend Dough Rosenberg and his ICONIX approach. A long time ago  I ordered a presentation CD where Dough describes the steps from Use Case to Code. I don't know whether this CD is still available, but if so just take the time to hear and see.

q.

P.S. I guess this is it: http://www.sparxsystems.com.au/products/iconix_pr.html

[SomersetGraham]

Plus there is an EA addin that supports the Iconix approach

[fyreman]

Thanks for the replies folks, but unfortunately ICONIX strikes me as more of the general UML same as far as pretty pictures with many, many blindspots.

My issues are not blocked due to my inability to write use cases.  The use cases that I have are too simple to be trouble and merely serve as functional entry points to the system.  I also fail to see how I can apply a vague admonition against "mixing things" in real life usage.  In fact, in my experience real-life is an endless dumping ground of mixings and so I would expect real-life tools to be able to cope.

I have many files on my Centos machine.  Why are they there?  How did they get there?  How do they work together?  These, and many other issues scream for the promise of UML and yet it appears as if these issues are things that UML is incapable of describing and are examples of what I term "blind spots".

[fyreman]

[edit]EDIT: REMOVED BY MODERATOR (Let's keep things friendly, eh?)[/edit]

[qwerty]

I thought it wasn't worth while so I had removed my post before yours was in. So just forget about it.

q.

P.S. Sorry for not reading your post above.

[KP]

1. "I want to run the command" doesn't sound like a very useful use case. I think "Add file(s) to archive" and "Remove file(s) from archive" would be better as they express the real goal of the actor (platform-independently, which is a bonus).

2. "I want to include the .h in a program" doesn't sound like a use case at all. The programmer can just add a dependency to the "tar" class on a class diagram.

3. The more usual way to model would be to have your Artifacts on a Deployment diagram, with Manifestation relationships to either Class or Component elements. The Class and Component elements will have Realization relationships to the UseCases.

4. "i want to install this program" doesn't sound like a use case either (how does it achieve the actor's goal? i.e. if the actor tells his boss he has been installing software all day, he shouldn't be surprised if the boss asks if he has done any real work). If, as you say, you want to document where the software comes from, give the Artifact a tagged value named "Location".

[fyreman]

Thanks for the response.

I understand your reasoning re: "I want to run the command"  In real life, to fully connect what this command does to requirements of an actor, we'd need many use cases that would express all the possible goals of the actor, that would be realized by using the command with different options.

I understand the politics of bosses wondering what on Earth you're doing all day long as you reboot, debug, curse, throw equipment from windows, etc.  Nevertheless, installation is in fact real work and often very difficult.  I think there's more to say about this so I'll launch a new topic about this.

.h.  Yes, that makes sense to me.

I understand this may not be "useful" but I'm mostly concerned with studying what's possible (or not) and how to do it.  Thanks for the advice.