4 ms·

mm I don't know about UML but I take two approaches. When going through concepts I use boxes with arrows and texts - I bet UML people would laugh derisively if

by Dn_Ab 16y ago

mm I don't know about UML but I take two approaches. When going through concepts I use boxes with arrows and texts - I bet UML people would laugh derisively if I claimed what I drew was UML, my shapes arent even consistent from diagram to diagram. On the next level I use type diagrams ala category theory of functions to figure out what will be needed in code. The diagrams help in terms of thinking out the concepts, also about composition (how FP manages code reuse and extensibility) and setting up guard rails to guide my thinking. The diagrams are also underpinned by a mathematical language and I can do some basic algebra with the concepts before writing code. I use only the most basic parts of category theory though. Through out this process, and most heavily at the start, I am usually also at the interactive testing out ideas.

DanielBMarkham 16y ago
I bet UML people would laugh derisively I think we have a disconnect here in most folk's opinion of UML -- what it's supposed to be used for, what kinds of people use it, how to do it "right" or not -- and actual reality. Are you communicating effectively with others, with yourself? Do you diagram enough to help solve problems? Sounds to me like you're doing just fine. Sometimes my UML is so scratchy and rough that it looks like something from an impressionist painting. That's fine -- as long as it works for me. Programming is full of little nooks and crannies where people get really tightly focused on one thing or another. web design comes to mind, or picking a programming language. They create a lot of complexity where most of the times just a little is needed. The danger here is that the rest of us take a look at that complexity and kind of throw our hands up and say "hell with it. I'm just drawing little boxes. There's no way I'm going to do "correct" UML" Part of this is because other folks make things so complex, but part of it is ourselves: many times we feel that something like a UML standard is the same as a C++ standard. They're not. If I'm coding C++, I have to conform to the standard. If I don't the code won't work. But if I'm writing a web page? I can do it just about any dang way I want to. Standards be damned. Now in practice do I use standards with things like web design? Sure -- but only as much as I personally find useful. To make it an all-or-nothing proposition is throwing the baby out with the bath water. What's required is to dive into one of these areas for a bit, learn the ropes, then use your common sense to apply just as much of it as you need to do whatever you are working on. Modeling is a powerful tool in problem solving in all sorts of areas. Having knowledge of how to model things visually is a nifty little tool to have in your back pocket. That's true even if you'll never code a bit of OOP in the rest of your life.
- Dn_Ab 16y ago
  I see what you mean. It makes a lot of sense. Its just that I take a dual approach in looking at it. You can look at simple diagrams as subsets of UML as I think you do? But personally, I would say that simple effective diagrams are a superset of UML. You get UML when you take simple diagrams and add bombastic restrictions. Its a matter of perspective and I can't say which makes more sense.
  - DanielBMarkham 16y ago
    There's a fun little book called "Back of the Napkin" (warning: affiliate link ahead) http://amzn.to/ezUvgk http://amzn.to/ezUvgk In it, the author develops his own little modeling system and talks about how to use it. While he goes a bit overboard (must be something in the water) his point is an excellent one: visual modeling conveys information at a bandwidth of an order or two of magnitude above conversations or documents. I recently had a functional project. It was a greenfield project and had a MySql backend. I wanted to use dynamic data in some parts and relational in others, fully taking advantage of both FP and the relational model. Problem was, I wasn't sure exactly how I wanted each piece to work. So, I picked up some scrap paper, a pencil, and sketched out some ideas. They sucked. A couple of days later I did it again. This time I saw some things I had been missing. It also sucked. A day after that, I sat down and sketched out what I wanted. Finally. It didn't suck. This entire process took a total of maybe 2 hours spread out over three days. A pencil and scrap paper. Soemtimes I just drew boxes with labels in them, sometimes I added aggregation or composition, sometimes I put in navigation. If I had continued to be stuck, I might have used a sequence diagram, or a collaboration diagram, or any one of a hundred other tools in my UML toolbox. The point is: I never sat down and told myself "I'm going to be doing UML right now. I didn't get out some big fancy tool, and I didn't make something that looked like the wiring diagram for a nuclear device. That's not how it works. It's a spectrum. Some of my diagrams might have looked like an ER diagram, or just a bunch of junk on paper. Doesn't matter. The process of diagramming served it's purpose of organizing and capturing my thoughts about how the system would be structured. When I needed more complexity, I reached into my UML toolkit and added new complexity. If I didn't need it, I didn't use it. UML worked for me. I didn't work for it. So I don't see UML as even being the same kind of thing as some of the other folks. There's no dual nature at all -- it's just a technical way of drawing pictures. And who doesn't need a picture now and then?

