Logical Design

Dan spent much of the weekend preparing for the Monday morning meeting. When the team members began arriving, they found a new stack of papers at their places, along with new binders. Fresh coffee and doughnuts were already in place on the credenza.

"I know somebody who was busy this weekend, and he wasn't catching fish," said Marilou as she sat down and looked over the papers.

"Yes, I put in some extra hours this weekend," said Dan as he filled his coffee cup and sat down. "I wanted to get us ready to move into the Logical Design step, and that meant doing some preliminary work on the objects and services."

"I came in Saturday afternoon to pick up something," said Marta as she handed Tim a doughnut. "Was that your car I saw in the parking lot?"

"Yes, but I wasn't here for RMS," replied Dan, quietly. "We had an executive management team meeting." Everyone looked up at the tone in Dan's voice, but he was busy moving some papers from his old binder to the new one and didn't see the questioning looks.

"The new binders," said Dan, "are for your MSF materials. I thought it might make more sense to keep them separate from the project materials. You'll eventually want to file the RMS folder away, but I hope you'll keep the MSF binder handy for other projects."

Everyone took a few moments to shift papers back and forth between the two binders. While they were doing that, Jane leaned over to Marilou and said in a low voice, "When we get done here, come by my office. Have I got some news for you!"

"What's up?" said Marilou. "It'd better not be more gossip about Jeff over in Legal."

"No, this is something else. Got an e-mail right before I came to the meeting."

"Everyone done?" asked Dan. "OK, open your MSF notebook, and let's take a brief look at the Logical Design step, which is our entire agenda for today." Everyone turned to the new Logical tab in their binder while Dan wrote Analysis and Rationalization on the whiteboard.

"Alright," he said, turning to the group. "We don't have a research step in Logical Design like we did in Conceptual Design. Can anyone tell me why?"

"Because we use the output of Conceptual Design as the input to Logical Design, so we don't need to do any research," said Tim, leaning back in his chair.

"Bravo, Tim," said Dan. "I'm glad to see you covered the material this weekend."

"Well, a few of us formed a study team," said Tim, smiling a little broader. "Always makes it easier when you study in teams."

Knowing that Tim and Bill were good friends, Dan wondered how much studying they had done between casts. However, he kept his thoughts to himself and continued, "Tim's right, everyone. We take the work we did Friday on the conceptual model and use it as the basis for our analysis step. The goal is to identify all the objects, services, attributes, and relationships, both explicit and implicit. Does everybody remember the definitions of those terms from our work last week? Then turn to the materials I prepared over the weekend, and let's get started."

The group worked hard for a little over an hour, thankful for Dan's advance effort on the logical model. When they stopped, Jane said, "That wasn't as bad as I thought it would be. Are we really finished?"

"Not yet, Jane." Dan moved to the whiteboard. "We've done a good job defining our objects and services, but there is one more step. We need to assign the services to layers. After we do that, we may want to redo some of the objects or services."

"I knew it was too easy," moaned Tim.

"Are these the 'user-business-data' layers that were in the material, Dan?" asked Marta. "I don't really see the purpose of them. Why split your application into pieces like that?"

"To deal with problems of flexibility, scalability, and reuse, like the ones we identified in RMS a few meetings ago," said Bill before Dan could answer. He walked to the board, picked up a marker, and asked Dan, "May I?"

Somewhat surprised, Dan nevertheless stepped back. "Absolutely, Chief. Go for it."

Bill spent about 10 minutes explaining N-tier development, including a brief explanation of packaging objects and services into components. "So you see, N-tier has so many advantages that we have decided as a company to write all our applications this way, even stand-alone ones."

"You mean that even if an application is going to run on only one machine with its own local database, you still write it using multi-layer principles?" asked Marta.

"Almost always," said Bill. "It gives you so much more flexibility. For example, you write a simple application for a single user that uses a VB front end against a local Access database. The specs clearly say that the app is never going to be multi-user and the data set is never going to grow beyond a certain size. After you deliver it, though, other users see it and want their own copy, or they want access to the same data. Before you know it, you've got 10 or 20 users, and the data set has grown way too big for Access. If you write it properly using multi-layer, it's a fairly simple thing to change the data services so that they point to SQL Server.

"One of the best features, though, is that you can design different front ends that hit the same business and data services. For example, you can have both a Win32 client and a Web-based client working with a single set of business services. The Web-based client is especially appealing because it's easy to deploy. You put the necessary pieces on your Web server, and the first time a user accesses the page, the necessary components are downloaded to their machine and registered automatically. No more walking from machine to machine to install software 800 times, or even messing with automatic software installers. The time savings can be phenomenal in an organization as large and dispersed as ours."

"Wow," thought Dan, "The Chief has been doing some big-time reading." Out loud he said, "Bill, it sounds to me as if you have made a real commitment to MSF."

"Not necessarily to MSF, Dan," said Bill with a tight smile. "I'm still in wait-and-see mode on that. But I started studying multi-layer and components about a year ago when I ran across an old COBOL buddy and asked him what he was doing. He told me he was doing multi-layer applications using Microsoft technologies, and all I could do was grunt and say something inane like 'That's nice.' I realized the development world was passing me by—and not only me, but also all the folks under me. I decided it was time to learn some new tricks so that I could teach them to the rest of the crew. Turns out many of them were way ahead of me and just waiting for me to catch on. I talked with them about doing multi-layer on RMS back during the kick-off, and they convinced me that it was time to make the switch. We've been doing a few smaller things in multi-layer over the last six months, but this is the first major application we've done this way. So, Dan, I would say I am absolutely committed to multi-layer development and to the Microsoft methodology for doing it. As for MSF, this old sea dog is still trying to decide if it's a wonderful new bone or simply bilge."

Everyone laughed, including Dan. "Well, Chief, you'll never be accused of hiding your feelings. That's fine; I think you'll come around before we're through. Let me say for now, though, that you just gave an excellent overview of multi-layer development. Thanks."

Jane nodded as Bill went back to his chair. "He's right, Bill. Even I understand it. Maybe you should have been a teacher."

"Nah," said Bill, smiling. "They don't let you go fishing on Fridays."

"All right, everyone, Bill has pointed the way. Let's take our earlier work and finish for today by putting things into layers." The team worked for another 30 minutes, moving objects and services into user, business, and data layers. As Dan had suspected, they had to change some items slightly, and a few items had to be split into two new objects for different layers.

Finally, Dan said, "I think that's got it. Now, let's verify our work by doing some walk-throughs. Start at the user layer and see if we can carry out all the use cases using the objects and services we've designed." After the team had walked through all the use cases, Dan sat back. "Good work, all. I think this is a good working version. It may change some as we get into Physical Design, but for now, we're done."

He stood up. "I'll get these drawn up nicely this afternoon and e-mail them to you by tomorrow morning. Bill and the other developers are meeting this afternoon with the EA team, and we'll begin work on the Physical Design then. The rest of you need to be prepared on Wednesday with draft versions of your parts of the Functional Spec, Project Plan, and a tentative schedule. We'll send you a development schedule to use after we meet this afternoon. Any questions? No? Then, Bill, I'll see you and Beth and Sam this afternoon at 2, and I'll see the rest of you on Wednesday morning."