Loading ...
Sorry, an error occurred while loading the content.

“Loosely Coupled” components in Agile Programming

Expand Messages
  • chiluvuri1
    I have been working of an agile software development process, which can be used to develop online GUI applications. I believe, it meets many of the goals of
    Message 1 of 21 , May 2, 2006
    • 0 Attachment
      I have been working of an agile software development process, which
      can be used to develop online GUI applications. I believe, it meets
      many of the goals of Agile programming, and I wondering, if you could
      verify that.

      Let me introduce the process. To understand the process, first you
      must accept that it is possible to build GUI Widgets that are
      functionally equivalent to traditional GUI Widgets, such as GUI
      Classes for Java/Swing.

      Please review the following web page and full proof, if you can spare
      30 minutes. If you cannot spare that kind of time, please except that
      it is possible to understand the rest of the process.
      http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm
      http://cbsdf.com/misc_docs/why-gui-api.htm
      http://cbsdf.com/misc_docs/gui-api-brief.htm

      Our "loosely coupled" component based software development process
      requires developers to build "Component Factories", which generate
      the components. Please find examples at:
      http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm
      http://cbsdf.com/technologies/component-factory.htm

      Then the process to build the application is illustrated in the
      following web page:
      http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm

      Please pay attention to the new concept "unified handle", how one can
      use the unified handle to remove any component, even it has 20
      subcomponents and 100 Objects.

      Please carefully review last 6 paragraphs and especially last 3
      paragraphs, which I think matches the goals of "Agile Programming".
      The CF/AC offers higher-level abstraction and since components
      are "loosely coupled", it would be much simpler to refine or replace.

      I am new to this group and please for give me if I miss understand
      the goals of agile programming. I have been working for years to
      absolutely make sure that all of our CBSDF processes work, but I am
      not sure if my goals are similar to the goals of agile programming
      (but I feel they are similar).

      Best Regards,
      Raju
    • Steven Gordon
      Raju, One of the goals of agile software development is to only build what the customer needs. Building more increases complexity which increases development
      Message 2 of 21 , May 2, 2006
      • 0 Attachment
        Raju,

        One of the goals of agile software development is to only build what
        the customer needs. Building more increases complexity which
        increases development costs and maintenance costs as well as making it
        more difficult to respond to the inevitable changes in requirements.

        Another goal is rapid and frequent delivery of working software in
        small increments in order to garner feedback to make sure that the
        software is what the customer wants and needs (and no more). I find
        that rapid and frequent delivery of working software often helps the
        customer figure out what they really want and need (even more
        effectively than weeks of requirement workshops).

        Does your approach support iterative development, delivery of
        increments of working software every 2 weeks, and easy adaptation to
        requirement changes?

        Steve

        On 5/2/06, chiluvuri1 <chiluvuri1@...> wrote:
        > I have been working of an agile software development process, which
        > can be used to develop online GUI applications. I believe, it meets
        > many of the goals of Agile programming, and I wondering, if you could
        > verify that.
        >
        > Let me introduce the process. To understand the process, first you
        > must accept that it is possible to build GUI Widgets that are
        > functionally equivalent to traditional GUI Widgets, such as GUI
        > Classes for Java/Swing.
        >
        > Please review the following web page and full proof, if you can spare
        > 30 minutes. If you cannot spare that kind of time, please except that
        > it is possible to understand the rest of the process.
        > http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm
        > http://cbsdf.com/misc_docs/why-gui-api.htm
        > http://cbsdf.com/misc_docs/gui-api-brief.htm
        >
        > Our "loosely coupled" component based software development process
        > requires developers to build "Component Factories", which generate
        > the components. Please find examples at:
        > http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm
        > http://cbsdf.com/technologies/component-factory.htm
        >
        > Then the process to build the application is illustrated in the
        > following web page:
        > http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
        >
        > Please pay attention to the new concept "unified handle", how one can
        > use the unified handle to remove any component, even it has 20
        > subcomponents and 100 Objects.
        >
        > Please carefully review last 6 paragraphs and especially last 3
        > paragraphs, which I think matches the goals of "Agile Programming".
        > The CF/AC offers higher-level abstraction and since components
        > are "loosely coupled", it would be much simpler to refine or replace.
        >
        > I am new to this group and please for give me if I miss understand
        > the goals of agile programming. I have been working for years to
        > absolutely make sure that all of our CBSDF processes work, but I am
        > not sure if my goals are similar to the goals of agile programming
        > (but I feel they are similar).
        >
        > Best Regards,
        > Raju
      • chiluvuri1
        Steve, Thanks for the info. Your summary explanation is very useful. ... to ... My objective is also exactly the same. The approach we have taken is to use
        Message 3 of 21 , May 2, 2006
        • 0 Attachment
          Steve,

          Thanks for the info. Your summary explanation is very useful.

          You said:
          >> Does your approach support iterative development, delivery of
          >> increments of working software every 2 weeks, and easy adaptation
          to
          >> requirement changes?

          My objective is also exactly the same. The approach we have taken is
          to use "loosely coupled" components (or subsystems), so that each
          subsystem is highly autonomous and can be refined or replaced with
          very little effect on other subsystems (no matter how big and complex
          the subsystem is).

          To reduce the complexity of large subsystem, it in turn built
          using `loosely coupled" components. So each subsystem is small enough
          to handle quickly. This web page provide a quick overview using
          figures:
          http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm

          Using this process, it is possible to eliminate over 70% to 90% of
          the complexity arises from irrational dependencies; we have to
          create, if we use Object Oriented programming. In the OOP, there is
          no way to contain the complex tangled dependencies between Objects,
          which makes nearly impossible to remove a large subsystem.

          We have invented a process where, for example, if a large component
          contains many subcomponents, all of them are packaged as single unit
          and handled through an unified-handler. Please review:
          http://cbsdf.com/technologies/LC-CBSD.htm
          http://cbsdf.com/technologies/OOP-indivisible-components.htm

          Using this process it is possible to create more complex online GUI
          applications than possible using traditional GUI platforms, such as
          java/Swing. Please see examples in the web site.

          Please forgive me. I did not created that many DHTML components and
          more focusing on next generation Vector Graphics, because, they give
          me lot more control and flexibility. I personally prefer them to
          DHTML/JavaScript.

          However, you could find few complex data-driven DHTML component
          hierarchies, which are practically impossible today. Using our
          technology, such components can be composed or decomposed in minutes,
          as shown, in the code below them.

          You can find many SVG component hierarchies, which also can be
          composed are decomposed in minutes. They are built by setting up the
          supply-chain of "Component factories" above.

          I greatly appreciate if you could review when you have time.
          Unfortunately, the technology may take couple of hours to understand,
          because it introduces many new concepts (which have been created over
          period of several years). So, you may do it any time in next few
          months, when you can spare some time.

          Best regards,
          Raju

          --- In extremeprogramming@yahoogroups.com, "Steven Gordon"
          <sgordonphd@...> wrote:
          >
          > Raju,
          >
          > One of the goals of agile software development is to only build what
          > the customer needs. Building more increases complexity which
          > increases development costs and maintenance costs as well as making
          it
          > more difficult to respond to the inevitable changes in requirements.
          >
          > Another goal is rapid and frequent delivery of working software in
          > small increments in order to garner feedback to make sure that the
          > software is what the customer wants and needs (and no more). I find
          > that rapid and frequent delivery of working software often helps the
          > customer figure out what they really want and need (even more
          > effectively than weeks of requirement workshops).
          >
          > Does your approach support iterative development, delivery of
          > increments of working software every 2 weeks, and easy adaptation to
          > requirement changes?
          >
          > Steve
          >
          > On 5/2/06, chiluvuri1 <chiluvuri1@...> wrote:
          > > I have been working of an agile software development process,
          which
          > > can be used to develop online GUI applications. I believe, it
          meets
          > > many of the goals of Agile programming, and I wondering, if you
          could
          > > verify that.
          > >
          > > Let me introduce the process. To understand the process, first you
          > > must accept that it is possible to build GUI Widgets that are
          > > functionally equivalent to traditional GUI Widgets, such as GUI
          > > Classes for Java/Swing.
          > >
          > > Please review the following web page and full proof, if you can
          spare
          > > 30 minutes. If you cannot spare that kind of time, please except
          that
          > > it is possible to understand the rest of the process.
          > > http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm
          > > http://cbsdf.com/misc_docs/why-gui-api.htm
          > > http://cbsdf.com/misc_docs/gui-api-brief.htm
          > >
          > > Our "loosely coupled" component based software development process
          > > requires developers to build "Component Factories", which generate
          > > the components. Please find examples at:
          > > http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm
          > > http://cbsdf.com/technologies/component-factory.htm
          > >
          > > Then the process to build the application is illustrated in the
          > > following web page:
          > > http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
          > >
          > > Please pay attention to the new concept "unified handle", how one
          can
          > > use the unified handle to remove any component, even it has 20
          > > subcomponents and 100 Objects.
          > >
          > > Please carefully review last 6 paragraphs and especially last 3
          > > paragraphs, which I think matches the goals of "Agile
          Programming".
          > > The CF/AC offers higher-level abstraction and since components
          > > are "loosely coupled", it would be much simpler to refine or
          replace.
          > >
          > > I am new to this group and please for give me if I miss understand
          > > the goals of agile programming. I have been working for years to
          > > absolutely make sure that all of our CBSDF processes work, but I
          am
          > > not sure if my goals are similar to the goals of agile programming
          > > (but I feel they are similar).
          > >
          > > Best Regards,
          > > Raju
          >
        • SherlockSridhar
          On Tue, 02 May 2006 14:33:57 -0000, chiluvuri1 said: ... Raju, I appreciate the effort you are taking to ensure that
          Message 4 of 21 , May 2, 2006
          • 0 Attachment
            On Tue, 02 May 2006 14:33:57 -0000, "chiluvuri1" <chiluvuri1@...>
            said:
            <snip>
            > Steve,
            >
            > Thanks for the info. Your summary explanation is very useful.
            > My objective is also exactly the same. The approach we have taken is
            > to use "loosely coupled" components (or subsystems), so that each
            > subsystem is highly autonomous and can be refined or replaced with
            > very little effect on other subsystems (no matter how big and complex
            > the subsystem is).
            </snip>

            Raju,

            I appreciate the effort you are taking to ensure that your process
            closely aligns with the Agile principles. Unfortunately, it is extremely
            difficult for some of us to dive into the links that you have sent for
            the same reasons you have pointed out. At the risk of paraphrasing
            Steven, I can only say this much:

            1. You do Iterative development, where the duration for each iteration
            is small enough for the code developed to be trashed, but large enough
            for some meaningful output.
            2. Each iteration produces a potentially shippable software.
            3. Customer provides feedback for the output.
            4. Customer decides what will get implemented for each iteration.
            5. WYNIWYG (what you need is what you get), not WYWIWYG (what you want
            is what you get).

            Of course, for such a rapid delivery model, there needs to be some
            supporting practices without which you will be working on a "Band-Aid"
            model. Such practices include Automated Testing, Continuous Integration,
            Simple Design and of course refactoring.

            I am using XP terminology for my response, but you will find that most
            Agile methods would have equivalent practices.

            Please map each of the practices to the practices in your process. If
            you are doing most of them, you are definitely doing Agile. Kindly
            remember that either you do or do not. There are no "partial"
            implementation of practices (you may implement 80% of all practices, but
            each practice you implement must be 100% - I hope you understand the
            difference).

            Regards
            Sherlocksridhar
            Regards
            Sridhar
            sherlocksridhar@...
            Sherlocksridhar.blogspot.com
            -----------------------------
            "A lot of preconceptions can be avoided by simply trying them out" - Bruce Eckel

            --
            http://www.fastmail.fm - Access all of your messages and folders
            wherever you are
          • chiluvuri1
            Sridhar, ... Some of the Agile programming concepts are very interesting. I will study more and try to create better processes for refactoring for my loosely
            Message 5 of 21 , May 3, 2006
            • 0 Attachment
              Sridhar,

              Thank you for detailed description, specially your short summary:

              > Such practices include Automated Testing, Continuous
              > Integration, Simple Design and of course refactoring.

              Some of the Agile programming concepts are very interesting. I will
              study more and try to create better processes for refactoring for my
              loosely coupled components.
              http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm

              I think, Loosely coupled components are better than Objects, for
              example to implement the concepts, (i) they can be designed to
              automatically self test its interfaces to detect broken interfaces,
              when plugged-in, and (ii) They can be integrated automatically that
              substantially cuts the cost of integration.

              I believe, Automation of these parts is key and I will try to build
              fully automated processes, hence reduce the complexity of incremental
              changes.

              Best Regards,
              Raju

              --- In extremeprogramming@yahoogroups.com, "SherlockSridhar"
              <sherlocksridhar@...> wrote:
              >
              > On Tue, 02 May 2006 14:33:57 -0000, "chiluvuri1" <chiluvuri1@...>
              > said:
              > <snip>
              > > Steve,
              > >
              > > Thanks for the info. Your summary explanation is very useful.
              > > My objective is also exactly the same. The approach we have taken
              is
              > > to use "loosely coupled" components (or subsystems), so that each
              > > subsystem is highly autonomous and can be refined or replaced
              with
              > > very little effect on other subsystems (no matter how big and
              complex
              > > the subsystem is).
              > </snip>
              >
              > Raju,
              >
              > I appreciate the effort you are taking to ensure that your process
              > closely aligns with the Agile principles. Unfortunately, it is
              extremely
              > difficult for some of us to dive into the links that you have sent
              for
              > the same reasons you have pointed out. At the risk of paraphrasing
              > Steven, I can only say this much:
              >
              > 1. You do Iterative development, where the duration for each
              iteration
              > is small enough for the code developed to be trashed, but large
              enough
              > for some meaningful output.
              > 2. Each iteration produces a potentially shippable software.
              > 3. Customer provides feedback for the output.
              > 4. Customer decides what will get implemented for each iteration.
              > 5. WYNIWYG (what you need is what you get), not WYWIWYG (what you
              want
              > is what you get).
              >
              > Of course, for such a rapid delivery model, there needs to be some
              > supporting practices without which you will be working on a "Band-
              Aid"
              > model. Such practices include Automated Testing, Continuous
              Integration,
              > Simple Design and of course refactoring.
              >
              > I am using XP terminology for my response, but you will find that
              most
              > Agile methods would have equivalent practices.
              >
              > Please map each of the practices to the practices in your process.
              If
              > you are doing most of them, you are definitely doing Agile. Kindly
              > remember that either you do or do not. There are no "partial"
              > implementation of practices (you may implement 80% of all
              practices, but
              > each practice you implement must be 100% - I hope you understand the
              > difference).
              >
              > Regards
              > Sherlocksridhar
              > Regards
              > Sridhar
              > sherlocksridhar@...
              > Sherlocksridhar.blogspot.com
              > -----------------------------
              > "A lot of preconceptions can be avoided by simply trying them out" -
              Bruce Eckel
              >
              > --
              > http://www.fastmail.fm - Access all of your messages and folders
              > wherever you are
              >
            • Ron Jeffries
              ... I don t recall ever seeing a team that really - paired all the time - wrote test-first tests for everything - had a customer test for everything - ... I ve
              Message 6 of 21 , May 3, 2006
              • 0 Attachment
                On Tuesday, May 2, 2006, at 11:43:55 PM, SherlockSridhar wrote:

                > There are no "partial"
                > implementation of practices (you may implement 80% of all practices, but
                > each practice you implement must be 100% - I hope you understand the
                > difference).

                I don't recall ever seeing a team that really

                - paired all the time
                - wrote test-first tests for everything
                - had a customer test for everything
                - ...

                I've seen teams that tried ...

                Ron Jeffries
                www.XProgramming.com
                A long range weather forecast should be obtained before leaving,
                as weather conditions are extremely unpredictable. --Natal Daily News
              • SherlockSridhar
                On Wed, 3 May 2006 06:05:10 -0400, Ron Jeffries ... I meant it in the context of implementing some practices without implementing the support practices or
                Message 7 of 21 , May 3, 2006
                • 0 Attachment
                  On Wed, 3 May 2006 06:05:10 -0400, "Ron Jeffries"
                  <ronjeffries@...> said:
                  > I don't recall ever seeing a team that really
                  >
                  > - paired all the time
                  > - wrote test-first tests for everything
                  > - had a customer test for everything
                  > - ...

                  I meant it in the context of implementing some practices without
                  implementing the support practices or worse, half-hearted efforts. Some
                  teams I have seen do iterative development in the name of Agile without
                  having really short iterations *and* without customer feedback. Some
                  even do code drops within essentially waterfall practices.
                  Sometimes builds every 4 weeks!

                  100% here is in intent rather than being fanatical about it. I guess for
                  newcomers to Agile, this might not have come out the way it was
                  intended. All I am worried about is some process being arbitrarily
                  *certified* as Agile. My mother always used to tell me, "Earning a good
                  name is a life long journey, but to earn a bad name is a matter of
                  minutes."

                  This is the context where I come from.

                  Regards
                  Sherlocksridhar
                  Regards
                  Sridhar
                  sherlocksridhar@...
                  Sherlocksridhar.blogspot.com
                  -----------------------------
                  "A lot of preconceptions can be avoided by simply trying them out" - Bruce Eckel

                  --
                  http://www.fastmail.fm - IMAP accessible web-mail
                • Paul Campbell
                  ... What you are doing is pretty much the antithesis of agile: general infrastructure with no direct business driver. The problem with loose coupling is that
                  Message 8 of 21 , May 3, 2006
                  • 0 Attachment
                    --- In extremeprogramming@yahoogroups.com, "chiluvuri1"
                    <chiluvuri1@...> wrote:
                    >
                    > I have been working of an agile software development process, which
                    > can be used to develop online GUI applications. I believe, it meets
                    > many of the goals of Agile programming.

                    What you are doing is pretty much the antithesis of agile: general
                    infrastructure with no direct business driver.

                    The problem with "loose coupling" is that it is often really just
                    "deferred coupling" and serves no purpose beyond making it harder to
                    test small bits of functionality in isolation because they dont have
                    concrete interfaces with direct business meaning. We swap direct
                    tracable static coupling for hidden implicit runtime coupling which
                    all but impossible to develope in a agile fasion.

                    To me your approach is a throwback to "reusable component based
                    development" circa 1999 and its the failure of this approach in
                    practice which has been one of the main drivers for the widespread
                    adoption of agile methods.

                    Paul.
                  • Jim Standley
                    Back when Case tools were all the hype, Ed Yourdon asked many of the vendors one simple question: Did you use your tool to build your tool? Most (all?) of
                    Message 9 of 21 , May 3, 2006
                    • 0 Attachment
                      Back when Case tools were all the hype, Ed Yourdon asked many of the
                      vendors one simple question: "Did you use your tool to build your tool?"
                      Most (all?) of them sputtered and dissembled for a while and then said,
                      "No, building a tool like ours is a special case." It usually turned
                      out that every other application was also too "special" for the tool.

                      To get to the point, did you use agile methods to build your framework?
                      Stories, iteration planning, pair programming, Test Driven Development?
                      Do you have a suite of tests that document and demonstrate all the APIs?

                      Make yourself agile and you'll know whether the framework works that way!

                      chiluvuri1 wrote:
                      > I have been working of an agile software development process, which
                      > can be used to develop online GUI applications. I believe, it meets
                      > many of the goals of Agile programming, and I wondering, if you could
                      > verify that.
                      >
                      > Let me introduce the process. To understand the process, first you
                      > must accept that it is possible to build GUI Widgets that are
                      > functionally equivalent to traditional GUI Widgets, such as GUI
                      > Classes for Java/Swing.
                      >
                      > Please review the following web page and full proof, if you can spare
                      > 30 minutes. If you cannot spare that kind of time, please except that
                      > it is possible to understand the rest of the process.
                      > http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm
                      > http://cbsdf.com/misc_docs/why-gui-api.htm
                      > http://cbsdf.com/misc_docs/gui-api-brief.htm
                      >
                      > Our "loosely coupled" component based software development process
                      > requires developers to build "Component Factories", which generate
                      > the components. Please find examples at:
                      > http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm
                      > http://cbsdf.com/technologies/component-factory.htm
                      >
                      > Then the process to build the application is illustrated in the
                      > following web page:
                      > http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
                      >
                      > Please pay attention to the new concept "unified handle", how one can
                      > use the unified handle to remove any component, even it has 20
                      > subcomponents and 100 Objects.
                      >
                      > Please carefully review last 6 paragraphs and especially last 3
                      > paragraphs, which I think matches the goals of "Agile Programming".
                      > The CF/AC offers higher-level abstraction and since components
                      > are "loosely coupled", it would be much simpler to refine or replace.
                      >
                      > I am new to this group and please for give me if I miss understand
                      > the goals of agile programming. I have been working for years to
                      > absolutely make sure that all of our CBSDF processes work, but I am
                      > not sure if my goals are similar to the goals of agile programming
                      > (but I feel they are similar).
                      >
                      > Best Regards,
                      > Raju
                    • chiluvuri1
                      Jim, ... Answer to this question is! Yes! We only build fine-grained Widgets and then only use our process to assemble them to build all other Widgets and/or
                      Message 10 of 21 , May 3, 2006
                      • 0 Attachment
                        Jim,

                        Thank you for the information. You said:
                        > "Did you use your tool to build your tool?"

                        Answer to this question is! Yes! We only build fine-grained Widgets
                        and then only use our process to assemble them to build all other
                        Widgets and/or Applications.

                        But, you said:
                        > To get to the point, did you use agile methods to build
                        > your framework? Stories, iteration planning, pair
                        > programming, Test Driven Development?

                        I don't think, I do some of them. As I said, I am new to Agile
                        Programming. I don't have enough comprehension on these concepts. The
                        steps such as iteration planning, pair programming sounds interesting
                        and I would learn more about them to adapt.

                        However, in other cases my objective is slightly different, for
                        example, make the components self-test the interfaces, hence
                        eliminate to entire testing cycle. Since "loosely components" are
                        better suited to self-test external interfaces and catch the broken
                        interfaces without manual intervention.

                        I wanted to create my own Agile method, which is bets for the loosely
                        coupled components, of course, by adapting better processes from
                        others and inventing our own where it makes sense. I wanted to learn
                        best processes from you so that I can avoid reinventing wheel (which
                        likely end up inferior to your tried and tested methods).

                        Best Regards,
                        Raju

                        --- In extremeprogramming@yahoogroups.com, Jim Standley
                        <jimstandley@...> wrote:
                        >
                        > Back when Case tools were all the hype, Ed Yourdon asked many of
                        the
                        > vendors one simple question: "Did you use your tool to build your
                        tool?"
                        > Most (all?) of them sputtered and dissembled for a while and then
                        said,
                        > "No, building a tool like ours is a special case." It usually
                        turned
                        > out that every other application was also too "special" for the
                        tool.
                        >
                        > To get to the point, did you use agile methods to build your
                        framework?
                        > Stories, iteration planning, pair programming, Test Driven
                        Development?
                        > Do you have a suite of tests that document and demonstrate all the
                        APIs?
                        >
                        > Make yourself agile and you'll know whether the framework works
                        that way!
                        >
                        > chiluvuri1 wrote:
                        > > I have been working of an agile software development process,
                        which
                        > > can be used to develop online GUI applications. I believe, it
                        meets
                        > > many of the goals of Agile programming, and I wondering, if you
                        could
                        > > verify that.
                        > >
                        > > Let me introduce the process. To understand the process, first
                        you
                        > > must accept that it is possible to build GUI Widgets that are
                        > > functionally equivalent to traditional GUI Widgets, such as GUI
                        > > Classes for Java/Swing.
                        > >
                        > > Please review the following web page and full proof, if you can
                        spare
                        > > 30 minutes. If you cannot spare that kind of time, please except
                        that
                        > > it is possible to understand the rest of the process.
                        > > http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm
                        > > http://cbsdf.com/misc_docs/why-gui-api.htm
                        > > http://cbsdf.com/misc_docs/gui-api-brief.htm
                        > >
                        > > Our "loosely coupled" component based software development
                        process
                        > > requires developers to build "Component Factories", which
                        generate
                        > > the components. Please find examples at:
                        > > http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm
                        > > http://cbsdf.com/technologies/component-factory.htm
                        > >
                        > > Then the process to build the application is illustrated in the
                        > > following web page:
                        > > http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
                        > >
                        > > Please pay attention to the new concept "unified handle", how one
                        can
                        > > use the unified handle to remove any component, even it has 20
                        > > subcomponents and 100 Objects.
                        > >
                        > > Please carefully review last 6 paragraphs and especially last 3
                        > > paragraphs, which I think matches the goals of "Agile
                        Programming".
                        > > The CF/AC offers higher-level abstraction and since components
                        > > are "loosely coupled", it would be much simpler to refine or
                        replace.
                        > >
                        > > I am new to this group and please for give me if I miss
                        understand
                        > > the goals of agile programming. I have been working for years to
                        > > absolutely make sure that all of our CBSDF processes work, but I
                        am
                        > > not sure if my goals are similar to the goals of agile
                        programming
                        > > (but I feel they are similar).
                        > >
                        > > Best Regards,
                        > > Raju
                        >
                      • Ron Jeffries
                        ... It would seem to me that prior to creating one s own agile method, one would be wise to study the existing literature, perhaps take some courses or attend
                        Message 11 of 21 , May 3, 2006
                        • 0 Attachment
                          On Wednesday, May 3, 2006, at 11:24:08 PM, chiluvuri1 wrote:

                          > I wanted to create my own Agile method, which is bets for the loosely
                          > coupled components, of course, by adapting better processes from
                          > others and inventing our own where it makes sense. I wanted to learn
                          > best processes from you so that I can avoid reinventing wheel (which
                          > likely end up inferior to your tried and tested methods).

                          It would seem to me that prior to creating one's own agile method,
                          one would be wise to study the existing literature, perhaps take
                          some courses or attend some conferences, and work with some
                          individuals and team who have extensive experience with Agile.

                          It might be helpful if you'd think about what you'd do if you wanted
                          to create your own open heart surgery method, then translate that
                          back into software development.

                          Regards,

                          Ron Jeffries
                          www.XProgramming.com
                          You can observe a lot by watching. --Yogi Berra
                        • chiluvuri1
                          ... Paul: Thank you for enlightening me. I think, I misunderstood the Agile programming. Hence, my process likely not an Agile programming. Our framework
                          Message 12 of 21 , May 3, 2006
                          • 0 Attachment
                            --- In extremeprogramming@yahoogroups.com, "Paul Campbell"
                            <yahoo@...> wrote:
                            >
                            Paul:

                            Thank you for enlightening me. I think, I misunderstood the Agile
                            programming. Hence, my process likely not an Agile programming.

                            Our framework heavily relies on reusable "Widgets" and "recipes" to
                            fully automate software development process.

                            I wanted to automate every thing that has finite states. For example,
                            if you study carefully, you would notice that the interactions
                            between subsystems (e.g. loosely coupled components) are also have
                            finite states, hence possible to create "recipe" to fully automate
                            integration of the applications.

                            The automation offers a great deal of advantage. For example, it
                            makes the "loosely coupled" components highly independent to refine
                            them or replace them. The reusable "recipe" would take care of
                            integration and interface compatibilities. This makes the iterative
                            improvements much simpler.

                            Also, reusable Widgets are not same as "loosely coupled" components.
                            As explained, in the following web page, the reusable widgets are
                            just ingredients to build the parts of the "loosely coupled"
                            components:
                            http://cbsdf.com/technologies/software-development-paradigm.htm
                            http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm

                            Please understand my Objective is not Agile programming, but to
                            create "loosely coupled" component based software development
                            process. We wanted to create higher-level abstraction to Objects,
                            because (as you can see in the above web pages) we believe Objects
                            are too complex, hence impossible to create automated tools to
                            assemble applications from such components.

                            But I believe, reusable components are absolutely essential to
                            increase the user productivity and to achieve good automation. Only
                            thing developer must do is things that are unique to the application,
                            such as, application logic as explained below:
                            http://cbsdf.com/GUI-metaphors.htm

                            You said:
                            > The problem with "loose coupling" is that it is often really just
                            > "deferred coupling"

                            Paul, I have to respectfully disagree. "Loose coupling" means, it
                            requires near zero effort to "couple" it. Which also make it easy to
                            remove or replace. Furthermore, the component code and classes must
                            be highly autonomous to refine, and such modifications would have
                            minimal effect on other interacting components in the application.

                            You Said:
                            > To me your approach is a throwback to "reusable
                            > component based development" circa 1999 and
                            > its the failure of this approach

                            Paul, I have to respectfully disagree with you here again. "Reusable
                            components" are essential to automate software development. We
                            heavily rely on reusable "widgets" and "recipes" for automation.

                            We wanted the application developer, to focus only on the application-
                            logic part in each CF, which generates the CUSTOM "Loosely Coupled"
                            components. Then use reusable "recipes" to automate the integration
                            and testing of interfaces for communication between the components.

                            Of course, we need Agile reusable components, so that, they can be
                            adapted to meet each application's unique needs. Hence, I call our
                            Widgets Agile Templates. As you can read, the Agile templates are
                            tightly coupled with application logic (which is unique to the
                            application) to build Loosely coupled components.

                            Although we have the same goals and share some common processes, we
                            are taking different routes.

                            Thank you for your feedback. I have learned very useful concepts from
                            Agile programming and will adopt some of them into my process.

                            Best Regards,
                            Raju

                            > --- In extremeprogramming@yahoogroups.com, "chiluvuri1"
                            > <chiluvuri1@> wrote:
                            > >
                            > > I have been working of an agile software development process,
                            which
                            > > can be used to develop online GUI applications. I believe, it
                            meets
                            > > many of the goals of Agile programming.
                            >
                            > What you are doing is pretty much the antithesis of agile: general
                            > infrastructure with no direct business driver.
                            >
                            > The problem with "loose coupling" is that it is often really just
                            > "deferred coupling" and serves no purpose beyond making it harder to
                            > test small bits of functionality in isolation because they dont have
                            > concrete interfaces with direct business meaning. We swap direct
                            > tracable static coupling for hidden implicit runtime coupling which
                            > all but impossible to develope in a agile fasion.
                            >
                            > To me your approach is a throwback to "reusable component based
                            > development" circa 1999 and its the failure of this approach in
                            > practice which has been one of the main drivers for the widespread
                            > adoption of agile methods.
                            >
                            > Paul.
                            >
                          • chiluvuri1
                            Ron, Creativity is strange thing. For example, let me give a personal example that worked for me. First one should know the problem well enough and try to
                            Message 13 of 21 , May 3, 2006
                            • 0 Attachment
                              Ron,

                              Creativity is strange thing.

                              For example, let me give a personal example that worked for me. First
                              one should know the problem well enough and try to solve on his own
                              first. He must give it best try. In this process, he has to create
                              many processes, make many decisions and choose among many options.
                              Once he is satisfied with the results, if he compares with others,
                              who have succeeded in doing the same, he would learn things:

                              First of all, he learns many of his mistakes, which is certainly an
                              enlightening experience. Which make him think differently and
                              contemplate other possibilities.

                              Occasionally some of the choices he made turns out to be better than
                              others, which he wouldn't have made, if he knows the solution
                              already. The knowledge kills his creativity. Discard 99% of the bad
                              choices and continue to develop the 1% that turns out to be good.

                              This helped me end up with online-GUI paradigm, which is comparable
                              to desktop GUI-API such as Java/Swing:
                              http://cbsdf.com/technologies/misc-docs/GUI-Widgets.htm
                              http://cbsdf.com/technologies/misc-docs/Scales-Dials-Meters.htm

                              My story: my goal in 1999 was to build reusable GUI components for
                              online applications. Why should I write 1000 line of DHTML code, if I
                              need to create Hirearchical-menu. I didn't even know JavaScript code
                              to write even 5 line code. So, I set out to create a Java Widget,
                              which can take the "components" in each cell as input and generate
                              the code.

                              I have barrowed DHTML code form some web site, since I don't know
                              DHTML programming. All I did is, printed the whole code, and just
                              replacing the contents of each Cell, with "component" Input into the
                              Java Class. Voile, I have a reusable GUI Widgets.

                              After few days, I need the GUI widget highly Agile, to be highly
                              customizable. Why should, I limit the cell to a string? Why cannot I
                              use any other component? I end up with the following:
                              http://cbsdf.com/technologies/demo-
                              links/DHTML_Demo/EXAMPLE1/ie_float1a.html
                              http://cbsdf.com/technologies/demo-
                              links/DHTML_Demo/EXAMPLE1/ie_floats2a.html
                              http://cbsdf.com/technologies/demo-
                              links/DHTML_Demo/EXAMPLE1/present_mix.html
                              http://cbsdf.com/technologies/demo-links/demo-links.htm

                              It is an eye opening experience. I know, I found some thing useful. I
                              have continued to pursue it, out of curiosity al these years. Just
                              like to share, and may be useful, if any of you are a geek like me,
                              and like to tinker in spare time.

                              Forgive me, if it is a boring story and end up useless to you.

                              Thank You,
                              Raju


                              --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                              <ronjeffries@...> wrote:
                              >
                              > On Wednesday, May 3, 2006, at 11:24:08 PM, chiluvuri1 wrote:
                              >
                              > > I wanted to create my own Agile method, which is bets for the
                              loosely
                              > > coupled components, of course, by adapting better processes from
                              > > others and inventing our own where it makes sense. I wanted to
                              learn
                              > > best processes from you so that I can avoid reinventing wheel
                              (which
                              > > likely end up inferior to your tried and tested methods).
                              >
                              > It would seem to me that prior to creating one's own agile method,
                              > one would be wise to study the existing literature, perhaps take
                              > some courses or attend some conferences, and work with some
                              > individuals and team who have extensive experience with Agile.
                              >
                              > It might be helpful if you'd think about what you'd do if you wanted
                              > to create your own open heart surgery method, then translate that
                              > back into software development.
                              >
                              > Regards,
                              >
                              > Ron Jeffries
                              > www.XProgramming.com
                              > You can observe a lot by watching. --Yogi Berra
                              >
                            • Chris Hanson
                              ... This argument is fallacious. Tangled dependencies between instances are not a result of object-oriented programming; it is not the actor. They are the
                              Message 14 of 21 , May 4, 2006
                              • 0 Attachment
                                On May 2, 2006, at 7:33 AM, chiluvuri1 wrote:

                                > In the OOP, there is
                                > no way to contain the complex tangled dependencies between Objects,
                                > which makes nearly impossible to remove a large subsystem.

                                This argument is fallacious. Tangled dependencies between instances
                                are not a result of object-oriented programming; it is not the
                                actor. They are the result of developers creating classes that have
                                tangled dependencies between their instances.

                                -- Chris
                              • Ron Jeffries
                                ... I believe you ll find that the term loose coupling dates back over 30 years, to the work of Constantine and others, on what was then called structured or
                                Message 15 of 21 , May 4, 2006
                                • 0 Attachment
                                  On Thursday, May 4, 2006, at 12:24:14 AM, chiluvuri1 wrote:

                                  >> The problem with "loose coupling" is that it is often really just
                                  >> "deferred coupling"

                                  > Paul, I have to respectfully disagree. "Loose coupling" means, it
                                  > requires near zero effort to "couple" it. Which also make it easy to
                                  > remove or replace. Furthermore, the component code and classes must
                                  > be highly autonomous to refine, and such modifications would have
                                  > minimal effect on other interacting components in the application.

                                  I believe you'll find that the term "loose coupling" dates back over
                                  30 years, to the work of Constantine and others, on what was then
                                  called structured or modular programming. It is still in use, and
                                  does not refer to the effort involved in "coupling", removing, or
                                  replacing, though it is not entirely unlike those notions.

                                  It refers to the property of programs having modules that not highly
                                  inter-connected. If that's somewhat like what you mean by loose
                                  coupling, then the term may not confuse your eventual users. If it
                                  isn't what you mean, I'd suggest finding a term that doesn't already
                                  have an existing computer science definition.

                                  >> To me your approach is a throwback to "reusable
                                  >> component based development" circa 1999 and
                                  >> its the failure of this approach
                                  >
                                  > Paul, I have to respectfully disagree with you here again. "Reusable
                                  > components" are essential to automate software development. We
                                  > heavily rely on reusable "widgets" and "recipes" for automation.
                                  >
                                  > We wanted the application developer, to focus only on the application-
                                  > logic part in each CF, which generates the CUSTOM "Loosely Coupled"
                                  > components. Then use reusable "recipes" to automate the integration
                                  > and testing of interfaces for communication between the components.

                                  I think everyone would agree that reusable components are of value,
                                  and that if software development were to be automated, they would be
                                  needed. However, from what I've heard, Paul is correct in pointing
                                  to the historical notions, and, if you've not already done so, you
                                  might be wise to look into these notions. "Those who will not learn
                                  from history are doomed to repeat it."

                                  > Of course, we need Agile reusable components, so that, they can be
                                  > adapted to meet each application's unique needs. Hence, I call our
                                  > Widgets Agile Templates. As you can read, the Agile templates are
                                  > tightly coupled with application logic (which is unique to the
                                  > application) to build Loosely coupled components.

                                  This seems to me to be an egregious misuse of a term which has
                                  gained currency in software development. You may, of course, call
                                  them anything you wish, but my initial reaction is that it's an
                                  inappropriate use of the term "Agile". If it turns out that the
                                  Agile community thinks that the name is inappropriate, using it is
                                  likely to backfire.

                                  Usable snap-together components are not new, nor are the techniques
                                  for using them. Still, what you're doing could be valuable if done
                                  well. I'd think it would be valuable to consider those who have
                                  gone before you in this kind of work, so that you can learn from
                                  their mistakes. And I think it would be valuable to give your ideas
                                  a name that, instead of riding on a community of thought that
                                  happens to be trendy, better reflects the true value of what you're
                                  offering.

                                  It seems to me that components can be pluggable, reusable,
                                  snappable, flexible, modular. Components, it seems to me, are not
                                  likely to be well-described as "agile", and your current approach.
                                  I'd like your idea to have a good chance to make it in the world. In
                                  aid of that, I'd suggest learning from the history of similar ideas,
                                  and giving them a name that reflects their uniqueness.

                                  Ron Jeffries
                                  www.XProgramming.com
                                  He who will not apply new remedies must expect old evils. -- Francis Bacon
                                • Ron Jeffries
                                  ... The ideas may well be good. I m merely pointing out things that have gone before you, from which you may wish to learn if you don t already have them under
                                  Message 16 of 21 , May 4, 2006
                                  • 0 Attachment
                                    On Thursday, May 4, 2006, at 1:15:47 AM, chiluvuri1 wrote:

                                    > I have barrowed DHTML code form some web site, since I don't know
                                    > DHTML programming. All I did is, printed the whole code, and just
                                    > replacing the contents of each Cell, with "component" Input into the
                                    > Java Class. Voile, I have a reusable GUI Widgets.

                                    > After few days, I need the GUI widget highly Agile, to be highly
                                    > customizable. Why should, I limit the cell to a string? Why cannot I
                                    > use any other component? I end up with the following:
                                    > http://cbsdf.com/technologies/demo-
                                    > links/DHTML_Demo/EXAMPLE1/ie_float1a.html
                                    > http://cbsdf.com/technologies/demo-
                                    > links/DHTML_Demo/EXAMPLE1/ie_floats2a.html
                                    > http://cbsdf.com/technologies/demo-
                                    > links/DHTML_Demo/EXAMPLE1/present_mix.html
                                    > http://cbsdf.com/technologies/demo-links/demo-links.htm

                                    > It is an eye opening experience. I know, I found some thing useful. I
                                    > have continued to pursue it, out of curiosity al these years. Just
                                    > like to share, and may be useful, if any of you are a geek like me,
                                    > and like to tinker in spare time.

                                    The ideas may well be good. I'm merely pointing out things that have
                                    gone before you, from which you may wish to learn if you don't
                                    already have them under your belt.

                                    As for calling your process "Agile", there is a community of many
                                    thousands of software practitioners who already know what that term
                                    means, who may not find your process to be consistent with the
                                    term. It may be advisable to give it a name which will be more
                                    consistent with what people already know.

                                    Of course, you can call it anything you want. I'm just reporting my
                                    opinion, which you asked for.

                                    Regards,

                                    Ron Jeffries
                                    www.XProgramming.com
                                    To tolerate a problem is to insist on it. -- Software for Your Head
                                  • chiluvuri1
                                    Chris: You may be right and I may be wrong, but I request you to please quickly review, why I think Objects interactions are tangled:
                                    Message 17 of 21 , May 4, 2006
                                    • 0 Attachment
                                      Chris:

                                      You may be right and I may be wrong, but I request you to please
                                      quickly review, why I think Objects interactions are tangled:
                                      http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
                                      http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm

                                      As explained above, GUI Objects require extensive use of set and get
                                      methods to build a GUI Component, which can be made highly
                                      independent, and thrown into the application and automate the
                                      integration (hence no manual coding):
                                      http://cbsdf.com/technologies/LC-CBSD.htm
                                      http://cbsdf.com/technologies/software-development-paradigm.htm

                                      I found that the loosely coupled components works and highly
                                      scalable. You can find numerous examples that it is possible. Now I
                                      am working to create a process that better suits online applications
                                      that uses such loosely coupled components.

                                      My Objective is only to get some Ideas from all of you, since you are
                                      experts and I liked some of the Ideas I found here. They open my eyes
                                      to new possibilities.

                                      Regards,
                                      Raju

                                      --- In extremeprogramming@yahoogroups.com, Chris Hanson <cmh@...>
                                      wrote:
                                      >
                                      > On May 2, 2006, at 7:33 AM, chiluvuri1 wrote:
                                      >
                                      > > In the OOP, there is
                                      > > no way to contain the complex tangled dependencies between
                                      Objects,
                                      > > which makes nearly impossible to remove a large subsystem.
                                      >
                                      > This argument is fallacious. Tangled dependencies between
                                      instances
                                      > are not a result of object-oriented programming; it is not the
                                      > actor. They are the result of developers creating classes that
                                      have
                                      > tangled dependencies between their instances.
                                      >
                                      > -- Chris
                                      >
                                    • chiluvuri1
                                      Ron: You are right! And I am not calling our process Agile and it definitely confuses. But by coincidence, I have named one part of our artifact of our system,
                                      Message 18 of 21 , May 4, 2006
                                      • 0 Attachment
                                        Ron:

                                        You are right! And I am not calling our process Agile and it
                                        definitely confuses. But by coincidence, I have named one part of our
                                        artifact of our system, Agile templates in early 2000. That is a mere
                                        naming for one artifact of our system. I hope, it would lend any one
                                        to confuse our process is Agile programming.

                                        At that time, the naming more represents my Objective or Goals to
                                        make reusable GUI Widgets highly customizable (hence Agile). I
                                        thought, if the GUI Widgets, do not restrict what kind of components,
                                        one can use for subcomponents, then they are more customizable,
                                        highly flexible and easy to use. This is still our philosophy for our
                                        GUI Widgets. Therefore, it is possible for developers to custom build
                                        each subcomponent using run-time data and yet another Agile GUI
                                        Widget, and so on.

                                        In general use, plug and play components are referred to as loosely
                                        coupled components. For example, CD-Drive, HardDrive and CPU are plug
                                        and play components. They can also be called "loosely coupled"
                                        components. I believe, we can create even better plug-n-play software
                                        components:
                                        http://cbsdf.com/technologies/software-irony.htm (Please forgive me
                                        for trying to be funny in there). There is lot of information, if you
                                        wish to dig deep.

                                        My Objective is only to get some Ideas from all of you, since you are
                                        experts and I liked some of the Ideas I found here. They open my eyes
                                        to new possibilities.

                                        I just want to see, if I can steel your Agile ideas and use them.
                                        Forgive me, if I give any other wrong impression.

                                        Best Regards,
                                        Raju


                                        --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                                        <ronjeffries@...> wrote:
                                        >
                                        > On Thursday, May 4, 2006, at 1:15:47 AM, chiluvuri1 wrote:
                                        >
                                        > > I have barrowed DHTML code form some web site, since I don't know
                                        > > DHTML programming. All I did is, printed the whole code, and just
                                        > > replacing the contents of each Cell, with "component" Input into
                                        the
                                        > > Java Class. Voile, I have a reusable GUI Widgets.
                                        >
                                        > > After few days, I need the GUI widget highly Agile, to be highly
                                        > > customizable. Why should, I limit the cell to a string? Why
                                        cannot I
                                        > > use any other component? I end up with the following:
                                        > > http://cbsdf.com/technologies/demo-
                                        > > links/DHTML_Demo/EXAMPLE1/ie_float1a.html
                                        > > http://cbsdf.com/technologies/demo-
                                        > > links/DHTML_Demo/EXAMPLE1/ie_floats2a.html
                                        > > http://cbsdf.com/technologies/demo-
                                        > > links/DHTML_Demo/EXAMPLE1/present_mix.html
                                        > > http://cbsdf.com/technologies/demo-links/demo-links.htm
                                        >
                                        > > It is an eye opening experience. I know, I found some thing
                                        useful. I
                                        > > have continued to pursue it, out of curiosity al these years.
                                        Just
                                        > > like to share, and may be useful, if any of you are a geek like
                                        me,
                                        > > and like to tinker in spare time.
                                        >
                                        > The ideas may well be good. I'm merely pointing out things that have
                                        > gone before you, from which you may wish to learn if you don't
                                        > already have them under your belt.
                                        >
                                        > As for calling your process "Agile", there is a community of many
                                        > thousands of software practitioners who already know what that term
                                        > means, who may not find your process to be consistent with the
                                        > term. It may be advisable to give it a name which will be more
                                        > consistent with what people already know.
                                        >
                                        > Of course, you can call it anything you want. I'm just reporting my
                                        > opinion, which you asked for.
                                        >
                                        > Regards,
                                        >
                                        > Ron Jeffries
                                        > www.XProgramming.com
                                        > To tolerate a problem is to insist on it. -- Software for Your Head
                                        >
                                      • Keith Ray
                                        It sounds like you want to use the techniques of dependency injection with GUI components. It also looks like you re only looking at the world of Java, which
                                        Message 19 of 21 , May 4, 2006
                                        • 0 Attachment
                                          It sounds like you want to use the techniques of "dependency
                                          injection" with GUI components.

                                          It also looks like you're only looking at the world of Java, which has
                                          many flaws in its UI design. I suggest looking at some other
                                          languages/environments for comparison... Apple's Cocoa and WebObjects,
                                          and Cincom Smalltalk's UIPainter and VisualWave.

                                          Apple WebObjects:
                                          http://www.apple.com/au/webobjects/getting_started.html

                                          Apple Cocoa:
                                          http://cocoadevcentral.com/articles/000080.php
                                          http://www.stone.com/The_Cocoa_Files/Doing_Objects_Right.html
                                          http://www.stone.com/The_Cocoa_Files/Arise_Aqua_.html

                                          Cincom UIPainter and VisualWave tutorials:
                                          http://www.whysmalltalk.com/vw7tutorialsII/weblogstatstoc2.htm

                                          On 5/4/06, chiluvuri1 <chiluvuri1@...> wrote:
                                          >
                                          > Chris:
                                          >
                                          > You may be right and I may be wrong, but I request you to please
                                          > quickly review, why I think Objects interactions are tangled:
                                          > http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
                                          > http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm
                                          >
                                          > As explained above, GUI Objects require extensive use of set and get
                                          > methods to build a GUI Component, which can be made highly
                                          > independent, and thrown into the application and automate the
                                          > integration (hence no manual coding):
                                          > http://cbsdf.com/technologies/LC-CBSD.htm
                                          > http://cbsdf.com/technologies/software-development-paradigm.htm
                                          >
                                          > I found that the loosely coupled components works and highly
                                          > scalable. You can find numerous examples that it is possible. Now I
                                          > am working to create a process that better suits online applications
                                          > that uses such loosely coupled components.
                                          >
                                          > My Objective is only to get some Ideas from all of you, since you are
                                          > experts and I liked some of the Ideas I found here. They open my eyes
                                          > to new possibilities.
                                          >
                                          > Regards,
                                          > Raju
                                          >
                                          > --- In extremeprogramming@yahoogroups.com, Chris Hanson <cmh@...>
                                          > wrote:
                                          > >
                                          > > On May 2, 2006, at 7:33 AM, chiluvuri1 wrote:
                                          > >
                                          > > > In the OOP, there is
                                          > > > no way to contain the complex tangled dependencies between
                                          > Objects,
                                          > > > which makes nearly impossible to remove a large subsystem.
                                          > >
                                          > > This argument is fallacious. Tangled dependencies between
                                          > instances
                                          > > are not a result of object-oriented programming; it is not the
                                          > > actor. They are the result of developers creating classes that
                                          > have
                                          > > tangled dependencies between their instances.
                                          > >
                                          > > -- Chris
                                          > >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          > To Post a message, send it to: extremeprogramming@...
                                          >
                                          > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                          >
                                          > ad-free courtesy of objectmentor.com
                                          > Yahoo! Groups Links
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >


                                          --

                                          C. Keith Ray
                                          <http://homepage.mac.com/keithray/blog/index.html>
                                          <http://homepage.mac.com/keithray/xpminifaq.html>
                                          <http://homepage.mac.com/keithray/resume2.html>
                                        • chiluvuri1
                                          Hi Keith: One of my single-minded obsessions is to minimize the dependencies between interacting components and then even eliminate the need for the
                                          Message 20 of 21 , May 5, 2006
                                          • 0 Attachment
                                            Hi Keith:

                                            One of my single-minded obsessions is to minimize the dependencies
                                            between interacting components and then even eliminate the need for
                                            the application developers to write that binding code.

                                            Please review the web page and then newly added paragraph at the end:
                                            http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm

                                            I believe, if we can eliminate that manual binding of subsystems,
                                            which would have far reaching implications to the software
                                            development (including to the Agile programming).

                                            In this effort, I am discovering some amazing things, but not what I
                                            want to do. Please see the Figure#1. We cannot eliminate the Object
                                            interactions and bindings, but we can encapsulate them in a higher-
                                            level abstraction, we call "CF/AC".

                                            Now it is possible to minimize the binding code for the CF. if you
                                            study any system, an "average" component provides 2 kinds of
                                            services. Of course, some components may provide more and in general
                                            many provide Zero.

                                            Please remember, shopping-cart may need to interact with many
                                            shopping items, but it provide only one kind of service, hence it
                                            needs only one line of binding code, for example, register its
                                            service Object with Global directory of services. (P.S. Although I
                                            came up with this idea with out knowing SoA, then studying SoA helped
                                            me refine my process, such as, interface contracts, versions, XML-
                                            data validations and tools to detect broken contracts. Likewise, I am
                                            hoping, I would get some useful ideas from here.)

                                            I have learned, that as long as we are dealing with Objects, we
                                            cannot avoid bindings. Also, large components contain many "loosely
                                            coupled" components, which must be again encapsulated, which is
                                            impossible for Objects, as shown in:
                                            http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm

                                            The hierarchical encapsulation of subcomponents and the "unified
                                            handler" is extremely important to control the complexity and
                                            preserving of the independency of each sub system. This would allow
                                            us to refine it, with little concern on the impact of other parts in
                                            the system.

                                            All the manufactured products use this hierarchical encapsulation of
                                            subcomponents and the "unified handler". For example, HardDrive
                                            encapsulates many components, and we need no knowledge of its
                                            subcomponents to remove it. How can we remove a large subsystem,
                                            which contains 300 Objects spread across many files? Some aspects of
                                            Aspect oriented programming scares me (but I don't know enough, so I
                                            may be wrong).

                                            I have read about Cocoa objects. Problem with reusable GUI Classes is
                                            that, if you want to make them highly customizable, you need to
                                            provide so many switches to abject each aspect (e.g. fonts, colors)
                                            of the resultant component. If we want to customize this based on
                                            user preferences, we need to get each piece from the user-Object. Now
                                            we can see the why the Object dependencies cannot be avoided.

                                            On the other hand, the Components (and all the other components that
                                            interact with this component) are designed specifically for one
                                            application, so there are so few things to worry about. Sorry, I
                                            should not go into philosophical discussion.

                                            Keith, thank you for the references I will read them again. But, I am
                                            just using Java, but one may do the same with C# or C++.

                                            Best Regards,
                                            Raju



                                            --- In extremeprogramming@yahoogroups.com, "Keith Ray"
                                            <keith.ray@...> wrote:
                                            >
                                            > It sounds like you want to use the techniques of "dependency
                                            > injection" with GUI components.
                                            >
                                            > It also looks like you're only looking at the world of Java, which
                                            has
                                            > many flaws in its UI design. I suggest looking at some other
                                            > languages/environments for comparison... Apple's Cocoa and
                                            WebObjects,
                                            > and Cincom Smalltalk's UIPainter and VisualWave.
                                            >
                                            > Apple WebObjects:
                                            > http://www.apple.com/au/webobjects/getting_started.html
                                            >
                                            > Apple Cocoa:
                                            > http://cocoadevcentral.com/articles/000080.php
                                            > http://www.stone.com/The_Cocoa_Files/Doing_Objects_Right.html
                                            > http://www.stone.com/The_Cocoa_Files/Arise_Aqua_.html
                                            >
                                            > Cincom UIPainter and VisualWave tutorials:
                                            > http://www.whysmalltalk.com/vw7tutorialsII/weblogstatstoc2.htm
                                            >
                                            > On 5/4/06, chiluvuri1 <chiluvuri1@...> wrote:
                                            > >
                                            > > Chris:
                                            > >
                                            > > You may be right and I may be wrong, but I request you to please
                                            > > quickly review, why I think Objects interactions are tangled:
                                            > > http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
                                            > > http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm
                                            > >
                                            > > As explained above, GUI Objects require extensive use of set and
                                            get
                                            > > methods to build a GUI Component, which can be made highly
                                            > > independent, and thrown into the application and automate the
                                            > > integration (hence no manual coding):
                                            > > http://cbsdf.com/technologies/LC-CBSD.htm
                                            > > http://cbsdf.com/technologies/software-development-paradigm.htm
                                            > >
                                            > > I found that the loosely coupled components works and highly
                                            > > scalable. You can find numerous examples that it is possible. Now
                                            I
                                            > > am working to create a process that better suits online
                                            applications
                                            > > that uses such loosely coupled components.
                                            > >
                                            > > My Objective is only to get some Ideas from all of you, since you
                                            are
                                            > > experts and I liked some of the Ideas I found here. They open my
                                            eyes
                                            > > to new possibilities.
                                            > >
                                            > > Regards,
                                            > > Raju
                                            > >
                                            > > --- In extremeprogramming@yahoogroups.com, Chris Hanson <cmh@>
                                            > > wrote:
                                            > > >
                                            > > > On May 2, 2006, at 7:33 AM, chiluvuri1 wrote:
                                            > > >
                                            > > > > In the OOP, there is
                                            > > > > no way to contain the complex tangled dependencies between
                                            > > Objects,
                                            > > > > which makes nearly impossible to remove a large subsystem.
                                            > > >
                                            > > > This argument is fallacious. Tangled dependencies between
                                            > > instances
                                            > > > are not a result of object-oriented programming; it is not the
                                            > > > actor. They are the result of developers creating classes that
                                            > > have
                                            > > > tangled dependencies between their instances.
                                            > > >
                                            > > > -- Chris
                                            > > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > > To Post a message, send it to: extremeprogramming@...
                                            > >
                                            > > To Unsubscribe, send a blank message to: extremeprogramming-
                                            unsubscribe@...
                                            > >
                                            > > ad-free courtesy of objectmentor.com
                                            > > Yahoo! Groups Links
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            > >
                                            >
                                            >
                                            > --
                                            >
                                            > C. Keith Ray
                                            > <http://homepage.mac.com/keithray/blog/index.html>
                                            > <http://homepage.mac.com/keithray/xpminifaq.html>
                                            > <http://homepage.mac.com/keithray/resume2.html>
                                            >
                                          • Steve Brennan
                                            Keith, What do you consider the flaws in the Java UI design? I ve been an MS guy forever and have never really worked in Java -- so I haven t paid my dues and
                                            Message 21 of 21 , May 5, 2006
                                            • 0 Attachment
                                              Keith,

                                              What do you consider the flaws in the Java UI design? I've been an MS guy
                                              forever and have never really worked in Java -- so I haven't paid my dues
                                              and don't deserve much of an answer. That said, have you written about this
                                              anywhere that you could link to, or are there some well known posts I can
                                              read on this?

                                              Thanks,
                                              Steve Brennan
                                              Centrics
                                              Saint Louis

                                              -----Original Message-----
                                              From: extremeprogramming@yahoogroups.com
                                              [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Keith Ray
                                              Sent: Thursday, May 04, 2006 10:14 AM
                                              To: extremeprogramming@yahoogroups.com
                                              Subject: Re: [XP] Re: "Loosely Coupled" components in Agile Programming

                                              It sounds like you want to use the techniques of "dependency injection" with
                                              GUI components.

                                              It also looks like you're only looking at the world of Java, which has many
                                              flaws in its UI design. I suggest looking at some other
                                              languages/environments for comparison... Apple's Cocoa and WebObjects, and
                                              Cincom Smalltalk's UIPainter and VisualWave.

                                              Apple WebObjects:
                                              http://www.apple.com/au/webobjects/getting_started.html

                                              Apple Cocoa:
                                              http://cocoadevcentral.com/articles/000080.php
                                              http://www.stone.com/The_Cocoa_Files/Doing_Objects_Right.html
                                              http://www.stone.com/The_Cocoa_Files/Arise_Aqua_.html

                                              Cincom UIPainter and VisualWave tutorials:
                                              http://www.whysmalltalk.com/vw7tutorialsII/weblogstatstoc2.htm

                                              On 5/4/06, chiluvuri1 <chiluvuri1@...> wrote:
                                              >
                                              > Chris:
                                              >
                                              > You may be right and I may be wrong, but I request you to please
                                              > quickly review, why I think Objects interactions are tangled:
                                              > http://cbsdf.com/technologies/misc-docs/CF-LC-Figures.htm
                                              > http://cbsdf.com/technologies/misc-docs/CF-Goog-Charts.htm
                                              >
                                              > As explained above, GUI Objects require extensive use of set and get
                                              > methods to build a GUI Component, which can be made highly
                                              > independent, and thrown into the application and automate the
                                              > integration (hence no manual coding):
                                              > http://cbsdf.com/technologies/LC-CBSD.htm
                                              > http://cbsdf.com/technologies/software-development-paradigm.htm
                                              >
                                              > I found that the loosely coupled components works and highly scalable.
                                              > You can find numerous examples that it is possible. Now I am working
                                              > to create a process that better suits online applications that uses
                                              > such loosely coupled components.
                                              >
                                              > My Objective is only to get some Ideas from all of you, since you are
                                              > experts and I liked some of the Ideas I found here. They open my eyes
                                              > to new possibilities.
                                              >
                                              > Regards,
                                              > Raju
                                              >
                                              > --- In extremeprogramming@yahoogroups.com, Chris Hanson <cmh@...>
                                              > wrote:
                                              > >
                                              > > On May 2, 2006, at 7:33 AM, chiluvuri1 wrote:
                                              > >
                                              > > > In the OOP, there is
                                              > > > no way to contain the complex tangled dependencies between
                                              > Objects,
                                              > > > which makes nearly impossible to remove a large subsystem.
                                              > >
                                              > > This argument is fallacious. Tangled dependencies between
                                              > instances
                                              > > are not a result of object-oriented programming; it is not the
                                              > > actor. They are the result of developers creating classes that
                                              > have
                                              > > tangled dependencies between their instances.
                                              > >
                                              > > -- Chris
                                              > >
                                              >
                                              >
                                              >
                                              >
                                              >
                                              >
                                              >
                                              > To Post a message, send it to: extremeprogramming@...
                                              >
                                              > To Unsubscribe, send a blank message to:
                                              > extremeprogramming-unsubscribe@...
                                              >
                                              > ad-free courtesy of objectmentor.com
                                              > Yahoo! Groups Links
                                              >
                                              >
                                              >
                                              >
                                              >
                                              >
                                              >


                                              --

                                              C. Keith Ray
                                              <http://homepage.mac.com/keithray/blog/index.html>
                                              <http://homepage.mac.com/keithray/xpminifaq.html>
                                              <http://homepage.mac.com/keithray/resume2.html>


                                              To Post a message, send it to: extremeprogramming@...

                                              To Unsubscribe, send a blank message to:
                                              extremeprogramming-unsubscribe@...

                                              ad-free courtesy of objectmentor.com
                                              Yahoo! Groups Links
                                            Your message has been successfully submitted and would be delivered to recipients shortly.