طراحی نرم افزار، دستاورد برتر دوره دوم پژوهشسرای جوان شهریار در بخش غرفه
طراحی نرم افزار ، فرآیند حل مشکل یا مشکلات پیاده سازی نرم افزار است.
نویسنده : نگار تجملیان
بازدید :
زمان تقریبی مطالعه :
تاریخ : پنج شنبه 1396/12/10 ساعت 12:32
دوازدهمین دوره از پروژه های دانش آموزی تبیان نیز با یاری خداوند و حضور پر شور شما دوستان و علاقمندان به پایان رسید.
در این دوره از جشنواره تعداد 126 گروه در بخش های سمینار های علمی، غرفه های نمایشگاهی و مسابقات به عنوان گروه های برتر، برگزیده و معرفی شدند.
بر آن شدیم تا با معرفی پروژه های گروه های برتر علاوه بر قدردانی از این دوستان نوآور، زمینه ای را برای ایده پروری سایر پژوهشگران علاقمند فراهم آوریم.
مقطع: دوره دوم متوسطه
موضوع: Slye یک نرم افزار است
نام مدرسه: پژوهشسرای جوان شهریار
نام استاد: آقای تورج منتظری شاه توری
دانش آموزان: علیرضا قدیمی، علی چراغعلی، ایمان اسماعیل زاده
مقدمه:
طراحی نرم افزار ، فرآیند حل مشکل یا مشکلات پیاده سازی نرم افزار است. یکی از اجزای اصلی طراحی نرم افزار ، نرم افزار مورد نیاز تجزیه و تحلیل (SRA) است. SRA بخشی از فرآیند توسعه ی نرم افزار است که مشخصات مورد استفاده در مهندسی نرم افزار را فهرست می کند. اگر نرم افزار نیمه اتوماتیک یا کاربر محور باشد، طراحی نرم افزار ممکن است با درگیر کردن «طراحی تجربه‌ی کاربر (User Experience Design) ، یک Storyboard ارائه کند تا به تعیین این مشخصات کمک کند. اگر نرم افزار به طور کامل اتوماتیک (به معنی بدون کاربر یا رابط کاربر) باشد، طراحی نرم افزار ممکن است به اندازه ی یک نمودار جریان کار (Flow Chart) یا متن توصیف توالی رویداد ها به صورت برنامه ریزی شده باشد. روش های نیمه استانداردی مانند زبان مدل سازی یکپارچه (Unified Modeling Language) و مفاهیم مدل سازی پایه نیز وجود دارد. در هر دو مورد، بعضی مستندات طرح معمولا، محصول طراحی است. علاوه بر این، طراحی نرم افزار، ممکن است بسته به فناوری مورد استفاده برای طراحی، مستقل از پلتفرم یا دارای پلتفرم مشخص باشد.
طراحی نرم افزار، هم یک فرآیند است و هم یک مدل. فرآیند طراحی، دنباله ای از مراحل است که طراح را قادر می سازد که تمام جنبه های ساخت نرم افزار را توصیف کند. خلاقیت و تجربه های گذشته، این احساس را ایجاد می کنند که چه چیزی یک نرم افزار «خوب» به شمار می رود و داشتن تعهد کلی در حفظ کیفیت، نمونه هایی از عوامل موفقیت قطعی برای طراحی شایسته است. با این وجود، مهم است که توجه داشته باشید که فرآیند طراحی همیشه یک روش ساده نیست. مدل طراحی را می توان با طرح معماری خانه مقایسه کرد، که با کلیت چیزی که باید ساخته شود، آغاز می شود (به عنوان مثال، ارائه ی تصویر سه بعدی خانه). هر چیزی که برای ساختن جزئیات (برای مثال طرح لوله کشی) ارائه شده است، به تدریج اصلاح شده است. به طور مشابه، مدل طراحی که برای نرم افزار ایجاد شده است، انواع مختلفی از دیدگاه های متفاوت نسبت به یک نرم افزار کامپیوتر398496 را فراهم می‌کند.
اصول طراحی اولیه، مهندس نرم افزار را قادر می سازد تا در فرآیند طراحی حرکت کند. «دیویس»، مجموعه ای از اصول طراحی نرم افزار را ارائه می دهد که لیست زیر از آن اقتباس شده و گسترش نیز یافته است:
·فرآیند طراحی نباید تک بعدی باشد. یک طراح خوب باید روش های جایگزین را در نظر بگیرد، که هر کدام بر اساس نیازمندی ها و منابع موجود برای انجام کار تشخیص داده شوند.
· طراحی باید به مدل تحلیلی مرتبط باشد. از آنجایی که اغلب، یک عنصر واحد در مدل طراحی، می تواند به چند نیازمندی برگردد، لازم است که برای ردیابی نحوه ی پوشش الزامات توسط مدل طراحی، راهی داشته باشیم.
·طراحی نباید چرخ را از اول اختراع کند. سیستم ها با استفاده از مجموعه ای از الگوهای طراحی ساخته شده اند که دیگران قبلا با بسیاری از موارد مشابه آن ها مواجه شده اند. این الگو ها همیشه باید به عنوان جایگزینی برای طراحی مجدد انتخاب شوند. زمان کوتاه است و منابع محدود است. زمان طراحی باید روی نمایش ایده های واقعا جدید و یکپارچه سازی الگوهایی که در حال حاضر وجود دارد، صرف شود.
·طراحی باید فاصله‌ی فکری را به حداقل برساند. فاصله‌ی بین نرم افزار و مشکلی که در دنیای واقعی وجود دارد. به عبارت دیگر، ساختار طراحی نرم افزار، هر زمان که ممکن باشد، باید شبیه ساختار دامنه‌ی مشکل (Problem Domain) باشد.
· طراحی باید یکنواخت و یکپارچه باشد. طراحی باید کاملا یکنواخت باشد. برای دستیابی به این نتیجه، قوانین قالب و سبک باید قبل از شروع طراحی، برای تیم طراحی تعیین شود. یک طراحی زمانی یکپارچه است که در تعریف رابط ها (Interfaces)، بین اجزای طراحی دقت شود.
· طراحی باید ساختار تطبیق با تغییرات را داشته باشد. هرگاه تغییری در نیازمندی ها اتفاق می افتد، طراحی باید متناسب با آن و به راحتی تغییر کند.
·طراحی باید ساختار تخریب به تدریج را دارا باشد، حتی زمانی که داده های نادرست وجود دارد یا حوادث یا شرایط عملیاتی ناخواسته رخ می دهد. نرم افزاری که به خوبی طراحی شده، نباید مختل شود. این مساله باید در طراحی دیده شده باشد، تا با شرایط غیرمعمول تطبیق داشته باشد و اگر درچنین شرایطی، لازم است که پردازش متوقف شود، باید این کار را به شیوه ای منحصر به فرد انجام دهد.
·طراحی برنامه نویسی نیست، برنامه نویسی طراحی نیست. حتی زمانی که طراحی های دقیق رویه ای (Procedural) برای اجزای برنامه ایجاد می شود، سطح انتزاع مدل طراحی، بالاتر از سورس کد است. تنها تصمیم های طراحی در سطح برنامه نویسی باید جزئیات پیاده سازی کوچکی را نشان دهد، که امکان طراحی کد رویه ای را می دهد.
· طراحی باید به اندازه ی کیفیت مورد انتظار ارزیابی شود، نه بیشتر از آن. مفاهیم طراحی و اقدامات طراحی متنوعی برای کمک به طراح در ارزیابی کیفیت در طول فرآیند توسعه وجود دارند.
·بازنگری در طراحی، باید صرفا به منظور به حداقل رساندن خطا های مفهومی (معنایی) صورت پذیرد. گاهی اوقات، هنگام بازنگری روی طراحی، تمایل به تمرکز بر روی برخی از نقاط، منجر به دور شدن از مسیر اصلی می شود. یک تیم طراحی، باید اطمینان داشته باشد که عناصر مفهومی عمده ی طراحی (اشکالات، ابهام، عدم انطباق)، قبل از نگرانی در مورد قواعد طراحی مدل، مورد توجه قرار گرفته اند.
مفاهیم طراحی
مفاهیم طراحی، طراحی نرم افزار بر پایه ی روش های پیچیده تر را به صورت کاربردی فراهم می کند. مجموعه ای از مفاهیم طراحی بنیادین، به شرح زیر تکامل یافته است:
انتزاع (Abstraction): انتزاع، فرآیند یا نتیجه ی تعمیم به وسیله ی کاهش محتوای اطلاعات یک مفهوم یا یک پدیده ی قابل مشاهده است، معمولا تنها به منظور حفظ اطلاعاتی که مربوط به یک هدف خاص است. انتزاع، بخشی از ارائه ی ویژگی های ضروری بدون جزئیات پس زمینه یا توضیحات است.
پالایش (Refinement): پالایش، فرآیند اصلاح است. سلسله مراتب، به وسیله‌ی تجزیه ی یک دیدگاه کل نگرانه از عملکرد، به صورت گام به گام، توسعه یافته است، تا دیدگاه زبان برنامه نویسی به دست آمده است. در هر مرحله، یک یا چند دستور العمل یک برنامه‌ی مشخص، به دستور العمل های دقیق تر تجزیه می شوند. انتزاع و پالایش، مفاهیم مکمل هم هستند.
پودمانی (Modularity): معماری نرم افزاری به اجزایی به نام پودمان (ماژول) تقسیم می شود.
معماری نرم افزار (Software Architecture): به ساختار کلی نرم افزار و شیوه هایی که این ساختار، یکپارچگی مفهومی به سیستم می دهد، اشاره دارد. معماری خوب، بازده خوبی با توجه به نتایج مورد نظر پروژه، مثلا از لحاظ عملکرد، کیفیت، برنامه و هزینه، خواهد داشت.
سلسله مراتب کنترل (Control Hierarchy): یک ساختار برنامه ای است که نشان دهنده ی سازمان یک جزء برنامه است و یک سلسله مراتب کنترل را نشان می دهد.
پارتیشن بندی ساخت یافته (Partitioning Structural): ساختار برنامه می تواند به صورت افقی و عمودی تقسیم شود. پارتیشن های افقی، شاخه های جداگانه ای از سلسله مراتب ماژولار را برای هر تابع برنامه اصلی تعریف می کند. پارتیشن بندی عمودی نشان می‌دهد که کنترل و کار باید در ساختار برنامه توزیع شود.
ساختمان داده (Data Structure): نشان دهنده ی ارتباط منطقی بین عناصر داده‌ای است. روند نرم افزار Software Procedure تمرکز بر پردازش هر یک از ماژول ها به صورت جداگانه است.
پنهان سازی اطلاعات (Information Hiding): ماژول ها باید مشخص و طراحی شوند تا اطلاعات موجود در یک ماژول برای ماژول های دیگر که نیازی به چنین اطلاعاتی ندارند، غیرقابل دسترسی باشد.
بخش پژوهش های دانش آموزی تبیان
تهیه: نگار تجملیان- تنظیم: محبوبه همت
در این دوره از جشنواره تعداد 126 گروه در بخش های سمینار های علمی، غرفه های نمایشگاهی و مسابقات به عنوان گروه های برتر، برگزیده و معرفی شدند.
بر آن شدیم تا با معرفی پروژه های گروه های برتر علاوه بر قدردانی از این دوستان نوآور، زمینه ای را برای ایده پروری سایر پژوهشگران علاقمند فراهم آوریم.
موضوع: Slye یک نرم افزار است
نام مدرسه: پژوهشسرای جوان شهریار
نام استاد: آقای تورج منتظری شاه توری
دانش آموزان: علیرضا قدیمی، علی چراغعلی، ایمان اسماعیل زاده
مقدمه:
طراحی نرم افزار ، فرآیند حل مشکل یا مشکلات پیاده سازی نرم افزار است. یکی از اجزای اصلی طراحی نرم افزار ، نرم افزار مورد نیاز تجزیه و تحلیل (SRA) است. SRA بخشی از فرآیند توسعه ی نرم افزار است که مشخصات مورد استفاده در مهندسی نرم افزار را فهرست می کند. اگر نرم افزار نیمه اتوماتیک یا کاربر محور باشد، طراحی نرم افزار ممکن است با درگیر کردن «طراحی تجربه‌ی کاربر (User Experience Design) ، یک Storyboard ارائه کند تا به تعیین این مشخصات کمک کند. اگر نرم افزار به طور کامل اتوماتیک (به معنی بدون کاربر یا رابط کاربر) باشد، طراحی نرم افزار ممکن است به اندازه ی یک نمودار جریان کار (Flow Chart) یا متن توصیف توالی رویداد ها به صورت برنامه ریزی شده باشد. روش های نیمه استانداردی مانند زبان مدل سازی یکپارچه (Unified Modeling Language) و مفاهیم مدل سازی پایه نیز وجود دارد. در هر دو مورد، بعضی مستندات طرح معمولا، محصول طراحی است. علاوه بر این، طراحی نرم افزار، ممکن است بسته به فناوری مورد استفاده برای طراحی، مستقل از پلتفرم یا دارای پلتفرم مشخص باشد.
تفاوت اصلی بین تجزیه و تحلیل نرم افزار و طراحی این است که خروجی تجزیه و تحلیل نرم افزار متشکل از حلِ مشکلات کوچک تری است. علاوه براین، تجزیه و تحلیل نباید در میان اعضای تیم یا گروه های مختلف، بسیار متفاوت صورت پذیرد. در مقابل، طراحی، بر توانایی ها متمرکز است، و بنابراین برای یک مشکل مشابه، می تواند طرح های متعدد وجود داشته باشد. بسته به محیط، طراحی، اغلب متفاوت است، چه از طریق چارچوب (Framework)های قابل اعتماد ایجاد شده باشد و یا با الگوهای طراحی (Design Patterns) مناسب انجام شود. مثال‌های طراحی شامل سیستم های عملیاتی، صفحات وب، دستگاه های تلفن همراه یا حتی الگوی رایانش ابری است.
طراحی نرم افزار، هم یک فرآیند است و هم یک مدل. فرآیند طراحی، دنباله ای از مراحل است که طراح را قادر می سازد که تمام جنبه های ساخت نرم افزار را توصیف کند. خلاقیت و تجربه های گذشته، این احساس را ایجاد می کنند که چه چیزی یک نرم افزار «خوب» به شمار می رود و داشتن تعهد کلی در حفظ کیفیت، نمونه هایی از عوامل موفقیت قطعی برای طراحی شایسته است. با این وجود، مهم است که توجه داشته باشید که فرآیند طراحی همیشه یک روش ساده نیست. مدل طراحی را می توان با طرح معماری خانه مقایسه کرد، که با کلیت چیزی که باید ساخته شود، آغاز می شود (به عنوان مثال، ارائه ی تصویر سه بعدی خانه). هر چیزی که برای ساختن جزئیات (برای مثال طرح لوله کشی) ارائه شده است، به تدریج اصلاح شده است. به طور مشابه، مدل طراحی که برای نرم افزار ایجاد شده است، انواع مختلفی از دیدگاه های متفاوت نسبت به یک نرم افزار کامپیوتر398496 را فراهم می‌کند.
اصول طراحی اولیه، مهندس نرم افزار را قادر می سازد تا در فرآیند طراحی حرکت کند. «دیویس»، مجموعه ای از اصول طراحی نرم افزار را ارائه می دهد که لیست زیر از آن اقتباس شده و گسترش نیز یافته است:
·فرآیند طراحی نباید تک بعدی باشد. یک طراح خوب باید روش های جایگزین را در نظر بگیرد، که هر کدام بر اساس نیازمندی ها و منابع موجود برای انجام کار تشخیص داده شوند.
· طراحی باید به مدل تحلیلی مرتبط باشد. از آنجایی که اغلب، یک عنصر واحد در مدل طراحی، می تواند به چند نیازمندی برگردد، لازم است که برای ردیابی نحوه ی پوشش الزامات توسط مدل طراحی، راهی داشته باشیم.
·طراحی نباید چرخ را از اول اختراع کند. سیستم ها با استفاده از مجموعه ای از الگوهای طراحی ساخته شده اند که دیگران قبلا با بسیاری از موارد مشابه آن ها مواجه شده اند. این الگو ها همیشه باید به عنوان جایگزینی برای طراحی مجدد انتخاب شوند. زمان کوتاه است و منابع محدود است. زمان طراحی باید روی نمایش ایده های واقعا جدید و یکپارچه سازی الگوهایی که در حال حاضر وجود دارد، صرف شود.
·طراحی باید فاصله‌ی فکری را به حداقل برساند. فاصله‌ی بین نرم افزار و مشکلی که در دنیای واقعی وجود دارد. به عبارت دیگر، ساختار طراحی نرم افزار، هر زمان که ممکن باشد، باید شبیه ساختار دامنه‌ی مشکل (Problem Domain) باشد.
· طراحی باید یکنواخت و یکپارچه باشد. طراحی باید کاملا یکنواخت باشد. برای دستیابی به این نتیجه، قوانین قالب و سبک باید قبل از شروع طراحی، برای تیم طراحی تعیین شود. یک طراحی زمانی یکپارچه است که در تعریف رابط ها (Interfaces)، بین اجزای طراحی دقت شود.
· طراحی باید ساختار تطبیق با تغییرات را داشته باشد. هرگاه تغییری در نیازمندی ها اتفاق می افتد، طراحی باید متناسب با آن و به راحتی تغییر کند.
·طراحی باید ساختار تخریب به تدریج را دارا باشد، حتی زمانی که داده های نادرست وجود دارد یا حوادث یا شرایط عملیاتی ناخواسته رخ می دهد. نرم افزاری که به خوبی طراحی شده، نباید مختل شود. این مساله باید در طراحی دیده شده باشد، تا با شرایط غیرمعمول تطبیق داشته باشد و اگر درچنین شرایطی، لازم است که پردازش متوقف شود، باید این کار را به شیوه ای منحصر به فرد انجام دهد.
·طراحی برنامه نویسی نیست، برنامه نویسی طراحی نیست. حتی زمانی که طراحی های دقیق رویه ای (Procedural) برای اجزای برنامه ایجاد می شود، سطح انتزاع مدل طراحی، بالاتر از سورس کد است. تنها تصمیم های طراحی در سطح برنامه نویسی باید جزئیات پیاده سازی کوچکی را نشان دهد، که امکان طراحی کد رویه ای را می دهد.
· طراحی باید به اندازه ی کیفیت مورد انتظار ارزیابی شود، نه بیشتر از آن. مفاهیم طراحی و اقدامات طراحی متنوعی برای کمک به طراح در ارزیابی کیفیت در طول فرآیند توسعه وجود دارند.
·بازنگری در طراحی، باید صرفا به منظور به حداقل رساندن خطا های مفهومی (معنایی) صورت پذیرد. گاهی اوقات، هنگام بازنگری روی طراحی، تمایل به تمرکز بر روی برخی از نقاط، منجر به دور شدن از مسیر اصلی می شود. یک تیم طراحی، باید اطمینان داشته باشد که عناصر مفهومی عمده ی طراحی (اشکالات، ابهام، عدم انطباق)، قبل از نگرانی در مورد قواعد طراحی مدل، مورد توجه قرار گرفته اند.
مفاهیم طراحی
مفاهیم طراحی، طراحی نرم افزار بر پایه ی روش های پیچیده تر را به صورت کاربردی فراهم می کند. مجموعه ای از مفاهیم طراحی بنیادین، به شرح زیر تکامل یافته است:
انتزاع (Abstraction): انتزاع، فرآیند یا نتیجه ی تعمیم به وسیله ی کاهش محتوای اطلاعات یک مفهوم یا یک پدیده ی قابل مشاهده است، معمولا تنها به منظور حفظ اطلاعاتی که مربوط به یک هدف خاص است. انتزاع، بخشی از ارائه ی ویژگی های ضروری بدون جزئیات پس زمینه یا توضیحات است.
پالایش (Refinement): پالایش، فرآیند اصلاح است. سلسله مراتب، به وسیله‌ی تجزیه ی یک دیدگاه کل نگرانه از عملکرد، به صورت گام به گام، توسعه یافته است، تا دیدگاه زبان برنامه نویسی به دست آمده است. در هر مرحله، یک یا چند دستور العمل یک برنامه‌ی مشخص، به دستور العمل های دقیق تر تجزیه می شوند. انتزاع و پالایش، مفاهیم مکمل هم هستند.
پودمانی (Modularity): معماری نرم افزاری به اجزایی به نام پودمان (ماژول) تقسیم می شود.
معماری نرم افزار (Software Architecture): به ساختار کلی نرم افزار و شیوه هایی که این ساختار، یکپارچگی مفهومی به سیستم می دهد، اشاره دارد. معماری خوب، بازده خوبی با توجه به نتایج مورد نظر پروژه، مثلا از لحاظ عملکرد، کیفیت، برنامه و هزینه، خواهد داشت.
سلسله مراتب کنترل (Control Hierarchy): یک ساختار برنامه ای است که نشان دهنده ی سازمان یک جزء برنامه است و یک سلسله مراتب کنترل را نشان می دهد.
پارتیشن بندی ساخت یافته (Partitioning Structural): ساختار برنامه می تواند به صورت افقی و عمودی تقسیم شود. پارتیشن های افقی، شاخه های جداگانه ای از سلسله مراتب ماژولار را برای هر تابع برنامه اصلی تعریف می کند. پارتیشن بندی عمودی نشان می‌دهد که کنترل و کار باید در ساختار برنامه توزیع شود.
ساختمان داده (Data Structure): نشان دهنده ی ارتباط منطقی بین عناصر داده‌ای است. روند نرم افزار Software Procedure تمرکز بر پردازش هر یک از ماژول ها به صورت جداگانه است.
پنهان سازی اطلاعات (Information Hiding): ماژول ها باید مشخص و طراحی شوند تا اطلاعات موجود در یک ماژول برای ماژول های دیگر که نیازی به چنین اطلاعاتی ندارند، غیرقابل دسترسی باشد.
بخش پژوهش های دانش آموزی تبیان
تهیه: نگار تجملیان- تنظیم: محبوبه همت
