What to do with the System class in my Class Diagram?

[Maurice brown]

I have a system class in my class diagram, and I don't know what to do with it. Most diagrams I see do not have a System class.

I'm trying to understand what it means.

I would like to start coding my design, as least parts of it, but I can't get pass the System class. I would like to model an Employee taking an Exam.

The class got added from my System Sequence Diagram and the Communications Diagrams.

I hope you can help me clarify what the System means and how I can start modeling Employee takes Exam Use Case.

Thanks!

[Yegor Bugayenko]

System is a bad name here, since it conflicts with java.lang.System. I would recommend to use Base.

It is the main and the only class you instantiate at your application "entrance", also known as function main(). For example, if it is a command line application, it may look like:

public void main() {
  Base base = new Base();
  base.run(System.in, System.out);
}

The entire logic of your application is implemented by this class.

[Junilu Lacar]

First, I want to apologize for 1) not really having anything that directly answers your question, and 2) for going off on a rant about the irrelevance and outdatedness, IMO, of what they're still teaching in schools, and finally 3) this rant again, if it seems a bit over the top. But it is a rant after all.

<rant>

If this is what they're still teaching in schools, then somebody needs to tell those old fart professors to get with the program already. These things are so 1990s. Or at least drawing them out this way is.

I've worked as a developer for over two decades now. In that time, I have drawn maybe 10, possibly fewer, UML diagrams with the kind of detail that you have shown here. I stopped trying to do that in 1998. Life is just too short.

I refer you to author Scott Ambler's website: http://agilemodeling.com/artifacts/ . If you go through the sample UML diagrams he has there, you'll notice that many of them appear to be photos of diagrams drawn out on a whiteboard. Well, they are. If I have to draw diagrams, they are usually on this medium and with that level of detail, which is nowhere near what you have most diligently done in your diagrams. I'm not saying this to disparage your work or belittle your effort but to give you an idea of what happens in the real world. Granted, this is my world view but it is also one that many, and more and more, professional developers happily share.

To give you another real-world view of how design is done in the wild, I encourage you to take a gander at the book we're promoting in the Design forum this week: https://coderanch.com/t/640907/design/John-Ferguson-Smart

The book is called BDD in Action where BDD stands for Behavior-Driven Development. If you get a chance to look through the book, you may notice an abject lack of detailed UML diagrams but I assure you, that's because the book talks about how real teams do real work in the wild.

(second to the) lastly, I'd encourage you to read these three essays by Jack Reeves where he proposes that Code is the Design. There may be some (maybe even many) who will have issues with the propositions in these essays but the truths in them have been borne out in my own experience so I have no arguments against them.

Lastly, I'll tell you how software is successfully designed and developed these days. Again, this is my world view, but one shared by many professionals these days. The better software development teams these days do their work through constant collaboration, frequent conversations, and highly automated and integrated testing and coding practices. This is how they produce software that delights their customers. That is what they should be teaching kids in school these days so that when they enter the work force, they don't have to throw out all this outdated "stuff" (to put it mildly) and learn what developers really do on the job.

</rant>

[Junilu Lacar]

Now that I've gotten that off my chest, I took a closer look at your diagram. I have to disagree with Yegor here. Whatever you call it, Base or System, it's a poor design choice to have this one class be responsible for so much in your program. Not only is this class busting at the seams with methods, they are all unrelated methods. This has the strong smell of the anti-pattern known as the God Class.

To my earlier point of how software development is very collaborative and interactive these days, these diagrams hint at being developed in isolation. A lot of strange and funny (not ha ha) things can happen when you do things like this in isolation. Designing software is like trying to find your way out of a corn maze. There are so many twists and turns that it's easy to get lost or find yourself in a blind alley.

If you had been working with someone else, they could have asked you a number of different questions early on to keep you out of trouble. Questions like:

1. Why does this System class have so many responsibilities? That's not a good thing.
2. Why is the Manager responsible for making new instances of Exam? associating Exams? associate with what?
3. Same line of questioning about Employee and Video Player
4. Same line of questioning about VideoPlayer and Video
5. Same line of questioning about Exam and Grade
...and so many more

I think you jumped down into the nitty-gritty details before you got your high-level concepts straight. Maybe you should start with a Conceptual Diagram or Class-Responsibility-Collaboration (CRC) cards instead. These will help you get a better high-level conceptual model.

And BTW, to give you an idea in how design happens in the/my real world, I start designing with just a high-level conceptual model or CRC cards of the major entities of my application. Designing is not done as a "phase" after analysis and it never spans more than a couple of hours a day without writing any code. Designing and coding/testing are tightly intertwined activities, so much so that they are almost indistinguishable from each other (did you read Jack Reeves' essays?).

I get a high-level design laid out on a whiteboard first, then I pair up with one or more developers and we start writing tests to flesh out the "story" behind the design. As we do this, we discover more about the concepts we have in mind and we fill in gaps or change some of the concepts around. It's not unheard of for us to throw away a concept we don't find useful and replace it with another one that makes more sense in the context of running tests and code. Most of all, we spend a lot of time reading the code we've written out loud. Our minds seem to process things differently when we hear these things said out loud.

As you've designed things now, I can't imagine that the code it suggests will make a whole lot of sense at all. Code should tell you a story that's consistent with what you would say in plain English (or whatever is your preferred language) to explain what the program does. That's how you know that your design is on the right track.

[Junilu Lacar]

Sometimes it's helps when you turn things around. For example, you asked "What to do with the System class?" If you turn this around and forget about the name "System", you'd have to look at the responsibilities you've laid out for this "unnamed thing". I do this a lot with my team. They ask me "What should we name this object?" and I say "Well, just name it 'Foo' for now, then we'll figure out a good name once we understand how it fits in with everything else."

To frame it another way, think about playing a game called "Who is this Person in Your Neighborhood?" And, yes, this is a twist on the old Sesame Street bit, if you're familiar with it.

Who is the person in your neighborhood?

He or she ...
1. Puts out fires
2. Rescues kittens from a tree
3. Helps people trapped in cars
4. Checks that the fire hydrants work
5. Arrests bad guys
6. Delivers your mail
7. Delivers your milk
8. Takes your garbage away every week
9. Gives you tickets if you drive too fast
10. Gives you medicine when you're sick
11. Takes care of your dog when you go on vacation

This doesn't make sense, does it? It's not just one person, is it? But take away all but the first 4 items on the list and it's clear who this person is, right?

Try to do the same thing with the responsibilities in that thing you now call System.