
14303cb728c6e6ea1e28606d21327ed9.ppt
- Количество слайдов: 28
Auto. DEVS: A Methodology for Automating Systems Development By Manuel C. Salas Advisor: Dr. Bernard P. Zeigler University of Arizona 2008
Agenda • Motivation • Objectives • Background • Contributions • Auto. DEVS to Autonomous Road Survey (DEMO) • Conclusions • Future Work
Motivation • Improve systems development to reduce human effort, time constraints, and production costs. • Unify every step of development and integration from business modeling to application deployment. • Overcome the "incoherence problem" between different stages of the development process. • Introduce automation in the development of systems to increase productivity and hide complexity.
Objectives • To provide a methodology to increase productivity by automating the life cycle process of a system. • To exploit model continuity to reduce incoherence between development phases. • To help developers identify and focus on the most critical parts of the system. • To provide a methodology that allows developers to create high performance distributed real-time systems that are extensible flexible, interoperable, reusable, and reliable.
Background • Many Organizations make use of the Systems Development Life Cycle (SDLC) methodologies. Methodology Pros Cons Waterfall 1. Process and complete phases one at a time. 2. Documentation produced at every stage 3. Testing is inherent to every phase. V-Shaped Incremental Spiral Synchronize and Build and Fix Stabilize 1. Cost effective 1. Flexible: allows 1. Test plans early on 1. Generates 1. High amount for small changing business during the life cycle. working SW of risk analysis. projects. requirements. 2. Works well for small quickly and early. 2. Good for large 2. More 2. Work is done in projects. 2. More flexible. projects. customer teams in parallel. 3. Each phase has 3. Easier to test 3. Software is interaction. 3. Each team has specific deliverables. and debug. produced earlier. design freedom. 1. Risk analysis 1. All requirements 1. Each phase of an requires highly 1. Relies heavily need to be explicitly iteration is rigid. specific expertise. the expertise 1. Money and on defined. 1. No early prototypes 2. Problems due to 2. Project's of members. creative freedom 2. Working versions are produced. not completed can do a lot to success is highly 2. No are ready is late 2. Little flexibility and requirements may dependent on documentation boost the team stages. adjusting scope. arise. the risk analysis. is provided. productivity.
Background (Cont) • Alternatives to the SDLC methodologies. Methodology Joint Applications Design Pros 1. Allows end users to participate in the elaboration of requirements. 2. Reduces ambiguity produced in the elaboration phase. 3. Brings domain expert ideas together. Cons 1. Big groups could become expensive and cumbersome. 2. Non-prepared sessions could waste valuable professionals time. Rapid Application Development 1. Prototypes allow emulating and building working systems. 2. Ability to rapidly change system design. 1. Can lead to a succession of prototypes that never culminate in a satisfactory production application. 2. Potential for inconsistent designs. 3. Difficulty model reuse.
Background (Cont) • M & S Development Tools: Rational Rose Real-Time Pros: -Unifies the project team by providing a set of integrated tools. -Automatic code generation to reduce development risk. -UML model debugger ------------------ Cons: -Focuses on design not on requirements. -Doesn’t support concurrency in Statechart Diagrams. -Doesn’t support Activity Diagrams, i. e. simulation, verification, test case gen.
Contributions • Introduce Auto. DEVS as a methodology to automate the development of complex, distributed, real-systems. • Demonstrate that this methodology overcomes the “incoherence problem” between different stages of design thru “model continuity”. • Develop a distributed simulation-based system for an autonomous robotic survey to show the powers of Auto. DEVS. • Provide a solution to automate the constant road supervision needed to improve productivity and reduce human efforts in a mine.
Auto. DEVS • Auto. DEVS is based on the Discrete Event Specification System (DEVS) and SES formalism. • Provides a Methodology to: • Automate the development of DEVSJAVA models to increase productivity and focus on the real aspects of the system. • Exploit model continuity to reduce “incoherence” between development phases by following the “Modeling-Simulation. Execution approach. • Go from a “spreadsheet” containing requirements specifications to a real-time executing system. • Allow alternative models to be selected, generated and evaluated.
Auto. DEVS GUI
Auto. DEVS Methodolgy Define Requirements Capture Spreadsheet Data Simulate Manual Generate DEVS Models (structure) Update PES Automatic Extract Structural Aspects Extract Behavioral Aspects Generate FD-DEVS Models (behavior) Verify Created Models Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) ID Requirement. Text Define Requirements Extract Structural Aspects Extract Behavioral Aspects Manual Capture shall be Generators FD-DEVS Spreadsheet Gps. Data. Generator, Surface. Data. Generator, Models and Data (behavior) 1 Wireless. Data. Generator. All the Generators components shall be started by the 2 Generators. All the Generators components shall be stopped by the 3 Generators. Generate DEVS Models (structure) Update PES Automatic Verify The Generator shall Created send data Simulate 4 every 1 second. Models Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) Define Requirements Extract Structural Aspects Extract Behavioral Aspects Manual Capture Spreadsheet Data Generate FD-DEVS Models (behavior) Generate DEVS Models (structure) Update PES Automatic SESMicro. Representation Automatic 1. From the Gen. Component perspective, Generators are made of more than one Generator!Verify 2. A Generator can be Gps. Data, Simulate Created Surface. Data, or Wireless. Data in class! Models 3. From the Component perspective, Generator sends Gen. Data to Generators! Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) Define Requirements Extract Structural Aspects Extract Behavioral Aspects Manual Generate FD-DEVS Models (structure) FDDEVSRepresentation Generate DEVS Models (behavior) Capture Spreadsheet Data 1. Generator: to start passivate in passive! Automatic 2. Generator: when in phase passive and receive Start then Verify go to active! Simulate Created 3. Generator: when in active and receive Stop then go. Models to passive! 4. Generator: hold in active for time 1 then output Gen. Data and go to active! Update PES Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) Define Requirements Capture Spreadsheet Data Simulate Manual Generate DEVS Models (structure) Update PES Automatic Extract Structural Aspects Extract Behavioral Aspects Generate FD-DEVS Models (behavior) Verify Created Models Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) Define Requirements Capture Spreadsheet Data Simulate Manual Generate DEVS Models (structure) Update PES Automatic Extract Structural Aspects Extract Behavioral Aspects Generate FD-DEVS Models (behavior) Verify Created Models Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) Define Requirements Capture Spreadsheet Data Simulate Manual Generate DEVS Models (structure) Update PES Automatic Extract Structural Aspects Extract Behavioral Aspects Generate FD-DEVS Models (behavior) Verify Created Models Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) Define Requirements Capture Spreadsheet Data Simulate Manual Generate DEVS Models (structure) Update PES Automatic Extract Structural Aspects Extract Behavioral Aspects Generate FD-DEVS Models (behavior) Verify Created Models Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) Define Requirements Capture Spreadsheet Data Simulate Manual Generate DEVS Models (structure) Update PES Automatic Extract Structural Aspects Extract Behavioral Aspects Generate FD-DEVS Models (behavior) Verify Created Models Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) Define Requirements Capture Spreadsheet Data Simulate Manual Generate DEVS Models (structure) Update PES Automatic Extract Structural Aspects Extract Behavioral Aspects Generate FD-DEVS Models (behavior) Verify Created Models Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodology (Cont) IDE: Define Requirements Capture Spreadsheet Data Structural Aspects Simulate Manual Generate DEVS Models (structure) Update PES Automatic FD-DEVS Extract Behavioral SESBuilder Aspects Generate FD-DEVS Models (behavior) Verify Created Models Create Test Models Transform PES to DEVSJAVA
Auto. DEVS Methodolgy Define Requirements Capture Spreadsheet Data Simulate Manual FD-DEVS Models (behavior) Generate DEVS Models (structure) Update PES Automatic Extract Structural Aspects Extract Behavioral Aspects Generate Sim. View: Verify Created Models DEVS/SOA: Create Test Models Transform PES to DEVSJAVA
Auto. DEVS to Autonomous Road Survey
Auto. DEVS to ARS (Cont) DEMO!
Conclusions • Auto. DEVS provides a methodology to automate systems development. • Auto. DEVS methodology provides a natural and effective way to model distributed real-time systems’ structure, behavior and timeliness. • Auto. DEVS methodology raises the importance of simulation to analyze and predict results before deployment. • Auto. DEVS allows developers to focus more on the core of the system.
Conclusions • Auto. DEVS combines DEVS and SES formalisms to allow the creation of structured information hierarchically and efficiently. • Autonomous. Road. Survey has been developed to show Auto. DEVS overcomes “incoherence problem”. • Auto. DEVS and ARS motivate the industry to exploit automated systems to improve productivity and reduce human efforts. • ARS provides a solution to automate the supervision of roads within a mine.
Future Work • Auto. DEVS: - Integrate with FD-DEVS, SESBuilder and DEVS/SOA. - Provide more automation for the model’s behavioral aspects. - Allow updates without compromising current models. • ARS: - Improve algorithms to find roads. - Extend Runner survey information, i. e. “blind areas”, quality of surface, materials found. - Minimize downtime of operation by introducing more Runners to the system. - Automate the execution of Runners to periodically update the Central System and Supervisors.
Questions ? manuel. salasc@gmail. com