Right now, I'm trying to learn a well documented software engineering. I knew that if we code using Object Oriented concept, we can do software design concept using UML. But what if we code using procedural programming, how we do software design? as my understanding, UML is for OOP.
And do you have any references in internet? Please advices and correct me if I'm wrong about UML.
Go read Code Complete, Second Edition. It has a lot of advice about software design, and almost all of it is very, very applicable to procedural code. (The original edition of the book came out before OO code was popular.)
UML is not just for OOP. Modularity and separation of concerns comes into play in any large scale system and it doesn't matter whether your language falls into the procedural, functional, declarative, or object oriented paradigm. There is no reason you can't adapt the concepts and diagrams in UML to document whatever software you're developing.
Some of the concepts such as generalization and realization in a class diagram might not make sense, but a "class" module could be used to represent another unit of compilation. Object diagrams as a whole might not make sense. But deployment, component, activity, state, use case, sequence, and timing diagrams would make sense outside of an object-oriented environment.
UML provides you with a common language and set of symbols for modeling. As long as there is a mapping between your target language and the set of symbols used, UML can be used, and I'd support it since it would make communicating your design much easier. If a certain concept (and therefore a certain symbol) doesn't make sense in your language, make sure you don't use it.
The design technique I made the best experiences with regarding 6+ years procedural programming (and 10+ years OO/UML) leading to clean and easy to test code is Flow Design:
And its "translation" to methods:
There is no well marked line between OOP and procedural. Just saying, there's a number of people (GTK APIs used to, IIRC) that map OOP over procedural languages.
And then there's a silent majority that develops incrementally by starting from a main(), adding objects as they seem fit, using them as tools and not like Platonic Ideas. When things are getting too big to handle, they write classes and diagrams like everybody does.
Then again, there's still some big design before finalizing contract in software engineering, so you may wonder how procedural-first firms could handle this. First of all there are not many of those firms, as it's harder to split tasks without objects.
Then, you know, there where many. They used control flow diagrams. With diamonds and rectangles and stuff. Nowadays they could use statecharts, and, in protocol interactions over network or inter-process, sequence diagrams.
