Posts Mentioning RSS Toggle Comment Threads | Keyboard Shortcuts

  • Mike 9:49 pm on April 16, 2008 Permalink | Reply
    Tags:   

    Gumby and Architecture Rules 

    I keep my desk pretty minimal. Its pretty big, but the desktop is usually about 80% cleaned. The few things that I keep on it, other than a notebook and pen, are strategically placed and are designed to be conversation pieces. These items include a 2 gallon fish tank, with a Tiger Barb and plant, a poseable Gumby figure, and the latest addition, my Architecture Rules mug.

    Now, the whole reason for these artifacts is to draw those two pass by my desk into a conversation – this offers a break in the day and a chance to get to know the people around me better.

    The fish tank has been very popular, a lot of people can relate, or have a story, or just like to look at the fish. Gumby is a lot of fun. Its fun to see those who recognizes him, and those who don’t even know who Gumby is. I wanna order a couple of Blockhead figures to go along side him.

    tigerbarb gumby mug

    So the new one is the Architecture Rules mug that I designed and put up on CafePress. This has been a great way for me to get the people around me to talk about software, and specifically, about software architecture. I highly recommend that, if you use Architecture Rules, you pick up one of these mugs, put it on your desk, and start telling the world that you are actively mitigating architecture risk everyday. Hey, thats something you, your coworkers, your customers, and your bosses can get behind.

    Or, if you’re just looking for a new trinket to put on your desk, this mug is a lot cheaper and easier to maintain than a fish tank is. I have personally tested the mug and had successfully results with coffee, water, various teas, apple cider, and soup.

    I have to be honest, the price that CafePress charges, of $13.99, is rather steep for a mug, but it is a tall mug with a capacity of 15 oz., and a buck or so goes to supporting Architecture Rules. Right now we are trying to raise funds to snag the domain architecturerules.com. Your purchase would go a long way in helping to secure that domain.

    Here you can check out the upclose graphic. And if you can’t afford the mug, but you wanna help us get the domain or help us towards our current fund raising goal, you might be able to donate some change to the project.

    So, what toys do you keep on your desk? What are the best conversation starters? Do you keep any trinkets branded with a tool or technology (my pen branded with Sun Java)?

     

  • Mike 8:35 pm on April 13, 2008 Permalink | Reply  

    What is “Architecture”? 

    The term “software architecture” is really hard to nail down. Different people have been defining it differently since we began writing software. I am not going to be able to tell you exactly what it is, but I can give you an idea as to what people are saying. By understanding that no one agrees on what architecture means, you can throw out the term more carefully as you talk with other developers.

    First, I want to share one my favorite “white papers.” I, for many years, didn’t know what people meant when they said architecture (actually, they probably didn’t either) but after reading this 3 page paper by Martin Fowler, I finally wrapped my head around it. The document is titled “Who Needs an Architect” and can be downloaded from the author’s site. The light bulb when on for me when I read these lines…

    “Remember Johnson’s secondary definition: “Architecture is the decisions that you wish you could get right early in a project.” Why do people feel the need to get some things right early in the project? The answer, of course, is because they perceive those things as hard hard to change. So you might end up defining architecture as “things that people perceive as hard to change”

    “There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. That, and duplication.”

    Finally, now that makes sense to me. I’d paraphrase it as “The parts of a software system that you need to get right, the first time.” In the article, there is a discussion about a building. They mention the basement. When you have a home, you can change the interior around, add new paint, take down a wall, put up a wall, even build a new addition. However, the basement is the foundation. It’s not going anywhere. You can modify a house, but you can’t modify the basement. The basement makes up the home’s “architecture,” (but don’t confuse the basement with a database.)

    Different people have been defining it differently since we began writing software.

    I made this pretty bold statement to start off this explanation. Well, I have the proof to back it up. The Software Engineering Institute has a website. At it, they bring together published Modern, Classic, and Bibliographic Definitions of architecture. They also allow the “community” to submit their own definitions. They have one to two hundred definitions from senior analysts, project managers, software architects, doctors, and other “really important people.” These definitions follow many different themes, from definitions around concrete software, to definitions based on only the concepts of the software. Check out this list of Community Software Architecture Definitions for yourself.

    We’ll finish this off by sharing some content off of page 13 of a white paper titled Building Enterprise Architecture from Endava.com

    Architecture is defined as a subset of the design. While it is difficult
    to define which subset, the following definitions help:

    “The highest-level concept of a system in its environment.”
    (IEEE)

    The organization or structure of significant components, and
    their interactions.

    An abstraction of a system’s implementation.
    The parts or aspects of the design that are considered
    important.

    The parts or aspects of the design that need to be
    understood by many people, the shared understanding of
    the system design

    The decisions that are (or are thought to be) hard to change.

    Another shining example of how many different definitions for Architecture there is.

    Want to share your definition? What did you learn architecture to be?

     

    • Richard 7:36 pm on April 15, 2008 Permalink

      Your basement analogy is a good one, but I think it’s more subtle than that. My house doesn’t have a basement, but it does have a foundation. Sure, I can change some walls around, but not all of them. I can make cosmetic changes all I want, turning a bedroom into a den, for example, and vice versa.

      Other changes are more fundamental. I could not, for example, move my kitchen to another location without repiping most of the house. I can’t add certain walls unless I address the ductwork and airflow (to prevent freezing in a closed off space). I suppose I could simply replace the furnace with something more powerful to compensate, but it seems to me that would be the same thing as upgrading a server just to compensate for crappy inefficient code.

      (I’m not a technical person, just someone who writes about technology)

    • Ocean 11:23 am on May 2, 2008 Permalink

      You could just as well reverse the conclusion: architecture is those parts of the system that are most prone to change. This would make a bit more sense since the parts that don’t change often contribute very little value.

    • Dan Sickles 11:16 pm on March 8, 2009 Permalink

  • Mike 8:37 pm on April 5, 2008 Permalink | Reply
    Tags:   

    Configuration Method Chaining 

    We have all seen method chaining, especially in configuration classes. Architecture Rules has a typical configuration class that currently does not support method chaining. Modifying the public API of a tool is hardly ever a good thing, but in this case, the change would still be completely backwards compatible. So we decided to investigate method chaining to determine if it should be introduced into this project or not.

    What is it

    Method chaining is a programming technique that is supported by many public interfaces. It allows the programmer to call one method from – directly after – another. For example, in Java:

    Chained

    Event event = new Event()
