• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

XP and programming paradigms

 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HS Thomas wrote in https://coderanch.com/t/130244/Agile/Pair-Programming-Case-study


Would component based development more naturally follow the aspect-orientation paradigm ?


Don't know...

Any offerings on XP in a component-based development project ?


What are the specifics of a component-based development project?

If we only knew what AOP was....looking for a good definition, there seems to be so many!


Of course the same is true for OOP - just take a look at the battles at news:comp.object about what OOP really is about...
 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I was just reading through The Catalysis Approach to see if anything quite revolutionary jumped out at me. So far I can't say it has.
But it was one of the first OO methodologies to unify concepts of objects frameworks and component technologies.And it was NEW when it first came out
The authors are Desmond D'Souza and Alan Cameron Wills.
Then I found this link in my mailbox. ACW seems to be continuing/extending the Unification Work.
eXtreme Programming meets UML
Would be glad to know what you think of the article(s) in relation to applying XP to Requirements Modelling.
The scope covers not just components but modules from legacy systems as well.
regards
[ June 16, 2003: Message edited by: HS Thomas ]
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the difference between the above and Agile Modelling ?

here is a summary on Agile Modelling :
  • a collection of values, principles, and practices for modeling software
  • agile modeling approach can be applied to requirements, analysis, architecture, and design
  • Because the scope of XP is much greater than that of AM, XP covers the full development lifecycle, it is a candidate "base process" into which the techniques of AM may be tailored.


  • regards
    [ June 16, 2003: Message edited by: HS Thomas ]
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The underlying concern for both approaches ( agile modelling vs components and legacy modules ) seems to be how best to leverage re-use and keep change requirements in hand.
    In fact one of the specifics of component-based development is the rapid development of end products by assembling components.
    regards
    [ June 16, 2003: Message edited by: HS Thomas ]
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by HS Thomas:
    The underlying concern for both approaches ( agile modelling vs components and legacy modules ) seems to be how best to leverage re-use and keep change requirements in hand.


    Where did you get this from for AM?
    I always understood AM to be about how to foster communication and understanding by using (non-code) models in an agile way.
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I might have read that it was implied in the following :


    The keys to modeling success are to have effective communication between all project stakeholders, to strive to develop the simplest solution possible that meets all of your needs,


    It is instinctive not to want to re-invent the wheel where that knowledge is made available.
    Note the link :
    Agile Modelling Resources


    "eXtreme Programming meets UML (Alan Cameron Wills) an alternative view to the essay AM and eXtreme Programming (XP)"on Scott W Amblers list of good resources on Agile Modelling.


    Component-based development focuses on re-use to a higher degree to the point where you could build a component that's not re-used anywhere else. But then if it isn't nothing's lost as long as there is at least 80% re-use following the 80-20 rule.
    To avoid sounding glib, here is an example:
    Business rules are broken down into minute business rule R1,R2,R3,R4 each to the level of a small set of SQL statements/ entity beans.
    Business processes are broken down into minute business process P1,P2,P3,P4,P5 each to the level of an EJB session bean or message-driven bean in the context of distributed objects.In the context of non-distributed objects these will be ordinary business objects.
    Process P1 uses rules R1 , R2 ,R5 for e.g. (( R1 and R2 ) and not R5) or R2)
    Process P2 uses rules R3 , R4 , R5
    Business Processes could be described and joined and re-used similarly (perhaps with a subset of the BPEL ? ) .
    I like the idea of rapid Component Assembly Platforms as long as the steps for re-engineered business process and models are followed through
    as rapidly(Agilely ?) .And these steps are not familiar to me.I expect this is where Agile Modelling comes in handy.
    from Agile Modelling


    Because the scope of XP is much greater than that of AM, XP covers the full development lifecycle, it is a candidate "base process" into which the techniques of AM may be tailored.


    I hadn't considered the scope of XP to be greater than AM, CBD, AOP , but for me this holds a lot of promise in following through business process re-engineering and modelling Agilely.
    I imagine the scope of XP is even greater than UML.
    regards
    [ June 20, 2003: Message edited by: HS Thomas ]
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator


    AOP, EJB and the Future of J2EE - In this talk, Rod Johnson begins by examining AOP concepts, before looking at approaches to implementing AOP including language enhancements (AspectJ) and standard Java approaches using dynamic proxies. Rod examines the implications of AOP for J2EE: how AOP can provide a lighter-weight yet more powerful alternative to EJB for many problems. The talk concludes with code examples showing how AOP can be used to solve common problems.
    Rod Johnson: Servlet 2.4 expert group member. Author, expert one-on-one: J2EE Design and Development.


    For those interested in following how AOP can be applied to a Component-based programming paradigms
    this could be a link to follow.
    AOP, EJB and the Future of J2EE
    regards
    [ June 22, 2003: Message edited by: HS Thomas ]
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by HS Thomas:
    Then I found this link in my mailbox. ACW seems to be continuing/extending the Unification Work.
    eXtreme Programming meets UML
    Would be glad to know what you think of the article(s) in relation to applying XP to Requirements Modelling.


    Well, I have only read "The Paper" now - and I am quite sceptical.
    For example, the author seems to be rather unexperienced with "pure" XP. I don't see him mentioning trying it before adding further practices and there are also some basic misconceptions about XP. So it seems to me as if he "fixed" XP without actually having a proof for it being broken. (I am totally OK with that - it's just that it makes me sceptical about some of his conclusions.)
    OK, let's go into the two main points I see in the paper: The use of UML for requirements modeling, and the existence of business analysts.
    First, let's make clear that XP doesn't exclude the use of UML. Remember, Communication is one of the four values XP is based on. Granted, it strongly emphasises oral, face to face communication, but it doesn't totally rely on it - the team members are expected to use any tools available that fit to foster that communication. If I remember correctly, some of the literature recommends CRC cards for quick design sessions, but UML certainly isn't forbidden.
    What I don't understand is his "need" for a more elaborate requirements modeling. He writes that this helps find inconsistencies in the requirements more early. Sadly, he doesn't explain how this helps providing more business value to the customer - to me it seems as if inconsitencies are already found "early enough" in XP.
    The use of business analysts also isn't new to XPers. The "Customer" is in fact a role which can be filled by as many people as necessary, some of which may be analysts.
    What I would pay attention to is that the business analysts don't get put *between* the developers and the actual customer(s). They shouldn't act as a filter, but be standing aside the customer(s), helping them to find out about their needs and communicate them to the developers.
    That's it in a short. Did it help?
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by HS Thomas:
    What is the difference between the above and Agile Modelling ?


    Well, in my humble opinion they don't have much in common... :roll:
    XP doesn't exclude modeling. It just doesn't include more modeling steps because it is a *minimal* set of practices and modeling needs wildly differ between projects. It simply trusts the developers to find out about things they have to do additionally - and to do them.
    All Agile Modeling seems to do to me, is adding principles and practices for noticing modeling needs and finding the right models to do. It probably can't hurt a project if the team members know about those practices - even if it wouldn't change the way they work at all...
    XPRM, on the other hand, does prescribe some additional practices. It doesn't give any hints on when to use them and when not to use them, as far as I can tell. It's far from obvious that those practices would add value to a big percentage of projects.
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by HS Thomas:
    I imagine the scope of XP is even greater than UML.


    This sentence doesn't compute for me. UML is a *language* - it's like saying the scope of XP might be greater than the scope of Java...
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I think I just stopped short of saying XP is bigger than RUP and getting myself into more trouble.
    But I see what you are saying i.e.
    XP doesn't exclude the use of UML as one of several tools to consider.
    regards
    [ June 20, 2003: Message edited by: HS Thomas ]
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    That's it in a short. Did it help?


    Yes , it did thanks.
    I have the same pre-conceptual "fixtures" that Alan Cameron Wills has about XP and will continue to do so until I've done some reading up and applying that to projects.
    For e.g not seeing the Business analysts as Customers.
    But until that changes , here is my view:
    I suppose the Requirements Model Testers may as well be the Pair Programming Test firsters.It's this flexibility that's difficult to grasp.
    But consider this scenario where the business wants to test the waters / market conditions as it were and throws in some data to simulate a non-reality. This was used quite often as a pre-cursor to specifying change requirements and usually over a period of time of months. Of course the programmers were kept in the dark so as not to influence the results in any way.
    Where would this fit in with the XP philosophy ?
    Oh okay, I concede the Business Analyst pretending to be the Customer would have the Test first conditions thrown into the pool and use those Tests as the basis to then refactor and design.There are benefits in not having the programmer involved in these type of Test first conditions hence the recomended extra level of
    "deriving tests from Requirements Models".
    XPers handle small incremental changes. How difficult is that for the BA/Customer to keep an eye on the big change and know that eventially all small changes will add up to the BIG change - so as to start setting Business operational changes in motion or should the business be prepared to deviate in small steps ?
    I think the answer is in continuous regression testing until the results show that the change is complete and ready to roll out.
    Some business changes have to be implemented with a BIG BANG! or even retracted.
    The issue that the article brings out to me is : Where do you draw the line before "burdening" the programmer rather than "empowering" ? That is the primary reason he talks of separating the analyst and designer roles. I think there should be three levels analyst, designer and programmer.
    And his approach also handles applying XP to big systems (some parts of it may be legacy).
    regards
    [ June 22, 2003: Message edited by: HS Thomas ]
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by HS Thomas:
    I think I just stopped short of saying XP is bigger than RUP and getting myself into more trouble.


    The scope of RUP is bigger than that of XP without question - technically, XP can even be thought of as an instance of RUP, tailored to small, colocated teams.
    But that's not necessarily a bad thing. Often it is much easier to know what practices you need to add than to know what practices you should remove from your process.
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by HS Thomas:
    I suppose the Requirements Model Testers may as well be the Pair Programming Test firsters.


    Remember that XP has two required levels of testing: unit tests, done by the developers during test driven development and acceptance tests, specified by the Customer as acceptance criteria for the user stories. The customer might well be assisted doing the latter by professional testers on the customer team.
    With all due respect, I suspect this discussion could be much more productive if you'd read some more of the basic XP literature (like "XP installed").

    XPers handle small incremental changes. How difficult is that for the BA/Customer to keep an eye on the big change and know that eventially all small changes will add up to the BIG change - so as to start setting Business operational changes in motion


    One way to do this is to group user stories into themes.
    What are your specific doubts?

    should the business be prepared to deviate in small steps ?


    They should certainly think about this, as it would probably increase ROI and provide valuable feedback.

    Some business changes have to be implemented with a BIG BANG! or even retracted.


    If that really is the case, just do it. The developers could still work highly incrementally.

    Where do you draw the line before "burdening" the programmer rather than "empowering"?


    Why don't you let the developers draw the line for themselves? Remember, XP team members don't *get assigned* to tasks, they *choose* them from the pool of those that need to be done in the current iteration.

    And his approach also handles applying XP to big systems (some parts of it may be legacy).


    Why can't "pure" XP be applied to big systems? (When is a system "big" anyway?) What is so special about incorporating legacy systems?
    [ June 22, 2003: Message edited by: Ilja Preuss ]
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Ilja.

    With all due respect, I suspect this discussion could be much more productive if you'd read some more of the basic XP literature (like "XP installed").


    Will do. As I've said above my view does have the fixtures most do about XP. Does this cover The Planning Game. Perhaps this is crucial to understanding XP? The Planning Game in the context of developers is a new concept. It certainly wasn't a requisite before and almost certainly would have been discouraged.
    I am also certain that most businesses would be approaching XP from ACW's viewpoint.
    And there are other issues to consider like CBD to maximise re-use, AOP ( in order to do what?, possibly maximise re-use) which need some architectural issues and keeping a close eye on what-the-business wants (requirements modelling) to be in place, that your average XP Programmer with the best will in the world isn't going to be able to handle.
    What's so different about legacy systems ? Perhaps in the way the system is supported. Nothing that a new breed of XP Programmers couldn't change.
    ,(pause for thought) Hmmm.
    Consider the biggest Flight Reservation System that has taken has taken several thousands of man years to develop.

    see ref to American Airlines' SABRE in Does IT matter


    The system also supplies information to criminal intelligence departments with regard to movements of persons,goods (where it has to be matched with movements of large sums of money).It has other money-generating spin-offs. The people who understand the intricacies and spin-offs of the system are going to be really interested in the processes that implement changes to the system. They will have a hard time accepting that a core of eXtremeists have the power to implement change that rapidly, without the requisite controls to monitor and check .
    Harking back to work by Peter Checkland in Systems Thinking, Systems Practice which draws parallels between biological systems and computer systems. If I recall correctly , environmental changes impact upon the system but the in-built self-regulatory system decides which changes to re-act to.
    This self-regulation was seen as an Organisational / Organism needs-to-survive requirement and it is already in place.

    XP, CBD, AOP can be seen as tools that help cope with rapid environmental changes that impact upon a business like deregulation in a highly competitive market.
    They could go for the BIG BANG approach and see what comes out in the wash.
    But a learning self-regulating organisation would draw some lines first.
    Where to XP and where not to.
    When to CBD etc...
    But it is eXtremely difficult to work with these where the they haven't even entered the Organisations sub-consciousness or if it's seen to be affecting existing work practices.
    So realistically these practices are applied more effectively in new systems. But as the organisation learns and the scope of these new systems grow into large systems and become legacy, these practices would have been adpoted to some extent
    hopefully.
    But I'm afraid that terms like game , themes , stories don't help it's adoption at an organisational level but maybe at a developmental one. And then they will be forced to be transmorphed into the equivalent RUP terms
    to be adopted and recognised by the organisation. I'd be interested in knowing if there are any Fortune 500 companies that have adopted XP to any extent. Links to these would be appreciated.
    Well , that's my take on XP and Procedure-Orientated Programming paradigms.
    Having drawn my lines I will beg, borrow and steal and get on with that XP reading.
    regards
    [ June 25, 2003: Message edited by: HS Thomas ]
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Here is an article where the author Carmine Mangione , who leads a company with XP teams and is trying to work with Fortune 500 companies for XP adoption.
    Software Project Failure : The Reasons the Costs
    He has shown different Cost- ROI models and has listed 5 failure traps - 4GL tools , IDEs, Scripting, re-engineering, prototype traps.
    Unfortunately , he has not shed any light in his article on how XP would fare better.
    But then that's something only an organisation gets to know by learning and that experience is perhaps unique to the organisation.

    Learning institutions tap into that experience across several organisations.
    These institutions across the world then form a common body of knowledge on which new graduates are taught ways of measuring costs of adopting vs not adopting XP with new technologies and without and vice-versa. Well, you know how it goes.
    In the meantime you are more likely to be practising "pure" XP if working for a technology company like T-Spaces , X-Spaces, Search Spaces -usually a partner of a Fortune 500 company (in which case some of these practices may filter through - kind of an early adoption).
    An organisation could also start a few all-or-nothing pure XP low-risk projects to "study" them.Practices like Pair Programming and Test-first then design are easily propogated once the benefits are realised. Once the right team is in place , evidenced by high morale, rapid results/feedback etc etc the transition to higher-risk projects is easier.
    Sorry. That's probably a lot more than you bargained for and quite likely has been said before.
    regards
    [ June 23, 2003: Message edited by: HS Thomas ]
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I see the concerns have some coverage in wiki.
    Separation of roles:
    JustaProgrammer
    Hard systems Engineering as opposed to "Soft" systems a la Checkland :
    ProductLineApproach
    Illja, I shouldn't have had any of these doubts.
    With your knowledge of XP in Project Velocity, Load Factor etc would you say XP was a "Soft" ( woolly Values, principles) or a "Hard" (concrete and measurable enough to make decisions on) Systems methodology ?
    Oh Okay, I've now come across concepts of WorkQueue VS ReleasePlan. The latter is familiar.
    And also transformation from UserStory to EngineeringTask:
    regards
    [ June 24, 2003: Message edited by: HS Thomas ]
     
    reply
      Bookmark Topic Watch Topic
    • New Topic