Improving Your Productivity


Developing software is a hard job, made harder because the product has to be easy to use, loaded with additional functionality, and usable even when distributed over complex Internet environments. Software must continually be better, quicker, and faster than ever before. To help you achieve these goals, software development has gone object-oriented. Instead of writing functions, you create little software objects that send messages to other software objects. Unlike functions, these software objects allow you to hide the details of internal operations in tidy programming objects. Now, to go along with this new direction in software development, you encounter a whole bunch of buzzwords. You can use Table 2-2 to translate the slew of new buzzwords when UML pros want to talk shop (or vendors want to sell you methods and tools for UML modeling).

Table 2-2: L Buzzwords and Their Interpretations

Expert’s Word

What They Really Mean

Example

Component

A real-world object or unit of software code that is so self- contained that it can be swapped out and replaced by another object, without the user knowing the difference.

You can replace one DVD player in your entertainment system with another DVD player of equal or better capability; you can replace one module of code with another that works better

Component-based development

Building your system out of modular/replaceable units of code.

Develop your system using Enterprise Java Beans, .Net, or CORBA components.

Interface

A contract that specifies what the object must do(but not how to do it).

A DVD player must accept audio and video signals through specific connectors (for example, RCA-type).

Pattern

Description of how developers solve a frequently occurring problem.

Use the adapter pattern to adapt an existing class interface to a new interface you can handle.

Framework

A large-scale pattern that dictates the architecture of your application

You could implement a hotel reservation application using an event-driven framework using GUI screens, or an auction framework over the Internet.

UML Modeling tool

Software that allows you to create UML diagrams— and generate code based on the diagrams.

Chapter 23 lists some vendors of Modeling tools.

Life cycle

A sequence of generic steps from beginning to end that everyone on the team has to follow for developing a system or software.

For many software projects, the life cycle (Waterfall, for instance) starts with the analysis step, followed by the design step; all steps are sequential.

Methodology

A prescribed detailed approach to the task of developing a system or software.

These are the steps prescribed by industry experts for the development of systems and software. These steps often involve the use of a mod-eling language like UML, RUP, OMT, Booch, and Agile.

Building component-based applications

You’ve seen manufacturers assemble hardware from groups of components. Each part of a device (for example, a disk drive) is created first. Then the parts sit in bins, waiting to be picked at the right time in the assembly process. One instance of a part like a power supply or disk drive is exactly like another; each part is a replaceable unit. The assembly-line approach to building hardware is more productive than building things by hand; object-oriented programming applies the same principle to software development.

Building software by assembling prefab pieces is faster and more productive than creating each program line by line from scratch. This is what the experts call component-based development. You can think of components as units of code that can be plugged into the software (as if into a circuit board) to form an application.

 Remember   To develop applications from groups of components, you need to perform the following tasks:

  • Create components: Write units of software as groups of cooperating objects, which you can reuse from application to application.

  • Separate what a component can do from how the component does it: You must declare interfaces to your components. Each interface specifies the name of the operation and any parameters needed by that operation. When one component invokes the interface of another component, it should not have to know anything about how the operation is performed.

    For example, if we build a streaming-video component in software that provides a run interface, you should be able to simply ask any of our streaming-video components to run. You shouldn’t have to know anything about the internal type, structure, or format of the video to run it. Thanks to this separation of concerns (external interface from internal code), you can replace our component with another component that provides the same run interface and your assembled application will continue to work. It’s like replacing one power supply in a disk drive with another.

  • Provide a common standard for communication among components: To make your components replaceable, you have to standardize on the exact way one component talks to another. The Object Management Group’s CORBA and Microsoft’s COM are two established communication standards that offer this sort of consistency.

  • Allow your components to exist in a standard environment: Your components must be able to create instances of other components, find out which interfaces other components provide, and register themselves so other components can find them and invoke them. Enterprise Java Beans (EJB) is a good example of a component environment. EJB provides standard ways to create, register, find, interface with, and delete components.

 Tip   Use UML component diagrams to describe an assembly of parts for your application. Use class, composite structure, sequence, and communication diagrams to describe how the insides of your components work. (Class diagrams show the attributes and operations of each object making up your component. Composite structure diagrams show the internal parts that make up each component. Sequence diagrams show interaction among the components over time. Communication diagrams show complex internal interactions of the parts of a component.)

Utilizing patterns in your development

One way you can become more productive is by reusing solutions to common development problems. Why reinvent the wheel every time you have a design problem? During the 1990s, many developers got together and documented common solutions to common system and software problems. They called the resulting documents design patterns. Each pattern has a name, a description of the problem it solves, a standard solution, and the documented trade-offs you encounter if you apply the pattern.

For example, the proxy design pattern allows you to have one object take the place of another. This pattern allows all objects to interact with each other across different computers. Your object on a client computer invokes a proxy object on the client computer; and that object is the one that contacts the real object on the server computer. Your original object knows nothing about how to contact the server object—and doesn’t have to (that’s what the proxy is for). This approach can make object development easier.

 Warning   Here the terminology gets confusing. Patterns describe a common way of making objects work together. Some experts use the word framework to describe larger-scale patterns used to create applications. Other experts use that same term—framework—to describe an existing group of objects that you customize for your own purposes. When the experts sort it out, we’re sure they’ll let us know.

 Tip   You can use UML collaborations and collaboration occurrences to model patterns and frameworks. For more information on diagramming collaborations and collaboration occurrences, see Chapter 15.

