التطبيقات الواعية بالسياق وبنية معالجة الأحداث المعقدة

يتزايد استخدام الهاتف المحمول في جميع أنحاء العالم باستمرار. اعتبارًا من عام 2013 ، استهلك حوالي 73 ٪ من مستخدمي الإنترنت المحتوى عبر جهاز محمول ومن المتوقع أن تصل هذه النسبة إلى ما يقرب من 90 ٪ بحلول عام 2017.

هناك بالطبع أسباب عديدة لثورة الهاتف المحمول. ولكن أحد أهمها هو أن تطبيقات الأجهزة المحمولة تحصل عمومًا على إمكانية الوصول إلى سياق أكثر ثراءً حيث أن جميع الهواتف الذكية تقريبًا اليوم مزودة بأجهزة استشعار الموقع وأجهزة استشعار الحركة والبلوتوث والواي فاي. من خلال الاستفادة من بياناتها ، يمكن للتطبيقات تحقيق "الوعي بالسياق" الذي يمكن أن يزيد بشكل كبير من إمكانياتها وقيمتها ، ويمكن أن تجعلها مميزة حقًا في متاجر التطبيقات.

في هذا البرنامج التعليمي ، سوف نستكشف إنشاء تطبيقات مدركة للسياق من خلال مثال لمعالجة الأحداث المعقدة. سنستخدم مثالًا بسيطًا إلى حد ما: تطبيق أسعار الوقود الذي يعثر على أفضل أسعار الوقود في منطقتك.

تطبيقات تدرك السياق

في Designing Calm Technology ، يصف مارك وايزر وجون سيلي براون التكنولوجيا الهادئة بأنها "تلك التي تُعلم ولكنها لا تتطلب تركيزنا أو اهتمامنا".

تتوافق تطبيقات الأجهزة المحمولة الواعية بالسياق إلى حد كبير مع هذه الفكرة وهي خطوة مهمة وقيمة على هذا المسار. يستخدمون المعلومات السياقية المستقاة من أجهزة الاستشعار الخاصة بهم لتزويد المستخدم بشكل استباقي بمعلومات قيمة ويفعلون ذلك بأقل جهد من جانب المستخدم. لا شك في أن مارك وايزر وجون سيلي براون سيشيدان بهذا التقدم التكنولوجي.

الوعي بالسياق هو فكرة أن التطبيق يمكن أن يستشعر ويتفاعل بناءً على البيانات السياقية التي يمكنه الوصول إليها. يستخدم مثل هذا التطبيق بيانات الاستشعار الغنية المتوفرة على جهاز محمول لتوفير معلومات دقيقة وذات صلة للمستخدم في السياق المناسب. من خلال الاتجاهات التي يلاحظها على مدار استخدام الجهاز ، و / أو من خلال التعليقات المقدمة من المستخدم ، يمكن لهذا التطبيق "التعلم" بمرور الوقت ، وبالتالي يصبح "أكثر ذكاءً" وأكثر فائدة.

معالجة الأحداث المعقدة

معالجة الأحداث المعقدة (CEP) هي شكل من أشكال معالجة الأحداث التي تستخدم تحليلات أكثر تعقيدًا لأحداث متعددة (على سبيل المثال ، بمرور الوقت ، من مصادر مختلفة ، وما إلى ذلك) ، ودمج وتحليل محتواها لاستنتاج معلومات وأنماط أكثر أهمية.

في تطبيق الهاتف المحمول ، يمكن تطبيق CEP على الأحداث التي تم إنشاؤها من مستشعرات الجهاز المحمول بالإضافة إلى مصادر البيانات الخارجية التي يمكن للتطبيق الوصول إليها.

الميزات الرئيسية لتطبيق أسعار الوقود

لأغراض البرنامج التعليمي الخاص بمعالجة الأحداث المعقدة ، لنفترض أن ميزات تطبيق أسعار الوقود لدينا تقتصر على ما يلي:

• الكشف التلقائي عن المواقع ذات الصلة جغرافيًا بالمستخدم (على سبيل المثال ، موقع منزل المستخدم وموقع عمل المستخدم)
• تحديد محطات الوقود تلقائيًا على مسافة معقولة من منزل المستخدم ومواقع العمل
• إخطار المستخدم تلقائيًا بأفضل أسعار الوقود بالقرب من المنزل والعمل

حسنًا ، لنبدأ.

الكشف عن مواقع المنزل والعمل

