1 / 14

UML and OOAD

UML and OOAD. U nified M odeling L anguage O bject O riented A nalysis and D esign. UML Origins. A product of the “design wars” of the 1980’s Grady Booch, James Rumbaugh, and others had competing styles. `94: Rumbaugh leaves GE to join Booch at Rational Software

betsy
Télécharger la présentation

UML and OOAD

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. UML and OOAD Unified Modeling Language Object Oriented Analysis and Design SCT/Pixel Online Workshop 18-19 June, 2001

  2. UML Origins A product of the “design wars” of the 1980’s Grady Booch, James Rumbaugh, and others had competing styles. `94: Rumbaugh leaves GE to join Booch at Rational Software “Method wars over. We won.” Others feared achieving standardization the Microsoft way. ’95: Rational releases UML 0.8; Ivars Jacobson (use cases) joins Rational“The Three Amigos” ’96: Object Management Group sets up task force on methods ’97: Rational proposed UML 1.0 to OMG. After arm twisting and merging, UML 1.1 emerges ’99: After several years of revisions and drafts, UML 1.3 is released SCT/Pixel Online Workshop 18-19 June, 2001

  3. What UML is • A way to express a software design, mostly through graphical tools • Is important for communication, does not specify the process used to reach a design. That process is far more more nebulous • Compare it to using circuit schematics and timing diagrams for documenting hardware designs • Capture the important details, “the art is knowing what to leave out.” SCT/Pixel Online Workshop 18-19 June, 2001

  4. What UML Can Do for Us • Lets us make out mistakes on paper, before we write and debug the code • Lets us communicate our ideas better • Lets us tap into a wealth of existing designs (patterns) that lets us draw on others’ experience • Lets us use existing tools designed around UML Rational Rose Rhapsody SCT/Pixel Online Workshop 18-19 June, 2001

  5. UML Tools: Class Diagram • Captures the packaging of the solution into software objects. • Elaborates the relationships betweeen objects, allowing dependencies to be controlled. • In an OO language, leads directly to coded objects. • A good basis for discussion and documentation. • But, it only shows the static structure. • Like a circuit diagram in electronics, it shows connectivity but not the dynamics of signals or messages. SCT/Pixel Online Workshop 18-19 June, 2001

  6. UML Tools: Sequence Diagram • Time runs downward • Shows how objects interact • Gives the sequence of interactions, but not the precise timing • Roughly analogous to timing diagrams in electronics • Have already been extremely useful in developing the DSP communication with the ROD hardware SCT/Pixel Online Workshop 18-19 June, 2001

  7. UML Tools: State Diagram • Not much different from usage in many other areas • Describes an object that changes state under specified transition activities and does specified activities in that state • Another tool for describing dynamic behavior SCT/Pixel Online Workshop 18-19 June, 2001

  8. OOAD • Going to Object Oriented software is not just changing the syntax of the language. It is a new way of organizing software. • An object is an instantiation of a class. Just as i can be an instantiation of type integer, x an instantiation of type float and “A” and instantiation of type char, an object myObj can be an instantiation of a (user-defined) class myClass. • An object has a state (specified by values of attributes) and behavior (given by functions, or methods). SCT/Pixel Online Workshop 18-19 June, 2001

  9. OOAD (2) • The idea is to keep as many of the details of the objects functionality inside the object and present only a well-defined interface to the outside world. • Open to extending the behavior or the object, but closed to exposing changes inside the object to the outside world. • Try to keep one piece of software from depending on changes to another piece. SCT/Pixel Online Workshop 18-19 June, 2001

  10. Example 1: VME Crate A VME crate has three modules in it: ADC, TDC, CPU. We need a routine that initializes the entire crate. The old way: Void initCrate(int crateNumber) { initADC(); initTDC(); initCPU(); } There are smarter ways (e.g. case statements), but there is no way to avoid the need for initCrate to call separate init routines for each type of module. SCT/Pixel Online Workshop 18-19 June, 2001

  11. VME Crate (2) The OO way: Void initCrate(crateNumber) { // interate over modules Module.init(); } The routine initCrate no longer needs to know what kind of module it is talking to. We could even add a new type of module and it wouldn’t care. SCT/Pixel Online Workshop 18-19 June, 2001

  12. VME Crate (3) • The module-specific details are encapsulated inside the object. • The various init routines are polymorphic as seen from the outside world. SCT/Pixel Online Workshop 18-19 June, 2001

  13. Example 2: Database Access As long as the methods of dbUser refer to the interfaces of myDataBase, they will not care whether we use a simple ASCII text file or a messy object oriented database. We can go from one to the other without changing dbUser. SCT/Pixel Online Workshop 18-19 June, 2001

  14. References ISBN: 020165783X ISBN: 0132038374 SCT/Pixel Online Workshop 18-19 June, 2001

More Related