#begin
The last section of the chapter is about circles and arrow, which effectively just means CASE tools, UML or diagramming. I think its funny since even though UML is a standard its still not widely used. I remember an interview with Simon Brown, the inventor of the C4 model where he said that UML is world-famous, in The Netherlands. And I think I recognize the same, in Dutch universities UML is the go to diagramming methodology. Its been hammered into my brain as well! But the important part is that everyone in your company should use the same standard to smoothen the communication. If one team is using UML, the other the C4 model, and others are using some TOGAF notation it will end up being a mess.
David and Andrew say again, don’t be a slave to formal methods. And I agree, when you are too dogmatic about some notation you might find yourself making way to detailed diagrams. So let me give you an example. Let’s say we need to design some class diagram. There are multiple levels of details you can add here. First we could just draw the classes and interfaces with some basic arrows between them. Second level of abstraction might be to add cardinality and change the notation of the arrows to match the relationships between classes conforming to UML specification. So simple arrows might be changed in associations, aggregations and compositions. Third level of abstraction would be to add the public and private methods and properties. Now, in most, if not all cases the first or second level of abstraction is sufficient. I don’t think you will ever add the third level, listing all the public and private methods and properties on classes since they change far too often and you can generate such diagrams anyway. There was a time in the 90’s where the idea was to generate entire systems based on the diagrams using these CASE tools. I a waterfall era that might have looked like a great idea but now it just wont work. If you have a healthy refactoring practice, these diagrams go out of date really quickly and will mismatch the underlying code.
But to get back to the book; David and Andrew claim that formal methods have some serious shortcomings.
They say that; “most formal methods capture requirements using a combination of diagrams and some supporting words”. Written communication is still the leading form transferring information to the stakeholders who are interested in the requirements. Also, when using a formal method like UML, your stakeholders must also understand how to read the diagrams. If they don’t understand UML, its practically useless and a simple boxes and lines diagram might have been more clear.
Their second claim is that: “formal methods require and encourage specialization”. Developers use class and sequence diagrams, architects use component and deployment diagrams, and database folks use entity relationship diagrams for example. I think these different types of diagrams are very useful since they are used in different contexts. What David and Andrew mean is that if there are two groups, one trying to gather all requirements and another who are just drawing diagrams you are doing it wrong. The same single group that gather the requirements should make the diagrams as well. Because if you don’t there will be a mismatch in communication.
And the third reasons why formal methods have some problems is: that the formal methods do not match with the type of systems David and Andrew like to write. They have made it clear that they like to write adaptable, dynamic systems using meta-data to change the application at runtime. They say that most formal methods describe static diagrams. And I’m not so sure how that would be a limitation. UML contains many dynamic diagrams like sequence, activity an data-flow diagrams. Then again, why would a system taking in meta-data as a means of configuration be any different from programs that don’t in diagramming context? I mean we can still model such systems using static diagrams. The classes and components are still there, relationships still exist even when they are dynamic vs. static.
So should we use formal methods? Well of course! Just remember that formal methods are just one tool on your superhero utility belt. You will find, during analysis that some formal method will be useful, or not. If it’s useful simply use the formal method and embrace it. David and Andrew say that you should never become a slave to any methodology. Pragmatic Programmers look at methodologies critically and extract the best for each of them and mold them into working practices. Practices will be refined constantly and your process will improve over time. Never accept the rigid confines of a methodology as limits of your world. Wow, I mean. That’s a powerful statement. I really like that!
I think that’s a great way to end this chapter. But let’s recap for a little bit. In this episode we talked about the requirements pit. We don’t want to be digging for requirements endlessly. And when faced with impossible puzzles we should maybe change our approach, analyze the constraints and see if they are actually there or are a symptom of the approach you have taken. Then we discussed the difference between procrastination and good judgment to wait before starting something new. Do some prototyping or use a tracer bullet approach to start your project, or well, simply wait until things get clearer. We also discussed the specification trap. Don’t over analyze and try to describe every minute detail of a specification. Remember that developers like to have some creativity in their work and taking this away will make them unhappy among other reasons. And last we talked about circles and arrows. Don’t be a slave to formal methods!
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments