1. Seeing the Forest in the Midst of the Trees

2. Who am I  Dr. Curtis Hrischuk  Adjunct professor at University of Alberta, Canada  Taught undergraduate and graduate software engineering  Worked for several communications companies writing software  Too many years to admit  Currently a Rational Software employee  Working on Rational Rose  Dr. Curtis Hrischuk  Adjunct professor at University of Alberta, Canada  Taught undergraduate and graduate software engineering  Worked for several communications companies writing software  Too many years to admit  Currently a Rational Software employee  Working on Rational Rose

3. Agenda  What is happening in the software world  What is most important to the developer  What is UML  What is cool that UML is useful for  What is happening in the software world  What is most important to the developer  What is UML  What is cool that UML is useful for

4. What is happening in the software world

5. ......................... “26% of software projects succeed.” Standish Group, CHAOS Report, 2000 “26% of software projects succeed.” Standish Group, CHAOS Report, 2000 The Good News…

6. ......................... That means 74% failed! Standish Group, CHAOS Report, 2000 That means 74% failed! Standish Group, CHAOS Report, 2000 The Bad News…

7. Software Development is Complex  Poorly designed project architectures require untimely changes  Requirements are undefined or change mid-project  Discovering defects late in project or flaws in architecture and design  Lack of communication between disparate team members  Artifacts are not accessible to all team members  Poorly designed project architectures require untimely changes  Requirements are undefined or change mid-project  Discovering defects late in project or flaws in architecture and design  Lack of communication between disparate team members  Artifacts are not accessible to all team members Poor Management = CHAOS

8. Standish Group, CHAOS Report, 2000 How To Make Sure Your Project will Fail  Lack of user input  Unclear objectives  Incomplete requirements and specifications  Changing requirements and specifications  Lack of planning  Lack of user input  Unclear objectives  Incomplete requirements and specifications  Changing requirements and specifications  Lack of planning COMMUNICATION

9. Necessity of Communication  Think of a 100 man-person team  Analysts, developers, QE, documentation, contractors  Marketing, product management, VPs  Geographically dispersed  Different offices  Different countries  Different time zones  Requirements change or priorities are rearranged  Different sub-systems are developed at different times  Number of communication paths increases by the square of the team size  Think of a 100 man-person team  Analysts, developers, QE, documentation, contractors  Marketing, product management, VPs  Geographically dispersed  Different offices  Different countries  Different time zones  Requirements change or priorities are rearranged  Different sub-systems are developed at different times  Number of communication paths increases by the square of the team size

