Software Has Shape
Software Has ShapeShape is a very fundamental concept. In software engineering it enables us to model the important characteristics of runtime systems in human friendly metaphors. Shape unifies both behavior and structure. A bundle of byte code and a machine spec can be said to define a shape in the most general sense. As software engineers we seek programming/modelling languages that reveal software shape to us. Discussing shape helps us to answer two questions:
Software has shape.
A program or other coherent collection of software (e.g. a framework or a class library) is an object (lower case) that exists in a multi-dimensional space. We can view that object through any of many windows.
Through one window, we see the shape of the inheritance hierarchy. Through another window, we see the object-ownership diagram. Through another window we see the time-series behavior of the system ... the sequence of object creations, deletions.
Through another we see the execution profile of the program running, with big piles of execution on top of some statements, and very tiny piles on others.
"Good" software has a "pleasing" shape.
If software has a "good" inheritance hierarchy, the shape of the hierarchy will be pleasing ... not too broadly branched, not too tall, fairly well-balanced.
If software is implemented efficiently, its execution profile will be relatively flat, with no big peaks indicating hot spots.
If software is "well-organized", the object ownership diagram will have clusters of tightly interconnected small objects, loosely connected to other such clusters. (Galaxy theory of software development?)
Oh yes, software has shape. -- RonJeffries
Of course Software Has Shape - the shape is the shape of the idea which it embodies. Just as Plato talked about the cave and the great archetypes of all creation, just so software has a logical and conceptual shape. It is rather like the distinction between algorithms and code - the algorithm attempts to capture the idea which is embodied in the code. Another example is the notion of a logical reality and a stylistic reality - the logical reality of a menu structure is the various logical decision paths that can be followed - the stylistic reality is the pop-up, pop-down, matrix buttons, floating ... and on and on - the two together constitute a shape which we can all experience.
What we need however is a way to CaptureTheShapeOfSoftware? and that is a pattern that is attempted unsuccessfully it seems to me with CaseTools and CirclesBoxesAndArrows and other IncompleteNotations. The whole subject is related to ConceptualModeling? and NaturalLanguageProcessing and lots of other interesting and meaty issues. -- RaySchneider
A given software product appears to be the projection of a multidimensional model held in the mind - the model containing more information than the product, typically - such as the gestalt understanding of the requirements that makes a particular solution feel like the right one.
A CASE tool should support the mental modelling process which is the primary creative act of software production. One the one hand, it should assist in the creation of the model - overcoming personal frustrations with limited brain capacity, and helping with the rotations from one point of view to another that are essential to ensure correctness and completeness. On the other, it should capture the full power of the model, for onward transmission, development - and pattern extraction.
Live in hope. -- DaveGreen
Robert C. Martin provides useful definitions of "good shape" in his book DesigningObjectOrientedCeePlusPlusApplicationsUsingTheBoochMethod?. These shape metrics apply to Java, Eiffel, and other languages. To some extent they apply to Smalltalk.
-- PatrickLogan
Software may have a shape, but it may be a unique shape for each viewer. So subjectively, SoftwareHasShape, but objectively SoftwareHasNoShape.
I may think of a piece of software, or any system of ideas, as having several different shapes. Some of your perceptions about software may resemble mine. They are all just views, projections of the overall system onto a simpler set of coordinates that allows us to think more clearly about some particularly aspect of the problem. I hope that one day we will have programming systems that allow us to manipulate these views more easily. Not just the single aspect at a time approach of Aspect Oriented Programming, where separate views are woven together, but where you cannot see the interaction of aspects except in the final weave, but systems where you can "take a node and shake it" so that a particularly aspect is uppermost, but where you can still see all the other interwoven aspects.
I'd refer y'all to my personal web page for some more detailed thoughts on what such programming systems might look like: languages that are less sensitive to code ordering would help.
-- AndyGlew
Software has a shape only metaphorically. It is invisible, and you can't feel it or weigh it. It has no volume or surface area (except metaphorically). In spite of what people say about it, it has no physical structure.
However, it has a shape in our mind's eye. We draw pictures to try to capture that shape. If we can get enough people to draw the same pictures then we might understand each other. Until then, we all see a different shape, and we end up talking past each other.
Software is not unique in this regard. Consider the phrase "the structure of the economy". You can't see, feel, or weigh the economy, either. It is a pattern of relationships and events, not an item we can observe directly. Yet economists are content to say it has structure, and a few of them even agree on what that structure is. But it is a lot easier to talk about structure and shape when we can all see the thing we are talking about.
Through one window, we see the shape of the inheritance hierarchy. Through another window, we see the object-ownership diagram. This gives sort of a mental picture of a multi-dimensional system being projected in various ways onto a two-dimensional piece of paper.
Software is not unique in this regard. Consider the phrase "the structure of the economy". One way software and the economy seem to be related in that the behavior of each is caused by information flows.
Musing... Do systems that depend on information flows have more "dimensions" than systems that depend on physical forces? Does it take more "windows/views/2D projections" to understand them?
I don't think that software (or information systems) necessarily have more dimensions than physical objects - it just depends on how you talk about the objects. For instance, consider an electrical generator. I can talk about the structure of it mechanically and describe its axles, joints, etc. I can use diagrams, drawings, models, whatever I need to show how the pieces fit and work together.
On the other hand, I can also describe it in terms of the magnetic lines of force and its electrical properties - using Maxwell's equations. These are two completely different views of the same object. It is much the same as looking at a software object's inheritance structure, its composition structure, its message flows, etc.
-- KyleBrown
Having reread this section after a very long time, I think that one of the previous authors (who didn't sign) might have hit on something. When I'm talking about an electrical generator having multiple "shapes" (both a mechanical and electromagnetic shape), the only reason it has > 1 shape is because it has a component that is energetic. Do we all remember Shannon's theorem of how Information == Entropy? And the thermodynamic definition of Entropy? Maybe there is something to describing this "information flow" stuff...
-- KyleBrown (getting very metaphysical)
Those people who say that software has shape only metaphorically just don't get it. I bet that is because they are not Smalltalk programmers. The inheritance hierarchy is not a metaphor. The browser "draws" the diagram for you. Similarly, the object-ownership diagram is not a metaphor, though the tools don't do as good a job drawing it. The sequence of object creations and deletions is not a metaphor. These are real shapes, at least as real as the shape of your house. Sure, you have to be trained to see that shape, but people who have never seen a house have to be trained to see the shape of a house, too.
When we store code as files, the layout of the files is one of the shapes of the system.
If you can generate your UML diagrams from the source code, then the UML diagrams are one of the shapes of the system.
Any diagram you can automatically generate from the source code is part of the shape of the system. It is not subjective, it is objective. There are lots of them. There are even lots of them that are useful.
If not shape, software surely has dimensions, especially object-oriented software: the depth of derivation and composition; the height of libraries and frameworks; the magnitude of source and binaries; the temporal performance; the lineage of programmers and programs.
Shapes are entities of extent in dimension. Dimension is a continuum of a measurable quality. The dimensions of a shape are the measured extents of its qualities. I think this fundamental and beyond mere metaphor.
Accordingly, anything with measurable qualities has shape. The number of dimensions of an entity are the number of orthogonal qualities that can be measured on it. A rectangle has two dimensions, length and width. Other qualities could be measured, such as area, but area is not orthogonal to length and width. You might say that a square in the x-y plane exists at z=0 in the x-y-z space; but the innate quality of the square is still two dimensional. Its measure in the z dimension is a characteristic of its locations, not its shape. Location is additional information.
Likewise, software has both shape and location.(All entities and all information does). To capture the full shape of an entity is to know everything innate to it. To capture its location as well, is to know everything about it. To capture a software entity's shape, we must measure in the orthogonal dimensions in which the entity extends. To capture its location we must measure in "all" orthogonal dimensions. Clearly, only partial location is possible, but what about shape. Can we measure software shape? Can we discover what dimension to measure?
Question: What are the dimensions of software?
Question: What does representation/metaphor have to do with it?
Question: What role do projections play?
On NarrowTheInterface and CritiqueOfUseCases I mumble something about software being a volume in multidimensional discrete space. How useful that is to this discussion, I'm not entirely sure.
Likewise, software has both shape and location. (All entities and all information do.) To capture the full shape of an entity is to know everything innate to it. To capture its location as well, is to know everything about it.
If you buy that software is a volume in discrete space, this sure sounds like a matrix to me. If you consider a vector in the matrix to be a point inside the volume, the vector has a location. The relationships between the vectors gives you the shape. -- SunirShah
Software has no shape because you have failed to define the shape for software. As a matter of fact you didn't even try.
Please StopUsingMetaphors
Some specific examples of shapes mentioned above:
I don't think its intended use is as an elaborate C.S. theory. Maybe it's just an added adjective in our software engineering vocabulary. Maybe it's just a poem.
Oh, yes. What if my inheritance tree is not a tree but an directed acyclic graph. What if I don't use Smalltalk, what if I don't use OO at all? And what exactly is a shape? You should be able to DEFINE , or to DESCRIBE in clear terms ShapeOfSoftware?, and think of software development in general.
Even coding in assembly is software development. Source code layout is irrelevant, it doesn't get executed, as a matter of fact the compiler is happy to take everything in a single line. UML is controversial in itself, and quite a few researchers have signaled several shortcomings, therefore I doubt you can define a set of canonical UML diagrams for every possible software, from where you can derive a shape.
Therefore even if I sound annoying please StopUsingMetaphors. The other descriptions of the shape of a software were metaphorically themselves. If you really manage to define the shape of a software in general, you might want to define some objective qualities of the shape.
If you want to do poetry, please advertise it as such.
So we are only ever allowed to use words and expressions which we can define with precision and for the general case? And if we don't, we have to stick warning signs all over? Oh my. --FalkBruegmann
Well, unless you try to have a pattern such as Software Written In Smalltalk Has Shape, you definitely ARE in the general case. It's a matter of simple fairness that when you talk about software development, you should consider all kinds of software. As to the 'precision' of your words and expression, if this is too tough to ask, at least some clarity and common sense is beneficial.
Is 'shape' another word for structure? I tend to use the word 'physical' a lot to differentiate a specification from an implementation. Some people don't like that either. -- RIH
The initial presumption of this page (or so it seems now) was that it spoke about ObjectOrientedProgramming. Note that you can write ObjectOrientedCode? is assembly language, and NotObjectOrientedCode? is Smalltalk. For carefully written ObjectOrientedProgram?s, all the visualizations discussed earlier produce some global uniform shape, so you can talk about the ShapeOfObjectOrientedSoftware?, but maybe not about ShapeOfSoftware? in other paradigms. -- AmirLivne
[EditHint: AmirLivne, did you mean to write "Note that you can write ObjectOrientedCode? in assembly language, and NotObjectOrientedCode? in Smalltalk." ?]
Maybe it's time for a few definitions.
Merriam-Webster defines shape thusly: "1 a : the visible makeup characteristic of a particular item or kind of item. b (1) : spatial form or contour (2) : a standard or universally recognized spatial form." (It defines it six other ways as well, and that's just the noun form, but this seems to be the way people are talking about shape. I don't even think we'd get much argument that software has a "form of embodiment" or "a mode of existence or form of having identifying features.")
b1 and b2 only make sense if "space" is assumed to be something non-physical, or at least partially non-physical. At least, bits on the storage medium are something no one in this discussion seems to care about. Certainly, it would be difficult to assert that all software has a "standard or universally recognized spatial form." Especially after reading the above.
So, we're left with 1a, or b1 with a non-physical (at least, non-exclusively physical) definition of space. A case could be made for either. For instance, pretty much all executable code is readily rendered as a series of 1's and 0's (or, by extension, hex, octal, decimal and what-have-you). Of more relevance to the discussion, source code in certain languages can be recognized from inspection in an editor as being functionally decomposed. There is even the notion of "programming style," which probably has more to do with this visual impression of source code than anything else - the way in which comments are used, the uniform placement of subroutines above (or below) the main execution line, using particular idioms like the trinary operator or exception handling. These idioms are generally done for the benefit of the programmer, not the computer, and the programmer's read-interface to the computer is primarily visual. Some people even get fussy about indentation and newlines. Quite a lot of people, actually. :)
I think, then, that a strong argument can be made that different "dimensions" of software (that is, different artifacts representing the software to something or someone) can be said to have shape, under definition 1a above. You can make an argument for b1, too. But does software have shape? What, exactly, is software, anyway? That's the tricky part. "Something used or associated with and usually contrasted with hardware" is the first definition in m-w.com. The second is marginally more helpful, but I think we have a better handle on it already than they do. Which isn't saying much.
WhatIsSoftware seems like a bit of a rat-hole to me. So try this: the general definitions above seem applicable to most software most of the time, but they're too vague to be useful in writing a good pattern. Or if they're not too vague, the implications one should get from them (and should include in a pattern of this type) need to be clearer. Does software have shape? I would say probably, in most (if not all) cases. But of what use is that to us? Does it lead to a way of representing software? Is it a CodeSmell when we're trying to integrate software of one shape with software of another? Are there particular shapes that are more desirable than others at particular points in time?
What about discrete or continuous changes in shape through the various dimensions of software? (I would prefer to make the abstractions of my interface match the logic of my implementation where possible, but there are exceptions like the adapter and bridge patterns.) Do the shapes of problem domains like embedded or distributed platforms lend themselves to particular software shapes? (Or "problem spaces." I keep trying to pull the geometry language out, and it keeps reinserting itself.)
I think if something useful is to come out of this discussion, it will probably lie in answering questions like these. Assuming that people are looking for something useful, that is. :) -- PhilGroce
I think of DesignPatterns being the "shape" of software in the same way that configurations of stones are the "shape" of GameOfGo. See http://senseis.xmp.net/?Shape. -- KarlKnechtel
It seems to me like there is a lot of talking past one another here. Of course software doesn't have a shape in the sense that it can be unambiguously embedded into three dimensional space. However, software does have structure. Maybe using that alternate word would clear some of this up?
Can that "structure" be presented visually?
[I assume you mean graphically, since I've never heard of software being presented as sound, smell, touch or taste. Everything can be presented graphically. That doesn't mean it makes it easier to understand or manipulate.]
VisualProgramming VisualProgrammingLanguage GraphicalProgrammingLanguage NassiShneidermanDiagrams VisualLanguage
all seem to show that software (can) have shape; but then there is
contention: SoftwareIsMechanistic?: it can be modeled, and this model will have a definite shape. A good model will reveal information about the system, even if you can't spin the wheels on the model.
EditText of this page
(last edited February 19, 2006)
or FindPage with title or text search