Dynamic Models in Design

1. Dynamic Models in Design CS6961 – Lecture 12 Nathan Dykman CS6961 - Lecture 12

2. Dynamic Models • To review, there are two major type of models in UML • Static models • Use Case, Class, Component, Deployment • Composite structure (mix of static/dynamic) • Dynamic models • Sequence, State, Activity CS6961 - Lecture 12

3. Dynamic Models • Dynamic modeling is often overlooked in the design process • Why is this, do you think? • Using dynamic models comes down to balance: • Too little: Critical dynamic details may be missed • Too much: Overwhelming detail CS6961 - Lecture 12

4. Dynamic Modeling • I think dynamic models are best used in two ways: • Exploratory: Does this design do what we want, how could it do it? • Descriptive: This is a tricky aspect of the system, this model (should) help explain what is going on CS6961 - Lecture 12

5. Dynamic Modeling Traps • Unfortunately, dynamic models are easy to overuse • For example, requiring a state diagram for every class • Not surprising, most of these diagrams aren’t helpful • Or activity diagram, or sequence diagram, etc. • Therefore, some avoid them completely • Missing out where they are useful. CS6961 - Lecture 12

6. Dynamic Modeling Domains • However, in some software domains, these kinds of models are critical: • Embedded Systems: Must have predictable, reactive behavior • Telecommunications: Strict protocol requirements • Service Oriented Applications: Conversations, Transactions very important. • And so on. CS6961 - Lecture 12

7. UML 2.0 Example CS6961 - Lecture 12

8. Sequence Diagram • Hopefully, all of you recognized the preceding diagram as a sequence diagram • If not, review chapter 4 of UML Distilled. • In design, the messages can be actual method calls • Because the instances on the sequence diagram are class instances CS6961 - Lecture 12

9. Sequence Diagrams • Are probably the most popular means of showing interaction between objects in UML • Communication Diagrams are still preferred by some (not me) • Remember, UML 2.0 added interaction frames • Which added to the expressiveness of sequence models. CS6961 - Lecture 12

10. Sequence Diagrams • It is often useful to take select use cases and build a sequence diagram in the design that reflects the use case • Insures that the design does cover use case functionality • Doesn’t need to be perfect, but enough detail to verify that the use case can be performed as required. CS6961 - Lecture 12

11. Sequence Diagrams • Complex systems often contain quite a bit of messaging • For example, most web systems pass between multiple classes (and layers) to process/render web pages • Sequence diagrams can show this interaction fairly well • Examples show how the flow of messages is structured. CS6961 - Lecture 12

12. UML 2.0 Example Action/ Activity Decision Point Fork/Join Activity with Sub-activity model CS6961 - Lecture 12

13. Activity Diagrams • This is an activity diagram. • We will cover activity models in more detail • For now: • Easy modeling of parallelism • Activities can nest (have sub-structure) • We will cover how to link activity models to classes • As well as execution in general. CS6961 - Lecture 12

14. Activity Diagrams • I find activity diagrams best used to model large scale workflow in the system • Workflow is a topic in of itself, of course • Workflows are more common in systems with longer-standing transactions • For example, maintaining a relationship with a shipping office, a supplier of goods, a long-term customer, etc. CS6961 - Lecture 12

15. Activity Diagrams • Again, activity diagrams should feel forced • They should pop out naturally to you • Also, remember that activity diagrams display parallel/concurrent behaviors • Sequence diagrams don’t do this nearly as well. • Activities can be linked to use cases • For example, a use case can become an activity (or activities) in a system. CS6961 - Lecture 12

16. State Example CS6961 - Lecture 12

17. State Diagram • Again, more details to come. But for now, note the following: • We have states. States can nest, or have their own state machine • We have start states (final states as well) • Substates (or complex states) can have multiple entry/exit states • Later, we will learn that these, like start/final states, are called pseudostates. CS6961 - Lecture 12

18. State Machines • In some domains, state machines are rare • In embedded systems, they can be the most commonly used diagram • Executable UML often centers around state diagrams • The state model in UML is quite complex • Again, don’t force it • But sometimes, it is a very useful abstraction to use. (So, don’t ignore it completely) CS6961 - Lecture 12

19. Pushing the Edges • For those interested in how dynamic models are used in real-time systems, check out: • Real Time UML (3rd Edition), by Bruce Powell Douglas • You can get access to real-time tools from Telelogic, iLogix, IBM/Rational if you liked • All require the use of a license server. CS6961 - Lecture 12

20. Dynamic Models • Tools like RSA tools do very little with dynamic models • You need a special modeling tool to do code generation from state machines, etc. • These are very complex tools • Some tools are starting to do forward and reverse engineering of sequence diagrams • RSA is supposed to do this for Java, no clue if it really does CS6961 - Lecture 12

21. Summary • Next Time, we go into more details • This may include exercises! • Be warned. • Reading: Chap. 4, 10, 11 in UML Distilled. CS6961 - Lecture 12