10. Higher Quality Faster Time to Market The Software Development Paradox Internet time :( Now do it with less …

11.  Over the life of a product, the distribution of effort is:  30% development  70% maintenance  Development  40% analysis &design  20% implementation  40% validation  Maintenance  20% adaptive  60% perfective  20% corrective  Over the life of a product, the distribution of effort is:  30% development  70% maintenance  Development  40% analysis &design  20% implementation  40% validation  Maintenance  20% adaptive  60% perfective  20% corrective The Software Effort Breakdown < Requirements and modeling < Testing < IDE and compiler (fun?)

12. What is Most Important

13. How to Make a Better Car …  The manufacturing of cars follows a process (assembly line)  An efficient assembly process means a good output rate  A quality assembly process means few defects  The process is tailored for the product  The process is improved and made more efficient  Software is no different …  The software process is the competitive advantage  We are manufacturing software  Tools are one aspect of the process  The manufacturing of cars follows a process (assembly line)  An efficient assembly process means a good output rate  A quality assembly process means few defects  The process is tailored for the product  The process is improved and made more efficient  Software is no different …  The software process is the competitive advantage  We are manufacturing software  Tools are one aspect of the process

14. Best Practices Process Made Practical Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Continuously Verify Quality Manage Changes (UCM) Model Visually (UML) Develop Iteratively Manage Requirements Use Component Architectures Continuously Verify Quality Manage Changes (UCM) Model Visually (UML)  Adopted by…  IBM  Microsoft  Oracle  Sun  Cap Gemini Ernst & Young  Deloitte Consulting  Rational Software! Avoid the hubris that you can do without a process

15. Develop Iteratively Initial Planning Requirements Analysis & Design Implementation Test Deployment Evaluation Management Environment Each iteration results in an executable release

16. Benefits of Iterative Development  Resolves major risks before large investments  Improves quality through continuous testing  Target your testing where breaks are likely  Delivers frequent, objectively verifiable milestones  Keep moral up  Keep managers and customers happy  Provides early and continuous user feedback  Keeps customers even happier (they pay the bills)  Enables quick reaction to new requirements and change requests  Find out needed changes as soon as possible  Resolves major risks before large investments  Improves quality through continuous testing  Target your testing where breaks are likely  Delivers frequent, objectively verifiable milestones  Keep moral up  Keep managers and customers happy  Provides early and continuous user feedback  Keeps customers even happier (they pay the bills)  Enables quick reaction to new requirements and change requests  Find out needed changes as soon as possible

17. More Process Plumbing  Defect tracking for those of us who aren’t perfect  Identify errors, enhancements, priorities, …  Per product, release, development stream, …  Leads to quality decisions ----> Million $ decisions  Project management  We’ll leave it to Microsoft!  Requirements management  Configuration and change management  Defect tracking for those of us who aren’t perfect  Identify errors, enhancements, priorities, …  Per product, release, development stream, …  Leads to quality decisions ----> Million $ decisions  Project management  We’ll leave it to Microsoft!  Requirements management  Configuration and change management

18. Manage Requirements  Are you building the system that the customer wants?  Find the impact when the customer changes their mind  Are you building the system that the customer wants?  Find the impact when the customer changes their mind

19. Workspace Management Parallel Development Build Management Configuration and Change Management  Control, track, and monitor changes to artifacts  Enable parallel iterative development  Multiple teams working in different streams  Establish secure workspaces for each developer  Automate integration and build management  Control, track, and monitor changes to artifacts  Enable parallel iterative development  Multiple teams working in different streams  Establish secure workspaces for each developer  Automate integration and build management Brief Description: The description should briefly convey the role and purpose of the use case. A single paragraph should suffice for this description. Flow of Events: This use Reports ! ! ! Alert

20. Assess architecture for functionality defects Continuously Verify Quality  Verify critical functions early by focusing on key use-case scenarios  Drive architecture with key scenarios  Assign “at risk” scenarios to earliest iterations  Implement and assess each iteration  Verify critical functions early by focusing on key use-case scenarios  Drive architecture with key scenarios  Assign “at risk” scenarios to earliest iterations  Implement and assess each iteration

21. What is Missing  Need a common language that unifies the different stake holders  Different stake holders have different software abstractions (models) and artifacts  We need ….  Need a common language that unifies the different stake holders  Different stake holders have different software abstractions (models) and artifacts  We need ….

22. Communication Using the Unified Modeling Language Data Modeling Web Modeling One language – One tool – One team Application Modeling Business Modeling Requirements Modeling

23. Who Should Model? Requirements and Business Models HTML CGI XML JavaScript Data Models Data Models C++ Java SW Models Software Engineer Database Designer Web Content Developer Business Analyst

24. Host or Target Application The Developer’s View The Model is The Application Use Case Diagram Sequence Diagram Class Diagram Structure Diagram Behavior Diagram Component Diagram Deployment Diagram

25. The Unified Modeling Language

26. UML History  1994: Grady Booch and Jim Rumbaugh began unifying their modeling techniques at Rational Software  1995: Ivar Jacobson joins team at Rational  1996: Consortium of 12 companies formed to oversee UML  Jan 1997: Version 1.0 published  Sept 1997: Revised Version 1.1  Nov 1997: Object Management Group standardized  Version 1.4 just accepted  Working on version 2.0  1994: Grady Booch and Jim Rumbaugh began unifying their modeling techniques at Rational Software  1995: Ivar Jacobson joins team at Rational  1996: Consortium of 12 companies formed to oversee UML  Jan 1997: Version 1.0 published  Sept 1997: Revised Version 1.1  Nov 1997: Object Management Group standardized  Version 1.4 just accepted  Working on version 2.0

27. Why is the Word “Model” Important?  Developing software is about developing executable abstractions  An abstraction or view is a model  For example, a class is an abstraction of a real-world entity or concept  Different stake holders have different abstractions  Marketing has the feature sheet  Developers have the requirements  Testing have test cases and configurations  There are model types in building a system  Developing software is about developing executable abstractions  An abstraction or view is a model  For example, a class is an abstraction of a real-world entity or concept  Different stake holders have different abstractions  Marketing has the feature sheet  Developers have the requirements  Testing have test cases and configurations  There are model types in building a system

28. UML Context  It enables and promotes a  use-case-driven  architecture-centric  iterative  incremental process that is  object oriented and component based  Justification is that  Use cases are used to manage and provide focus for a problem-solving effort.  Architecture is used to manage complexity and maintain integrity and focus as a solution to a problem evolves.  Iterations and increments are used to repeatedly apply a process to evolve a solution to a problem.  It enables and promotes a  use-case-driven  architecture-centric  iterative  incremental process that is  object oriented and component based  Justification is that  Use cases are used to manage and provide focus for a problem-solving effort.  Architecture is used to manage complexity and maintain integrity and focus as a solution to a problem evolves.  Iterations and increments are used to repeatedly apply a process to evolve a solution to a problem.

29. Why is UML So Great?  Combines best ideas from software engineering, database theory, and system design  Technology agnostic  Problem domain agnostic  Extensibility mechanisms allow tailoring to the domain  Scalable  Recursive, hierarchical decomposition  Bootstrapping principle  Language that can define itself  High information density  Visual  Packs a lot into a small space  Combines best ideas from software engineering, database theory, and system design  Technology agnostic  Problem domain agnostic  Extensibility mechanisms allow tailoring to the domain  Scalable  Recursive, hierarchical decomposition  Bootstrapping principle  Language that can define itself  High information density  Visual  Packs a lot into a small space

30. UML Defines Itself (Principle of Bootstrapping)

31. UML Models  Models capture  the structural, or static, features of systems  the behavioral, or dynamic, features of systems.  Models have several independent dimensions  Each emphasize particular qualities of a model  Each dimension has a diagram type  Models capture  the structural, or static, features of systems  the behavioral, or dynamic, features of systems.  Models have several independent dimensions  Each emphasize particular qualities of a model  Each dimension has a diagram type

32. UML Diagrams  Use case diagrams depict the functionality of a system.  Class and object diagrams for the static structure  Sequence (collaboration) diagrams for behavior in a scenario  State diagrams for execution  Activity diagrams for process descriptions  Component diagrams for dependencies between components  Deployment diagrams for configuration and environment  Use case diagrams depict the functionality of a system.  Class and object diagrams for the static structure  Sequence (collaboration) diagrams for behavior in a scenario  State diagrams for execution  Activity diagrams for process descriptions  Component diagrams for dependencies between components  Deployment diagrams for configuration and environment

33. Other Elements of UML  There are many  Package, sub-system, class, classifier, interface, …  We really don’t have the time to discuss this  Talk to your professors  There are many good books around  There are many  Package, sub-system, class, classifier, interface, …  We really don’t have the time to discuss this  Talk to your professors  There are many good books around

34. Newbie Difficulties

35. Fallacy of Identification  We think that our models are in fact reality  The model is an abstraction with assumptions  Our assumptions fit reality  Reality does not fit our assumptions  We think that our models are in fact reality  The model is an abstraction with assumptions  Our assumptions fit reality  Reality does not fit our assumptions

36. Analysis Paralysis  When developers only focus on the model  Need to make a decision but the model provides no guidance  Developers are stuck  Don’t know what to do next  Leads to diminishing returns  More modeling effort does not greatly increase the quality of the design  Do something logical to break the cycle  When developers only focus on the model  Need to make a decision but the model provides no guidance  Developers are stuck  Don’t know what to do next  Leads to diminishing returns  More modeling effort does not greatly increase the quality of the design  Do something logical to break the cycle

37. Cool Things to do with UML

38. Unit Test Functionality  Generate test code directly from model  Provide test data and expected results  Generate test code directly from model  Provide test data and expected results Generate Component Test Stub Test Driver Model Test Generation Developer Adds Test Data

39. System Test Functionality ?? Model Create Components Brief Description: The description should briefly convey the role and purpose of the use case. A single paragraph should suffice for this description. Flow of Events: This use case starts when the actor does something. An actor always initiates use Cases. The use case should describe what the actor does and what the system does in response. It should be phrased in the form of a dialog between the actor and the system. The use case should describe what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the Actor enters customer information; it is better to say the Actor enters the customer’s name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageable; you may want to define things like customer information there, to keep the use case from drowning in details. Simple alternatives may be presented within the text of the use case. If it only takes a few and what the system does in response. It should be phrased in the form of a dialog between the actor and the system. The use case should describe what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the Actor enters customer information; it is better to say the Actor enters the customer’s name and address. A Glossary of Terms is often useful to keep the complexity of the use case manageable; you may want to define things like customer information there, to keep the use case from drowning in details. Simple alternatives may be presented within the text of the use case. If it only takes a few Tests Generate “Skeleton” Code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code code Complete Code code Automates Component Testing 1. Embellish model  Easier testing  More complete testing 1. Embellish model  Easier testing  More complete testing 2. Automatically generate component tests from the model  Automatically generate code for component testing from a UML model  Enable scenario-based testing during component integration, before system is complete  Automatically generate code for component testing from a UML model  Enable scenario-based testing during component integration, before system is complete

40.  Ready made design and code solutions for common development tasks  COM, MFC, ATL  MTS, ADO  ASP, DHTML  Fully customizable  You can create your own code templates to automate common design and implementation tasks to ensure consistency in both design and code  Ready made design and code solutions for common development tasks  COM, MFC, ATL  MTS, ADO  ASP, DHTML  Fully customizable  You can create your own code templates to automate common design and implementation tasks to ensure consistency in both design and code Code Templates For Architecture Design

41. Frameworks For Architecture Definition  Frameworks: Predefined model element sets for modeling specific systems  Used to:  Define the architecture of specific types of systems  Provide a set of reusable components  Create templates for new models  Simplify development with commercial frameworks  Promote reuse and standards with custom user frameworks  Frameworks: Predefined model element sets for modeling specific systems  Used to:  Define the architecture of specific types of systems  Provide a set of reusable components  Create templates for new models  Simplify development with commercial frameworks  Promote reuse and standards with custom user frameworks

42. Robust Development Using Proven Patterns  Develop your application using predefined industry recognized patterns:  Apply patterns to existing model elements  Create new model elements automatically via patterns  Leverage proven designs  Develop your application using predefined industry recognized patterns:  Apply patterns to existing model elements  Create new model elements automatically via patterns  Leverage proven designs

43. Keeping the Model and Code Synchronized  Manual model and code synchronization  On-demand synchronization  Complete control as updates occur  Auto synchronization  Source is updated when model is modified  Rational Rose model updated when source is modified  Manual model and code synchronization  On-demand synchronization  Complete control as updates occur  Auto synchronization  Source is updated when model is modified  Rational Rose model updated when source is modified

44. UML Model Debugging Rational Rose RealTime Model Generate/Compile Control/Observe

45. Distributed UML Designs  Enables deployment and visualization of distributed applications  Supports patterns for creating high-availability applications  Provides the distributed communication infrastructure  Enables deployment and visualization of distributed applications  Supports patterns for creating high-availability applications  Provides the distributed communication infrastructure COTS Server Shelf Controller Call Server Administration H/W Control

46. Do all of this for Multiple Languages  UML models can be targeted for different languages  Java  Microsoft Visual C++  Microsoft Visual Basic  ANSI C++  Ada  IDL  XML-DTD  SQL  UML models can be targeted for different languages  Java  Microsoft Visual C++  Microsoft Visual Basic  ANSI C++  Ada  IDL  XML-DTD  SQL

47. That’s all

48. Some Important Web Sites  The SEEDS program will let your college get Rose  http://www.rational.com/corpinfo/college_relations/seed/terms cond.jsp .NET development  http://rational.devx.com/index.htm/CONTENT_ID/5959  Java development  www.jroundup.com  Project management  www.ganthead.com  The SEEDS program will let your college get Rose  http://www.rational.com/corpinfo/college_relations/seed/terms cond.jsp .NET development  http://rational.devx.com/index.htm/CONTENT_ID/5959  Java development  www.jroundup.com  Project management  www.ganthead.com

50. “ClearCase is the dominant SCM tool.”Ovum No.1 in Visual Modeling, 4 years running 1 Rational Rose No.1 in SCM, 3 years running 1 Rational ClearCase “…a major contender as the de facto standard for real-time embedded...”IDC Real-time embedded leadership Rational Rose RealTime “...the battle for dominance is over: Rational wins.”Ed Yourdon Driving Standards in Best Practices UML, WebDAV “…the company that put the ‘unified’ in modeling languages…”JavaPro “Easy-to-use...ideal for team based development...” InfoWorld No.1 in Requirements Management 2 Rational RequisitePro 1 IDC, 2 Standish Rational: Ongoing Leadership