[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 19x.html Fri Mar 8 09:46:07 PST 2013

Contents


    Exercises 19 -- UML Interaction Diagrams and DCDs

    1. Name the two types of interaction diagrams and give very simple example of the same interaction using one type of diagram and the other. Add a DCD that supports the interaction.
    2. How do you show that one class is responsible for creating an object? Show the creation UML notation for both types of interaction diagram. How might you show this in a DCD?
    3. How do you show that a class is responsible for executing an operation rather than an object?
    4. How do you show an operation that will be static in C++ or Java?
    5. How can you show an array and an element in an array in the UML?
    6. What is a found message? What does it mean?
    7. How do you show a returned object in a sequence diagram?
    8. Explain these structures: alt, loop, and opt.
    9. How do you show an action (x=x/2.0; for instance) in a sequence diagram?
    10. Explain ref and sd and the relation between them.
    11. In a communication diagram -- how many messages per link? How are the sequenced?
    12. I have messages numbered 1, 2, 3, 2.1, 1.1, 3.1, 1.2, 3.2. In what sequence are they actually sent?
    13. What does this mean in a communication diagram: [gender = male]? And what does *[i=1..20]?
    14. What is the purpose and form of a DCD? How does it relate to a Domain Model?
    15. Invent an example and use it to demonstrate three different ways of showing an attribute in a UML class diagram.
    16. What information can you attach to an operation in a UML DCD?
    17. How do you document the code for an operation in a UML DCD?
    18. Explain "keyword", "constraint", and "stereotype" in the UML.
    19. Draw a diagram that illustrates (using your own invented example) "generalization".
    20. What is an "abstract" class?
    21. How do you show that class "A" depends on class "B".
    22. How do you show an "interface" in the UML?
    23. WHat does an association class do?
    24. What is a singleton class?
    25. How do you show templatized classes in the UML?
    26. Give an example in the UML of a class in the C++ STL.
    27. Simple example from use case to code

      MiniCalc

        Use Case: The user inputs an arithmetic expression with addition, multiplication, and constant integers, and the system evaluates it.

        Analysis: Separate the parsing of the expression from the evaluation. The GRASP Controller is called Parser which which is also the Builder (GoF) of an Expression data structure before evaluating it.

        Iteration Plan: Develop the evaluation package first with a test expression constructed in "main".

        Design: [ Minicalc.png ] (graphic DCD+example communications), [ Minicalc.cpp ] (C++ code), [ Minicalc.Cards.html ] (CRC like cards), and [ Minicalc.dia ] (Editable dia diagram).

        Exercise 0: what GoF and GRASP patterns did I use?

        Execise 1: Simulation with one object per student.

        Exercise 2: New use case: print out an expression. Add a print function to Expressions and Operators.

        Exercise 3: Add Subtraction to the design.

        Exercise 4: Translate into Java/PHP/Python/Ruby/YFOOPL and make it work. Keep the UI simple.

      1. YFOOPL::acronym="Your Favorite Object Oriented Programming Language".

      . . . . . . . . . ( end of section MiniCalc) <<Contents | End>>

      Example Exam Project

        Note -- also see the PIzza project and the CSUSB Inventory project.

        Vision

        Yet another social networking site...

        We will encourage people and companies to post pages to our site. we will charge companies but in other repects they are very similar -- call them bother entities. Each Page has an Entity. Entities have a series of Pages. Pages are tagged by people. People can record a relationship with a page (but not with entities). Types of pages: Advert, Photo, Link, Blog, ... Photos have a time and place. Links have a URL.

        Domain Model

        TBD

        Use Case Model -- Diagram

        TBD

        Use Case Model -- Scenarios

        TBD

        Use Case Model -- SSD

        TBD

        Interaction diagram of the effect of an incoming system message

        TBD

        DCD

        TBD

    . . . . . . . . . ( end of section Exercises 19 -- UML Interaction Diagrams and DCDs) <<Contents | End>>

    Standard Definitions

  1. Artifact::="Anything that is created in the course of a project".
  2. artifact::=see above.

  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code. [ 02DiceGameClasses.gif ] (example).
  4. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".

  5. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  6. GoF::="Gang of Four", [ patterns.html#GoF ]
  7. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good set of objects and/or classes to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  8. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  9. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what has no value now, see YAGNI.

  10. OO::shorthand="Object-Oriented".
  11. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.

  12. patterns::="Documented families of problems and matching solutions", see Patterns.
  13. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  14. Process::="How to develop software".

  15. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci and Engineering School, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

  17. SSD::="System Sequence Diagrams", see chapter 10 and [ 02DiceGameSSD.gif ] (example).

  18. TBA::="To Be Announced".

  19. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  20. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  21. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need it now. In this class it also means "It won't be on the final or in quizzes".

  22. XP::="Extreme Programming", the ultimate iterative, code-centric, user-involved process.

( End of document ) <<Contents | Top