حامی فایل

مرجع دانلود فایل ,تحقیق , پروژه , پایان نامه , فایل فلش گوشی

حامی فایل

مرجع دانلود فایل ,تحقیق , پروژه , پایان نامه , فایل فلش گوشی

دانلود مقاله طراحی و پیاده سازی نرم افزار شبیه ساز عملکرد تراکتور با ویژوال بیسیک

اختصاصی از حامی فایل دانلود مقاله طراحی و پیاده سازی نرم افزار شبیه ساز عملکرد تراکتور با ویژوال بیسیک دانلود با لینک مستقیم و پر سرعت .

 

 

خلاصه :
این تز یک قسمت از پروژه HSV در مرکز استرالیایی برای زمینه رباتیک در دانشگاه سیدنی است . هدف توسعه Package ارتباطی بی سیم برای ارتباط بین کامپیوتر آن بورد ute و کامپیوتر اپراتور است . اول از همه حسگرها و محرک ها مطالعه و بحث شدند و همه داده های مهم که اپراتور ممکن است به آن علاقه داشته باشد تحلیل و معین شده اند . سیستم ارتباطی بی سیم سپس انتخاب و گسترش یافت . بانداستفاده شده 2.4 GHz بود و سیستم IEEE802.llb بوسیله ارتباط پیک توپیک کامپیوترها استفاده می شود . Package سخت افزاری بی سیم به دفت انتخاب شده مانند : آنتن ute ، آنتن اپراتور کارت اینترنتی ارتباطی بی سیم و مبدل اینترنتی . کتابخانه ارتباطی استفاده شده کتابخانه msg-Bus بود . جایی که ارتباط به آسانی فعال می شود تا پیام‌ها در یک زمان فرستاده شوند .دو نرم افزار اصلی توسعه یافت . اولین نرم افزار توسعه یافته برای ute تمام دیتای حسگرها را ز حافظه تقسیم شده هسته اصلی می خواند و آن را به کامپیوتر اپراتوری می فرستد . نرم افزار دوم ، نرم افزار اپراتور با ute ارتباط می یابد و دیتای مخصوصی رامی خواهد و آن را در فایلهای متنی ذخیره می کند . سرانجام ، روالهای مطمئن برای هر کس طرح ریزی شده که ute برای مردم توسعه یافته استفاده کند و هر بخش از آزمایش انجام شده در هر زمان را دنبال کند .
فهرست مطالب

 

 

 


فصل اول
مقدمه

