• No results found

Model Driven Testing Test Driven Modelling

Eating Your Own Dog Food

•  Let’s practice example/test-driven approach and learn the

principles of Test Driven Modeling by analyzing how to apply it to a small example system MagicTest.

•  MagicTest provides functionality for a teacher to create test

questions, group them into a test and assign it to the class that he is teaching. The students of that classes make

assessments of the test that are automatically evaluated.

Data Architecture

MagicUniversity Data Structures 51 name : String [1] cv : String [1] title : String Teacher start : date [1] end : date [1] Class name : String [1] year : Integer [1] Student title : String [1] code : String [1] description : String [1] credits : Integer [1] Course teacher 1 0..* subject 1 0..* 0..* prerequisites 0..* supervisor 1 0..* participants 1..* 0..*

Representative Data Sample

52 ü  A sample shows inconsistency with data structure

What Can We Do When Sample Violates Data Structure

1.  Fix data structure (sample is good, structure was wrong)

2.  Fix data sample (sample is wrong, structure was good)

§  Use invalid sample in testing for ensuring that such cases are not

allowed and handled appropriately in the system

MagicUniversity Data Structures 54 name : String [1] cv : String [1] title : String Teacher start : date [1] end : date [1] Class name : String [1] year : Integer [1] Student title : String [1] code : String [1] description : String [1] credits : Integer [1] Course teacher 1 0..* subject 1 0..* 0..* prerequisites 0..* supervisor 1 0..* participants 1..* 0..*

ü  Decision: Enable multiple supervisors 1..*

Representative Data Sample

55 ü  A sample is now in sync with data structure

Build Bigger Representative Samples

56 ü  A data designer should prepare it along with data structure

Modeling Interaction Scenario at Business Logic Layer

57 ü  Service operations are discovered based on scenarios

... «component» TestManagementService ... «component» TestAssessmentService +startTestAssessment() +submitAnswer() +finishTestAssessment() -evaluateTestAssessment() «component» TestAssessmentService +getQuestion() «component» TestManagementService

GUI Modeling in UML

GUI structure can be captured in UML class or composite structure diagrams

§  Modern modeling tools typically provide graphical rendering to enable

better presentation for users and GUI designers/analysts 1. Identify abstract GUI screens as UML classes

2. Build abstract GUI navigation schema as UML state machine

3. Build a story board GUI sample set as UML instance

specifications for validating GUI design with data samples

ü  Reuse data for GUI samples from data design (or vice versa)

GUI Navigation Schema

59 ü  How do I know it is suitable?

TestAssessmentWindow

StudentProfile UserDetails

TestResultsWindow Authorized

submit login info exit / LoginDialog OK GetTestResults EditData OK Finish at (timeout) TakeTest

all [session expired] [login incorrect] / show error msg

[password expired] / show change password fields [password not expired]

Login

Quit Start

Building GUI-Based Story Board Model (1)

60 ü  Validates both navigation schema and screen structures

Profile

Edit Data

Get Test Results

Logout Title: Status: Active: Breaks: Time Limit: Instructions: Magic Test 2009-05-25 - 2009-06-06 4 60 Active None Java Test (Advanced)

Magic Test

UML Test (Advanced) UML Test (Beginner)

Building GUI-Based Story Board Model (2)

61 ü  Validates both navigation schema and screen structures

MagicTest: UML Basics

Question 2 Question 3 ... Question 10 Question 1

How many standard diagram types does UML 2 define?

9

13

Pause Test < Back< Back Next > Finish Test

1

1

Building GUI-Based Story Board Model (3)

62 ü  Validates both navigation schema and screen structures

Evaluation

Start:

End: 2009-05-29

2009-05-28 Taken Breaks:

Time elapsed (in Minutes): 17 0

Grade:

You finished the test quite well. You've made only 2 mistakes. Keep it this way and you will finish other tests also.

Maybe even better if you concentrate a little bit more and take more time for thinking about the questions.

8

Lessons Learned

1.  Conceptual mistakes in design models can be found early by

validating it with example/test models

2.  Quality engineers need to be involved in collaborative

modeling together with developers

ü  Developers should produce essential example models

