An approach to specify the requirements and design of a Distributed Software System (DSS), which is mostly used in recent years, is describing scenarios with visual artefacts, such as, UML Sequence Diagrams and ITU-T (ITU-T UNION, 2004) Message Sequence Charts (MSC) and High level Message Sequence Charts (hMSC) (Kruger, 2000). Scenarios describe system's behavior and define the components and their interactions. Each scenario determines a partial behavior of the system. Hence, the restricted view of the components in each scenario and distributed functionality and/or control in DSS, may result in inconsistency in the system behavior. One problem that arise in scenario based Distributed Software Systems is emergent behaviors or implied scenarios that occur because of restricted view of one or more components. Emergent behaviors are known as unexpected behaviors that components show in their execution time (Uchitel, 2003; Bhateja et al., 2007). However, this behavior was not defined in their designs. This unexpected behavior may imply a new scenario to the system, and can result in considerable cost and damage (Alur et al., 2005). Therefore, emergent behaviors should be detected in the early phases of software development to prevent damage or cost after deployment. The detected emergent behaviors can be either accepted or denied by the stakeholders. However, they should be detected and discussed, to be added as new designs, or to be specified as negative scenarios that should be avoided (Uchitel et al., 2002). In our research, we try to devise an automatic methodology to detect the emergent behaviors (implied scenarios) from the designs of the system. We also mean to help the designers for the exact point of the problem in the system and the possible solutions to remove the detected emergent behaviors.
展开▼