Chapter 4 :
4.1 Background : (پیش زمینه)
massage-Bus رابط برنامه نویسی کاربردی msg-Bus یک کتابخانه برای پشتیبانی پردازش داخلی و ارتباط سیستم داخلی است که واسط سوکت را استفاده می کند . کتابخانه پروتکل پیام دیاگرام را استفاده می کند (UDP) که بوسیله IP فراهم می شود. این انتخاب که نسبت به استفاده TCP برتری دارد ساخته شده است . برای اجرای دلایل و بدلیل اینکه واسط اساسی (اترنت سریع کلیدداری در صفحه بندی hupspoke) خودش به تنهایی مجزا است : ارتباط دو طرفه نقطه به نقطه پس گره ها و تصادم یابی با دوباره ارسال کردن بسته ها گم شده . کتابخانه برای کد کردن ساختار دستوری C++ است .
توابع گذرگاه پیام : 4.2
یک سیستم توزیعی شامل تعدادی از سیستم هاست (که گره ها نامیده می شوند) جایی که روی هر نود یک شماره از فرایندها (که وظایف خوانده می شوند) می توانند اجرا شوند . هدف از یک message Bus یک گذرگاه پیام فعال سازی این وظایف است برای انتقال دادن اطلاعات تبادلی و همزمان سازی اهداف دلیل استفاده از message Bus برای این تبادلات اجتناب از ارتباطات نقطه به نقطه یک شبکه وسیع و بدست آوردن معماری سیستم پیمانه ای است . هدف توانایی ارتباط (گذراندن پیام) پس وظیفه ها در نودهای مختلف پاپس وئظایفی در نود مشابه بدون ایجاد هیچ تغییر برای وظایف دیگر در سیستم می باشد . کتابخانه msg-bus شامل تعدادی از توابع است که بوسیله سرویس گیرنده ، سرور و برنامه های نظیر به نظیر فراخوانی می شووند . بوسیله استفاده از این فراخوانی ها یک سیستم تمام توزیع شده عبور دهنده پیام می‌تواند در هر سیستم عامل پشتیبانی شده فهمیده شود . چهار تابع اصلی شامل :
msg - attach message Bus نصب ارتباط
msg - detach message Bus آزادسازی ارتباط با
msg - send فرستادن یک پیغام به برنامه یا نود دیگر
msg - receive انتظار رسیدن یک پیغام و خواندن آن
4.2.1 : ضمیمه یا پیوست
تابع کتابخانه ای msg-bus یعنی msg-attach اولین تابعی است که بوسیله هر فرایندی که بخواهد msg-Bus را استفاده کند فراخوانی می شود . آن نود و برنامه را برای ایجاد سوکت و تنظیم یک ساختار عمومی با دیتای معمولی استفاده می کند . تابع مقدار Msg-ok(0) را هنگامی که الحاق موفقیت آمیز است یا یکی از کدهای خطا در جایی که سوکت باز است ، بسته است یا خطاها قرار داده شده اند برمی گرداند .
Long msg - attach (char*node,char*task)
(گره) : nede
نود نامی از خود سیستم است (در واقع آدرس IP) که بوسیله یک رشته درفرمت
"XXX.XXX.XXX.XXX" معرفی می شود . (برای مثال "155.69.31.90" ) .
(وظیفه) : task
task(وظیفه) اسمی از خود سیستم است :‌این باید یک رشته باشد که یک عدد صحیح است . ( در واقع یک شماره درگاه) در رنج 65535+1024 را معرفی می کند . (برای مثال "5016" )
(انفعال ) Detach 4.2.2
تابع کتابخانه msg-bus یعنی msg-attach باید قبل از خارج شدن برنامه کاربردی فراخوانی شود که msg-bus استفاده شود . آن نزدیک socket خواهد بود . هیچ پارامتری هم نیاز نیست .
Long msg-detach( );
4.2.3
msg-send از تابع کتابخانه ای msg-bus برای فرستادن پیغام به برنامه (وظیفه) دیگر بکار می رود . تابع یک بسته با اطلاعات فرستنده و گیرنده اضافه خواهد کرد . برای توانایی فرستادن ، سوکت بایداول بوسیله msg-attach ( ) اضافه شود . ID پیغام و طول (اگر لازم باشد) به دستور بایتی شبکه تبدیل خواهند شد. برای محتویات میدان داده ای ، آن مسئولیت برنامه کاربردی است که این را انجام دهد . برای اطمینان از اینکه آن دریافت شده باشد ، پارامتر قبلی باید به شکل صحیح تنظیم شود . سپس msg - send ( 0 قبل از اینکه برگردد منتظر یک تعویق (البته استفاده از یک timeout) می ماند . تابع هنگامی که فرستادن موفقیت آمیز باشد msg-ok(0) را بر می گرداند یا هنگامی که فرستادن خطا داشته باشد یکی از کدهای خطا را بر می گرداند . timeout یا تصدیق .
Long msg - send (char*nede , char * tssk , Long id , Long len , char * data , boolck);
Node
نود یا گره نام سیستم است (آدرس IP) جایی که برنامه قرار می گیرد . نام نود در رشته ای در فرمت "XXX.XXX.XXX.XXX" معرفی می شود (برای مثال "155.69.31.90"
task
وظیفه یا برنامه نام فرایند مقصد است : این باید یگ رشته بارها که یک عدد صحیح (در واقع یک شماره گذرگاهی) در رنج 1024 به 65535 را معرفی کند (برای مثال "5016")
id
شناسه ای از پیام برای فرستادن است . (ID ساختار پیام ، احتیاج به دریافت وظیفه برای جذب داده دارد)
Len
طول ، در مقیاس بایت : دنباله بلاک داده است .
data
بلاک دیتا ، یک رشته است .
ack
اگر فرستنده بخواهد برای تصدیق دریافت منتظر بماند بولین True را set می کند .
: دریافت 4.25
msg-receive تابع کتابخانه ای msg-bus یک پیام را از یک سوکت دریافت می کند و با ID پیام و دیتا جواب می دهد . مقدار time out می تواند برای ثانیه های زیاد انتظار کشیدن داده شود . زمانی که یک time out اتفاق بیافتد ، تابع بوسیله کد خطای Msg-ERR-timeout(-30) برگردانده می شود .
اگر timeout به 1- تنظیم شود تابع برای همیشه برای یک پیام ورودی منتظر خواهد ماند .
(این در یک setup استفاده خواهد شد جایی که برنامه دریافتی به یک event ورودی لینک شده است برای اینکه تابع بازخورد فراهم شود) . تابع هنگامیکه پیام دریافتی موفقیت آمیز باشد msg-ok(0) را بر می گرداند یا یکی از کدهای خطا را هنگامی که خطا دریافت می شود . time out یا تصدیق . زمانی که یک ساختمان داده دریافت می‌شود ، این ساختار فقط بعد از اینکه ID پیغام شناخته شده یکی می شود .
ما یک اشاره گر برای یک ساختار درست فرمت شده ایجاد خواهیم کرد و آن را به یک میدان داده ای ساختار نیافته برای دستیابی به داده نسبت می دهیم .
Long msg - receive(char*nede,char*task,Long* id , Long* len , char* data , Long timeout) ;
Node
نود نام سیستم است (آدرس IP) جایی که فرایند فرستاده شده ناشی می شود . اسم نود بوسیله یک رشته در فرمت "XXX.XXX.XXX.XXX" معرفی می شود . (برای مثال "135.69.31.90" )
task
برنامه (وظیفه) نام فرایند فرستاده شده است . این شاید یک رشته باشد که یک عدد صحیح (در واقع یک شماره گذرگاه) در رنج 1024 تا 65535 را معرفی کند (برای مثال "5016")
id
شناسه ای از پیام دریافتی است . ID بوسیله برنامه فرستاده شده با موافقت با وظیفه دریافتی استفاده می شود تا ساختار پیام تعریف شود . برنامه دریافتی برای جذب داده مورد نیاز است .
Len
طول ، در مقیاس بایت : دنباله بلاک داده است .
data
بلاک دیتا ، یک رشته است .
timeout :
انتظار کشیدن به مدت چند میلی ثانیه برای یک پیام ورودی . هنگامی که timeout صفر است تابع فقط با دیتایی که در صف موجود است بر می گردد . وقتی مثبت است، این تابع بلوکه می شود و تا وقتی که پیام برسد منتظر می ماند .
پیغامهای فوری 4.3
کتابخانه می تواند بین پیامهای معمولی و پیامهای فوری فرق قائل شود . برای هر برنامه ای که کانال ارتباطی استفاده می کند همچنین یک کانال فوری می تواند باز شود. اگر کانال ارتباطی معمولی بسته باشد کانال اضطراری می تواند استفاده شود . تابع msg-attach-urgent از کتابخانه msg-bus خیلی به msg-attach شبیه است . هر چند سوکت های مختلف برای تهیه کانال جدا برای پیام های اضطراری باز است . این کانال اضطراری مورد نیاز است زیرا برای پیام های اضطراری به صف شدن و گم شدن غیرقابل قبول است زیرا بافر سرریز می کند . تابع می تواند بوسیله هر فرایندی که می خواهد تسهیلات کانال اضطراری از msg-bus را استفاده کند فراخوانی شود . آن می تواند با msg-attach( ) در زمان نصب فراخوانی شود . تابع هنگامی که الحاق موفقیت آمیز باشد msg-ok(0) را بر می گرداند یا یکی از کدهای خطا را هنگامیکه سوکت باز باشد یا بسته یا خطاها set شوند نشان می دهد .
Long msg - attach - urgent(Char*nede,char*task) ;
چیز مشابهی که به فرستادن پیغام ها ، دریافت پیغامها و جدا کردن پارامترها جواب می‌دهد مانند زیر است:
Long msg - send - urgent(char*node,char*task , Long id, Long len , char* data , bool ack) ;
Long msg - receive - urgent (char*node , char * task , Long * id , Long * len , char * data , Long timeout) ;
Msg-detach 0 urgent ( ) ;
در پروژه ها پیامهای فوری استفاده نمی شود زیرا اساساً پیامهای ارتباطی کاملاً ساده و به موقع هستند . هچ کدام از آنها اضطراری نیستند .

 

chapter 5
5-توسعه نرم افزار
.5.1 در این مرحله از پایان نامه راه اندازی سخت افزار قطعیت داده شد و کتابخانه ارتباطی شبکه فهمیده شد . بنابراین مرحله بعد توسعه نرم افزار خواهد بود . توسعه نرم افزار یک معمای عمومی دارد که به پنج مرحله اصلی تقسیم می شود : احتیاجات ،
طراحی ، کد کردن ، آزمایش و تعمیر و نگهداری .
گراف زیر روالی را که در توسعه نرم افزار بکار می رود نشان می دهد . بعد از شکل دادن بعضی قسمتهای مخصوص ، هر چند گاهی اوقات احتیاج دوباره به توجه کردن به آن دارد زیرا معماری سیستم با قسمتهای انفرادی پیوند قوی دارد .
شکل .5.1 مراحل توسعه نرم افزار

 

 

 

 

 


.5.2 احتیاجات
هدف پایان نامه طراحی و ساخت یک بسته ارتباطی بی سیم است که برای شبکه بندی کامپیوتر آنبورد ute با کامپیوتر بی سیم اپراتور ، جایی که دستورات، پیغامها و دیتای حسگر می تواند از یک کامپیوتر به دیگری انتقال یابد می باشد . تشخیص نهایی این است که نرم افزارباید یک ارتباط شبکه ای بین دو کامپیوتر برقرار کند . جایی که اپراتور بعضی دستورات را به کامپیوتر ute می فرستد تا بخواهد بعضی از دیتای حسگرها یا همه دیتای حسگر را به او بفرستد و ثوابت کنترلی را برای مدلهایی مانند نقاط شروع و و .. داده باید روی کامپیوتر اپراتور ، هر حسگر یا هر تقسیم در فایل txt خودش ذخیره شود .
هر فایل باید با عضی خصوصیات درباره آنچه دیتاست ، داده و زمان برای مجموعه داده شروع می شود و با داده و زمان پایان مجموعه داده تمام می شود . هر حسگر زمان خودش را برای تخصیص دارد ، همه آن بستگی به زمانی که هر حسگر به‌روز‌رسانی می شود دارد . جدول زیر زمان بروز رسانی دیتای هر حسگر را نشان می‌دهد .
جدول5.1 : زمان بندی حسگرها
Timing Sensor
200 ms GPS1
200 ms GPS2
200 ms Laser 1
200 ms Laser 2
100 ms Compass
25 ms Uteactuators
25 ms Generalute
10 ms INS

 

همچنین مجموعه ای از ترکیب 2 ، 3 یا بیشتر حسگر پیشنهاد می شود . زیرا گاهی اوقات ما فقط احتیاج به ترکیب 2 یا 3 تا حسگر برای جستجو یا کنترل داریم . بقیه برای ما بی استفاده است که چرا ممکن است حسگرهای خاصی ضبط شود که فقط از بعضی واسطه های Dos استفاده می کند .

 

.5.3 طراحی
همانطور که قبلاً بحث شد ما مجبوریم دو نرم افزار انفرادی طراحی کنیم : یکی برای ute و دیگری برای اپراتور . برنامه ute کاملاً ساده و درست برای اشاره کردن است در صورتیکه برنامه اپراتور کمی بیشتر پیچیده باشد . معماری نرم افزار اصلی بوسیله گراف زیر خلاصه شده است .اولین چیزی که انجام می شود بوجود آوردن ارتباط بین دو کامپیوتر بوسیله الحاق آدرسهای IP به یکدیگر است . پس اپراتور یک پیغام به ute می فرستدجایی که آن برای بعضی دیتاهای خاص (معمولاً دیتای حسگرها) درخواست می کند . نرم افزار ute داده را از حافظه اشتراکی می خواند (حافظه اشتراکی فوق هسته ای ) و آن را به کامپیوتر اپراتور می فرستد . سرانجام نرم افزار اپراتور دیتا را در فایل متنی می نویسد . نرم افزار زمانی که اپراتور آن را می خواهد پایان می یابد و پس در برنامه ارتباط بین آنها را می شکند . در قسمت بعدی ، طراحی
برای هر نرم افزار انفرادی در جزئیات کامل بحث می شود .
شکل 5-2 : معماری نرم افزار اصلی
-5.3.1 نرم افزار ute
نرم افزار ute خیلی ساده(درست) است . هدف گرفتن پیام جستجو برای داده و فرستادن آن برای گرفتن پل جدید است . این روال دوباره و دوباره تکرار می شود .
اگر یک پیغام دریافت نکند برای همیشه منتظر می ماند . اولین چیز اتصال به حافظه اشتراکی فوق هسته ای است جایی که آن به همه حسگرها دسترسی دارد . آن تمام ساختار حسگرها را در زمان واقعی می خواند . بنابراین ، همه داده های حسگرها هر دفعه بروزرسانی می شوند و هسته حسگرها را بروز رسانی می کند . همه ساختار حسگرها درخواست نمی شوند هر چند تمام ساختارها فرستاده خواهد شد و آنچه نیاز باشد ذخیره خواهد شد . قدم بعدی شناسایی آدرس IP است سپس به نرم افزار دیگر الحاق می شود . یک ارتباط شبکه ای به وجود خواهد آمد . پس آن تا زمانی که پیام دریافت کند همیشه منتظر می ماند . هر پیام دریافتی اساساً هیچ داده ای در آن نخواهد داشت (هر چند ما می توانیم هر داده یا ساختاری را که می خو.اهیم بفرستیم) آن فقط یک message ID خواهد داشت . هر شماره Message ID یک درخواست برای بعضی داده های خاص است . در این مرحله ما یک تابع انتخابی خواهیم داشت که شامل نه حالت مختلف است . اولین حالت فقط یک سیگنال ضربان قلب است . به عبارت دیگر فقط یک چکاپ است اگر ارتباط زنده باشد . 8 حالت دیگر برای هشت مجموعه مختلف از ساختار حسگرهاست . هر کدام برای حسگرهای انفرادی مانند GPS ، لیزر ، INS و قطب نما می باشد . هر چند encoder و مقادیر کنترلی محرک فقط در دو ساختار مختلف فرستاده می شوند : یکی شامل تمام موقعیت محرک های encoder چرخه ای و دیگری شامل تمام تنظیمات کنترل گرمایی می باشد .هر معماری حسگر یکبار به خودش فرستاده می شود . سرعت فرستادن داده خیلی سریع و کوچکتر از زمانی است که هر حسگر بروزرسانی می شود . بنابراین ، نرم افزار می‌تواند تمام مقادیر حسگرها را قبل از اینکه بوسیله هر کدام از آنها به تاخیر بیافتد بفرستد . بعد از فرستادن تمام داده های لازم ، آن جدا می شود هر زمان که نرم افزار بوسیله دریافت message ID صفر برای اتصال پایان یابد . شکل زیر معماری را قدم
به قدم برای نرم افزار ute در تمام جزئیات نشان می دهد .
شکل .5-3معماری نرم افزار ute

-5.3.2 نرم افزار اپراتور
برنامه اپراتور جایی است که تصمیمی باید بوسیله اپراتور گفته شود برای اینکه چه نوع داده خواسته شده در این قسمت اپراتور کنترل کامل روی اعمال ارتباطی شبکه دارد . اولین قسمت الحاق به کامپیوتر ute است که در طرف دیگر باید اجرا شود و برای اتصال منتظر می ماند .برای الحاق ، نرم افزار آدرس IP کامپیوتر را جستجو می‌کند و پس با استفاده از تابع msg-attach اتصال برقرار می کند . قسمت بعد دیتا را شناسایی می کند و زمانی که ارتباطات ساخته شدند . سپس آن 8 فایل متنی مختلف ایجاد خواهد کرد یکی برای هر حسگر بعد از ایجاد فایلها آن نوع دیتای ذخیره شدند در فایل را با داده و زمان در خط اول می نویسد . خط بعد تعریف هر ستون از داده می باشد . همه آنها با timestamp شروع می شود و سپس دیتای حسگر مانند ارتفاع ، طول ، حالت ، ماهواره و غیره .
(که برخی از مقادیر GPS بود) قسمت بعد یک بخش درون حلقه است که تا وقتی اپراتور بخواهد از برنامه خارج شود همیشه true می ماند . در هنگام شروع اپراتور انتخاب خواهدکرد که آنها چه نوع داده ای را می خواهند از ute تقاضا کنند . آنجا چهار دلیل اصلی وجود دارد :
1-چک کردن اینکه آیا ارتباط زنده است .
2-خروج از برنامه و جدا شدن از شبکه
3-دریافت تمام داده های حسگر و ذخیره آنها در فایل متنی
4-انتخاب فقط حسگرهای مخصوص - یکی ، دوتا یا بیشتر . در این مرحله ، اپراتور باید حسگرها را یکی یکی تخصیص دهد .
اگر انتخاب نادرست باشد ،اپراتور می تواند هر چیزی را در حال اجرا است متوقف کند و به انتخاب برگردد . بعد از اجرای یک آزمایش و ذخیره بعضی داده ها در همان زمان انتخاب دیگری از حسگرها می تواند ایجاد شود و داده جدید ذخیره خواهد شد. او می تواند در فرایند بوسیله انتخاب خروج وقفه ایجاد کند و نرم افزار از شبکه جدا خواهد شد .
چارت زیر معماری نرم افزار از نرم افزار اپراتور را در تمام جزئیات عملکرد نشان خواهد داد . هر قسمت ممکن است قسمت های کوچک دیگری که ممکن است در آن شامل باشد بسازد .

شکل .5-4 معماری نرم افزار اپراتور

 

-5.4 کدنویسی :
کد نویسی و اشکال گیری در واسط Win32,Dos در visual C++ انجام شده است . دو کد اصلی نوشته شده است . یک کد برای ute وکد دیگر برای اپراتور نوشته شده است . هر کدام از آنها در بخش بعد بحث خواهد شد .

 

-5.4.1 کد ute
قسمت اول اتصال یا الحاق به فایلهای سربرنامه بود . لیست زیر بعضی از فایلهای سربرنامه غیرمعمولی اصلی را نشان خواهد داد :
• #include" msg-bus.h" برای در برگرفتن کتابخانه ارتباطی بی سیم
• #include"Hypshare.h" برای فوق هسته
• #include "hk common.h" برای فوق هسته
• #include "shared Mem Protocol" برای حافظه اشتراکی جایی که حسگرها و داده های محرک ها خوانده می شود .
پس تعیین ساختارهای حافظه اشتراکی حسگرها:
Static void*hksur=NULL;
Static struct aietc_packet*pEtc;
Static struct sic_packet *pll.*pl2;
Static struct pos_packet *pGPSI , *pGPS2;
Static struct ins_packet*plns;
Static struct general UTE Info *pGui;
Static unsigned long Last CmpTime = 1L;
Static struct Compass *pCmp=NULL;
پس تمام ساختارهای حسگرها از حافظه اشتراکی فوق هسته از کامپیوتر ute خوانده می شود .
Hksur=hkusersharedRam(&SZsm);
If (hksur!=Null)
خواندن ساختار برای اولین حسگر لیزری از حافظه اشتراکی :
Pl1=(struct
Sic_packet*)(((char*)hksur)+Laser -offset-in-usershared memory);
خواندن ساختار برای دومین حسگر لیزری ازحافظه اشتراکی :
Pl2=Pl1+1;
خواندن ساختار برای اولین حسگر GPS از حافظه اشتراکی :
PGPS1=(struct
Pos_packet*)(((char*hksur)+GPS1-offset-in-usershared memory);
خواندن ساختار برای دومین حسگر GPS از حافظه اشتراکی :
PGPS2=PGPS1+1
خواندن ساختار برای حسگر عمومی ute مثل encoder از حافظه اشتراکی :
Petc=(struct
Aietc-packet*)(((char*)hksur)+ETC1-offset-in-usershared memory);

 

خواندن ساختار برای حسگر INS ازحافظه اشتراکی :
PLns=(struct ins-packet*)
(((char*)hksur)+INS-offset-in-usershared memory);

 

خواندن ساختار برای حسگر قطب نما از حافظه اشتراکی :
Pcmp=(Stuct Compass*)
(((char*)hksur+compass-offset-in-usershared memory);
خواندن ساختار برای ute info عمومی مانند نقاط تنظیمی برای کنترل گرها از حافظه اشتراکی :
Pgui=(struct general ute info*)((char*)hksur
+Etc2-offset-inusershared memory );
قسمت بعدی شناسایی آدرس IP از کامپیوتر ute برای ارتباط آینده باشبکه می باشد :
//cheking the Ip Addresses
Word wversion Requested ;
WSADATA wsa Data ;
Char name [255]

 

PHOSTENT hodtinfo ;
WVersionRequested=MAKEWORD(2.0);
If(WSAStartup(wVersionRequested , & wsaData )==0)
{
if(gethostname(name , size of (name ))==0)
{
if((hostinfo=gethosbyname(name))!=NULL)
{
own_nade=inet_ntoa(*(struct in_addr*)*hostinfoo->h_addr_list);
Printf ("\n the IP is %s \n \n ".own_node);
}
}
WSACleanup( ) ;
}
بعد از شناسایی آدرس IP ، ارتباط شبکه ای بی سیم ساخته خواهد شد و تابع
msg-attach از کتابخانه "msg-bus" استفاده می شود . "own-node" آدرس IP است و "5220" شماره پورت انتخابی تصادفی است .
/*connect to the message bus*/
if ((rc=msg-attach(own-node,"5220"))!=MSG-ok
msg-error(rc);
مرحله بعد تا وقتی حلقه همیشه درست می باشد است . بعد از اینکه برنامه تابع
msg-receive را استقاده خواهد کرد ، جایی که آن برای پیاماز کامپیوتر اپراتور و خواندن msg-id منتظر است و پس تصمیم می گیرد کدام مرحله تابع انتخابی را استفاده کند .
Whicle (1) {
Rc = msg_receive (snd_node , snd_task , & msg_id & msg_len , msg_data-1);
If (rc!=MSG_OK)
Msg_error(rc);
Print f("id is %d\n" . msg_id);
Switch(msg_id)
Case one زمانی است که اپراتور چک می کند آیا ارتباط eth برقرار است . بنابراین پیام دریافتی شامل هیچ چیز به جز 1 به عنوان ID نیست . case دوباره یک پیغام خالی با ID مساوی 1 بر می گرداند .
Case 1 ;
{
if((rc=msg_send("snd-node" , "5110" , 1 , 0 , Null , false))! =(MSG_ok)
msg_error(rc);
break ;
}
باقیمانده case ها داده حسگرها را هر وقت آنها درخواست شوند می فرستد . فقط اولین GPS طرح و توضیح داده شده است .ID برای GPS ، 2 است . وظیفه اصلی برای این مورد فرستادن ساختار داده GPS2 است .
Case2 ://send GPS1
{
rc=msg-send(own-node, "5110" , msg-id , size of (struct pos - packet) , (char*) PGPS1 , -1
if (rc!=MSG_ok)
msg-error (rc);
break;
Case zero جایی است که کاربر برای پایان دادن برنامه و شکستن ارتباط شبکه بی‌سیم سوال می کند .

 

Case 0;
{
if((rc=msg-detach( ))!=MSF-ok)
msg-error(rc);

 

-5.4.2 نرم افزار اپراتور
اولین قسمت الحاق فایلهای سربرنامه بود . لیست زیر بعضی از فایلهای سربرنامه نامعمول اصلی را نشان میدهد .
#include<time-h>0 برای شناسایی داده و زمان
#include "msg-bus.h" که کتابخانه ارتباطی بی سیم را در بر می گیرد .
#include "shared mem protocol .h" برای حافظه اشتراکی جایی که حسگرها و داده های محرک خوانده می شوند :
قسمت بعد شناسایی آدرس IP ازکامپیوتر اپراتور برای ارتباط آینده به شبکه است .
Checking the IP Addresses
WORD wVersionRequested;
WSADATA wsa Data ;
Char name [255];
PHOSTENT hostinfo ;
WVersionRequested=MAKEWORD(2.0);
If(WSAStartup (wVersion Requested . &wsaData)= = 0)
{
if(gethostname(name , size of(name)) = = 0)
{
if((hostinfo=gethostbyname(name))!=NULL)
{
ip=inet_ntoa(*(struct in_addr*)*hostinfo->h_addr_list);
printf("\n the IP is %s \n \n",ip);
}
}
WSACleanup( ) ;
}
بعد از شناسایی آدرس IP ، ارتباط شبکه ای بی سیم که تابع msg-attach از کتابخانه "msg-bus" را استفاده می کند ، ساخته خواهد شد ، "own-node" آدرس IP است و "5110" شماره پورت انتخابی تصادفی است .
/* Connect to the message bus*/
if((rc=msg-attach (ip,"5110")) ! =MSG-ok)
ms_error(rc) ;
قدم بعد خواندن داده و eth time از کامپیوتر است . داده و زمان از سیستم عملکرد windows خوانده می شود .
//time
time(&bintime);
curtime=Localtime(&bintime);
قدم بعد باز کردن 8 فایل مختلف است که هر یک برای یک حسگر مخصوص است . فایلها در فرمت ASCII هستند . خط اول تعیین اینکه فایل شامل چه چیزی است می‌باشد و پس اینکه چه داده و زمانی ایجاد می شوند . بعد از آن ، مقدار هر ستون تعیین خواهد شد . آن باستون مرتب نمی شود اما برای تعریف داده به اندازه کافی واضح است . مثال زیرفقط برای داده GPS1 است . باقیمانده فایلهای حسگرهای eth ایجاد شده ، روالهای مشابهی را استفاده می کنند .
//Oppening GPSI
if(FGPSI = fopen("FGPSI.txt","W"))= = NULL)
printf("The file was not opened\n");
fprintf(FGPSI) "The File Contains the First GPS Data in:%s" ,
ctime(&bintime));
fprintf(FGPSI,"timestamo , latitude , longitude, altude , altitude , ttcorse , speedog ,
vspeed , sigmaLati , sigmaLongi , sigmaAlti , mode , satellites");
در این مرحله ،‌اپراتور می تواند روی یکی از چهار option اصلی تصمیم بگیرد :
1-حرف "e" برای خروج
2-حرف "a" برای همه حسگرهایی که دریافت و ذخیره شده اند .
3-حرف "p" برای چک کردن اینکه آیا ارتباط برقرار است .
4-حرف "s" برای انتخاب بعضی حسگرهای خاص و / یا داده های محرک
While(msg_id!=0)
{
if(id_imput!="0"|id_imput)="1"|id_imput!="2"|id_imput!=3)
{
printf("\n Please choose one of the following options ; \n");
printf"\n->the letter "0" to exit ........n");
printf("\n->the letter "2" for all the sensors to be retrieved and saved........n");
printf("\n->the letter "1" to check if the connection is alive........n");
printf("\n->the letter "3" to select some specific sensors and / or actuators data\n");
gets(id)input);
}
اگر عدد "0" انتخاب شود ، اپراتور می خواهد خارج شود بنابراین پیام به ute که ID صفر را برای درخواست قطع ارتباط شبکه خواهد داشت فرستاده می شود . پس دو کامپیوتر از شبکه جدا خواهد شدو پیوند ارتباطی خواهد شکست .
IF(id_imput= = 0)
{
msg_id=0 ;
if((rc=msg_send(ip,"5220" , msg_id, 0 , NULL, FALSE))! = MSG_OK)
printf("NO CONNECTION %d" , rc);
if((rc=msg_detach())!=MSG_OK)
msg_error(rc);
}
اگر عدد "1" انتخاب شود‌، اپراتور چک می کند آیا ارتباط برقرار است . بنابراین یک پیام با ID مساوی یک فرستاده می شود و یک پیغام با اپراتور که هر یک ثانیه می‌گوید من موجودم چاپ می شود . اپراتور می تواند این فرایند را با فشار دادن هر کلید قطع کند .

 

If(id_imput= = "1")
{
while(!_kbhit())
{
msg_id=1;
if((rc=msg_send(ip,"5220" , msg_id, 0 , NULL , FALSE))! = MSG_OK)
printf("NO CONNECTION%d",rc);
msg_receive(snd)nodel , snd_task1,&msg)id,&msg_len,msg_data,-1);
sleep(1000);
printf("i"am alive\n");
}
id_input=1;}
اگر عدد "2" انتخاب شود یعنی اپراتور بعد از همه دیتاهای حسگرها ذخیره می شود . کد ریز نشان خواهد داد که چگونه هر قسمت یک حسگر را فراخوانی می کند و بعد از دریافت داده برای حسگر بعدی فراخوانی می کند . زمان برای بروزرسانی هر حسگر متفاوت است زیرا گاهی اوقات یک حسگر راقبل از اینکه بقیه را فراخوانی کنم بیشتر از یک بار فراخوانی می کنیم . ساختار فراخوانی و زمان بندی ، استفاده برای حساب کردن هر عبارت را کنترل می کند و تابع steep برای زمان بندی .

 

If((id)imput = = 2)
{msg_id=2;
if((rc=msg_send(ip,"5220" , msg_id , 0 , NULL , False))! = MSG_OK)
printf("NO CONNECTION?d" , rc) ;
while (!_kbhit())
{for)int d=0 ; d<1 ; d++)
{
//GPS1
msg_receive (snd_node1,snd_task1, &msg_id , msg_len,msg_data,-1);
GPS1=*pos_packet*)msg_data;
fprintf(FGPS1,"%d %d %d %d %d %d %d %d %d %d %d \n" , GPS1 , timestamp , GPSI . latitude , GPSI . longitude , GPSI . altitude , GPSI . ttcourse , GPSI . speedog , GPSI , vspeed , GPSI . sigm aLati , GPSI . sigmaLogi , GPSI . sigmaAlti, GPSI . mode , GPSI . satellites) ;
msg_send(ip, "5220" , 3 , 0 , NULL , FALSE) ;

 

//GPS 2
msg_receive (snd_node1 , snd_task1 , &msg_id , & msg_len , msg_data , -1);
GPS2 = *(pos_packet *)msg_data ;
Fprintf(FGPS2 . "%d %d %d %d %d %d %d %d %d %d %d \n" , GPS2 , latitude , GPS2 , longitude , GPS2 , altitude , GPS2 , ttcourse , GPS2 , speedog , GPS2 . vspeed , GPS2 , sigm aLati , GPS2 . sigmaLongi , GPS2 . sigmaAlti ,GPS2 , mode , GPS2 . satellites , GPS2 . timestamp);
Msg_send(ip,"5220" , 4 , 0 , NULL , FALSE) ;

 

//Laser1
msg_receive (snd_node1 , snd_task , &msg_id & msg_len , data , -1);
l1=*(stc_packet *)msg_data;
for(j=0;j<361;j++)
{l1 . range [j];
fprintf(Flaser1,"%d" , l1.range [1]);}
fprintf(Flaser1,"\n" );
msg_send(ip,"5220" , 5 , 0 , NULL , FALSE);

 

//Laser 2
msg_receive(snd_node1, snd_task1 , &msg_id , &msg_len , msg_data, 1);
l2=*(sic_packet*)msg_data;
for (j=0 ; j<361 ; j++)
{l2 . range [j] ;
fprintf(Flaser2 , "%d" , l2 , range[j];}
fprintf(Flaser2 , "\n" );
msg_send (ip, "5220" , 6 , 0 , NULL , FALSE);
for(intc=0 ; c<2 ; c++)
{
// Compass
msg_receive (snd_node1 , snd_task1 , &msg)id , &msg_len , msg)data , -1);
Cmp = *(Compass*)msg_data;
Fprintf(Fcompass , "%d %d %d\n" , Cmp . Heading , Cmp.Pitch , Cmp . Roll);
Msg_send (ip, "5220" , 8 , 0 , NULL , FALSE) ;
For(int b=0 ; b<5 ; b++)
{
//Actuators
msg_receive (snd_node1, snd_task1 , &msg_id , &msg_len , msg_data , -1);
lns=*(ins_packet*)msg_data;
fprintf(Factuators , "%d %d %d %d %d\n" , Etc.Counts , Etc . Accelerator , Etc.Streering , Etc . Brake , Etc.timestamp);
msg_send (ip , "5220" , 9 , 0 , NULL , FALSE);

 

//send Ute Info
msg_receive (snd_nodel , snd_task1 , &msg_id &msg_len , msg_data , -1);
Gui=*(general UTE Info*)msg_data ;
Fprintf(Factuators , "%d %d %d %d %d %d %d %d %d %d\n" Gui.PID_A.Kp, Gui.PID_Aki,Gui.PID_A.Kd , Gui , PID_A.SeMax , Gui.PID_A.yMin , Gui.PID_A.y.Max, Gui.PID_A.spoint , Gui . Steering Control Mode , Gui , manual_steering);
Msg_send (ip , "5220" , 7 , 0 , NULL , FALSE) ;
For(int a=0 ; a<2 ; a++)
{
//INSmsg_receive(snd_nodel , snd_task1 , &msg_id , &msg_len , msg_data, -1);
Ins = *(ins_packet*)msg_data;
Fprintf(FINS,"%d %d %d %d %d %d %d %d\n" , Ins.bank,Ins.elev , Ins.ax , Ins.ay , Ins.az . Ins.gx , Ins.gy , Ins.gz);
Msg_send (ip , "5220" , 2 , 0 , NULL , FALSE );
Printf("Count%d\n",a);
Sleep(10) ;
} } } } }
printf("\n Please Enter the ID Number \n" );
gets(id_input);,}
اگر اپراتور عدد "3" را انتخاب کند او مجبور است یک سری از انتخابها را طی کند . برنامه از او هر مجموعه ساده از داده های حسگر را می خواهد اگر احتیاج به خواندن و ذخیره شدن باشد . پس هر وقت حسگر انتخاب نشد ذخیره آن در txt ممنوع می‌شود . ساختار آن قسمت دقیقاً شبیه قسمت قبل است . اگر عبارت برای انتخاب باشد .

 

-5.5 آزمایش و تعمیر و نگهداری
بعد از اشکال گیری کدها و رهایی از خطاهای اشکال گیری اصلی و اخطارها ، بعضی کدهای ضعیف کشف می شود . من در تعمیر بعضی از آنها موفق بودم اما بقیه مشکل بودند و احتیاج به مقدار زیادی زمان داشتند . قسمت بعد درباره بعضی از ضعف های کدها بحث خواهد کرد : بدلیل اینکه نرم افزارها در زمان واقعی اجرا می شوند وبرنامه ute حافظه اشتراکی فوق هسته ای را استفاده می کند . ما مجبوریم نرم افزار فوق هسته را برای خواندن حسگرها در زمان واقعی اجرا کنیم و آنها را در حافظه اشتراکی ذخیره کنیم . بنابراین ، نرم افزار ute به دیتای تازه حسگر دستی خواهد داشت و آن را به اپراتور از طریق شبکه ارتباطی بی سیم خواهد فرستاد .
هر چند این ممکن است کوشش ناخواسته زیادی بخواهد . همانطور که قبلاً بحث شد، ما قادریم پس واژه های حسگر برای ذخیره در فایلهای متنی انتخاب کنیم . هر چند اگر ما اول GPS1 را برای ذخیره انتخاب کنیم ، بوسیله لیزر دنبال می شود و به دوباره به دادة GPS1 بر می گردد . هر وقت ذخیره کردن از قسمت قبل GPS1 با یک مجموعه جدید از time stamp ها تمام شد ادامه می یابد . هر چند اگر ما نرم افزار را خارج کنیم و آن را دوباره با انتخاب GPS1 اجرا کنیم ، آن در داده GPS1 موجود رونویسی خواهد شد . پیشنهاد می شود فایلها هر بار که آزمایش تمام می شود در دایرکتوری های مختلف ذخیره شود . یک راه حل این است که به برنامه اجازه دهیم هر بار که آن را اجرا کنیم یک دایرکتوری جدید ایجاد کند ، جایی که نامش به داده و زمان مرتبط باشد و دیتا را در آن ذخیره کند . ضعف دیگر که کشف شد این است که اگر ما باعث شویم که برنامه اپراتور داده مورد نیاز را روی صفحه چاپ کند آن پردازنده را کند خواهد کرد و خواندن پردازش داده را کندتر می کند که منجر به تاخیر ر بروزرسانی حسگر می شود . بنابراین چاپ داده روی صفحه بخاطر جلوگیری از هر تاخیری کنسل شد . همه داده ها فقط در فایلهای متنی ذخیره می شوند . خروجی داده متنی اول به عنوان فایلهای ASCII ایجاد شد . پیشنهاد شد فایل های داده ای بزرگتر را به عنوان دررویی ذخیره شود .
هر چند هنگام استفاده از کامپیوتر اپراتور فضا مساله مهمی نیست . داشتن یک هارددیسک حداقل 10 گیگابایتی برای یک ساعت آزمایش داده های حسگر کافی می‌باشد . هر چند اگر فایلهای نوعی دودویی احتیاج باشد آن برای پیاده سازی ذخیره آپشن یک آپشن ساده می باشد قبل از اینکه فایل ایجاد می شود . من ترجیح می دهم ASCII را استفاده کنم زیرا برای فهمیدن آسان تر است و برای استفاده برای نمودار کشیدن یا فیلتر کردن بدون احتیاج هر کد یا کتابخانه برای ترجمه آسان تر است . بات نرم افزار اپراتور ، کاربر یک انتخاب از مجموعه داده های مخصوص انتقال می دهد و در ابتدای برنامه ذخیره می کند . در این مرحله یک ورودی اشتباه منجربه پیاده سازی یک تصمیم اشتباه می شود . بنابراین ، یک روال کشف خطا برای جلوگیری از دستورات ورودی اشتباه طراحی شد که منجر به پردازش و پیاده سازی کد اشتباه می‌شود .

 

 

 

 

فرمت این مقاله به صورت Word و با قابلیت ویرایش میباشد

تعداد صفحات این مقاله  142  صفحه

پس از پرداخت ، میتوانید مقاله را به صورت انلاین دانلود کنید


دانلود با لینک مستقیم


دانلود مقاله طراحی و پیاده سازی نرم افزار شبیه ساز عملکرد تراکتور با ویژوال بیسیک

پاورپوینت طراحی و پیاده سازی زبانهای برنامه سازی

اختصاصی از حامی فایل پاورپوینت طراحی و پیاده سازی زبانهای برنامه سازی دانلود با لینک مستقیم و پر سرعت .

پاورپوینت طراحی و پیاده سازی زبانهای برنامه سازی


پاورپوینت طراحی و پیاده سازی زبانهای برنامه سازی

فرمت:پاورپوینت

فصل اول
اصول طراحی زبانها
 
چرا زبانهای برنامه سازی را مطالعه می کنیم؟
 
برای بهبود توانایی خود در توسعه الگوریتمهای کارآمد
 
استفاده بهینه از زبان برنامه نویسی موجود
 
می توانید با اصلاحات مفید ساختارهای برنامه نویسی آشنا شوید.
 
انتخاب بهترین زبان برنامه سازی
 
آموزش زبان جدید ساده می شود.
 
طراحی زبان جدید ساده می شود.
 
تاریخچه مختصری از زبانهای برنامه سازی
 
توسعه زبانهای اولیه
 
زبانهای مبتنی بر اعداد (اواخر دهه 1930 تا اوایل دهه 1940)
 
اهداف الگول عبارت بودند از:
 
نشانه های الگول باید به ریاضیات استاندارد نزدیک باشد.
 
الگول باید برای توصیف الگوریتمها مفید باشد.
 
برنامه ها در الگول باید به زبان ماشین ترجمه شوند.
 
الگول نباید به معماری یک ماشین مقید باشد.
 
توسعه زبانهای اولیه
 
زبانهای تجاری ( 1955)
 
زبان هوش مصنوعی (دهه 1950)
 
زبانهای سیستم
.
.
.
258 صفحه

دانلود با لینک مستقیم


پاورپوینت طراحی و پیاده سازی زبانهای برنامه سازی

دانلود مقاله بررسی امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت در صنایع خودروسازی

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

 

 

 

بررسی امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت در صنایع خودروسازی کشور
مورد مطالعه شرکت خودروسازی تبریز

 


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

 

 

 

 

 

 

 

1- مقدمه
در دنیای رقابتی امروز کسب اطلاعات درست و مناسب از درجه اهمیت بالایی برخوردار است و همواره این اطلاعات در تصمیم گیریهای مدیریت ، یکی از مهمترین و موثرترین فاکتورها به حساب می آید. لذا در زمینه مالی نیز اطلاعات می بایست صحیح و به موقع در اختیار مدیریت قرار بگیرد تا در موقع لزوم تصمیمات درستی اتخاذ شود. وظیفه تهیه این اطلاعات وپردازش آنهابه عهده سیستمهای اطلاعاتی حسابداری است .جهت تبدیل حسابداری به یک ابزاراطلاعاتی ،سیستمی مناسب بایدطراحی شودکه درآن عوامل وعناصرتهیه کننده وپردازشگراطلاعات درهمکاری وتعامل بایکدیگربتوانندازموادخام اطلاعاتی (وقایع مالی ) محصولی ارزشمند به نام اطلاعات مالی ،تهیه ودراختیارمدیریت وسایراستفاده کنندگان نشان دهند.
یکی از این سیستمها که مدیریت را در دستیابی به اطلاعات درست و منطقی یاری می کند ،سیستم حسابداری سنجش مسئولیت می باشد. حسابداری سنجش مسئولیت از سیستم های کنترلی مدیریت تلقی می شود زیرا برنامه ریزی اقتصادی و تصمیمات کنترلی موثر، نیازمند ارزیابی از چگونگی عملکرد (طبق مسئولیتهای محوله) واحدهاست. ارزیابی به موقع مسئولیتها و عملکرد واحدهای اقتصادی ، می تواند منجر به تخصیص بهینه منابع محدود شود. بنابراین ارزیابی مسئولیت و عملکرد ،فرآیندی است که از طریق آن مدیران در تمامی سطوح، اطلاعات را درباره عملکرد خود از داخل شرکت به دست می آورند وقضاوت می کنند. مهمترین عنصردریک سیستم موفق حسابداری مسئولیت ،پذیرش مسئولیتهای تعیین شده به صورت عادلانه توسط مدیران مرکزمسئولیت وتمایل آنان برای مسئول بودن است. ازآنجاکه مرحله اجرائی سنجش مسئولیت نشان دهنده هردو بعد نتایج اجرائی موفق وناموفق می باشد اطمینان راسخی بین افرادتحت کنترل ومافوقشان موجودمی باشد.سیستم حسابداری مسئولیت مطلوب ،بایدبرنظریه های رفتارانسانی مبتنی ودارای عوامل مهم کمی وکیفی باشد.
چنانچه هدف اصلی ازسیستم حسابداری مسئولیت ،اختصاص منابع مالی شرکت به طریق مطلوب وارائه اطلاعاتی درباره کارائی مدیران وافرادمسئول سازمان باشدبایدنقش نیروی انسانی به طورموثردرسیستم حسابداری مسئولیت بکارگرفته شود.
2- سیستم اطلاعاتی
یک سیستم اطلاعات ،که گاهی اوقات سیستم پردازش داده نامیده می شود یک سیستم مصنوعی است که متشکل از مجموعه کاملی از مولفه های دستی و رایانه ای می باشد که برای جمع آوری ،ذخیره و اداره داده ها و تهیه اطلاعات مورد نیاز کاربران تهیه شده است. [همت فر 1387]

 

3- سیستم اطلاعاتی مدیریت (MIS):
سیستم اطلاعاتی مدیریت نوعی سیستم مصنوعی است که شامل مجموعه ای از مولفه های رایانه ای و دستی می باشد که برای تسهیل عملیات یک شرکت و حمایت از فرایند تصمیم گیری از طریق تهیه اطلاعاتی که مدیران می توانند برای برنامه ریزی و نظارت بر فعالیت های شرکت استفاده نماید ،ایجاد شده است. [همت فر 1387]
نظام اطلاعاتی مدیریت به طورخلاصه مجموعه ای ازمنابع انسانی وسرمایه ای است که درهماهنگی با یکدیگر اطلاعات مورد نیاز مدیریت را درتمامی سطوح ازطریق فرآوری داده ها تامین می کند. درواقع کاراصلی این نظام اطلاعاتی نیزمثل سایرسیستمهای اطلاعاتی ،تبدیل داده ها به اطلاعات است.
4- سیستم اطلاعاتی حسابداری (AIS)
سیستم اطلاعاتی حسابداری عبارت است از مولفه و عنصری از سازمان که از طریق پردازش رویدادهای مالی ،اطلاعات هشدار دهنده مربوط به ثبت نتایج و اطلاعات مبنای تصمیم گیری را در اختیار استفاده کنندگان از اینگونه اطلاعات قرار می دهد. تعریف جامع تری که از سیستم اطلاعاتی حسابداری ارائه شده است چنین است: سیستم اطلاعاتی حسابداری عهده دار وظیفه تبدیل داده های اطلاعاتی به گزارشهای سودمند مالی و ارائه آنها به مدیریت درون سازمان و مراجه برون از سازمان جهت تصمیم گیری می باشد. [همت فر 1387]
به این ترتیب نظام اطلاعاتی حسابداری زیرمجموعه ای ازیک سیستم بزرگتر(سیستم اطلاعاتی مدیریت )محسوب می شود ،اما همان طورکه گفته شد مهمترین زیرمجموعه این نظام اطلاعاتی است. نمودار ذیل این رابطه را به شکل واضح تری نشان می دهد.
سیستم اطلاعاتی حسابداری
سیستم اطلاعاتی مدیریت

 

 

 

 

 

 

 

 

 

 

 

5- جایگاه سیستم های اطلاعاتی حسابداری در سازمانها:
همگام با پیشرفت دانش وتکنولوژی ،حسابداری نیز متحول گردیده و درحال حاضر از جمله ابزارهای مهم کنترل دربرنامه ریزی وتصمیم گیری محسوب می شود ،به همین لحاظ تغییرات عمده ای در نگرش به حسابداری ایجاد شده که از مهم ترین آنها دیدگاه حسابداری به عنوان سیستم اطلاعاتی است.
«حسابداری به عنوان مجموعه ای از اجزاء بهم پیوسته در داخل یک سازمان که فعالیت ها ورویدادهای مالی موسسه را به اطلاعات مالی تبدیل می کند ،تعریف شده است.»

 


فعالیتها ورویدادها اطلاعات مالی مانند گزارش مالی مانند خرید،فروش و...
همانگونه که در نمودار فوق مشاهده می ش شود وظیفه اصلی سیستم اطلاعاتی حسابداری فراهم نمودن اطلاعاتی است که استفاده کنندگان از آن در تصمیم گیری های خود استفاده می کنند.
6 - حسابداری سنجش مسئولیت
سیستم حسابداری براساس مسئولیت براین اصل تکیه داردکه هرشخص مسئول عملکردخود وزیردستانش می باشد. این مفهوم حسابداران رادرانجام وارائه گزارش نتایج عملیات ازنقطه نظرمسئولیت رهنمون می سازد. [میلجر 1986]
در این سیستم واحدهای سازمان به بخشهای کوچکتری تقسیم می‌شوند و به هر یک از بخشها مسئولیتهای خاصی واگذار می‌شود. هر یک از بخشها، متشکل از افرادی است که دربارة وظایف معین یا امور مدیریت مسئولیت دارند. مدیریت ارشد واحدهای سازمان باید از هم آهنگی اهداف مدیران این بخشها با هدفهای کلی واحد انتفاعی اطمینان حاصل کنند.
6-1- مفروضات حسابداری سنجش مسئولیت
برای پیاده سازی و اجرای سیستم سنجش مسئولیت فرضیات اساسی به شرح ذیل تعریف شده است.
الف) مدیران در قبال فعالیتهائی که در سازمان و در حیطه کنترل آنان واقع می‌شود جوابگویند .
ب) مدیران سعی کافی در جهت رسیدن به هدفهای شرکت و هدفهای سازمان تحت نظارت خود مبذول می‌دارند.
ج) مدیران در جهت تعیین روشهای اندازه گیری و ارزیابی فعالیتهایشان با یکدیگر همکاری می‌کنند.
چ) اهداف با انجام مؤثر فعالیتها ، قابل حصول هستند.
ح) گزارش مدیران به طور منظم و در زمانهای مشخص تهیه می‌شود.
خ) نقش حسابداری سنجش مسئولیت در مؤسسه به روشنی مشخص شده است.
در مؤسسات کوچک، نقش حسابداری سنجش مسئولیت کمتر مؤثر است، اما همگام با رشد این مؤسسات ، کنترل و ارزیابی فعالیتها مشکل‌تر شده و نیاز به استفاده از حسابداری سنجش مسئولیت اهمیت پیدا می‌کند.
6-2- تمرکز زدایی و حسابداری سنجش مسئولیت
تمرکز زدایی در مقابل تمرکز گرایی، در ادبیات مدیریت و سازمان معرفی شده است، تمرکز زدایی با افزایش اختیار و به تبع آن افزایش مسئولیت و در مقابل تمرکز گرایی با کاهش اختیار و به تبع آن کاهش مسئولیت همراه شده است. افزایش اختیار، لازمه اش، پاسخگویی بیشتر است. بنابراین ضرورت بهره گیری از روشها و نظامهای سنجش مسئولیت در نظام اداری غیرمتمرکز افزایش می یابد.
6-2-1-منافع تمرکز زدایی
الف) مؤسسات به واحدهای قابل کنترل کوچکتر تقسیم می‌شدند و مدیریت در بخش های سازمان تخصصی می شود (اعم از اطلاعات و مهارتها).
ب) تصمیمات در سطوحی گرفته می‌شود که در آن سطوح، مسئولان با مشکلات قسمت و اطلاعات مربوط به تصمیم گیری آشنائی نزدیک دارند.
ج) تصمیمات درمواقع مورد لزوم اتخاذ شده و زمان بندی صحیح تصمیم گیری‌ها رعایت می‌شود .
چ) به دلیل مشارکت در تصمیم گیری، روحیة کارکنان و میزان ارضای شغلی آنان بالا خواهد بود .
ح) مسئولان امکان خواهند داشت که از مهارتهای با ارزشی استفاده کنند و نتیجتاً سطح مهارت خود مدیریت مؤسسه افزایش خواهد یافت.
خ) مسئولان به انجام فعالیتهائی که برای مؤسسه فایده بیشتری دارد تشویق می‌شوند.
6-2-2-هزینه های تمرکز زدایی
الف ) مدیران این سازمانها، در پاره ای اوقات، بر عملکرد واحد خود، تنها متمرکز می شوند و از اهداف کلی سازمان غفلت می ورزند.
ب) تمرکز صرف و مجرد بر نتیجه واحد سازمانی، تمایل مدیران سازمان غیرمتمرکز، به ارتباط با واحدهای دیگر سازمان و خواسته ها و تمایلات آن کاهش می یابد.
پ) در سازمانهای غیرمتمرکز، بعضی از وظایف یا خدمات ممکن است موازی یا تکراری و غیر ضروری انجام شود. برای مثال، دو دپارتمان یک دانشگاه، هر یک نظام رایانه ای ارائه خدمات داشته باشند که هزینه ها را افزایش دهد که این امر ممکن است غیر ضرور باشد.
6-3-مراحل اجرای نظام حسابداری سنجش مسئولیت
1 - تعیین مراکز مسئولیت
2 - بودجه بندی و پیش بینی مخارج و درآمدهای مراکز مسئولیت تعریف شده
3 - تهیه نمودار سازمانی و تعیین اختیارات و قلمرو هر یک از مراکز مسئولیت
4 - مشخص کردن هزینه های قابل کنترل و غیرقابل کنترل
5 - تهیه گزارش عملکرد برای هر مرکز توسط مدیر مسئول آن
6-4-تاریخچه سیستم حسابداری سنجش مسئولیت
تاسالهای دهه 1950 میلادی سیستم حسابداری براساس مسئولیت موردتوجه قرارنگرفته بود.دراین زمان بودکه به تدریج سیستم حسابداری براساس مسئولیت وتاثیرآن بررفتارنیروی انسانی موردتوجه قرارگرفت وتحقیق درزمینه بررسی ارتباط بین علوم رفتاری وحسابداری مدیریت توسعه پیداکرد.بویژه پژوهشهای هافمند(1968)،هاپ وود(1972 )،واتلی (1987 )نشان دادکه کنترل بودجه ای ،فرآیندسازمانی پیچیده ای است که نیازمندتوجه کافی برارتباط نزدیک میان فرآیندهای کمی و واکنشهای انسانی است.درایران درزمینه حسابداری سنجش مسئولیت تحقیقاتی صورت گرفته است . یک موردتحقیق درمهرماه سال 1373 دردانشگاه علامه طباطبایی صورت پذیرفته که درآن محقق بامصاحبه با10 نفرازکارشناسان واساتید رشته حسابداری دردانشگاه ،به بررسی موانع ومشکلات اجرائی نمودن سیستم حسابداری سنجش مسئولیت درصنایع ایران پرداخته است. و در سال 1375 آقای پرویز بختیاری دانشجوی کارشناسی ارشد رشته مدیریت دانشگاه تهران در پایان نامه دوره کارشناسی ارشد خود به بررسی مشکلات استقرار سیستمهای مدیریتی در شرکتهای ایرانی پرداخته و یکی از دلایل عمده این مشکلات را بی اطلاعی مدیران از این گونه سیستمها ذکر کرده است. در سال 1380 آقای ابوالقاسم فخاریان در نشریه حسابدار شماره 146 ، در مقاله ای تحت عنوان سیستمهای کنترل و سنجش عملکرد به این موضوع پرداخته است که میتوان پرسنل شرکت را توسط مسئولیتهای تعریف شده ای که به آنها می سپاریم مورد کنترل قرار دهیم.
7- فرضیه های تحقیق
درانجام این پژوهش ،محقق یک فرضیه اصلی وچهار فرضیه فرعی به شرح زیر مورد بررسی قرار داده است.
فرضیه اصلی:
بین شرایط موجود در سازمان و امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت ، رابطه معنی داری وجود دارد.
فرضیه فرعی اول:
بین عدم تمرکز اختیارات مدیران و امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت ، رابطه معنی داری وجود دارد. (فرضیه عدم تمرکز)

 


