Software Artifacts

What exactly are software artifacts? Put simply, a software artifact is a file that exists as part of some software system. The most common software artifacts are source code files and executable files. What isn't usually considered an artifact, however, is the logical design of the system.

It sounds strange that the system design isn't considered a software artifact but in most cases, it is the truth. The design of any software system is implicitly captured in the source code files. Because without the system design, there wouldn't be any source code files because they would have no reason to exist.

If the software system is modeled with UML, shouldn't the model files themselves be considered software artifacts. I would like to think so. Especially since they do a better job of making the system design explicit than the source code does.

Additionally, UML models can also make the software artifacts of the modeled system explicit. That is, you can have meta-artifacts. This of course assumes that the model itself is considered an artifact. If it sounds too confusing, it really doesn't have to be. UML artifact elements can help illuminate where in the model these artifacts, usually source code files, are expressed as a logical design.

Software Preservation

Grady Booch, over at the handbook of software architecture makes a good point of why preserving classic software systems for future generations is important. There is a storyline behind every system. Within this story lies an endless supply of rationale behind tricky technological problems. Of course, the rationale behind doing such and such with some software component would probably be worth something to some developer in the future. The how probably isn't as important, although it might be. Everything should be preserved as best as possible.

It might be difficult to say what might happen if the software of today isn't preserved for future generations. But what harm could be done if every meaningful software system were preserved for the future? There is probably a mountain of historical data that exists today that is of no particular use besides self-interest. At least it has no use yet. The only thing that is certain is that we'll never know if it proved to be worth-while if we don't do it today.

This got me thinking about software that isn't that old. Maybe a few years old. What if I as a developer worked on it but it was no longer of particular use to anyone else, would it be worth preserving? I think so. I've had countless times where I just thought of something I did to solve a similar problem in a older project. Trac really helps here. I just launched Trac and sure enough, I was able to find what I needed.

Distributing unit tests.

In this context, I'm referring to distributing unit tests along with a software package, as opposed to executing unit tests in a distributed fashion (which is an interesting topic in its' own right). Unit testing has proven to be an essential development artifact to ensure all use cases are executed correctly. I wish I could say all open source projects distribute unit tests as a component of the package. This is simply not the case. Several projects do, however, include a testing facility which is usually composed of unit tests.

Why, if the authors of these software packages spend time writing all these unit tests, should they be distributed along with the software? After all, they write these unit tests for their own testing. Sometimes an entire testing team is responsible for this task.

I would say that no matter how big a testing team any given project has, they are never going to cover all possible corner cases. That goes without saying (but I'm saying it anyway). Custom operating environments, even some other piece of installed software, could cause unexpected behavior that is in no way handled correctly be the software in question. At least having unit testing available in these situations can offer some clue.