%0 Conference Paper %1 doyle05 %A Doyle, Laurence %A Pennotti, Michael %B Conference on Systems Engineering Research %C Hoboken, NJ, USA %D 2005 %K systems hci complexity uml %T Systems Engineering Experience with UML on a Complex System %U http://www.stevens-tech.edu/cser/authors/20.pdf %X Experience using UML for systems engineering on a complex system is described. The system was an experimental situation awareness system for small military units such as a hostage rescue mission. This experience provides insight into the use of process-oriented and object-oriented models. Real projects that experiment with methodology are an important source of information that cannot be duplicated on a contrived problem. Most of the functional requirements in this system involved software but there was also unique hardware. Use case specifications were derived directly from a very high level specification from the customer without any intervening artifact. Subsystem interaction diagrams were developed from the use case specifications. The use of UML as a systems design tool had the advantage that it greatly facilitated the transition into software development. While this approach was largely successful, there were some cases when the object-oriented model did not fit the problem. In addition to their role in task automation, models provide a mental representation that helps us solve engineering problems. Object-oriented and process-oriented models provide two different representations. Because this project attempted to apply an object-oriented model so broadly, it was a de facto experiment in the use of such models. An examination of the cases where a process-oriented model fit better than an object-oriented model provides insight into the differences between these two views. The experience on this project supports idea that each view is a better cognitive fit to a different set of problems.

@inproceedings{doyle05, abstract = {Experience using UML for systems engineering on a complex system is described. The system was an experimental situation awareness system for small military units such as a hostage rescue mission. This experience provides insight into the use of process-oriented and object-oriented models. Real projects that experiment with methodology are an important source of information that cannot be duplicated on a contrived problem. Most of the functional requirements in this system involved software but there was also unique hardware. Use case specifications were derived directly from a very high level specification from the customer without any intervening artifact. Subsystem interaction diagrams were developed from the use case specifications. The use of UML as a systems design tool had the advantage that it greatly facilitated the transition into software development. While this approach was largely successful, there were some cases when the object-oriented model did not fit the problem. In addition to their role in task automation, models provide a mental representation that helps us solve engineering problems. Object-oriented and process-oriented models provide two different representations. Because this project attempted to apply an object-oriented model so broadly, it was a de facto experiment in the use of such models. An examination of the cases where a process-oriented model fit better than an object-oriented model provides insight into the differences between these two views. The experience on this project supports idea that each view is a better cognitive fit to a different set of problems.}, added-at = {2006-09-09T19:26:51.000+0200}, address = {Hoboken, NJ, USA}, author = {Doyle, Laurence and Pennotti, Michael}, biburl = {https://www.bibsonomy.org/bibtex/2d6590a0f4afa7468daa44559897e7784/neilernst}, booktitle = {Conference on Systems Engineering Research}, citeulike-article-id = {378444}, comment = {- pretty useful intro to the Systems Eng community. Short on results, more anecdotal. - took systems programmers (functional/imperative) and made them use UML and complained it was too weird (no surprise there) - some references on combining software and systems engineering, but mainly vendor-driven and UML focused. - their problems with UML tend to arise because they haven't a)got experienced developers and b) they are using OOP on a trivial system - benefits of OOP tend to be seen in maintenance, evolution, etc.}, description = {sdasda}, interhash = {7dd059ca178a1d36b231f49469ec7380}, intrahash = {d6590a0f4afa7468daa44559897e7784}, keywords = {systems hci complexity uml}, month = {March}, organization = {INCOSE}, priority = {0}, timestamp = {2006-09-09T19:26:51.000+0200}, title = {Systems Engineering Experience with UML on a Complex System}, url = {http://www.stevens-tech.edu/cser/authors/20.pdf}, year = 2005 }