تبليغاتX
فاوا پایگاه بسیج شهدای ایرنا

فاوا پایگاه بسیج شهدای ایرنا

در راستاي طرح آموزش فناوري اطلاعات در توسعه نيروي انساني

 

 

قسمت اول: تامين و ارايه‌ي دليل

 

1- هدف اوليه‌ي اين يادداشت، ترويج استفاده از فناوري اطلاعات در رسيدگي به دعاوي مدني در دادگاه‌ها و تشويق دو طرف دعوا به استفاده از اين فناوري در زمان محاکمه است.

2- ممکن است دادگاه‌ها درباره‌ي استفاده از فناوري اطلاعات هنگام دادرسي و محاکمه، يادداشت‌هاي عملي بيشتري صادر كنند. يک استفاده کارآمدتر از فناوري اطلاعات، امتياز يک پروتکل توافق شده براي مبادله‌ي اطلاعات الکترونيکي در جريان ارايه‌ي دليل؛ در جلسه‌ي رسيدگي است.

3- دو طرف در جريان هر دعواي مدني، در زمان مشخص شده، به انجام موارد زير تشويق شده‌اند:

 

الف) استفاده از اطلاعات الکترونيکي براي تهيه‌ي ليستي از دلايل و مدارک قابل ارايه.

ب ) پذيرش نتايج حاصل ازمبادله‌ي اطلاعات الکترونيکي منطبق با پروتکل توافق شده.

ج) مبادله‌ي نسخه‌ي الکترونيکي دلايل و مدارک مثل لوايح و اظهاريه‌ها .

 د) تنظيم موضوعات ارايه شده براي بررسي و تحقيق در موارد مورد نياز، با استفاده ازاطلاعات الکترونيکي، از جمله  GFX.

و) توجه به استفاده از اطلاعات الکترونيکي در محاکمه.

 

4- اگر دو طرف متوجه شوند که قبل از شروع رسيدگي، بيش از پانصد مدرک و سند را (بافناوري اطلاعات)، بين خود رد و بدل خواهند کرد، بهتر است براي مبادله‌ي اسناد و مدارک و فهرست‌بندي آن‌ها در شکل الکترونيکي، توافق كنند.

 

5- اگر دو طرف توافق کنند که اسناد و مدارک را به شكل الکترونيکي مبادله كنند، انجام موارد زير مي‌تواند براي آن‌ها بسيار سودمند باشد:

 

الف) تلاش براي به دست آوردن يك توافق در پروتکل مورد استفاده.

 ب ) جلب موافقت دادگاه و رعايت پروتکل مورد توافق.

 ج ) تلاش براي به دست آوردن دستورمشابه با پروتکل از دادگاه، در صورتي كه دو طرف نتوانند به توافق برسند.

 

6- اگر دو طرف توافق كنند که براي يک پروتکل مبادله‌ي اطلاعات تصميم‌گيري كنند، پروتکل بايد شامل موارد زير باشد:

 

الف) مبادله‌ي اسناد و مدارک دادگاه، ابلاغ‌ها و اعلاميه‌ها، در شکل الکترونيکي

ب) مبادله‌ي الکترونيکي ليست‌هاي ضروري اسناد و مدارک قابل ارايه. (از جمله GFX، در موارد مقتضي)

ج) وسيله‌ي مناسب براي مبادله‌ي اطلاعات الکترونيکي در جريان ارايه‌ي ادله.

د) استفاده از فناوري در محاکمه.

 

7- اين يادداشت كاربردي در برگيرنده‌ي مطالبي براي  کمک به دو طرف براي توافق در يک پروتکل و راهنمايي آنها در زمينه‌ي چگونگي جمع‌آوري اطلاعات الکترونيکي است.

 

8- چک ليست فناوري تنظيم شده در ضميمه‌ي الف مي‌تواند براي دو طرف در تعيين پروتکل فناوري اطلاعات مفيد باشد. (پروتکل فناوري که در جريان دعوا بايد از آن استفاده شود.)

ضميمه‌ي الف  به آدرس اينترنتي دادگاه فدرال مراجعه کنيد.

ضميمه‌ي ب – در زمينه‌ي استفاده از اطلاعات خام راهنمايي مي‌كند. بهتر است دو طرف براي گردآوري اطلاعات الکترونيکي از آن استفاده كنند.

ضميمه ج – به آدرس اينترنتي دادگاه فدرال مراجعه کنيد.

 

9- دادگاه هم‌چنين، در مواردي، دو طرف را تشويق مي‌كند که مدارک را به شکل الکترونيکي و قبل از جلسه‌ي رسيدگي به هيات قضات محاکمه کننده تحويل دهند. اين راهكار مي‌تواند با يک سند که در هارد ذخيره و ثبت شده است، تکميل شود.

 

10- واژه‌هاي فني اين يادداشت كاربردي در فهرست معاني ضميمه (C) تعريف شده‌اند. (به آدرس اينترنتي دادگاه فدرال مراجعه کنيد.)

 

مبادله الکترونيکي مدارک دادگاه

 

11- هنگامي که يکي از دو طرف يک لايحه، گواهي‌نامه، اعلاميه يا اظهاريه، ليست مدارک يا تحقيقات را براي طرف ديگر مي‌فرستد، گيرنده مي‌تواند کپي مدرک را در شکل الکترونيکي از فرستنده بخواهد.

 

12- دادگاه از دو طرف انتظار دارد با تقاضاي معقول براي ارايه‌ي کپي مدارک به شکل الکترونيکي موافقت كنند.

 

13- پيرو مورد 15 كه در زير به آن اشاره مي‌شود، زماني که يک طرف مدرکي را به شكل الکترونيکي تهيه مي‌کند، مدرك بايد حاوي همان مطالبي باشد كه در کپي کاغذي آن آمده است.

 

14- در موارد مقتضي، دو طرف مي توانند مدرک را به شكل‌هاي ساخته شده، مثل HTM بخواهند. بنابراين بر حسب مورد خطوط شبه نوشتاري هر جا كه لازم باشد، مي‌توانند استفاده شوند، براي مثال اگر سندي به يک سند  ID ارجاع دهد، يک خط شبه نوشتاري مي‌تواند براي تصوير کردن و بازتاب سند مربوط به آن استفاده شود.

 

15- هرگاه مدرکي ضمايم داشته باشد، به طور معمول از ارايه‌دهنده انتظار مي‌رود نسخه‌ي الکترونيکي ضمايم و مدارک اصلي را تهيه كند، به شرط آن که آن ضمايم به شكل يك مدرك الکترونيکي، به وسيله‌ي ارايه کننده يا از طرف او يا وکلايش براي دادخواهي ايجاد شده باشد.

 

16- دادگاه از دو طرف انتظار دارد، براي توافق در موضوعات زير تلاش كنند:

 

الف) شکل وقالبي که در آن نسخه‌هاي الکترونيکي مدارک دادگاه آماده (و ذخيره) مي‌شود.

ب) روش مبادله‌ي نسخه‌هاي الکترونيکي مدارک دادگاه .

پ) شرايط و مواردي که با دست‌يابي به آنها بايد اسناد دادگاهي به شکل الکترونيکي، مبادله شوند.

 

17- تهيه‌ي مدارک الکترونيکي به وسيله‌ي يک طرف با شرط آزمودن آن‌ها به وسيله‌ي گيرنده براي اطمينان درباره‌ي از بين نرفتن مدارک، نامعقول نخواهد بود.

 

18- دادگاه ممکن است به يکي از دو طرف دستور دهد، کپي‌هايي از مدارک دادگاه را در يک قالب الکترونيکي ويژه به دادگاه تقديم كند. پيرو آن‌چه كه در مورد 15 به آن اشاره شد، وقتي يک طرف مدرکي را به صورت الکترونيکي به دادگاه تقديم مي‌کند آن مدرک بايد داراي همان شکل و محتويات کپي کاغذي آن باشد. دادگاه از طرفي که مدارک را به صورت الکترونيکي تهيه مي نمايد انتظار دارد اخطاريه‌ي کتبي و مناسب درباره‌ي نياز به آزمودن صحت يا خرابي آن مدارک تهيه كند.

 

مبادله‌ي الکترونيکي ليست دلايل قابل ارايه و مدارک

 

19- دو طرف از آغاز جريان دعوا به بررسي راه‌هاي موثرتر فناوري اطلاعات، براي ارايه‌ي دليل و بازرسي مراحل محاکمه تشويق شده‌اند.

 

20- مناسب‌ترين استفاده‌ي فناوري اطلاعات، به طور معمول به درجه و طبقه‌ي مدارک ارايه شده بستگي دارد و بر حسب مورد مي‌تواند به توافق دو طرف يا دستور دادگاه در محدود کردن حوزه‌ي ارايه‌ي دليل وابسته باشد.

 

21- اگر دو طرف، حوزه و محدوده‌ي‌ ارايه‌ي دلايل و مدارک قابل ارايه را تعريف و معين كنند، تصميم‌گيري در خصوص استفاده‌ي مناسب از فناوري ساده‌تر است و بهتر اعلام خواهد شد . 

 

22- دستور رسيدگي دادگاه مي‌تواند متضمن دستورهاي زير باشد:

 

 الف) مذاکره‌ي دو طرف براي چگونگي بهترين استفاده از فناوري براي تبادل اطلاعات درباره‌ي مدارک قابل ارايه  يا کپي هاي آن.

ب) ارايه‌ي اظهاريه‌هاي کتبي در زمينه‌ي چگونگي بهترين استفاده از فناوري براي تبادل اطلاعات.

 

 پيش از رسيدگي 

 

دادگاه الکترونيکي شبکه‌اي ايجاد شده، مبتني بر وب است که دادگاه فدرال از آن به عنوان يک جلسه‌ي واقعي دادرسي به صورت online استفاده مي‌کند. براي ارسال دستورات و ساير تصميمات موقت قضايي online هنگام استفاده از شبکه، دادگاه مي‌تواند همانند يک جلسه‌ي عادي دادرسي اظهاريه‌هاي کتبي و مدارک گواهي‌نامه را دريافت و دستوراتي صادر كند. دو طرف براي ارتباط با دادگاه الکترونيکي بايد نام  کاربر و کلمه عبوري را که دادگاه صادر کرده است، وارد كنند. با اين كار مي‌توانند پيام‌هاي پست شده به شبکه را درباره‌ي موضوع مورد نظرشان بخوانند و پيام‌هاي خودشان را پست كنند. امکان دارد همراه پيام‌ها، مدارک و دلايل را نيز پيوست و به شبکه ارسال كنند. پايلوت، دادگاه الکترونيکي دادگاه فدرال، در جمعه 23 فوريه 2001، آغاز شده و ادامه دارد. در طول دوره‌ي راهنمايي، دست‌رسي به دادگاه الکترونيکي شده به دو طرف و نمايندگانشان محدود شده است. تنظيمات فني و پروتکل دادگاه الکترونيکي با استفاده از دادگاه تشکيل  ‌شده بر روي شبکه و با راهنمايي‌ها و ديگر نتايجي که از دادگاه به دست مي‌آورد، تجديد نظر مي‌شود.

 

پروتکل دادگاه الکترونيکي

 

دادگاه الکترونيکي مطابق پروتکل، استفاده مي‌شود. به طور خلاصه، دو طرف دعوا بايد همان‌گونه که در جلسه‌ي عادي دادگاه عمل مي‌شود، در دادگاه الکترونيکي رفتار كنند. پروتکل جزييات بيشتري را در زير مطرح نموده است:

 

شرايط ورود به شبکه و نيازمندي‌هاي فني

 

براي استفاده از شبکه شما به موارد زير نياز خواهيد داشت :

 

يک کامپيوتر استاندارد.

يک شبکه گسترش دهنده همراه يک رابط اينترنتي.

يک پست الکترونيکي.

يک نام کاربر و کلمه عبور كه دادگاه صادر مي‌كند.

 

امنيت اطلاعات

 

دادگاه الکترونيکي براي تامين امنيت و محفوظ ماندن مذاکرات، از سيستم و تکنولوژي  ssl استفاده مي‌کند. داشتن يک نسخه‌ي جست‌و‌جوگر اينترنتي 40 يا بالاتر يا "netscape narigator"  40  يا بالاتر باشيد براي استفاده از اين تسهيلات ضروري است.

 

پروتکل

 

رفتار هريک از دو طرف دعوا در دادگاه الکترونيکي مانند رفتار آنها در جلسه عادي دادگاه است. بدين معنا که دادگاه الکترونيکي تنها بايد براي بررسي‌ها و تشخيص موضوعات تعيين شده و به وسيله دادگاه يا قاضي مورد استفاده قرار گيرد.

دادگاه الکترونيکي براي مذاکرات انحصاري بين دو طرف دعوا يا نمايندگان آنها مورد استفاده قرار نمي گيرد به ويژه زمانيکه مذاکرات محرمانه يا حساس باشند.

زبان و روش مذاکره در دادگاه الکترونيکي بايد مشابه آن چيزي باشد که در جلسه عادي دادرسي استفاده مي شود.

تعهداتي که يکي از دو طرف يا نماينده‌اش بر روي شبکه به دادگاه يا قاضي يا طرف ديگر مي‌دهد، مانند تعهدات پذيرفته شده در جلسه‌هاي عادي رسيدگي، بايد رعايت و اجرا شود.

قواعد مربوط به اهانت به دادگاه در دادگاه الکترونيکي نيز همانند جلسه‌ي عادي رسيدگي اعمال مي‌شود.

براي هر موضوع مطرح شده در دادگاه الکترونيکي يک کپي از مباحث رد و بدل شده در قالب يک متن فقط خواندني( reed – only) در وب‌سايت شبکه، در دست‌رس است، مگر اين‌که دادگاه يا قاضي دستورات ديگري صادر كنند.

 

