SD East 2002

Software Development Conference, Boston

Wednesday, November 20, 2002

Advanced Principles of Software Design

Open/Closed Principle: Modules should be open for extension, but closed for modification" - Bertrand Meyer.

Simple design, release early & often, in case of new requirements take the bullet & refactor, vs. try to anticipate every future requirement with in the initial design, also known as overengineering, which results in a system that's large and difficult to change in the face of unforeseen requirements. Amazon, for example, may change their site constantly, and the user can do nothing about it.

He spent an extremely long time introducing the concept of polymorphism, and describing how a polymorphic C++ class was better than C function calls. This is not exactly an "advanced principle of software design".

Out of the blue: "Lasers are great. Has anyone ever lit up a stop sign with a laser? It just explodes with light." He balanced a gumball on his laser pointer. Showed sparkle pattern that moved with your head and has no focal plane. Could be related to effects of single wavelength, or pattern of the red receptors in the eye. This was interesting to me, and I'd noticed this effect myself with a laser level. I'm not sure why he chose to break into this, though, because he suddenly snapped out of it.

Liskov Substitution Principle: "Derived classed must be usable through the base class interface, without the need for the user to know the difference." Square may seem to be a subtype of Rectangle, but it's not substitutable. Word "isa" in English isn't a good fit for inheritance. "Behaves as a" might be better. Can't take away functionality of a base class in a derived class.

He spent a long time leading up to the introduction of the Adapter pattern.

Seeing as there wasn't much time left, he detoured into astronomy history, starting with Aristarchus and continuing person by person. It was all interesting, but seemed to have nothing to do with software development, until, several minutes of this later...he said that his time was up and never mind.

So in an hour and a half, we only got to two of the four principles he was supposed to present (from his slides and the catalog synopsis) out of twelve principles listed in his books. I did get something out of this class, just not much.

I should have gone to XLinks instead.

Use Case Design Pattern: Realistic Implementations in Java

Paul R. Reed, Jr., author of Developing Applications with Java & UML.

Most distinctive quote: "You have to look at use cases as a pair of striped trousers." (More on this below.)

Use case: a transaction from the actor's perspective. Ultimately, the actor receives some type of response that the request has been satisfied. Coarse-grained, not a functional decomposition.

Recommends theserverside.com web site.

Back to the trousers. Success pathways were drawn down the right leg, failure pathways were drawn down the left leg. Some of the steps along a pathway may fail, but that doesn't necessarily mean that the path fails. Success pathways include "happy path".

Use case relationships: include, extend, generalize, realize. Place Order includes Security, Seasonal Discount extends Place Order, etc.

Use case realization: at least one per use case, one per technology used. Such as an "Order product Web" realization for the "Order product" use case. He always makes a use case control class, a facade which is the conductor of the use case orchestra, as a student once put it.

Patterns. (Went over history, Gang of Four, Design Patterns book, etc.) Command pattern is implemented in Struts and is a very good fit for use cases. He'll have his slides with annotation on jacksonreed.com in a week.

Showed some diagrams using Rational Rose.

Use Case realization: brainstorming area for pathways, collaboration diagrams, sequence diagrams class hierarchies. Lots of UML here.

Java Server Pages. Model 1, JSP page acts as View and Controller, leads to bloated JSP page code. Initial model, no longer best practice.

Model 2 combines servlet, acting as request router, with JSP page, providing formatting. With Java Beans, HTML Form -> Servlet -> Java Bean, controller -> Beans for business logic. Enterprises are often saying "we don't need Enterprise Java Beans, Java Beans are all we need." Sometimes EJB is way overkill. Controller would start transaction (have helper class do it) , pass operations to other beans, coordinate reply. JSP formats reply. Under EJB, model would be similar, but controller would probably be a stateless session bean. Also similar under .NET.

Value Objects. Data-only object used for remote calls. (Called Data Transfer Objects in another talk.)

Data Access Objects encapsulate SQL for a class.

If you're not using Struts, run out and get it. It will save a lot of code.

XML Schema Language

Eliotte Rusty Harold

I had intended to go to the Mapping Objects to Relational Databases test, but it was overflowing. Not even standing room only. People were already standing in all the standing room and others were trying to peek in from outside the door, including me. The geekpack was impenetrable, so several of us left. I went to the XML Schema class as a backup.

XML Schemas put forth requirements for an XML document to be valid. The standard goes further than DTD; for instance, DTD can't enforce item order. He used Xerces-J from the command line. Programs supporting schema validation: Xerces-J 1.4.4 and 2.x, Xerces-C++ 1.7.0, Oracle XML parsers for Java, C, and C++, MSXML in .NET. (He didn't recommand the command line as a regular mode of working.)

XML Schema looks simple at first, but there are a lot more namespace machinations in it than I thought. I was trying to get my head around them most of the time, so I let the notes slide as I tried to keep up.

Documents that must be validated use a namespace URI of xml schema-instance. Schema language not powerful enough to validate itself.

Schema is first pass at making sure the document is legal. Can't do everything in XML schema, for instance, you can't make sure a customer number is already in your database.

Complex types can have children and attributes. Simple types have neither. Main elements: xsd:element,xsd:attribute,xsd:complexType,xsd:simpleType.

Types aren't always obvious to the eye. 45.64 could represent a float, a string, a regular expression, or build 64 or version 45 of Microsoft Word.

Unfortunately the standard xsd:types gMonth and gMonthDay were defined out of sync with the ISO8601 spec and fixed in errata. So some older validators will react differently.

Avoid defining unqualified child elements in your schemas of qualified parents.

PSVI: post schema-validation infoset. Tells you types of elements.

Can't declare entities, handle parent models (where the child puts contraints on its parent, rather than vice versa).

XML Namespace considerations are extrememly involved and took up the bulk of the class.

Alternatives: Schematron, liberal tree-pattern-based validator implemented in XSLT. Essentially defines a list of assertions in XPath language, complements XML Schema well; RELAX-NG, direct competitor to XML Schema on standards track. Looks much more concise. Others: Hook, Examplotron, interesting but not practical. DTDs not dead.

His books: XML in a Nutshell, XML Bible Gold edition.

He still has not been able to read W3C XML Schema 1 spec cover to cover, too confusing.