فرضیه فرعی دوم:
بین صلاحیت و لیاقت مدیران و امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت ، رابطه معنی داری وجود دارد. (فرضیه صلاحیت و کفایت)
فرضیه فرعی سوم:
بین انعطاف پذیری سیستم حسابداری وامکان پیاده سازی و اجرای حسابداری سنجش مسئولیت، رابطه معنی داری وجود دارد. (فرضیه انعطاف پذیری)
فرضیه فرعی چهارم:
بین حجم فعالیتهای شرکت و امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت، رابطه معنی داری وجود دارد. (فرضیه حجم عملیات)
8 - جامعه و نمونه آماری
جامعه آماری این پژوهش شرکت خودرو سازی تبریز و شرکتهای تولید کننده قطعات مورد نیاز این شرکت می باشد ونمونه انتخاب شده پرسنل مالی شرکتهای فوق می باشد. در این تحقیق چون جامعه آماری حدوداً دارای 67 عضو می¬باشد ،باید بین 50تا100درصد جامعه آماری به عنوان نمونه انتخاب شود. به همین دلیل برای همه مدیران حسابداری و پرسنل مالی شرکت خودرو سازی تبریز ¬ پرسشنامه ارسال شد.
9 - روش و نوع تحقیق
در این پژوهش برای بررسی وضعیت موجود درشرکت جهت پیاده سازی و اجرای سیستم حسابداری سنجش مسئولیت از روش تحقیق «توصیفی»استفاده شده. برای این کار با استفاده از بررسی شرایط اجرای سیستم حسابداری سنجش مسئولیت سؤالاتی تهیه شد .این سؤالات به قسمتهای حسابداری شرکتها ارائه شد و با استفاده از پاسخ مدیران و پرسنل حسابداری شرکتها به سؤالات تهیه شده ،وضعیت امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت مورد بررسی قرارگرفت. تحقیق حاضر از نوع تحقیقات میدانی – کتابخانه ای است یعنی بخشی از اطلاعات وادبیات موضوعی با مراجعه به مقالات و کتب تخصصی و مراجعه به سایتهای اینترنتی مربوطه بدست آمده وبخش میدانی نیز مربوط به بررسی شرایط و عوامل موثر بر پیاده سازی و اجرای حسابداری سنجش مسئولیت در شرکت خودرو سازی تبریز به وسیله پخش پرسشنامه می باشد. .
12- نتایج آزمون فرضیه ها
- آزمون فرضیة فرعی اول
فرض صفر هنگامی رد میشود که مقدار آماره آزمون بیشتر از 64/1 باشد. (برای اطمینان 95 درصد).
مقدار آماره آزمون برابر با 2/53 است که در ناحیه رد فرض صفر قرار دارد پس میزان نسبت موافقین ( نسبت کسانی که به پرسش: هرچه حجم فعالیت و دادو ستد های شرکت بیشتر شود نیاز به سیستم حسابداری سنجش مسئولیت بیشتر احساس می شود ، پاسخ مثبت داده اند ) 70درصد بوده و به صورت معناداری بزرگتر از 50 درصد است. بنابراین بین حجم فعالیت شرکت و امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت رابطه معناداری وجود دارد.

 