Using UML tools

UML is easy to draw; artistically challenged experts designed it that way. But, keeping track of many different kinds of diagrams—on many pieces of paper—is especially tedious when you have to make changes during development. Using UML to model and build today’s complex software systems requires something more than a white board, lots of paper, and pencils with big erasers.

What you need is a UML modeling tool, formerly known as a CASE (Computer-Aided Software Engineering) tool. A modeling tool aids the development of software by keeping track of all the software engineering symbols (such as those in UML), and it helps you do the following tasks:

  • Drawing UML diagrams: This can include class diagrams (see Chapter 7), use case diagrams (see Chapter 8), and sequence diagrams (see Chapter 12).

  • Drawing UML notation correctly: The tool draws a UML class as a box and a UML state as a rounded rectangle. You don’t have to fool with getting the icon to look right.

  • Organize the notation and the diagrams into packages: With large projects, as the number of classes increase you need help organizing your diagrams. Modeling tools help you organize by packages. (For more information on package organization see Chapter 7 and Chapter 19.)

  • Searching for specific elements in your diagrams: This is very helpful when you have a lot of diagrams with many classes, objects, associations, states, and activities.

  • Reverse engineering: Some of the tools read your object-oriented programming code and convert it into simple class diagrams. This saves you time when you’re modeling existing software.

  • Model reporting: You can disseminate information about your models to other developers by asking the tool to generate a report.

  • Generating code: The big payoff of a UML modeling tool is the fast creation of some, but not all, of the code you need for your software.

Over 120 different modeling tools support UML modeling. (Chapter 23 in this book describes ten such tools.) You can even get some of them free. Whatever the outlay, choose a UML tool that fits the kind of system you’re building and that makes you the most productive.

 Tip   Think carefully about the kind of system you’re building before you buy a UML modeling tool. Consider the following system categories:

  • Information systems: You want to build software applications that process information. Look for a tool that is well rounded in that it provides you with all the UML diagrams.

  • Real-time and embedded systems: You concern yourself with strict timing and sizing issues in these systems. Get a tool that is especially good at state diagrams (see Chapter 16), timing specifications, and real-time simulation of event handling (a special program that directly implements a state diagram).

  • Database systems: In this case, you design databases to handle transactions online or serve as data warehouses. Consider the tools that support conceptual, logical, and physical models, and that can generate the code to query and extract data from your chosen database-management system.

  • Web-based systems: Here you concern yourself with scripting languages and Web services; you have to generate XML data structures, create client-side code, and specify server-side operations. You need a tool that allows you to diagram all the different components in a Web-based application.

 Remember   The primary reason you buy a UML tool is to improve productivity. Look for a tool that gives you the automated support you need on the job. Don’t listen to vendor hype; look first at what the modeling tool can actually do for you. The best tools have capabilities like these:

  • Shell generation: The tool generates header files for your code according to a class diagram, but doesn’t generate any actual method code.

  • Code generation: Now we’re talking. These tools generate basic code for setting and getting the attributes of a class. They also generate simple constructor methods.

  • Language-development support: You find some tools support the whole application development process. These tools integrate requirements management, UML modeling, and an interactive visual development environment. A good tool that supports your language development parses your code in the UML model for correctness. You should be careful to choose a tool that fits your language needs and supports the development tools you use. These tools also reverse engineer code into simple UML models, helping you with integrating legacy code.

  • Database generation: These tools allow you to specify logical and physical data models as different class diagrams. The tool generates Data-Description Language (DDL) statements such as create table and create index. Make sure the UML tool generates the DDL you need for the relational database-management system (RDBMS) you use.

    Some UML tools don’t generate DDL directly. The tool vendor supplies you with an export facility. You export your UML class diagram into a more traditional entity-relationship modeling tool. That tool generates the DDL.

  • OCL support: The object-constraint language (OCL) provides you with a powerful way of expressing business rules beyond the UML diagrams. OCL allows you to declare pre- and postconditions for your operations. A precondition is a statement of truth before an operation can work properly. A postcondition is a statement of what is true after an operation executes successfully. If you use OCL heavily, look for tools that parse OCL and generate partial code from OCL.

  • Support for collaboration on large projects: Many UML tools place your diagrams in a file on your computer. If you work with others, then you have to send them copies of the file with your diagrams. On very large projects (with 50 or more developers), that approach leads to disaster—the files get changed, no one knows which file is the latest and greatest, and mistakes proliferate. When you work big projects, look for tools that store their models in an industrial-strength database instead of a file. Large projects also require lots of documentation. Look for a tool that generates reports in HTML, XML, and hard copy

Sorting out methodology madness

