Overview of Software Modeling Techniques and Insights from Project Guidelines

1. Lecture 19 Review Wei Le

2. Project Guidelines Presentation: 12 min (talk, demo, and questions) Nov 16 Wed in class • A big picture on what you have done • Explain in details one or two key modeling documents, or steps you take in research • Insights • How modeling helps you build software, tips you discovered regarding software modeling or • Research discoveries • Demo

3. Project Guidelines Final Documents: in one file (Nov 16 Wed before the class – no delay) • Index of modeling documents • Who did what part • Modeling documents with explanations if necessary • Final thoughts: what have you discovered from this project regarding software modeling and what have you learned that you believe that’s important • Research document will follow the project descriptions Code: submit the demo code unless you talk to me about the waive • Advice for one-person group: you can submit less models but I would like to see the quality of the models and final thoughts • Questions: 5-7pm Monday

4. Statistics Class participation: • 19 lectures + 1 guest lecture • 18 Wild & crazy idea sessions • 14 papers Homework: • 5 homework +1 presentation Final Project: • Project proposal • Mid-point check • Project final

5. Roadmap for Today • Review – big pictures, connect the dots and something you can save for future references • Basic Modeling (UML) • Formal Modeling (OCL, Z, Alloy) • Software Architecture & Design Patterns • Reverse Engineering • Model based verification and Testing The review will try to build a picture of the knowledge and especially connect what we have learned • Class picture • Engineering project presentation 1

6. Software Modeling: what and why • What is software modeling? • Determine and specify software requirement and design in a structure (or sometimes formalized) way • Why do we need models before coding? • Communicate with users • Divide tasks • Verification/testing • What is this course about? • A survey/sampling of techniques for constructing and applying models

7. I. Basic Modeling UML: requirement Requirement stage: A big picture, how users use the system • Use case diagram – function requirement, not necessarily all the requirement can be captured • Use case description • Sequence diagram • Model-based testing Internal detailed behavior: • Statechartor state diagram • Model based testing • Model checking • Activity diagram

8. 1. Basic Modeling UML: design Transition from Requirement to Design • Class diagram • OCL • Design patterns • Component and deployment diagrams • Architecture context

9. Use Case Diagram

10. Use Case Modeling • Scope system and identify primary actors that interact with the system • Determine goals of primary actors • For each actor, consider the ways that the actor typically interacts with the system to accomplish goals - Focus only on interactions between system and actors and ignore interactions between actors • “black-box” - do not describe internal operations (e.g., storing to a data base) • A use case diagram should contain only use cases at the same level of abstraction

11. Organizing Use Cases • Specializing/generalizing use cases • Including use cases • Extending use cases

12. Specializing Use Cases Payment System Make Payment Make Credit Payment Make Cash Payment

13. Including Use Cases Library System Check out <<includes>> Database Retrieval • Used to avoid writing the same flow of events across a number of use cases – as one part of the step

14. Extending Use Cases Order Processing System Make Payment <<extends>> Validate Payment • incorporating additional behavior at specified locations of the base use case • model a separate flow that is executed under certain conditions

15. Use Case

16. Sequence Diagram and Use Case

17. Sequence Diagram • Behavior models at the requirement level • The sequence of messages exchanged by the set of objects performing a certain task • actor, objects (name: class), lifeline and activation box, message (argument, return value) • Alt, opt, break (like break in the loop), par, neg (sequence that must not occur), loop. region (critical region), assert

18. State Diagram • Control aspects of the system • State (abstraction of object values), event (trigger the change), activity, transition, guard condition (Boolean expression) • Event types: change event (when t>80) , signal event (pick up a phone), time event (after 10 s)

19. State Diagram

20. Activity Diagram • Richer behavior diagram – both data and control flow • Capture unit of executable functionality – compare to sequence diagram • Mathematical functions • Calls to other behaviors • Processors of data • When to use it • Business modeling • Dataflow • Concurrent program and parallel algorithm

21. Activity nodes • Action nodes: executable activity nodes • Parameter Nodes: input/output parameters • Control nodes:coordinate flows in an activity diagram between other nodes Activity final – entire activity; flow final – terminate a path • Object nodes: data passing through the flow – pin Buffer, Datastore

22. Activity edges • Directed • Weight: determines the minimum number of tokens that must traverse the edge at the same time • Control flow edge • Object flow edge

23. «local precondition» Have a license To motorway tollgate Go to the station with a friend Catch the ticket Buy the ticket Obliterate the ticket The friend goes home Exit to xxxxx tollgate Get luggage ready Go home with the car Study for 5 minutes Go to Heaven/ Hell ;) Go to Heaven/Hell ;) Fill up with fuel Pay the ticket Get off the train Go home with bus Catch the train Car crash Turn on the car [else] [on car] [the tank is full] [on train] The train derail When the train arrives to xxxxx [else] [xxxxx is a long way]

24. Class Diagram • Name • Attribute [visibility] name [multiplicity] [: type] [= initial-value] • Operation [visibility] name [(parameter-list)] [: return type] • Construct class diagrams from requirement: names – objects, relations of objects + balanceOn (date: Date) : Money

25. Association, Aggregation and Composition

26. Component and Deployment Diagrams • Component diagram: interface and dependency • The structural relationships between the components of a system • Deploy diagram: • Where the different components of the system will physically run and how they will communicate with each other. • A node represents either a physical machine or a virtual machine node (e.g., a mainframe node).

27. Component and Deployment Diagrams

28. 1. Basic Modeling UML: • Requirement : use case, sequence, state, actitivity • Design and architecture: class, component, deployment • Questions? • Next: Formal Modeling

29. 2. Formal Modeling Requirement and design that can be precisely described • Class invariant • Constraints: pre/post conditions of operations/states When/Why? • Automatically generate code • Check for Correctness Formal modeling can be used with informal modeling • OCL mostly use with UML • There is also a tool that integrates Z to UML

