Already a member?
Sign in
Discussion Forum
- Most Recent
- Most Active
- Keyword Tag Groups
???keywordTags???
???noTags???
Use the Discussion Forum to participate in and track threads of interest. (help)
Posting...
Note: You can enter up to [REMCHARS] additional characters.
Did you know you can edit the content of this page by clicking EasyEdit?
Did you know you can edit the content of this page by clicking EasyEdit?
| Started By | Thread Subject | Location | Replies | Last Post | |||
|---|---|---|---|---|---|---|---|
| JSiegrist | Graphitext question | Graphitext | 1 | Jul 28 2008, 5:37 PM EDT by phomer | |||
|
Thread started: Jul 26 2008, 2:46 AM EDT
Watch
While I know you're not exclusively tying Graphitext to XML, when using it as your description language doesn't XQuery give you the 'regex-like' searching to the structured description that you're describing?
Show Last Reply
|
|||||||
| JSiegrist | Common Blueprints | Common Blueprints | 1 | Jul 11 2008, 6:12 PM EDT by phomer | |||
|
Thread started: Jul 11 2008, 1:31 AM EDT
Watch
Question: Isn't what you're proposing essentially the generation of the top-level system architecture for these different systems? Something you generally see in a high-level UML diagram (assuming OOP and conventional Java practices). Treating the system as a single black box and showing its interaction(s) with external users and systems seems like it would work as well provided that you couldn't "zoom in" on the black box to decompose it into a diagram of interacting black box system components.
Show Last Reply
|
|||||||
| JSiegrist | Pipeline approach and (data) flow-based programming | Pipeline of Transformations | 3 | Jul 11 2008, 3:58 PM EDT by phomer | |||
|
Thread started: Jul 11 2008, 2:39 AM EDT
Watch
Two things about the pipeline approach. First, it seems that a pipeline could be considered the same as a functional programming approach where the result is passed through a function of composition with the first pipeline stage the innermost function and the last stage the outermost one. Second, J. Paul Morrison has done a lot of work on flow-based programming over many years. He has a book available on the subject from here that describes how such systems work and how effective they are as a programming model. It's a pity that this approach isn't more widely used.
Relevant links: J. Paul Morrison's Flow Based Programming page: http://www.jpaulmorrison.com/fbp/index.shtml Wikipedia on Dataflow: http://en.wikipedia.org/wiki/Dataflow Wikipedia on Dataflow programming: http://en.wikipedia.org/wiki/Dataflow_programming
Show Last Reply
|
|||||||
| phomer | Data Model? | Systems to Blueprint | 0 | Jul 11 2008, 3:23 PM EDT by phomer | |||
|
Thread started: Jul 11 2008, 3:23 PM EDT
Watch
I tend to see the systems by the data they manipulate. Thus a text-editor is wrapped around an arbitrary arrangement of text symbols. And IDE is wrapped around a collection of 'project' related files. A build system is wrapped around a complex set of build dependencies. A photo-editor is wrapped around a set of images and meta data. A screen sheet is wrapped around a sparse matrix of data. An instance messenger is wrapped around a text-based connection to another messenger. An emailer is wrapped around a number of different collections of email. A browser is wrapped around a massive series of interconnected 'presentation' pages (and associated technologies).
In all of the above cases, at some level of generalization, there is a focus on a single core set of data. There is often lots of auxiliary data, and some attempts at other features, but all of the above are very specific instances. Their data defines them. Interestingly enough, they complete on the variations in existing functions (and of course looks). |
|||||||
| phomer | The shell | Alternative ls description | 1 | Jun 20 2008, 1:45 AM EDT by JSiegrist | |||
|
Thread started: Jun 12 2008, 12:27 PM EDT
Watch
It is interesting that you've backed out the context to include the shell. In a very real sense, the user wants to execute ls, but the way they chose to do it might have been a shell, but it also might have been a GUI of some. Mostly, command utilities are invoked on unix through sh, ksh or csh, but they can also be invoked directly via an exec kernel call I believe. That is to say, that the ultimate goal of the user was to get an ls listing, how they 'triggered' that to execute was a technical issue depending on the context in which they were using the over-all system. Any 'stuff' (keyboard, mouse-clicks, process loading) that happens between the user deciding to apply some specific functionality and that functionality actually executing (as instructions in a process) is, I think, in a sense just part of the technical 'context' in which they have invoke the functionality, not part of the functionality itself.
Show Last Reply
|
|||||||
| phomer | technology vs. problem domain | Alternative ls description | 0 | Jun 12 2008, 6:17 PM EDT by phomer | |||
|
Thread started: Jun 12 2008, 6:17 PM EDT
Watch
From a user perspective, they need to get some type of listing of a specific directory, as part of their process. Way back, I can remember a user that would use "dir" in VMS frequently to detect when a specific batch job had finished. In that case, they always used an argument to select a specific file, which was only written at the very end of the process. If it existed, the job was complete. The business or problem domain of ls, is the listing of the information in a meaningful way to a user. The technological domain is how the command is triggered, how the arguments and context are passed into the command, and how the final output is redirected to some method of display.
I keep thinking back to blueprints in the sense that the business problem is the 2D representation of the final 3D work, where the 'materials' used to "build" that 3D thing are equivalent to the technology. In a sense, the shell, C, unix, pipes, processes, etc. are all just the 'materials' at the construction site. All the user cares about is that they can list out their file in a specific format. Even all of the specifics of the format, simple-column, multi-column, colors, etc. are essentially an extra dimension of information that the user might not need to know, in order to still make an informed choice that the essence of the ls command will meet their needs. The blueprints can give insight into the functionality, but not all of the detail. Just enough. |
|||||||
| JSiegrist | Textual Blueprint question | Simple Textual Blueprint | 1 | Jun 10 2008, 10:51 AM EDT by phomer | |||
|
Thread started: Jun 9 2008, 9:55 PM EDT
Watch
Wouldn't the screen update constitute 'side effects' in the above program description? http://en.wikipedia.org/wiki/Side_effect_(computer_science) Or does the fact that this screen update is a desired make it the expected change in the system?
Show Last Reply
|
|||||||
| phomer | Feedback | Attempt #1 | 6 | Jun 10 2008, 10:42 AM EDT by phomer | |||
|
Thread started: Jun 9 2008, 11:46 AM EDT
Watch
For any working set of software instructions, there is some complete set of all of the information that is needed by the compiler to turn these into machine code. What's interesting about that is that while there is an infinitely large number of axioms in which to decompose the instructions, there is an even larger set of all of the partial information involved. In the introduction the size of #1 is significantly larger than #2 (there are more ways to partially represent software, then there are ways to encode it).
Show Last Reply
|
|||||||
| JSiegrist | Experiment #1 | Discussion Forum | 1 | Jun 4 2008, 10:50 PM EDT by phomer | |||
|
Thread started: Jun 3 2008, 10:03 PM EDT
Watch
Hello Paul,
I propose that the first system to use in the Experiment #1 should be a document workflow system like the simple one described in the paper titled "Building Software From Data". Not only is this a fairly small system, but it's also one that you've used elsewhere as an example.
Show Last Reply
|
|||||||
| JSiegrist | Software Engineering diagrams and drawings | Discussion Forum | 3 | May 21 2008, 10:52 AM EDT by phomer | |||
|
Thread started: May 21 2008, 2:01 AM EDT
Watch
"On Tue, May 20, 2008 at 1:54 PM, John Siegrist wrote:
In looking at the sorts of diagrams/drawings that have been used in software projects, I find that nearly all the work done on diagramming besides UML were all designed with Structured Programming in mind. Some of these look quite useful, but I don't see entirely how the diagramming techniques could carry over to object-oriented systems. There are a surprising number of and geat variety to these older style diagrams."
Show Last Reply
|
|||||||
| phomer | Improvements | Software Blueprints | 0 | May 16 2008, 3:55 PM EDT by phomer | |||
|
Thread started: May 16 2008, 3:55 PM EDT
Watch
Attach comments to makes suggestions for general improvements to this site.
|
|||||||
