Better Software - June 2008 - (Page 25)

curs in parallel to the requirements envisioning—an architecture is never elaborated in a vacuum, but instead addresses both functional and non-functional requirements. Some agile teams like to use whiteboards for this kind of activity, but a complementary strategy is to use a modeling tool on a laptop combined with a projector, so everybody can follow the progress in real time. We have found that using a software-based modeling tool—in this case we’re using Rational Software Architect (RSA) for the visual models depicted in this article—instead of a whiteboard has some advantages. First, it avoids the overhead of having someone copy the whiteboard at the end of the session—this is particularly important if you don’t have dedicated whiteboard space or if for security reasons you can’t leave your architecture sketches up. Second, if you require technical documentation, perhaps due to regulatory compliance issues, you just print the diagram or generate a report from your working model. Third, the software-based tool facilitates the integration of remote participants into the design sessions, as you can share your model in real time over the network, which is critical for our developers in Bangalore. Identifying your technical strategy is an important part of architecture envisioning, and a simple but critical view is a technology diagram, as seen in figure 4, which provides an overview of the architecture layers and the technologies that will be used. Another diagram that we develop describes the deployment architecture we will be using. As on the majority of projects we have some technology constraints to which we need to adapt. Our main constraint is to reuse two existing Derby database schemas: one developed to store employee information (HR) and the other developed to manage the items’ stock availability (Inventory), as shown in the deployment architecture diagram in figure 5. For business applications, initial high-level domain modeling often is a valuable part of your envisioning activities because it identifies the major business entities and their relationships. Our approach consists of looking at the existing model (if there is one) to reuse any existing domain objects and update the model while implementing the use cases Figure 3: Initial use cases Figure 4: Auction technology diagram rather than doing too much up-front domain modeling. This reduces overall development cost and time to market, and improves data quality by avoiding the creation of yet another silo database. For this project there was no existing domain model, but we can start www.StickyMinds.com one by reverse engineering the HR and Inventory databases. These databases are the source of record for that data, so they’re where we need to start to keep the overall data quality within our organization as high as possible. You can either look at this model using Entity/ReJUNE 2008 BETTER SOFTWARE 25 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.