Usability: Goal: What is usability? Dictionaries: Merriam-Webster: * Capable of being useful, practical usable -> fit for a certain intent -> does it have value? SO/IEC 25010: USABILITY: degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. Subcharacteristics: 1) Appropriateness recognizability: degree to which users can recognize whether a product or system is appropriate for their needs 2) Learnability: degree to which a product or system can be used by specified users to achieve specified goals of learning to use the product or system with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use 3) Operability: degree to which a product or system has attributes that make it easy to operate and control 4) User error protection: degree to which a system protects users against making errors 5) User interface aesthetics: degree to which a user interface enables pleasing and satisfying interaction for the user 6) Accessibility: degree to which a product or system can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use Reference: ISO/IEC 25010:2011. Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models However! Something is wrong in industry! They should have usable tools but why is it not? Perceived problem with usability? Where do things go wrong? * Are they happy to learn about these things? => for example LTL difficult to learn/use. Generate LTL by for example PromoBox, define it using DSL as well (http://msdl.cs.mcgill.ca/people/bart/publ/doc16). * complexity? Group in Finland: modelling and Simulation for the masses. Village change road -> consultancy firm did optimal study, people objected and made their own model together with what-if analysis. Tools can remove accidental complexity but not the inherent complexity. * Take from the embedded systems world? * simulation Simulink with runner up Modelica for plant * simulink misses some things: not model basic software, software architecture, etc. * How to represent these concerns (except for Capella) there is no DSL there. Only SystemC <> UML , SysML * MARTE is not fitting the bill, * papyrus eclipse and code generation, mix and merge with programming environment, papyrus does not give hooks for this. * Tool evolution: Tools grow as modelling and sim tool not as a synthesis tool => should we take a step back? * Possible solution: MPM . integrate different tools, for example co-simulation. What is the minimal approach to combine different models together? * Language issues: SysML terrible support for instances: Engineers think in terms of instances not types, etc. Instances come first for embedded engineers, not the typing where you loose info on network and topology. Some of the problems are easily fixed because are not. Academia does not get anything out of it; IBM gave up on it. Mathworks: simulation first; Papyrus too stretched. But if we do not solve it, we will not have impact. Match how people use a tool and the tool itself. We should reason in their terms, sysml use it as instance oriented. * We also need to talk about processes. * Computer Science vs the world: Java for embedded, will this solve things? No! Bias of computer scientists with object orientation need to be rethought. State automatons for example is not OO. Could be generated to OO code but also to tables, etc. * Need in industry to look at semantics. (Simulink code generation example) Reuse language infrastructure; but it is a different language! Semantics need to be defined. But is very pragmatic! Currently, we are loosing the interest of industry, we are not giving them what they need. Failed experiments like sysML, MARTE, .. * What about language-engineering? Introduce napkin domain specific languages. Work from there and make it happen for the industry. There are clear gaps in modelling scenarios. F.e. building automation HVAC. complexity, timing, certification. Simulink for control of chiller, cold water flow, etc. But simulink is abstract control model, serial networks, etc. The napkin is not big enough! No system level languages that can handle this. What are we going to sell these companies? Large scale! Should the academics to this? Industry do not have a starting point: they do have the system in reality! What is the answer that we can give: MBSE cannot give you an answer? This is also tool builder problems. How do we deal with this. Tool builders rewards is really low. Academics stick to little prototype because it more rewarding than really going all the way. * Think before what usability (library, starting points, etc.) Some companies oversell, and we loose credibility * Language subsets: How do customise, modify the subset of sysml, uml ,etc. that is really useful for industry (per domain?) stereotypes, dsml, etc. Standards for SMEs, what is the minimal set of standards that are needed to create? Again tailor to the needs of a company. * Is it fundamental? SysML is failing as a root. But mechanical engineers use it quite often. For example the missing link was parametric diagrams. As a terminology it standardises as well … However, it does not, for example port (SysML) , how does this add to the simulink port, etc. It creates confusion. Fuzzy semantics. * But… Systems theory -> possible signals, possible abstractions, etc. We threw that away and we are reinventing the wheel. Computer Science problem we can solve. Domain experts need to say what they need in a language. We can describe structure, but in CPS we cannot describe the semantics properly. Novel ways to combine languages. * Should we start from scratch or should we modify and extend? Mathworks extended scope to code gen, deployment, etc. but rather conservative. If you want to extend/.. you are on your own. UML/SysML got everything wrong at all levels, but it is highly fixable. Modelica other way -> from physics to control. Can we define a better version of MARTE? Could we have better tool support? There have been lots of dead ends (from an industrial point of view) ISO IEC, etc. standards * learnability * efficiency * memorability * errors and severity * satisfaction Ten main usability principles: usability of tools vs language and formalism => it is not the language and the formalism but the representation that really matters. tables are really what they like! Why do they really like tables? Is it because it is copyable, it matches the underlying semantics, they grew up with it, etc. Laziness is human nature. The code, the powerpoint and the picture. Simulink is the tool for control engineers. If the group is computer scientists, but if there are systems people, they will see the value of something more than tables. CPS: plant modellers, control engineers, software engineers, etc. Semantic issues come to the foreground. Lots of connected excel worksheets, build on comfort zones. Inherent paradigm to them, once I figure that out I can start using it. There is some easy semantic that makes sense. Command line history for example, what does that mean. Is it the same or is it a list, etc. You need to figure that out. You need to tell a story. For example, statecharts choices. The why is very important. The pattern of a tool is needed. Explaining the process. include other people like cognitive psychologists. Include the end-user, observe the end-user and feed-back into the tool design. Data-mining. Set of simulation tools, usability depends on the background of the end-user. Very subjective depending on the background. Performance is also needed. No debugging, large models, etc. Design for it. outcome between different surveys do diverge. Tools are usable for only one domain, when combined with other domains all bets are off. Still essential complexity remains. Usability, how quickly can I get into it? getting from I am new to I am a expert user. Git for example, horrible in the beginning Process from beginner to end is not well documented. Stories are needed. Guiding from basic principle to complex. How to teach best practices. Industrial context: language could be very efficient but it could be disruptive on process or design, etc. It will not be used in this case. Example from industry: simple CBSE tool changed to complex and expressive tool; the tool user actually used it in an other way (portion of the language that was not made for it, no code gen anymore, etc.) Compatibility to the process and company. Sometimes also the cheap way, buy the tool not the consultancy. Transition could have been smoother. Engineer are like fish climbing trees now. Processes and workflows are not explicit. Is that why it is hard to move to another paradigm/tool/process/etc. What we produce is usually not usable for industry. We should maybe take that more into account when we do research. Eclipse has problems. But, it is a platform, you need to customise. However, it is the only thing that is actually there. Bottom up: start from a couple of cases and everybody applies to it. Everything is connected, the processes, the tools, etc. We do not see usability as problem, but as a last thing. Start from usability. Why use people excel a lot in all domains? Comfort zone, people are lazy and we should make tools that are modular in user experience. Different interfaces depending on the person (automaton, table) Not only a matter of GUI.