Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

closed as too broad by gnat, Ixrec, Snowman, durron597, MichaelT Oct 10 '15 at 23:43

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

OO is a design style, not a language feature. If you're comfortable with UML and OOP, you can use it in assembly language, bash scripts, or anything. – Javier May 23 '11 at 14:51

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.)

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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:

share|improve this answer

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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.