1 / 40

Seeing the Forest in the Midst of the Trees

Intro to UML (materials herein excerpted from Seeing the Forest in the Midst of the Trees). Seeing the Forest in the Midst of the Trees. What is happening in the software world. The Good News…. “26% of software projects succeed.” Standish Group, CHAOS Report, 2000. The Bad News….

ivana-hebert
Download Presentation

Seeing the Forest in the Midst of the Trees

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Intro to UML (materials herein excerpted from Seeing the Forest in the Midst of the Trees) Seeing the Forest in the Midst of the Trees

  2. What is happening in the software world

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

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

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

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

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

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

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

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

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

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

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

  14. The Unified Modeling Language

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

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

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

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

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

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

  21. USE CASEs • Describes the proposed functionality of a system • Represent functional requirement • Notation • Use cases: ellipse with action phase • Actors is a user of the system or other systems

  22. Logical Model • Class and Object Diagrams • Class Diagram Notation • 3-compartment rectangle • Relationship among classes • Object diagram: instance of a class • Accessibility Notation

  23. Logical Model (continued) • Class and Object Relationship • Inheritance: generally describes the hierarchical relationship between classes (family tree) • . Some materials herein are excerpted from The Logical Model by Geoffrey Sparks

  24. Logical Model (continued) • Class and Object Relationship • Association: generally relate to one object having an instance of another as an attribute or owning. Some materials herein are excerpted from The Logical Model by Geoffrey Sparks

  25. Sequence Diagrams (dynamic relationship) • illustrates this message passing and the sequence in which it occurs normally within a given usecase Some materials herein are excerpted from The Logical Model by Geoffrey Sparks

  26. Logical Model (continued) • Class and Object Relationship • Aggregation: generally define whole/part relationships. . Some materials herein are excerpted from The Logical Model by Geoffrey Sparks

  27. Cool Things to do with UML

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

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

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

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

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

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

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

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

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

  37. That’s all

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

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

More Related