Seeing the Forest in the Midst of the Trees

1. Seeing the Forest in the Midst of the Trees 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

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

4. What is happening in the software world

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

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

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 PoorManagement =CHAOS

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

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

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

11. The Software Effort Breakdown • 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 < Requirements and modeling < IDE and compiler (fun?) < Testing

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

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

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

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

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

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

19. Configuration and Change 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 • 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 Workspace Management Parallel Development Reports Reports Alert ! ! Build Management

20. 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 Assess architecture for functionality defects

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 ….

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

23. Who Should Model? RequirementsandBusiness Models HTMLCGIXMLJavaScript BusinessAnalyst Web ContentDeveloper Everyone! C++JavaSW Models Data Models SoftwareEngineer DatabaseDesigner

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

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

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

28. 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

29. UML Defines Itself (Principle of Bootstrapping)

30. 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

31. 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

32. 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

33. Newbie Difficulties

34. 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

35. 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

36. Cool Things to do with UML

37. Unit Test Functionality TestDriver Generate Component Test Stub Stub Developer AddsTest Data • Generate test code directly from model • Provide test data and expected results Test Generation Model

38. System Test Functionality Model • 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 Automates Component Testing Complete 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 Generate “Skeleton” Code Create Components Tests code code code code code code code code code code code  ?? 1. Embellish model • Easier testing • More completetesting 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

39. Code Templates For Architecture Design • 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 automatecommon design and implementation tasks to ensure consistencyin both design and code

40. 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

41. 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

42. 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

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

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

45. 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

46. That’s all

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

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