RSS feed [root] /software design /document




login:

password:

title search:




 


Sat Sep 28 08:10:27 GMT 2024

software design



(google search) (amazon search)
second
download zip of files only

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)


Tue Jan 12 17:28:40 GMT 2010 From /document/software+design

testBus



(google search) (amazon search)


Fri Jul 10 15:08:04 GMT 2009 From /document/software+design

saga



(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)


Thu Sep 18 16:54:56 GMT 2008 From /document/software+design

spec



(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 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 Aug 27 16:00:00 GMT 2003 From /document/software+design

Essence Pattern



(google search) (amazon search)


Wed May 21 16:00:00 GMT 2003 From /document/software+design

mapping Objects



(google search) (amazon search)


Wed May 07 16:00:00 GMT 2003 From /document/software+design

Keiron Domain Model Centric



(google search) (amazon search)


Tue Apr 09 16:00:00 GMT 2002 From /document/software+design

pattern 201



(google search) (amazon search)


Fri Feb 08 16:00:00 GMT 2002 From /document/software+design

open close principle



(google search) (amazon search)


Thu Jan 17 16:00:00 GMT 2002 From /document/software+design

pattern 101



(google search) (amazon search)


Mon Aug 20 16:00:00 GMT 2001 From /document/software+design

uml diagrams



(google search) (amazon search)


Tue Jul 03 16:00:00 GMT 2001 From /document/software+design

MVP



(google search) (amazon search)


Tue Jul 03 16:00:00 GMT 2001 From /document/software+design

UI myth



(google search) (amazon search)


Tue Jul 03 16:00:00 GMT 2001 From /document/software+design

comment of comment



(google search) (amazon search)


Tue Jul 03 16:00:00 GMT 2001 From /document/software+design

complexity



(google search) (amazon search)


Tue Jul 03 16:00:00 GMT 2001 From /document/software+design

programming


Subject: Re: Some programming problem of Newbie
Date: 4 Aug 1999 10:59:35 +0100
From: csstjds@brunel.ac.uk (John D Salt)
Organization: Brunel University, Uxbridge, UK
Newsgroups: comp.software-eng

In article <7o8q27$u1p$1@nnrp1.deja.com>,
Carfield Yim wrote:
>I know that it is good to writing pesudo code before implentation.
>But everytime I want to start to write pesudo code, I don't know how to
>start, especially when doing program in visual tools (e.g.:C++ Builder).
>And so I keep in delay and delay, at last, I go back to writing code
>directly after knowing what should I do.
>
>I just wonder, how can I train myself to follow good programming
>practice? Any book can help me?

First of all, I wouldn't worry too much about following your
preception of other people's idea of "good programming practice".
What's "good" is what's good for you, and programming people
have very different individual tastes and practises.

Still, whether you use pseudo-code or not, it's pretty obvious
that you should have some idea what you want to write before
you write it. How much of a "programming plan" do you have
before you dive into code? Do you keep hand-written notes
beside the terminal as you go along? Do you ever make large
changes to what you're coding just to get it to compile?

It also matters what style of programming you're attempting.
If you're using C++ to create object-oriented applications,
I'd say pseudo-code is probably not a good way to get a
clear picture of the overall structure of the program. For
O-O development, restrict pseudo-code to the internals of
individual methods (and many methods will be so simple they
don't need pseudocode at all). Use something like CRC cards
to help you shape the class structures, responsibilities and
interactions.

If you still need to write pseudocode but can't seem to get
started, try some or all of the following:

* Write by hand, not by machine.

* Start with the universal problem-solving Nassi-Schniederman
diagram:

+----------------------------+
| Begin |
+----------------------------+
|| Solve_Problem ||
+----------------------------+
| End |
+----------------------------+

...then refine it incrementally. There's obviously no problem
"getting started" here, as the start step is the same for
everything. Yes, I know it sounds daft, but it works for me.

* Try focusing on the data structures first rather than control
structures first.

* Don't be afraid to throw rough work away, often.

* Take a nip of whisky before you start to get the creative
juices flowing.

It's possible that the programs you're trying to code now are
simple enough that you can see the whole answer in your head
at once. In this case, pseudo-code (or any other design
technique) may seem not to be very useful. If this is the
case, try a problem so big or so hard you can't see the whole
answer (or even the whole problem!) all in one go.

All the best,

John.
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.

(google search) (amazon search)


Tue Jul 03 16:00:00 GMT 2001 From /document/software+design

recursive



(google search) (amazon search)


Wed Sep 22 16:00:00 GMT 1999 From /document/software+design

Pattern Detection



(google search) (amazon search)