SEARCH
search sponsored by
Atomz.com
INSIDE
Current Issue
Columns
Offline
Archives
TRACKS
Web Authors
Designers
Developers
Strategists
GUIDES
Style Sheets
Web Browsers
Web Tools
Ranking System
RESOURCES
FirmFinder
Newsletters
ABOUT
WebReview.com
Write for Us
Advertising
Staff
Contact
NETWORK
WebReview.com
WebTechniques.com
Web2001Show.com
InternetandMobile.com
![]()
|
![]() |
![]() |
May 18, 2001 > Developers
Planning Your Web Site With UML (Part II)
By Steve Franklin
Rank 3
The Design Phase
The design phase should overlap the analysis phase—you want to start sketching down your design ideas while you learn more about the system you're trying to build. There's no sense trying to analyze the system 100% and then move straight into design. The requirements will always evolve, and your design will sometimes drive your requirements (and vice versa). All developers do some sort of design—some just do the design straight in the code. This works, but becomes more difficult for managing complex code or distributing work across a development team. A bit of time spent modeling the system through design diagrams can pay large dividends in the end.
Design For the Future
Most software developers spend more time debugging and reworking existing code than they do writing code. This is particularly true when you consider your effort on multiple Web sites. Good designs from one site will carry over into another in the form of structure, organization and reusable code. However, if you rush your code together without any planning, the odds of benefiting from your code over the long term
decreases. A very cost-effective way to map out your site involves sketching out a few class diagrams. The following figure shows a number of key relationships that are typically used in class diagrams.
![Class Diagram]()
Figure 5: Class Diagram
Diagrams such as the one above can be created quite quickly. This diagram was used to sketch out my previous WML tutorial and took approximately 15 minutes. However, it was very useful to support the demo and saved me the rework that I would likely have had to do otherwise. There are a few key features shown in this diagram that I'd like to review (you first may want to review the discussion of the application in the WML tutorial).
- The Renderer class is an abstract class—shown by the italicized name. This means that it isn't to be used directly, and only subclassed versions should be instantiated (e.g. new Region()). All content-generating pages should subclass from this class to fit into our framework of deploying content to multiple types of browsers.
- The WeatherReport class is responsible for creating and owning any Region objects. This is shown through the black diamond that indicates a strong aggregate relationship, meaning that one object owns and creates the other.
- The plus ("+") symbols before method names indicate that the methods are public, and can be called from another object or function. The minus ("-") sign indicates that the variable or method is private, and can only be seen by member functions of the same object. Methods and variables are public in PHP, but we should always treat variables as private and avoid accessing them directly.
- The HTMLWeatherReport class depends on HTMLUtils. A dependency indicates that one instantiates and/or calls functions from the other.
- Each class in a class diagram should show all methods (and variables if any), their visibility (public, private or protected if appropriate), return types for functions, parameter arguments for functions, and data types for variables. Functions go first, and variables generally follow in a separate block if they exist.
If you aren't building an object-oriented system, you can still use class diagrams to model your system. Classes would simply represent various include and function files that you've written. Your diagram wouldn't show any inheritance, composition/aggregation or other OO relationships. But you could show which files call one another using dependency arrows.
Model Your Run-time System
Sometimes, you'll want to show how the bits and pieces fit together at run-time. The class diagram above shows all the relationships between classes, but doesn't show the order in which calls are made or how results from one function may determine which call is made next. In order to show the more dynamic aspects of the system, UML provides a number of different types of diagrams. Scenario diagrams are particularly useful when you're designing your Web site. Scenario diagrams come in two flavors: collaboration and sequence diagrams. You don't generally model all of the interactions of your system. Typically, you employ scenario diagrams to model complex parts of your system, or to sort out a general pattern for your code. For instance, you might want to demonstrate how the authentication code fits into a given page, or show how a utility framework can be used by pages to maintain a common look-and-feel. The two types of scenario diagrams are shown in the following section.
![Collaboration Diagram]()
Figure 6: Collaboration Diagram
The collaboration diagram above shows the general design for getting a weather report from the Web site. The actual code for this system (excluding the authentication mechanism) can be found in the WML tutorial. Some of the insignificant methods are missing from this diagram, because I'm only interested in modeling the key steps in the process. You can follow the methods from "1" through to "1.3.3.4". Some teams number their diagrams 1, 2, 3, 4, ..., but it's generally better to show the depth in the call stack by showing 1, 1.1, 1.2, 2, 2.1, and so on. This numbering scheme shows the transition of control more clearly. For instance, this diagram shows that the report() method calls a number of functions in WMLUtil and a Region object. The buildHeader(...) function in WMLUtil is called before we start to report on the region through a number of query and content-generation functions. We finally call buildFooter(...) in the WMLUtil module before returning to the report() method, and back to getPage(). You can add more detail to your collaboration diagrams regarding returned data, constraints, and conditions.
![Sequence Diagram]()
Figure 7: Sequence Diagram
A sequence diagram is very similar to collaboration diagrams in the information that it conveys. In fact, many UML modeling tools can generate sequence diagrams from collaboration diagrams and vice versa. The main difference with a sequence diagram is that sequences of events are easier to view on the diagram. Furthermore, detailed information regarding lifetimes and timings can be added to the diagram (such as delays, concurrent threads, and construction or deletion of objects.)
When deciding whether to use sequence or collaboration diagrams, I have a few criteria that help me to decide which format is more appropriate:
- Use sequence diagrams if you're trying to show timing- or thread-specific issues in the code.
- Use collaboration diagrams if you're trying to show patterns of interactions between objects.
- Use sequence diagrams when you want to show the interactions across several or more objects.
- Use collaboration diagrams when you want to show lots of messages/interactions between a small number of objects.
Plan for Deployment
As mentioned in the tool choice section of this article, most Web sites don't have a complex architecture. However, deployment diagrams can still be of interest to you on two levels: architecture and file organization. For file organization, I prefer to work with the class modeling tools as discussed in the screen layout section. In this section, I'll briefly include a component diagram for your reference, but you may not require it depending on your site's needs and complexity. The following example obviously has more machines (nodes) than our simple example, because our demonstration app could comfortably fit on a single server unless scalability for a large audience was required.
![Component Diagram]()
Figure 8: Component Diagram
Good Design Principles
UML is just a tool. Used properly, it can make it easier to build better sites. But good design principles are the key to a good site and no notation will teach you good design habits by itself. There are a number of books out there that can help you, but I'll try to cover a few common issues.
Write Cohesive and Decoupled Code
This phrase is used repeatedly to describe good object-oriented principles. A cohesive class contains behavior and information that's closely related in purpose and domain. This means that you wouldn't jumble a bunch of UI code in with math algorithms, and you would try to bundle closely related user information into a UserAccount class. Cohesive design is important for a number of reasons. It helps to reduce dependencies across classes, creates a more intuitive and understandable design, simplifies description of the design to other developers, and reduces the number of classes that a developer typically has to work with at any one time. For instance, if you have to make changes to the authentication mechanism in your site, it would be nice to change one class in one file, rather than change several.
A decoupled design minimizes the number of interactions across classes or files. Not only is a decoupled design easier to understand and convey to others on your team, but it's also easier to maintain. Consider the following example:
![Sample Design 1]()
Figure 9: Design Example #1
Without knowing more about the purpose of each class above, it's not feasible to measure the cohesiveness of any of the classes. However, the relationships would indicate that the design is nicely decoupled. The interactions across classes are minimized, making it easier to understand behavior. More importantly, changes to any class impacts a minimal number of other classes (for example, changes to D would only impact class B directly). Furthermore, to access the functionality of class D, a developer may not need to know anything about classes E, F, or G. Now, look at the following example for contrast.
![Sample Design 2]()
Figure 10: Design Example #2
This design example is obviously quite tightly coupled. Changes to class D1 would require extensive tests to other classes to see how they have been impacted. Furthermore, if you want to perform some functionality, you can't just assume that it's all hidden behind class D1, and may have to explore C1, E1, and/or F1 as well.
Avoiding an overly complex design takes some practice, but the following tips may help:
- Aim for cohesive classes. Don't distribute related functionality across files or classes.
- Use effective and clear naming. If others don't know what a class or function does, or what a variable means, then the design won't be intuitive regardless of the structure. Acronyms or abbreviations can hurt the readability of your design.
- Don't be afraid to refactor your code. Sometimes moving functionality between a few files/classes can greatly simplify your code. Creating or deleting files should always be considered periodically (see the book Refactoring: Improving the Design of Existing Code for a good discussion on the subject)
- Keep classes compact. Code bloat is a sign that a class is losing cohesiveness. Huge classes, modules, or files typically lack a clear purpose.
- Do a design review with someone else. Others may have new ideas, or may identify things that were clear to you yet unclear to others.
- Don't allow performance to weigh too heavily in the early design phase. A clean and well-factored design will be easier to optimize and tweak than an awkward design that was optimizing yesterday's problems. I'm not suggesting that you throw performance considerations to the wind, but you certainly should leave detailed optimization until later in the project.
Find Tools that Support the Design Process
There are a few tools that you may wish to consider if you are using UML to support your site's software lifecycle. A detailed review of any one of these is beyond the scope of this article, but you can mail me with any specific questions you might have.
- Pen and Paper - These diagrams aren't particularly complex. A few quick sketches in a common notation is a lot more useful than diagrams that only mean something to you. Maintaining class interfaces and scenario diagrams can tend to be a bit cumbersome, but you can certainly sketch out the high-level picture without a fancy tool.
- Microsoft Visio - Visio Professional 2000 now comes with UML support integrated into the product. This tool is a fair deal when you consider all of the other uses you may find for the drawing tool. If you use a version earlier than 2000, you can find a UML stencil and template courtesy of one of the Navision employees.
- Rational Rose - this is my personal favorite, but it's a pricey tool for most small Web projects. Tools like Rational Rose make it very easy to grow and maintain your design, generate reports from the model, and share the modeling effort with others in a collaborative and parallel fashion.
Other options that I've used very little or not at all, but are considered by some to be excellent options, include:
- MagicDraw - a low-cost Java-based UML modeling tool.
- Together - ties in very well with C/C++ and Java, and supports UML modeling. Look for Together WhiteBoard (free) to get started on some class diagrams.
- Objecteering UML - offers a free personal UML product.
- System Architect - a popular high-end UML modeling tool with round-trip engineering support.
Summary
This article has introduced some of the basic concepts associated with UML. I hope I've been able to show enough about the notation and its application to pique your interest. A small amount of formal software engineering can add a tremendous amount of value and efficiency to your next Web site, and ensure that some of your work carries on well into the future through a maintainable site and reuse on future projects. From here, the best way to learn the notation is to review the references in the sidebar or pick up a good book and start using the tools. It's even easier if you can find someone who has done some UML and OO analysis and design to provide you with some feedback.
Steve has been working with Internet and related technologies for over a decade. His primary "off-hours" hobby can be found at lookoff.com, a repository for Internet and researching information and resources.
|
![]() |
![]() |
![]() |
|