لنبدأ بمنطق الكشف التلقائي عن موقع المنزل والعمل للمستخدم. من أجل تبسيط الأمور في مثال معالجة الأحداث المعقدة لدينا ، سنفترض أن المستخدم لديه جدول عمل عادي إلى حد ما. لذلك يمكننا أن نفترض أن المستخدم سيكون عادة في المنزل بين 2 و 3 صباحًا ، وسيكون عادة في مكتبه بين 2 و 3 مساءً.

بناءً على هذه الافتراضات ، نحدد قاعدتي CEP ونجمع بيانات الموقع والوقت من الهاتف الذكي للمستخدم:

• حكم موقع المنزل
  • جمع بيانات الموقع بين 2 و 3 صباحًا لمدة أسبوع
  • تجميع بيانات الموقع للحصول على عنوان المنزل التقريبي

• حكم موقع العمل
  • جمع بيانات الموقع بين الساعة 2 و 3 مساءً طوال أيام الأسبوع
  • قم بتجميع بيانات الموقع للحصول على موقع العمل التقريبي

الخوارزمية عالية المستوى لاكتشاف المواقع موضحة أدناه.

لنفترض بنية بيانات JSON البسيطة التالية لبيانات الموقع:

 { "uid": "some unique identifier for device/user", "location": [longitude, latitude] "time": "time in user's timezone" }

ملاحظة: من الممارسات الجيدة دائمًا جعل بيانات المستشعر غير قابلة للتغيير (أو نوع القيمة) ، بحيث يمكن استخدامها بأمان بواسطة وحدات مختلفة في سير عمل CEP.

تطبيق

سنقوم بتنفيذ الخوارزمية الخاصة بنا باستخدام نمط وحدة قابل للإنشاء ، حيث تؤدي كل وحدة مهمة واحدة فقط وتستدعي بعد ذلك عند اكتمال المهمة. هذا يتوافق مع فلسفة Unix Rule of Modularity.

على وجه التحديد ، كل وحدة هي وظيفة تقبل كائن config والوظيفة next التي تسمى لتمرير البيانات إلى الوحدة التالية. وفقًا لذلك ، تقوم كل وحدة بإرجاع وظيفة يمكنها قبول بيانات المستشعر. هذا هو التوقيع الأساسي للوحدة:

 // nominal structure of each composable module function someModule(config, next) { // do initialization if required return function(data) { // do runtime processing, handle errors, etc. var nextData = SomeFunction(data); // optionally call next with nextData next(nextData); } }

لتنفيذ الخوارزمية الخاصة بنا لاستنتاج مواقع المنزل والعمل للمستخدم ، سنحتاج إلى الوحدات النمطية التالية:

• وحدة تصفية الوقت
• وحدة المجمع
• وحدة التجميع

يتم وصف كل من هذه الوحدات بمزيد من التفصيل في الأقسام الفرعية التالية.

وحدة تصفية الوقت

مرشح الوقت الخاص بنا هو وظيفة بسيطة تأخذ أحداث بيانات الموقع كمدخلات ولا تمرر البيانات إلا إلى الوحدة next إذا وقع الحدث ضمن الشريحة الزمنية محل الاهتمام. تتكون بيانات config لهذه الوحدة من وقتي البدء والانتهاء للشريحة الزمنية محل الاهتمام. (يمكن لنسخة أكثر تعقيدًا من الوحدة النمطية التصفية بناءً على شرائح زمنية متعددة.)