موضوعاتي که مي‌توانند در دادگاه الکترونيکي مطرح شوند

 

تمام موضوع يا بخشي از موضوع که بايد در دادگاه الکترونيکي مطرح شود، به وسيله‌ي دادگاه يا قاضي تعيين خواهد شد. اين امر با توجه به ماهيت و پيچيدگي موضوعاتي که بايد حل و فصل شوند و تعداد طرفين، دست‌رسي هر طرف به پست الکترونيکي و اينترنت، نظريات دو طرف، ماهيت و حدود هر دليل قابل ارايه، ضرورت تمام يا بخشي از موضوع  صورت مي‌پذيرد.

 

پايان استفاده از دادگاه الکترونيکي براي يک موضوع يا عنوان خاص

 

دادگاه يا قاضي مي‌تواند به تشخيص خود و يا به درخواست يکي از دو طرف، در هر زماني به استفاده از شبکه در مورد يک موضوع يا بخشي از موضوع خاتمه دهد.

 

کد ورود

 

هر يک از دو طرف دعوا يا اعضاي دادگاه الکترونيکي، نام کاربر و کلمه عبور مخصوص به خود دارند. محرمانه ماندن اين اطلاعات و حفظ و نگه‌داري آنها در مکاني امن بسيار مهم است.

دادگاه يا قاضي چنين فرض مي‌كند که پيام‌ها و مدارک ارسالي به دادگاه الکترونيکي از حساب يک کاربر خاص، از طرف و با مسئوليت صاحب حساب ارسال شده است.

 

استفاده از دادگاه الکترونيکي

 

دادگاه يا قاضي مي‌توانند در مورد اين‌که يك موضوع يا بخشي از موضوع چگونه در شبکه به كار برده شود، دستوراتي صادر كند، مثل اين‌که دادگاه يا قاضي مي‌تواند دستور دهد:

 

چه موضوع يا موضوعاتي در دادگاه الکترونيکي مطرح شوند.

چه کساني مي توانند در دادگاه الکترونيکي شرکت نمايند.

حداکثر طول پيام يا ضمايم و پيوست هاي آن چقدر باشد.     

حداکثر زماني که مي‌توان پيام ها (از جمله جوابيه و دفاعيات) را به دادگاه الکترونيکي ارسال كرد، چقدر است.

 

پيام‌ها

 

پيام‌ها بايد :

 

با موضوعات يا زمينه‌ي بخشي که براي آن پيام ارسال شده مرتبط باشند.

خلاصه، حاوي مطلب اصلي و به‌جا باشند.

 

مدارک

 

مدارک را مي‌توان به پيام‌هاي فرستاده شده به شبکه، پيوست كرد؛ ولي نمي‌توان آن‌ها را در دادگاه استفاده‌کننده از دادگاه الکترونيکي ثبت كرد. مدارک فقط مي‌توانند مطابق دستور يکم قواعد SA, SAB, SAC از قواعد دادگاه فدرال ثبت شوند.

در موارد فوري و ضروري مي‌توان مدرک ثبت شده را به دادگاه الکترونيکي فرستاد به شرط  آن‌كه مدرک پس از آن در دادگاه ثبت خواهد شد.

در مواردي که در پيام به مدرکي ثبت شده اشاره مي‌شود، مي‌توان براي آساني ارجاع، يک کپي از مدرک ياد شده را به پيام پيوست كرد. در اين موارد پيام بايد حاوي تاريخ ثبت مدرک باشد.

 

ارسال مدارک بايد به يکي از اشکال زير باشد:

 

Rich Text format (RTF))

Portable Document format (PDF))

Tagged Damag format (TIF))

Graphical  Information format (GIF)

Joint photographic Experts Group (JPG)

or word

 

احکامي كه بايد مورد رضايت دو طرف باشد:

 

هنگامي که مدرک ارسالي به  دادگاه الکترونيکي پيش‌نويس يک حکم سازشي باشد، پيامي که مدرک به آن پيوست شده است بايد در برگيرنده تصديقي از ارسال کننده باشد. مبني بر اين که هر دو طرف آن را ديده‌اند و با شرايط حکم سازشي موافق هستند. پيامي که براي به دست آوردن حکم سازشي ارسال مي‌شود، ممکن است پي در پي پيوست‌هاي پايين را به همراه داشته باشد:

 

کپي احکامي که به امضاي هر طرف يا نمايندگانشان رسيده است. پيرو دستور 41 قاعده‌ي 7  از قواعد دادگاه فدرال .

مدرکي که انعکاس دهنده احکام سازشي امضا شده است.

 

ثبت احکام

 

احکامي که به وسيله‌ي دادگاه يا قاضي در دادگاه الکترونيکي صادر مي‌شوند بايد به روش عادي و به موجب دستور 36 از دادگاه فدرال ثبت شوند.

 

دادگاه الکترونيکي و ميانجي‌گري

 

ممکن است از برخي پرونده‌ها، از دادگاه الکترونيکي در جهت ميانجي‌گري استفاده شود. در چنين مواردي که شرايط پروتکل تا اندازه‌اي که مرتبط هستند، اعمال مي‌شود، متصدي ثبت که مسئول ميانجي‌گري است ممکن است در مورد نحوه‌ي عمل براي ميانجي‌گري در شبکه دستوراتي بدهد. براي مثال وي ممکن است در موارد زير دستوراتي صادر كند:

 

- موضوع يا موضوعاتي که بايد در دادگاه الکترونيکي مطرح شوند.

- کسي‌که مي‌تواند در شبکه مشارکت كند.

- حداکثر طول پيام‌ها و ضمايم و پيوست‌ها و حداکثر زماني که پيام ها (از جمله پاسخ‌ها و يا دفاعيات) بايد به شبکه فرستاده شوند.

 

محاکمات بدوي و تجديدنظر الکترونيکي، در جريان دادرسي

 

محاکمات بدوي و تجديدنظر الکترونيکي عبارت‌اند از جريان کار دادگاه، زماني‌ که اکثر مدارک و اوراق مرتبط ذخيره شده‌اند و کليه‌ي اقدامات درجريان رسيدگي به طور الکترونيکي در دست‌رس هستند.

محاکمه‌هاي الکترونيکي هم‌چنين به عنوان "جلسه‌هاي بدون اوراق دادرسي" شناخته شده‌اند. زيرا در اين محاکمه‌ها استفاده از اوراق کپي مدارک (کپي هاي کاغذي) به حداقل مي‌رسد. ايده‌ و فکر "جلسات بدون اوراق دادرسي" هم در محاکمه‌هاي بدوي و هم در جريان رسيدگي تجديدنظر مي‌تواند اعمال شود.

براي درك مفهوم مورد نظر در محاکمه‌ي بدوي، مي‌توان به يک نمونه‌ي راهنما كه در پرونده‌ي پيتر دي‌ رز روي داده است، اشاره كرد. قاضي O Loughlin سرتاسر محاکمه را اداره کرده بود و بيشتر آن در شهري در ناحيه 470 کيلومتري جنوب "آليس اسپرينگ" بررسي شده بود. پرونده براي اولين بار در ژوئن  تا جولاي و سپتامبر تا  اکتبر 2001 بررسي شد.

ناظران و متصديان دادگاه فدرال با کمک‌هاي تکنيکي محدودي از پيمان‌کاران، بيشتر جنبه‌هاي فني اين محاکمه را نظارت كردند.

يک نمونه از مفهوم مورد نظر در مرحله‌ي تجديدنظر در پرونده‌ي کوبيلو است. پيمان‌کاران بيشتر جنبه‌هاي فني مرحله‌ي تجديدنظر را با همكاري فني و محدود اعضاي دادگاه فدرال نظارت كرند. 

 

 


 

 

+ نوشته شده در  ساعت   توسط فرهاد شرف پور  | 

هدف دولت الكترونيك ارائه خدمات بهتر، با هزينه، كمتر و اثر بخشي بيشتر است؛ ولي
نمي‌توان استاندارد مشخصي براي ساير ويژگي‌هاي آن معرفي كرد، زيرا هر دولتي
مي‌تواند با توجه به نيازهاي جامعه خودش نظام دولت الكترونيك را پايه‌ريزي كند.



رشد و توسعه فناوري اطلاعات و مزاياي زياد کاربرد اين فناوري در بهبود روند ارائه خدمات سازما‌ن‌هاي دولتي، سبب گرايش دولت‌ها به اين فناوري و حرکت به سمت پياده‌سازي دولت الکترونيک شده است. در اين مطلب با مروري بر مفاهيم و اصطلاحات رايج در زمينه دولت الکترونيک مقدمه‌اي اجمالي بر اين مبحث بيان مي‌گردد.

1- تعاريف و اصطلاحات
• دولت الكترونيك (E- Government): دولت الكترونيك استفاده از فناوري‌هاي اطلاعاتي و ارتباطي به منظور ارائه خدمات دولتي، به صورت بهنگام و مستقيم به شهروندان، در 24 ساعته شبانه روز و 7 روز هفته است. دولت الكترونيك به افراد تسهيلات لازم جهت دسترسي مناسب به اطلاعات و خدمات دولتي و فرصت‌هاي گسترده‌تر براي مشاركت در فرايندها را ارائه مي‌نمايد.

• ذي‌نفع (Stakeholder): افراد، سازمان‌ها و گروه‌هاي خاصي هستند كه به نحوي به طرح‌ها و برنامه‌هاي دولت علاقه‌مند هستند و تصميمات دولت براي آنها اهميت دارد و به عبارتي در فعاليت‌هاي دولتي ذي‌نفع هستند؛ مانند كارفرماياني كه مصوبات دولت در مورد حداقل حقوق كارگران براي آنها از نظر كاري و حرفه‌اي داراي اهميت است.

• مشتري (Customer):استفاده‌كننده از سرويس‌هاي دولتي را مشتري مي‌گويند، مانند بازنشستگاني كه حقوق بازنشستگي دريافت مي‌كنند و يا افرادي كه براي معالجه به كلينيك‌هاي دولتي مراجعه مي‌نمايند.

• شهروند (Citizen): فردي با حقوق و مسئوليت‌هاي تعريف‌شده و معين در جامعه؛ اين حقوق شامل حق رأي، حق اظهار نظر آزاد و ... مي‌شود. افرادي كه در انتخابات شركت كرده و رأي مي‌دهند و يا اشخاصي كه در يك تجمع سياسي سخنراني مي‌كنند، مشتريان دولت نيستند؛ بلكه شهرونداني هستند كه در فعاليت‌هاي جامعه شركت مي‌كنند.

• بنگاه (Business): شركت‌هاي تجاري و خصوصي بوده كه از يك سو با دولت و سازمان‌هاي دولتي و از سوي ديگر با مصرف‌كنندگان (consrmers) يا مشتريان در ارتباط هستند. تمامي شركت‌ها از زمان تأسيس شركت براي ثبت و امور مالي و مالياتي و رعايت استانداردها و قوانين و ... با دولت و ارگان‌هاي اداري در ارتباط هستند. همچنين برخي شركت‌ها به عنوان پيمانكار با دولت در تعامل هستند مثل شركت‌هايي كه برخي پروژه‌هاي عمراني دولت را بر عهده مي‌گيرند.

2- ساختار و روابط دولت الکترونيک
در واقع ستون‌ اصلي دولت الكترونيك، ارتباطي است كه دولت با شهروندان، بنگاه‌هاي اقتصادي، كاركنان و ساير مؤسسات دولتي برقرار مي‌سازد و اين ارتباطات است كه روح دولت الكترونيك را تشكيل مي‌دهد. در اين قسمت سعي مي‌كنيم ابعاد مختلف دولت الكترونيك و روابط بين آنها را بشناسيم. دولت الكترونيك براي سرويس‌دهي به شهروندان، واحدهاي خصوصي و سازمان‌هاي دولتي ديگر، از مجراهاي مختلفي استفاده مي‌كند كه اين خود به روابطي مابين دولت و اركان جامعه مي‌انجامد كه تحت عناوين زير دسته بندي مي‌شوند:

• G2E: رابطه دولت با شهروندان كه طي آن دولت سرويسي را به شهروندان ارائه مي‌دهد‌. در اينجا شهروند به عنوان عضوي از جامعه كه حق او استفاده از سرويس‌هاي دولت الكترونيك است، اين خدمات را به صورت رايگان دريافت مي‌كند.

• G2B: رابطه‌اي بين دولت و بنگاه‌هاي تجاري وخصوصي است كه طي آن دولت سرويسي رابه آن سازمان يا شركت خصوصي ارائه مي‌دهد. به عنوان مثال مي‌توان به مزايده‌اي كه از طرف دولت در اينترنت به اجرا گذاشته مي‌شود و شركت‌هاي خصوصي از طريق اينترنت در اين مزايده شركت مي‌كنند اشاره كرد. خدماتي از قبيل ارائه مجوز وگواهي‌نامه‌ها، انجام خريد و فروش كالاها، خدمات وغيره دراين بخش انجام مي‌گيرد.

• G2G: رابطه‌اي بين سازمان‌هاي درون دولت و يا بين دولت‌هاي مختلف كه طي آن، هريك از اين سازمان‌ها يا دولت‌ها مي‌توانند به ديگري سرويس دهند و يا روابطي در زمينه‌هاي مختلف داشته باشند. اكثر امور اداري دولت به نحوي به هم مربوط هستند. بدين معني كه اطلاعات يك سازمان يا بخش مورد استفاده، از سرعت و اطمينان كافي برخوردار نيست. به همين دليل نياز به اتصال سازمان‌هاي مختلف دولتي احساس مي‌شود.

