a framework for developing conceptual models of the mission space ...

More documents

Recommendations

Info

1.2. The Problem Conceptual models are usually underused in simulation development. Borah states in [7] that “the community of engineers engaged in simulation development need to step back and develop a clear understanding of the role of conceptual modeling in the simulation development process. Once the role of conceptual modeling is established then the requisite elements of a sound conceptual model can be defined as a part of ongoing discussions of sound simulation development practices”. To understand the situation, we need to ask the following question; what is the role of a conceptual model in simulation development? Zeigler states that one of the important aspects in modeling is communication [75]. He states that “the long-term contribution of any modeling effort lies in the benefits it affords, either by direct use or by guidance for further development, to science and industry”. Accordingly the model should help modelers, domain experts and the users of the model a clear understanding of the context and to visualize it within the framework of their prior conceptions about how things work. This is what we should expect from a conceptual model in the simulation development life cycle. Most of the ambiguity concerning a conceptual model is caused by the employment of many different disciplines in a simulation development project such as modeling and simulation, systems engineering and software engineering. These disciplines interpret a conceptual model from different points of views, which result in different expectations. What we need is a high-level approach to conceptual modeling which covers the requirements of all these related disciplines and defines the interactions among them. An informal conceptual model would be sufficient in the early simulation development phases, which should then be elaborated and more formally represented to be useful for systems and software developers. The initial conceptual model could be effectively used for validation purposes so that it can form a sound basis for a detailed conceptual model. Although many of the researchers acknowledge the importance of conceptual modeling in the simulation development lifecycle, there are very few studies and publications on the conceptual model development methods and notations. Most of the time the information required for developing a mission space conceptual model is written in free text by the subject matter experts. Pace [48] describes four approaches for documenting the conceptual models; which are ad hoc method, design accommodation, CMMS paradigm, and scientific paper approach. All of these approaches utilize free text notation for representing the conceptual models. The free text notation causes ambiguous and recurrent definitions, is difficult to interpret by machines, and does not provide adequate guidance to the modeler [66]. There are also more formal notations used for conceptual modeling, such as UML (Unified Modeling Language), BPMN (Business Process Modeling Notation) and IDEF1X [58], [10] and [23]. Each of these methods provides different approaches; UML follows a more object-oriented approach, BPMN is more 7
process-oriented, IDEF1X is a more data-oriented approach. However, these are general modeling notations which do not necessarily address the specific requirements of the mission space conceptual modeling. It should be noted that although some tools and techniques can be provided and successfully employed for effective conceptual modeling, the usefulness of a conceptual model is related with the skills and experience of the modeler in charge. As Shannon has written in [62], “The art of modeling can be mastered by those who possess the necessary skills of ingenuity, insight, and resourcefulness, as well as an extensive exposure to the systems and physical phenomena they are trying to model. There is no hard and fast rule about how the problem is originally formulated, i.e., how one looks at it in the first place. There are no magic formulas for deciding what should be included in the model in the form of variables and parameters, descriptive relationships and constraints, and criterion for judgment of effectiveness. Remember that nobody solves the problem; rather, everybody solves the model that he has constructed of the problem. This concept helps to keep the model and the art of modeling in the proper perspective.” As a result of the essence of the “art of modeling”, there would not be a single conceptual model developed in a one shot process for any simulation system. Conceptual models are “living” documents that are iteratively developed, and evolve as required by the simulation development process from an informal description to a more formal description to communicate between the diverse groups (sponsors/users, modelers, systems engineers, and software designers) participating in a simulation development effort. Since conceptual modeling is mostly related with the problem definition phase, late removal of any defect injected at this phase will cost too much effort and time sometimes even leading to unrecoverable situations. Conceptual models can form a basis for verification and early validation activities that may dramatically decrease the number of defects injected at the early phases of the simulation development life cycle. The problem statement inspiring this thesis can be summarized as follows: There is not a widely accepted conceptual modeling approach that includes a notation capable of representing a wide range of simulation systems, providing an effective bridge between the simulation requirements and simulation design and forming a basis for early validation of the simulation systems. 1.3. The Solution Approach In order to resolve the defined problems in the previous section, we propose an approach for developing conceptual models of the mission space. Our approach includes 3 major components, which are, the conceptual modeling notation, process definition and a software tool that supports the notation and the process as shown in Figure 3. 8
Page 1 and 2: A FRAMEWORK FOR DEVELOPING CONCEPTU
Page 3 and 4: I hereby declare that all informati
Page 5 and 6: ÖZ SİMÜLASYON SİSTEMLERİ GÖRE
Page 7 and 8: ACKNOWLEDGMENTS This thesis is a re
Page 9 and 10: 2.4. Summary ......................
Page 11 and 12: LIST OF TABLES Table 1: Conceptual
Page 13 and 14: Figure 30: Sample Task Flow Diagram
Page 15 and 16: IEEE Institute of Electrical and El
Page 17 and 18: Zeigler describes the basic element
Page 19 and 20: Balci [4] states that the early pha
Page 21: DMSO (Defense Modeling and Simulati
Page 25 and 26: as shown in Figure 4. Mission Space
Page 27 and 28: Chapter 4 describes the modeling no
Page 29 and 30: constraints related with the domain
Page 31 and 32: are examples to these notations. UM
Page 33 and 34: with the development of the federat
Page 35 and 36: federation scenario, the geographic
Page 37 and 38: SEDEP adds a step at the start of t
Page 39 and 40: For each type of relation between S
Page 41 and 42: acquisition and knowledge elicitati
Page 43 and 44: Attribute is similar to the attribu
Page 45 and 46: 2.3.2. Conceptual Model Figure 8: B
Page 47 and 48: interaction classes include HLA par
Page 49 and 50: CHAPTER 3 3. KAMA APPROACH This cha
Page 51 and 52: the mission space. The diagrams as
Page 53 and 54: for modeling software systems. Alth
Page 55 and 56: Figure 9: Conceptual Modeling Proce
Page 57 and 58: entity ontology. We do not intend t
Page 59 and 60: The user can create, store, delete
Page 61 and 62: Figure 10: High Level Use Case Diag
Page 63 and 64: includes manager packages which pro
Page 65 and 66: package includes common metamodel e
Page 67 and 68: metamodel of that package. The Foun
Page 69 and 70: PseudoState InitialState Dependency
Page 71 and 72: feature and structural feature. A b
Page 73 and 74:
4.3. Mission Space Package 4.3.1. O
Page 75 and 76:
Constraints [C-MS-a-1] A mission sh
Page 77 and 78:
Task Flow or Mission Space diagrams
Page 79 and 80:
f. WorkProduct A work product repre
Page 81 and 82:
h. SynchronizationPoint A synchroni
Page 83 and 84:
k. ResponsibleFor A responsible for
Page 85 and 86:
[C-MS-m-2] An extends relation cann
Page 87 and 88:
[C-MS-o-1] An achieves relation has
Page 89 and 90:
Attributes • No additional attrib
Page 91 and 92:
Extending_Mission extends Mission1
Page 93 and 94:
model is represented by 4 types of
Page 95 and 96:
Notation c. KAMAAttribute An actor
Page 97 and 98:
f. KAMAAssociation A generalization
Page 99 and 100:
Generalizations • Association fro
Page 101 and 102:
22. But the reader of the conceptua
Page 103 and 104:
as multiple diagrams in order to re
Page 105 and 106:
4.5.3. Class Descriptions a. KAMASt
Page 107 and 108:
Constraints [C-SM-c-1] A KAMAInitia
Page 109 and 110:
Notation 4.5.4. Diagrams a. Entity
Page 111 and 112:
CHAPTER 4 5. APPLICATION OF THE NOT
Page 113 and 114:
included implementation details. We
Page 115 and 116:
1) Identify the high-level strategi
Page 117 and 118:
d. Process and Outputs The process
Page 119 and 120:
. Are KAMA models straightforward?
Page 121 and 122:
cover, the rate of detect/identify/
Page 123 and 124:
necessarily have to produce the wor
Page 125 and 126:
Figure 33: Sample Command Hierarchy
Page 127 and 128:
Figure 35: Sample Entity State Diag
Page 129 and 130:
Conceptual Model Element (in the so
Page 131 and 132:
As we completed the first case stud
Page 133 and 134:
The conceptual model will be develo
Page 135 and 136:
Model Use: 3) Validity: Are KAMA mo
Page 137 and 138:
defined. The team came up with 157
Page 139 and 140:
Figure 38: Sample Entity Ontology D
Page 141 and 142:
equirements. Unless we had performe
Page 143 and 144:
are powerful tools to represent eve
Page 145 and 146:
specification contains the abstract
Page 147 and 148:
developing conceptual models using
Page 149 and 150:
Moreover, the framework offered all
Page 151 and 152:
observations showed that both the s
Page 153 and 154:
performing context-sensitive search
Page 155 and 156:
REFERENCES 1. Akkök, N., “Toward
Page 157 and 158:
31. Law, A.M. & Kelton, W.D. (1999)
Page 159 and 160:
67. Tanriover, O. (2008) Inspection
show all

a framework for developing conceptual models of the mission space ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?