Analysis - Practices

In software development, analysis is the process of studying and defining the problem to be resolved. (We all define the problem before we start solving it, right? Right? Oh, please, somebody say “Right!” We can’t all be that screwed up, can we?) It involves discovering the requirements that the system must perform, the underlying assumptions with which it must fit, and the criteria by which it will be judged a success or failure.

Object-Oriented Analysis (OOA), then, is the process of defining the problem in terms of objects: real-world objects with which the system must interact, and candidate software objects used to explore various solution alternatives. The natural fit of programming objects to real-world objects has a big impact here: you can define all of your real-world objects in terms of their classes, attributes, and operations.

Design

If analysis means defining the problem, then design is the process of defining the solution. It involves defining the ways in which the system satisfies each of the requirements identified during analysis.

Object-Oriented Design (OOD), then, is the process of defining the components, interfaces, objects, classes, attributes, and operations that will satisfy the requirements. You typically start with the candidate objects defined during analysis, but add much more rigor to their definitions. Then you add or change objects as needed to refine a solution. In large systems, design usually occurs at two scales: architectural design, defining the components from which the system is composed; and component design, defining the classes and interfaces within a component.

Models

Did you ever build a model ship? When I was young, my mom and I built a model of the famous clipper ship Cutty Sark.³ I’ve always been fascinated by the tall ships of old; but I really learned about how they work when we built that model. All of the strange nautical terminology from the old pirate movies—forecastle, capstan, main mast, and especially belaying pins (“You mean they’re not just there so somebody can pull one out and swing it as a club?”)—gained concrete meaning when I assembled them and saw them in the context of the entire system.

Well, that’s a central goal of using UML in OOAD: to let you study and understand a system via a model of that system. Like aerodynamic engineers, construction architects, and others in the physical engineering world, you’ll build models of systems yet to be built, not just models of existing systems. Your models will let you explore design alternatives and test your understanding of the system at a much faster rate and much lower cost than the rate and cost associated with actually building the system.

“But wait a minute!” the skeptic in the crowd shouts. “I can see the Cutty Sark, if I travel to London. And I can see the model Cutty Sark, if I visit your home. I can look at the two, and see how the model relates to the real thing. But I can’t ‘look at’ software, except at its user interface. So your model looks like the UI? Isn’t that just a prototype?” That’s the problem with the usual engineering model analogy as applied to software models: there’s no direct physical correspondence between the model and the final product. A better analogy is to models in less tangible scientific disciplines. Quantum physics is a good example of a field in which models help you to understand things you can’t see: no one can see quarks or leptons or hadrons or any of the many subatomic particles; and attributes like charm and strangeness have only metaphorical meaning. The models of quantum physics aren’t literally true, yet they’re very useful in understanding physical phenomena. Software models are like that: useful metaphors and abstractions to help you think about a problem and a solution, not literal depictions of the code itself.

In the case of OOAD with UML, your models consist primarily of diagrams: static diagrams that depict the structure of the system, and dynamic diagrams that depict the behavior of the system. With the dynamic diagrams, you can trace through the behavior and analyze how various scenarios play out. With the static diagrams, you can ensure that each component or class has access to the interfaces and information that it needs to carry out its responsibilities. And it’s very easy to make changes in these models: adding or moving or deleting a line takes moments; and reviewing the change in a diagram takes minutes. Contrast that with actually building the code: hours to implement the change, hours more to test and review it.

But remember The Model Rule:

To use UML effectively, you should never be simply drawing pretty pictures; you should always be editing an underlying model, using the pretty pictures as your user interface.

Your core artifact of the OOAD process is the model. In fact, you will likely have multiple models:

• Analysis Model. This is a model of the existing system, the end user’s requirements, and a high-level understanding of a possible solution to those requirements.

• Architecture Model. This is an evolving model of the structure of the solution to the requirements defined in the Analysis Model. Its primary focus is on the architecture: the components, interfaces, and structure of the solution; the deployment of that structure across nodes; and the trade-offs and decisions that led up to that structure.