30. OCL – a Typed, Declarative Language • Class Invariants - attributes, association • Pre-/Post- Conditions for Operations Context class name/operation/attributes Init/Pre/Post/Inv: context Customer::birthdayOccurs() pre : -- none post : age = age@pre + 1 contextFlight inv:duration < 4 Flight duration: Integer inv: duration < 4

31. OCL – supported Types and Operations Boolean (or, and, imply), Real and Integer (+,-), String (size, =, concat) Precedence Rules: Name Syntax highest Pathname :: Time expression @pre The dot, arrow, and message operations ., ,^, ^^ Unary operations -, not Multiplication and division *, / Addition and substration +, - Relational operations <,>,<=,>=,<>,= Logical operations and, or, xor Logical implies implies lowest

32. Z – write constraints about system • History: 70s @oxford • Typed, based on Set theory, First Order Logic • Motivation: • Logic deduction to find faults • Precise communicate the requirement • Useful tools – help you write Z spec, type check and run a deduction • Community Z Tools (CZT) project • Latex style tool

33. Z- Elements • Set: a collection of items that are belong to the same category • Type: a total set of items of the same category - Z (integer set) • Tuple: instances of Cartesian product AXB • Relation: a set of tuples • Function: a binary relation, an element in the domain has the unique element in the range • Sequence: ordered elements

34. Z Basic Constructs • Declarations introduce variables. • Expressions describe values that variables can assume– compute values • Operations on constants and variables (set and arithmetic) • Predicatesplace constraints on the values that variables do assume • Arithmetic relations • Set membership • Set relations • Logic: building from the above

35. Z - Advanced Constructs • Z schema - math in a box, with a name attached • Used for declarations, predicates, expressions • Schema calculus builds large schemas from smaller ones. • Lambda expression • let/if-then-else Define functions ( declaration | predicate expression) • (let r == iroot(a) • r*r < a < (r+1)*(r+1)) | x | = if x > 0 then x else -x

36. Z – How to Specify a System

37. Using Z to define an abstract data type state space (a set of variables and their constrains), initial state, operations State space: Initial State: Operation:

38. Formal Reasoning Is Philip in the research division? Logical Equivalence

39. 2. Formal Modeling • Constraints: class invariants, pre-/post-conditions • Based on Set Theory, First Order Logic • Language: OCL, Z, Alloy • Apply formal reasoning for proof • Questions? • Next: Software Architecture

40. 3. Software Architecture and Design Patterns • Approaches to analyze the system • Top down: decomposition (layers of use case diagrams) • Bottom up: individual use cases • Software architecture: components and interface • Fulfill the functionality • Non-functional requirement: reusability, testability, maintainability (changes for algorithms, data, function), scalability, application-specific requirement (e.g., fault tolerance, uncertainty) • Decouple the dependencies between components

41. Software Architecture Patterns – Architecture Styles • Main-program-with-subroutine: centralized control, procedural calls, modules contain local and global data – Change data structure • Abstract-data-type: messages, information hiding - Change Functions • Implicit-invocation: decentralized control, react to signals, GUI - Non-determinism, bad testability • Pipes and filters: data flow, continuously process data - Storage overhead • Repository: independent computation unit, data center/compilers • Layered: hierarchy of layers, VM - limited visibility,

42. Software Architecture Patterns II • Architecture styles are not purely parallel, we can combine the types • There are other styles out there • Design patterns (for OO software): • Patterns for a smaller region of the code • There are patterns to use multiple design patterns together, e.g., MVC • Software architecture and model-based verification and testing - testability

43. A Typical Software Architecture Design Process • The data design • the architectural structure of the system • Context • Components • Analysis of alternative architectural styles to choose the one best suited to customer requirements and quality attributes • Elaboration of the architecture based on the selected architectural style - component diagram • Assess the architecture complexity: data and control

44. Answers for Previous Questions • Architecture: four types of components: computational, memory, manager (operations and states) and controller (control sequence of events) – MVC • KWIC architecture style comparison Interactions between modules are wired to the modules themselves, so the changing the overall processing algorithm or add new functionality may involve a large number of changes

45. 3. Software Architecture • There is no single answer, right or wrong, it is about tradeoff • Best way to evaluate is to build the system based on the architecture, and evaluate the system - expensive • Experience and analytical skills • Useful tools: architecture styles, design patterns, typical architecture design process, *architecture specification languages • Questions? • Next: Reverse Engineering and Model based verification and testing

46. 4. Reverse Engineering • Find models from source code • Class diagram • Sequence diagram • State diagram • Activity diagram • Use cases • Design patterns • Dependencies • Constraints • Control flow graph • Abstract syntax tree

47. Applications of Reverse Engineering • We can not document every details about a software • It is expensive to keep the document and model consistent, as code consistently changing • Most of the time we improve from given code – called software maintenance cost (50-90%) • Applications of reverse engineering: program comprehension, visualization, software reuse, refactoring, software verification, regression testing

48. Automatic Techniques for Reverse Engineering • Static analysis: scan source code for information • Class diagram, sequence diagram, design patterns • Dynamic analysis: program invariants and constraints • Potential problems: imprecise, coverage of the code • Tools available under Google

49. 5. Model-based Verification and Testing • Model checking: • Property (FSM) against Programs (PDA or FSM) • Static, counter example returned • Model based testing: • Effective on testing small systems • FSM is a common model to be used to test event-based systems • Automatic

50. Industrial Modeling - Andy • Models: structure, organize and visualize software artifacts, a big picture of the system with hidden complexity • Refactoring • Build from scratch • Challenges: no model is perfect, live model • Useful practice: layering, simulation