1 / 52

Lecture 19 Review

Lecture 19 Review. Wei Le. 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

velvet
Download Presentation

Lecture 19 Review

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

More Related