Better Software - June 2008 - (Page 26)

lationship notation, as shown in figure 6, or as a UML domain model, as shown in figure 7, depending on the skills present on your team. All these models provide us with critical views for our initial architecture and, as everything else on an agile project, they can be modified if necessary to adapt to changes discovered along the project. The advantage of doing this initial modeling is that it provides a starting point from which to work, reducing the chance of major refactoring later in the project. A small investment in up-front thinking helps scale agile techniques for the complex situations in which many project teams find themselves. We can now start our first iteration and work on the “Place a Bid” and “Bill Buyer” use cases. Because some of the team members and stakeholders are remote, the product owner will start detailing the use cases by modeling a bit ahead of the team [7]. Figure 8 shows the level of detail to which the product owner would likely go, just enough so the developers understand the gist of the requirement and can then ask him detailed questions during the iteration. The more detailed requirement specification would be captured in the form of customer tests as part of our TDD activities. Remember, with AMDD you explore high-level concepts and with TDD you specify the details. Let’s focus on implementing “Place a Bid,” so we’ll need to concern ourselves only with that part of the model for now. Figure 9 shows the new Bid object as well as its relationships to existing objects. The Bid class contains the current bid, the bid increment, the new resulting bid, and the currency used along with a reference to the product that was purchased and the employee who purchased it. While creating the bid, the price attribute of the Item class would be updated to store the new bid amount. We can use forward-engineering automation to generate an updated physical data model as shown in figure 10, and, comparing it to the original one, generate an SQL script to update the database, as shown in figure 11. The initial reaction that many agilists have to the model in figure 10 is that we’ve over-engineered the system, particularly when you consider the detail sur26 BETTER SOFTWARE JUNE 2008 Figure 5: Auction deployment diagram Figure 6: Initial data model rounding phone numbers and addresses. Au contraire, mon ami! Remember, our system takes advantage of the existing HR and Inventory databases, so the simplest design is to leverage the existing assets instead of building a silo system from scratch. www.StickyMinds.com Now that we have our data stabilized, let’s have a look at the other layers. Displaying the items only takes a simple SDO call to retrieve the items from the database and display them in a JSF page. This is something that our IDE JSF wizard will generate for us, so we http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - June 2008

Better Software - June 2008 Contents Mark Your Calendar Contributors Technically Speaking eLightenment Code Craft Test Connection Management Chronicles Agile Model-Driven Development The Myth of Risk Management Stop the Insanity! Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.