فرضیات تعداد نسبت مقدار Z نتیجه
بلی خیر بلی خیر
فرضیه فرعی اول بین حجم فعالیت شرکت و امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت رابطه معناداری وجود دارد. 28 12 70% 30% 2.53 فرض صفر رد می‌شود
فرضیات فرعی تر هرچه سازمان بزرگتر باشد احتیاج به عدم تمرکز مسئولیت بیشتر احساس می شود. 31 9 77.5% 22.5% 3.42 فرض صفر رد می‌شود
هرچه پرسنل یک سازمان بیشتر باشد احتیاج به عدم تمرکز مسئولیت بیشتر احساس می شود. 26 14 65% 35% 1.90 فرض صفر رد می‌شود
هرچه تعداد شعبه های یک سازمان بیشتر باشد احتیاج به عدم تمرکز مسئولیت بیشتر احساس می شود. 33 7 82.5% 17.5% 4.05 فرض صفر رد می‌شود
هرچه ساعات کارکرد شرکت بیشتر باشد احتیاج به عدم تمرکز مسئولیت بیشتر احساس می شود.. 13 27 32.5% 67.5% 2.28- فرض صفر رد نمی‌شود

 

نتایج آزمون برای فرضیات فرعی اول همانند آزمون نسبت برای فرضیه اول انجام گرفته. همانگونه که توضیح داده شد فرض صفر فقط در فرضیه فرعی چهارم رد نشده است یعنی اینکه بین ساعات کارکرد شرکت و تمرکز مسئولیت در مدیران رابطه ای وجود ندارد ولی در سه فرضیه فرعی دیگر یعنی بزرگی شرکت ، تعداد پرسنل شرکت و تعداد شعبات شرکت این ارتباط به اثبات رسیدکه این رابطه ها منطقی به نظر میرسند.از نتایج فرضیات فوق می توان نتیجه گرفت که بین حجم فعالیت شرکت و امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت رابطه معناداری وجود دارد.
بنابراین در سطح اطمینان 95% می توان گفت که بین حجم فعالیت شرکت و امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت رابطه معناداری وجود دارد.
- آزمون فرضیة فرعی دوم
از آنجاییکه مقدار آماره آزمون برابر با 73/5 است (73/5 > 64/1) ، پس در ناحیه رد فرض صفر قرار می گیرد و فرض صفر رد می‌شود. فرضیات فرعی از فرضیه اصلی دوم به روش مشابهی آزمون شده و نتایج آن در جدول مربوطه ارایه شده است، همانگونه که مشخص گردیده است فرض صفر در تمام موارد رد میگردد یعنی فرضیات فرعی در تمام موارد تایید میشود. مقادیر آماره آزمون در کمترین مقدار برابر با 22/2 و در بیشترین مقدار 98/10 بدست آمده که همگی در ناحیه رد فرض صفر قرار می گیرند.
بنابراین با 95% اطمینان می توان گفت که بین تمرکز اختیارات مدیران و امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت رابطه معناداری وجود دارد.

 

 

 

 

 

 

 

 

 

