Having been a pioneer in computer-aided software engineering (GE, 1970) we quickly recognized the key difference between computer-aided mechanical, electrical, electronic and architectural engineering. Mechanical, electrical, electronic engineering benefited from computerization of the myriad properties and characteristics of materials as documented in the Chemical Rubber Tables Handbook, the RCA Integrated Circuits Handbook, etc.
In software there were few physical rules to be automated. For those writing device drivers the design of the hardware gave good guidance. Likewise for those writing control programs for microprocessors. But when it came to 'applications' the rules were much less clear. Making Knuth's 2,500 algorithms easily accessible and auditing code for GoTo's didn't make CASE useful. We became convinced that success in computer-aids for software engineering would not lie in physics-based models but in models of how designers think (or not) and how to facilitate higher order thinking (Janusian, Hegelian, etc.).
Having just finished the tenth annual Congress on the Future of Engineering Software, I can report that the scene has not changed all that much for MCAD, ECAD and ICCAD (although Intel is attempting to raise the level of language used in designing electronics). Most users and vendors are talking a lot about 3D and buzz things but not about "designing" as an intellectual phenomenon that may be amenable to computer-based augmentation. Emerging kinds of computer aids, e.g., genetic algorithms, are changing Architects (real ones doing buildings, etc. not 'enterprise' or 'software' ones) views that ACAD that can help them considerably. They sound more and more like systems engineering practitioners (which, of course, they are). Also, conversations with nanomachine researchers are surfacing similar concerns.
The main memes are computer-aided design of implicit systems and goal-pursuit systems. At the risk of irritating the cybernetics crowd I will say that we are facing third order systems while they are talking about second order systems and most of INCOSE is still talking about first order.
Models are essential. I think we all have demonstrated that specifications or other written descriptions ABOUT things, the interaction among things and the interactions among the interactions simply do not communicate.
Models, being emulations OF things, the interaction among things and the interactions among the interactions do communicate much more effectively and efficiently, provided that the models
a) address the truth, the whole truth and nothing but the truth,
b) include the minimal implicate order (addressing at least the thermodynamics, informatics, biomatics, teleonomics, social dynamics, economics and ecologics),
c) relevant emergence.
For second order or higher implicit systems a key factor is that any modeling language and tool must allow a model of the system to be one of the 'things' in the system and allow the model to affect the system's gradients, pattern of relationships and even content of 'things.' I have yet to see how SysML allows that.
A second key factor is that SE practitioners must have a much higher level language for modeling systems than is now the case with CORE, Cradle, etc. I have not seen any evidence regarding the relative productivity of practitioners with SysML vs. the existing languages/tools.