.setDescription("")
.setStartDate(start)
.setEndDate(end)
.setPrivate(true);

    Unchained

    Event event = new Event();
event.setDescription("");
event.setStartDate(start);
event.setEndDate(end);
event.setPrivate(true);

    Where Is It

    We see it very often with configuration classes. Such as the Hibernate Configuration class.

    Configuration configuration = new Configuration()
.addClass(org.hibernate.Item.class)
.addClass(org.hibernate.Bid.class)
.setProperty("...dialect", "...MySQLInnoDBDialect")
.setProperty("...connection.datasource", "java:jdbc/test")
.setProperty("...order_updates", "true");

    Its also used commonly with the Builder Pattern which simply creates a complex object using a number of steps.

    How To

    Designing method chaining into your code is pretty simple. In Java, rather than returning void by a method, such as a setter methods, return the entity being acted on. In Java, just return this;

    class Event {

public Event setDescription(String description) {
this.description = description;
return this;
}

public Event create() {
... something complicated ...
return this;
}
}

    So, to change an existing class to support method chaining in Java, change all your void methods, to return the entity type, and add return this; at the end of the method. It is pretty much a trivial task.

    Concerns

    There are some concerns with method chaining.

    First, there are some out there who claim that chained methods are less readable. To them, it could be less readable. To other, more readable. Aligning the chained method calls on new lines can increase readability. A single line of method calls is certainly less readable than a single method call on a single line. Compare this to the examples of the Event class above.

    Event event = new Event()
.setDescription("").setStartDate(start).setEndDate(end);

    Second, mixing setter methods, with action methods can be very confusing to the readers. The problem comes with determining where these complex actions are taking place. Consider the following.

    int eventId = new Event()