فرمت این مقاله به صورت Word و با قابلیت ویرایش میباشد

تعداد صفحات این مقاله  15  صفحه

پس از پرداخت ، میتوانید مقاله را به صورت انلاین دانلود کنید


دانلود با لینک مستقیم


دانلود مقاله بررسی امکان پیاده سازی و اجرای حسابداری سنجش مسئولیت در صنایع خودروسازی

دانلود پروژه کامپیوتر نرم افزار طراحی و پیاده سازی پایگاه داده های توزیع شده همگن

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

دانلود پروژه کامپیوتر نرم افزار طراحی و پیاده سازی پایگاه داده های توزیع شده همگن


دانلود پروژه کامپیوتر نرم افزار  طراحی و پیاده سازی پایگاه داده های توزیع شده همگن

پروژه کامپیوتر گرایش : نرم افزار – طراحی و پیاده سازی پایگاه داده های توزیع شده همگن

 

طراحی و پیاده سازی پایگاه داده های توزیع شده همگن

 

پروژه دوره کارشناسی

در رشته مهندسی کامپیوتر گرایش نرم افزار

 

 

 

دانشگاه شهید بهشتی

پیشگفتار

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

اینگونه از سیستم های پایگاهی در عین دارا بودن مزایایی همچون :

 

  • سازگاری و هماهنگی با ماهیت سازمان های نوین
  • کارایی بیشتر در پردازش داده ها به ویژه در پایگاه داده های بزرگ
  • دستیابی بهتر به داده ها
  • اشتراک داده ها
  • افزایش پردازش موازی
  • کاهش هزینه ارتباطات
  • تسهیل گسترش سیستم
  • استفاده از پایگاه داده های از قبل موجود.

 

