You are currently browsing the monthly archive for September 2006.
Before I lose track of these links, here’s what I’ve been looking at for architecture diagram generation:
- Someone in the UK named Chris Wallace has some nice dynamic GraphViz examples.
- UMLGraph handles class diagrams and sequence diagrams using
- Martin Fowler posted a bliki entry about UML sketching tools.
- MetaUML looks like a fairly powerful way to incorporate UML into LaTeX documents. This looks to have more icons and such that UMLGraph.
Ok, so I should specify right off the bat my opinions about Java. I don’t like it, and many of its shortcomings more pronounced due to my experience with Python. I don’t like forcing a coupling between object and file hierarchies. I don’t like silly typing rules casting everything under the sun to an Object. I don’t understand the hype around JDBC: I expect my language to be bindable to my RDBMS, and I know that any advanced database programming will require sacrificing portability. I don’t like hearing advocates brag about the “write once, run anywhere” mantra when I know that not all JVMs (or JNI modules) are equal, or possible. I know Python’s not perfect either, but for the sake of my argument let me use it simply as a foil:
Why is software reuse so hard? My initial response to this was thinking about the human nature of pride and protectionism. Creators have a natural tendency to want to keep their creations owned by themselves. “Intellectual Property” is such a rush right now, with people screaming, “I thought of that first! You aren’t allowed to copy it, because it’s such a good idea!” The whole idea of proprietary software hinges on not sharing on a global scale.
The book describes more about software reuse within a company; namely, Software Product Lines. They describe how proactive reuse is difficult (because it’s Big Design Up Front) and typically ignored. Reactive reuse, on the other hand, is a basic point for refactoring and the whole DRY principle: if something’s repeated, separate the commonalities to reduce repetition. At some level, it’s a question of randomness and compressibility: Software is incompressible if it has no repetitions, and refactoring is a form of compression.
One strength I saw in the ATAM was identifying the need for relationships between the quality attribute requirements in a project. The book explains this as a Utility Tree, saying that requirements can be classified as a hierarchy (based on a “problem being solved” link). Given that they have worked on more real projects, I would guess that they have experience with what needs to be modeled.
However, I don’t really think a simple tree is sufficient. Certain quality attributes could be diametrically opposed, and a basic graphical display of that would be useful. Maybe a tree to represent “composition of requirement classifications” and an additional (directed?) graph to represent additional architecture-driving relationships. If it could be seen that one “set” of requirements was directly associated with a number of other sets of requirements, it would make sense, then that the focal point of requirements would be the focal point of architecture.
I’m a PHP programmer. I’ve been using it since ’02 or ’03, and I’m very familiar with the language and “enough” of the packages to get by. Over the last few days, I’ve been taking another look at Django. I’ve looked through most of its code (it’s surprisingly small, I figured it would be bigger) and am trying to wrap my head around it to see how effectively I could actually use it. Most of the time, I’m really comparing it to how I’ve solved a particular problem with PHP in the past, or seeing what sort of Program Transformation is involved between what I’ve done and what the Django devs have done.
It’s really interesting to see a big common area (and makes me satisfied, that my design isn’t crazy), but then to see something that, for me, has worked with a single method, but that in their framework has been extracted out into their entire MiddleWare suite. Me likey.
Last night I spent a few hours browsing through source code and documentation for a number of projects: Gaim, POV-Ray, Angband, and Freeside. While I didn’t see any documentation in those projects representative of the examples shown in the text, I did see one similarity in all of them. The major pieces of documentation were all well-targetted at a specific audience.
- Gaim included mostly a FAQ useful to read before downloading the source code: What did the project do? Who should be interested in the source code, and why? What is the process or point-of-contact for getting involved in the project?
- POV-RAY included tons of documentation directed towards the end-user. While they aren’t a substitute for developer documentation, the entire architecture of POV-Ray is based around parsing inputs and geometric rendering of outputs, so many of the architectural decisions will be essentially “guessable” by examining the user interface.
Ok, I have a beef. I hate it when people say “well theoretically this should do X…” when that’s not what they really mean. Most of the time I hear it misused, the simplest replacements are either “ideally”, or “it should”, or “maybe”.
Attribute-Driven Design (ADD) is a process to developing a software architecture. It is presented within the context of the Evolutionary Delivery Life Cycle (EDLC), a software lifecycle based around architecture. The EDLC describes two feedback loops:
- Concept – Requirements – Architecture and high-level Design
- Iterative Development – Delivery – Feedback – Redesign from Feedback
The most critical part of the lifecycle that I see is that the iterative development is targetted at localized changes. The feature-requests that would be architectural (i.e. “no no, it has to run on this QNX cluster, not Linux!”) are expected to be taken care of prior to initial development. This is certainly more financially feasable given the cost of changing architectural concepts after development has started, but it does place a larger burden on the architect (get the high-level stuff right or the low-level stuff will be constantly struggling).
Ok, I got to see the editing capabilities of paternshare.org. Here are my miscellaneous notes while browsing:
- Why does the “edit” view of a page look so completely different from the other views? It is awful.
- The “preview” command looks like it just saved immediately and went to the page, rather than doing a real preview
- I see instructions for “how to write a pattern”, but not “how to use our Wiki syntax”. That’s necessary on the edit page.
- Why doesn’t the system automatically copy the default template, or allow one of a set of default templates to start with? e.g.
- why can only logged-in users get RSS feeds?
- History view doesn’t show diffs (or even a +chars -chars to give us an idea of how big the changes are).
It looks like Arlo has Feline Endocrine Alopecia – apparently a disorder involving hair loss. He’s missing hair symmetrically on the backs of four of his legs, but his behavior and skin health seem perfectly fine.
My kitty is going bald!