by Dn_Ab 16y ago

DanielBMarkham 16y ago

I bet UML people would laugh derisively I think we have a disconnect here in most folk's opinion of UML -- what it's supposed to be used for, what kinds of people use it, how to do it "right" or not -- and actual reality. Are you communicating effectively with others, with yourself? Do you diagram enough to help solve problems? Sounds to me like you're doing just fine. Sometimes my UML is so scratchy and rough that it looks like something from an impressionist painting. That's fine -- as long as it works for me. Programming is full of little nooks and crannies where people get really tightly focused on one thing or another. web design comes to mind, or picking a programming language. They create a lot of complexity where most of the times just a little is needed. The danger here is that the rest of us take a look at that complexity and kind of throw our hands up and say "hell with it. I'm just drawing little boxes. There's no way I'm going to do "correct" UML" Part of this is because other folks make things so complex, but part of it is ourselves: many times we feel that something like a UML standard is the same as a C++ standard. They're not. If I'm coding C++, I have to conform to the standard. If I don't the code won't work. But if I'm writing a web page? I can do it just about any dang way I want to. Standards be damned. Now in practice do I use standards with things like web design? Sure -- but only as much as I personally find useful. To make it an all-or-nothing proposition is throwing the baby out with the bath water. What's required is to dive into one of these areas for a bit, learn the ropes, then use your common sense to apply just as much of it as you need to do whatever you are working on. Modeling is a powerful tool in problem solving in all sorts of areas. Having knowledge of how to model things visually is a nifty little tool to have in your back pocket. That's true even if you'll never code a bit of OOP in the rest of your life.

Dn_Ab 16y ago
I see what you mean. It makes a lot of sense. Its just that I take a dual approach in looking at it. You can look at simple diagrams as subsets of UML as I think you do? But personally, I would say that simple effective diagrams are a superset of UML. You get UML when you take simple diagrams and add bombastic restrictions. Its a matter of perspective and I can't say which makes more sense.
- DanielBMarkham 16y ago
  There's a fun little book called "Back of the Napkin" (warning: affiliate link ahead) http://amzn.to/ezUvgk http://amzn.to/ezUvgk In it, the author develops his own little modeling system and talks about how to use it. While he goes a bit overboard (must be something in the water) his point is an excellent one: visual modeling conveys information at a bandwidth of an order or two of magnitude above conversations or documents. I recently had a functional project. It was a greenfield project and had a MySql backend. I wanted to use dynamic data in some parts and relational in others, fully taking advantage of both FP and the relational model. Problem was, I wasn't sure exactly how I wanted each piece to work. So, I picked up some scrap paper, a pencil, and sketched out some ideas. They sucked. A couple of days later I did it again. This time I saw some things I had been missing. It also sucked. A day after that, I sat down and sketched out what I wanted. Finally. It didn't suck. This entire process took a total of maybe 2 hours spread out over three days. A pencil and scrap paper. Soemtimes I just drew boxes with labels in them, sometimes I added aggregation or composition, sometimes I put in navigation. If I had continued to be stuck, I might have used a sequence diagram, or a collaboration diagram, or any one of a hundred other tools in my UML toolbox. The point is: I never sat down and told myself "I'm going to be doing UML right now. I didn't get out some big fancy tool, and I didn't make something that looked like the wiring diagram for a nuclear device. That's not how it works. It's a spectrum. Some of my diagrams might have looked like an ER diagram, or just a bunch of junk on paper. Doesn't matter. The process of diagramming served it's purpose of organizing and capturing my thoughts about how the system would be structured. When I needed more complexity, I reached into my UML toolkit and added new complexity. If I didn't need it, I didn't use it. UML worked for me. I didn't work for it. So I don't see UML as even being the same kind of thing as some of the other folks. There's no dual nature at all -- it's just a technical way of drawing pictures. And who doesn't need a picture now and then?