Jump to content

Talk:Bottom–up and top–down design

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by SineBot (talk | contribs) at 16:54, 21 May 2022 (Signing comment by Sequitorian - "→Pyramidal Modeling: new section"). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconCognitive science (inactive)
WikiProject iconThis article is within the scope of WikiProject Cognitive science, a project which is currently considered to be inactive.Cognitive scienceWikipedia:WikiProject Cognitive scienceTemplate:WikiProject Cognitive scienceCognitive science

Top-down and Bottom-up Approaches in Psychology

I have added a very brief description about top-down and bottom-up processing in the world of Psychology, and I have also referenced the information that I used.Please let me know if there are some inaccuracies that need to be fixed in the information I have added.Joysabal (talk) 03:55, 16 March 2011 (UTC)[reply]

@Joysabal:The information about neurology is outdated. Researchers now think that all levels of cortical processing are subject to top-down processing. Note the discussion of recurrent feedback processing and the influence of higher-tier cortical areas on the V1 page.ParticipantObserver (talk) 19:26, 24 August 2018 (UTC)[reply]


Overall a good article on top down and bottom up design — Preceding unsigned comment added by Hir47584 (talk • contribs) 20:29, 11 September 2012 (UTC)[reply]

Too much jargon

I feel that the introductory paragraph and initial descriptions are written with far too much technical speak and are extremely hard to understand, even for a person who is quite familiar with the concepts like myself. I am a senior psychology major, and when I read the descriptions of the two processes, I was completely confused! I believe that the goal of an encyclopedic entry should be to enable a reader who is completely uneducated in a topic to walk away from reading it feeling as if they have a better understanding of the topic. This article falls far short of that, in my opinion. Snagglepuss24 (talk) 17:01, 12 April 2013 (UTC)[reply]

I'm not sure how we can remove jargon and keep it informative and accurate. Do you have a suggestion for a change? Walter Görlitz (talk) 19:10, 12 April 2013 (UTC)[reply]
            Well, I would suggest that one shouldn't talk about top-down and bottom-up as inductive or deductive approaches.  People use these terms differently, which isn't to say that 
                there are no clear meanings.  Deduction and induction are two parts in a series of systematic thinking, which also includes abduction and inference to the best explanation.  So, 
                whether you're bottom-up or top-down shouldn't affect whether you should participate in only one aspect of thinking.  That's crazy.  

           These are attitudes based on the resources one is best fit to apply in a general problem solving situation.  I think one shouldn't even be focusing on top-down/bottom-up at all.  
                It's a red herring.  In fact, people talk about a middle-out approach (Sydney Brenner, Denis Noble).  

          As for whether it takes a different meaning for design should not be relevant unless it is to clear up some communication issues.  That is, it shouldn't affect your behavior or the 
               type of experiments you decide to run whether you find out you're a bottom-up or top-down designer.  — Preceding unsigned comment added by Gahnett (talk • contribs) 04:27, 3 September 2013 (UTC)[reply]

Repeats the analysis-synthesis myth

Top-down design in software or in systems engineering can reasonably said to involve decomposition and analysis, though "analysis" is probably too broad a brush to be useful here. But in no way is top-down design more tied to deduction than bottom-up design. The referenced article contains an extremely poor account of deduction inconsistent with all modern and ancient descriptions of deduction from mathematicians and philosophers:

"Deductive reasoning works from the more general to the more specific. Sometimes this is informally called a "top-down" approach. We might begin with thinking up a theory about our topic of interest. We then narrow that down into more specific hypotheses that we can test."

All hypothesis testing (all empirical science) is inductive reasoning; it, in the strictest sense, affirms its consequence (see Quine, Hume and the rest). Both top-down and bottom-up design can equally be called inductive reasoning. The equation of synthesis with induction likely stems from Design Thinking nonsense, which relies on equivocation of two meanings of the term analysis: analysis is decomposition, hence the opposite of synthesis, which means assembly (in their view). Even if you accept this position, design, whether top-down or bottom-up, would be called synthesis. But no sense of the terms analysis and synthesis have any explanatory power toward the goal of differentiating top-down and bottom-up. — Preceding unsigned comment added by Bill Storage (talk • contribs) 06:07, 8 November 2013 (UTC)[reply]

Hello fellow Wikipedians,

I have just added archive links to 3 external links on Top-down and bottom-up design. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—cyberbot IITalk to my owner:Online 16:53, 27 February 2016 (UTC)[reply]

Top-down 'design' is analysis - not design; semantic confusion obscuring truth.