دارای معایبی نیز می باشد. از جمله معایب آن می توان به موارد ذیل اشاره نمود :

 

  • پیچیدگی طراحی سیستم
  • پیچیدگی پیاده سازی
  • کاهش کارایی در برخی موارد
  • هزینه بیشتر
  • مصرف حافظه بیشتر

 

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

 

با تقدیر و سپاس

از زحمات

استاد عزیز

که در تمامی مراحل این پایان نامه مرا یاری نمودند .


 

و تقدیم به پدر و مادر عزیزم

که همواره سنگ صبورم بوده اند .

وتمام کسانی که از سرچشمه دانششان نوشیده ام .

 

 

مطالعات نظری.. 7

فصل اول. 8

  1. سیستم پایگاهی توزیع شده 9

تعاریف… 9

  1. مزایا و معایب سیستم پایگاهی توزیع شده 13

2.1.                  مزایا: 14

2.2.                  معایب: 14

  1. چند سیستم نمونه. 14
  2. یک اصل بنیادی.. 15
  3. دوازده قاعده فرعی.. 17

5.1.                  خود مختاری محلی.. 17

5.2.                  عدم وابستگی به یک مانه مرکزی.. 18

5.3.                  استمرار عملیات… 18

5.4.                  استقلال از مکان ذخیره سازی.. 19

