دسته بندی | علوم انسانی |
بازدید ها | 1 |
فرمت فایل | docx |
حجم فایل | 76 کیلو بایت |
تعداد صفحات فایل | 47 |
مبانی نظری وپیشینه تحقیق مفهوم روش عقلانی- عاطفی- رفتاری (REBT)
توضیحات: فصل دوم (پیشینه ی پژوهش)
همرا با منبع نویسی درون متنی فارسی و انگلیسی کامل به شیوه APA جهت استفاده فصل دو
توضیحات نظری در مورد متغیر و همچنین پیشینه در مورد متغیر مربوطه و متغیرهای مشابه
رفرنس نویسی و پاورقی دقیق و مناسب برای فصل دو
منبع : دارد (به شیوه APA)
نوع فایل: WORD و قابل ویرایش با فرمت doc
قسمتی از مبانی نظری متغیر:
روش منطقی- عاطفی- رفتاری(REBT) یک تئوری شخصیت و شیوه ای برای مشاوره و روان درمانی است که به وسیله آلبرت الیس در سال 1955 تأسیس شد. بر طبق این نظریه، اگر نتیجه یا عارضه و رفتاری با بار عاطفی فوق العاده ای که دارد به دنبال حادثه محرکیبیاید، چنین به نظر می رسد که آن حادثه محرک، باعث این نتیجه شده است. در صورتی که واقعاً چنین نیست، عوارض و نتایج عاطفی عمدتاً به وسیله سیستم عقیدتی(B) ایجاد می شود. بنابراین وقتی عارضه نامطلوبی مانند اضطراب برای مراجع اتفاق می افتد به سرعت می توان ردپای آن را در عقاید غیر منطقی او جست و جو کرد. در این صورت اگر این عقاید غیر منطقی با برخوردی منطقی، مورد بحث و بررسی(D) قرار گیرد و تصحیح گردد عوارض آشفتگی و اضطراب از بین می رود و از اتفاق افتادن مجدد آن جلوگیری می شود(احمدی، 1387). این تئوری با رفتارگرایان سنتی، که معتقد بودند محرک(S) باعث پاسخ(R) می شود، مخالف است و اعتقاد دارد که نظر و برداشت آدمی بین محرک و پاسخ، قرار می گیرد و فرد از محرک تعبیر خاصی می کند. بنابراین پاسخ هایی که انسان می دهد، به شدت تحت تأثیر نظریات و عقاید او قرار دارد و رابطه به صورت(A-B-C) در می آید. در این رابطه (A) عوامل تحریک کننده یا رویدادی فعال کننده است که می تواند پیامدهای رفتاری و عاطفی داشته باشد در این مدل الیس این پیامد ها را معلول A نمی داند بلکه آن ها را معلول B می داند(شیرافکن،1385)، (B)همان عقاید و نظریات است که شامل نظام باورهای فرد در مورد آن رویداد می باشد. در صورتی که باور فرد در مورد A منفی باشد، آن گاه پیامدهای رفتاری و عاطفی وی نیز منفی خواهد بود و (C) همان عواقب و پاسخ هاست که شامل پیامدهای رفتاری و عاطفی است. نقش درمانگر در جلسه درمان مباحثه(D) در مورد عقاید و باورهای نامعقول(IB ) می باشد. درمانگر در این رویکرد از فنون شناختی، عاطفی و رفتاری نیز استفاده می کند(شیرافکن، 1385). تئوری REBT معتقد است که فرد، از نظر زیستی، استعداد فوق العاده ای برای انتخاب و استفاده درست از زندگی دارد و نیز مستعد برای ناهماهنگی و تلقین پذیری است.انسان دارای توان مشاهده کردن و تعقل است و در ذهن خود می تواند تجربیات خویش را سازمان دهد و بر محدودیت ها غلبه کند. هم چنین او میل باطنی و سهل الوصولی نسبت به انکار واقعیت و استفاده غلط از عقل خود دارد و به صورت غیر قابل قبولی افکار موهومی را در ذهن خود می آفریند و سلامت و شادابی خود را از بین می برد. فرد با قبول نکردن واقعیت، و جذب شدن در افکار غیر منطقی و موهوم به عوارض عاطفی نسبتاً شدیدی دچار می شود که آن را" اختلال عاطفی" می نامند(احمدی، 1386). به بیان ساده تر اگر محرک زیان آوری در زندگی فرد، در نقطه A (واقعه محرک) اتفاق بیفتد، معمولاً او این نقطه را به صورت عینی می بیند و به صورت منطقی(RB) نتیجه می گیرد که این واقعه تأسف آور است و آرزو می کند که این واقعه برطرف شود و در نقطه(C ) یعنی عواقب و نتایج به درستی احساس اندوه، تأسف و رنجیدگی می کند. این احساس اندوه و رنجیدگی به او کمک می کند تا برای رو به رویی با آن واقعه محرک و زیان آور کاری بکند. علی رغم آن واقعه ناخوشایند از توان منطقی خود استفاده می کند و افکاری از قبیل، " از آن واقعه ناراحتم و چه می توانم برای تغییر آن انجام دهم " و احساساتی مانند اندوه و رنجیدگی خواهد داشت. سپس به تنظیم مجدد موقعیت می پردازد و راه مقابله با آن را می یابد و خود را با آن سازگار می کند(احمدی، 1386).
دسته بندی | مبانی و پیشینه نظری |
بازدید ها | 9 |
فرمت فایل | doc |
حجم فایل | 41 کیلو بایت |
تعداد صفحات فایل | 18 |
مبانی نظری و مفهوم شناسی اهمال کاری
در 18 صفحه ورد قابل ویرایش با فرمت doc
توضیحات: فصل دوم کارشناسی ارشد (پیشینه و مبانی نظری فایل)
همراه با منبع نویسی درون متنی به شیوه APA جهت استفاده فصل دو
توضیحات نظری کامل در مورد متغیر
پیشینه داخلی و خارجی در مورد متغیر مربوطه و متغیرهای مشابه
رفرنس نویسی و پاورقی دقیق و مناسب
منبع : انگلیسی و فارسی دارد (به شیوه APA)
نوع فایل: WORD و قابل ویرایش با فرمت doc
قسمتی از متن مبانی نظری و پیشینه
مبانی نظری و مفهوم شناسی اهمال کاری
2-3-1 مفهوم اهمال کاری
در لغت واژه اهمال کاری این گونه معنا شده است: کاری را که بنا است به انجام برساند، به تاخیر اندازد. روان شناسان گفته اند: اهمال کاری این است که کاری را که تصمیم به اجرای آن داریم، به آینده موکول کنیم. معمولا چون شما نمی خواهید کاری را انجام دهید به اهمال کاری مبتلا می شوید؛ به عنوان مثال: هنگامی مردم یکی پس از دیگری از قحطی می میرند که دولتها اهمال کاری می کنند. در یک کلمه مى توان گفت: جوهره این آسیب روانى به تعویق انداختن، اهمال کاری ورزیدن، سبک گرفتن و سهل انگارى در کار است. بنابراین، اهمال هم در امور فردى و هم جمعى معنا و مفهوم پیدا مى کند. در نهایت مى توان گفت: در همه این معانى نوعى این دست آن دست کردن نهفته است. در زبان عربى واژه هاى کسل، ضجر مترادف اهمال کارى است. عناوینى چون تهاون و إبطاء چندان دور از این واژه نیستند. دو واژه مماطله و تسویف نیز مرادف اهمال کارى اجتماعى است که در قول و قرارهاى زمانى تحقق پیدا مى کند( آقاتهرانی،1382).
...
2-3-6 عوامل درونی و بیرونی اهمال کاری
الف- عوامل درونی و روانی
عوامل درونی و روانی اهمال ریشه در برخی نفس و جان انسانی داشته که به شکل صفات و روحیات اهمال کار ظهور و بروز دارند. در واقع منشأ آنها را در روان آدمی باید جست و جو کرد. عوامل درونی از این قرار است:
1-احساس کهتری: احساس کهتری(خودکم بینی) معلول عوامل متعدد شخصیتی و اجتماعی است که به برخی از آن ها اشاره می شود.
عوامل شخصیتی و فردی: یک: کسی که از خود توقع دارد کاری که انجام می رساند بهترین و کاملترین باشد، چون به نتیجه دلخواه خود نمی رسد، به او احساس کهتری دست می دهد و بنابراین، چاره را در تعویق کار می بیند.
دو: هر کس دوست دارد بر ضعف شخصیت خود غالب آید؛ لیکن تعداد اندکی از انسان ها بر آن فایق آیند و عده بسیاری هم به اضطراب و نا امیدی دچار می شوند.
سه: نقص های جسمانی چون: کوتاهی قد، نازیبایی، نقص در شنوایی و بینایی و...، و یا کمبودهای روانی نظیر کُندذهنی، عصبانیت و.... خود در شخص این حالت را به وجود می آورد که باید کهتری خود و برتری دیگران بر خود بپذیرد.
عوامل محیطی و اجتماعی: یک: به طور طبیعی همه طالب جلب محبت این و آن هستند، ولی چون می توانند به اوج آن دست یابند، از دیگران رنجیده خاطر می شوند و دم از نارضایتی از مردم می زنند و در نهایت با آن ها خصومت می ورزند. این خصومت و یا کلمات درشت به دیگران گویای احساس کهتری خویش نسبت به دیگران است.
مطالب:
2-3-1 مفهوم اهمال کاری
2-3-2 اهمال کاری سازمانی
2-3-3 تاریخچه علمی- پژوهشی اهمالکاری
2-3-4 ویژگی های اهمال کار
2-3-5 آثاراهمالکاری
2-3-6 عوامل درونی و بیرونی اهمال کاری
الف- عوامل درونی و روانی
ب- عوامل بیرونی و محیطی
2-3-7 راه های پیشگیری و درمان اهمال کاری
منابع:
دسته بندی | پاورپوینت |
بازدید ها | 0 |
فرمت فایل | ppt |
حجم فایل | 614 کیلو بایت |
تعداد صفحات فایل | 22 |
پاورپوینت معنا و مفهوم ازدواج و آداب رسوم سنت ازدواج
( این پاورپوینت در 22 اسلاید اماده ارائه و مطالعه میباشد)
ازدواج قراردادی است رسمی برای پذیرش یک تعهد متقابل به منظور تشکیل زندگی خانوادگی تا طرفین ازدواج در سایه آن، در خط سیر معین و شناخته شده ای از زندگی قرارگیرند. این قرارداد با رضایت و خواسته زن و شوهر و بر مبنای آزادی کامل دو طرف منعقد می گردد و در پرتو آن، روابطی بس نزدیک بین آن دو پدید می آید.
این قرارداد ارتباط و پیوند دو طرفه به وسیله الفاظ و عباراتی معین، انجام می گیرد که آن را «عقد» یا «پیمان ازدواج» می نامیم.
دسته بندی | مبانی و پیشینه نظری |
بازدید ها | 0 |
فرمت فایل | doc |
حجم فایل | 41 کیلو بایت |
تعداد صفحات فایل | 18 |
مبانی نظری و مفهوم شناسی اهمال کاری
در 18 صفحه ورد قابل ویرایش با فرمت doc
توضیحات: فصل دوم کارشناسی ارشد (پیشینه و مبانی نظری فایل)
همراه با منبع نویسی درون متنی به شیوه APA جهت استفاده فصل دو
توضیحات نظری کامل در مورد متغیر
پیشینه داخلی و خارجی در مورد متغیر مربوطه و متغیرهای مشابه
رفرنس نویسی و پاورقی دقیق و مناسب
منبع : انگلیسی و فارسی دارد (به شیوه APA)
نوع فایل: WORD و قابل ویرایش با فرمت doc
قسمتی از متن مبانی نظری و پیشینه
مبانی نظری و مفهوم شناسی اهمال کاری
2-3-1 مفهوم اهمال کاری
در لغت واژه اهمال کاری این گونه معنا شده است: کاری را که بنا است به انجام برساند، به تاخیر اندازد. روان شناسان گفته اند: اهمال کاری این است که کاری را که تصمیم به اجرای آن داریم، به آینده موکول کنیم. معمولا چون شما نمی خواهید کاری را انجام دهید به اهمال کاری مبتلا می شوید؛ به عنوان مثال: هنگامی مردم یکی پس از دیگری از قحطی می میرند که دولتها اهمال کاری می کنند. در یک کلمه مى توان گفت: جوهره این آسیب روانى به تعویق انداختن، اهمال کاری ورزیدن، سبک گرفتن و سهل انگارى در کار است. بنابراین، اهمال هم در امور فردى و هم جمعى معنا و مفهوم پیدا مى کند. در نهایت مى توان گفت: در همه این معانى نوعى این دست آن دست کردن نهفته است. در زبان عربى واژه هاى کسل، ضجر مترادف اهمال کارى است. عناوینى چون تهاون و إبطاء چندان دور از این واژه نیستند. دو واژه مماطله و تسویف نیز مرادف اهمال کارى اجتماعى است که در قول و قرارهاى زمانى تحقق پیدا مى کند( آقاتهرانی،1382).
...
2-3-6 عوامل درونی و بیرونی اهمال کاری
الف- عوامل درونی و روانی
عوامل درونی و روانی اهمال ریشه در برخی نفس و جان انسانی داشته که به شکل صفات و روحیات اهمال کار ظهور و بروز دارند. در واقع منشأ آنها را در روان آدمی باید جست و جو کرد. عوامل درونی از این قرار است:
1-احساس کهتری: احساس کهتری(خودکم بینی) معلول عوامل متعدد شخصیتی و اجتماعی است که به برخی از آن ها اشاره می شود.
عوامل شخصیتی و فردی: یک: کسی که از خود توقع دارد کاری که انجام می رساند بهترین و کاملترین باشد، چون به نتیجه دلخواه خود نمی رسد، به او احساس کهتری دست می دهد و بنابراین، چاره را در تعویق کار می بیند.
دو: هر کس دوست دارد بر ضعف شخصیت خود غالب آید؛ لیکن تعداد اندکی از انسان ها بر آن فایق آیند و عده بسیاری هم به اضطراب و نا امیدی دچار می شوند.
سه: نقص های جسمانی چون: کوتاهی قد، نازیبایی، نقص در شنوایی و بینایی و...، و یا کمبودهای روانی نظیر کُندذهنی، عصبانیت و.... خود در شخص این حالت را به وجود می آورد که باید کهتری خود و برتری دیگران بر خود بپذیرد.
عوامل محیطی و اجتماعی: یک: به طور طبیعی همه طالب جلب محبت این و آن هستند، ولی چون می توانند به اوج آن دست یابند، از دیگران رنجیده خاطر می شوند و دم از نارضایتی از مردم می زنند و در نهایت با آن ها خصومت می ورزند. این خصومت و یا کلمات درشت به دیگران گویای احساس کهتری خویش نسبت به دیگران است.
مطالب:
2-3-1 مفهوم اهمال کاری
2-3-2 اهمال کاری سازمانی
2-3-3 تاریخچه علمی- پژوهشی اهمالکاری
2-3-4 ویژگی های اهمال کار
2-3-5 آثاراهمالکاری
2-3-6 عوامل درونی و بیرونی اهمال کاری
الف- عوامل درونی و روانی
ب- عوامل بیرونی و محیطی
2-3-7 راه های پیشگیری و درمان اهمال کاری
منابع:
دسته بندی | معماری |
بازدید ها | 0 |
فرمت فایل | doc |
حجم فایل | 712 کیلو بایت |
تعداد صفحات فایل | 85 |
پایان نامه مفهوم و دستهبندی معماریها و جایگاه معماری نرمافزار در آن
عنوان |
شماره صفحه |
چکیده 3
فهرست مطالب.. 4
فهرست جدولها 10
فهرست شکلها 11
مقدمه. 14
فصل اول
مفهوم و دستهبندی معماریها و جایگاه معماری نرمافزار در آن. 20
1-1 مقدمه 20
1-2 تاریخچه معماری 20
1-3 مفهوم و تعریف معماری.. 21
1-4 چارچوبهای معماری.. 22
1-4-1 چارچوب معماری Zachman. 22
1-4-2 چارچوب معماری FEAF. 23
1-4-3 چارچوب معماری C4ISR.. 23
1-5 چارچوبها و متدولوژیها 23
1-6 دستهبندی معماریها 25
1-6-1 معماری سیستم، معماری نرمافزار 25
1-6-2 معماری سازمان 26
1-6-3 معماری کسب و کار 26
1-6-4 معماری اطلاعات.. 27
1-6-5 معماری سیستمهای کاربردی.. 27
1-6-6 معماری داده 28
1-6-7 معماری تکنولوژی.. 28
1-7 معماریهای دیگر 30
فصل دوم
مفهوم معماری نرمافزار و مقایسهای تحلیلی بر تعاریف آنها 32
2-1 مقدمه 32
2-2 مفهوم معماری نرمافزار 32
2-3 تعاریف معماری نرمافزار 33
2-4 دلایل وجود تعاریف مختلف برای معماری نرمافزار 35
2-4-1 وجود دیدگاهها و رویکردهای متفاوت.. 35
2-4-2 کیفی بودن شناسه "سطح بالا بودن" در مفهوم معماری.. 36
2-4-3 تفاوت در کلمات مورد استفاده در تعاریف... 36
2-5 ارائه جدول اجزاء تشکیل دهنده تعاریف.. 36
2-5-1 اجزاء معماری نرمافزار و منطق انتخاب اجزاء 37
2-5-2 ارتباطهای بین اجزاء معماری نرمافزار 38
2-5-3 مجموعه اجزاء معماری نرمافزار و ارتباط بین آنها 39
2-6 تعریف و مقایسه پارمترهای متناظر در چارچوب.. 40
2-6-1 رابطه، ارتباط، تعامل، اتصال.. 41
2-6-2 اجزاء نرمافزاری، موئلفه، زیرسیستم. 42
2-6-3 خصوصیت، واسط، رفتار 44
2-6-4 ساختار، سازماندهی، چارچوب.. 45
فصل سوم
مفهوم، تعریف و سنجش مشخصههای کیفی در معماری نرمافزار 47
3-1 مقدمه 47
3-2 مفهوم کیفیت نرمافزار و مشخصههای کیفی.. 47
3-3 تعریف کیفیت در نرمافزار و مشخصههای کیفی.. 49
3-4 Observable via Execution 50
3-5 Not Observable via Execution 50
3-6 معرفی برخی از صفات کیفی نرمافزار بر اساس دستهبندی [Bass 03] 52
3-7 صفات دسته اول: صفات کیفی سیستمی.. 53
3-7-1 Availability 54
3-7-2 Performance 54
3-7-3 Security 55
3-7-4 Functionality 55
3-7-5 Usability 56
3-7-6 Modifiability 56
3-7-7 Portability 57
3-7-8 Reusability 57
3-7-9 Integrability 58
3-7-10 Testability. . 58
3-8 صفات دسته دوم: صفات کیفی کسب و کار 59
3-8-1 Time to Market 59
3-8-2 Cost and benefit 59
3-8-3 Projected lifetime of the system 59
3-8-4 Targeted Market 59
3-8-5 Rollout schedule 59
3-8-6 Integration with legacy systems 60
3-9 صفات دسته سوم: صفات کیفی معماری.. 60
3-9-1 Conceptual Integration 60
3-9-2 Correctness and Completeness 60
3-9-3 Buildability 60
3-10 Trade-Off موجود بین صفات کیفی.. 60
فصل چهارم
سبکها و الگوهای معماری نرمافزار و نحوه ارزیابی و انتخاب آنها 64
4-1 مقدمه و تاریخچه 64
4-2 تعریف سبک معماری.. 65
4-2-1 تعاریف مختلف سبک معماری نرمافزار 65
4-3 معرفی برخی سبکهای متداول. 65
4-3-1 سبکهای متمرکز روی داده 66
4-3-2 سبکهای جریان داده 67
4-3-3 سبکهای ماشین مجازی.. 68
4-3-4 سبکهای فراخوانی و بازگشت... 69
4-3-5 سبکهای موئلفههای مستقل.. 71
4-3-6 سبکهای چند ریختی.. 72
4-4 الگوهای معماری نرمافزار 73
4-5 سازماندهی الگوها 73
4-5-1 الگوهای پیادهسازی.. 75
4-5-2 الگوهای طراحی 75
4-5-3 الگوهای معماری.. 75
4-6 الگوها و سبکها 77
4-7 ارزیابی و انتخاب یک سبک معماری نرمافزار 77
4-7-1 پارامترهای ارزیابی سبکها 77
4-7-2 جدول ارزیابی سبکها 77
4-7-3 تکمیل جدول ارزیابی سبکها 78
4-7-4 ارائه الگوریتم استفاده از جدول.. 78
4-7-5 مشکلات موجود. 80
فصل پنجم
طرح مشکل موجود، سوابق، راهکارها و کارهای انجام شده 82
5-1 مقدمه 82
5-2 طرح مشکل موجود در سبکهای معماری نرمافزار 82
5-3 دستهبندیهای سبکهای معماری.. 84
5-3-1 دستهبندیهای موضوعی.. 84
5-3-2 دستهبندی سبکهای معماری بر اساس [Clements 02-1] 86
5-3-3 دستهبندیهای سیستمی.. 89
فصل ششم
ارائه یک استاندارد برای سازماندهی سبکهای معماری نرمافزار 93
6-1 مقدمه 93
6-2 ورودی و خروجیهای یک استاندارد سازماندهی سبکها 93
6-3 بررسی جنبههای موجود برای ارائه یک استاندارد سازماندهی.. 94
6-3-1 دستهبندیهای سیستمی.. 94
6-3-2 دستهبندیهای موضوعی.. 94
6-3-3 روشهای ارزیابی سبکهای معماری نرمافزار 95
6-3-4 روشهایی استاندارد برای مستند کردن و جمعبندی سبکها 95
6-4 اجزاء استاندارد سازماندهی سبکها 97
6-4-1 دستهبندی پیشنهادی برای کلیه سبکهای معماری نرمافزار 97
6-4-2 کاتالوگ مستند سازی کلیه سبکهای معماری نرمافزار 98
6-5 معرفی فرایند ایجاد استاندارد سازماندهی سبکها 99
6-6 فاز اول: تهیه استانداردهای مورد نیاز 100
6-6-1 قدم اول: ارائه یک استاندارد برای دستهبندی انواع سیستمهای نرمافزاری.. 101
6-6-2 قدم دوم: ارائه یک استاندارد برای دستهبندی انواع سبکهای معماری نرمافزار 103
6-6-3 قدم سوم: ارائه یک استاندارد برای مستند کردن هر سبک معماری نرمافزار 105
6-6-4 قدم چهارم: ارائه یک استاندارد برای دستهبندی انواع مشخصههای کیفی.. 107
6-7 فاز دوم: تهیه دستهبندی استاندارد و قالب استانداردِ کاتالوگ سبکها 109
6-7-1 قدم اول: ارائه یک قالب دستهبندی استاندارد برای سبکهای معماری نرمافزار 110
6-7-2 قدم دوم: ارائه یک قالب استاندارد برای کاتالوگ کلیه سبکهای معماری نرم افزار 112
6-8 فاز سوم: جمعآوری و مستند کردن سبکهای موجود و ارائه روشهای ارزیابی.. 113
6-8-1 قدم اول: اضافه کردن سبکهای دستهبندیهای موضوعی به استاندارد. 113
6-8-2 قدم دوم: اضافه کردن سبکهای دستهبندیهای سیستمی به استاندارد. 113
6-8-3 قدم سوم: تهیه یا ارائه مدل ارزیابی برای سبکهای هر نوع سبک/نوع سیستم. 114
6-9 فاز چهارم: ارائه طرحهای کاربرد، توسعه و سازگاری استاندارد 114
6-9-1 قدم اول: ارائه طرح استانداردِ ارائه سبکهای جدید. 114
6-9-2 قدم دوم: ارائه طرحها و قوانین توسعه استانداردهای موجود. 114
6-10 جمعبندی کلی استاندارد ارائه شده 115
فصل هفتم
مدلسازی فرایندهای استاندارد ارائه شده، بر اساس UML. 118
7-1 مقدمه 118
7-2 فرایند مدلسازی فرایند. 118
7-3 مدل کردن منابع کسبوکار 119
7-4 مدل کردن اهداف کسبوکار 120
7-5 تعیین Actorهای کسبوکار 120
7-6 مدل جریانهای کاری موجود در استاندارد 121
7-7 جریانهای کاری فاز اول. 122
7-7-1 فاز اول - قدم اول.. 122
7-7-2 فاز اول- قدم دوم. 123
7-7-3 فاز اول - قدم سوم. 123
7-7-4 فاز اول - قدم چهارم. 124
7-8 جریانهای کاری فاز دوم 124
7-8-1 فاز دوم - قدم اول.. 125
7-8-2 فاز دوم - قدم دوم. 125
7-9 جریانهای کاری فاز سوم 126
7-9-1 فاز سوم - قدم اول.. 127
7-9-2 فاز سوم - قدم دوم. 127
7-9-3 فاز سوم - قدم سوم. 128
7-10 جریانهای کاری فاز چهارم 128
7-10-1 فاز چهارم - قدم اول.. 129
7-10-2 فاز چهارم - قدم دوم. 129
7-11 مدل خروجیهای کسبوکار 130
فصل هشتم
خلاصه، نتیجهگیری و کارهای آینده 132
8-1 مقدمه 132
8-2 خلاصه و نتیجهگیری.. 132
8-3 کارهای آینده 133
8-4 در نهایت 135
منابع و مراجع. 136
فهرست جدولها
شماره جدول |
شماره صفحه |
جدول 1‑1 : چارچوبهای مهم معماری.. 23
جدول 2‑1 : یک چارچوب برای تعاریف معماری نرمافزار 40
جدول 2‑2 : پارامترهای متناظر در چارچوب.. 41
جدول 4‑1: الگوهای معماری نرمافزار ارائه شده در [Buschmann 96] 76
جدول 4‑2: یک مثال برای سبکها و اعداد مربوط به هر یک از مشخصههای کیفی آنها 79
جدول 4‑3: مقادیر مشخصههای کیفی که کاربر درخواست نموده است. 80
جدول 4‑4: مجموع قدر مطلق تفاضلات محاسبه شده برای هر سبک... 80
جدول 4‑5: مجموع مربعات تفاضلات محاسبه شده برای سبکهایی که مقدار SAD یکسانی دارند. 80
جدول 5‑1 : دستهبندی سبکهای معماری نرمافزار در [Shaw 96] 85
جدول 5‑2 : دستهبندی [Fielding 00] 86
جدول 5‑3 : دستهبندی سبکهای معماری نرمافزار بر اساس [Clements 02-1] 89
جدول 5‑4 : دستهبندی [Buschmann 96] 89
جدول 5‑5: سبکهای ارائه شده برای سیستمهای پردازش توزیع شده از [Morisawa 02] 90
جدول 5‑6: سبکهای ارائه شده برای سیستمهای اطلاعاتی سازمان از [Kolp 01] 90
جدول 5‑7: سبکهای ارائه شده در [Hawthorne 05] 90
جدول 5‑8: سبکهای ارائه شده برای سیستمهای تجارت الکترونیک از [Widhani 02] 90
جدول 5‑9: سبکهای ارائه شده برای سیستمهای مدیریت منابع از [Kircher 04] 91
جدول 6‑1: انواع سیستمهایی که تاکنون برای آنها سبک معماری ارائه شده است. 102
جدول 6‑2: استانداردی برای مستند کردن هر سبک بر اساس استاندارد [Clements 02-1] 106
جدول 6‑3: عبارات اختصاری استفاده شده در جدول. 111
فهرست شکلها
شماره شکل |
شماره صفحه |
شکل 1‑1: مفهوم معماری تدبیرات و نقشههای قبل از ساخت سیستمها است. ]ایزایران 81[ 21
شکل 1‑2 : نحوه بیان متدولوژیها با چارچوبها ]ایزایران 81[ 24
شکل 1‑3 : معماری سازمان و زیرمعماریهای مربوطه از ]ایزایران 81[ 26
شکل 2‑1 : مفهوم معماری نرمافزار، طراحی سطح بالا میباشد. 33
شکل 2‑2 : جزء معماری به ناظر و منظر معمار بستگی دارد 37
شکل 2‑3 : R یک رابطه بیرونی و R1 یک رابطه درونی است.. 38
شکل 2‑4: فرامدل پیشنهادی برای رابطه، ارتباط، تعامل، اتصال. 42
شکل 2‑5: فرامدل ارائه شده برای جزء، موئلفه، سیستم و... 43
شکل 2‑6: فرامدل پیشنهادی برای رفتار، خصوصیت، واسط.. 45
شکل 3‑1: فرامدل ارتباط مشخصههای کیفی با دیگر مفاهیم موجود در معماری از [Albin 03] 50
شکل 3‑2: تاکتیکهای ارائه شده برای دستیابی به حد مطلوب Availability در [Bass 03] 51
شکل 3‑3: دستهبندی مشخصههای کیفی بر اساس [Bass 03] 53
شکل 3‑4: Trade-Offهای موجود بین مشخصههای کیفی و حد مطلوب آنها از [Barbacci 95] 61
شکل 3‑5: ارتباط صفات کیفی و وابستگی آنها به یکدیگر از [Fitzpatrik 96] 62
شکل 4‑1: دستهبندی Garlan و Shaw برای سبکهای معماری نرمافزار از [Shaw 96] 66
شکل 4‑2 : مدل سبکهای متمرکز روی داده از [Shaw 96] 67
شکل 4‑3 : سبک Pipe and Filter از [Shaw 96] 68
شکل 4‑4 : سبک برنامه اصلی و زیرروال از [Shaw 96] 69
شکل 4‑5: سبک معماری Object Oriented از [Shaw 96] 70
شکل 4‑6 : نمونهای از سبک لایهای مورد استفاده در استاندارد ارتباطی ISO از [Shaw 96] 71
شکل 4‑7: مجموعه از الگوها از [Trowbridge 03] 74
شکل 4‑8: نمایش روابط الگوها با خطوط از [Trowbridge 03] 74
شکل 4‑9: سطوح انتزاع الگوها از ]زاداحمد 85[ 75
شکل 4‑10: الگوی لایهای از ]زاداحمد 85[ 76
شکل 4‑11 : جدول ارزیابی سبکهای معماری نرمافزار بر اساس پارامترِ مشخصههای کیفی.. 78
شکل 5‑1: قسمتی از دستهبندی سبکهای معماری نرمافزار از [Shaw 97] 85
شکل 5‑2 : ارتباط بین نوعِ دید معماری، سبک معماری، دید معماری از [Clements 02-1] 88
شکل 6‑1: ورودی و خروجیهای سیستم استاندارد سازماندهی سبکهای معماری نرمافزار 94
شکل 6‑2: جنبههایی که باید برای ارائه استاندارد سازماندهی سبکها در نظر بگیریم. 96
شکل 6‑3 : منظرها و ناظرهای هر سبک معماری نرمافزار 98
شکل 6‑4: اجزاء اصلی استاندارد سازماندهی سبکهای معماری نرمافزار 98
شکل 6‑5: دستهبندی اولیه برای سبکهای معماری نرمافزار از [Ryoo 05] 104
شکل 6‑6: یک دستهبندی قابل توسعه برای سبکهای معماری نرمافزار از [Ryoo 05] 104
شکل 6‑7: مدل کیفیت McCall از [Astudillo 04] 108
شکل 6‑8: مدل کیفیت ISO/9126 از [Astudillo 04] 109
شکل 6‑9: نمونه یک دستهبندی انواع سیستمها برای سیستمهای اطلاعاتی.. 110
شکل 6‑10: قالب دستهبندی پیشنهادی برای سیستمهای اطلاعاتی.. 111
شکل 6‑11: فرایند ارائه قالب استاندارد برای تهیه کاتالوگ سبکها 112
شکل 6‑12: فرایند ایجاد یک استاندارد برای سازماندهی سبکهای معماری نرمافزار 117
شکل 7‑1: منابع کسبوکار مورد استفاده در کل فرایند. 119
شکل 7‑2: سلسله مراتب اهداف در فرایند معرفی شده 120
شکل 7‑3: Actorهای کسبوکار موجود در فرایند ارائه شده 121
شکل 7‑4: فازهای فرایند ارائه استاندارد 121
شکل 7‑5: مدل قدمهای ارائه شده برای فاز اول. 122
شکل 7‑6: مدل فرایند ارائه شده برای قدم اول از فاز اول. 123
شکل 7‑7: مدل فرایند ارائه شده برای قدم دوم از فاز اول. 123
شکل 7‑8: مدل فرایند ارائه شده برای قدم سوم از فاز اول. 124
شکل 7‑9: مدل فرایند ارائه شده برای قدم چهارم از فاز اول. 124
شکل 7‑10: مدل قدمهای ارائه شده برای فاز دوم 125
شکل 7‑11: مدل فرایند ارائه شده برای قدم اول از فاز دوم 125
شکل 7‑12: مدل فرایند ارائه شده برای قدم دوم از فاز دوم 126
شکل 7‑13: مدل قدمهای ارائه شده برای فاز سوم 126
شکل 7‑14: مدل فرایند ارائه شده برای قدم اول از فاز سوم 127
شکل 7‑15: مدل فرایند ارائه شده برای قدم دوم از فاز سوم 127
شکل 7‑16: مدل فرایند ارائه شده برای قدم سوم از فاز سوم 128
شکل 7‑17: مدل قدمهای ارائه شده برای فاز چهارم 128
شکل 7‑18: مدل فرایند ارائه شده برای قدم اول از فاز چهارم 129
شکل 7‑19: مدل فرایند ارائه شده برای قدم دوم از فاز چهارم 129
شکل 7‑20: خروجیهای هر یک از مراحل که منجر به استاندارد نهایی خواهد شد. 130
مقدمه
پیشرفت و بزرگتر شدن جامعه بشری در دنیای امروزی و پیچیدهتر شدن روابط بین آنها، باعث بوجود آمدن سیستمهای بزرگ و پیچیده در زندگی بشر امروزی شده است. با پیشرفت علم کامپیوتر و وارد شدن آن به بطن زندگی بشر، اکثر سیستمهایی که بشر امروزی با آنها سروکار دارد، به صورت کامپیوتری پیادهسازی میشوند.
زندگی بشر امروزی وابسته به سیستمهای نرمافزاری بزرگ و پیچیدۀ موجود میباشد. سیستمهای شرکتهای هواپیمایی و مسافربری، سیستمهای ارتباطی توزیع شده همانند تلویزیون، تلفنهای معمولی و همراه، سیستمهای بانکداری، سیستمهای مدیریت بورس، سیستمهای عمل جراحی راه دور، سیستمهای کنترل ماهوارههای مختلف، سیستمهای معاملات راه دور و هزاران سیستم نرمافزاری دیگر که وجود خلل و نقصی در آنها تاثیرات جبران ناپذیری بر زندگی بشر امروزی خواهد داشت.
در نتیجه یکی از نیازهای حیاتی بشر امروزی اینست که سیستمهای بزرگ و پیچیدۀ موجود، بدون خطا، سریع، با امنیت و کارایی بالا و... در اختیار آنها گیرد. در نتیجه توسعه دهندگان سیستمهای نرمافزاری بزرگ و پیچیده، باید سیستمهایی با چنین ویژگیهایی، در اختیار کاربران قرار دهند.
در نتیجه ارائه سیستمهایی در مقیاس بزرگ که دارای برخی ویژگیها همچون کارایی بالا، بدون خطا و بدون عیب، سریع و امن و...، نیاز توسعه دهندگان سیستمهای نرمافزاری مقیاس بزرگ میباشد. به این مشخصهها در حوزه مهندسی نرمافزار نیازهای غیرعملیاتی یا مشخصههای کیفی میگویند.
مهمترین مسئله در توسعه سیستمهای نرمافزاری مقیاس بزرگ، مبحث معماری آن میباشد. معماری، ساختارهای موئلفهها و زیرسیستمهای یک سیستم مقیاس بزرگ و ارتباط بین آنها میباشد. معماری نرمافزار، یکی از مهمترین حوزهها در مهندسی نرمافزار است و دلیل آن تاثیر حیاتی معماری در موفقیتِ توسعه سیستمهای نرمافزاری است.
توسعه یک سیستم نرمافزاری مقیاس بزرگ با ویژگیهای مذکور، نیازمند ارائه یک معماری مناسب و کامل برای سیستم نرمافزاری مورد نظر میباشد. در نتیجه ارائه یک معماری درست و مناسب برای چنین سیستمهایی از اهمیت حیاتی برخوردار است.
همیشه بشر از تجربیات قبلی خود یا دیگران در انجام کارهای فعلی بهره جسته است. در زمینه معماری نرمافزار نیز معماران نرمافزار برای ارائه یک معماری مناسب میتوانند از تجربیات معماران گذشته و ماهر برای ارائه معماری خود بهره گیرند. امروزه برای سیستمهای گوناگون، معماریهای مختلفی توسط معماران ماهر ارائه شده است. این معماریها به کررات در سیستمهای مختلف مورد آزمایش قرار گرفته و اعتبار و صحت آنها برای استفاده در برخی از سیستمهای نرمافزاری اثبات شده است. به این معماریها، الگوها یا سبکهای معماری نرمافزار میگویند.
در نتیجه یک معمار نرمافزار برای ارائه یک معماری مناسب، باید به سبکهای معماری موجود در حوزه سیستمی خود آشنایی داشته باشد تا بتواند از آنها برای ارائه یک معماری مناسب استفاده کند. یعنی معمار یک سیستم نرمافزاری برای ارائه یک معماری برای یک سیستم، باید تسلط کافی بر سبکهای معماری نرمافزار و مزایا، معایب و کاربردهای هر یک از آنها داشته باشد.
سبکهای معماری نرمافزار همه روزه توسط افراد و گروههای مختلف ارائه میشوند و هر گروه در حوزه سیستمی خود، به معرفی سبکهای جدید معماری نرمافزار میپردازد. درنتیجه یک معمار نرمافزار برای آشنایی به سبکهای معماری مربوط به حوزه خود، باید در یک دوره تناوب خاص مثلاً هر ماه، سبکهای معماری جدید را جمعآوری، بررسی و تحلیل کند. تا بتواند یک معماری درست و مناسب برای سیستم مورد نظر خود ارائه کند.
از طرفی با وجود سبکهای معماری مختلف برای حوزههای موجود، ممکن است برای یک کاربرد خاص، سبکهای زیادی پیشنهاد شده باشد. در برخی موارد ارائه کنندگان سبکها، روشهایی برای انتخاب یک سبک از بین سبکهای مختلف که توسط خودشان معرفی شده، ارائه میکنند. ولی همیشه این طور نیست و برای سبکهای مختلف که توسط افراد مختلف برای یک حوزه خاص ارائه شده است، روشی برای انتخاب یک سبک وجود ندارد.
از طرفی دیگر، همه روزه بر تعداد سبکهای معماری نرمافزار افزوده میشود و تعداد آنها در حال افزایش میباشد و هیچ کنترل مرکزی و واحد بر آنها وجود ندارد. این امر معماران سیستمهای نرمافزاری را در شناخت و استفاده از سبکها، دچار مشکل میکند یعنی با انباشته شدن سبکهای معماری نرمافزار، کار معماران نرمافزار در انتخاب یک سبک، خیلی مشکل خواهد شد.
در نتیجه میتوان مشکلات موجود برای ارائه یک معماری را به صورت زیر بیان کرد:
1- با افزایش روز افزون سبکهای معماری نرمافزار، هیچ کنترل مرکزی و واحد برای آنها وجود ندارد. و در ارائه سبکهای نوعی پراکندگی وجود دارد.
2- برای سبکهای ارائه شده توسط گروههای مختلف، روشهای انتخاب و ارزیابی واحدی وجود ندارد.
3- برای ارائه یک سبک معماری نرمافزار به صورت یک مستند، روشی استاندارد وجود ندارد که همه از این استاندارد تبعیت کنند.
4- عدم وجود یک سری از مشخصههای کیفی استاندارد که همه ارائه کنندگان سبکها از آنها برای ارائه روشهای ارزیابی خود استفاده کنند.
5- به دلیل وجود سبکهای مختلف، یک معمار نرمافزار در انتخاب یک سبک معماری دچار سردرگمی خواهد شد.
و دهها مشکل دیگر که با ارائه روز افزون سبکهای معماری نرمافزار به صورت پراکنده و عدم کنترل مرکزی، معماران نرمافزار در استفاده از سبکهای معماری، امروزه و در آینده به آن دچار خواهند شد.
برای حل مشکلات ذکر شده تلاشهایی توسط گروههای مختلف انجام گرفته است و مبحث دستهبندی سبکهای معماری بوجود آمده است. برای دستهبندی سبکهای معماری نرمافزار روشهای مختلفی تاکنون ارائه شده است. دستهای از روشها، سبکهای معماری نرمافزار را بر اساس نوع سبک آنها دستهبندی میکنند. یعنی ابتدا یک دستهبندی از انواع سبکهای معماری ارائه کرده سپس سبکهای معماری را در این دستهبندی قرار میدهند. ما به این نوع دستهبندیها، دستهبندی موضوعی میگوییم. برخی دیگر، سبکها را بر اساس نوع سیستم مورد کاربرد آن سبک، دستهبندی میکنند. یعنی ابتدا یک دستهبندی از انواع سیستمهای نرمافزاری ارائه کرده، سپس سبکهای معماری را در این دستهبندی قرار میدهند. ما به این نوع دستهبندی، دستهبندی سیستمی میگوییم. سوالی که در این زمینه مطرح میشوند، اینست که آیا این روشها، مشکلات موجود را حل میکنند. یعنی با دستهبندی سبکها میتوان مشکل معماران و پراکندگی سبکهای ارائه شده را حل کرد.
آنچه مسلم است، صرف دستهبندی سبکها به روش موضوعی یا سیستمی مشکلات موجود به طور کامل رفع نخواهد شد. به عنوان مثال مشکلاتی مانند ارائه پراکنده سبکها بدون کنترل مرکزی، عدم مستندسازی استاندارد سبکها، عدم وجود نحوه ارزیابی و انتخاب سبکهای همنوع و... هنوز پا برجا هستند.
در نتیجه عوامل دیگری نیز باید در این دستهبندیها لحاظ گردند. به عنوان مثال نحوه ارزیابی سبکها که باید برای تمامی سبکها، روشهای ارزیابی با سبکهای همنوع خود ارائه شود یا روشی استاندارد برای مستند کردن سبکها در این دستهبندیها وجود داشته باشد.
در نتیجه برای رفع مشکلات موجود، نیاز به یک استاندارد سازماندهی برای کلیه سبکها داریم که بر اساس این استاندارد بتوانیم کلیه سبکهای موجود و سبکهایی را که در آینده ارائه خواهد شد، سازماندهی کنیم. درنتیجه اگر توسعه چنین استانداردی را به عنوان یک سیستم در نظر بگیریم، میتوانیم از روشهای توسعه سیستمها همانند مدلهای موازی یا فازبندی شده مثل RUP[1]، برای توسعه و تکمیل این استاندارد استفاده کنیم.
برای توسعه چنین استانداری میتوان مراحل زیر را بر اساس متدولوژی RUP جنین تعریف کرد.
1- فاز اول – شناخت (Inception): در این فاز به بررسی و شناخت مسئله موجود پرداخته و کلیه مفاهیم مورد نیاز برای آن را مورد بررسی قرار میدهیم. به طوری که دید درستی از مسئله و آنچه میخواهد داشته باشیم. در حقیقت مسئله مورد نظر، تعریف و مورد بررسی قرار میگیرد و مفاهیم مورد استفاده در مسئله شناخته میشوند.
با توجه به مسئله مورد نظر که توسعه یک استاندارد برای سازماندهی سبکهای معماری نرمافزار میباشد، در این فاز باید کلیه مفاهیم مورد نیاز برای توسعه این استاندارد شناخته شود. مفاهیمی که باید شناخته شود، به صورت زیر خواهد بود.
1-1- بررسی مفهوم معماری و دستهبندیهای آن: در این مرحله به بررسی مفهوم معماری در حالت کلی پرداخته و بعد از آشنایی با مفهوم آن به بررسی انواع معماریهای موجود میپردازیم. در ادامه جایگاه معماری نرمافزار در این دستهبندی را مشخص مینماییم.
1-2- بررسی مفهوم و تعریف معماری نرمافزار: در این مرحله به بررسی مفهوم معماری نرمافزار میپردازیم و با اشاره به تعریف معماری نرمافزار، سعی میکنیم درکی واضح و بدون ابهام از معماری داشته باشیم.
1-3- بررسی مشخصههای کیفی در معماری نرمافزار: با توجه به اهمیت مشخصههای کیفی در معماری نرمافزار و اینکه هدف اصلی معماری، دستیابی به میزان مطلوبی از این مشخصهها است، در نتیجه باید مفهوم، تعریف و نحوه اندازهگیری هر یک از مشخصههای کیفی مورد بررسی قرار گیرد.
1-4- بررسی سبکها و الگوهای معماری نرمافزار: با توجه به مسئله مورد بررسی که توسعه یک استاندارد برای سازماندهی سبکهای معماری نرمافزار میباشد، باید مفهوم و تعریف سبک معماری مورد بررسی قرار گرفته و برای آشنایی بیشتر با آنها، برخی از سبکهای معماری نرمافزار را مطالعه و مورد بررسی قرار دهیم.
2- فاز دوم – تکوین (Elaboration): در این فاز باید نیازمندیهای سیستم مورد نظر به صورت کامل شناخته شده و مورد تحلیل قرار گیرند. برای تحلیل نیازمندیها ابتدا باید فرایندهای توسعه سیستم را پیدا یا معرفی کرده سپس آنها را به موردهای کاربرد شکسته و با معرفی سناریو برای هر یک از آنها، گروههای کاری تشکیل شده و موردهای کاربرد را مورد تحلیل قرار دهند.
برای سیستم مورد نظر یعنی ارائه یک استاندارد برای سازماندهی سبکهای معماری نرمافزار مراحل زیر را پیشنهاد میدهیم.
2-1- تحلیل نیازمندیهای مسئله: در این مرحله بر اساس شناختی که در فاز قبل از مفاهیم مرتبط با موضوع بدست آمده است، نیازمندیهای مورد نیاز مسئله مطرح میشود. در این مرحله روشهای قبلی نیز مورد بررسی قرار خواهد گرفت و بر اساس روشهای قبل، ایدهای برای توسعه این سیستم ارائه میشود.
2-2- بدست آوردن فرایندهای مورد نیاز سیستم: در این مرحله باید فرایندهای مورد نیاز برای توسعه سیستم و سازماندهی مذکور ارائه شود. هر یک از فرایندها تفضیل شده و برای هر یک پیشنهاداتی ارائه شود.
[1] Rational Unified Process (RUP)
دسته بندی | پژوهش |
بازدید ها | 0 |
فرمت فایل | doc |
حجم فایل | 162 کیلو بایت |
تعداد صفحات فایل | 16 |
بخشهایی از متن:
1- مشخصات عبارتند از:
هلال قرمز بالای مشت نشان دهنده فلسفه خون کانگ فو یعنی مبارزه تا آخرین قطره خون در راه آزادی انسانها می باشد.
2-مشت در میان دایره سیاه نشان دهنده قیام از دل تاریکیها و پلیدیهاو همه آنچه که انسان امروز از خود بیگانه کرده ودر بند کشیده است.
و مشت نشانه تجاوز نمی باشد ،بلکه حالت دفاعی دارد که از شکل آن نیز مشخص است .
3-هلال سفید زیر مشت نشان دهنده نژاد سفید ایرانی است.
4-کره جهان زیر مشت و نقشه ایران در وسط کره بعنوان پایگاه کانگ فو توآ در جهان مشخص شده است .
این آرم روی سینه طرف چپ قرار می گیرد که مشت حفاظت از قلب ماست که طپش آن صدای فکر مان است.
پس آرم کانگ فو نیز دفاعی بودن این هنر را نشان می دهد و بازگو کننده این نقطه است که :
پیکار ما فقط برای دفاع از انسانیت است .
...
کونگ فو توآ یک هنر رزمی ایرانیست که در خارج از ایران با مُعرفانِ خوب و بَدَش به پِرشین کونگ فو، یعنی کونگ فوی پارس، شناخته شده. وجه َتمایز این هنر از هنرهای رزمی دیگر، حرکات پُرتوانِ جسمانی، همراه با شُک های تکنیکی و رانشِ بازدَم است که چون اُجاقی وجود را شعله ور میکند و پس از فرو کش یا پایان تمرین، احساسی خوب و پاک به آدم میدهد که آدم از تلاشِ خود، خوشنود میشود. بِسان یک رقص قدرت میماند که بر پایه ی فرهنگ و آدابِ نژادِ آریایی از خاور تا باختر و از شمال تا جنوب ایران و فَراسوی مرزهای ایرانِ کنونی ریشه دارد. کونگ فو توآ شامل تکنیکها، ترکیبات، دورانها و پیچشهای بسیاریست که زیبا به نظر میرسند و یک چالش بزرگ برای کسانیست که در پی ورزشهای رزمی هستند یا پیِ خود شناسی میگردند. بهتر است که ما مشکلات و خواسته های شخصی خود را با آن مخلوط نکرده و درست آموزش دهیم کونگ فو توآ دَربَرگیرنده ی نرمشها، حرکات بدنساز، تکنیکهای دست و پا، حرکات موجی، تمرینات تنفسی، یوگا، نفوذ بر اجسام سخت، دفاع شخصی، مبارزات سُنتی آزاد و نیمه آزاد، تمرینهای انفرادی و تمرینهای گروهی است
در تمرین ها، سرعت، اِنعطاف، و هدف گیریِ توان در یک نقطه یا همان تمرکز گیری، شایانِ توجه است تا دست یازیده به مطلوب برسیم در کونگ فو توآ روی هَنایش یا اَثرِ تمرینات توجه ویژه ای میشود میوه و اَثری که انسان از این خود شناسی بر میگیرد از آنجایی که با انجام این تمرینها و کنکاش در فلسفه ی کونگ فو توآ انسان با چرخه ی هستی یین و یانگ در میاُفتد و چالش میجوید، پس در این دَرگیری، توانِ او نیز در هر گوشه ای از زوایای هستی بروز میکند....
...