UML is just a notation. UML does not tell you when to use which diagram. The experts had plenty of time to create lots of suggestions about when, what, where, why, and how to use UML. They call this advice a methodology.

 Tip   Most experts use their own obscure terms to describe their specific methods. You may find their jargon very confusing—especially when different experts use the same word to mean different things, or different words to mean the same thing.

 Remember   Every method for developing systems and software starts with the following basic steps:

  1. Planning: Organize your project.

  2. Analysis: Find out what your application does or needs to do.

  3. Design: Specify how your application works.

  4. Implementation: Just build the application.

  5. Testing: You make sure the application works properly.

  6. Deployment: Launch the finished application onto servers and the users’ computers.

Any good engineer will tell you about the basic steps for developing a system. But you need to know which UML diagram to use during each step. You must have a sense of how to order the steps, and how long you should take to perform a step for your project (for example, some complex software requires a longer requirements-gathering period). That’s where the experts come in with their life cycles and their methodologies.

Riding multiple life cycles

A system or software development life cycle tells you what to do (process steps) and when to do it (the sequence of process steps). When the experts give you just a life cycle, they don’t tell you how to perform the actual steps.

Fortunately, life cycles come in recognizable types. Here are the ones you’re most likely to come across:

  • Waterfall: This life cycle is one of the oldest and one of the simplest. Each basic step (planning, analysis, design, and so on) follows the others in a strict sequence. First you perform your planning. When that is done, you gather your application requirements during analysis. Only after you have all the requirements can you move on to design. This life cycle is not very flexible.

  • Spiral: The Spiral was originally a way to make the Waterfall life cycle more flexible. Think of this cycle as a sequence of mini-Waterfalls. Your project progresses in smaller steps. At the end of each spiral (a whole sequence of risk assessment, analysis, design, and prototyping), the team assesses how well the project is doing. The next spiral then addresses these issues to build a larger prototype. Eventually the prototype becomes the full, delivered system.

  • Iterative Development: The Spiral is thorough, but developers needed a life cycle that didn’t take so long. When they recognized they could perform groups of steps in parallel iterations, they had the key to speeding up the process.

    First, high-level requirements are gathered. Then the project is broken up into small bit-size pieces of customer-oriented capabilities that meet those requirements. Small project teams work on each iteration at the same time to deliver each piece. (An iteration involves building, testing, and providing a small functional part of the overall program.) You get the project done faster because your team works on different parts of the project at the same time.

Adhering to multiple methodologies

A methodology tells you how to perform a sequence of steps to get the job—completing an application—done in the time available. When you read experts’ prescriptions for building an application you may get the impression they’re really saying, “Do it my way or else face disaster.”

 Warning  Don’t be confused by the lingo. What some experts call a methodology is just a life cycle. Look for a method that’s well enough thought out to tell you what to do, when to do it, how to do it, and how long to do it.

 Remember   No one follows the experts all the time. Every project is different and yours is no exception. Read what the experts have to say—and then create a customized methodology that fits your company culture, your type of project, your team dynamics, and your path to success.

If you want some useful starting points, you can find methodologies like the following by using your favorite search engine on the Web:

  • OMT, Booch, Objectory: In the old days (pre-1995), these were the leading object-oriented methodologies. Each method had its own notation. UML came along and replaced the different diagram symbols with one unified notation. But you can’t get a complex project done using just a notation—look deeper at the overall approach.

  • Rational Unified Methodology: During the mid-1990s, the Rational software tool company hired (or had access to) the methodologists of OMT, Booch, and Objectory fame. These folks (known to developers as the Three Amigos) came up with a unified method to go along with the unified notation. Rational called its new method RUP for the Rational Unified Process. (See www.rational.com.)

  • Catalysis: During the mid- to late 1990s, component-based development became fashionable. Desmond D’Souza and Alan Wills developed a methodology they called Catalysis that describes how to perform development using components. (See www.catalysis.org.)

  • Agile, eXtreme Programming / eXtreme Modeling: After the turn of the current century, a number of developers came together to address the continuing failure of methodologies. Older methodologies like RUP seemed bloated and overbearing, resulting in projects that generated lots of diagrams and documents but still failed. These developers wanted something more agile than RUP. The result—the Agile method—encouraged developers to tailor their methods to meet their specific needs. Agile modeling using UML is geared toward small development projects with tight deadlines, like building Web front ends. (For agile development see www.agilealliance.org. For eXtreme Programming see www.extremeprogramming.org.)

 Tip   Use risk as your guide. Each step of a methodology is intended to mitigate some risk you might face on a project. Every project is different because every project faces a different group of risks. Typical risks include lack of communication among developers, not enough money in the budget, not enough time on the schedule, and failing to meet user requirements. Review your project to identify the high-priority risks that could kill your development effort. Then you should find the process steps, methods, and UML diagrams to help you mitigate those risks.

 Remember   No matter what method you choose, successful projects happen because teams learn to work together. Don’t worry about the fancy words; get everyone on the team focused and excited by the project. You can use UML diagrams to communicate, exchange ideas, build consensus, and document for others what your project, application, system, or software is going through on its way to completion.




UML 2 for Dummies
UML 2 For Dummies
ISBN: 0764526146
EAN: 2147483647
Year: 2006
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net