Writing good software Part I

Now that I am starting to wrap my head around everything a little better I thought I would re visit a favorite book. Object Oriented Analysis & Design is a book in the head first series by O'Reilly. I have not read this book in a long time and even when I did I don't think I really understand it. Know that I want to learn more about the actual architecture side of things I thought I would dive back into it. What a better way to dive through it then to share everything with the 5 of you who read this blog ;)

Writing great software is not easy, if it was easier everyone would be doing it. There is more work involved in creating great software and for some the task in hand does not involve the future. The first thing we need to go over is modeling our application. A visual model is usually represented using UML. There are plenty of resources out there on UML but  I will quickly run down the basics.

UML or Unified Modeling Language is a simple way to structure or communicate the details of your code using a visual representation. There are many programs out there for modeling UML diagrams but for this quick example I am just going to use my favorite new program. This a very basic class but It will give us some details about how our model will look.

The top of the diagram is the name of the class. When we get into creating abstract classes you will see a set of brackets around the name but we can talk about that another day. The next section is our variables or properties. We want to provide just the basic details about our properties so the name and type will work just fine. You could provide the  methods access (public,private) but this kind of information is usually left out. Next we have a simple line that separates the properties from the methods. Finally we have our methods or behavior declarations. These are the behaviors that this method will perform. Here we are providing the return type as well as any parameters the method will accept.

Here is a quick representation of our class as a component. It is also good to point out that our constructor is not in the class diagram. This is really just a personal preference. If you want to include it go ahead but if you don't want to you don't need to.

There is much more that you can do with UML including code generation but we will save all of that for a rainy day. This is just a quick intro what you can do using UML. It really can be a big help especially in more complex system to step back and visually construct your model.