• G2E: رابطه بين دولت با كارمندانش است و شامل سرويس‌هايي است كه از طرف دولت به كارمندان اداري سازمان‌هاي مختلف دولتي در رابطه با كار و شغل آنها ارائه مي‌شود. اين سرويس‌ها مي‌توانند شامل امور مالي، حقوقي و ماليات و … مربوط به كارمندان باشد. رسيدگي به نحوه عملكرد كارمندان و ارتباطات داخلي يك سازمان دولتي جهت كاهش كاغذبازي و جلوگيري از اتلاف زمان و افزايش كارايي سازمان دولتي نيز مي‌تواند از جمله كاركردهاي GE باشد.

با توجه به روابطي كه مطرح شد ارتباطات ديگري در جهت مخالف نيز بين دولت و اركان جامعه وجود دارد كه مي‌توان به يكي از آنها اشاره كرد:

• C2G: عبارت است از ارتباطي ميان دولت و مردم كه طي آن شهروندان اطلاعاتي را به دولت ارائه مي‌دهند. به عنوان مثال در يك رأي‌گيري الكترونيكي فرم‌ها و آرائي كه شهروندان به دولت ارائه مي‌دهند؛ يك ارتباط C2G را به وجود مي‌آورد.

3- ويژگي‌هاي دولت الکترونيک
هدف دولت الكترونيك ارائه خدمات بهتر، با هزينه، كمتر و اثر بخشي بيشتر است؛ ولي نمي‌توان استاندارد مشخصي براي ساير ويژگي‌هاي آن معرفي كرد، زيرا هر دولتي مي‌تواند با توجه به نيازهاي جامعه خودش نظام دولت الكترونيك را پايه‌ريزي كند.

