Comments (3)
Maybe just keep the current name and avoid more work?
I would stick to the current naming too, simply to avoid work as well. However, as soon as we get to the paper, we have to pick a name.
Who decides which name we will use?
I would suggest to do this along with @sulzmann next time the three of us meet.
from gui-state-machine-api.
I think I still like "SUT model" or "GUI model", respectively, "sut-model" or "gui-model" for the artifact ID. It appears to be compliant with Stachowiak's model theory:
- Mapping: Models are always models of something, i.e. mappings from, representations of natural or artificial originals, that can be models themselves.
Our mapping is GUI paths of the SUT.
- Reduction: Models in general capture not all attributes of the original represented by them, but rather only those seeming relevant to their model creators and/ or model users.
We only capture those GUI paths we know …
- Pragmatism: Models are not uniquely assigned to their originals per se. They fulfill their replacement function a) for particular – cognitive and/ or acting, model using subjects, b) within particular time intervals and c) restricted to particular mental or actual operations.
… because that's enough.
from gui-state-machine-api.
I think I still like "SUT model" or "GUI model", respectively, "sut-model" or "gui-model" for the artifact ID. It appears to be compliant with Stachowiak's model theory:
- Mapping: Models are always models of something, i.e. mappings from, representations of natural or artificial originals, that can be models themselves.
Our mapping is GUI paths of the SUT.
- Reduction: Models in general capture not all attributes of the original represented by them, but rather only those seeming relevant to their model creators and/ or model users.
We only capture those GUI paths we know …
- Pragmatism: Models are not uniquely assigned to their originals per se. They fulfill their replacement function a) for particular – cognitive and/ or acting, model using subjects, b) within particular time intervals and c) restricted to particular mental or actual operations.
… because that's enough.
SUT model or state graph would be fine for me as was state machine.
Maybe the argument about incomplete models was that you do capture all attributes in a model but all instances of the attributes you capture?
Who decides which name we will use?
Maybe just keep the current name and avoid more work?
edit:
From the EXSYST paper:
The UI model represents our knowledge of the possible application behavior. This information is contained in a state machine that we create from observing actual executions of the application under test.
so they mention state machine, UI model and I read somewhere something like an EFG (Event Flow Graph)?
MS told me in the beginning its like a state machine, later he said a state machine must be complete.
from gui-state-machine-api.
Related Issues (20)
- Replace Descriptors with SutState HOT 1
- Allow passing SutState directly to executeAction(...) HOT 1
- Replace trait-implementing objects with classes HOT 1
- Disable/remove travis-ci.org build HOT 1
- Remove field neverExploredActions
- Concurrency support HOT 2
- Add trait for Serialization
- Update recheck and discard old dependencies
- Use Neo4J backend HOT 7
- Replace automatic ID with a given name
- Create a new release with the changes of #17, #21 and #24 HOT 1
- Get action that lead to one state. HOT 3
- Allow specifying the location to load/save state machines
- Identify SutStates and Actions by hash codes
- Remove unnecessary helper methods
- Adding attributes to SutStateIdentifier HOT 1
- Ignore retestId when generating checksum from serializables SutState and Action HOT 3
- Define a concept how to store types of never explored actions HOT 2
- Define scalafmt rules to match the Java code style of other retest projects
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gui-state-machine-api.