UML class diagram for php site without class

Question

I am trying to create UML documentation for PHP site. Yes, I know this is not the usual way - but this site is already in production and now we need UML documentation for it :)

Programmer which made this site is not OOP at all - he didn't use any PHP class to create this site. Instead that he did many php files. I believe in PHP world is quite popular approach.

Now I am wondering how can I create class diagram for this code? As I know class diagram is only a way to show system architecture and programming concept. I believe in this case I can present single php file as one class and variables used in this file as class attribute. If some file included some other file I can present this as a class relation. Is it right approach?

Answer 1

Well, you could start this way. This would probably be the same as painting a VanGogh the Picasso-way.

Of course it depends on many factors, but if possible I would dump the code and design it the right way. But that's probably impossible in most cases (too expensive I hear the managers say, yes, yes). So the right approach in that case: keep the zombie alive, but forget UML. It will not help you much here.

You might as well try to just redesign little parts. If so, start from scratch here too.

Interestingly the old Indian proverb "When you find, you are riding a dead horse, get off" did never reach many managers.

Ok. So let's try a few ways to ride the dead horse.

• Make a UC documentation first. That would work even with non-OO software.
• Find the few parts which are OO and put those into an UML documentation (static class diagrams and where appropriate some SDs)
• Create an object dependency structure of the existing PHP files. Just use an object for each file and draw a dependency relation. That will in most cases scare managers enough to drive a re-design.
• Where recognizable isolate interfaces and bring them to light in your class diagram so far.
• Where ever possible point out the existing mess and insist on a refactoring.
• Make the cadaver obvious. The more it smells, the likelier there will be money for refactoring.
• Try to isolate sub-systems that can be worked on individually.

Finally:

• Good luck!