• Component (Design) Models. This is a number of models (roughly, one per component) that depict the internal structure of the pieces of the Architecture Model. Each Component Model focuses on the detailed class structure of its component, and allows the design team to precisely specify the attributes, operations, dependencies, and behaviors of its classes.

Depending on your development process, you may have even more models: a Business Model, a Domain Model, possibly others. The major benefit of models is that you can make model changes far earlier in the development cycle than you can make code changes, and far easier. And because you can make changes early, you can make your mistakes early. And that’s a good thing, because early detection and correction is cheap detection and correction. Modeling will let you catch your most costly bugs early; and early detection and correction can save you a factor of 50 to 200 on the cost and schedule of a bug fix.⁴

---

Equal Time for an Extreme Perspective

Although software engineering literature is rife with research that demonstrates that the cost to fix a defect rises catastrophically over time, those in the Extreme Programming camp disagree. They argue that all such research is dated, and that modern development tools and techniques allow a maximum limit to the cost of change.⁵ They see not an exponential growth, but an asymptotic approach, as shown in Figure 1-1.

Figure 1-1.  Cost to correct defects over time 

To which theory I can only reply, “So?”

• First, their theory is a prediction, not a guarantee: if you apply the techniques they advocate and if you do everything correctly and if you are working in the right sort of environment on the right sort of project, then the lessons of 30 years of software engineering will allow you to attain the asymptotic curve. Good for you, if you can do that; but the exponential curve is the default behavior. (Furthermore, I would argue that modeling is a useful tool for attaining that asymptotic curve.)

• Second, look at those curves. Do you want to argue over which curve is “right” at the 8-weeks mark? Or would you rather just fix the problem at the 1-week mark? (Beck argues that there is benefit in waiting for the latest possible time, so that you have the maximum information when you make the fix and also so that you don’t waste time fixing problems that never really arise; but his actual example shows the benefits of making a change as soon as you are aware of it. These concerns aren’t incompatible.)

---

Modeling has another benefit, one I call The Outline Effect. Back in high school, I never needed study habits: I liked to read, and I liked to learn, so school came easy to me at my small rural high school. Then I went to a Big Ten university, and reality came crashing in on me. I didn’t understand that learning at that level was supposed to be work, a job you tackled in a systematic fashion with specific goals and strategies. My “strategy” was sort of like code-and-fix: just tackle whatever came along, and hope it all worked out. It didn’t, and I didn’t understand why. Every night, I sat in my room, reading the textbooks  . . until something distracted me, which happened far too often. Meanwhile, every night, a friend sat in his room across the hall, outlining the textbooks. And surprise—he had a much better GPA than I did.

It took me years to appreciate my friend’s study skills. The process of outlining the text forced him to focus: he had a concrete goal in mind, and wouldn’t allow distractions until he finished it. Furthermore, the outlining involved more of his brain: in order to produce an outline of the textbook, he first had to comprehend the textbook; and then to actually write the outline in his own words, he had to involve yet more areas of his brain, as he had to formulate what he wanted to write. Heck, he even had to involve his tactile and motor areas of his brain in order to write the words. He had a much more fully involved brain, and thus he much more fully understood the material.

This is a benefit you can gain from modeling: by listening and talking and reading and by then translating what you learn into a model, you learn it more thoroughly. This is even more important in system design than in studying from a textbook: in a textbook, you expect that the text will be more or less consistent, and that any seeming inconsistency is most likely a sign of something you misunderstood; but in requirements gathering, contradiction and inconsistency are inevitable parts of the process. By modeling the requirements, you may highlight the inconsistencies, particularly when you gather details from many different parts of a specification and put them together in the same diagram.

And there’s one more modeling benefit, one I believe I may have mentioned earlier: communication. It’s easier to communicate with models than with text, or even with code; and you can communicate with a wider audience with models than with other forms of expression. Once you’ve created a diagram “in your own words,” I can more easily comprehend how you comprehend things by comparing your diagram with what I comprehend.

>>> More Practices Articles          >>> More By Apress Publishing

blog comments powered by Disqus