در جزوه چهارم پاسخنامه و جواب آزمون طراحی معماری آزمون نظام مهندسی مرداد ۱۳۹۴ به طور کامل بیان گردیده است و کلیه نقشه ها و خواسته هایی که در صورت سوالات آزمون طراحی معماری نظام مهندسی مطرح گردیده است به صورت کامل و جامع ارائه شده است.
این پروژه شامل مطالب جامع و کاملی از روستای ماسوله واقع در شمال کشور میباشد.که در آن به بررسی اقلیم و آب و هوا و مصالح و ....روستا و خانه های آن پرداخته شده است که وجود تصاویر ضمیمه و نیز پلانهای موجود و اسکیسهای دستی از نقاط مختلف روستا کمک شایانی به این پروژه کرده است.
این فایل در قالب ورد و قابل ویرایش در 115 صفحه می باشد.
فصل ۱
۱-۱- مقدمه ۲
۱-۱-۱ – معماری سرویس گرا چیست؟ ۳
۲-۱-۱- ویژگی های سیستم های مبتنی بر معماری سرویس گرا ۹
۳-۱-۱- آماده شدن برای معماری سرویس گرا ۱۲
۲-۱- معرفی ۱۵
۳-۱- ویژگیهای سرویس و محاسبات سرویس گرا ۱۷
۴-۱- نرم افزار به عنوان سرویس ۱۹
۵-۱- مفهوم معماری سرویس گرا ۲۰
۶-۱- معماری سرویس گرای مقدماتی ۲۳
۷-۱- معماری سرویس گرای توسعه یافته ۲۵
۸-۱- نیازمندیهای معماری سرویس گرا ۲۹
فصل ۲ : معماری سرویس گرا
۱-۲- مقدمه ۳۲
۲-۲- محرک های تجاری در رویکردی جدید ۳۲
۳-۲- معماری سرویس گرا به عنوان یک راه حل ۳۵
۱-۳-۲- تجزیه و تحلیل و طراحی شی گرا ۳۵
۲-۳-۲- طراحی بر مبنای جزء ۳۶
۳-۳-۲- طراحی سرویس گرا ۳۷
۴-۳-۲- طراحی بر مبنای واسط ۳۹
۵-۳-۲- معماریهای برنامه های کاربردی لایه ای ۴۱
۴-۲- نگاهی دقیق تر بر معماری سرویس گرا ۴۲
۱-۴-۲- جنبه های عملکردی ۴۳
۲-۴-۲- جنبه های کیفیت سرویس ۴۴
۳-۴-۲- همکاری SOA ۴۵
۴-۴-۲- نقش ها در معماری سرویس گرا ۴۵
۵-۴-۲- عملیات در معماری سرویس گرا ۴۶
۶-۴-۲- سرویس در بافت SOA ۴۸
۷-۴-۲- سرویس در برابر اجزاء ۴۹
۵-۲- مزایای معماری سرویس گرا ۵۱
۱-۵-۲- بالا بردن دارایی های موجود ۵۱
۲-۵-۲- مجتمع سازی و اداره کردن راحت تر پیچیدگی ۵۲
۳-۵-۲- پاسخگویی بیشتر و خرید و فروش سریعتر ۵۲
۴-۵-۲- کاهش هزینه و افزایش استفاده مجدد ۵۲
۵-۵-۲- آمادگی در برابر حوادث ۵۳
فصل ۳ : معماری سرویس وب
۱-۳- مقدمه ۵۵
۲-۳- سرویس وب چیست؟ ۵۶
۳-۳- مدل چند لایه مبتنی بر XML-Web service ۵۶
۱-۲-۳- برخی از ویژگیهای سرویس های وب ۶۳
۴-۳- قابلیت عملکرد متقابل سرویس های وب ۶۵
۱-۱-۳-۳- انگیزه های مالی برای معماری سرویس گرا ۶۶
۲-۱-۳-۳- خصیصه های معماری سرویس وب ۶۸
۳-۱-۳-۳- سازمان قابلیت عملکرد متقابل سرویس های وب ۶۹
۴-۱-۳-۳- خصوصیات گزارش ۷۱
۵-۱-۳-۳- موارد کاربردی و سناریوی مورد استفاده ۷۲
۶-۱-۳-۳- برنامه های کاربردی نمونه ۷۱
۷-۱-۳-۳- ابزارهای تست ۷۲
۲-۳-۳- گزارش بر مبنای WS-I 1.0 ۷۲
۱-۲-۳-۳- سناریوی مورد استفاده یک طرفه ۷۳
۲-۲-۳-۳- سناریوی مورد استفاده تقاضا / پاسخ همزمان ۷۳
۳-۲-۳-۳- سناریوی مورد استفاده تماس برگشتی اولیه ۷۳
فصل ۴ : انتخابهای تکنولوژی
۱-۴- انتخابهای تکنولوژی ۷۶
۲-۴- مقدمه ۷۷
۱-۲-۴- مزایای سرویس های وب ۷۷
۲-۲-۴- معایب سرویس های وب ۷۸
۳-۴- لایه های پشته معماری سرویس گرا ۷۹
۱-۳-۴- حمل و نقل ۷۹
۲-۳-۴- پروتکل تبادل سرویس ۸۰
۳-۳-۴- شرح سرویس ۸۱
۴-۳-۴- سرویس ۸۲
۱-۴-۳-۴- سرویس وب و J2EE ۸۲
۲-۴-۳-۴- چارچوب کاری احضار سرویس وب ۸۳
۳-۴-۳-۴- برخی ملاکهای مؤثر در انتخاب چهارچوبها ۸۴
۵-۳-۴- فرآیند تجاری ۹۲
۶-۳-۴- بایگانی سرویس ۹۴
۱-۶-۳-۴- درخواست مستقیم ۹۴
۲-۶-۳-۴- انتشار جمعی ساده ۹۴
۳-۶-۳-۴- استفاده از دایرکتوری ۹۵
۷-۳-۴- سیاست ۹۵
۱-۷-۳-۴- استانداردهای نوظهور برای سیاست ۹۶
۸-۳-۴- امنیت ۹۷
۹-۳-۴- معاملات ۱۰۲
۱-۹-۳-۴- استانداردهای نوظهور برای معاملات ۱۰۳
- WS-Coordination ۱۰۳
- WS-Transaction ۱۰۴
پشتیبانی نگهداری برای سرویس وب ۱۰۴
۱۰-۳-۳- مدیریت ۱۰۵
نتیجه گیری ۱۰۷
خلاصه ۱۰۸
منابع ۱۱۲
معماری سرویس گرا به عنوان یکی از آخرین دستاوردها در تولید نرم افزار، به نظر می رسد، در سالهای آتی معماری غالب صنعت فناوری اطلاعات و ارتباطات باشد. علت بوجود آمدن این معماری، ایده ای بود که در ذهن تعدادی از معماران آن وجود داشت و آن نرم افزار به عنوان سرویس بود. در مدل نرم افزار به عنوان سرویس شما نرم افزار خود را بگونه ای طراحی می کنید که قابل استفاده توسط سیستم های دیگر باشد یعنی دیگران می توانند برای استفاده از سرویس شما ثبت نام کنند و هر موقع که لازم داشتند از خدمات آن بهره ببرند، همانند حالتی که در مورد شبکه های تلویزیون کابلی وجود دارد. تا زمانی که شما به سرویس متصل هستید، شما می توانید هر لحظه که خواستید از سرویس استفاده کنید.
برای مدتهای طولانی برنامه نویسان سعی می کردند تا، کدهای خود را بصورت modular بنویسند، تا بتوان از آن در تولید نرم افزارهای دیگر استفاده کرد. تفاوت نوشتن کد بصورت modular و بر اساس معماری سرویس گرا در حجم مخاطبان آن است.
دوباره به همان مثال اول برمی گردیم، وقتی شما کد خود را به منظور قابل استفاده بودن توسط نرم افزارهای دیگر، به شکل Modular می نویسید مانند این است که، یک شبکه تلویزیون کابلی درون یک ساختمان خاص دارید و بنابراین فقط ساکنین آن ساختمان می توانند از آ« بهره برداری کنند.
در جهان امروز طیف مخاطبانی که بالقوه می توانند از سرویس شما استفاده کنند، کل کاربران روی شبکه اینترنت است. بنابراین باید مکانیزمی بوجود می آمد، که می توانست پاسخگوی این محیط جدید (اینترنت) و کاربران آن باشد و بنابراین معماری سرویس گرا بوجود آمد. این معماری توسط دو شرکت IBM ، Microsoft بوجود آمد، که هر دو شرکت طی سالهای اخیر از حامیان اصلی سرویسهای وب و عامل بسیاری از ابداعات جدید در حیطه سرویس های وب، مانند WSE ، UDDI بوده اند. قابل ذکر است، که در آخرین معماری در حال توسعه، در تولید نرم افزار که هنوز هم در مرحله تحقیقاتی است (MDA) ، تدابیری جهت هماهنگی با معماری سرویس گرا در نظر گرفته شده است.
از نمونه های استفاده از این معماری در کشور خودمان، سازمان ثبت احوال کشور است که موظف شده تا پایگاه اطلاعاتی خود را بصورت سرویس وب و مبتنی بر این معماری به سایر نهادها مانند نیروی انتظامی و سایر دستگاه ها ارائه دهد.
همان طور که در عنوان آن مشخص است، به مفهومی در سطح معماری، اشاره می کند و بنابراین در مورد چیزی پایه ای و اساسی در سطوح بالا است، که پایه و اساس آن تجربیات بدست آمده در تولید سیستم های نرم افزاری مبتنی بر CBD و دو اصل اساسی در صنعت مهندسی نرم افزار یعنی تولید نرم افزار بصورت با همبستگی زیاد و در عین حال با چسبندگی کم است. بنابراین ایده های برنامه نویسی سرویس گرا ایده ا جدید نیست و شما شاید قبلاً از آن استفاده کرده باشید. اما جمع آوری بهترین تجربیات از تولید چنین سیستمهایی بصورت مجتمع و ناظر به وضعیت تکنولوژیکی امروز بشر، که همان مفاهیم مطرح شده در معماری سرویس گرا است چیز جدیدی است. در زیر بصورت دقیق تر این بحث را ادامه می دهیم آیا تولید سیستم های سرویس گرا مفهوم جدیدی است؟ مهندسان نرم افزار، همیشه می گفتند و گفته اند که نرم افزار باید به شکلی نوشته شود که همبستگی زیاد ولی در عین حال اتصال کمی داشته باشد. شرکتهای بزرگ نرم افزاری هم در جهت گام برداشتن برای رسیدن به این دو اصل، تکنولوژی هایی را بوجود آورده اند که به برنامه نویسان اجازه دهد تا به این دو هدف در تولید نرم افزارهای خود تا حد زیادی دست یابند. برای مثال می توان به تکنولوژی هایی مانند CORBA ، COM+ و RMI و موارد دیگر، اشاره کرد. خوب پس مشاهده کردید که موضوع برنامه نویسی سرویس گرا، مفهوم جدیدی نیست و این معماری تلاشی دیگر در جهت تولید نرم افزارهای با همبستگی زیاد و در عین حال با چسبندگی و اتصال کم است. ممکن است بپرسید، پس چرا با وجود تکنولوژی های قدرتمندی چون RMI ، COM+ و CORBA چیز جدیدی بوجود آمد؟ مگر تکنولوژی های قبلی موفق نبودند؟ بله مهمترین اشکال در معماری های قدرتمندی چون موارد مذکور این بود که تولید کنندگان آنها سعی داشتند، که تکنولوژی خود را بر بازار غالب نمایند. رویایی که هرگز به حقیقت نمی پیوست . بنابراین با توجه به این موضوع که این تکنولوژیها قادر به تعامل مناسب با یکدیگر نبودند عملاً اصل همبستگی زیاد بصورت خود بخود رد می شد.
البته معماری های مذکور اشکالات دیگری هم داشتند که نسبت به موارد بالا از اهمیت کمتری برخوردار است که از جمله آنها می توان به عدم هماهنگی با اصول امنیتی مورد استفاده در اینترنت اشاره کرد. البته بعدها راه حل هایی هم برای این مشکل بوجود آمد (مانند Over HTTP RPC ) اما به این علت که از روز اول، در طراحی این تکنولوژی ها این امر در نظر گرفته نشده بود، از کارایی مناسبی برخوردار نبودند. مفهوم همبستگی زیاد و در عین حال با چسبندگی و اتصال کم، وقتی بخواهد در جهت ارزیابی یک سیستم نرم افزاری یا تکنولوژی، مورد استفاده قرار گیرد بسیار مبهم می شود. حتی کسی می تواند ایده های همبستگی و چسبندگی را با هم ترکیب کند! برای جلوگیری از چنین ابهاماتی، شما می توانید از ویژگی های معماری سرویس گرا به عنوان یک راه برای ارزیابی میزان همبستگی و چسبندگی و اتصال یک سیستم نرم افزاری یا یک تکنولوژی استفاده کنید. اگر چه مفاهیم مطرح شده در معماری سرویس گرا دقیقاً همان مفاهیم همبستگی زیاد و در عین حال چسبندگی کم نیستند، اما سیستمهایی که بر اساس معماری سرویس گرا طراحی و پیاده سازی شده اند، نشان داده اند که توانسته اند تا حد بسیار زیادی ویژگی های همبستگی زیاد و در عین حال چسبندگی کم را بخوبی در خود ایجاد و حفظ کنند.
معماری سرویس گرا (SOA) روشی جدید و در حال تکامل برای ساخت برنامه های توزیع شده است. سرویس ها اجزای توزیع شده با رابط های تعریف شده و مشخص هستند که پیغام های XMIL را پردازش و تبادل می کنند. با رویکرد سرویس گرا می توان راه حل هایی را ارائه داد که به مرز دامنه های سازمان یا شرکت محدود نیستند. با استفاده از SOA می توان در شرکتی که دارای سیستم ها و برنامه های کاربردی مختلف روی ایستگاه های کاری متفاوت است، یک راه حل یکپارچه سازی با استقلال زیاد ساخت که جریان یکنواخت و ناهماهنگ کار را تضمین کند.
هرکس که از سایت های تجارت الکترونیکی به صورت آنلاین خرید کرده باشد، با مفهوم سرویس ها آشنا است. وقتی که سفارش تان را دادید، باید اطلاعات کارت اعتباری تان را ارایه کنید که به طور معمول توسط یک فراهم کننده سرویس ثانویه، تأیید و شارژ می شود. وقتی که سفارش پذیرفته شد، شرکت سفارش گیرنده با یک شرکت فراهم کننده سرویس حمل و نقل هماهنگ می کند و در نهایت کالای شما تحویلتان می شود. نیاز به معماری سرویس گرا از جنبه های دیگر نیز به شکل بارزی در برنامه های کاربردی تجارت الکترونیکی مشهود است. اگر مثلاً جزء مربوط به پرداخت کارت اعتباری Offline و یا غیر فعال باشد، قرار نیست که فرآیند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوند و عملیات پرداخت به وقت دیگری موکول شود.
مثل سایر معماری های توزیع شده، SOA ساخت برنامه های کاربردی با استفاده از اجزایی که در دامنه های جدا از هم قرار دارند را ممکن می سازد. SOA از سرویس های وب به عنوان نقاط ورود برنامه کاربردی استفاده می کند که از لحاظ مفهومی معادل همان اجزای Proxy و Stub در سیستم های توزیع شده سنتی مبتنی بر اجزاء هستند. با این تفاوت که در این جا ارتباط بین سرویس وب و استفاده کننده خیلی آزادانه تر و مستقل تر است. به علاوه SOA به خاطر در برداشتن فاکتورهایی که اهمیت حیاتی در تجارت دارند، نیز منحصر به فرد است. فاکتورهایی نظیر: قابلیت اطمینان سرویس، جامعیت پیام، یکسانی تراکنش و امنیت پیام. در امور تجاری واقعی نمی توان روی سرویس هایی که یک درخواست را فقط به خاطر این که بتوانند بفهمند، پردازش می کنند حساب کرد. در امور تجاری به قطعیت و اطمینان بیشتری خاطر این که بتوانند بفهمند، پردازش می کنند حساب کرد. در امور تجاری به قطعیت و اطمینان بیشتری نیاز است. واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف متفاوت باشد. با وجود این هیچکدام از این موارد نباید برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند.
واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف، متفاوت باشد. با وجود این، هیچ کدام از این موارد نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند. علاوه بر آن نباید هیچ ابهامی در نحوه فراخوانی یک سرویس وجود داشته باشد. اگر سیستمی توانایی های خود را در قالب سرویسی روی وب ارائه کند، در آن صورت نحوه فراخوانی آن سرویس باید به طور واضح مستندسازی و اعلام شود. بسیاری از مسائل دسترس پذیری و مقیاس پذیری برنامه های کاربردی امروزی در SOA حل شده است که احتمال نقض آن در هر مرحله ای از جریان کار بسیار زیاد است. در SOA فرض بر این است که خطا وجود دارد و می تواند اتفاق بیفتد، بنابراین استراتژی هایی برای برخورد با این خطاها در نظر گرفته است. به عنوان مثال اگر یک سرویس نتواند یک پیغام را در مرحله اول بپذیرد، این معماری طوری طراحی شده است که مجدداً پیام را بفرستد.
و اگر یک سرویس به طور کامل قابل دسترس نباشد، (که هرگز نباید در یک سیستم SOA پایدار اتفاق بیفتد) آن وقت معماری طوری طراحی شده است که روی دادن خطاهایی که منجر به قطع کامل در خواست سرویس می شود، امکان پذیر نباشد. SOA قابلیت اطمینان را افزایش می دهد، چون خطاهای موقت در بخشی از جریان کار نمی توانند کل فرآیند تجاری را از کار بیاندازند.
به بیان کلی، SOA فرآیندی تکامل یافته را ارائه می نماید و از این نظر می توان آن را بلوغ سرویس های وب و تکنولوژی های یکپارچه سازی به حساب آورد. در SOA به این امر توجه شده است که سیستم های با اهمیت حیاتی که بر مبنای تکنولوژی های توزیع شده ساخته می شوند، باید تضمین های خاصی را تأمین نمایند. در این گونه سیستم ها باید این اطمینان وجود داشته باشد که درخواست های سرویس به طور صحیح مسیر دهی و هدایت شوند، در زمان مناسب به آن ها پاسخ داده شود، و این سرویس ها به طور واضح و دقیق سیاست های ارتباطی و رابط های خود را اعلام کنند.
- استفاده کنندگان از سرویس هیچ لزومی ندارد از جزئیات پیاده سازی سرویس در سمت سرویس دهنده مطلع باشد.
- محل سرویس دهنده باید از نظر استفاده کننده از سرویس پنهان باشد (در انجام امور مرتبط با استفاده از سرویس) و تنها در زمان اجرای سرویس گیرنده از مکان سرویس دهنده آگاه خواهد شد.
- نرم افزار مبتنی بر معماری سرویس گرا باید بتواند با نرم افزارهای موجود روی سایر پلتفرم ها تعامل داشته باشد.
- چندین نسخه از سرویس باید بصورت همزمان در کنار هم فعالیت کنند زیرا با توجه به طیف گسترده استفاده کنندگان در صورت بروز رسانی سرویس در سمت سرویس دهنده ، به سرعت امکان بروز رسانی استفاده کنندگان سرویس وجود ندارد.
همچنین تعدادی از ویژگی هایی که هر نرم افزار، اعم از اینکه مبتنی بر این معماری باشد یا نباشد، باید داشته باشد به شرح زیر است :
کارآیی زیاد
امنیت بالا ( تضمین محرمانگی، صحت اطلاعات و همیشه در دسترس بودن) و همچنین کنترل دسترسی
قابلیت اطمینان بالا بخصوص وقتی سروکار با تراکنش های چند مرحله ای است.
سرویس های وب به عنوان پایه معماری سرویس گرا : سیر تکامل و رشد XML، با پیدایش سرویس های وب همراه بود. یک سرویس وب بهترین راه حل برای پیاده سازی معماری سرویس گرا است، مخصوصاً وقتی دیدگاه استفاده از کل کاربران اینترنت به عنوان کاربران بالقوه سرویس مطرح باشد. شما پایه کار خود را بر پروتکل HTTP بنا می نهید، پروتکلی که از همه پروتکل های دیگر روی اینترنت قابل دسترس تر است. با نگاه به قابلیتهای سیستم های نرم افزاری مبتنی بر معماری سرویس گرا، شما متوجه خواهید شد که سرویس های وب بسیاری از موارد مطرح شده در بالا را رعایت می کنند اما تعدادی از اصول مطرح شده را هم زیر پا می گذارند که آن را بررسی می کنیم :
کارآیی : XML که عنصر اصلی سازنده سرویسهای وب است، نسبت به سایر مکانیزم های انتقال اطلاعات (binary) از سربار بسیار زیادی برخوردار است.
قابلیت اطمینان در تراکنش ها : اگر شما در یک تراکنش از یک سرویس وب استفاده کنید، چگونه می توانید صحت تراکنش را تضمین کنید در حالی که تمام کارهای شما مبتنی بر اینترنت و پروتکل HTTP است؟
امنیت : شما چگونه می توانید کاربران سرویس خود را تصدیق هویت کنید تا بعد از آن بتواند صلاحیت آنها را در استفاده از سرویس تان مورد بررسی قرار دهید؟
همچنین یک نکته منفی دیگر در مورد سرویس های وب در حال حاضر، عدم پشتیبانی اکثر محیط های نرم افزار (IDE) برای تولید و استفاده از آنها است و در عین حال فراهم کردن قابلیتهایی مانند کمک به برنامه نویس در استفاده از متدها و غیره یا پیدا کردن خطاها در زمان کامپایل و نه زمان اجرا.
بنابراین، مگر اینکه موارد فوق به نحوی حل نگردد، ممکن است استفاده از سرویس های وب به عنوان پایه معماری سرویس گرا مورد سوال قرار گیرد. البته در هر حال سرویس های وب از این نظر که طیف کاربران بالقوه آنها اینترنت است بسیار مورد توجه هستند. در حال حاضر هم در اکثر سازمانها برای تمامی نرم افزارها یک واسط بصورت وب سرویس جهت فراهم کردن استفاده از آن برای سازمانهای همکار فراهم می شود و یا حتی در داخل سازمان و در مواردی که استفاده از نرم افزار مذبور در داخل سازمان بسیار استفاده شود، با توجه به مشکلات کارایی سرویس های وب، یک واسط بصورت یکی از تکنولوژی های برنامه نویسی مبتنی بر Component مانند +Com و یا CORBA برای نرم افزار ایجاد می شود.
آموزش مدلسازی و ویرایشات در تریدی مکس 2016 در زمینه معماری(فصل اول : بخش مقدماتی)
Tutorial 3DS Max Design For Architectural
اپلیکیشن اندروید
موزش ها بصورت تجربی-کاربردی و کامل میباشد.
به دلیل حجم زیاد آموزش، در 4 فصل ارائه شده است:
1- فصل اول: مدلسازی-ویرایشات معماری(مقدماتی)
2- فصل دوم:متریال-نورپردازی-رندر معماری(متوسطه)
3- فصل سوم: انجام پروژه خارجی V-Ray از مدلسازی تا رندر معماری(پیشرفته)
4- فصل چهارم: انجام پروژه داخلی V-Ray از مدلسازی تا رندر معماری(پیشرفته)
آموزش : مجتبی کاظمپور
دقت کنید،جهت فراگیری کامل آموزش حتما از نسخه اول به ترتیب شروع کنید.
دانلود گزارش کامل کار آموزی رشته معماری شرکت مشاوره ارکان توسعه روند طراحی نقشه های ساختمانی بافرمت ورد وقابل ویرایش تعدادصفحات 35
پروژه کارآموزی آماده,دانلود کارآموزی,,پروژه کارورزی,گزارش کار آموزی
این پروژه کارآموزی بسیار دقیق و کامل طراحی شده و جهت ارائه واحد درسی کارآموزی
چکیده
طبقه همکف : اطلاعات، سرویس های بهداشتی آقایان و خانم ها، اتاق های مربیان، تعدادی انبار، آبدارخانه، آزمایشگاههای آنالیز و سیگامی، شیمی و فیزیک، معدنی عمومی، شیمی آلی، فیزیک مکانیک، مکانیک سیالات، تحقیقات شیمی، اتاق رسمی فنی. طبقه اول و دوم : سرویس های بهداشتی آقایان و خانم ها، اتاق های مربیان، تعدادی انبار، آبدارخانه، آزمایشگاههای اپتیک، فیزیک الکترونیک، مدار منطقی، الکترونیک، میکروبیولوژی، فیزیولوژی، کشاورزی، بیوشیمی، اتاق استراحت مربیان. طبقه سوم : اتاق منشی و مسئول، سرویس های بهداشتی آقایان و خانم ها، اتاق های مربیان، تعدادی انبار، آزمایشگاه معماری کامپیوتر، کارگاههای آموزش کامپیوتر، ساخت و تعمیر آزاد کامپیوتر. در ادامه تعدادی از نقشه ها و عکس های مربوط به این ساختمان ارائه می شود. و پلانهای مسکونی که هر کدام در قسمت خود آن توضیح داده شده است. مقدمه : معماری پنجره‌ای است که اگر آن را بگشایی همه چیز را زیباتر خواهی دید زیباتر زندگی خواهی کرد. و تأثیر آن بر روح آدمی مطمئناً پلکانی خواهد بود به سوی بالا اگر یادمان نرود که معماری هنری است متناسب با فرهنگ هر ملت و معماری باید مردمی، همراه با احساسات انسانی و منظم باشد. به امید آن روز که تمام سعی خود را برای داشتن مکانی زیباتر، امن تر و راحت تر برای زندگی کردن بنماییم. فصل اول معماری رهیافتی است به جعبه‌ای با دو بعد آرمان و هدف، آرمان معماری فرم بخشیدن به یک الگوی جهانی و هدف آن، بیدار کردن احساس انسانی است و برای رسیدن به این دو باید از فن و هنر در کنار یکدیگر بهره برد. موضوع اولیه معماری ایجاد یک الگوی فضایی است، یعنی نظم بخشیدن به یک فضای برهنه و عاری از هر چیز. انتظام فضایی. به معنای استفاده از فرمی است که فضا منشاء آن است و نظمی شفاف آن را به فضا مرتبط می‌کند. برای دستیابی به این هدف، معماری به هندسه نیاز دارد، هندسه علم ایجاد نظم منطقی و هوشمندانه‌ای است که حامل ارتباط فرم با فرم و فرم با فضا میباشد. از این رو، هندسه فرم آرمانی را ایجاد می‌کند، فرمی که بیان بصری مفهوم است و فضایی انتزاعی در آن تجلی می‌یابد. به طور کلی هندسه به ارتباطات منطقی خالص توجه دارد، بنابراین هندسه مفاهیم و ارزشهای اجتماعی را منعکس می‌سازد و جهانی با منطق شفاف ایجاد می‌کند. به طور خلاصه، هندسه ثباتی منطقی باقی می‌ماند و ارزش‌هایی چون صداقت، زیبایی و خوبی در مرحله دوم ارائه می‌شوند. منطقی که احساس را طرد می‌کند و تنها درباره حقیقت با ما صحبت می‌کند. معماری، پیوسته در جستجوی انتظامی است که بر اساس نیروی طبیعی و جاذبة زمین باشد، اگر چه هنوز به آن دست نیافته است. بر خلاف هندسه، معماری نمی‌تواند در تمام ابعاد نفوذ کند، زیرا نیروی جاذبه آن را به حرکت‌های افقی و عمودی محدود می‌سازد. معماری، الگویی پویاست. یک ساختمان طبیعتاً حرکت می‌کند ولی زمانی که مردم در امتداد مسیری حرکت می‌کنند، شکل آن در حال حرکت به نظر می‌رسد. مردم با حرکت و تغییر نقطه دیدشان فرم کلی معماری را در ذهن تجسم می‌کنند. موضوع دوم در معماری بیدار کردن احساسات انسانی است. هندسه، فضایی منطقی و با ثبات ایجاد می‌کند. ولی به راستی، این منطق چگونه ما را با تجربه‌های معماری آشنا می‌سازد؟ آیا تنها نظم هندسی است که فضا را روشن و واضح می‌سازد؟ آیا هندسه باعث یکنواختی و سکون نیست؟ آیا نیازی به رهایی فضا از ثبات هندسی ناشی می‌شود؟ آیا فرم و فضا صرفاً باید بر اساس منطق هندسی شکل گیرد؟ هنگامی که چند فرم یا حجم در کنار هم قرار می‌گیرند، این هندسه و منطق هندسی است که به آنها نظم و ترتیب می‌بخشد. زمانی که این انتظام بین عناصر معماری مانند ستون، دیوار، سقف و کف ایجاد می‌شود، در واقع به آنها هویت می‌بخشد. و در نتیجه ما نظم موجود در این مجموعه را درک می‌کنیم. اگر در این عناصر، نسبت‌ها دقیقاً بر اساس ابعاد و اندازه‌ها و تناسبات ریاضی باشد، ما یک مجموعه خردمند را احساس می‌کنیم. هندسه و تناسبات آن از اجزاء مختلف یک سیستم واضح بصری می‌سازند. آیا در الین سیستم صرفاً تناسبات هندسی و ایجاد فضایی با نظم مشخص مطرح است؟ در پایان آیا یک سیستم صرفاً موزون و معقولانه، دارای نوعی یکنواختی است ؟ هنگامی که نظامی منطقی بر فرم و فضا غالب باشد، فضا را تحت الشعاع خود قرار می‌دهد به هر حال معماری به نظم هندسی نیاز دارد، ولی ممکن است این نظم روح و جان معماری را بگیرد. بنابراین اگر معماری صرفاً بر اساس منطق باشد نمی‌تواند پاسخگوی روح و احساسات ما باشد. برای دستیابی به این هدف باید از قواعد منطقی و خشک آن کناره گرفت. بنابراین، بین قواعدد نوعی و تضاد ایجاد شود، نوعی پویایی که بین فرم با فرم یا فرم با فضا ایجاد شود تا نیازهای احساسی ما نیز ارضاء شود. زیرا این تضاد و پویایی، سرشار از هیجان و احساسات است. معماری می‌کوشد تا نظم را برای مردم متجلی سازد و این مردم هستند که در حرکت تدریجی نظم، فضا را درک می‌کنند و آن تأثیر می‌پذیرند. این نظم در ذهن افراد، پویایی و تحرک می‌یابد و مردمی که معماری را تجربه می‌کنند از این پویایی تأثیر می‌گیرند و بدین گونه معماری از طریق نظم انتزاعی خود در ما تأثیر می‌گذارد. در حقیقت پویایی موضوع معماری نیست، بلکه پیامد آن است. معماری قادر به پیش بینی واکنش‌های احساسی ما نیست. از این رو آن را نمی‌توان در روند طراحی پیش بینی کرد، همانگونه که نمی‌توان شیوه‌های مختلف یک بازی را پیش بینی کرد، زیرا آنچه ذهن ما را تحت تأثیر قرار می‌دهد، نامشخص است. معماری باید ادامه یابد تا با آزمون و خطای روش‌های مختلف به یک معماری خلاقانه دست یافت. اما برای این که یک طرح خیالی معماری را هر چند خلاقانه به واقعیت تبدیل کنیم باید دو زبان نوشتار و ترسیم را بدانیم. در زبان نوشتار اطلاعات فنی پروژه را بررسی می‌کنیم. و در زبان ترسیم با استفاده از تصاویر دو بعدی و سه بعدی به درک بهتر از آن می‌رسیم. به طور کلی یک پروژه ساختمانی شامل چهار مرحله است : 1) فاز 2) فاز یک 3) فاز دو 4) فاز سه 1) فاز صفر که همان مرحله مطالعاتی پروژه میباشد این مطالعات در زمینه‌های مختلف انجام می‌گیرد. در زمینه طراحی، مطالعات شناخت پروژه و نیز بدست آورده متر مربع فضاها و ... جزء فاز صفر محسوب می‌گردد. برای نمونه در زیر به بررسی روند طراحی یک واحد مسکونی اشاره شده است. گ 1) انجام مطالعات اولیه برنامه ریزی فیزیکی و تعیین اهداف پروژه 2) بررسی عوامل محیطی، جغرافیایی و فرهنگی 3) شناسایی کامل اجزای عملکرد ساختمان : الف ) ورودی ب ) هال خصوصی (نشیمن) ث ) پذیرایی ج ) ناهار خوری د ) آشپزخانه ن ) اتاق حمام و ) سرویس بهداشتی (حمام و دستشویی) ه ) اتاق خواب ی ) بالکن (تراس) 4) بررسی روابط متقابل اجزاء طرح 5) تجزیه و تحلیل زمین (آنالیز سایت) و مکان یابی ساختمان 6) تعیین نحوه استقرار ساختمان و سازماندهی فضاها در ارتفاع 7) بررسی مصالح و انتخاب سیستم ساختمانی مناسب در موارد بالا مختصراً به بررسی فاز صفر یک ساختمان مسکونی پرداختیم. بعد از این فاز یک شروع می‌شود که همان مرحله تهیه نقشه‌های ساختمانی توسط مهندس معمار میباشد در این مرحله نقشه‌ها فقط حالت شناخت فضاها را دارند و به هیچ وجه جزئیات را نشان نمی‌دهند البته خود طراح حتماً باید در ضمن طراحی جزئیات را مدنر داشته باشد تا در مراحل بعدی با اشکال مواجه نشود. مقیاس نقشه‌های ساختمانی در فاز یک تا 100/1 میباشد.فهرست مطالب
چکیده
مقدمه
فصل اول : معماری رهیافتی
- ا رزیابی بخش های مرتبط کارورزی
1- طراحی پلان پارکینگ پروژه شماره 1
2- طراحی پلان تیپ طبقات پروژه شماره 1
3- طراحی پلان معماری پروژه شماره 1
4- طراحی پلان همکف پروژه شماره 2
5- طراحی پلان تیپ طبقات پروژه شماره 2
6- طراحی نما پروژه شماره 2
7- طراحی برش پروژه شماره 2
8- طراحی پرسپکتیو پروژه شماره 2
9- یادگیری و محاسبه میزان ساخت و طبق ضابطه بر اساس دستور نقشه
10- ترسیم بسیاری از مبلمان داخلی و تجهیزات بهداشتی ساختمان
11- محاسبه میزان ساخت بر اساس دستور نقشه پروژه شماره 3
12- طراحی پلان همکف و پارکینگ پروژه شماره 3
13- طراحی پلان تیپ طبقات پروژه شماره 3
14- طراحی پلان مبلمان پروژه شماره 3
15- طراحی پلان برش پروژه شماره 3
16- طراحی نمای پروژه شماره 3
17- طراحی پرسپکتیو داخلی پروژه شماره 3
18- طراحی پرسپکتیو خارجی پروژه شماره 3
19- یادگیری تعداد زیادی از دستورهای برنامه outocad از قبیل : Erase LINE Surttab Layer Extrade PE.trim.Rectangle ...
فصل دوم : بررسی روند طراحی پروژه ها
- طراحی مبلمان و تجهیزات بهداشتی ساختمان
- محاسبه میزان ساخت
فصل سوم : آزمون آموخته ها و نتایج و پیشنهادات