Softwaring

همه ما گاهی در پروژه های کوتاه مدت با تعداد قابلیت های محدود درگیر بوده ایم. در این شرایط چه میزان به طراحی اهمیت داده اید؟ آیا کماکان روی یک طراحی خوب پافشاری کرده اید یا بر وسوسه آن غلبه کرده و به توسعه نرم افزار بدون طی مراحل طراحی تن داده اید؟ برای برخی پیاده سازی نرم افزار فاقد طراحی در حکم خیانت(!) است اما آیا همه نرم افزارها نیاز به طراحی دارند یا می توان گاهی از خیر طراحی گذشت؟

در نمودار زیر خطی فرضی مشاهده می کنید که به نظر Martin Fowler نقطه تصمیم گیری در مورد وجود یا عدم وجود طراحی در نرم افزار است. اگر میزان قابلیتها (و البته میزان زمان و منابع مصرفی) نرم افزار مورد نظر پایین تر از این خط باشد، ممکن است تصمیم گیری در مورد عدم وجود طراحی معقول باشد. اما اگر عملکرد و قابلیتهای نرم افزار تحت بررسی شما بالاتر از این خط باشد، "اوصیکم بالطراحی".

سوال اساسی اینجاست که مکان مناسب قرارگیری این خط کجاست؟

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

 اصل موضوع را در اینجا بخوانید.

Software factory–based application development addresses the problem of traditional application development where applications are developed and delivered without taking advantage of the knowledge gained and the assets produced from developing similar applications. Many approaches, such as training, documentation, and frameworks, are used to address this problem; however, using these approaches to consistently apply the valuable knowledge previously gained during development of multiple applications can be an inefficient and error-prone process.

Software factories address this problem by encoding proven practices for developing a specific style of application within a package of integrated guidance that is easy for project teams to adopt. Developing applications using a suitable software factory can provide many benefits when compared with conventional software development approaches:

• Consistency. Using a software factory to build multiple instances of a software product line (a set of applications that share features and architecture) makes it easier to achieve consistency. This simplifies governance and lowers maintenance and training costs.
• Quality. Using a software factory makes it easier for developers to learn and implement proven practices. Developers spend less time writing boilerplate code and spend more time creating features that are unique to each application. This reduces the likelihood of the application having design flaws or code defects. Applications developed using a software factory may also be verified before deployment; this ensures that factory-specific best practices were followed during development.
• Productivity. Using a software factory streamlines and automates the prescribed application development activities in the following ways:
  • It reuses software assets, particularly extensible architecture baselines, application frameworks, and application blocks.
  • It provides contextualized and automated guidance.
  • It generates code from models that represent abstractions of the application elements and mechanisms.

These approaches simplify, automate, or even eliminate many routine development tasks. By using a software factory, developers can concentrate on higher-value activities; this decreases the overall development time and cost.

Ref: Patterns & Practices

اگر در اینترنت در مورد تعریف یا مفهوم معماری نرم افزار جستجو کنید، هزاران صفحه و مقاله خواهید یافت. اما گاهی برای درک مفهومی، راه عکس آن بهتر ما را به پاسخ خواهد رساند، به این معنا که بدانیم مفهوم مزبور به چه معنایی نیست و شامل چه مواردی نمی شود. مطلب زیر عینا از مقدمه کتابی تحت عنوان Large Scale Software Architecture کپی شده است و موضوع آن این است: معماری نرم افزار چه نیست؟!

 What software architecture is not?

The software architecture does not include the hardware, network, or physical plant architecture. As such, the software architecture description is not intended to convey the complete description of the system, only the software within that system and any context needed to create the software. As an example, information such as hardware model number, hardware configuration information, routers, or LAN cards is not the focus in software architecture views. Other views, tables, or documents may be used to specify this type of information. However, this type of information should be included or referenced if it influences the software design.

In general, the software architecture description should not duplicate information found in other sources, such as requirements documents or marketing information. Duplication causes extra rework when these other documents change.

The software architecture description must be kept at the appropriate level of detail. The team that defines the architecture must keep each view at the right level of detail and avoid showing more than one level of detail in a particular view, unless the reasons for doing so are clear and agreed upon in advance.

Low-level implementation details should not be included in the software architecture description. For example, a context or subsystem view should not include details about the implementation mechanism for a particular interface.

In addition, descriptions of specific implementation mechanisms such as compiler optimizations, shared versus static libraries, COTS class or method names, or file format should not be included in the software architecture views.

Reference:

1.      Large-Scale Software Architecture, Jeff Garland/Richard Anthony, Wiley Pub.

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

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