صفحه اصلی پیگیری سفارش درباره ما تماس با ما
جستجو
تحقیق و مقالات رایگان مشاهده دسته بندی ها
  2. کامپیوتر - IT
  3. دانلود مقاله معماری نرم افزار

دانلود مقاله معماری نرم افزار

Word 583 KB 7815 122
مشخص نشده مشخص نشده کامپیوتر - IT
قیمت قدیم:۲۵,۲۰۰ تومان
قیمت با تخفیف: ۱۹,۸۰۰ تومان
دانلود فایل
  • بخشی از محتوا
  • وضعیت فهرست و منابع

  • چکیده

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

     

    مقدمه

     

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

    معماری نرم افزارِ یک برنامه یا سیستم کامپیوتری، ساختار یا ساختارهایی از سیستم می باشد، که در برگیرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بین آنها باشد[Bass 03]  . معماری نرم‌افزار شامل اولین تصمیمات طراحی سیستم می‌باشد و این تصمیمات زیربنای فعالیت‌های طراحی، پیاده‌سازی، استقرار و نگهداری سیستم می‌باشد. همچنین معماری نرم‌افزار، اولین عنصر قابل ارزیابی در فرایند توسعه نرم‌افزار می‌باشد[Bass 03]  . بنابراین برای طراحی سیستمی که نیاز‌های کیفی مورد نظر را برآورده سازد، تولید معماری نرم‌افزار اولین گام در دستیابی به کیفیت در نرم‌افزار و همچنین ارزیابی ویژگی‌های کیفی است.  

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

    در این گزارش، هدف بررسی روش­های موجود در طراحی معماری نرم­ افزار بر اساس ویژگی­های کیفی مورد نظر مشتریان و بررسی نحوه خودکار سازی فرایند طراحی معماری با ارائه ابزار­هایی برای این منظور می­باشد. ادامه مطالب گزارش به این صورت طبقه بندی شده اند. در بخش 2 توضیح مختصری در ارتباط با معماری نرم­افزار و مفاهیم مرتبط با آن ارائه می­شود. این مفاهیم در ادامه مطالب گزارش به کار گرفته خواهند شد. در بخش 3 طراحی معماری نرم­افزار، ویژگی­های یک طراحی خوب و عوامل تاثیرگذار در طراحی معماری مورد بررسی قرار خواهند گرفت. در بخش 4 روش­های طراحی معماری نرم افزار مورد بررسی قرار خواهند گرفت. در بخش 5 خلاصه و  نتیجه گیری ارائه خواهد شد. در بخش 6 مراجع مورد استفاده در این گزارش معرفی می­گردد.

    معماری نرم افزار چیست ؟

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

    در [Bass 03] معماری نرم افزار به صورت زیر تعریف شده است :

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

    از تعریف فوق می توان به نتایج زیر دست یافت :‌

    •   معماری، اجزای نرم افزار را تعریف می نماید. همچنین در این تعریف، از جزئیاتی از اجزا، که در نحوه استفاده و ارتباط با اجزای دیگر کاربردی ندارند؛ صرف نظر می گردد.

    •   هر سیستم نرم افزار شامل چندین ساختار می باشد؛ و هیچ یک از این ساختارها، به تنهایی معماری نرم افزار نمی­باشد. بلکه این ساختارها در کنار یکدیگر معماری نرم افزار را تشکیل می دهند.

    •   هر سیستم نرم افزاری دارای یک معماری می باشد. (زیرا هر سیستم نرم افزاری دارای اجزایی است که این اجزا با یکدیگر دارای رابطه می باشند).

    •   رفتار هریک از اجزاء، بخشی از معماری نرم افزار می باشد. (زیرا این رفتار در نحوه ارتباط بین اجزا تاثیرگذار است.)

    •   معماری نرم افزار باید قابل ارزیابی باشد تا بتوان از روی آن تشخیص داد سیستم مورد نظر بر پایه معماری انتخاب شده نیازهای خود را برآورده خواهد کرد یا خیر.

    علاوه بر تعاریف ارائه شده در [Bass03] تعاریف گوناگون دیگری نیز برای معماری نرم افزار ارائه شده است که در اینجا به برخی از آنها اشاره خواهیم کرد :

    در [IEEE00]معماری نرم افزار به صورت زیر تعریف شده است :

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

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

    در [Booch 98]  معماری نرم افزار مجموعه‌ای از تصمیمات مهم درباره ساختار سیستم نرم‌افزاری ، انتخاب اجزاء ساختاری و ارتباطات بین آنها و همچنین مشخص نمودن نحوه همکاری این اجزاء با یکدیگر می‌باشد. وقتی این اجزاء در کنار یکدیگر سیستم بزرگی را تشکیل دهند معماری نرم افزار به وجود خواهد آمد.

    در [Garlan 93]، معماری نرم‌افزار سطحی از طراحی تعریف شده است که دارای ویژگی‌های زیر می‌باشد :

    •   ورای الگوریتم و ساختمان داده طراحی شده باشد.

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

    •   ترکیبی از اجزاء طراحی باشد که از بین گزینه‌های طراحی موجود انتخاب شده است.

     

    در تعاریف ارائه شده توسط [Booch 98] و [Garlan 93]، از معماری به عنوان ساختار کلی سیستم نام‌ برده شده است. باید توجه داشت، ضعف این تعریف نسبت به تعریف ارائه شده توسط [Bass 03] در محدود کردن ساختار سیستم به تنها یک ساختار می‌باشد. در حالی که سیستم برای مشخص کردن معماری، دارای ساختار‌های گوناگون باشد.

    در [RUP 03] معماری نرم‌افزار سازمان یا ساختار اجزاء اصلی سیستم که از طریق واسط‌هایی با هم ارتباط برقرار می‌کنند؛ می‌باشد به طوری که هر یک از اجزاء از اجزاء کوچکتری تشکیل شده که این اجزاء کوچک نیز با یکدیگر ارتباط دارند. در این تعریف نیز، به ساختار‌های گوناگون اشاره نشده است. گرچه در [RUP 03] در مرحله طراحی معماری نرم‌افزار، ساختار‌ها یا دیدگاه های مختلفی برای معماری معرفی شده است.

     

    دیدگاه ما نسبت به معماری، دیدگاه [Bass 03] می‌باشد. یکی از نکات مهم در این تعریف، امکان ارائه ساختار‌های گوناگون برای معماری می‌باشد. این ساختار‌ها نباید محدود به چندین ساختار پیش فرض باشند. به عنوان مثال برای تولید معماری یک سیستم امن، می‌توان مدل امنیتی سیستم را نیز عضو معماری قرار داد. زیر بررسی و ارزیابی آن قبل از مرحله پیاده سازی بسیار حیاتی می‌باشد.

     

    تعاریف پایه در معماری نرم افزار

    در این بخش به بررسی برخی از مفاهیم پایه در معماری نرم افزار خواهیم پرداخت. در بخش های بعدی از این مفاهیم پایه استفاده زیادی خواهد شد.

    الگو­های معماری یا سبک­های معماری

    الگوهای معماری[2]  یا سبک ­های معماری[3] شامل شرحی از اجزاء و نوع روابط بین آنها می باشد به نحوی که تعدادی قانون برای معرفی اجزاء و نحوه ارتباط بین آنها، مشخص گردد. [Bass 03]

    به عنوان مثال client-server یک الگوی معماری است که مشخص می کند سیستم دارای دو جزء می باشد و این دو جزء تحت پروتکل خاصی با یکدیگر ارتباط دارند.

    هر الگوی معماری در برگیرنده تعدادی معیار کیفی[4] می باشد و معمار نرم افزار بر اساس نیازهای کیفیتی مورد نظر، الگوی معماری مناسب را انتخاب می نماید.

    در بسیاری از موارد از سبک‌های معماری، به جای الگوهای معماری استفاده می گردد.

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

     

    مدل مرجع[5]

    مدل مرجع، تقسیم بندی و تجزیه کارکردهای مختلف یک سیستم به همراه جریان داده های بین هریک از بخش‌ها می باشد. در حقیقت مدل مرجع، تقسیم بندی یک مسئله مشخص به اجزاء می‌باشد به گونه ای که این اجزا توانایی حل مسئله را داشته باشند. به عنوان مثال، مدل مرجع برای یک نرم افزار سیستم عامل، شامل بخش‌هایی نظیر : مدیریت حافظه، مدیریت دیسک، مدیریت فعالیت‌ها و ... می‌باشد.

     

    معماری مرجع [6]

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

     مدل مرجع

    الگوی معماری

    معماری مرجع

    معماری نرم افزار

     ارتباط بین الگوی معماری، مدل مرجع و معماری مرجع

     

    < >دیدگاه های معماری سیستم های مدرن و امروزی به اندازه ای پیچیده هستند که یه ساختار و دیدگاه واحد، توانایی نمایش همه جنبه های آنها را ندارد.[Bass 03] بنابراین برای نمایش معماری یک سیستم نرم افزاری از دیدگاه های مختلف استفاده می کنیم. یک ساختار یا دیدگاه معماری، نمایش مجموعه ای از اجزای معماری مرتبط با یکدیگر و ارتباط بین این اجزا می باشد.

     (تصاویر در فایل اصلی موجود است)

    دیدگاه Bass

    بر اساس طبقه بندی ارائه شده در [Bass 03] ساختارهای معماری نرم افزار قابل دسته بندی از سه گروه عمده به شرح زیر می باشند:

    •   ساختار ماژول‌ ها

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

    •   ساختار اجزاء و رابط‌ها 

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

    •   ساختار تخصیص منابع

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

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

     

    دیدگاه 4+1

    این دیدگاه در [Kruchten 95] ارائه شده و امروزه به عنوان استاندارد در IEEE 1471 [IEEE 00] مطرح می‌باشد. در این دیدگاه، ساختارهای معماری به صورت زیر طبقه بندی شده اند :

    •   Logical View

    •   Process View

    •   Deployment View

    •   Implementation View

    •   Use-case View

    همچنین این دیدگاه در [RUP 03] نیز به عنوان استاندارد توسعه معماری نرم افزار معرفی گردیده است. پایه این دیدگاه متدولوژی شیء گرا و ابزار استفاده از آن UML می باشد. برای استفاده بهینه از این دیدگاه پیشنهاد می شود که مدل فرایند انتخابی به صورت تکراری و بر پایه RUP انتخاب گردد.

     

    دیدگاه‌های دیگر

    از دیگر دیدگاه هایی که در [Garland 03]  معرفی گردیده شده می توان به :

    •   دیدگاه RM-ODP    (استاندارد ISO )

    •   دیدگاه Hofmeister

    اشاره نمود. برای جزئیات بیشتر به [Garland 03]  مراجعه شود.

  • فهرست:

    1 مقدمه 4
    2 معماری نرم افزار چیست ؟ 5
    2-1 تعاریف پایه در معماری نرم افزار 6
    الگوهای معماری یا سبک های معماری 6
    مدل مراجع 6
    معماری مرجع 6
    2-2 دیدگاه های معماری 7
    دیدگاه Bass 7
    دیدگاه 4+1 8
    دیدگاه‌های دیگر 8
    3 طراحی معماری نرم افزار 9
    3-1 کارکرد‌های سیستم و معماری نرم‌افزار 9
    3-2 ویژگی‌های کیفی 9
    3-3 ویژگی‌های کیفی سیستم 10
    3-4 سناریو‌های ویژگی‌کیفی 10
    3-5 ویژگی‌های کیفی کسب و کار 11
    3-6 ویژگی‌های کیفی معماری 12
    3-7 یک طراحی معماری خوب باید دارای چه ویژگی‌هایی باشد؟‌ 12
    3-8 دستیابی به ویژگیهای کیفی 12
    تاکتیکهای معماری 12
    الگوهای معماری 14
    ارتباط تاکتیکها و الگوهای معماری 15
    4 روشهای طراحی معماری نرم افزار 16
    4-1 طراحی مبتنی بر ویژگی 16
    4-2 طراحی به کمک سبک های معماری مبتنی بر ویژگی 17
    4-3 طراحی با ملاحظات اقتصادی با استفاده از روش آنالیز سود هزینه 19
    5 ویژگی کیفی قابلیت تغییر 23
    5-1 تعریف قابلیت تغییر 23
    5-2 مشخص نمودن نیاز‌های قابلیت تغییر با استفاده از سناریو‌های کیفی 23
    5-3 مدل سازی قابلیت تغییر در سطح معماری نرم افزار 24
    5-4 تاکتیک‌های قابلیت تغییر 24
    5-5 تاکتیک‌هایی که تغییرات را محلی می‌کنند. 25
    5-6 تاکتیک‌هایی که میدان دید وظایف را کاهش می دهند. 26
    5-7 تاکتیک‌هایی که از پخش شدن تغییرات جلوگیری می‌کنند. 26
    5-8 ارزیابی قابلیت تغییر 27
    ارزیابی نحوه اختصاص وظایف 27
    ارزیابی وابستگی بین ماژول‌ها 27
    انواع وابستگی 27
    نحوه بازنمایی وابستگی‌ها 29
    روش Brute-force 29
    استفاده از بستار انتقالی 29
    استفاده از روش‌های بهینه سازی 30
    استفاده از جدول وابستگی‌ها 30
    5-9 تصمیم گیری نهایی در مورد طراحی ویژگی کیفی قابلیت تغییر 30
    6 مطالعه موردی 31
    6-1 مرحله 1 - انتخاب یک سناریو حقیقی 31
    6-2 مرحله 2 - بررسی نوع سناریو حقیقی 31
    6-3 مرحله 3 - انتخاب چهارچوب استدلال مناسب 32
    6-4 مرحله 4 - مشخص نمودن پارامتر‌های محدود و آزاد 34
    6-5 مرحله 5 - مشخص کردن تاکتیک‌های وابسته به پارامتر‌های آزاد 35
    6-6 مرحله 6 - اختصاص مقادیر اولیه به پارامتر‌های آزاد 36
    6-7 مرحله 7 - انتخاب تاکتیک‌ها و به کاربردن آنها برای دستیابی به پاسخ مناسب 36
    استفاده از کامپایلر به عنوان واسط 38
    استفاده از سیستم‌عامل به عنوان واسط 38
    6-8 مرحله 8 : اختصاص مسئولیت‌ها به عناصر معماری 38
    7 خلاصه و نتیجه گیری 40
    8 مراجع 41


    منبع:

     

     

    [Asundi 01] J. Asundi, R. Kazman, and M. Klein, Using Economic Considerations to Choose Among Architecture  Design Alternatives, Technical Report, CMU/SEI-2001-TR-035, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2001.

     

    [Bachmann 02] F. Bachmann, L. Bass, and M. Klein, Illuminating the Fundamental Contributors to Software Architecture Quality, Technical Report, CMU/SEI-2002-TR-025, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2002.

     

    [Bachmann 03] F. Bachmann, L. Bass, and M. Klein, Deriving Architectural Tactics: A Step Toward Methodical Architectural Design, Technical Report, CMU/SEI-2003-TR-004, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2003.

     

    [Bass 01] L. Bass, M. Klein, F. Bachmann, "Quality Attribute Design Primitives and the Attribute Driven Design Method," In proc. of the 4th International Workshop on Product Family Engineering, Bilbao, Spain, 3-5 October 2001, pp. 122 - 130.

     

    [Bass 03] L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Second Edition, Addison-Wesley, 2003.

     

    [Booch 98] G. Booch, J. Rumbaugh, and I. Jacobson, UML User Guide, Addison-Wesley Longman, 1998.

     

    [Chastek 05] G. Chastek, and R. Ferguson, Toward Measures for Software Architectures, Technical Report, CMU/SEI-2006-TN-013, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2005

     

    [Garlan 93] D. Garlan, and M. Shaw. An Introduction to Software Architecture, Technical Report, CMU/SEI-94-TR-21, 1993.

     

    [Garland 03] J. Garland,  R. Anthony, Large-Scale Software Architecture, Wiley Press, 2003.

     

    [IEEE 00] Recommended Practice for Architectural Description of Software Intensive Systems. Technical Report IEEE P1471-2000, IEEE Standards Department, The Architecture Working Group of the Software Engineering Committee, September 2000.

     

    [Kazman 02] R. Kazman, J. Asundi, and M. Klein, Making Architecture Design Decisions: An Economic Approach, Technical Report, CMU/SEI-2002-TR-035, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 2001.

     

    [Klein 99] M. Klein, R. Kazman, Attribute-Based Architectural Styles, Technical Report, CMU/SEI-99-TR-022, Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, 1999.

     

    [Kruchten 95] P. Kruchten, "The 4+1 view model of architecture", IEEE Software, 12, No. 5, 1995.

     

    [RUP 03]  P. Kruchten, The Rational Unified Process: An Introduction, Third Edition, Addison-Wesley, 2003.

     

    [Shaw 96] M. Shaw, and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall, 1996.

     

    [Shaw 06] M. Shaw, and P. Clements, "The Golden Age of Software Architecture," IEEE Software, vol. 23,  no. 2,  pp. 31-39,  Mar/Apr,  2006.

     

    [With 02] P. H.N. de With, and and G. J. van Dijk, "Architecture assessment for practical management of system architectures", Proc. Workshop Embedded Systems (Progress02), Utrecht, NL, 2002.

