I picked this book up several years ago while writing curriculum for a training class on OOAD and UML. My reason for seeking it was that I needed an alternative to several of the books that Rational published, including UML Distilled and The Unified Modeling Language User Guide. The later two texts just did not tie UML, process and practical examples together and Larman's book did.
What appealed to me about "Applying UML and Patterns", is that it combined both theory and practice in manifold ways. I’ve critiqued each of the following areas:
- Software Development Life Cycle
- UML
- Patterns
- Practical Case Study and Examples
Software Development Life Cycle - From project Inception through Elaboration, even one new to the Unified Process will know exactly where the sample project is within the software development life cycle. In addition, the book gives the reader both a good intro to the Agile UP and substantiates why UP driven projects have higher success rates than those using the waterfall process. It sites the MIT Sloan Management Review of Successful Projects (http://smr.mit.edu) to build the case.
UML and other Artifacts - The book does an outstanding job of giving solid examples of applying UML notation and creating Use Cases. From writing effective use cases, to creating and refining a domain object model, to applying several popular patterns, you'll be glued each chapter. The inside and back cover provide useful aides for quick reference to the UP, several of Larman's patterns and UML notation.
Patterns - I think the book's value in showing how patterns compliment the design process speaks for itself. Those introduced, such as Larman's "Information Expert", "Creator" and "Controller" are part of his GRASP series.
Practical Case Study and Examples - The book intertwines UML, UP and a realistic case project called the “NextGEN point of sale system” in a real, practical way. Often, I've loaned this book to colleagues and client managers, both for their edification and at times to persuade them on a finer point of RUP, Agile and UP based process. It has also proved to be a good reference by providing RUP objectives and UML artifacts at key points in the SDLC.
Overall, the book makes for good reading for developers and team leads alike. I recommend it as a baseline prior to choosing a UP based methodology and for those wanting to understand the big picture and how Use Case, UML, Patterns and UP can compliment on another.
It would be great to see a book as quality as this written using .Net specific tools, such as Visio UML and C#.
If you are interested, please see www.craiglarman.com for more details and sample chapter from the book.
In trying to standardize Application Error Handling, my group has come up with the following guidelines. Feel free to pick it apart and provide your comments back to me.
Each application should implement error handling in the following order :
1. Try-Catch - Use of Structured Exception Handling blocks
2. Use of Page Level Error Events
3. Application Wide Error Pages
4. Exceptions shall be logged
5. Using and Enabling Trace
Every effort should be made by the developer to provide structured exception handling blocks to circumvent un-handled exceptions. Therefore, Page Level and Application Wide error trapping should be used to augment SEH, but not circumvent it.
Structured Exception Handling Blocks:
The use of Try...Catch...Finally Statements will be used as a first attempt to trap and correct application errors. Try…Catch…Finally statements should be placed around related blocks of code at a granularity that facilitates catching and correcting errors with minimal impact to the end user. The following general form shall be used:
Try
[ tryStatements ]
[ Catch [ exception [ As type ] ]
[ catchStatements ] ]
[ Exit Try ]
...
[ Finally
[ finallyStatement ] ]
End Try
Page Level Error Events:
The Page object’s ErrorPage attribute shall be used display a specific page when an unhandled exception occurs on a Web form. The page-level setting supersedes the application-level settings in the Web.config file.
For example, the following HTML sets the ErrorPage attribute for a Web form:
Inherits="MCSDWebAppsVB.ErrorPages" errorPage="ErrDefault.aspx"%>When the exception occurs, the user is redirected to designated error page (i.e.ErrDefault.aspx). Because the error page is displayed through redirection, the context for the error is lost and Server.GetLastError returns nothing from the target error page. Therefore, Server.GetLastError shall be called in the Page_Error event and the result placed in a Session variable.
Application Wide Error Pages:
Application Wide Error Pages shall be used to provide user friendly responses for errors not caught in a structured event handling block. The customErrors section of the web.config file shall be set to specify a default error page to display, along with other required error pages for specific HTTP response codes that indicate errors.
For example:
o The customErrors mode attribute must equal On to view the error pages while debugging the application on your local machine.
o Setting the mode to RemoteOnly (the default) will display the designated error pages when the application is accessed from client computers, but not when the application is accessed locally.
Logging Exceptions:
Any exceptions that meet the following criteria should be logged:
o Those considered serious in that they could result in data loss or corruption
o Those that need to be monitored for application:
o Security
o Performance
o Functional Compliance
Using the System.Diagnostics namespace, exceptions shall be logged either to the Server “Application” or Log. The following approach, should be used:
Dim eventLog1 As New EventLog()
If Not eventLog1.SourceExists("") Then
eventLog1.CreateEventSource("", "< ApplicationName>")
End If
eventLog1.Source = "(")
eventLog1.WriteEntry("", ex.ToString(), _
EventLogEntryType.Error)
eventLog1 = Nothing
Using and Enabling Trace:
Tracing is an integral and useful part of application development within the .Net Framework while debugging, testing and even at times, in production. The following convention will ensure that it is used properly in each SDLC phase.
During Development:
It shall be the developer’s responsibility to use the Shared (static) methods of the Trace Class, which is part of System.Diagnostics namespace:
o Write - Writes to Listeners collection
o WriteLine - Same as Write except adds a CR to the end
o WriteIf - Writes conditionally
o WriteLineIf - Same as WriteIf except adds a CR to the end
o Assert - Writes to listeners collection if expression is False and displays a message box
o Fail - Same as Assert except condition automatically fails without testing
o Trace levels shall be used so that the granularity of trace information can be controlled.
o Output shall be sent to the appropriate Listeners collection. If the TextWriterTraceListener is used, care shall be taken to ensure the log file is created new each session, so that it does not become excessively large.
o The Trace class shall be used over the Debug class. Since the only difference between Trace and Debug is that Debug statements are not included in Release version, the Trace class shall be used over the Debug class. This will ensure tracing can be enabled in production.
During System Test and Production:
For security reasons, it shall be the developer’s and admin’s responsibility to ensure that tracing is disabled when an active debug session in not in process.
As tracing can be turned controlled for an entire Web application or for an individual page in the application and the following standard ASP.Net conventions should be used:
o In order to access the Trace.axd page, turn tracing on for an entire application in the application’s Web.config file, set the element’s Enabled attribute to True.
o Other Trace Attributes should be responsibly managed by the developer and team as illustrated:
o where pageOutput="false" writes to the Trace.axd log file, else it will to screen.
o requestLimit="N“ so the only the first N requests go to Trace.axd.
o localOnly="true“ should be used to ensure that trace is only viewed by the local IIS developer or admin, but not remotely by the user community.
o To configure trace level in web.config set the relevant via XML Key/Value Pairs. For example:
Single Page Tracing shall be used judiciously during production. If need, to turn tracing on for a single page, the DOCUMENT object’s Trace property can be set to True in the Visual Studio .NET Properties window. This sets the @ Page directive’s Trace attribute to True in the Web form’s HTML.
***