[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] 17dynamics.html Wed Jan 11 07:25:59 PST 2012

Contents


    Modeling Dynamics -- Activity Diagrams and State Machines

      -- Chapter 28: UML Activity Diagrams

    1. This is covered in CSci372 and skipped in CSci375.
    2. ++ Flowcharts reborn.
    3. -- Introduction
    4. -- 28.1 Example
    5. -- 8.2 Uses: BPM DFD Algorithms ...
    6. ++ Beware using an activity diagram to show a DFD. UML activity diagrams imply a strict sequence rather than a set of loosely coupled parallel processes. Even Fig 28.3 implies a strict sequence. To show many components cooperating (as in a typical business) you can use component diagrams. See [ ../papers/rjb04bDFDs/ ] for examples.
    7. -- 28.3 More Notation: Subprograms, decision/merge, signals... See [ 17Signals.gif ] (notation for activities and signals)
    8. --28.4 Guidelines
    9. -- Martin Fowler's "UML Distilled" points out that UML2.0 activity diagrams have different semantics to UML1.* activity diagrams. To avoid confusion an activity should never have more than two control flows out and no more than one control flow in. Use diamonds and bars to make the precise meaning clear.
    10. -- 28.5 Example: NextGen
    11. -- * 28.6 Process: Activity Diagrams in the UP

      -- Chapter 29 State Machine Models

    12. ++ Based on Computer Science Theory from the 1940's!
    13. ++ A very useful and simple way to think about complex behavior patterns. We have tools and theories that help analyze these charts. Most people understand them with little training.
    14. -- Not covered in CSci375 -- lack of time.
    15. -- Introduction
    16. -- 29.1 Example
    17. -- ** 29.2 Definitions
    18. -- ** 29.3 How and when to use
    19. -- ** 29.4 More State Machine Notation
    20. -- ++++ There is a big ambiguity in UML2.0: state diagrams look like activity diagrams and have different semantics. To be clear put an event or condition on all transitions in a state diagram.
    21. -- **** 29.5 Example: model UI Navigation via a state machine
    22. -- 29.6 Example: NextGen
    23. -- ++ Dynamics in the Domain Model. You can also draw a Life History state chart of conceptual objects in the domain. This will often teach a lot about the way things happen in the real world outside the computer.... and give you a lead on how objects evolve `inside the computer.
    24. -- +++ Examples of State Machine Notation [ ../samples/uml.states.gif ] [ 17course.gif ] [ 17doorProtocol.gif ]

    . . . . . . . . . ( end of section Modeling Dynamics -- Activity Diagrams and State Machines. Standard Definitions) <<Contents | End>>

  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.
  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 class 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 is not needed, 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 Dept, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

  17. SSD::="System Sequence Diagrams", see chapter 10.

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