2 added 383 characters in body
source | link

UML is to a program what the plans are to a building in my humbe view. Plans alone aren't a design off course, you need material specifications (used code tools) for that, a general view of the building (some schematic representation of the whole software, including GUI designs), how the building is planted in the surroundings (a clear scheme of how the software interacts with others / is planted within the OS), how it stands to the climate and soil (interaction with hardware), ... Plenty of books on design try to define it, but as with so many things in science, every scientist has a bit his own definition.

Now, I also don't agree with your observation that you can't derive the code from UML. You can, if you have the additional information mentioned. But the real code isn't the design any more, that's the artifact. You can't extract the real stones and concrete from a plan either, but you need the plan to put the real stones and concrete in the correct form and the correct place.

In that light, I found following article interesting (I met it in a different context when I was looking for graph software, but nonetheless...). The graph approach to describe a design made sense to me, although -again- this is only part of the design in my opinion. The interesting thing is that this approach gives a framework to understand and refactor designs (as opposed to refactor the software), as indicated in following papers :

There are a whole lot of other approaches to describe (part of) the design, like structured design (HIPO Charts) or integrated program design, design patterns, ...

Still, as long as there's no industry standard set, it's unlikely to get a "regular" way to express this. Even after 50+ years. And be honest, if your company finds a good way to express a design, would you share it with the world?

UML is to a program what the plans are to a building in my humbe view. Plans alone aren't a design off course, you need material specifications (used code tools) for that, a general view of the building (some schematic representation of the whole software, including GUI designs), how the building is planted in the surroundings (a clear scheme of how the software interacts with others / is planted within the OS), how it stands to the climate and soil (interaction with hardware), ... Plenty of books on design try to define it, but as with so many things in science, every scientist has a bit his own definition.

In that light, I found following article interesting (I met it in a different context when I was looking for graph software, but nonetheless...). The graph approach to describe a design made sense to me, although -again- this is only part of the design in my opinion. The interesting thing is that this approach gives a framework to understand and refactor designs (as opposed to refactor the software), as indicated in following papers :

There are a whole lot of other approaches to describe (part of) the design, like structured design (HIPO Charts) or integrated program design, design patterns, ...

Still, as long as there's no industry standard set, it's unlikely to get a "regular" way to express this. Even after 50+ years. And be honest, if your company finds a good way to express a design, would you share it with the world?

UML is to a program what the plans are to a building in my humbe view. Plans alone aren't a design off course, you need material specifications (used code tools) for that, a general view of the building (some schematic representation of the whole software, including GUI designs), how the building is planted in the surroundings (a clear scheme of how the software interacts with others / is planted within the OS), how it stands to the climate and soil (interaction with hardware), ... Plenty of books on design try to define it, but as with so many things in science, every scientist has a bit his own definition.

Now, I also don't agree with your observation that you can't derive the code from UML. You can, if you have the additional information mentioned. But the real code isn't the design any more, that's the artifact. You can't extract the real stones and concrete from a plan either, but you need the plan to put the real stones and concrete in the correct form and the correct place.

In that light, I found following article interesting (I met it in a different context when I was looking for graph software, but nonetheless...). The graph approach to describe a design made sense to me, although -again- this is only part of the design in my opinion. The interesting thing is that this approach gives a framework to understand and refactor designs (as opposed to refactor the software), as indicated in following papers :

There are a whole lot of other approaches to describe (part of) the design, like structured design (HIPO Charts) or integrated program design, design patterns, ...

Still, as long as there's no industry standard set, it's unlikely to get a "regular" way to express this. Even after 50+ years. And be honest, if your company finds a good way to express a design, would you share it with the world?

1
source | link

UML is to a program what the plans are to a building in my humbe view. Plans alone aren't a design off course, you need material specifications (used code tools) for that, a general view of the building (some schematic representation of the whole software, including GUI designs), how the building is planted in the surroundings (a clear scheme of how the software interacts with others / is planted within the OS), how it stands to the climate and soil (interaction with hardware), ... Plenty of books on design try to define it, but as with so many things in science, every scientist has a bit his own definition.

In that light, I found following article interesting (I met it in a different context when I was looking for graph software, but nonetheless...). The graph approach to describe a design made sense to me, although -again- this is only part of the design in my opinion. The interesting thing is that this approach gives a framework to understand and refactor designs (as opposed to refactor the software), as indicated in following papers :

There are a whole lot of other approaches to describe (part of) the design, like structured design (HIPO Charts) or integrated program design, design patterns, ...

Still, as long as there's no industry standard set, it's unlikely to get a "regular" way to express this. Even after 50+ years. And be honest, if your company finds a good way to express a design, would you share it with the world?