ü  Testers should take over with creating variations for a better

coverage of error-prone situations

3.  Example/test-driven modeling enables achieving a better

quality of model-driven software by testing design models early

Model-Driven Development Scenarios beyond Code Generation

1. Test Driven Modeling

64 2. Model Driven Requirements Management

3. Architecture Planning & Code Review Against Architecture 4. Model Driven System Documentation

Migrating from Document-Based to Model-Based Requirements In 2009, MagicDraw R&D decided to migrate from document-

driven to model-driven requirement engineering using SysML Advantages:

§  Much better teamwork and version management capabilities

§  More formal/structured descriptions of the requirements

§  Maintain the information about already implemented functionality

§  Traceability to the architecture and test cases

§  Eating your own dog food

After 6 years of applying model-based requirements

engineering, MagicDraw R&D team doesn’t want to go back to documents J

Modeling Requirements with SysML

•  SysML is a specialized UML profile targeted to system

engineering (as opposed to software engineering)

•  SysML defines elements for modeling requirements and their

relationships (including relationships to other artifacts such as test case or block)

66

Element Layout in Requirement Diagrams

Requirements Representation in Table Format

Modeling GUI Requirements

Lessons Learned

1.  Model-based requirements are much easier to manage and

evolve

2.  Modeling facilitates defining more structured and better

quality requirements

3.  Model-based approach enables better collaboration between

analysts who define requirements and quality engineers who define test cases verifying them

4.  Change is not easy – the idea was floating around for some

time but it was implemented only by a new product manager, who invested a lot of effort to make it happen

Model-Driven Development Scenarios beyond Code Generation

1. Test Driven Modeling

71 2. Model Driven Requirements Management

3. Architecture Planning & Code Review Against Architecture 4. Model Driven System Documentation

What Is the Most Popular Architecture Planning Tool?

Model-Code Engineering

Code Generation

§  Generate code from model files based on an existing template

Reverse

§  Retrieve system architecture from code and visualize it

§  Note #1: in complex systems developers need to fill in metafiles

§  Note #2: automated visualization is not easy

code generation reverse *.java, *.cpp, *.h, *.idl, *.cs, *.cil Code 73

Lessons Learned

1.  While code can reveal “as is” dependencies of

implementation components, it is not useful as a planning tool

2.  Visual modeling with UML is a good means for architecture

planning

3.  UML needs to be extended with a customer-specific profile,

which captures important context information such as interface levels, responsible teams, technologies, etc. 4.  It is necessary to map code to architecture in order to

perform code-architecture reviews

Model-Driven Development Scenarios beyond Code Generation

1. Test Driven Modeling

75 2. Model Driven Requirements Management

3. Architecture Planning & Code Review Against Architecture 4. Model Driven System Documentation

What is the Most Popular System Documentation Tool?

Generating Documents from Model

You can generate an HTML, Reach Text and Open Office

documents, XML or any other simple text report for a modeling project

MagicDraw Report Engine

Properties

Report as a Model Transformation •  Model 2 Model •  Model 2 Code •  Model 2 Document Concept Description #forrow ($class in $sorter.sort($Class, “name”)) $report.getIconFor($class) $class.name $report.getComment($class) #endrow Concept Description

Reader Information about library customer.

Request Document registering reader's wish to have a new title in a library.

Request Evaluation Librarian's decision whether to approve or deny reader's request.

Title Information about a book, journal or another kind of library inventory item. Library may contain multiple copies of the same title.

Lessons Learned

1.  Models may be a good choice as master source for system

documentation

2.  Model-driven system documentation facilitates a more

structured system documentation, a separation of style and content, and elimination of duplicated information in a

master source

3.  A good rule of thumb telling if it is a good idea to go for a

model-driven system documentation is if a major/bigger part of system documentation content is depicted in figures,

tables, and lists.

Challenges in MDD: Back to Basics

Model Refactoring Modeling Best Practices

Model Code Synchronization Model Traceability and Analysis

Executable Models Model Debugging

Large Scale Models

Modeling Teamwork Model Libraries Model Interchange Model Reviews Abstraction Level Modeling Patterns

Model Configuration and Version Management 80

Consider code generation

Related documents