An Example of Using Rod's Pattern DTD
Here's an example of a pattern marked up using the pattern document type defintion. Following the markup are some examples of renderings that might be generated from the XML code.
You can return to the main page for Rod's draft pattern DTD.
(My apologies to Jim Coplien and AT&T, they have nothing to do with this. I simply needed a short, concrete
and easy to follow example. The original version of this pattern can be found at http://www.bell-labs.com/people/cope/Patterns/Process/section18.html.)
<!-- ################################################################################ # EXAMPLE OF PATTERN MARKED-UP USING PATTERN.DTD TAGS # ################################################################################ --> <!-- header and reference to dtd ommitted --> <pattern> <name>Code Ownership</name> <problem> <thumbnail> A Developer cannot keep up with a constantly changing base of implementation code. </thumbnail> A Developer cannot keep up with a constantly changing base of implementation code. </problem> <context> <thumbnail> A system with mechanisms to document and enforce the software architecture, and developers to write the code. </thumbnail> A system with mechanisms to document and enforce the software architecture, and developers to write the code. </context> <forces> <itemlist> <item> Something that's everybody's responsibility is no one's responsibility. </item> <item> You want parallelism between developers, so multiple people can be coding concurrently. </item> <item> Most design knowledge lives in the code; navigating unfamiliar code to explore design issues takes time. </item> <item> Provisional changes never work. </item> <item> Not everyone can know everything all the time. </item> </forces> <solution> <thumbnail> Each code module in the system is owned by a single Developer who is the only only allowed to modify the module. </thumbnail> Each code module in the system is owned by a single Developer. Except in exceptional and explicit circumstances, code may be modified only by its owner. </solution> <resultingContext> The architecture and organization will better reflect each other. </resultingContext> <relatedPatterns> <!-- Note that by "before pattern", I mean that the referenced pattern establishes the context of this one. By "after pattern", I mean that this pattern helps to establish the context of the referenced pattern. --> Related patterns include <patref pattern="Architect Also Implements" relation="before pattern">Architect Also Implements</patref>, <patref pattern="Organization Follows Market" relation="before pattern">Organization Follows Market</patref>, and <patref pattern="Interrupts Unjam Blocking" relation="after pattern">Interrupts Unjam Blocking</patref>, <P> The pattern <patref pattern="Review The Architecture" relation="after pattern">Review the Architecture</patref> helps keep designers and architects from developing tunnel vision from strict application of this pattern. </relatedPatterns> <rationale> Lack of code ownership is a major contributor to discovery effort in large-scale software development today. Note that this goes hand-in-hand with architecture: to have ownership, there must be interfaces. This is a form of <!-- Note that by "example of", I mean that this pattern is an example of the referenced pattern. --> <patref pattern="ConwaysLaw" relation="example of">Conway's-law</patref>-in-the-small (see also <patref pattern="Architect Also Implements" relation="before pattern">Architect Also Implements</patref>). <p> Arguments against code ownership have been many, but empirical trends uphold its value. Typical concerns include the tendency toward tunnel vision, the implied risk of having only a single individual who understands a given piece of code in-depth, and breakdown of global knowledge. Other patterns temper these problems (see <patref pattern="Review The Architecture" relation="after pattern">Review the Architecture</patref> and <patref pattern="Engage Customers">Engage Customers</patref>. <p> Tim Born argues that there is a relationship between code ownership and encapsulation, in the sense that C++ protection keeps one person from accessing the implementation of another's abstraction. <p> Law is property, and the lack of identifiable property leads to anarchy (Rousseau et al.). <p> It has been argued that code ownership should be applied only to reusable code. Such a constraint would be worthy of consideration if someone comes up with a good distinction between usable code and reusable code. </rationale> <version> <date>1995.03.23</date> <time>09:00:44 CST</time> <revision>1.0</revision> </version> <copyright>Copyright © 1995 AT&T</copyright> <author> <propername> <firstname>James</firstname> <lastname>Coplien</lastname> </propername> <email to="cope@belllabs.com" subject="Code Ownership">cope@belllabs.com</email> <href url="http://www.bell-labs.com/people/cope/index.html"> http://www.bell-labs.com/people/cope/index.html</href> <org> <name>AT&T Bell Laboratories</name> <href url="http://www.att.com/index.html"> http://www.att.com/index.html</href> </org> </author> </pattern> <!-- ################################################################################ # END EXAMPLE # ################################################################################ --> |
Here's one rendering that might be generated from the mark-up. Note that the order of the sections here is diffenent from that of the XML source.
|
Here's a "thumbnail sketch" generated from the XML source. This could be listed, for example, as an "external patterns" section of a pattern that references this one.
Pattern Name | Problem(s) Addressed | Proposed Solution |
---|---|---|
Code Ownership | A Developer cannot keep up with a constantly changing base of implementation code. | Each code module in the system is owned by a single Developer who is the only only allowed to modify the module. |
(Again, my apologies to Jim Coplien and AT&T, they have nothing to do with this. I simply needed a short, concrete and easy to follow example. The original version of this pattern can be found at http://www.bell-labs.com/people/cope/Patterns/Process/section18.html.)