1. no time to have a practical course for multiformalism systems what is a good design what rules are there for obtaining a good systems how about automatic guides? automatically tell the student that they are using an incorrect design pattern students never haven been confronted with design of a complex system. issues: * time, two hours is insufficient for the design of a complex system * motivation; students do not understand why they need multiformalism modeling the link between code and modeling is often lacking Can we provide software engineering students with pre-built components? So the students only have to focus on some key parts. It is probably not necessary to build a system to understand what a complex system is all about - You can provide a system and have students analyze the system - This requires students to understand MoC, otherwise they fail to have the proper insight Complex - at least three components from different domains (control, signal processing, communication, physical domains ...) - by size, by criticality, heterogeneity, distributed, multi-view, lots of actors, ... - collaborative 'good practices' * comments * heterogeneous team work * specifications (have students document the functionality that they will implement) - front-end and back-end specification, and then exchange for the implementation * Model-Based Design * requirements languages/engineering * validation (design tests from requirements), model coverage analysis The intent should not be to replace courses on SDF, FSM, bond graphs, etc., ... but they should also learn how to collaborate to achieve system design without knowing the details of each component. Can we raise the level of abstraction in developing courses? - provide formalisms at a higher level of abstraction (DEVS, Petri nets, SDF, ...) than code that has well defined operational semantics - then a transformation from DSL does not have to target the code level - next, require students to build a DSL and write a simulator for it (which requires a high-level formalism with operational semantics) - give students examples from many different domains to address the multi-domain complexity MDE is not sufficiently well developed (no pun) to be moved into undergrad coursework (like OO is) It is important to have students develop working systems (e.g., Android apps, online web-site video library) - this can be achieved by UML based classes - but, using UML is too close to the solution domain (Java), students find it disturbing that they cannot simply use Java Three legacy/classis formalisms are: Causal Block Diagrams, Petri nets, Statecharts Is the requirements engineering sufficiently addressed in MDE? - sequence diagrams capture requirements - a Statechart design is built - sequence diagrams are translated to automata that can then check behaviour traces produced by simulating the Statechart design - similarly with a Java/Python implementation (Modelling) languages for specification and requirements and their utility should receive more attention Ask students: Is it still established Computer Science what we are doing? Is it possible and useful to establish a repository of lecture notes, class slides, demos (A/V) assignments, problems, tests, seminal papers, ... to reuse? - Can we put everything in ReMODD? No, because it is for models (in PDF format) only First question to ask is: what are the competencies to instill in students What is the role of tools? - UML tools are not very helpful: only drawing tools or only partial code generation - UML tools can be used to capture constraints quite well, still requires a complex code base to check the well-formedness of constraints - It may also lead to abuse of class time where a tool or technology is taught and not the concepts (UML vs. OO concepts) - limit the scope of UML (only class diagrams, statecharts, ...) How do students find what minimizes accidental comlexity? By exaggerated example. Large example. For example, give students a large legacy code base and ask them to reengineer it (e.g., make a small change) Is it essential for students to first fail to see the importance of collaborative structure? Fuel level indicator, cruise control on 1 ECU, cruise control on 2 ECUs as practical projects Streamline the curriculum, coordinate what is being taught in different courses - Regroup courses in order to have different engineering domains - Use legacy software that is available (browser, OS, ...) - Courses that are very focused (real time systems, embedded systems) and there are more diverged courses You can add model driven techniques in all of these This prevents losing valuable time to convey basic concepts on modeling Class length ... Teaching best practices: - can you change pace, for example show a video or a challenge (a black slide) after about 30 minutes - more prep work? difficult to enforce, plus there are limits on total time spent on a course (about 10h/wk per course; 1 credit = 30 hours of combined effort, e.g., typical course in Belgium is 6 credits) ------------------------------------------------------ Conclusions: 1. ACTION ITEM: to spec out a repository (e.g., this can be initiated by starting a wiki page) - could be starting point for prep work 2. To experiment with many formalisms, there is merit in providing a high-level executable formalism (such as Statecharts) to shorten the distance to implementation 3. It is valuable to provide examples from different domains to provide students with a feel for the intricacies of each domain 4. 'Industrial' complexity can be introduced by either (i) selecting an existing code base and require analysis/re-engineering and (ii) componentize a complex system and have students construct a system from the parts 5. Course design - modularization of course material - streamline and regroup with other courses