5.5.                  استقلال از چگونگی پارسازی داده ها 19

5.6.                  استقلال ازچگونگی نسخه سازی داده ها 22

5.7.                  پردازش در خواست های توزیع شده 24

5.8.                  مدیریت تراکنش های توزیع شده 24

5.9.                  استقلال از سخت افزار. 25

5.10.                استقلال از سیستم عامل.. 25

5.11.                استقلال از شبکه. 25

5.12.                استقلال از DBMS. 26

  1. پایگاه داده های توزیع شده همگن و ناهمگن.. 26
  2. مشکلات سیستم های توزیع شده 26

7.1.                  پردازش در خواست… 27

7.2.                  مدیریت کاتالوگ… 30

7.3.                  انتشار بهنگام سازی.. 33

7.4.                  کنترل ترمیم. 34

7.5.                  کنترل همروندی.. 36

  1. گدار. 38
  2. مقایسه سیستم های مشتری/خدمتگزار با سیستم های توزیع شده 40
  3. خلاصه. 41
  4. نتیجه گیری.. 42

فصل دوم. 43

  1. سیستم های پایگاه داده های توزیع شده و موازی.. 44
  2. توازی بین درخواست ها 46
  3. نگاهی دقیقتر به تکنولوژی پایگاه داده های توزیع شده وموازی.. 51

