 
Compiling the NapkinYou return from the coffee shop with your ideas sketched on a napkin. You need to describe a solution to your group or your boss. So you transcribe your ideas from the napkin to your whiteboard and drag all your colleagues into your cube to show them. No software tool will ever replace the conversations that happen around the whiteboard, but if you have to send your idea out of the office, it is generally frowned on to mail Polaroids or send an email with digital photos of your whiteboard. The whiteboard does not make it easy to document your ideas so you can refer to them later. You might not like it, but you have to locate a UML tool and create the model that describes your idea. Though a model is simply a collection of model elements and their relationships, these elements can be grouped to form diagrams. These diagrams are greater than the sum of the elements as they provide various views of your model. The different views can be used to tell a story about how the application is structured. The type of diagrams you use to visualize your model depends on your problem. As you are getting started, you might choose to create a Use Case Diagram. This is a good overview diagram that identifies the major components of your project. Though the Use Case Diagram can be made as complicated as needed, it really has only two major parts: the Actor and the Use Case. An Actor represents an entity that will interact with your system. An example of an entity might be a “Customer” or “Bank Teller” that interacts with your program. The actor could even be a third-party library or a piece of hardware. The main idea of the Use Case diagram is to show these actors can interact with your program. For example, a Bank Teller might “Deposit Money” or “Withdraw Money.” In this case, the Deposit Money” and “Withdraw Money” are Use Cases. No code is directly related to the Actor or Use Cases, but these interactions expose the need for certain components in your project. Thinking through the use cases is frequently skipped during planning and as any programmer knows, a use case analysis will have to happen eventually. Thinking through what your project requirements are saves implementing unnecessary features and forgetting others. Creating a Use Case diagram might well expose any overlooked points. The diagram can't keep you from adding features that are unnecessary, but it at least tells you that they are not needed. So, the first step is to perform a use case analysis and create Use Case diagrams. A tutorial guides you through the process of creating a Use Case diagram.Completion of the use case analysis and diagrams leads naturally to sketching out the components of your system. Whether in the mind, on a napkin, or with a UML tool, this step has never been skipped in the development of a successful system. The benefit of formally creating a Component diagram is that it can help you define the classes and interfaces that will make up your components. If you completed the Use Case diagram tutorial, you can see how important that analysis is. From the Use Case diagram at the conclusion of the tutorial, some of the necessary components become evident: a Customer component, an Account component, and a Database component. The interactions between components can be further defined with Collaboration and Sequence diagrams. These components represent the deliverable pieces of your system. These are the pieces that your boss, your customer, or both parties must sign off on as sufficient. Until the components are agreed on, the architect and programmers are shooting at a moving target. But after the components are set, fine-grain structural work can begin. This fine-grain design is started by creating the Class Diagram. Again, a ready-made tutorial will lead you through the details of creating a Class Diagram. If you went to the effort to creating Use Case and Component diagrams that were accurate, you might be tempted to just sit down and start coding. But remember the last time you did that and later had to re-create interfaces and superclasses because you did not see the necessary relationships when you started coding? As you create your Class diagram, you are forced to make all the pieces fit together, reflecting on where you need interfaces, superclasses, and even entire design patterns. So, you see, the benefit to these diagrams is that they expose structures of inheritance before you write several classes and see that you are writing the same methods repeatedly. Using the NetBeans UML tool adds another great dimension to the Class Diagram, namely design patterns. If you know that a certain component of your system will utilize a design pattern or set of patterns, simply dragging and dropping the pattern onto the canvas creates the basic component for you. Better yet, the tool creates it correctly. Forget about trying to remember how the design pattern is actually structured. The NetBeans UML add-on pack provides the Gang of Four (GoF) and Enterprise Java Beans (EJB) design patterns ready for use. If you use a custom design pattern often, you can save it for future use. The best news is that none of this work will be wasted. If you are using the NetBeans UML add-on pack, a Class diagram can be turned into Java source code with the click of a button. You can even set the options for how the code is to be generated: headers, comments, variable placement, and other formatting. These settings would even include adding copyright information to all the generated files. The code generation alone should make this step worth doing during your development cycle. Therefore, it is worth your time to create the model first and let the tool generate all the basic code. Everyone diagrams in one form or another. The difference is that those who diagram by using a UML tool have something to show for their planning effort when the diagrams are completed. Napkins have a tendency to be used to clean up spilled drinks and thrown away. Every project that is well thought out will have some form of Use Case diagrams, Component diagrams, and Class diagrams that can live long after “imagineering” at the coffee shop has ended. What Were They Thinking?UML is simply a modeling language and is independent of any coding language. Therefore, just as UML can be translated into a coding language, so can a coding language be translated into UML. This process is known as “reverse engineering.” There are numerous uses for this process, but the most common is to simply get a view of how code is structured: What are the objects and how are they related? Seeing diagrams of the code can expose design patterns and other complexities that might not be obvious while reading the code. For the “how-to” tutorial using the NetBeans UML tool, see Reverse Engineering Java Applications or the Flash Reverse Engineering Demo. Though this article is not meant to be a tutorial, if you are using NetBeans to do your reverse engineering, a couple of steps are worth noting. You start with a free formed Java code base. The first step in reverse-engineering this code base is to create a NetBeans “Java Project with Existing Sources.” Wizards in NetBeans can help you with this process. After the project is created, a menu item is added to the project to reverse-engineer it. Even with large projects, this process only takes a few moments. When complete, a UML Project appears in the project tree. This project can now be manipulated at will. Diagrams can be created from the generated model elements. If alterations need to be made to the diagrams, simply make the alterations and regenerate the code (called “forward engineering”). You can either replace the code from which the model came or store it somewhere else. Notice the power in these features. You can develop your code from the model itself. This flexibility enables you to retain all the visual and reporting abilities of the model while also being able to compile and run your code. It really is the best of both worlds. If you like typing your code instead of creating it from diagrams, you can do exactly that. When your manager asks for a code review, simply reverse-engineer your code to update your model and take the diagrams into the meeting. Though reverse engineering is a tremendously useful tool to help you understand legacy code, it does not provide answers to all the questions. For instance, use cases cannot be drawn from a model that has been created by reverse engineering. You would not expect this outcome, as the code contains a different level of information than that required by the use cases. Other diagrams that do not make sense to create from reverse engineered model are Component, Activity, Collaboration, State, and Deployment. But, because the class elements and relationships are all known, any of these diagrams can be quickly created and you can then deduce the answers to the questions that naturally follow: What are the use cases? What is the deployment structure? What are the major components? You only need to supply the missing information pertinent to that diagram to have a fully developed model. SummaryUML is a language. Even though great tools exist for working in UML, it is still a language. If you do not understand the structures of the language, the design palettes in the tools can only frustrate you. To make the language “unified,” UML has encompassed a great deal of functionality. This bulk can make the UML tools cumbersome and hard to use. Sun Microsystems offers a class to learn UML in the context of object-oriented analysis and design. Using your understanding of the context of the different elements in UML, your models can take on a high level of practicality and efficiency. If you are creating models by using the wrong elements, your models will not translate into code. Whether you are an architect or a programmer, modeling is a necessary step in any project that is more complicated than HelloWorld. Some modeling languages, for example, are tuned for things like database design, but if you only have time to learn one modeling language, UML has become the industry-standard for modeling. The UML tools, such as the NetBeans UML add-on pack, have evolved so far that modeling is no longer a waste of cycles or simply an academic exercise that is tossed after the programming starts. The tools can and do actually help you get your programming done, giving you a chance to start the cycle again at the coffee shop. This article was last update June 11,
| Learning TrailsDocs for PacksAdditional ResourcesFAQs | |||||||||||||||||||||||||||||||||
|