فيما يلي تنفيذ للرمز الزائف لوحدة مرشح الوقت:

 function timeFilter(config, next) { function isWithin(timeval) { // implementation to compare config.start <= timeval <= config.end // return true if within time slice, false otherwise } return function (data) { if(isWithin(data.time)) { next(data); } }; }

وحدة المجمع

تتمثل مسؤولية المُجمع ببساطة في جمع بيانات الموقع ليتم تمريرها بعد ذلك إلى الوحدة next . تحافظ هذه الوظيفة على دلو داخلي ثابت الحجم لتخزين البيانات. تتم إضافة كل موقع جديد يتم مواجهته إلى الحاوية حتى تمتلئ الحاوية. ثم يتم إرسال بيانات الموقع المتراكمة في الحاوية إلى الوحدة التالية كمصفوفة.

يتم دعم نوعين من حاويات المجمع. يؤثر نوع الحاوية على ما يتم إجراؤه على محتويات الحاوية بعد إعادة توجيه البيانات إلى المرحلة التالية ، على النحو التالي:

• دلو النافذة المتدحرجة ( type = 'tumbling' ): بعد إعادة توجيه البيانات ، يفرغ الحاوية بالكامل ويبدأ من جديد (حجم الحاوية المصغر إلى 0)

  

• نوع النافذة قيد التشغيل ( type = 'running' ): بعد إعادة توجيه البيانات ، يتجاهل فقط أقدم عنصر بيانات في الحاوية (يقلل حجم الحاوية بمقدار 1)

فيما يلي تنفيذ أساسي لوحدة التجميع:

 function accumulate(config, next) { var bucket = []; return function (data) { bucket.unshift(data); if(bucket.length >= config.size) { var newSize = (config.type === 'tumbling' ? 0 : bucket.length - 1); next(bucket.slice(0)); bucket.length = newSize; } }; }

وحدة التجميع

هناك بالطبع العديد من التقنيات المعقدة في هندسة الإحداثيات لتجميع البيانات ثنائية الأبعاد. فيما يلي طريقة واحدة بسيطة لتجميع بيانات الموقع:

• البحث عن الجيران لكل موقع في مجموعة من المواقع
• إذا كان بعض الجيران ينتمون إلى مجموعة موجودة ، فقم بتوسيع الجيران باستخدام الكتلة
• إذا كانت المواقع في مجموعة الجوار أكثر من عتبة ، أضف الجيران كمجموعة جديدة

إليك تطبيق لخوارزمية التجميع هذه (باستخدام Lo-Dash ):

 var _ = require('lodash'); function createClusters(location_data, radius) { var clusters = []; var min_points = 5; // Minimum cluster size function neighborOf(this_location, all_locations) { return _.filter(all_locations, function(neighbor) { var distance = distance(this_point.location, neighbor.location); // maximum allowed distance between neighbors is 500 meters. return distance && (500 > distance); } } _.each(location_data, function (loc_point) { // Find neighbors of loc_point var neighbors = neighborOf(loc_point, location_data, radius); _.each(clusters, function (cluster, index) { // Check whether some of the neighbors belong to cluster. if(_.intersection(cluster, neighbors).length){ // Expand neighbors neighbors = _.union(cluster, neighbors); // Remove existing cluster. We will add updated cluster later. clusters[index] = void 0; } }); if(neighbors.length >= min_points){ // Add new cluster. clusters.unshift(neighbors); } }); return _.filter(clusters, function(cluster){ return cluster !== void 0; }); }

يفترض الكود أعلاه وجود وظيفة distance() تحسب المسافة (بالأمتار) بين موقعين جغرافيين. يقبل نقطتي موقع في شكل [longitude, latitude] ويعيد المسافة بينهما. فيما يلي نموذج لتنفيذ مثل هذه الوظيفة:

 function distance(point1, point2) { var EARTH_RADIUS = 6371000; var lng1 = point1[0] * Math.PI / 180; var lat1 = point1[1] * Math.PI / 180; var lng2 = point2[0] * Math.PI / 180; var lat2 = point2[1] * Math.PI / 180; var dLat = lat2 - lat1; var dLon = lng2 - lng1; var a = Math.sin(dLat/2) * Math.sin(dLat/2) + Math.sin(dLon/2) * Math.sin(dLon/2) * Math.cos(lat1) * Math.cos(lat2); var arc = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a)); var distance = EARTH_RADIUS * arc; return distance; }

من خلال تحديد خوارزمية التجميع الخاصة بنا وتنفيذها (في وظيفة createClusters() الموضحة سابقًا) ، يمكننا استخدامها كأساس لوحدة التجميع الخاصة بنا:

 function clusterize(config, next) { return function(data) { var clusters = createClusters(data, config.radius); next(clusters); }; }

جمع كل ذلك معا

تم الآن تحديد جميع وظائف المكونات المطلوبة ، لذلك نحن على استعداد لتشفير قواعد موقع المنزل / العمل.

هنا ، على سبيل المثال ، تنفيذ محتمل لقاعدة موقع المنزل:

 var CLUSTER_RADIUS = 150; // use cluster radius of 150 meters var BUCKET_SIZE = 500; // collect 500 location points var BUCKET_TYPE = 'tumbling'; // use a tumbling bucket in our accumulator var home_cluster = clusterize({radius: CLUSTER_RADIUS}, function(clusters) { // Save clusters in db }); var home_accumulator = accumulate({size: BUCKET_SIZE, type: BUCKET_TYPE}, home_cluster); var home_rule = timeFilter({start: "2AM", end: "3AM"}, home_accumulator);

الآن عندما يتم استلام بيانات الموقع من الهواتف الذكية (عبر websocket ، TCP ، HTTP) نقوم بإعادة توجيه هذه البيانات إلى وظيفة home_rule والتي بدورها تكتشف مجموعات لمنزل المستخدم.

يُفترض بعد ذلك أن يكون "موقع المنزل" الخاص بالمستخدم هو مركز مجموعة موقع المنزل.

ملاحظة: على الرغم من أن هذا قد لا يكون دقيقًا تمامًا ، إلا أنه مناسب لمثالنا البسيط ، خاصة وأن الهدف من هذا التطبيق على أي حال هو ببساطة معرفة المنطقة المحيطة بمنزل المستخدم ، بدلاً من معرفة موقع المنزل الدقيق للمستخدم.

فيما يلي مثال بسيط لدالة تحسب "مركز" مجموعة من النقاط في مجموعة عن طريق متوسط ​​خطوط العرض وخطوط الطول لجميع النقاط في مجموعة المجموعة:

 function getCentre(cluster_data) { var len = cluster_data.length; var sum = _.reduce(cluster_data, function(memo, cluster_point){ memo[0] += cluster_point[0]; memo[1] += cluster_point[1]; return memo; }, [0, 0]); return [sum[0] / len, sum[1] / len]; }

يمكن استخدام نهج مماثل لاستنتاج موقع العمل ، مع الاختلاف الوحيد هو أنه سيستخدم مرشح الوقت بين 2 و 3 مساءً (على عكس 2 و 3 صباحًا).

وبالتالي ، فإن تطبيق الوقود لدينا قادر على اكتشاف مواقع عمل المستخدم والمنزل تلقائيًا دون الحاجة إلى أي تدخل من المستخدم. هذه هي الحوسبة الواعية بالسياق في أفضل حالاتها!

البحث عن محطات الوقود القريبة

لقد تم الآن العمل الجاد لتأسيس الوعي بالسياق ، لكننا ما زلنا بحاجة إلى قاعدة أخرى لتحديد أسعار محطات الوقود التي يجب مراقبتها (أي محطات الوقود القريبة بدرجة كافية من منزل المستخدم أو موقع العمل لتكون ذات صلة). تحتاج هذه القاعدة إلى الوصول إلى جميع مواقع محطات الوقود لجميع المناطق التي يدعمها تطبيق الوقود. القاعدة كما يلي:

• حكم محطة الوقود
  • ابحث عن أقرب محطات وقود لكل منزل ومكان عمل

يمكن تنفيذ ذلك بسهولة باستخدام وظيفة المسافة الموضحة سابقًا كمرشح موقع لتطبيقه على جميع محطات الوقود المعروفة للتطبيق.

مراقبة أسعار الوقود

بمجرد حصول تطبيق الوقود على قائمة محطات الوقود المفضلة (أي القريبة) للمستخدم ، يمكنه بسهولة مشاهدة أفضل أسعار الوقود في هذه المحطات. يمكنه أيضًا إخطار المستخدم عندما يكون لإحدى محطات الوقود هذه أسعارًا أو عروض خاصة ، خاصةً عند اكتشاف وجود المستخدم بالقرب من محطات الوقود هذه.

خاتمة

في هذا البرنامج التعليمي لمعالجة الأحداث المعقدة ، بالكاد خدشنا سطح الحوسبة الواعية بالسياق.

في مثالنا البسيط ، أضفنا سياق الموقع إلى تطبيق بسيط لتقرير أسعار الوقود وجعلناه أكثر ذكاءً. يعمل التطبيق الآن بشكل مختلف على كل جهاز ويكتشف بمرور الوقت أنماط الموقع لتحسين قيمة المعلومات التي يوفرها لمستخدميه تلقائيًا.

بالتأكيد يمكن إضافة المزيد من بيانات المنطق والاستشعار لزيادة دقة وفائدة تطبيقنا المدرك للسياق. يمكن لمطور الهاتف الذكي ، على سبيل المثال ، الاستفادة من بيانات الشبكة الاجتماعية وبيانات الطقس وبيانات المعاملات الطرفية لنقاط البيع وما إلى ذلك لإضافة المزيد من الوعي بالسياق لتطبيقنا وجعله أكثر قابلية للتطبيق وقابلية للتسويق.

مع الحوسبة الواعية للسياق ، فإن الاحتمالات لا حصر لها. سيستمر ظهور المزيد والمزيد من التطبيقات الذكية في متاجر التطبيقات التي تستخدم هذه التقنية القوية لجعل حياتنا أكثر بساطة.