دانلود مقاله ترجمه شده استفاده از روش KAOS جهت مدلسازی مدیریت تصادف خودرو – مجله IEEE

• فهرست مطالب:

 چکیده
۱ مقدمه
۲ مدل اعلانی برای سیستم ایده آل
الف تشریح قطعات مدل هدف
ب استخراج موضوعات از مشخصات هدف
ج غنی سازی مدل هدف
د بررسی گزینه های جایگزین در سناریوها
ه شناسایی اهداف نرم افزاری برای انتخاب گزینه جایگزین
۳ تجزیه و تحلیل موانع برای تکمیل مدل هدف
الف شناسایی عوامل
۴ استخراج مدل عامل
۵ استخراج مدل های عملیاتی
الف استخراج عملیات از مشخصات هدف
ب استخراج عامل از مدل رفتاری
۶ بحث

• بخشی از ترجمه:

در اين مقاله روش KAOS براي مدل مبتني بر RE در تعدادي از مراحل مدل سازي براي مديريت تصادف ماشين ارائه شده است. مدل كامل ادغام عمدي و ساختار و ابعاد عملياتي در رفتاري RE است. همراه هر يك از ابعاد، تكنيك هاي استخراج و يا مشتق هايي براي استفاده در ساخت مدل در نظر گرفته شده است. قوانين مورد استفاده قرار گرفته است تا ادغام ابعاد چند گانه انجام شود. اهداف تصفيه شده تا زماني كه آن ها مي توانند به عوامل اختصاص داده شوند. ساختار كليدي مفاهيم سيستماتيك از مشخصات هدف گرفته شده است. اين فرايند پالايش استدلال جايگزيني براي گزينه هاي فعال داشته و توسط حالت هاي مختلف نشان داده شده است و با استفاده از انتخاب اهداف نرم از مدل هدف بوده است. مشخصه كامل تر از هدف از طريق تجزيه و تحليل مانع به دست آمده است. لذا مدل عامل همراه با هدف مشتق شده در مشخصات عمليات نرم افزار و رفتاري عامل است. با وجود ارائه شرايط خطي، مدل KAOS اينجا براي تجزيه و تحليلي در راستاي حمايت از يك انتقال يكپارچه از نيازهاي عملياتي سطح بالا و بالعكس در نظر گرفته شده است و معلوم مي شود كه هر دو از بالا به پايين و از پايين به بالا وجود دارد. زبان مدل سازي و روش و تكنيك هاي مرتبط با هر مرحله براي افزايش كيفيت سند مورد نياز به دست آمده از مدل در شرايط مورد نياز در نظر گرفته است كه ثبات و كفايت و دقت و اندازه گيري و شايستگي و ساختار را دارد. 

• بخشی از مقاله انگلیسی:

INTRODUCTION Requirements engineering (RE) is concerned with the elicitation, evaluation, specification, consolidation, and evolution of the objectives, functionalities, qualities, and constraints a software-based system should meet within some organizational or physical setting [5]. The RE process is intrinsically complex. • A wide spectrum of concerns need to be addressed, ranging from high-level, strategic objectives to detailed, technical requirements. • Two systems are involved: the system as it is before software development and the system-to-be. The latter includes software and environment components such as people, devices or pre-existing software. • The involved stakeholders may have diverse, partial and conflicting concerns. • Risks must be anticipated in order to achieve requirements completeness and system robustness. • Numerous alternative options must be evaluated for selection of preferred ones. KAOS is a rigorous method for requirements engineering aimed at addressing those challenges [5]. The method may be briefly characterized as follows. • Model-based and multi-view: the elaborated system specification is organized at various levels of abstraction and according to multiple system facets. • Goal-oriented: the software requirements and environment assumptions are derived so as to meet the system’s functional and non-functional objectives. • Constructive: systematic steps and heuristic rules at each step are available to provide guidance in elaborating highquality requirements. • Incremental: early reasoning on partial models is supported. • Wide-spectrum: declarative and operational models are integrated. • Formal when and where needed for more sophisticated analysis. • Lightweight for use in practical situations, with formal details kept hidden wherever possible. In KAOS, the multiple system facets are captured through complementary models integrated through inter-model consistency rules [5]. • The goal model interrelates all functional and nonfunctional objectives of the system considered (as-is or tobe). • The object model defines and interrelates all concepts involved in the goal specifications. • The agent model specifies the system components, their interfaces and their responsibilities with respect to goals. • The operation model specifies the functional services derived from the goals assigned to specific agents. • The behavior model captures agent behaviors for goal satisfaction in terms of interaction scenarios and parallel state machines. The paper shows KAOS in action on the bCMS case study (barbados Car crash Management System) [3]. The proposed system is intended to coordinate the communication between a fire station coordinator (FSC) and a police station coordinator (PSC) to handle crises in a timely manner. Only a few modeling steps are discussed here for lack of space. Further modeling increments resulting in a larger portion of the bCMS model are available in [2]. Section II shows the elaboration of a first-sketch model for an ideal system; a few high-level goals are gradually refined into subgoals assignable to individual system agents. During such refinement, key concepts are identified and structured in an object model. Alternative system options are then discussed and evaluated in the light of soft goals and agent responsibilities. Section III de-idealizes the model presented in Section II through risk identification, assessment and resolution. Section IV shows how operational software specifications, behavior models and agent interfaces are obtained systematically from the models previously built. Section V concludes the paper by briefly discussing the strengths and limitations of the overall model obtained. II. DECLARATIVE MODEL FOR AN IDEAL SYSTEM The main bCMS goals are first identified, specified and related to each other within goal model fragments (Section II.A). While doing so, a first sketch for the object model is derived from goal specifications (Section II.B). The goal model is enriched by refining goals until fine-grained subgoals are obtained that can be assigned to software or environment agents, respectively (Section II.C). Throughout this process, scenarios can be used for goal elicitation or for illustration of alternative goal refinements (Section II.D).