UML Overview <ul><li>Contents (12) </li></ul><ul><ul><li>The Communication Problem </li></ul></ul><ul><ul><li>UML As A Sol...
The Communication Problem <ul><li>Problem: System Engineers & Software Engineers often speak different languages.  </li></...
UML As A Solution Option <ul><li>The de-facto standard (not proprietary) tool for expressing reqs. & design information fo...
UML As A Solution Option <ul><li>UML is both broad and deep </li></ul><ul><li>Breadth: can be used to model systems in a w...
13 UML Diagrams
UML Diagram Usage
Class Diagram Example
Sequence Diagram Example
Activity Diagram Example
State Machine Diagram Example
The Language Of The Language
Implementation Options
Quotes For Reflection <ul><li>&quot;I hold great hopes for UML, which seems to offer a way to build products that integrat...
Upcoming SlideShare
Loading in …5
×

The Case For Uml

438 views

Published on

This is a pitch I gave to propose the adoption of UML as a standard way of communicating between system and software engineers.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
438
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Case For Uml

  1. 1. UML Overview <ul><li>Contents (12) </li></ul><ul><ul><li>The Communication Problem </li></ul></ul><ul><ul><li>UML As A Solution Option (2) </li></ul></ul><ul><ul><li>UML Building Blocks = Diagrams </li></ul></ul><ul><ul><li>Diagram Purpose/Usage </li></ul></ul><ul><ul><li>Diagram Examples (4) </li></ul></ul><ul><ul><li>Language Of The Language </li></ul></ul><ul><ul><li>Options </li></ul></ul><ul><ul><li>Quotes For Reflection </li></ul></ul>
  2. 2. The Communication Problem <ul><li>Problem: System Engineers & Software Engineers often speak different languages. </li></ul><ul><li>Cause: Engineers use ad-hoc text/graphical methods for communicating/recording requirements & design information. Lack of common understanding between disciplines can cause inefficient, ambiguous, error-laden product development (regardless of process). </li></ul><ul><li>Effect: Increased product development costs, missed delivery dates, lack of shared/common understanding. “The damn thing doesn’t Work!”, “It’s a design problem, you figure it out!  No, it’s a requirements problem, you figure it out!”. </li></ul>
  3. 3. UML As A Solution Option <ul><li>The de-facto standard (not proprietary) tool for expressing reqs. & design information for SW-intensive systems. </li></ul><ul><li>Hundreds of books available, taught in universities, many companies provide training, big range of tools available from cheap to expensive. </li></ul><ul><li>Can be used by both system engineers & software engineers. Shortens the gap between reqs. & design (SysML is a small leap from, and overlaps UML) </li></ul><ul><li>Requires a paradigm shift from functional system thinking to object orientation, but not a huge learning curve. A little steeper curve for systems engineers. </li></ul>
  4. 4. UML As A Solution Option <ul><li>UML is both broad and deep </li></ul><ul><li>Breadth: can be used to model systems in a wide variety of application domains (business IT, factory automation, air traffic control , embedded real-time control). </li></ul><ul><li>Depth: can be used for sketching (whiteboarding), as a blueprint, or as an executable language. </li></ul>
  5. 5. 13 UML Diagrams
  6. 6. UML Diagram Usage
  7. 7. Class Diagram Example
  8. 8. Sequence Diagram Example
  9. 9. Activity Diagram Example
  10. 10. State Machine Diagram Example
  11. 11. The Language Of The Language
  12. 12. Implementation Options
  13. 13. Quotes For Reflection <ul><li>&quot;I hold great hopes for UML, which seems to offer a way to build products that integrates hardware and software, and that is an intrinsic part of development from design to implementation. But UML will fail if management won't pay for quite extensive training, or toss the approach when panic reigns .&quot; - Jack Gannsle </li></ul><ul><li>“ Always specify and/or design as if the guy who ends up using your output as his input will be a violent psychopath who knows where you live.” - Damian Conway </li></ul><ul><li>“ Incorrect documentation is often worse than no documentation.” - Bertrand Meyer </li></ul><ul><li>“ It’s software development, not documentation development.” – Scott Ambler </li></ul>

×