• (S (SMALL: دولت الكترونيك نبايد گستردگي بيش از حد داشته باشد؛ تا بتواند از اتلاف نيروي انساني و سرمايه جلوگيري كند. بنابراين بهتر است دولت‌هاي بزرگ به دولت‌هاي محلي كوچك‌تر تقسيم شوند.

• (M(MORAL: دولت الكترونيك بايد مقيد به اخلاق بوده و حريم اطلاعات خصوصي شهروندان را حفظ نمايد.

• (A (AUDITABLE: دولت الكترونيك بايد نسبت به فعاليت اجتماعي، اقتصادي و سياسي كه انجام مي‌دهد جوابگو باشد؛ بدين معني كه شهروندان بتوانند تا حد امكان از روند پيشرفت اين فعاليت‌ها آگاهي‌هاي لازم را كسب كنند.

• (R (RESPONSIBLE: دولت الكترونيك بايد در صورت بروز مشكلاتي ناشي از فعاليت‌هايش به مردم پاسخگو باشد.
• (T (TRANSPARENT: دولت الكترونيك بايد از موضع شفافي در رابطه با امور شهروندان برخوردار باشد.

4- مراحل تكامل دولت الكترونيك
در جريان گسترش كمي و كيفي سرويس‌هايي كه دولت الكترونيك به جامعه ارائه مي‌دهد، دولت از مراحل مختلفي عبور مي‌كند كه مي‌توان آنها رابه چهار مرحله تقسيم كرد:

- به وجود آمدن وب‌سايت‌هاي دولتي كه شامل اطلاعاتي درمورد سازمان‌هاي مختلف دولتي است.
- ايجاد وب‌سايت‌هاي دولتي كه شامل اطلاعات سازمان‌ها دريك محيط تعاملي هستند.
- ايجاد وب‌سايت‌هايي كه به سرويس‌گيرندگان اين اجازه را مي‌دهند كه بتوانند به اطلاعات شخصي مورد نياز خود دست يابند.
- گسترش وب‌سايت‌ها و شبكه‌هايي كه دائماً به شهروندان خدمات مي‌دهند و شامل سازمان‌هاي بسيار زيادي هستند كه توسط اين شبكه به يكديگر متصل شده‌اند.

مراحل پيشرفت دولت الكترونيك و سرويس‌هاي ارائه‌شده در هر مرحله در شكل زير به نمايش درآمده است.






شکل 1- مراحل تکامل دولت الکترونيک


سازمان ملل براي ارزيابي پيشرفت كشورها در برپايي دولت الكترونيك پنج مرحله زير را شناسايي نموده است:

• مرحله نوظهور
طي اين مرحله تعدادي وب‌سايت ساده و مستقل از هم توسط دستگاه‌هاي دولتي ايجاد مي‌شود كه بر روي آنها اطلاعاتي محدود و پايه‌اي گذاشته مي‌شود.

• مرحله تکامل‌يافته
در اين مرحله بر تعداد سايت‌هاي دولتي افزوده مي‌شود. در اين مرحله اطلاعات غني‌تر و پويا هستند و تغييرات با تواتر بيشتري درسايت‌ها اعمال مي‌شوند.

• مرحله تعاملي
در اين مرحله كاربران از فرم‌هاي الكترونيكي استفاده مي‌كنند و از طريق اينترنت با مقامات دولتي براي انجام كارهاي خود تماس برقرار كرده و درخواست‌ها و قرار ملاقات‌هاي خود را به صورت on line تنظيم مي‌نمايند.

• مرحله تراكنش
طي اين مرحله كاربران مي‌توانند پرداخت هزينه خدمات و يا انجام تبادلات مالي را از طريق شبكه و‌ به صورت امن انجام دهند.

• مرحله يكپارچه
طی اين مرحله كليه فعاليت‌هاي دولتي به صورت يكپارچه بر روي شبكه اينترنت ارائه خواهد شد.

5- موانع گسترش دولت الكترونيك
از ميان موانع گسترش دولت الكترونيك، مي‌توان به سه مورد اصلي اشاره كرد كه عبارتند از: فرهنگي، سازماني و محدوديت منابع.

5-1- عوامل فرهنگي
5-1-1- موقعيت كنوني
بررسي دولت‌ها و مطالعات اوليه آنها براي به اجرا درآوردن طرح دولت الكترونيك نشان داده است كه مشكل اصلي ايجاد وتوسعه دولت الكترونيك، تكنولوژي نيست، بلكه مشكل اصلي در اين است كه آيا فرهنگ جامعه آمادگي پذيرش تغييرات بسيار زيادي كه ايجاد خواهد شد را دارد يا خير.

اين تغييرات تأثير اصلي خود را بر كارمندان دولتي خواهند گذاشت. بررسي‌ها نيز نشان مي‌دهد كه عده‌اي از كارمندان دولت با تغييرات سريع در نظام اداري مخالفند. درحالي كه عده‌اي ديگر با آن موافق بوده و از آن استقبال مي‌كنند.

براي راضي كردن عموم مردم نيز بايد جامعه را متقاعد كرد كه انتقال اطلاعات به قدر كافي امن هست وحريم خصوصي افراد كاملاً رعايت مي‌شود. در ساختار سازماني يك دولت الكترونيك‌، كارمندان به جاي جلوگيري از خطر و ريسك دركارهاي اداري به مديريت ريسك مي‌پردازند.

درچنين محيطي افراد به خلاقيت و نوآوري در كارهاي اداري تشويق مي‌شوند. همچنين در جامعه اطلاعاتي پيشرفته، شهروندان و واحدهاي خصوصي به امنيت سيستم دولت الكترونيك اطمينان داشته و اكثر امور خود را از طريق آن انجام مي‌دهند، در چنين فضايي دولت نيز از خلاقيت و نوآوري حمايت مي‌كند.

5-1-2- راه رسيدن به محيط فرهنگي مطلوب
عملي ساختن دولت الكترونيك بيش از هر چيز، به مديريت و راهبري بسيار كارآمد نياز دارد. اين هيأت‌مديره تنها از متخصصان IT تشكيل نمي‌شوند؛ بلكه در اين هيأت افرادي با تخصص‌هاي اقتصاد، مديريت و جامعه‌شناسي نيز حضور خواهند داشت. گام اصلي بعدي تنظيم يك برنامه همه جانبه براي ادامه عملي ساختن دولت الكترونيك است.

5-2- عوامل سازماني و اداري
5-2-1- موقعيت كنوني سازمان‌ها وادارات
درحال حاضر، ادارات دولتي داراي روابط بين سازماني نيستند و اين به دليل فقدان يك شبكه الكترونيكي مناسب بين آنها است. مسئولان اين سازمان‌ها نيز تنها به مديريت در حوزه درون‌سازماني عادت كرده‌اند و ارتباط بين سازمان‌هاي مختلف مي‌تواند مشكلاتي را براي آنها ايجاد كند. روش تصميم‌گيري بالا به پايين نيز عامل ديگري است كه به مشكلات مديريتي دامن زده است.

5-2-2- ساختار اداري مطلوب دولت الكترونيك
در يك نظام دولتي الكترونيك، موانع و حصارهاي بين سازماني برداشته مي‌شود و دولت از يك نظام بسته و محتاط به يك نظام باز كه در آن نوآوري حرف اول را مي‌زند تبديل مي‌شود.

5-2-3- راه رسيدن به ساختار اداري مطلوب
يكي از راه‌هاي مؤثر مي‌تواند دادن پاداش به كارمندان و مديراني باشد كه به جا افتادن دولت الكترونيك در سازمان خود كمك مي‌كنند. حتي برخي دولت‌ها ارگان‌هاي خاصي را جهت دنبال كردن اين موضوع تاسيس كرده‌اند در همين حال به موازات اين فعاليت‌ها، متخصصان IT درحال ساختن زير بناي لازم براي مرتبط ساختن ارگان‌هاي مختلف به يكديگر خواهند بود.

5-3- كمبود منابع
5-3-1- وضعيت حاضر
همان‌طور كه گفته شد در حال حاضر- درجوامع پيشرفته‌اي مثل ايالات متحده - كمبودي از لحاظ منابع تكنولوژيك احساس نمي‌شود؛ اما كمبود نيروي انساني متخصص چه از لحاظ فني و چه از نظر مديريتي يك مشكل عمده در راه سرعت بخشيدن به روند تغير به دولت الكترونيك به شمار مي‌رود. از طرفي به دليل نو و بديع بودن اين موضوع در واقع مي‌توان گفت كه هيچ نيروي مديريتي با تجربه‌اي، براي پياده‌سازي دولت الكترونيك در سطح جامعه وجود ندارد.

5-3-2- وضعيت مطلوب براي پياده سازي دولت الكترونيك
يك موج جديد از افراد تحصيل‌كرده در فناوري اطلاعات و مديريت وارد دولت مركزي خواهند شد. از طرفي بهتر است دولت تا حد امكان به وسيله آموزش و حقوق بيشتر به جذب افراد شايسته از بين كاركنان فعلي دولت اقدام كند؛ زيرا اين افراد با ساختار دولتي و اداري آشنايي بيشتري دارند.

5-3-3- راه رسيدن به وضعيت مطلوب
گرچه استخدام مديراني كه توانايي‌هاي گسترده‌اي در فناوري اطلاعات دارند، يك اقدام اساسي و اصولي محسوب مي‌شود؛ اما آموزش مديران قديمي و استفاده از آنها اين مزيت را دارد كه اين افراد مي‌توانند درهزينه‌ها صرفه‌جويي كرده و اعتبارات مازاد را براي بهبود كيفيت زيرساخت‌هاي تكنولوژيك دولت الكترونيك به كار گيرند.




+ نوشته شده در  ساعت   توسط فرهاد شرف پور  | 

معماري مبتني بر سرويس رويکرد جديدي در دنياي نرم‌افزار است که با رفع محدوديت‌ها و
نواقص معماري‌هاي پيشين به عنوان بهترين گزينه در اين زمينه محسوب مي‌گردد. در اين
مقاله سعي شده است مفاهيم و اصول پايه‌اي اين معماري به طور اجمالي مورد بررسي قرار
گيرد.


 

مقدمه
سيستم‌هاي اطلاعاتي به سرعت در حال رشد هستند؛ سازمان‌ها نيازمند پاسخگويي سريع به نيازمندي‌هاي جديد کسب‌وکار هستند. اين در حالي است که معماري‌هاي نرم‌افزاري موجود به حد نهايي قابليت‌هاي خود رسيده‌اند. معماري مبتني بر سرويس SOA قدم تکاملي بعدي براي کمک به سازمان‌ها جهت مديريت چالش‌هاي پيچيده است.

معماري مبتني بر سرويس حالت بلوغ يافته معماري مبتني بر اجزا، طراحي مبتني بر واسطه (شي‌گرا) و سيستم‌هاي توزيع ‌شده است. در معماري مبتني بر اجزا عملکرد کلي به کارهاي کوچک‌تري تقسيم مي‌شود که هر يک در يک جزء بسته‌بندي خواهند شد. يک سيستم توزيع‌شده، تعميمي از يک معماري مبتني بر اجزا است که به اجزائي که در موقعيت‌هاي فيزيکي مختلف وجود دارند، اشاره مي‌کند.

مهم‌ترين مزيت معماري مبتني بر اجزا سهولت در استفاده مجدد و تغيير هدف اجزاي خاص و سهولت در امر نگهداري سيستم است. استفاده مجدد و تغيير هدف معمولاً مهم‌ترين پيشران‌هاي کسب‌و کار جهت استفاده از اين نوع معماري در دهه 90 ميلادي بوده است. بر اساس منطق معماري مبتني بر سرويس، سيستم‌هاي نرم‌افزاري بزرگ مي‌توانند از گردآوري مجموعه‌هايي از عملکردهاي مستقل و قابل استفاده مجدد تشکيل گردند.

برخي از اين عمليات مي‌تواند از طريق سيستم‌هاي موجود و يا سيستم‌هاي ديگر فراهم گردد ولي ساير عمليات لازم بايد پياده‌سازي شوند. هر سرويس امکان دسترسي به مجموعه خوش‌ تعريفي از عمليات را مي‌دهد. سيستم به عنوان يک کل به صورت مجموعه‌اي از تعاملات بين اين سرويس‌ها طراحي مي‌شود. معماري مبتني بر سرويس، سرويس‌هايي را که سيستم از آنها تشکيل شده را تعريف ‌مي‌کند و تعاملات لازم بين سرويس‌ها جهت ارائه رفتار مشخص را توصيف ‌مي‌کند و در نهايت سرويس‌ها را به يک يا چند پياده‌سازي در تکنولوژي‌هاي خاص تصوير مي‌کند.

SOA بر اساس استفاده از اشياء و اجزا توزيع شده است و قدم تکامل بعدي در محيط‌هاي محاسبه‌اي است. اين معماري در حال حاضر مدل مرجع استانداردي ندارد؛ اما پياده‌سازي‌هاي موجود مفاهيم مشترکي را مورد استفاده قرار مي‌دهند که در ادامه اين مفاهيم پايه مورد بررسي قرار مي‌گيرند.

2- مفاهيم اصلي در معماري مبتني بر سرويس
در حال حاضر استاندارد مشخصي براي تعريف SOA وجود ندارد اما مواردي که در ادامه مي‌آيد مهم‌ترين و سازگارترين موارد در پياده‌سازي SOA هستند.

2-1- سرويس‌
يک سرويس رفتار تعريف شده قراردادي است که مي‌تواند به‌وسيله يک جزء براي استفاده جزء ديگر پياده‌سازي شده و فراهم گردد.

2-2- شرح سرويس
شرح سرويس پارامترهاي فني، قيود و سياست‌هايي را شامل مي‌شود که قالب‌هاي لازم براي فراخواني سرويس را تعريف مي‌کند. هر سرويس بايد شامل تعريف سرويس در قالب استاندارد باشد. اين موضوع کاربردها و کاربران انساني را قادر مي‌سازد تا با بررسي شرح سرويس و تعيين موضوعاتي نظير اين‌ که سرويس چه کاري انجام مي‌دهد، چگونه به آن انتصاب مي‌يابند و اين‌که چه پروتکل‌هاي امنيتي (در صورت وجود) بايد به همراه آن مورد استفاده قرار گيرد، از آن سرويس استفاده کند.

اين اعلان همچنين ممکن است شامل جزئياتي در مورد هر فرايند ضمني و ديگر واژه‌هاي کاري و قانوني باشد که ممکن است در زمان فراخواني سرويس اتفاق بيفتد. به عنوان مثال، اگر يک استفاده‌کننده سرويس، سرويسي را فراخواني کند که يک درخواست خريد را براي فراهم‌کننده سرويس ارسال نمايد، و اجرا موفقيت‌آميز باشد، اين موضوع ممکن است منجر به مسئوليت مالي نسبت به فراهم‌کننده سرويس يا بخش قانوني ديگر مي‌شود.

در حاليکه طبيعت سرويس‌ها ممکن است تغيير کند، استاندارد مشترکي جهت اعلان يک سرويس هنگام تهيه يک زيرساخت مطلوب است. دو نمونه از چنين استانداردهاي موجود ebXML و WSDL هستند.

2-3- اعلان و يابش سرويس‌ها
شرح سرويس بايد به شيوه‌اي قابل دسترسي در اختيار کاربران بالقوه قرار گيرد که به اين امر اعلان سرويس اطلاق مي‌شود.

يابش، ‌زماني انجام مي‌شود که يک مشتري بالقوه اطلاعاتي در مورد وجود يک سرويس، پارامترهاي قابل اعمال و واژگان آن به دست آورد. يافتن، بحث تصديق هويت جهت اجراي سرويس را شامل نمي‌شود؛ گرچه اين جزئيات ممکن است در الگوي يافتن قرار گيرد.

اجزاي اعلان و يابش در SOA به شيوه‌هاي مختلف از جمله استفاده از روش ثبات / مخزن و يا روش دايرکتوري سرويس قابل پياده سازي هستند.

• پياده‌سازي به روش ثبات / مخزن
يک ثبات / مخزن جزئي است که در آن کاربران امکان ذخيره و مديريت سرويس‌هاي لازم براي عملکرد سازمانشان را خواهند داشت. اين موضوع شامل سرويس‌هايي است که تسهيم بين بيش از يک کاربر (نظير xml schemas و شرح web-service) را فراهم مي‌آورد که به ثبات به گونه‌اي منتسب مي‌شود که ثبات در مورد تمامي رويدادهاي قابل ارزيابي نسبت به محصولات در مخزن اطلاع دارد.

• پياده‌سازي به روش دايرکتوري
دايرکتوري يک واسط است که اطلاعات انتساب به محصولات را فراهم مي‌آورد. افرادي که مالک محصولات هستند و يا آنها را کنترل مي‌کنند، مي‌توانند يک مدخل به دايرکتوري باز کرده تا به محصولات ارجاع داده و خود انتسابات به آن را توضيح دهند. ديگران ممکن است اين اطلاعات را بازيابي کرده و از آن جهت انتساب به محصولات استفاده کنند. مهم‌ترين مشکل دايرکتوري اين است که هيچ کنترل يا اطلاع‌رساني در صورت حذف، تغيير و جايگزين شدن يک محصول انجام نمي‌دهد و قادر به اعلام اين رويدادها به کاربران نيست.

هر دو پياده‌سازي دايرکتوري و ثبات / مخزن امکان سازگاري با يکديگر را دارند. به اين معنا که عملکرد اجازه مي‌دهد که محتوا از يک پياده‌سازي توسط يک پياده‌سازي ديگر مورد ارجاع قرار گيرد.
چندين استاندارد وجود دارد که پياده‌سازي‌ها دايرکتوري و ثبات / مخزن را دارند. رايج‌ترين استانداردها عبارتند از:



• OASIS ebXML Registry-Repository Technical Specifications16
• OASIS Universal Description and Discovery Interface (UDDI) Technical Specification17.2




2-4- خصوصيات مدل داده‌اي مرتبط
در هنگام فراخواني يک سرويس، پارامترهاي مشخصي ممکن است براي انجام درخواست سرويس مورد نياز باشد. سرويس همچنين ممکن است پارامترهايي را به کاربر سرويس بازگرداند. W3C WSDL يک نمونه شناخته شده از پياده‌سازي اين بخش است.

3- اصطلاحات رايج در معماري مبتني بر سرويس
• فراهم‌کننده سرويس: يک موجوديت نرم‌افزاري که خصوصيات سرويس را پياده‌سازي مي‌کند.
• درخواست‌کننده سرويس: يک موجوديت نرم‌افزاري که يک فراهم‌کنندة سرويس را فراخواني مي‌کند، به‌طور سنتي اين مورد به عنوان "کلاينت" شناخته مي‌شود؛ اما يک درخواست‌کننده سرويس مي‌تواند يک کاربر برنامه کاربردي و يا سرويس ديگر باشد.
• موقيعت‌ياب سرويس: يک نوع خاص از فراهم‌کننده سرويس که به‌عنوان يک ثبات عمل مي‌کند و امکان جست‌وجوي واسطه‌هاي فراهم‌کننده سرويس و موقعيت سرويس را مي‌دهد.
• واسط سرويس: يک نوع خاص از فراهم‌کننده سرويس است که مي‌تواند درخواست سرويس را به يک يا چند فراهم‌کننده سرويس منتقل کند.

4- چارچوب SOA
4-1- زيرساخت SOA
4-1-1- نقشه مفهومي

شکل‌هاي 2 تا 4 نقشه‌هايي مفهومي هستند که مفاهيم پايه SOA را مستقل از معني و تکنولوژي‌ها تشريح مي‌کنند. نقشه‌هاي مفهومي غير رسمي بوده و نمايش گرافيکي از مفاهيم و رابطه بين آنها را شامل مي‌شود. شکل 2 مثالي از يک نقشة مفهومي است.






 


شکل1- مثالي از نقشه مفهومي


 

اغلب معماري‌هايي که SOA ناميده مي‌شوند، شامل يک فراهم‌کننده سرويس، يک کاربر سرويس و برخي زيرساخت‌هاي پيام‌رساني هستند.







 


شکل2- مدل مرجع معماري مبتني بر سرويس پايه




4-1-2- مفاهيم اختياري و زيرساخت‌هاي SOA اشتراکي







 


شکل3-مفاهيم اختياري براي SOA و نمايش تعامل آنها با مفاهيم پايه اين معماري




جهت اجراي تعهدات در زمان اجرا، اغلب SOAها ممکن است شامل مفاهيمي اضافه بر آنچه در شکل 3 نشان داده شده است، باشند. مفاهيم ديگر کاربران سرويس، کلاينت سرويس، قرارداد پذيرش سرويس و فراخواني سرويس هستند. فراخواني يک سرويس يا وجود کاربر سرويس در مدل SOAالزامي نيست. فراهم‌کننده يک سرويس، قرارداد سرويس جهت استفاده آن و شرح سرويس را ارائه مي‌کند. شرح سرويس به مدل داده‌هاي مرتبط با فراخواني سرويس ارجاع مي‌کند.

شرح سرويس از طريق يکي از چندين روش اعلان مي‌شود. کاربر سرويس خصوصيات سرويس را از طريق مکانيزم اعلان شناسايي مي‌کند. شناسايي، پذيرش قرارداد را شامل نمي‌شود. همچنين فراخواني سرويس را نيز القا نمي‌کند. اين امر صرفاً عملي براي پيدا کردن اطلاعات در مورد سرويس است. اين امر لزوماً در يک عمل اتفاق نمي‌افتد و ممکن است به تعدادي از کارها نياز داشته باشد. همچنين ممکن است از طريق وسايل غير الکترونيکي صورت پذيرد.

شکل 4 ساير عملکردهاي خاص اختياري را حذف کرده و از پياده‌سازي‌هاي خاص نظير پيام‌رسانيSOAP ، WDSL و ebXML خودداري مي‌کند.

4-2- الگوهاي SOA
شکل 5 يک الگوي ساده سرويس را نمايش مي‌دهد. در جايي که يک فراهم‌کننده سرويس، سرويس را پيشنهاد مي‌دهد و يک کاربر سرويس، از سرويس‌ها استفاده مي‌کند. چندين نوع از پروتکل‌هاي ارتباطي ممکن است زوج درخواست/ پاسخ را مورد استفاده قرار دهد و روش‌هاي متنوعي نظير سنکرون يا آسنکرون ممکن است استفاده شود. SOA به هيچ پروتکل ارتباطي خاص محدود نمي‌شود. شکل 5 الگوي "درخواست – پاسخ" را نمايش مي‌دهد.







 


شکل4-الگوي پايه براي معماري مبتني بر سرويس




5- چرخه حيات SOA
بر اساس طرح IBM، براي SOA مي‌توان يک چرخه حيات در نظر گرفت. در فاز "مدل" نيازمندي‌هاي کسب‌و کار جمع‌آوري شده و فرايندهاي کسب و کار آنها طراحي مي‌شود. بعد از بهينه شدن فرايندها، از طريق کنار هم قرار دادن سرويس‌هاي موجود و سرويس‌هاي جديد اين فرايندهاي کسب‌و کار شکل مي‌گيرد. سپس اين سرمايه‌ها در يک محيط امن و با قابليت تجميع بالا نصب مي‌شود. بعد از نصب فرايندهاي کسب و کار، کاربران IBM اين فرايندهاي کسب و کار را هم از منظر فني و هم از منظر فرايندهاي کسب و کار مورد نظارت و مديريت قرار مي‌دهند.

اطلاعات جمع‌آوري شده در فاز مديريت به چرخه حيات بازخورد خواهد داشت تا بهبود پيوسته فرايندها را امکان‌پذير سازد. در زير همه اين مراحل در چرخه حيات، حاکميت و فرايندهايي هستند که رهنمود‌ها و افق‌هاي آينده را براي پروژه SOA فراهم مي‌کنند.







 


شکل 5- چرخه حيات معماري مبتني بر سرويس




6-1- مرحله مدل‌سازي
فاز مدل با جمع‌آوري و تحليل نيازمندي‌هاي کسب‌و کار آغاز مي‌شود که بعداً براي مدل کردن، شبيه‌سازي و بهينه کردن فرايندهاي کسب و کار مورد استفاده قرار مي‌گيرند. فرايندهاي کسب و کار حاصل براي طراحي سرويس‌هاي نرم‌افزاري مرتبط و سطوح سرويس جهت حمايت از اين فرايندها مورد استفاده قرار مي‌گيرند. در طول اين فاز، مدلي جهت ايجاد درک مشترک بين کسب و کار و فناوري اطلاعات در فرايندهاي کسب و کار، اهداف و خروجي‌ها استفاده مي‌شود. به علاوه اين مدل مي‌تواند اين اطمينان را به وجود آورد که کاربردهاي حاصل، نيازمندي‌هاي کسب و کار تعريف شده را براورده مي‌سازد. اين مدل همچنين مي‌تواند مبنايي جهت اندازه‌گيري کارآيي کسب و کار باشد.

6-2- مرحله گردآوري
در طول فاز گردآوري، کتابخانه سرويس‌هاي موجود مي‌تواند جهت يافتن سرويس‌هاي مورد نظر و موجود در سازمان بررسي شود. در صورتي که سرويس مورد نظر يافت نشد اين امکان وجود دارد که يک سرويس جديد ايجاد و پس از تست به مجموعه افزوده شود. هنگامي که سرويس‌هاي مورد نياز فراهم شد، سرويس‌ها جهت پياده‌سازي فرايندهاي کسب‌و کار هماهنگ مي‌گردند.

6-3- مرحله نصب
در طول فاز پياده‌سازي، مقياس و محيط زمان اجرا جهت تأمين نيازمندي‌هاي سطوح سرويس به وسيله فرايندهاي کسب‌وکار پيکربندي مي‌شود. پس از پيکربندي يک فرايند کسب‌وکار، امکان پياده‌سازي آن در يک محيط امن، مطمئن و مقياس‌پذير سرويس‌ها وجود خواهد داشت. محيط سرويس‌ها به گونه‌اي بهينه‌سازي مي‌شود که علاوه بر اجراي مطمئن فرايندهاي کسب‌وکار، امکان انعطاف‌پذيري جهت بروز کردن به طور پويا و در صورت تغيير نيازمندي‌هاي کسب‌وکار را فراهم مي‌آورد. اين رويکرد مبتني بر سرويس همچنين هزينه و پيچيدگي نگهداري سيستم را نيز کاهش مي‌دهد.

6-4- مرحله مديريت
فاز مديريت شامل نظارت و نگهداري از زمان پاسخ و در دسترس بودن سرويس مي‌شود. همچنين مديريت منابع سرويس‌هاي زيرين در اين فاز انجام مي‌شود. درک کارايي زمان واقعي فرايندهاي کسب‌وکار امکان ايجاد بازخورد ضروري به مدل فرايند کسب و کار جهت بهبود دائمي را فراهم مي‌آورد. اين کار همچنين مديريت و نگهداري کنترل نسخه براي سرويس‌هاي تشکيل دهنده فرايندهاي کسب و کار را شامل مي‌شود. فاز مديريت در نهايت امکان اتخاذ تصميمات کسب و کار بهتر و سريع‌تر را فراهم مي‌سازد.

6-5- مرحله حاکميت و فرايندها
حاکميت و فرايندها جهت موفقيت هر نوع پروژه SOA ضروري هستند. جهت تخمين موفقيت، ممکن است يک مرکز تعالي در کسب‌وکار، براي پياده‌سازي سياست‌هاي حاکميتي و دنبال کردن استانداردهاي حاکميتي بين‌المللي جهت اهداف کنترلي براي اطلاعات و تکنولوژي مرتبط ايجاد گردد. پياده‌سازي سياست‌هاي حاکميتي قوي مي‌تواند منجر به پروژه‌هاي SOA موفق گردد.

7- خصوصيات اساسي جهت استفادة بهينه از سرويس‌ها
• درشت‌دانه بودن: عملکردها روي سرويس‌ها به طور متفاوت پياده‌سازي مي‌شوند تا کارآيي بيشتري را در برگيرند و بر روي مجموعه‌هاي داده‌اي بزرگ‌تر در مقايسه با طراحي مبتني بر اجزا عمل مي‌کند. (شکل 8)
• طراحي مبتني بر واسط: سرويس‌ها، واسط‌هاي مجزا‌ ‌تعريف‌شده را پياده‌سازي مي‌کنند. مزيت اين امر آن است که چندين سرويس مي‌توانند يک واسط مشترک را پياده‌سازي کنند و يک سرويس مي‌تواند چندين واسط را پياده‌سازي کند. (شکل 9)
• قابل يافت بودن: سرويس‌ها لازم است هم در زمان طراحي و هم در زمان اجرا قابل يافت باشند، نه تنها با شناسة يکتا بلکه همچنين با شناسة واسط و با نوع سرويس.
• نمونه منفرد: بر خلاف توسعة مبتني بر جزء که از اجزا بر حسب نياز نمونه‌هايي ايجاد مي‌شود، هر سرويس يک نمونه منفرد و همواره در حال اجرا است که مجموعه‌اي از کلاينت‌ها با آن ارتباط برقرار مي‌کنند.
• اتصال ست: سرويس‌ها با ديگر سرويس‌ها و کلاينت‌ها از طريق تبادل اطلاعات استاندارد xml با يکديگر در ارتباط هستند؛ اين ارتباط باعث کاهش وابستگي و جداسازي بر اساس پيام‌رساني مي‌شود.
• آسنکرون: به طور کلي، سرويس‌ها از رويکرد انتقال پيام آسنکرون استفاده مي‌کنند. اما اين امر ضروري نيست. در بعضي مواقع در پياده‌سازي سرويس‌ها از انتقال پيام سنکرون نيز استفاده مي‌شود.
در شکل‌هاي زير برخي از ويژگي‌هاي فوق نمايش داده شده است:







 


شکل 6- تأکيد بر درشت‌دانه بودن در سرويس‌ها




 





 


شکل 7- طراحي مبتني بر واسط در معماري سرويس‌گرا




8- مقياس‌پذيري از طريق رفتار آسنکرون و صف‌بندي
بهتر است که از ماهيت آسنکرون در ‌سرويس‌ها استفاده شود. با توجه به سربار انتقال اضافه و همچنين اين انتظار که سرويس‌ها، ماهيتاً در فواصل فيزيکي دور از يکديگر خواهند بود، کاهش زمان انتظار درخواست‌کننده براي پاسخ بسيار اهميت دارد. از طريق آسنکرون کردن فراخواني يک سرويس، با يک پيام بازگشت مجزا، به درخواست‌کننده امکان ادامة اجرا تا زمان فراهم شدن پاسخ داده مي‌شود.

البته اين به معناي اشتباه بودن رفتار سنکرون سرويس نيست، بلکه به اين معنا است که رفتار سرويس آسنکرون مطلوب است، به خصوص در جايي که هزينه‌هاي ارتباطي زياد است و يا تأخير شبکه قابل پيش‌بيني نيست.






 


شکل8- روش سنکرون در مقابل روش آسنکرون




با استفاده از فراخواني آسنکرون، به فراهم‌کننده اين امکان داده مي‌شود که از چندين رشتة کاري جهت مديريت چندين درخواست کلاينت استفاده کند. جهت اجراي فراخواني آسنکرون، درخواست‌کننده بايد نشاني بازگشت را به سرويس پياده‌ساز يک واسط ارسال کند.

9- جمع‌بندي
معماري مبتني بر سرويس گام تکاملي بعدي در دنياي نرم‌افزار است. معماري‌هاي نرم‌افزاري فعلي قادر به حل تمامي مشکلات و چالش‌هاي فرا روي سازمان‌ها و سيستم‌هاي اطلاعاتي بزرگ و پيچيده نيستند. ويژگي‌هاي خاص معماري مبتني بر سرويس اين معماري را به عنوان بهترين گزينه براي اين موضوع مطرح کرده است.


 





 

+ نوشته شده در  ساعت   توسط فرهاد شرف پور  | 

طراحی پايگاه داده و ايجاد نمودار ارتباط موجوديت ها (ERD) يکی از مهمترين بخش های چرخه حيات توسعه يک نرم افزار است  که در برخی موارد از آن به عنوان مهمترين بخش نيز نام برده می شود . مدل صحيح و به هنگام (Up To Date) اطلاعات می تواند به عنوان مهمترين ابزار مرجع برای مديران بانک اطلاعاتی (DBAs) ، پياده کنندگان نرم افزار و ساير اعضاء تيم توسعه دهنده نرم افزار باشد . فرآيند ايجاد مدل داده به تيم توسعه دهنده کمک می کند تا به پرسش های مطرح شده توسط کاربران نهائی سيستم پاسخ دهند .همچنين طراحی کارا و موثر پايگاه داده به تيم توسعه دهنده اين امکان را می دهد تا سيستم را از همان ابتدا در فرم مناسب پياده سازی نمايند . ساخت سيستم با کيفيت فوق الذکر اين امکان را به تيم توسعه دهنده خواهد داد تا زمان کلی انجام پروژه را کاهش دهند ، که در واقع اين امر موجب کاهش هزينه های توسعه پروژه نيز خواهد شد .
با توجه به موارد فوق ، شعار طراحی خوب و جامع پايگاه داده اين است که :
 

 

 اول اندازه بگير و بعد قيچی کن

طراحان خوب و خبره بانک های اطلاعاتی ، مبانی و اصول نرمال سازی پايگاه داده را همواره در خلال طراحی به خاطر داشته و آن را به کار خواهند گرفت . همانطور که در مقاله نرمال سازی بانك های اطلاعاتی   به تفصيل بيان شد ، نرمال سازی فرآيندی در خلال طراحی پايگاه داده است كه با چهار هدف عمده ذيل دنبال می شود :

  • به حداقل رسانی افزونگی اطلاعات
  • به حداقل رسانی تغيير ساختار اطلاعات
  • به حداقل رسانی I/O سرور به منظور کاهش تعداد تراکنش ها (Transactions)
  • و در نهايت حفظ يکپارچگی اطلاعات

برای طراحی بانک اطلاعاتی نرم افزار و مدل سازی آن می بايست اصول و تکنيک های ذيل را مد نظر داشت و از آنها استفاده نمود .

موجوديت (Entity) ،  مجموعه ای از چيزهائی است که مربوط به بانک اطلاعاتی سيستم مورد نظر می باشد و يا به تعبير ديگر هر آنچه كه می خواهيد در سيستم راجع به آن اطلاعات جمع آوری و نگهداری نمائيد را شامل می شود  . در مدل فيزيکی ،  موجوديت تبديل به جدول (Table) می شود .

خصلت (Attribute) يکی از مشخصه های توصيفی و يا مقداری موجوديت می باشد . در مدل فيزيکی يک خصلت به يک ستون (Column) و يا فيلد (Field) تبديل می شود .

کليد اصلی (Primary Key) خصلت و يا ترکيبی از خصلت ها در يک موجوديت است که تضمين کننده يکتا بودن هر رخداد از موجوديت می باشد . خصلت يا خصلت های کليد اصلی نمی توانند فاقد ارزش باشند (NULL) و معمولا" کمتر تغيير می کنند . معمولا" سعی می شود جهت انتخاب کليد اصلی از خصلت هائی استفاده شود که کارائی بيشتری داشته و بهترين معرف موجوديت باشند (کارائی يک فيلد از نوع Integer به مراتب بيشتر از فيلدی از نوع Char است ) . در صورتيکه نتوان در يک موجوديت خصلت يا خصلت هائی برای کليد اصلی شدن يافت ، آنگاه کليدهای دستی برای اين كار را ايجاد می كنيم که به آنها کليد Artificial می گويند .

ارتباط ( Relationship) ، ارتباط منطقی بين دو موجوديت است . يک ارتباط در واقع نشان دهنده قوانين کاری حاکم بر پروژه و اطلاعات آن است که معمولا" به صورت جملات فعلی توصيف می گردد . مثل ارتباط بين موجوديت کارمند و دپارتمان که به صورت جمله ذيل بيان می شود :
"کارمند شاغل است در دپارتمان" در اين مثال ارتباط بين موجوديت کارمند و دپارتمان با جمله "شاغل است" توصيف ميگردد .
دو نوع ارتباط می تواند بين موجوديت ها وجود داشته باشد :

  • ارتباط يک به چند (One To Many) در اين نوع ارتباط ، هر رخداد از موجوديت والد با چندين رخداد در موجوديت فرزند ارتباط دارد . به عنوان مثال چندين کارمند می توانند در يک دپارتمان شاغل به کار باشند .

  • ارتباط چند به چند (Many To Many) . در اين نوع ارتباط ، چند رخداد از يک موجوديت با چند رخداد از موجوديت ديگر ارتباط دارند . به عنوان مثال اگر يک کارمند بتواند در چند دپارتمان شاغل به کار باشد ، آنگاه ارتباط بين موجوديت کارمند و دپارتمان يک ارتباط چند به چند است . ارتباط چند به چند در طراحی پايگاه داده پذيرفته شده نيست چراکه علاوه بر افزونگی اطلاعات موجب عدم يکپارچگی اطلاعات نيز می گردد ، از اينرو بايد اين ارتباط طبق فرم چهارم نرمال سازی تبديل به دو ارتباط يک به چند شود . همانطور که در مقاله نرمال سازی بانك های اطلاعاتی  اشاره گرديد براي حل اين مشکل کافی است يک موجوديت واسط که به آن موجوديت XREF می گويند ايجاد و خصلت های کليد اصلی هردو موجوديت را به اين موجوديت رابط منتقل نمود . با اين عمل هريک از موجوديت های اصلی به عنوان والد اين موجوديت رابط تلقی شده و يک ارتباط يک به چند بين آنها برقرار خواهد شد. در نتيجه يک ارتباط چند به چند تبديل به دو ارتباط يک به چند خواهد شد . لازم به ذکر است که بسياری از سيستم های مديريت بانک های اطلاعاتی رابطه ای ( نظير MS SQL Server) از ارتباط چند به چند پشتيباني نمی کنند .

کليد خارجی (Foreign Key) . هرگاه خصلت(های) کليد اصلی موجوديت والد در موجوديت فرزند وجود داشته باشد (بر اساس ارتباط تعريف شده بين دو موجوديت) آنگاه اين خصلت ها در موجوديت فرزند ، کليد خارجی ناميده می شوند . در واقع نمی توان هيچ رخدادی در موجوديت فرزند (که دارای کليد خارجي است) ايجاد نمود که رخداد مربوط به آن (بر اساس محتوای خصلت کليد خارجی) قبلا" در موجوديت والد ايجاد نشده باشد . آنگونه که از توصيف فوق استنباط می شود کليد خارجی تضمين کننده يکپارچگی اطلاعات در داخل پايگاه داده است چرا که باعث می شود كه هيچ فرزند بدون والدی در بانک اطلاعاتی نداشته باشيم .

ارتباط (RelationShip) بين دو موجوديت به دو مدل ذيل دسته بندی می گردد :

  • ارتباط تعريف شده (identifying Relationship) . اگر کليد اصلی جدول والد بخشی (يا تمام)  از کليد اصلی جدول فرزند باشد و يا به تعبير ديگر بخشی از کليد اصلی موجوديت فرزند کليد خارجی نيز باشد ، در اين حالت ارتباط مابين اين دو موجوديت از نوع تعريف شده است . 

  • ارتباط تعريف نشده (Non-Identifying Relationship) ، برخلاف مورد فوق اگر کليد اصلی جدول والد در جدول فرزند وجود داشته باشد اما نه به عنوان بخشی از کليد اصلي آن و صرفا" به عنوان يک خصلت غير کليد ، در اين حالت ارتباط بين اين دو موجوديت از نوع تعريف نشده می باشد . ارتباط تعريف نشده خود دارای دو حالت متفاوت به شرح ذيل است :
     mandatory non-identifying relationship ، زمانی است که خصلت کليد خارجی در موجوديت فرزند نتواند فاقد ارزش باشد (Not Allow NULL)
     non-mandatory non-identifying relationship ، زمانی است که خصلت کليد خارجی در موجوديت فرزند بتواند فاقد ارزش باشد (Allow NULL)

 Cardinality ، به ما در فهم بيشتر ماهيت ارتباط مابين موجوديت والد و فرزند کمک می کند . جهت تشخيص Cardinality يک ارتباط کافی است به سئوال ذيل پاسخ داده شود :
" چه تعداد رخداد از موجوديت فرزند مرتبط است با هر رخداد از موجوديت والد؟ " 
چهار نوع Cardinality مختلف به شرح ذيل وجود دارد :

  • One To Zero or Many به اين معنی که هر رخداد از موجوديت والد با هيچ و يا چند رخداد از موجوديت فرزند مرتبط است . به اين نوع Common Cardinality می گويند.

  • One To One Or Many به اين معنی که هر رخداد از موجوديت والد با حداقل يک و يا چند رخداد از موجوديت فرزند مرتبط است . به اين نوع P Cardinality می گويند .

  • One To Zero Or One ، به اين معنی که هر رخداد از موجوديت والد با هيچ و يا تنها يک رخداد از موجوديت فرزند مرتبط است . به اين نوع Z Cardinality می گويند .

  • One to Exactly N ، به اين معنی که هر رخداد از موجوديت والد بايد با N رخداد از موجوديت فرزند مرتبط باشد . به اين نوع N Cardinality می گويند .

 خلاصه

  • طراحی خوب بانک اطلاعاتی می تواند به تيم توسعه دهنده نرم افزار در کاهش زمان انجام پروژه و هزينه های آن کمک کند .

  • طراحی بانک اطلاعاتی و مدل سازی آن به تيم توسعه دهنده نرم افزار کمک خواهد کرد تا درک بهتر و عميقتری نسبت به نيازمنديهای کاربران نرم افزار پيدا کرده و در نتيجه نرم افزاری را توسعه دهند که در برگيرنده قوانين کاری و خواسته آنها باشد .

  •  يكی از اهداف اصلی طراحی بانک اطلاعاتی و مدل سازی آن ، مستقل بودن آن از پلت فرم است ، بنابر اين اختيار انتخاب محيط و پلت فرم پياده سازی فيزيكی پايگاه داده با تيم توسعه دهنده بوده و در ماحصل کار هيچ تغييری ايجاد نخواهد کرد .






+ نوشته شده در  ساعت   توسط فرهاد شرف پور  | 

قبل از پرداختن به موضوع بانک های اطلاعاتی رابطه ای (Relational Data Base) ، بهتر است اشاره ای به مفاهيم ذيل داشته باشيم :

  • موجوديت (Entity)
    به هر چيزی (شی ، شخص ، محل و ...) که می خواهيم در يک سيستم راجع به آن اطلاعاتی را جمع آوری ، پردازش و نگهداری نمائيم ، يک موجوديت گفته می شود . تعريف فوق ، متداولترين برداشت اوليه از موجوديت می باشد . مجموعه موجوديت های يک سيستم ، ساختار اطلاعاتی آن سيستم را مشخص می كند . هر موجوديت شامل اجزاء و المان هائی است که آن موجوديت را توصيف می كند كه به آنها  خصيصه و يا Attribute گفته می شود . هر موجوديت بسته به اين كه  در سيستم مورد مطالعه چه ميزان اطلاعات راجع به آن می خواهيم داشته باشيم ، شامل حداقل يک و يا چند خصيصه خواهد بود. از آنجا که هر موجوديت راجع به يک موضوع به خصوص می باشد ، بنابراين يک ارتباط منطقی بين کليه خصايص موجوديت وجود خواهد داشت .در واقع  ،‌ تمام خصائص يک موجوديت توصيف کننده آن موجوديت خواهد بود . برای روشن شدن موضوع بد نيست به نمونه مثال ذيل توجه نمائيد :
    -  موجوديت مشتری شامل خصلت های نام مشتری ، آدرس مشتری ، تلفن مشتری و ... است .
    - موجوديت سفارش شامل خصلت های شماره سفارش ، تاريخ سفارش ، نام مشتری ، کالای سفارش شده ، تعداد کالای سفارش شده و ... است
    همانگونه که در مثال فوق مشاهده گرديد ،  تمام خصلت های موجوديت مشتری توصيف کننده يک مشتری و تمام خصلت های موجوديت سفارش توصيف کننده يک سفارش می باشند .

  • کليد (Key)
    هر رخداد از يک موجوديت را بايد بتوان به وسيله يک و يا ترکيبی از چند خصيصه آن به صورت يکتا شناسائی نمود . به تعبير ديگر ، هر يک از رخدادهای يک موجوديت بايد يکتا باشد ، در غير اينصورت تغيير و يا حذف يک رخداد از موجوديت (در مثال فوق يک مشتری) غير ممکن خواهد بود . از اينرو از بين خصلت های يک موجوديت يک و يا ترکيبی از چند خصيصه به عنوان کليد آن موجوديت انتخاب می شود .  اين خصلت (و يا ترکيب خصلت ها) بايد بتواند يکتائی هر رخداد از موجوديت را تضمين نمايد . در موجوديت سفارش مثال فوق ، خصلت شماره سفارش می تواند بعنوان کليد انتخاب شود .
    توضيح : در برخی از موارد در يک موجوديت چندين کليد وجود دارد  كه به هر يک از آنها يک Candidate Key يا Alternate Key گفته می شود .
    در برخی از حالات نمی توان در يک موجوديت هيچ کانديدی براي کليد يافت ، مانند موجوديت مشتری در مثال فوق . در اين موجوديت هيچيك از خصلت ها و يا هيچ ترکيبی از آنها نمی تواند صد درصد تضمين کننده يکتائی آن باشد (با اينکه احتمال وجود دو مشتری هم نام در يک آدرس و با يک شماره تلفن بسيار کم است ، اما باز هم احتمال وقوع دارد) . در چنين مواردی مجبور هستيم يک خصلت به موجوديت اضافه کنيم تا تضمين کننده يکتائی رخدادهای آن باشد . در مثال فوق با اضافه کردن خصلت کد مشتری به موجوديت مشتری ، می توان يکتائی آن را تضمين نمود . به اين نکته دقت شود که بسياری از خصلت های يک موجوديت در کنترل سيستم نيست و از خارج به سيستم تحميل می گردد . به عنوان مثال ما نمی توانيم تعيين کنيم که نام مشتری های سازمان تکراری نباشد . اما عدم تکراری بودن خصلت هائی که خود ما ايجاد نموده ايم را می توان تضمين کرد ( نظير کد مشتری که توسط سيستم و يا سازمان مربوطه توليد می شود )  .

  • کليد اصلی (Primary Key)
    از بين کليدهای يک موجوديت (Candidate Key) ، می بايست يک کليد را به عنوان کليد اصلی انتخاب نمود . معيارهای مختلفی در اين انتخاب دخيل هستند ، اما معمولا" بهترين کليدی که معرف مفهوم و ماهيت موجوديت باشد به عنوان کليد اصلی انتخاب می گردد .

  • وابستگی تابعی (Functional Dependency)
    وابستگی تابعی مفهومی است که مابين خصلت های يک موجوديت تعريف می گردد . به اين معني که می گوئيم خصلت A با خصلت B وابستگی تابعی دارد ، در صورتيکه به ازای هر مقدار مشخص از خصلت B بتوان مقدار مشخص و يکتائی از خصلت A را بدست آورد ، اما عکس آن ممکن است صادق نباشد . در موجوديت مشتری مثال قبل ، به ازای هر کد مشتری می توان نام او را بدست آورد در اين صورت می گوئيم خصلت نام مشتری با خصلت کد مشتری وابستگی تابعی دارد . اما عکس آن صادق نيست چرا که به ازای يک نام مشتری مشخص ، نمی توان يک کد مشتری يکتا استخراج نمود (دو مشتری مختلف می توانند نام يکسان داشته باشند ، در اين حالت يک نام مشتری ممکن است متناظر با دو  و يا حتی چند کد مشتری باشد).

  • انواع رابطه بين خصلت های يک موجوديت
    بين خصلت های يک موجوديت سه نوع رابطه وجود دارد :
    رابطه يک به يک (One To One) : در حالتی اتفاق می افتد که خصلت A وابستگی تابعی به خصلت B داشته باشد و خصلت B نيز وابستگی تابعی به خصلت A داشته باشد . در اين حالت هر دو خصلت A و B کانديدای کليد شدن می باشند.
    رابطه يک به چند (One To Many) : اگر خصلت A وابستگی تابعی به خصلت B داشته باشد و عکس آن صادق نباشد ، يك ارتباط از نوع يک به چند وجود خواهد داشت . در اين حالت ، خصلت B کانديد کليد شدن است و خصلت A صرفا" يکی از توصيف گرهای موجوديت محسوب می گردد .
     -  رابطه چند به چند (Many To Many) : اگر دو خصلت هيچکدام وابستگی تابعی به يکديگر نداشته باشند آنگاه رابطه بين آنها چند به چند خواهد بود . در اين حالت هيچيکدام از آنها کانديد کليد شدن نبوده (ممکن است ترکيب آنها کانديد کليد شدن باشد) و صرفا" توصيف کننده موجوديت خواهند بود .

  • هنجار سازی (Normalization)
    هنجار سازی ، فرآيندی است كه طی آن يك موجوديت جهت به حداقل رسانی نابهنجاری های بوجود آمده در خلال تغييرات اعمال شده بر روی رخدادهاي يک موجوديت مورد بررسی و تبديل قرار می گيرد. اگر اين فرآیند به طور صحيح بر روی يک موجوديت اعمال نگردد ، آنگاه نمی توان هيچ تضمينی در خصوص حفظ يکپارچگی اطلاعات آن موجوديت ارائه داد . فرآيند هنجار سازی به دليل اهميت و گستردگی آن  در مقاله ای جداگانه تشريح خواهد شد. 

  • نا بهنجاری
    به پيامدهای ناخواسته تغيير اطلاعات نابهنجاری گفته می شود .

  • Relation
    موجوديت ها در مدل منطقی داده های سيستم مورد بحث و بررسی قرار می گيرند و پس از طی فرآيند هنجارسازی در مرحله فيزيکی به صورت ماتريسهای دوبعدی مشتمل بر سطرها (رخدادهاي مختلف يک موجوديت) و ستون ها (خصلت های مختلف آن موجوديت) تعريف می گردند . هر يک از اين ماتريس ها را يک ارتباط يا Relation می نامند که در مدل فيزيکی معمولا" آنها را با نام جدول (Table) معرفی می کنند . همانطور که پيش از اين اشاره شد تمام خصلت های يک موجوديت با يکديگر ارتباط منطقی داشته و معرف آن موجوديت می باشند ، از اينرو به اين جداول ارتباط می گويند .

  • Tuple
    هر يک از رخدادهای مختلف يک موجوديت را يک Tuple می گويند که در مدل فيزيکی معمولا" از آنها با نام رديف (Row) و يا رکورد (Record) نام برده می شود . بنابراين Tuples ، رديف های جدول دو بعدی هستند که آن را به عنوان Relation و يا Table می شناسيم .

  • Attribute
    هريک از خصلت های مختلف يک موجوديت را Attribute می نامند ( نظير کد مشتری ) . معمولا" در مدل فيزيکی به جای Attribute از فيلد (Field) و يا ستون (Column) استفاده می شود . بنابراين Attributes ، ستون های جدول دو بعدی هستند که آن را به عنوان Relation و يا Table می شناسيم .

شكل زير يك Relation را به همراه اجزاء آن نشان می دهد :

Relation Employee
 يك Relation به همراه اجزاء آن

  • ارتباط (Relationship)
    منظور ارتباط بين دو Relation  و یا جدول است که بر اساس برابری فيلدهای يکسان در هر جدول تعريف و دارای انواع مختلفی است . ( به دليل اهميت و گستردگی ، در مقاله ای جداگانه تشريح خواهد شد) .  اين ارتباط ها در مدل منطقی مابين موجوديت ها (خصوصا" موجوديت های نرمال شده ) تعيين می گردند و به آن Entity Relation یا ER سيستم می گويند . مدل ER سيستم توسط ابزارهای مستند سازی جهت درک بهتر مدل داده ای سيستم ترسيم می گردد که به آنها ERD می گويند .

پس از تشريح برخی از مفاهيم اوليه و در عين حال مهم بانك های اطلاعاتی رابطه ای ، به اختصار می توان گفت که يک بانک اطلاعات رابطه ای مجموعه ای از رابطه ها (Relations) و يا جداول به همراه تمامی ارتباط هائی (Relationship) است که بين آنها وجود دارد  . هر بانک اطلاعاتی در خصوص يک سيستم مورد نظر طراحی و ايجاد می گردد ، اما در برخی از سازمان های بزرگ که بين سيستم های مختلف آن ارتباط وجود دارد (نظير سيستم پرسنلی ، حقوق و دستمزد و مالی و ...) ممکن است  بانک های اطلاعاتی با يکديگر تجميع  و پس از طی فرآيند يکپارچه سازی به صورت يک بانک اطلاعاتی جامع و يکپارچه برای آن سازمان تعريف و ايجاد گردد .
امروزه سيستم های مديريتی بانک های اطلاعاتی رابطه ای مختلفی وجود دارد که هر يک ويژگی ها و قابليت هايی خاص خود را دارند . به اين سيستم ها و يا نرم افزارها اختصارا" RDBMS گفته می شود .  MS ACCESS ،  MS SQL ، ORACLE ، SYBASE   ، نمونه هائی  متداول در اين زمينه می باشند .
تمامی سيستم های مديريت بانک های اطلاعاتی رابطه ای به منظور ارائه قابليت های خود و استفاده از آنها از زبان مشترکی که به آن SQL  ( برگرفته شده از Structured Query Language )  گفته می شود ، استفاده می نمايند . تمامی نيازها و انتظارات  کاربران از بانک های اطلاعاتی نظير جستجوی اطلاعات ، ايجاد ، تغيير و يا حذف اطلاعات حتی ايجاد بانک اطلاعاتی و يا ساير اجزاء مرتبط با آن توسط زبان فوق تعريف و تحويل RDBMS داده خواهد شد تا پس از بررسی بر روی بانک اعمال گردد.




+ نوشته شده در  ساعت   توسط فرهاد شرف پور  | 

نرمال سازی ( Normalization ) يا به تعبيری هنجار سازی فرآيندی است در رابطه با بانك های اطلاعاتی كه با دو هدف عمده زير انجام می شود :

  • کاهش افزونگی اطلاعات ، به اين معنی که اطلاعات فقط در يک مكان (جدول) ذخيره و در تمام بانک با استفاده از روابط منطقی تعريف شده (RelationShip) قابل دسترسی باشد .

  • حفظ يکپارچگی اطلاعات ، به اين معنی که اعمال تغييرات بر روی اطلاعات ( نظير ايجاد ، بهنگام سازی و حذف ) در يك مكان انجام و به دنبال آن آثار تغييرات در تمام بانك مشاهده گردد .  برای روشن شدن مفهوم يکپارچگی بد نيست به مثال ذيل توجه نمائيد :
    فرض كنيد در يك بانك اطلاعاتی دارای دو موجوديت كتاب و نويسنده باشيم . هر يك از موجوديت های فوق دارای المان های اطلاعاتی (Attribute) مختص به خود می باشند . به عنوان نمونه موجوديت "كتاب" دارای المان اطلاعاتی نام نويسنده  و  موجوديت "نويسنده " دارای المان های اطلاعاتی متعددی نظير نام نويسنده ، آدرس نويسنده و ... باشد .  در صورتی كه در موجوديت "کتاب"  يک رخداد (رکورد) ايجاد نمائيم بدون اينکه نام نويسنده آن را در موجوديت "نويسنده" ايجاد کرده باشيم ،  دچار يک ناهمگونی اطلاعات خواهيم شد .

با توجه به اهداف فوق می توان گفت كه فرآيند نرمال سازی از ناهنجاری های بوجود آمده به دليل بروز تغييرات در بانك جلوگيری خواهد نمود . با اعمال فرآيند نرمال سازی ، يك بانك اطلاعاتی كارآ و مطمئن را خواهيم داشت .
فرآيند نرمال سازی ، فرم های متفاوتی دارد كه انواع متداول آن به شرح ذيل است :

  • فرم اول نرمال سازی 1NF

  • فرم دوم نرمال سازی 2NF

  • فرم سوم نرمال سازی 3NF

  • فرم بويس کد نرمال سازی BCNF

  • فرم چهارم نرمال سازی 4NF

فرم اول نرمال  1NF
موجوديت و يا جدولی در فرم اول نرمال است كه تمامی المان های اطلاعاتی آن ( منظور Attribute است ) يكتا و يا اصطلاحا" atomic باشند . برای روشن شدن اين موضوع فرض كنيد دارای موجوديتی با نام "فاكتور فروش " باشيم . 

 
 

فاكتور فروش

شماره فاکتور(کليد اصلی)
تاريخ فاکتور
کد مشتری
نام مشتری
کالای 1
تعداد کالای 1
قيمت واحد کالای 1
.
.
.
کالای n
تعداد کالای n
قيمت واحد کالای n

با مشاهده موجوديت فوق متوجه اين موضوع خواهيم شد كه المان های كالا ، تعداد كالا و قيمت واحد كالا بيش از يك مرتبه در موجوديت وجود داشته و اصطلاحا" يك گروه تكرار را تشكيل می دهند . برای اجرای مدل فيزيكی اين موجوديت ناچار خواهيم بود در طراحی جدول آرايه ای به طول ثابت ( به عنوان نمونه با ده عضو ) تعريف و در آن به ترتيب كالای 1 تا 10 را تعريف نمائيم . 

مشکل : طراحی فوق ما را با دو مشکل عمده روبرو خواهد ساخت : اول اين كه  کارائی بانک اطلاعاتی پائين خواهد آمد (اگر در آينده تعداد کالاهای فاکتور فروش بيش از 10 کالا باشد ، آنگاه مجبور خواهيم بود طراحی جدول مربوطه و متعاقب آن نرم افزارهائی که از آن استفاده می كنند را تغيير دهيم ) و مشکل دوم اين كه  بسياري از فاکتورها لزوما" دارای 10 کالا نيستند و بنابراين محتوی بسياری از فيلدها در جدول فوق خالی (داراي ارزش Null) خواهد ماند و حجم زيادی از فضای ديسک هدر خواهد رفت .

راه حل : برای حل اين مشکل کافی است تمامی گروه های تکرار و يا آرايه ها را از موجوديت خارج کرده و به موجوديت ديگری منتقل نمائيم . در چنين مواردی ، كليد اصلی موجوديت اول را به عنوان بخشی از كليد اصلی موجوديت جديد قرار داده و با تلفيق يكی ديگر از آيتم های اطلاعاتی موجوديت جديد كه تضمين كننده يكتا بودن ركوردهای آن موجوديت ( جدول ) است ، كليد اصلی موجوديت ايجاد می گردد . بدين ترتيب ، يك ارتباط بين موجوديت پدر و فرزند بر اساس كليد اصلی موجوديت پدر برقرار خواهد شد .
مجددا" به موجوديت "فاكتور فروش " مثال قبل پس از تبديل به فرم اول نرمال توجه نمائيد : 

 
 

رديف های فاكتور فروش

 



ارتباط بين موجوديت پدر و فرزند بر اساس كليد اصلی موجوديت پدر
(فاكتور فروش)

فاكتور فروش

شماره فاکتور(قسمت اول کليد اصلی)
کالا (قسمت دوم کليد اصلی)
تعداد
قيمت واحد
 

 

شماره فاکتور(کليد اصلی)
تاريخ فاکتور
کد مشتری
نام مشتری

به طور خلاصه می توان گفت كه هدف از فرم اول نرم سازی حذف گروه های تكرار و آرايه ها از موجوديت يا جدول است . فرآيند فوق ، می بايست بر روی تمامی موجوديت های بانك اطلاعاتی اعمال گردد تا بتوان گفت بانك اطلاعاتی نرمال شده در فرم اول است . 

فرم دوم نرمال 2NF
موجوديتی در فرم دوم نرمال است که اولا" در فرم اول نرمال باشد و ثانيا" تمامی آيتم های (Attribute) غير کليدی آن وابستگی تابعی به تمام کليد اصلی‌ موجوديت داشته باشند نه به بخشی از آن .همانگونه كه از تعريف فوق استنباط می گردد ، فرم دوم نرمال سازی در خصوص موجوديت هائی بررسی و اعمال می شود كه دارای كليد اصلی مركب هستند ( بيش از يك جزء ) . بنابراين در مثال فوق موجوديت "فاكتور فروش " به خودی خود در فرم دوم نرمال است ولی موجوديت "رديف های فاكتور فروش " كه دارای كليد اصلی مركب است ، نياز به بررسی دارد .

مشکل : در صورتی كه موجوديت در فرم دوم نرمال نباشد ، آنگاه با تغيير اطلاعات قسمت های غيروابسته به تمام كليد ، اين تغييرات در يك ركورد اعمال می شود ولی تاثيری بر روی ساير ركوردها و يا جداول نخواهد داشت . در مثال فوق با تغيير محتوی قيمت واحد در موجوديت "فاكتور فروش " ، قيمت واحد كالا در يك فاكتور فروش اصلاح می گردد اما در ساير فاكتورها اعمال نخواهد شد .

راه حل : برای حل اين مشکل کافی است موجوديت جديدی ايجاد نمائيم و کليد اصلی آن را برابر با آن بخش از کليد اصلی موجوديت مورد بررسی که دارای المان های وابسته به آن است قرار دهيم ، سپس تمام المان های اطلاعاتی وابسته تابعی به اين کليد را از موجوديت مورد بررسی خارج کرده و به موجوديت جديد منتقل نمائيم . در اين حالت بين موجوديت جديد ايجاد شده و موجوديت نرمال شده ، بر اساس کليد اصلی موجوديت جديد ايجاد شده يک ارتباط پدر فرزندی تعريف خواهد شد . دقت کنيد که بر عکس نرمال سازی فرم اول ، در اين جا موجوديت موردبررسی فرزند بوده و موجوديت جديد پدر خواهد بود .
 به مثال فوق برمی گرديم و فرم دوم نرمال سازی را بر روي آن اعمال می نمائيم . موجوديت "فاکتور فروش" دارای کليد مرکب نيست پس در فرم دوم نرمال بوده و نياز به بررسی ندارد ، اما موجوديت "رديف های فاکتور فروش"  نياز به بررسی دارد . در اين موجوديت آيتم اطلاعاتی "قيمت واحد" وابستگی تابعي به آيتم کالا دارد که بخشی از کليد است نه کل کليد ، پس لازم است تا اين موجوديت را تبديل به فرم دوم نرمال نمائيم . بدين منظور  موجوديتی به نام "کالا" ايجاد کرده ، کليد اصلی آن را برابر کالا قرار داده و آيتم قيمت واحد را از موجوديت رديف های فاکتور فروش خارج نموده و به اين موجوديت منتقل می نمائيم. مثال فوق پس از تبديل به فرم دوم نرمال به شکل ذيل خواهد بود :

 
 

رديف های فاكتور فروش

 



ارتباط بين موجوديت پدر و فرزند بر اساس كليد اصلی موجوديت پدر (فاكتور فروش)

فاكتور فروش

شماره فاکتور(قسمت اول کليد اصلی)
کالا (قسمت دوم کليد اصلی)
تعداد
 

 

شماره فاکتور(کليد اصلی)
تاريخ فاکتور
کد مشتری
نام مشتری

 

ارتباط بين موجوديت پدر و فرزند بر اساس كليد اصلی موجوديت پدر (كالا)

 

كالا

کالا (کليد اصلی)
قيمت واحد

فرم سوم نرمال 3NF
موجوديت و  يا جدولی در فرم سوم نرمال است که اولا" در فرم دوم نرمال بوده و ثانيا" تمام آيتم های غير کليد آن وابستگی تابعی به کليد اصلی داشته باشند ، نه به يک آيتم غير کليد .

مشکل : در صورتی كه موجوديتی در فرم سوم نرمال نباشد ، آنگاه با تغيير آيتم يا آيتم های اطلاعاتی غير وابسته به کليد اصلی در يک رکورد، تغييرات در ساير رکوردها اعمال نخواهد شد و دچار دوگانگی اطلاعات خواهيم شد (مثلا" يک مشتري با دو نام متفاوت) .

راه حل : کافی است آيتم های غير کليدی به هم وابسته را به موجوديت جديدی منتقل  و کليد اصلی موجوديت جديد را تعيين نمائيم ، آنگاه کليد اصلی موجوديت جديد را در موجوديت نرمال شده به عنوان يک کليد خارجی (Foreign Key) در نظر گرفت . در موجوديت "فاکتور فروش"  مثال فوق آيتم نام مشتری وابستگی تابعی به آيتم کد مشتری دارد که خود يک آيتم غير کليد است بنابر اين بايد نرمال سازی فرم سوم در خصوص آن اعمال شود . شکل ذيل نحوه انجام اين كار را نشان می دهد :

 
 

رديف های فاكتور فروش

 



ارتباط بين موجوديت پدر و فرزند بر اساس كليد اصلی موجوديت پدر (فاكتور فروش)

فاكتور فروش

شماره فاکتور(قسمت اول کليد اصلی)
کالا (قسمت دوم کليد اصلی)
تعداد
 

 

شماره فاکتور(کليد اصلی)
تاريخ فاکتور
کد مشتری (کليد خارجی)

ارتباط بين موجوديت پدر و فرزند بر اساس كليد اصلی موجوديت پدر (كالا)

ارتباط بين موجوديت پدر
 ( مشتری ) و فرزند بر اساس كليد خارجی 

 

كالا

مشتری

کالا (کليد اصلی)
قيمت واحد

کدمشتري (کليد اصلی)
نام مشتری

فرم بويس کد نرمال BCNF
فرم بويس کد دارای مفهوم جامع تری نسبت به فرم دوم و سوم نرمال است . در فرم دوم و سوم نرمال بحث بر سر وابستگی تابعی آيتم های غير کليدی به کليد اصلی است . اما در فرم بويس کد ، موجوديتی در فرم بويس کد نرمال است که اولا" در فرم اول نرمال بوده و ثانيا" تمام المان های غير کليدی آن کاملا" وابسته تابعی به يک کليد باشند و نه چيز ديگر . نکته حائز اهميت در اين فرم اين است که بحث بر سر وابستگي تابعی با يک کليد است نه فقط کليد اصلی. مفهوم فوق در خصوص موجوديت هائی که دارای چندين کليد هستند (Alternate Key) مطرح می شود . 

فرم چهارم نرمال 4NF
اين فرم در خصوص موجوديت هائی است که ارتباط بين المان های آن يک ارتباط چند ارزشه و يا چند به چند باشد . به عنوان مثال ، موجوديت کلاس درس می تواند شامل چندين دانش آموز و چندين معلم باشد. در چنين مواردی ارتباط بين معلم و دانش آموز يک ارتباط چند به چند می باشد . در اين حالت با ايجاد يك موجوديت رابط  مابين موجوديت های مذكور، مشکل ارتباط چند به چند حل خواهد شد (بسياری از سيستم های مديريت بانک های  رابطه ای نظير MSSQL از رابطه چند به چند پشتيبانی نمی نمايند ، يعنی نمی توان بين دو جدول يک رابطه چند به چند ايجاد نمود). معمولا" تمام المان های موجوديت رابط ايجاد شده بخشی از كليد اصلی است .

خلاصه
نرمال سازی فرم های ديگری نيز دارد که به دليل نادر بودن و خاص بودن آنها در اين مقاله به آنها اشاره نشده است . آنچه در خصوص نرمال سازی  عموميت دارد تا فرم سوم آن است ، يعنی در هنگام طراحی بانک های اطلاعاتی حتما" می بايست فرآيند نرمال سازی تا فرم سوم را انجام داد .
فرآيند نرمال سازی يک فرآيند تکراری (Recursive) است يعنی پس از هر مرحله نرمال سازی که منجر به ايجاد موجوديت های جديد می گردد ، فرآيند را بايد از ابتدا تا انتها بر روی موجوديت های تازه ايجاد شده نيز اجرا نمود.






+ نوشته شده در  ساعت   توسط فرهاد شرف پور  | 

هوش مصنوعی (artificial intelligence) را باید عرصهٔ پهناور تلاقی و ملاقات بسیاری از دانشها، علوم، و فنون قدیم و جدید دانست. ریشه‌ها و ایده‌های اصلی آن را باید در فلسفه، زبان‌شناسی، ریاضیات، روان‌شناسی، نورولوژی، و فیزیولوژی نشان گرفت و شاخه‌ها، فروع، و کاربردهای گونه‌گونه و فراوان آن را در علوم رایانه، علوم مهندسی، علوم زیست‌شناسی و پزشکی، علوم ارتباطات و زمینه‌های بسیار دیگر.

هدف هوش مصنوعی بطور کلی ساخت ماشینی است که بتواند «فکر» کند. اما برای دسته بندی و تعریف ماشینهای متفکر، می‌بایست به تعریف «هوش» پرداخت. همچنین به تعاریفی برای «آگاهی» و «درک» نیز نیازمندیم و در نهایت به معیاری برای سنجش هوش یک ماشین نیازمندیم.

با وجودی که برآورده سازی نیازهای صنایع نظامی، مهم‌ترین عامل توسعه و رشد هوش مصنوعی بوده‌است، هم اکنون از فراورده‌های این شاخه از علوم در صنایع پزشکی، رباتیک، پیش بینی وضع هوا، نقشه‌برداری و شناسایی عوارض، تشخیص صدا، تشخیص گفتار و دست خط و بازی‌ها و نرم افزارهای رایانه‌ای استفاده می‌شود مباحث هوش مصنوعی پیش از بوجود آمدن علوم الکترونیک، توسط فلاسفه و ریاضی دانانی نظیر بول (Boole) که اقدام به ارائه قوانین و نظریه‌هایی در باب منطق نمودند، مطرح شده بود. در سال ۱۹۴۳، با اختراع رایانه‌های الکترونیکی، هوش مصنوعی، دانشمندان را به چالشی بزرگ فراخواند. بنظر می‌رسید، فناوری در نهایت قادر به شبیه سازی رفتارهای هوشمندانه خواهد بود.

 با وجود مخالفت گروهی از متفکرین با هوش مصنوعی که با دیده تردید به کارآمدی آن می‌نگریستند تنها پس از چهار دهه، شاهد تولد ماشینهای شطرنج باز و دیگر سامانه‌های هوشمند در صنایع گوناگون هستیم.

نام هوش مصنوعی در سال ۱۹۶۵ میلادی به عنوان یک دانش جدید ابداع گردید. البته فعالیت درزمینه این علم از سال ۱۹۶۰ میلادی شروع شده بود.

بیشتر کارهای پژوهشی اولیه در هوش مصنوعی بر روی انجام ماشینی بازی‌ها و نیز اثبات قضیه‌های ریاضی با کمک رایانه‌ها بود. در آغاز چنین به نظر می‌آمد که رایانه‌ها قادر خواهند بود چنین اموری را تنها با بهره گرفتن از تعداد بسیار زیادی کشف و جستجو برای مسیرهای حل مسئله و سپس انتخاب بهترین آن‌ها به انجام رسانند.

 هنوز تعریف دقیقی که مورد قبول همهٔ دانشمندان این علم باشد برای هوش مصنوعی ارائه نشده‌است، و این امر، به هیچ وجه مایهٔ تعجّب نیست. چرا که مقولهٔ مادر و اساسی‌تر از آن، یعنی خود هوش هم هنوز بطور همه‌جانبه وفراگیر تن به تعریف نداده‌است. در واقع، می‌توان نسل‌هایی از دانشمندان را سراغ گرفت که تمام دوران زندگی خود را صرف مطالعه و تلاش در راه یافتن جوابی به این سؤال عمده نموده‌اند که: هوش چیست؟ اما اکثر تعریف‌هایی که در این زمینه ارایه شده‌اند بر پایه یکی از ۴ باور زیر قرار می‌گیرند:

 سیستم‌هایی که به طور منطقی فکر می‌کنند

 سیستم‌هایی که به طور منطقی عمل می‌کنند

سیستم‌هایی که مانند انسان فکر می‌کنند

سیستم‌هایی که مانند انسان عمل می‌کنند

 شاید بتوان هوش مصنوعی را این گونه توصیف کرد:«هوش مصنوعی عبارت است از مطالعه این که چگونه کامپیوترها را می‌توان وادار به کارهایی کرد که در حال حاضر انسان‌ها آنها رابهتر انجام می‌دهند».

فلسفۀ هوش مصنوعی

 بطور کلی ماهیت وجودی هوش به مفهوم جمع آوری اطلاعات, استقرا و تحلیل تجربیات به منظور رسیدن به دانش و یا ارایه تصمیم میباشد . در واقع هوش به مفهوم به کارگیری تجربه به منظور حل مسایل دریافت شده تلقي ميشود. هوش مصنویی علم و مهندسی ایجاد ماشینهایی با هوش با به کارگیری از كامپیوتر و الگوگيری از درک هوش انسانی و نهايتا دستیابی به مکانیزم هوش مصنوعی در سطح هوش انسانی ميباشد.

در مقایسه هوش مصنوعی با هوش انسانی می توان گفت که انسان قادر به مشاهده و تجزیه و تحلیل مسايل در جهت قضاوت و اخذ تصمیم میباشد در حالی که هوش مصنوعی مبتنی بر قوانین و رویه هايی از قبل تعبیه شده بر روی کامپیوتر میباشد. در نتيجه علی رغم وجود کامپیوترهای بسیار کارا و قوی در عصر حاضر ما هنوز قادر به پیاده کردن هوشي نزدیک به هوش انسان در ایجاد هوشهای مصنوعی نبوده ایم.

 بطور كلّی، هوش مصنوعی را می توان از زوایای متفاوتی مورد بررسی و مطالعه قرار داد. مابین هوش مصنوعی به عنوان یک هدف، هوش مصنوعی به عنوان یک رشته تحصیلی دانشگاهی، و یا هوش مصنوعی به عنوان مجموعۀ فنون و راه کارهایی که توسط مراکز علمی مختلف و صنایع گوناگون تنظیم و توسعه یافته است باید تفاوت قائل بود.

مدیریت پیچیدگی

ایجاد و ابداع فنون و تکنیک‌های لازم برای مدیریّت پیچیدگی را باید به عنوان هستۀ بنیادین تلاش‌های علمی و پژوهشی گذشته، حال، و آینده، در تمامی زمینه‌های علوم رایانه، و به ویژه، در هوش مصنوعی معرّفی کرد. شیوه‌ها و تکنیک‌های هوش مصنوعی، در واقع، برای حلّ آن دسته از مسائل به وجود آمده است که به طور سهل و آسان توسط برنامه‌نویسی تابعی (Functional programming)، یا شیوه‌های ریاضی قابل حلّ نبوده‌اند.

 در بسیاری از موارد، با پوشانیدن و پنهان ساختن جزئیّات فاقد اهمّیّت است که بر پیچیدگی فائق می‌آییم، و می‌توانیم بر روی بخش‌هایی از مسئله متمرکز شویم که مهم‌تر است. تلاش اصلی، در واقع، ایجاد و دستیابی به لایه‌ها و ترازهای بالاتر و بالاتر تجرید را نشانه می‌رود، تا آنجا که، سر‌انجام برنامه‌های کامپوتری درست در همان سطحی کار خواهند کرد که خود انسان‌ها به کار مشغولند.

 به یاری پژوهش‌های گسترده دانشمندان علوم مرتبط، هوش مصنوعی از آغاز پیدایش تاکنون راه بسیاری پیموده‌است. در این راستا، تحقیقاتی که بر روی توانایی آموختن زبانها انجام گرفت و همچنین درک عمیق از احساسات، دانشمندان را در پیشبرد این علم، یاری کرده‌است. یکی از اهداف متخصصین، تولید ماشینهایی است که دارای احساسات بوده و دست کم نسبت به وجود خود و احساسات خود آگاه باشند. این ماشین باید توانایی تعمیم تجربیات قدیمی خود در شرایط مشابه جدید را داشته و به این ترتیب اقدام به گسترش دامنه دانش و تجربیاتش کند.

برای نمونه به رباتی هوشمند بیاندیشید که بتواند اعضای بدن خود را به حرکت درآورد، او نسبت به این حرکت خود آگاه بوده و با سعی و خطا، دامنه حرکت خود را گسترش می‌دهد، و با هر حرکت موفقیت آمیز یا اشتباه، دامنه تجربیات خود را وسعت بخشیده و سر انجام راه رفته و یا حتی می‌دود و یا به روشی برای جابجا شدن، دست می‌یابد، که سازندگانش، برای او، متصور نبوده‌اند.

هر چند مثال ما در تولید ماشینهای هوشمند، کمی آرمانی است، ولی به هیچ عنوان دور از دسترس نیست. دانشمندان، عموماً برای تولید چنین ماشینهایی، از تنها مدلی که در طبیعت وجود دارد، یعنی توانایی یادگیری در موجودات زنده بخصوص انسان، بهره می‌برند.

آنها بدنبال ساخت ماشینی مقلد هستند، که بتواند با شبیه‌سازی رفتارهای میلیونها یاخته مغز انسان، همچون یک موجود متفکر به اندیشیدن بپردازد.

هوش مصنوعی که همواره هدف نهایی دانش رایانه بوده‌است، اکنون در خدمت توسعه علوم رایانه نیز است. زبانهای برنامه نویسی پیشرفته، که توسعه ابزارهای هوشمند را ممکن می‌سازند، پایگاههای داده‌ای پیشرفته، موتورهای جستجو، و بسیاری نرم‌افزارها و ماشینها از نتایج پژوهش‌های هوش مصنوعی بهره می‌برند.

 سیستمی که عاقلانه فکر کند. سامانه‌ای عاقل است که بتواند کارها را درست انجام دهد. در تولید این سیستم‌ها نحوه اندیشیدن انسان مد نظر نیست. این سیستم‌ها متکی به قوانین و منطقی هستند که پایه تفکر آنها را تشکیل داده و آنها را قادر به استنتاج و تصمیم گیری می‌نماید. آنها با وجودی که مانند انسان نمی‌اندیشند، تصمیماتی عاقلانه گرفته و اشتباه نمی‌کنند. این ماشینها لزوما درکی از احساسات ندارند. هم اکنون از این سیستم‌ها در تولید عامل‌ها در نرم افزارهای رایانه‌ای، بهره گیری می‌شود. عامل تنها مشاهده کرده و سپس عمل می‌کند.

سیستم‌های خبره

 سیستم‌های خبره زمینه‌ای پرکاربرد در هوش مصنوعی و مهندسی دانش ا‌ست که با توجّه به نیاز روز افزون جوامع بر اتخاذ راه ‌حل‌ها و تصمیمات سریع در مواردی که دانش‌های پیچیده و چندگانهٔ انسانی مورد نیاز است، بر اهمیت نقش آنها افزوده هم می‌شود. سیستم‌های خبره به حل مسائلی می‌پردازند که به طور معمول نیازمند تخصّص‌های کاردانان و متخصّصان انسانی‌ست. به منظور توانایی بر حل مسائل در چنین سطحی (ترازی)، دسترسی هرچه بیشتر اینگونه سامانه‌ها به دانش موجود در آن زمینه خاص ضروری می‌گردد.

عامل‌های هوشمند

 عامل‌ها (Agents) قادر به شناسایی الگوها، و تصمیم گیری بر اساس قوانین فکر کردن خود می باشند. قوانین و چگونگی فکر کردن هر عامل در راستای دستیابی به هدفش، تعریف می‌شود. این سیستم‌ها بر اساس قوانین خاص خود فکر کرده و کار خودرا به درستی انجام می‌دهند. پس عاقلانه رفتار می‌کنند، هر چند الزاما مانند انسان فکر نمی‌کنند.

ایلین ریچ، هوش مصنوعی(وتکنیک‌ها)، ترجمه آزاد از دکتر مهرداد فهیمی، نشر جلوه، ۱۳۷۵، وب‌گاه سیمرغ هوش مصنوعی: به شیوه‌ای مدرن هوش مصنوعی: راهنمائی برای سامانه‌های هوشمند این کتاب به صورتی ساده و روان نوشته شده‌است. Nisenfeld, A. E., Artificial Intelligence Handbook: Principles, Instrument Society of America, ۱۹۸۹. ISBN: ۱ - ۵۵۶۱۷


 

+ نوشته شده در  ساعت   توسط فرهاد شرف پور  |