I am greatly confused with this term called "Design". Recently I had to develop a workflow engine in the quickest possible time. I have a team of 3 people and for 2 of them this is the first software project in their life.
I started to write Java classes representing the flow model, nodes (tasks) in the flow, the attributes of the model and transition. Then I wrote methods to execute transitions. All in all under 10 classes with 3 to 4 methods excluding the setters and getters.
It took nearly 3 hours to explain them the code and I asked them to write the Hibernate mapping files, DAOs & Services for persisting the model data and for the execution API. Things fell in place nice and smooth.
The whole thing got completed in 3 weeks.
How much time this could have taken in so called Process Oriented consulting companies?
I would have drawn UML (class diagram and sequence diagram) first as part of my design process. This could have easily taken 2 weeks. Then the developers need to have knowledge in UML to read and understand the diagrams. I could have asked the developers to first write code for the classes. That would have taken another 2 weeks easily. Then comes the persistence and service layer classes.
For me clearly the use of UML here would delay things. Consciously I have avoided this situation by not drawing the UML diagrams. Because I have never seen a case where some one need to draw UML diagrams first before coding.
So, what is that I have seen in consulting companies where there is time allocated as design phase to draw the UML diagrams?
People who stopped coding long ago (5+ years) come out with Class diagrams ( a.k.a High Level Design). People who stopped coding recently(3+ years) start drawing sequence diagrams using these classes. The design tools ( or at least Rational) have 2 types of class diagrams called logical class diagrams and design class diagrams. These sequence diagrams would use both of these interchangeably because none of the logical or design class diagrams would be complete and this happens because (Yes! you guessed it) the designer is not current in coding.
Now, the developers are left free to implement them in the way they want. Introducing instance variables for stateless classes and adding more methods etc.
After some time the design and code mean 2 different things!
But I was taken aback first when i heard the concept of Class diagrams representing HLD and sequence diagrams in LLD. This is completely absurd because sequence diagrams are the unit test cases for your class diagrams and I will not just take Class diagrams from "a" designer unless he draws a complete sequence diagram and prove that the classes have sufficient methods to solve the case.
People need to clearly understand one thing people who don't know the classes, methods, constructors etc, would not understand a UML diagram and people who understand this don't need a UML diagram. They better can see the code.
Another fact is that a designer who can clearly think of these can straight away write the code (or at least stubs or interfaces) and leave the rest to the developers.
Customers wont understand this and developers can understand the code better. More over the developers will be constrained to write the code with in the boundaries set by the designer.
And finally you dont have 2 different work products.
Now, if you go closer and see what type of architecture translates into the design of various systems :
If these are the principles behind the architecture do we really need UML? If a developer works on 2 projects like this he can start writing the code straight away.
Developers and designers work on measurements on two orthogonal axis. Developers top - down or Y axis by length of code and designers left to right on X axis by the length of the sequence diagram.
Developers increase the lines of code by calling innumerable amount of setters. Designers lengthen the sequence diagram by another mile by inserting HTTP objects such as Request, session etc. By showing how the data is stored and retrieved with them.
It leads to every one wasting time on unwanted things and produce non maintainable artifacts.
Avoid all these and understand that "Code is Design"!
I started to write Java classes representing the flow model, nodes (tasks) in the flow, the attributes of the model and transition. Then I wrote methods to execute transitions. All in all under 10 classes with 3 to 4 methods excluding the setters and getters.
It took nearly 3 hours to explain them the code and I asked them to write the Hibernate mapping files, DAOs & Services for persisting the model data and for the execution API. Things fell in place nice and smooth.
The whole thing got completed in 3 weeks.
How much time this could have taken in so called Process Oriented consulting companies?
I would have drawn UML (class diagram and sequence diagram) first as part of my design process. This could have easily taken 2 weeks. Then the developers need to have knowledge in UML to read and understand the diagrams. I could have asked the developers to first write code for the classes. That would have taken another 2 weeks easily. Then comes the persistence and service layer classes.
For me clearly the use of UML here would delay things. Consciously I have avoided this situation by not drawing the UML diagrams. Because I have never seen a case where some one need to draw UML diagrams first before coding.
So, what is that I have seen in consulting companies where there is time allocated as design phase to draw the UML diagrams?
People who stopped coding long ago (5+ years) come out with Class diagrams ( a.k.a High Level Design). People who stopped coding recently(3+ years) start drawing sequence diagrams using these classes. The design tools ( or at least Rational) have 2 types of class diagrams called logical class diagrams and design class diagrams. These sequence diagrams would use both of these interchangeably because none of the logical or design class diagrams would be complete and this happens because (Yes! you guessed it) the designer is not current in coding.
Now, the developers are left free to implement them in the way they want. Introducing instance variables for stateless classes and adding more methods etc.
After some time the design and code mean 2 different things!
But I was taken aback first when i heard the concept of Class diagrams representing HLD and sequence diagrams in LLD. This is completely absurd because sequence diagrams are the unit test cases for your class diagrams and I will not just take Class diagrams from "a" designer unless he draws a complete sequence diagram and prove that the classes have sufficient methods to solve the case.
People need to clearly understand one thing people who don't know the classes, methods, constructors etc, would not understand a UML diagram and people who understand this don't need a UML diagram. They better can see the code.
Another fact is that a designer who can clearly think of these can straight away write the code (or at least stubs or interfaces) and leave the rest to the developers.
Customers wont understand this and developers can understand the code better. More over the developers will be constrained to write the code with in the boundaries set by the designer.
And finally you dont have 2 different work products.
Now, if you go closer and see what type of architecture translates into the design of various systems :
- There will be classes that are called DTOs. These things have nothing but default constructor and public getters and setters
- There will be DAOs for CRUD functionality and a service layer which acts like a proxy or some times transaction handler
- The best improvisation that is done most of the times when the customer (who has a decent developer in their team) complains that the whole code is procedural and not OOP is making an empty base DTO and make all DTOs inheriting from that!
If these are the principles behind the architecture do we really need UML? If a developer works on 2 projects like this he can start writing the code straight away.
Developers and designers work on measurements on two orthogonal axis. Developers top - down or Y axis by length of code and designers left to right on X axis by the length of the sequence diagram.
Developers increase the lines of code by calling innumerable amount of setters. Designers lengthen the sequence diagram by another mile by inserting HTTP objects such as Request, session etc. By showing how the data is stored and retrieved with them.
It leads to every one wasting time on unwanted things and produce non maintainable artifacts.
Avoid all these and understand that "Code is Design"!