کلمات کلیدی: Bass - سبک های معماری - سیستم نرم‌ افزاری - طراحی معماری نرم افزار - ماژول‌ - مدل مرجع - معماری - معماری - معماری مرجع - معماری نرم افزار
مقالات مرتبط با این مطلب:

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

عنوان طرح: تعریف معماری سازمان و پیاده سازی سیستم جامع اطلاعاتی و اتوماسیون مورد نیاز مرکز تأمین قطعات تراکتورسازی تبریز. مقدمه امروزه با پیشرفت تکنولوژی و تغییر ماهیت فعالیتهای مدیریتی، اطلاعات به عنوان اصلی ترین موجودیت در هر فرآیند کاری و مهمترین ابزار مدیریت می تواند نقش حائز اهمیتی در افزایش راندمان فرایندها و تضمین اهداف کسب و کار داشته باشد. رقابت موجود در دنیای تجارت، ...

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

RSS 2.0 عمران-معماري خاکبرداري آغاز هر کار ساختماني با خاکبرداري شروع ميشود . لذا آشنايي با انواع خاک براي افراد الزامي است. الف) خاک دستي: گاهي نخاله هاي ساختماني و يا خاکهاي بلا استفاده در

معماري سرويس گرا به عنوان يکي از آخرين دستاوردها در توليد نرم افزار، به نظر مي رسد، در سالهاي آتي معماري غالب صنعت فناوري اطلاعات و ارتباطات باشد. علت بوجود آمدن اين معماري، ايده اي بود که در ذهن تعدادي از معماران آن وجود داشت و آن نرم افزار به عنوا

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

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

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

شروع کار با ADO.NET ابتدا: بايد بدانيد که NET Data Provider . چيست؟ بمنظوراتصال به يک منبع داده ، مي بايست در ابتدا يک Net Data Provider . ، انتخاب گردد . Data Provider ، کلاس هاي لازم بمنظور اتصال به يک منبع داده ، خواندن اطلاعات ، ويرايش ، بهنگام

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

ثبت سفارش
تعداد
عنوان محصول