I am concerned that this an issue arising out of careless use of the word 'design'. I would like to suggest the following argument for clarity:

The terms analysis (literally cutting up of a problem) and design (drawing of a solution) are thrown around rather carelessly, as if they could be interchanged without causing semantic damage.

If you have a problem, such as an invoice system, or building a house, then you need to perform analysis as a first stage. You have the house or invoice system as your starting point. The invoice system may exist, as a paper based system; the house doesn't exist yet. However, both problems need top-down analysis as the first stage towards finding solutions. In analysis you must ask what each is to achieve i.e. the outputs - invoices, a good place in which to live. This determines what inputs are needed and how they must be processed to achieve those outputs. In the case of the invoice system the analysis will produce a schematic/logical model of the existing system showing its outputs, inputs and processing; a flowchart, data flow diagrams and so on. In the case of the house, the analysis will produce a description that fits the requirements - so many people to live there so there must be so many bedrooms with so much space; they need to cook food so a kitchen of a certain minimum size etc.

Having thus established, down to the last detail, what is required, and the relationship between those requirements as the hierarchical structure of abstractions involved, (cooker in kitchen or line total inside invoice calculation) it is then possible to move to design.

Design cannot logically be 'top down'. I suggest that this is a paraphrase made by those who fail to realize that they are talking about analysis and design, which are two quite distinct phases with distinct methods. They think that they are 'designing' but are actually analyzing and then designing. Although you could argue that so many make this mistake that that makes them right as that is what 'design' has come to mean.

Perhaps as the products of analysis are 'drawings' e.g. flowcharts and structure diagrams some have erroneously been led to think that they were designing? Yes, those charts might then form the skeleton of the design but they in-themselves are not the design, they are the products of the analysis. A caring robot to dress someone? Analysis of the existing process reveals that the socks must go on first, then the shoes. Flowchart that. Then the design for the solution must take the same flowchart/logical sequence but the act of deriving that flowchart does not belong to the design phase, it belongs to the analysis - the logical sequence belongs to the problem domain, not the designed solution. You simply cannot break that logic - unless you are in the phone booth, becoming superman, of course. When it comes to design you stick with that algorithm but adjust the way in which the processes are performed: different agent, maybe different types of socks and shoes but not a different logical order.

Design takes the fruits of analysis, the structure of the problem, with its single top and all of the decomposed abstractions (hierarchically nested groups) and selects methods of processing, from a range of options, to be applied to the problem structure. You need entities to separate the external environment from the internal? Then find/select a material that will do this - maybe bales of straw, maybe bricks - you are the designer, you find the best solution from the options. Maybe you need to do more analysis - is the thickness of the wall an issue? Maybe your analysis wasn't thorough enough? You know that you need to move the invoice from the company to the customer. You the designer have options - bicycle, drone, internet, which will it be?

To summarize, analysis and design should be seen as two semantically distinct but related processes:

Analysis is about discovery of the nature of the problem, for which a solution is required.

Design is selecting best-fits from a range of options to produce/engineer that solution.

Therefore analysis is, and can only be, top-down (start with the whole thing and end up with a definition of every part) and produces a structure representing the parts and the links between them whereas design can never be top-down as you cannot logically start with the 'whole design' i.e. the definition of the finished structure, with all of its parts in place, and then start breaking that down to start designing those parts. If you say that you are doing that then you are going back to analysis. You did not have a complete 'design' in the first place. You had a complete name for the problem you wished to solve but that can only sit at the top of the analysis. You only get a top of the design once you have completed it in every part.

Maybe many 'designs' fail because they were designs that were attempted by those who failed to complete a full analysis of the problem in the first place, rather assuming that they knew what they were to design rather than actually finding out in detail first? Lessentropy (talk) 10:22, 8 October 2017 (UTC)[reply]

Changes to Ecology Section-adding information, fixing grammar

Hello! My name is Nicole Bednarik.

I felt that the Ecology section of this article did not elaborate enough on either of the processes. I have added more details going off of what the original text said, including a citation from where I got this information from. I also fixed some grammar issues that took away from the quality of the section.

If any of my information is incorrect, could be added to further, or if I am missing any citations, please let me know or change it.

Bednariknicole (talk) 16:23, 2 May 2019 (UTC)Bednariknicole[reply]

Pyramidal Modeling

This may prove useful ... https://stevegluck.com/pyramidal-modeling.html ... — Preceding unsigned comment added by Sequitorian (talk • contribs) 16:52, 21 May 2022 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Talk:Bottom–up_and_top–down_design&oldid=1089051941"