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

More documents

Recommendations

Info

Since the KAMA framework does not aim to provide an executable model, this suggestion was rejected and proposed as a future work. • The third study used the KAMA notation as is for developing the conceptual model of the mission space and extended the KAMA notation and process definition to represent the simulation space conceptual model. Another experimental study was conducted to examine the cognitive aspects of the graphical notation used to represent the KAMA conceptual models [29]. The study used two groups of subjects for the experiment, one group of engineers and another group of domain experts. The problem resolution processes of these groups were examined by using the diagrams developed in KAMA notation. The groups were asked to find the errors that have been seeded in the diagrams. Both groups had difficulty in understanding computationally complex diagrams that included nested decision flows. Domain engineers found crowded diagrams difficult to understand. Both groups followed a linear flow and did not perform parallel controls, inter-diagram checks and return flows. None of the subjects used concurrent search techniques. The subjects suggested using different symbols or colors for representing the relations and the model elements. The following changes to the notation were proposed as a result of the first case study. These issues were based on our participation in the modeling process. Command hierarchy diagrams should include additional relation types in order to effectively represent the real life situations. These relation types, which already existed in the entity relationships diagrams, are generalization, association and aggregation. The organization structure diagrams included the entity model elements, which were reported to increase the complexity of the model during the modeling process. The entity model element was removed from this diagram type. After the first iteration of the conceptual model development process, the modelers felt necessary to represent the relationships among the workproduct model elements, which had a very similar structure with the entity model elements. Therefore, we decided to include the workproduct model elements in the entity relationship diagrams. The modelers also needed to represent the context information in the entity state diagrams. Entity state diagrams were used to show the states and transitions within an entity throughout its lifecycle; however an entity might have different behaviors within different missions. In order to represent this information, we decided to add the context data to the transitions among the states. The modelers needed to attach comments to the model elements to provide free text information about the model elements. KAMA did not have such a utility; therefore we decided to add a “note” element to all of the diagrams, which would not have any semantics but only a graphical node with information on it. Also we had to provide a “note relation” that would be used to link notes to the other model elements. 115
As we completed the first case study we realized that performing verification and validation activities after the first release of the conceptual model would be an effective way to determine the defects earlier. Therefore, we decided to add a review step before the “refine the conceptual model” step. This might be a joint review with the domain experts, so that both modelers and domain experts would ensure that they speak in the same language. Formal review techniques employing checklists might be used for verification and structured walkthroughs might be used for validation purposes. Verification results revealed that developing the conceptual models in a diagrammatic modeling language and using a tool that supports this language helped the modelers in describing relationships, navigating among the model elements, communicating the model and finding mistakes. We also observed that using intuitive graphical notations would increase the effectiveness of the verification process. 5.4. Case Study 2 5.4.1. Background One of the objectives of this thesis was providing a suitable notation both for development and usage of the conceptual models. Therefore, we decided to conduct the second case study in an organization where we could have the modelers develop the model and domain experts use the model. The purpose of the case study was to explore and evaluate the sufficiency of the KAMA notation for developing and validating conceptual models of the mission spaces. We conducted the case study in a software development company with 50+ software and systems developers. The company focuses on defense projects with major interest in simulation and information systems. Most of the software engineers have graduate degrees and are experienced in simulation systems development. Although they had experience in simulation development, they did not follow a defined conceptual modeling process in their previous modeling experience. The project has been estimated to last for 3 years, and an iteration will be released at the end of each year. A conceptual modeling phase has been planned for each iteration which is followed by a system requirements analysis phase. The conceptual modeling team consisted of 10 software engineers and the acquirer organization provided support to the team when required. The conceptual modeling team consisted of 6 members from the team of a simulation development project, targeted for developing/enhancing a system for Turkish Military Forces. Two of them were senior team leaders with more than 12 years of experience and the rest of the team were senior software engineers who were specialized in modeling and simulation. 116
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 and 22:
DMSO (Defense Modeling and Simulati
Page 23 and 24:
process-oriented, IDEF1X is a more
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: Conceptual Model Element (in the so
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?