3.1.                  سطح و نوع توزیع شدگی داده ها ومسئولیت ها در DDBMSهای مختلف…. 52

3.2.                  پردازش و بهینه سازی درخواست… 55

3.3.                  کنترل همروندی (Concurency control) 63

3.4.                  پروتکل های قابلیت اطمینان. 67

  1. خلاصه. 77
  2. نتیجه گیری.. 78

فصل سوم. 79

  1. تاریخچه. 80
  2. جنبه هایاوراکل برای سیستم های توزیع شده 82
  3. خطوط اتصال پایگاه داده ها 82

3.1.                  رده بندی database link بر اساس نحوه برقراری ارتباط.. 83

ضرورت استفاده از database link ها 83

3.2.                  بکارگیری اسامی سراسری پایگاه داده هادر database link ها 84

3.3.                  نامگذاری database link ها 85

3.4.                  گونه های مختلف database link. 85

3.5.                  مقایسه کاربران ِ گونه های مختلف database link ها 86

3.6.                  مثال هایی از تعریف database link در سیستم های توزیع شده پایگاه داده ها 87

  1. عملیات روی داده های ذخیره شده در پایگاه داده های توزیع شده اوراکل.. 88

فصل چهارم. 89

  1. توزیع داده ها 90

1.1.                  استراتژی های توزیع داده ها 90

1.2.                  تخصیص داده ها 91

1.3.                  طرح توزیع و تخصیص مناسب برای DDB خوابگاه دانشگاه شهید بهشتی.. 91

1.4.                  انتخاب طرح توزیع DDB خوابگاه دانشگاه شهید بهشتی.. 91

متن کامل را می توانید دانلود نمائید چون فقط تکه هایی از متن پایان نامه در این صفحه درج شده (به طور نمونه)

ولی در فایل دانلودی متن کامل پایان نامه

همراه با تمام ضمائم (پیوست ها) با فرمت ورد word که قابل ویرایش و کپی کردن می باشند

موجود است


دانلود با لینک مستقیم


دانلود پروژه کامپیوتر نرم افزار طراحی و پیاده سازی پایگاه داده های توزیع شده همگن