Diagrams are usually a good way to convey an idea. There is an intrinsic human ability to understand abstract instructions in this form. It is not surprising that in designing software we would look for a way to express it as such. UML diagrams are not only helpful as a [mockup]blue_print in designing but also as format to present the main idea in a more straight-forward way to non-tech assets.
I should really explain what I mean by a non-tech asset, this term could be used somewhere else for a different purpose –if you do so know a better word for my definition, please leave a message. I think of non-tech assets as a broad spectrum of individuals that may be involved directly or indirectly to the end-product. There also may be closer relations amongst different expertise that makes part of a certain project alien to a particular group –also tech aware but not omniscient. This is my philosophical attempt at saying some people need to understand how something works not necessarily why it works –this tie well with obfuscation I believe.
So, by the definition given above and by the readings this week it becomes clearer that there is a choice to be made in UML diagrams –should it be all-expressive or partially-expressive? I believe that most tend to stay at the partially-expressive end, which is best because it uses obfuscation to increase clarity
Throughout the last classes (school class) we have been discussing how to optimize code by looking at UML diagrams. The information on the diagram provided us with the information necessary to see the problems accrued by the code’s configuration. So, it is safe to say that there is a minimum amount of information that needs to be in a diagram in order to be fully helpful. It is also a safe bet to say that a lot of the implementations that don’t affect the relationship amongst the classes (not school classes) is too much information. I think that if we code clean (no pun intended) the implementation speaks for itself and it doesn’t need diagram representation, which should only be necessary when we look at many classes interacting.
This week’s readings mentioned a standardization problem. There are a lot of ways to use UML for a variety of subjects. A public (tech public) uproar from a previous attempt to standardize was mentioned. The complexity lies in how many ways these diagrams are used. Maybe software developers would benefit from such standardization. As far as I know if I had to work with a team, I would like them to produce diagrams that follow a particular set of rules instead of looking at a jungle of too much and too little. Fowler says it best in this quote “… there is no hard-and-fast correspondence between the UML and code, yet there is a similarity. Within a project team, team conventions will lead to a closer correspondence” (Fowler, 2004).
References
Fowler, M., 2004. UML destiled . In: s.l.:Pearson Education, inc.
technology blog 