.setDescription("")
.setStartDate(start)
.setEndDate(end)
.setPrivate(true)
.insert()
.getId();

    This is simple example. Most everyone understands that the insert() call is utilizing JDBC code to insert the Event in to a table, it probably sets the Event id property, and then the getId() returns that id. But what if the entity was more obscure, and the method name was not so clear? It might not be obvious where complex actions are taking place.

    A third concern is when do you stop? and when don’t you stop? Let say an entity has a dozen or so setters that are commonly called as part of setting up a usable entity. Should you call all twelve? Two groups of six? Group by type? What is more readable? what is less readable? I don’t know. Depends on the author, the readers, the context. There are a lot of considerations.

    When to Use

    Method chaining is pretty commonly used when you are performing one complete action, building a complete entity, or performing an atomic task.

    First, performing an action, such as a query. Here is an example from Hibernate.

    List cats = session.createCriteria(Cat.class)
.add( Restrictions.like("name", "Fritz%") )
.add( Restrictions.between("age", minAge, maxAge) )
.list();

    Second, building an entity. Sometimes this is done with a Builder class. With the example of the Event class, calling the setters could be chained. Calling insert() and getId() should not be chained.

    Finally, an atomic task, such as validation, could reasonably be chained.

    boolean valid = validator(value)
.isGreaterThan(0)
.isLessThan(10)
.isCurrancy();

    Our Dilemma

    We did this research to determine weather or not we should modify the Architecture Rules API to support method chaining in the Configuration and Rule classes.

    rule_class_diagram configuration_class_diagram

    Based on the research that we have done, since the Configuration and Rule classes have no actionable methods – just setters, they are essentially POJOS – we think it would be appropriate to chain those setters together, and that the resulting code would be no less readable or deceiving. We will include method chaining in 2.1.0.

    Resources

    http://martinfowler.com/dslwip/MethodChaining.html
    http://www.hibernate.org/hib_docs/reference/en/html/session-configuration.html
    http://kasparov.skife.org/blog/src/method_chaining.html

     

  • Mike 10:01 pm on April 2, 2008 Permalink | Reply
    Tags:   

    Architecture Rules 101 

    How about a short, sweet introduction to Architecture Rules.

    The Basics

    • Java.
    • Open Source.
    • Asserts architectural rules via unit tests.
    • Write your rules in XML.
    • Run your tests with junit, ant, or a continuous integration server.

    Your Rules

    You define your rules. For example, if you are developing n-tiered software, you probably have three layers. A DAO/integration layer, a service/business layer, and a presentation layer. Generally, the presentation layer does not interact directly with the integration layer. You could describe this rule as: com.company.project.presentation can not depend on the com.company.project.integration package. Its that easy.

    The XML

    The XML is in architecture-rules.xml and contains two section: <configuration> and <rules>. Configuration describes where your files are, and the rules simply describe a package, and one or more packages that it can not depend on.

    <architecture>

<configuration>
<sources>
<source>\target\classes</source>
</sources>
</configuration>

<rules>

<rule id="dao">
<packages>
<package>
com.company.project.presentation
</package>
</packages>
<violations>
<violation>
com.company.project.integration
</violation>
</violations>
</rule>

</rules>

</architecture>

    Thats it. You have a simple architecture-rules.xml.

    The Unit Test

    Just extend and run your tests.

    public class SimpleArchitectureTest
extends AbstractArchitectureRulesConfigurationTest {

public String getConfigurationFileName() {
return "architecture-rules.xml";
}

public void testArchitecture() {
assertTrue(doTests());
}
}

    More Features

    In Architecture Rules 201, we’ll show you how to check for cycles (cyclic dependencies), write more action-packed rules, and describe how to handle source paths that can’t be found. We can also take a gander at the various Exceptions that can be thrown when rules are broken.

    Go Get It

    The next thing to do, is to go get it and try it out. Download, svn checkout, or put it in your pom.xml. Just add this repository:

    <repository>
<id>architect-rules-repo</id>
<name>
architecture-rules hosted by code.google.com
</name>
<layout>default</layout>
<url>

http://architecturerules.googlecode.com/svn/maven2/

</url>
<releases>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<checksumPolicy>ignore</checksumPolicy>
</snapshots>
</repository>

    And this dependency:

    <dependency>
<groupId>com.seventytwomiles</groupId>
<artifactId>architecture-rules</artifactId>
<version>2.0.3</version>
</dependency>

    architecture rules xml architecture rules java

     

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel