Mon Feb 20 16:53:02 GMT 2012 From /document/software+design/GUI+design
agile_2010_Cindy_McCracken
(google search) (amazon search)
download zip of files only Mon Feb 20 16:53:02 GMT 2012 From /document/software+design/GUI+design agile_2010_Cindy_McCracken(google search) (amazon search) Thu Dec 29 15:35:42 GMT 2011 From /document/software+design Vernon_2011_1(google search) (amazon search) Tue Nov 29 18:32:38 GMT 2011 From /document/software+design StrangeLoop2011-DeanWampler-HeresiesandDogmasinSoftwareDevelopment(google search) (amazon search) Fri Oct 21 16:32:50 GMT 2011 From /document/software+design Cheatsheet-Performance-Principles-Patterns-and-Anti-Patterns(google search) (amazon search) Sun Jul 24 16:08:36 GMT 2011 From /document/software+design 02-Code-Quality(google search) (amazon search) Sun Jul 24 14:36:08 GMT 2011 From /document/software+design Object-Oriented(google search) (amazon search) Thu Jun 30 17:02:38 GMT 2011 From /document/software+design practical-file-system-design(google search) (amazon search) Wed Mar 23 15:58:22 GMT 2011 From /document/software+design _atlantic_monthly-broken_windows(google search) (amazon search) Sat Apr 18 19:10:26 GMT 2009 From /document/software+design Evolving Frameworks_ A Pattern Language(google search) (amazon search) Wed Sep 17 15:08:22 GMT 2008 From /document/software+design Everything.You.Know.is.Wrong(google search) (amazon search) Mon Mar 17 17:25:16 GMT 2008 From /document/software+design/Design+pattern+example+in+aspect+programming READMEImplementations of GoF Design Patterns in Java and AspectJ Code base documentation Overview ======== The goal was to provide parallel implementations in AspectJ and Java that allow for direct comparisons. It has to be noted that most patterns offer variability in the implementation approach. We choose the one that appeared to be the most general. Sometimes, the AspectJ version implements a slightly different (or additional) case(s). This is because AJ sometimes allows for additional functionality. Please refer to the web page for a detailed description of this work. Example Setup ============= All pattern examples have a class called Main. This class is the test driver for the particular example. The Main classes are extensively documented using ajdoc, usually describing the experimental setup and the assignment of roles to participants. In most cases, the differences between Java and AspectJ implementations are also mentioned. Documentation (ajdoc) ===================== It is possible to generate the ajdoc documentation for either all examples, for only the reusable library aspects, or for one particular example. Since ajdoc shows type names without their package (on the left hand side), multiple types with the same name (but residing in different packages) may be confused when the documentation for all examples is generated. ==> Generate documentation for all examples: use the makeDocs batch file. (1) Change to the directory that you extracted the ZIP archive into. (2) Type "makeDocs" to generate the HTML documentation in the docs subdirectory. ==> Generate Documentation for the reusable library aspects: use the provided makeLibraryDocs batch file. (1) Change to the directory that you extracted the downloaded ZIP file into. (2) Type "makeLibraryDocs" to generate the HTML documentation in the docs subdirectory. ==> Generate docs for a single example: use the makeSingleExampleDocs batch file. (1) Change to the directory that you extracted the downloaded ZIP file into. (2) Call the batch file. It needs two arguments: the name of the pattern and the language used. For example, type: "makeSingleExampleDocs singleton aspectj" or type: "makeSingleExampleDocs templateMethod java". Within the ajdoc documentation, we tried to separate type names from our examples and role names (as presented in GoF). We show roles names in italics and actual type names in code font. This is reflected in the ajdoc documentation. Questions, feedback, suggestions, etc. The AODP web page is http://www.cs.ubc.ca/labs/spl/aodp.html Please send all questions, feedback, and suggestions to Jan Hannemann (jan@cs.ubc.ca). We are very much interested in improving our code. Please do not hesitate to drop us a line. Appendix ======== This appendix outlines how to compile and run the examples provided, and how to generate ajdoc documentation. A number of DOS batch files exist that automate these tasks somewhat. Note that they only work in Windows environments. The following is a list of tasks and a description of what commands accomplish them. For compiling, running and generating documentation, two options are given. The first one is using a provided script; the second is the standard command-line option (longer, but will work on all operation systems). Set up your system: 1. Install Java and AspectJ 2. Make sure your CLASSPATH contains the current directory (denoted by a period), e.g. CLASSPATH=.;C:\... 3. Extract the ZIP file into a directory of your choice 4. Change to that directory Compile Java and AspectJ versions of a design pattern example (e.g. observer). Choose one: � makePattern observer � ajc @examples\observer\files.lst Run a compiled example (e.g. observer). Choose one: � testPattern observer (this runs both Java and AspectJ versions) � java examples.observer.java.Main (for the Java version), java examples.observer.java.Main (for the AspectJ version) Generate documentation for all examples. Choose one: � makeDocs � ajdoc -private -d docs @allPatterns.lst Generate documentation for the library aspects. Choose one: � makeLibraryDocs � ajdoc -private -d docs ca.ubc.cs.spl.pattern.library Generate documentation for a single example (e.g. the AspectJ version of the observer example). Choose one: � makeSingleExampleDocs observer aspectj � ajdoc -private -d docs examples.observer.aspectj View the generated documentation: � Open the file index.html (located in the docs/ subdirectory) with your favorite browser. (google search) (amazon search) Mon Feb 26 07:12:12 GMT 2007 From /document/software+design ExampleOfGoodAPI(google search) (amazon search) Mon Feb 26 07:10:52 GMT 2007 From /document/software+design HowToDesignGoodAPI(google search) (amazon search) Mon Dec 18 03:15:44 GMT 2006 From /document/software+design dddquickly(google search) (amazon search) Tue Jun 13 15:09:58 GMT 2006 From /document/software+design Event-driven Architectures(google search) (amazon search) Tue Mar 21 10:27:32 GMT 2006 From /document/software+design AdvancedPrinciplesOfClassDesign(google search) (amazon search) Tue Mar 21 05:06:12 GMT 2006 From /document/software+design short present of how to make good API design(google search) (amazon search) Wed Jul 07 16:00:00 GMT 2004 From /document/software+design pattern examples(google search) (amazon search) Tue Jun 08 16:00:00 GMT 2004 From /document/software+design architect comment pattern---------- Forwarded message ---------- Date: Thu, 29 Aug 2002 17:16:33 +0200 From: John Favaro Reply-To: extremeprogramming@yahoogroups.com To: Yahoo XP Group Subject: [XP] An architect's comments on patterns In a recent thread I passed on some comments from my brother, who is an architect, on the "design-build" paradigm. I had asked him what he knew about it, since there was interest in the software engineering community as an analogy to optional scope contracts; and I was interested in hearing at least one architect's point of view. The resulting discussion was interesting enough that I decided What The Heck Let's Go All The Way and I asked my brother another question: "What do you know about Christopher Alexander? His concept of patterns has generated a great deal of interest in the software engineering world." Here is his response: "He was a kind of guru in the 60's and 70's. "the 'patterns' refers essentially to 'tradition' ; his basic point being that over 5,000 years immutable patterns of building and architecture emerge that we can rely on when taking on a building design; (for example, if you look at good rooms in domestic settings the best ones always seem to have windows on two sides, preferably opposite sides) He came up with 'patterns' instead of 'tradition' because it was Berkeley in the sixties when tradition was seen as oppressive, euro-centric and 'irrelevant'. He wanted to catalogue all the patterns of architecture in the history of the world (all over the world, not just Europe of course) in the belief that there would be a scientific way to get to good design--therefore avoiding the role of culture (because culture requires values and judgment and whose culture are we talking about anyway?) Of course it didn't work because architecture is an art not a science. And his concept of patterns is ten times more oppressive than the concept of the context of tradition as the fertile ground within which innovation thrives (innovation is all about finding the exception to the rule that changes the way we look at the rules, and sometimes even the rules themselves). The buildings he actually produced (not very many, small residences) ended up being ultra-conservative (very eurocentric, in fact, like little Austrian cottages) and not very remarkable. "computer science is a science but I have a feeling that computer applications are as much an art as a science, since they're about tailoring to specific needs, making choices and judgments, relating choices to a set of values on behalf of the client, etc. "that's why the design-build analogy is big trouble because the intent is to cut the 'artist' out of the equation--let the accountants drive the choices, after all it's all cut and dry right?, it's all just science; that's what the HMO's have done to doctors and medicine; our field went through it after WWII--you're next. "run for your life..." (Yes, he can be a bit provocative and dramatic) In a second message he added this: "well, the solution is to train the computer consultants to be responsible about budget and schedule--that time and money are as potent in creative possibility as anything else; the solution is not to cut them out of the picture altogether; that just leads to self-fulfilling ends--assume the consultant is only interested in design, let him focus on that in the vacuum of budget and schedule and 'we'll handle that part (even though we don't know what the hell he's talking about),' thus setting up a relationship of conflict and misunderstanding from the beginning and encouraging the designer to be irresponsible and narrowly focused; "you treat people like children, they're going to act like children;" Since I saw it first, I guess I get to make the first comments :-) - after all the opinions expressed by us software guys about the architecture field, it's kind of funny to see an architect commenting on OUR field. - regarding his opinion on Alexander's work ... well, it certainly made for interesting reading. Whether his opinion is universally shared in the world of architecture I don't know. One possibility that occurs to me is that my brother's goals for a successful building might be different from Alexander' s. What he did seem to be implying, however, is that Alexander ultimately did not have a lasting influence in the world of architecture. Again, I don' t know how true that is. - I did find interesting his insistence on measuring Alexander's ideas by the buildings that were actually built with them. That meshes well with the centricity of code artifacts in XP, as the principal measure of results. - regarding his characterization of the nature of computer applications, I thought he did pretty well, actually. - when he starts talking about design-build again, I think this is once more where the difference between our contexts comes out. As Dan Palanza and others explained in the earlier thread, XP in particular is doing a lot to eliminate the antagonistic relationship between design and build in our context. Likewise the emphasis in agile development on accepted responsibility for time and budget considerations. The analogy to his warning about designers working in a vacuum of time and budget constraints in our situation might be that of *requirements analysts* working in vacuum of time and budget constraints, something Martin Fowler has also commented on. Perhaps the overriding impression I get from all this is that, as others have written recently, maybe we shouldn't push quite as hard as we do to find perfect analogies between our world and the architectural world every single time. Patterns and design-build may not have been successful in the architectural world (if that's even true) -- but nobody doubts any more that patterns have been hugely successful in the software world; and it looks like the design-build paradigm as it is being tailored and applied in the software world (e.g. with optional scope contracts) will probably be successful, too. To each his own context. John (google search) (amazon search) Sun May 30 16:00:00 GMT 2004 From /document/software+design replace Conditional With Visitor(google search) (amazon search) Wed Mar 24 16:00:00 GMT 2004 From /document/software+design/Design+pattern+example+in+aspect+programming/thinkAbout CommandProtocol(google search) (amazon search) Wed Mar 24 16:00:00 GMT 2004 From /document/software+design/Design+pattern+example+in+aspect+programming/thinkAbout CommandReceiver(google search) (amazon search) |