Команда разработки проектов в системе программной инженерии. Введение Программная инженерия (лекции)
При покупке жёсткого диска могут возникнуть различные неясности, относительно каких-либо параметров. Довольно часто пользователи путаются в интерфейсах жёстких дисков, хотя основных интерфейсов, по сути, всего лишь два – IDE и SATA.
В данной статье мы постараемся основательно разобраться с этим немаловажным параметром, а также подробно рассмотрим каждый из наиболее популярных интерфейсов. Также, не оставим без внимания морально и физически устаревший, на текущий 2014 год, интерфейс IDE, дабы похоронить его окончательно.
Итак, для начала нужно разобраться с понятием интерфейса, именно в контексте жестких дисков. Интерфейс – это средство взаимодействия, в случае HDD, состоящее из сигнальных линий, контроллера интерфейса и специального протокола (набора правил). Как известно один конец кабеля интерфейса (будь-то IDE или SATA), мы вставляем в разъем на HDD, а другой конец – в разъём на материнской плате.
Теперь давайте пройдёмся по каждому из наиболее популярных интерфейсов, но начнём с более старого, который уже достаточно давно вышел из массового потребления, но всё ещё присутствует в ряде устаревших систем.
Интерфейс IDE (ATA)
IDE - Integrated Drive Electronics (электроника, которая встроена в привод). Его ещё называют PATA.
Как уже упоминалось выше, данный интерфейс очень устарел. Разработан он был ещё в далёком 1986 году. Много говорить относительно данного интерфейса и его спецификаций мы не будем. Констатируем тот факт, что обладает он довольно низкой скоростью передачи данных по сравнению с SATA . Применяется IDE лишь в очень старых системах, материнские платы которых, не поддерживают интерфейс SATA, либо в том случае, когда в наличии имеется IDE-диск. На рис.1 изображен шлейф IDE, а соответствующий ему разъём на материнской плате на (рис. 2).
Рис.1
Рис.2
При покупке нового жёсткого диска, нужно ознакомиться с интерфейсами, которые поддерживает Ваша материнская плата (выбор материнской платы ). Новейшие материнские платы, зачастую выпускают без разъёмов IDE, но ещё можно найти достаточно много моделей, которые поддерживают как IDE, так и SATA-интерфейсы. Опять же, при наличии SATA-интерфейса, лучше приобрести соответствующий диск с этим интерфейсом, чем возвращаться в прошлое и покупать IDE-диск (в случае с материнскими платами, которые поддерживают оба стандарта).
Интерфейсы SATA, SATA 2(II), SATA 3 (III)
В 2002 году появились первые жёсткие диски, с прогрессивным, на то время, интерфейсом SATA . Максимальная скорость передачи данных которого, составляла 150 Мбайт/c.
Если говорить о преимуществах, то первое что бросается в глаза – это замена 80-жильного шлейфа (рис.1), на семижильный кабель SATA (рис.3), который намного устойчивее к помехам, что позволило увеличить стандартную длину кабеля с 46 см до 1м. Также, были разработаны соответствующие разъёмы SATA (рис.4), которые в несколько раз компактнее, нежели разъёмы предшествующего стандарта IDE. Это позволило разместить на материнской плате больше разъёмов, теперь на новых материнских платах можно встретить более 6 разъёмов SATA, против традиционных 2-3 IDE, в старых материнских платах ориентированных на данный стандарт.
Рис.3
Рис.4
Далее, появился стандарт SATA ІІ, скорость передачи данных докатилась до 300 Мбайт/c. Данный стандарт заимел множество преимуществ, среди них: технология Native Command Queuing (именно она позволила достичь скорости 300Мбайт/с), горячее подключение дисков, выполнение нескольких команд одной транзакцией и другие.
Ну, а в 2009 году на свет был представлен интерфейс SATA 3 . Данным стандартом предусмотрена передача данных со скоростью 600 Мбайт/c (для жёстких дисков «ой» как избыточно).
В актив улучшений интерфейса можно дописать более эффективное управление питанием и, конечно же, повышение скорости.
Следует отметить, что SATA, SATA II и SATA III, полностью совместимы , что очень практично, в силу множества апгрейдов различных компонентов системы. Также, хотелось бы обратить внимание на тот факт, что интерфейс SATA используют SSD –диски и DVD/СD-приводы. Именно для быстрых SSD-дисков, будут очень к стати, высокие скорости SATA-интерфейса.
В виде небольшого итога данной статьи, ещё раз скажу, что при выборе жёсткого диска (конкретно интерфейса), необходимо обратить внимание на то, какой из стандартов поддерживает Ваша материнская плата. В свете современных тенденций – это, скорее всего, будет какой-либо из стандартов SATA. А для старых материнских плат и жёстких дисков всегда остается стандарт IDE.
Теперь, сомнения по поводу того, какой же интерфейс выбрать: IDE или SATA, должны исчезнуть. Удачи!
P.S. Мы рассмотрели наиболее популярные интерфейсы, более специфических существует большое множество. К примеру, съёмные жёсткие диски используют стандарт eSATA и т.д.
Доброго времени суток! В прошлой записи мы с вами в подробностях рассмотрели устройство харда, но я специально ничего не сказал про интерфейсы — то есть способы взаимодействия харда и остальных устройств компа, или если еще конкретней, способы взаимодействия (соединения) харда и материнской платы писишника.
А почему не сказал? А потому что эта тема — достойна объема никак не меньшего целого поста. Так что сейчас разберем подробно наиболее популярные на сегодняшний день интерфейсы . Сразу оговорюсь, что запись или пост (кому как удобнее) в данный раз будет иметь внушительные размеры, но куда деваться, без этого к сожалению никак, потому как если написать кратко, получится не совсем понятно.
Быстрая навигация
Понятие интерфейса жесткого диска ПК
Для начала давайте дадим определение понятию «интерфейс». Говоря простым языком (а именно им я и буду по-возможности выражаться, поскольку блог то на обычных людей рассчитан, таких как мы с вами), интерфейс — способ взаимодействия устройств друг с другом и не только устройств. К примеру, многие из вас должно быть слышали про так называемый «дружественный» интерфейс какой-либо программы. Что это значит? Это значит, что взаимодействие человека и программы более легкое, не требующее со стороны пользователя большИх усилий, по сравнению с интерфейсом «не дружественным». В нашем же случае, интерфейс — просто способ взаимодействия конкретно харда и материнской платы писишника. Он представляет собой набор специальных линий и специального протокола (набора правил передачи данных). То есть чисто физически — шлейф (кабель, провод), с 2-х сторон которого располагаются входы, а на жестком диске и материнке есть специальные порты (места, куда присоединяется кабель). Таким образом, понятие интерфейс — включает в себя соединительный кабель и порты, находящиеся на соединяемых им устройствах.
Виды взаимодействия винтов и материнской платы компа (виды интерфейсов)
Что ж, первым на очереди у нас будет самый «древний» (80-е года) из всех, в современных HDD его уже не встретить, это интерфейс IDE (он же ATA, PATA).
IDE
IDE — в переводе с английского «Integrated Drive Electronics», что буквально означает — «встроенный контроллер». Это уже потом IDE стали называть интерфейсом для передачи данных, ввиду того, что контроллер (находящийся в устройстве, в основном в жестких дисках и оптических приводах) и надо было чем-то соединять. Его (IDE) еще называют ATA (Advanced Technology Attachment), получается что то вроде «Усовершенствованная технология подсоединения». Дело в том, что ATA — параллельный интерфейс передачи данных, за что вскоре (буквально сразу после выхода SATA, о котором речь пойдет чуть ниже) он был переименован в PATA (Parallel ATA).
Что тут сказать, IDE хоть и был очень медленный (пропускная способность канала передачи данных составляла от 100 до 133 мегабайта в секунду в разных версиях IDE — и то чисто теоретически, на практике гораздо меньше), однако позволял присоединять сразу сразу два устройства к материнской плате, используя при этом один шлейф.
Причем в случае подключения сразу 2-х устройств, пропускная способность линии делилась пополам. Но, это далеко не единственный недостаток IDE. Сам провод, как видно из рисунка, достаточно широкий и при подключении займет львиную долю свободного пространства в системном блоке, что негативно скажется на охлаждении всей в целом. В общем IDE уже устарел морально и физически, по данной причине разъем IDE уже не встретить на многих современных материнских платах, хотя до недавнего времени их еще ставили (в количестве 1 шт.) на бюджетные платы и на некоторые платы среднего ценового сегмента.
SATA
Следующим, не менее популярным, чем IDE в свое время, интерфейсом является SATA (Serial ATA), характерной особенностью которого является последовательная передача данных. Стоит отметить, что на момент написания поста — является самым массовым для применения в компьютерах.
Существуют три основных варианта (ревизии) SATA, отличающиеся друг от друга пропускной способностью: rev. 1 (SATA I) — 150 Мб/с, rev. 2 (SATA II) — 300 Мб/с, rev. три (SATA III) — 600 Мб/с. Но это только в теории. На практике же, скорость записи/чтения винтов в основном не превышает 100-150 Мб/с, а оставшаяся скорость пока не востребована и влияет разве что на скорость взаимодействия контроллера и кэш-памяти HDD (повышает скорость доступа к диску).
Из нововведений отмечу — обратную совместимость всех версий SATA (диск с разъемом SATA rev. 2 можно подключить к мат. плате с разъемом SATA rev. три и т.п.), улучшенный внешний вид и удобство подключения/отключения кабеля, увеличенная по сравнению с IDE длина кабеля (1 метр максимально, против 46 см на IDE интерфейсе), поддержка функции NCQ начиная уже с первой ревизии. Спешу обрадовать обладателей старых устройств, не поддерживающих SATA — существуют переходники с PATA на SATA, это реальный выход из ситуации, позволяющий избежать траты денег на покупку новой материнской платы или нового жесткого диска.
Так же, в отличие от PATA, интерфейсом SATA предусмотрена «горячая замена» жестяков, это значит, что при включенном питании системника компа, можно присоединять/отсоединять жесткие диски. Только для ее реализации надо будет немного покопаться в настройках БИОС и включить режим AHCI.
eSATA (External SATA)
Следующий по списку — eSATA (External SATA) — был создан в 2004 году, слово «external» говорит о том, что он используется для подключения внешних жестких дисков. Поддерживает «горячую замену» дисков. Длина интерфейсного кабеля увеличена по сравнению с SATA — максимальная длина составляет в данный момент аж два метра. eSATA физически не совместим с SATA, но обладает той же пропускной способностью.
Но eSATA — далеко не единственный способ подключить внешние устройства к компу. Например FireWire — последовательный высокоскоростной интерфейс для подключения внешних устройств, в том числе HDD.
Поддерживает «горячу замену» винтов. По пропускной способности сравним с USB 2.0, а с появлением USB 3.0 — даже проигрывает в скорости. Однако у него все же есть преимущество — FireWire может обеспечить изохронную передачу данных, что способствует его применению в цифровом видео, так как он даёт возможность передавать данные в режиме реального времени. Несомненно, FireWire популярен, но не настолько, как к примеру USB или eSATA. Для подключения винтов он используется довольно редко, в большинстве случаев при помощи FireWire подключают различные мультимедийные устройства.
USB (Universal Serial Bus)
USB (Universal Serial Bus), пожалуй самый распространенный интерфейс, используемый для подключения внешних жестяков, флешек и твердотельных накопителей (SSD). Как и в предыдущем случае — есть поддержка «горячей замены», довольно большая максимальная длина соединительного кабеля — до 5 метров в случае использования USB 2.0, и до три метров — если используется USB 3.0. Наверное можно сделать и бОльшую длину кабеля, но в этом случае стабильная работа устройств будет под вопросом.
Скорость передачи данных USB 2.0 составляет порядка 40 Мб/с, что в общем-то является низким показателем. Да, конечно, для обыкновенной повседневной работы с файлами пропускной способности канала в 40 Мб/с хватит за глаза, но как только речь пойдет о работе с крупными файлами, поневоле начнешь смотреть в сторону чего-то более скоростного. Но оказывается выход есть, и имя ему — USB 3.0, пропускная способность которого, по сравнению с предшественником, возросла в 10 раз и составляет порядка 380 Мб/с, то есть практически как у SATA II, даже чуть больше.
Есть две разновидности контактов кабеля USB, это тип «A» и тип «B», расположенные на противоположных концах кабеля. Тип «A» — контроллер (материнская плата), тип «B» — подключаемое устройство.
USB 3.0 (тип «A») совместим с USB 2.0 (тип «A»). Типы «B» не совместимы между собой, как видно из рисунка.
Thunderbolt (Light Peak)
Thunderbolt (Light Peak). В 2010 году компанией Intel был продемонстрирован первый комп с данным интерфейсом, а чуть позднее в поддержку Thunderbolt к Intel присоединилась не менее известная компания Apple. Thunderbolt достаточно крут (ну а как иначе то, Apple знает во что стоит вкладывать деньги), стоит ли говорить о поддержке им таких фич, как: пресловутая «горячая замена», сразуе соединение сразу с несколькими устройствами, действительно «огромная» скорость передачи данных (в 20 раз быстрее USB 2.0).
Максимальная длина кабеля составляет только три метра (видимо больше и не надо). Тем не менее, несмотря на все перечисленные преимущества, Thunderbolt пока что не является «массовым» и применяется преимущественно в дорогих устройствах.
Идем дальше. На очереди у нас пара из очень похожих друг на друга интерфейсов — SAS и SCSI. Похожесть их заключается в том, что они оба применяются преимущественно в серверах, где требуется высокая производительность и как можно меньшее время доступа к жесткому диску. Но, существует и обратная сторона медали — все преимущества данных интерфейсов компенсируются ценой устройств, поддерживающих их. Жесткие диски, поддерживающие SCSI или SAS стоят на порядок дороже.
SCSI (Small Computer System Interface)
SCSI (Small Computer System Interface) — параллельный интерфейс для подключения различных внешних устройств (не только жестких дисков).
Был разработан и стандартизирован даже несколько раньше, чем первая версия SATA. В свежих версия SCSI есть поддержка «горячей замены».
SAS (Serial Attached SCSI)
SAS (Serial Attached SCSI) пришедший на смену SCSI, должен был решить ряд недостатков последнего. И надо сказать — ему это удалось. Дело в том, что из-за своей «параллельности» SCSI использовал общую шину, так что с контроллером сразу могло работать только лишь одно из устройств, SAS — лишен этого недостатка.
Кроме этого, он обратно совместим с SATA, что несомненно является крупным плюсом. К сожалению цена винтов с интерфейсом SAS близка к стоимости SCSI-винчестеров, но от этого никак не избавиться, за скорость приходится платить.
NAS (Network Attached Storage)
Если вы еще не утомились, предлагаю рассмотреть еще один прикольный способ подключения HDD — NAS (Network Attached Storage). В настоящее время сетевые системы хранения информации (NAS) имеют большую популярность. По сути, это отдельный комп, этакий мини-сервер, отвечающий за хранение данных. Он подключается к другому ПК через сетевой кабель и управляется с другого компа через обычный браузер. Это все надо в тех случаях, когда требуется большое дисковое пространство, которым пользуются сразу несколько людей (в семье, на работе). Данные от сетевого хранилища передаются к писишникам юзеров либо по обычному кабелю (Ethernet), либо при помощи Wi-Fi. На мой взгляд, очень удобная штука.
Надеюсь вам понравился материал, предлагаю добавить в закладки бложик, чтобы ничего не пропустить и встретимся с вами уже в следующих постах сайта.
В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ.
С тех пор программная инженерия прошла достаточно бурное развитие. Этапы развития программной инженерии можно выделять по-разному. Каждый этап связан с появлением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы. На слайде представлены ряд фундаментальных проблем разработки программ и найденных фундаментальных методов их решения. Эти методы и по сей день составляют основу подходов к проектированию программных продуктов.
Повторное использование кода (модульное программирование)
Проблема . На первых этапах становления программной инженерии (даже когда она так еще не называлась) было отмечено, что высокая стоимость программ связана с разработкой одинаковых (или похожих) фрагментов кода в различных программах. Вызвано это было тем, что в различных программах как части этих программ решались одинаковые (или похожие) задачи: решение нелинейных уравнений, расчет заработной платы, … Использование при создании новых программ ранее написанных фрагментов сулило существенное снижение сроков и стоимости разработки.
Модульное программирование . Главный принцип модульного программирования состоял в выделении таких фрагментов и оформлении их в виде модулей. Каждый модуль снабжался описанием, в котором устанавливались правила его использования – интерфейс модуля. Интерфейс задавал связи модуля с основной программой – связи по данным и связи по управлению. При этом возможность повторного использования модулей определялась количеством и сложностью этих связей, или насколько эти связи удалось согласовывать с организацией данных и управления основной программы. Наиболее простыми в этом отношении оказались модули решения математических задач: решения уравнений, систем уравнений, задач оптимизации. К настоящему времени накоплены и успешно используются большие библиотеки таких модулей.
Для многих других типов модулей возможность их повторного использования оказалась проблематичной в виду сложности их связей с основной программой. Например, модуль расчета зарплаты, написанный для одной фирмы, может не подойти для другой, т.к. зарплата в этих фирмах рассчитывается не во всем одинаково. Повторное использование модулей со сложными интерфейсами является достаточно актуальной и по сей день. Для ее решения разрабатываются специальные формы (структуры) представления модулей и организации их интерфейсов.
Рост сложности программ (структурное программирование)
Проблема . Следующий этап возрастания стоимости ПО был связан с переходом от разработки относительно простых программ к разработке сложных программных комплексов. К числу таких сложных программ относятся: системы управления космическими объектами, управления оборонным комплексом, автоматизации крупного финансового учреждения и т.д. Сложность таких комплексов оценивалась следующими показателями:
Большой объем кода (миллионы строк)
Большое количество связей между элементами кода
Большое количество разработчиков (сотни человек)
Большое количество пользователей (сотни и тысячи)
Длительное время использования
Для таких сложных программ оказалось, что основная часть их стоимости приходится не на создание программ, а на их внедрение и эксплуатацию. По аналогии с промышленной технологией стали говорить о жизненном цикле программного продукта, как о последовательности определенных этапов: этапа проектирования, разработки, тестирования, внедрения и сопровождения.
Структурное программирование . Этап сопровождения программного комплекса включал действия по исправлению ошибок в работе программы и внесению изменений в соответствии с изменившимися требованиями пользователей. Основная причина высокой стоимости (а порой и невозможности выполнения) этапа сопровождения состояла в том, что программы были плохо спроектированы – документация была не понятна и не соответствовала программному коду, а сам программный код был очень сложен и запутан. Нужна технология, которая обеспечит «правильное» проектирование и кодирование. Основные принципы технологии структурного проектирования и кодирования:
Нисходящее функциональное проектирование, при котором в системе выделяются основные функциональные подсистемы, которые потом разбиваются на подсистемы и т.д. (принцип «разделяй и властвую»)
Применение специальных языков проектирования и средств автоматизации использования этих языков
Дисциплина проектирования и разработки: планирование и документирование проекта, поддержка соответствие кода проектной документации
Структурное кодирование без goto
Введение в программную инженерию
Программная инженерия: назначение, основные принципы и понятия
1.1Предпосылки и история
В конце 60-х – начале 70-х годов прошлого века произошло событие, которое вошло в историю как первый кризис программирования. Событие состояло в том, что стоимость программного обеспечения стала приближаться к стоимости аппаратуры («железа»), а динамика роста этих стоимостей позволяла прогнозировать, что к середине 90-годов все человечество будет заниматься разработкой программ для компьютеров. Тогда и заговорили о программной инженерии (или технологии программирования, как это называлось в России) как о некоторой дисциплине, целью которой является сокращение стоимости программ.
С тех пор программная инженерия прошла достаточно бурное развитие. Этапы развития программной инженерии можно выделять по-разному. Каждый этап связан с появлением (или осознанием) очередной проблемы и нахождением путей и способов решения этой проблемы. На слайде представлены ряд фундаментальных проблем разработки программ и найденных фундаментальных методов их решения. Эти методы и по сей день составляют основу подходов к проектированию программных продуктов.
Повторное использование кода (модульное программирование)
Проблема . На первых этапах становления программной инженерии (даже когда она так еще не называлась) было отмечено, что высокая стоимость программ связана с разработкой одинаковых (или похожих) фрагментов кода в различных программах. Вызвано это было тем, что в различных программах как части этих программ решались одинаковые (или похожие) задачи: решение нелинейных уравнений, расчет заработной платы, … Использование при создании новых программ ранее написанных фрагментов сулило существенное снижение сроков и стоимости разработки.
Модульное программирование . Главный принцип модульного программирования состоял в выделении таких фрагментов и оформлении их в виде модулей. Каждый модуль снабжался описанием, в котором устанавливались правила его использования – интерфейс модуля. Интерфейс задавал связи модуля с основной программой – связи по данным и связи по управлению. При этом возможность повторного использования модулей определялась количеством и сложностью этих связей, или насколько эти связи удалось согласовывать с организацией данных и управления основной программы. Наиболее простыми в этом отношении оказались модули решения математических задач: решения уравнений, систем уравнений, задач оптимизации. К настоящему времени накоплены и успешно используются большие библиотеки таких модулей.
Для многих других типов модулей возможность их повторного использования оказалась проблематичной в виду сложности их связей с основной программой. Например, модуль расчета зарплаты, написанный для одной фирмы, может не подойти для другой, т.к. зарплата в этих фирмах рассчитывается не во всем одинаково. Повторное использование модулей со сложными интерфейсами является достаточно актуальной и по сей день. Для ее решения разрабатываются специальные формы (структуры) представления модулей и организации их интерфейсов.
Рост сложности программ (структурное программирование)
Проблема . Следующий этап возрастания стоимости ПО был связан с переходом от разработки относительно простых программ к разработке сложных программных комплексов. К числу таких сложных программ относятся: системы управления космическими объектами, управления оборонным комплексом, автоматизации крупного финансового учреждения и т.д. Сложность таких комплексов оценивалась следующими показателями:
Большой объем кода (миллионы строк)
Большое количество связей между элементами кода
Большое количество разработчиков (сотни человек)
Большое количество пользователей (сотни и тысячи)
Длительное время использования
Для таких сложных программ оказалось, что основная часть их стоимости приходится не на создание программ, а на их внедрение и эксплуатацию. По аналогии с промышленной технологией стали говорить о жизненном цикле программного продукта, как о последовательности определенных этапов: этапа проектирования, разработки, тестирования, внедрения и сопровождения.
Структурное программирование . Этап сопровождения программного комплекса включал действия по исправлению ошибок в работе программы и внесению изменений в соответствии с изменившимися требованиями пользователей. Основная причина высокой стоимости (а порой и невозможности выполнения) этапа сопровождения состояла в том, что программы были плохо спроектированы – документация была не понятна и не соответствовала программному коду, а сам программный код был очень сложен и запутан. Нужна технология, которая обеспечит «правильное» проектирование и кодирование. Основные принципы технологии структурного проектирования и кодирования:
Нисходящее функциональное проектирование, при котором в системе выделяются основные функциональные подсистемы, которые потом разбиваются на подсистемы и т.д. (принцип «разделяй и властвую»)
Применение специальных языков проектирования и средств автоматизации использования этих языков
Дисциплина проектирования и разработки: планирование и документирование проекта, поддержка соответствие кода проектной документации
Структурное кодирование без goto
Модификация программ (ООП)
Проблема . Следующая проблема роста стоимости программ была вызвана тем, что изменение требований к программе стали возникать не только на стадии сопровождения, но и на стадии проектирования – проблема заказчика, который не знает, что он хочет. Создание программного продукта превратилось в его перманентное перепроектирование. Возник вопрос как проектировать и писать программы, чтобы обеспечить возможность внесений изменений в программу, не меняя ранее написанного кода.
Объектно-ориентированное программирование . Решением этой проблемы стало использование подхода или метода, который стали называть объектно-ориентированным проектированием и программированием. Суть подхода состоит в том, что вводится понятие класса как развитие понятия модуля с определенными свойствами и поведением, характеризующими обязанностями класса. Каждый класс может порождать объекты – экземпляры данного класса. При этом работают основные принципы (парадигмы) ООП:
Инкапсуляция – объединение в классе данных (свойств) и методов (процедур обработки).
Наследование – возможность вывода нового класса из старого с частичным изменением свойств и методов
Полиморфизм – определение свойств и методов объекта по контексту
Проиллюстрировать возможности принципов ООП можно на следующем примере. В организации, состоящей из трех отделов надо начислять заработную плату. В программе каждый отдел представлен своим модулем – объектом, а начисление зарплаты – объектом «Зарплата». При необходимости расчета зарплаты объекту «Отдел» передается экземпляр объекта «Зарплата». Объект «Отдел» передает объекту «Зарплата» необходимые данные и затем с помощью методов объекта «Зарплата» выполняет необходимые расчеты.
В отделе 3 частично изменились правила начисления зарплаты. В этой ситуации при объектно-ориентированном подходе из класса «Зарплата» выводится класс «Зарплата 1», который наследует неизменившиеся правила начисления зарплаты и переопределяет изменившиеся. Здесь при расчете зарплаты объектам «Отдел 1» и «Отдел 2» будет передаваться объект «Зарплата», а объекту «Отдел 3» - объект «Зарплата 1». При таких изменениях:
Срабатывает принцип наследования: код «Зарплата», «Отдел 1» и «Отдел 2» остаются без изменения, а код «Зарплата 1» изменяется ровно настолько, насколько это необходимо.
Срабатывает принцип полиморфизма: код «Отдел 3» также не изменяется – он продолжает считать, что работает с объектом «Зарплата»
Некоторые итоги
Программная инженерия (или технология программирования) как некоторое направление возникло и формировалось под давлением роста стоимости создаваемого программного обеспечения. Главная цель этой области знаний - сокращение стоимости и сроков разработки программ.
Программная инженерия прошла несколько этапов развития, в процессе которых были сформулированы фундаментальные принципы и методы разработки программных продуктов. Основной принцип программной инженерии состоит в том, что программы создаются в результате выполнения нескольких взаимосвязанных этапов (анализ требований, проектирование, разработка, внедрение, сопровождение), составляющих жизненный цикл программного продукта. Фундаментальными методами проектирования и разработки являются модульное, структурное и объектно-ориентированное проектирование и программирование.
Продолжение кризиса программирования
Несмотря на то, что программная инженерия достигла определенных успехов, перманентный кризис программирования продолжается. Связано это с тем, рубеж 80–90-х годов отмечается как начало информационно-технологической революции, вызванной взрывным ростом использования информационных средств: персональный компьютер, локальные и глобальные вычислительные сети, мобильная связь, электронная почту, Internet и т.д.
Цена успеха – кризис программирования принимает хронические формы:
- США тратит ежегодно более $200 млрд. на более чем 170 тыс. проектов разработки ПО в сфере IT; 31,1% из них закрываются, так и не завершившись; 52,7% проектов завершаются с превышением первоначальных оценок бюджета/сроков и ограниченной функциональностью; потери от недополученного эффекта внедрения ПО измеряются триллионами.
Статистика по 30,000 проектам по разработке ПО в американских компаниях показывает следующее распределение между:
У спешными – вовремя и в рамках бюджета был выполнен весь намеченный фронт работ
Проблемными – нарушение сроков, перерасход бюджета и/или сделали не все, что требовалось
Проваленными – не были доведены до конца из-за перерасхода средств, бюджета, качества.
Источник: The Standish Group International The Standish Group International, Inc., Extreme Chaos, 2000 - //sample_research/PDFpages/extreme_chaos.pdf
1.2Программная инженерия – что это такое?
Начнем с определений
На сегодняшний день нет единого определения понятия «программная инженерия». На слайде приведено несколько таких определений, данных крупными специалистами в этой области, или зафиксированные в документах ведущих организаций.
Сам термин – software engineering (программная инженерия) - впервые был озвучен в октябре 1968 года на конференции подкомитета НАТО по науке и технике (г.Гармиш, Германия). Присутствовало 50 профессиональных разработчиков ПО из 11 стран. Рассматривались проблемы проектирования, разработки, распространения и поддержки программ. Там впервые и прозвучал термин «программная инженерия» как некоторая дисциплина, которую надо создавать и которой надо руководствоваться в решении перечисленных проблем.
Вскоре после этого в Лондоне состоялась встреча 22-х руководителей проектов по разработке ПО. На встрече анализировались проблемы и перспективы развития ПО. Отмечалась возрастающее воздействие ПО на жизнь людей. Впервые серьезно заговорили о надвигающемся кризисе ПО. Применяющиеся принципы и методы разработки ПО требовали постоянного усовершенствования. Именно на этой встрече была предложена концепция жизненного цикла ПО (SLC – Software Lifetime Cycle) как последовательности шагов-стадий, которые необходимо выполнить в процессе создания и эксплуатации ПО. Вокруг этой концепции было много споров. В 1970 г. У.У. Ройс (W.W. Royce) произвел идентификацию нескольких стадий в типичном цикле и было высказано предположение, что контроль выполнения стадий приведет к повышению качества ПО и сокращению стоимости разработки.
Разберемся в вопросах
Для того, чтобы получить представление о том, что такое программная инженерия, попробуем разобраться в следующих вопросах:
- Что такое программное обеспечение (software)? Что такое программная инженерия? В чем разница между программной инженерией (software engineering) и информатикой (computer science)? В чем разница между программной инженерией и системной инженерией (systems engineering)? В чем отличие программной инженерии от других инженерий?
Что такое программное обеспечение (software)?
Программное обеспечение это набор компьютерных программ, процедур и связанной с ними документации и данных (ISO/IEC 12207). Взгляд на ПО как только на программу, сидящую в компьютере слишком узок. Дело в том, что продается (поставляется) не только программа, но еще и документация, в которой можно прочитать как установить программу и как ей пользоваться и данные для установки программы в различных условиях (конфигурационные файлы). Поэтому ПО иногда называют программным продуктом. Т.е. программный продукт (программное обеспечение) – это не только программы, а также вся связанная с ними документация и конфигурационные данные, необходимые для корректной работы программы. А специалисты по программному обеспечению разрабатывают программные продукты, т.е. такое ПО, которое может быть продано потребителю.
В зависимости от того, для кого разрабатываются программные продукты (конкретного заказчика или рынка, программные продукты бывают двух типов:
- коробочные продукты (generic products – общие продукты или shrink-wrapped software – упакованное ПО) заказные продукты (bespoke – сделанный на заказ или customized products – настроенный продукт). Важная разница между ними заключается в том, кто ставит задачу (определяет, или специфицирует требования). В первом случае это делают сами разработчики на основе анализа рынка (маркетинга) – и при этом рискуют сами. Во втором – заказчик и при этом рискует, что разработчик не сможет реально выполнить все требования в срок и при выделенном бюджете.
Что такое программная инженерия?
Инженерная дисциплина
Все аспекты производства ПО
Для решения задачи инженеры применяют теории, методы и средства, пригодные для решения данной задачи, но они применяют их выборочно и всегда пытаются найти решения, даже в тех случаях, когда теорий или методов, соответствующих данной задаче, еще не существует. В этом случае инженер ищет метод или средство для решения задачи, применяет его и несет ответственность за результат – ведь метод или средство еще не проверены. Набор таких инженерных методов или способов, теоретически возможно не обоснованных, но получивших неоднократное подтверждение на практике, играет большую практическую роль. В программной инженерии они получили название лучших практик (best practices).
Инженеры работают в условиях ограниченных ресурсов: временных, финансовых и организационных (оборудование, техника, люди). Иными словами, продукт должен быть создан в установленные сроки, в рамках выделенных средств, оборудования и людей. Хотя это в первую очередь относится к созданию заказных продуктов (оговаривается в условиях контракта), но при создании коробочных продуктов эти ограничения имеют не меньшее значение, т.к. здесь они диктуются условиями рыночной конкуренции.
Все аспекты производства ПО . Программная инженерия занимается не только техническими вопросами производства ПО (специфицирование требований, проектирование, кодирование,…), но и управлением программными проектами, включая вопросы планирования, финансирования, управления коллективом и т.д. Кроме того, задачей программной инженерии является разработка средств, методов и теорий для поддержки процесса производства ПО.
Программные инженеры применяют систематичные и организованные подходы к работе для достижения максимальной эффективности и качества ПО. Их задача состоит в адаптации существующих методов и подходов к решению свой конкретной проблемы.
В чем отличия от информатики?
И наконец, информатика – это не единственный теоретический фундамент программной инженерии, т.к. круг проблем, стоящих перед программным инженером значительно шире просто написания программ. Это еще управление финансами, организация работ в коллективе, взаимодействие с заказчиком и т.д. Решение этих проблем требуют фундаментальных знаний, выходящих за рамки информатики.
В чем отличие от других инженерий?
Отличие программной инженерии от других инженерий интересно прежде всего с точки зрения двух вопросов:
Почему доля провальных проектов в программной инженерии так велика по сравнению с другими инженериями?
Можно ли в программной инженерии применять опыт других инженерий?
Эти вопросы является фундаментальными для программной инженерии. По этому поводу высказывается много мнений (и часто противоположных). Остановимся на некоторых более или менее очевидных отличиях программной инженерии от других инженерий.
Прежде всего, отметим, что жизненный цикл продукта любой инженерии в упрощенном виде включает фазы: проектирование, создание образца, испытание, производство, эксплуатация.
Компьютерная программа – это (в отличие от объектов других инженерий) не материальный объект (просьба не путать с носителем программы – устройством памяти любого типа). Отсюда следуют следующие отличия. Фаза производства состоит в копировании образца на другие носители. Стоимость фазы исчезающее мала. Если кодирование считать элементом проектирования (что очень близко к истине), то отсутствует также и фаза создания образца (строится компилятором и линковщиком)
Отсюда следуют следующие выводы:
Стоимость программы – это стоимость только ее проектирования
Стоимость проектирования коробочных продуктов «размазывается» по копиям
Стоимость заказных продуктов (массово не копируемых) остается высокой
В чем еще отличие от других инженерий?
Второе существенное отличие состоит в том, что программа – искусственный объект. Т.е. для программы нет объективных законов, которым бы подчинялось ее поведение. Например, у инженера – строителя есть объективные законы строительной механики: равновесия моментов и сил, устойчивости механических систем и т.д. Инженер – строитель может проверить свои архитектурные решения на соответствие этим законам и тем самым обеспечить удачу проекта. Эти законы объективны, они будут действовать всегда. У программного инженера на первый взгляд также есть типовые, проверенные временем архитектурные решения (например, клиент-серверная архитектура). Но эти решения определяются уровнем развития вычислительной техники (и адекватным им уровнем требований). С появлением техники с принципиально новыми возможностями программному инженеру придется искать новые решения.
Прямым следствием отсутствия возможности «теоретического» контроля проекта является то, что тестирование продукта – это единственный способ убедиться в его качестве. Именно поэтому стоимость тестирования составляет существенную стоимость ПО. Кстати, строительный инженер, как правило, лишен возможности такого «тестирования» своего продукта перед сдачей его в эксплуатацию.
Ну и наконец, программная инженерия – молодая дисциплина, опыт которой насчитывает всего несколько десятков лет. По сравнению с опытом строительной инженерии (тысячелетия) это конечно очень мало. Программную инженерию иногда сравнивают с ранней строительной, когда законы строительной механики еще не были известны и строительные инженеры действовали методом проб и ошибок, накапливая бесценный опыт. Несмотря на молодой возраст, программная инженерия также накопила определенный опыт, который позволяет (при разумном его применении) делать удачные проекты. Этот опыт выражен в основных принципах программной инженерии, которые мы с вами сейчас рассмотрим.
Подробнее о проблемах проектирования ПО можно посмотреть в неоднозначной статье Кони Бюрера «От ремесла к науке: поиск основных принципов разработки ПО» /fset.asp?Url=/rational/science.htm
Из чего складывается стоимость ПО?
Структура стоимости ПО существенно зависит от типа ПО, применяемых методов его разработки и … метода оценки. Так, многие авторы отмечают высокую долю стоимости этапа сопровождения. Для некоторых типов ПО она может составлять 60 и более процентов от общей стоимости. Между тем, этап сопровождения включает выполнение двух видов работ: исправление ошибок в программе (несоответствий первоначальным требованиям) и внесение изменений в программу (добавление новых требований). При другом подходе к оценке можно считать, что этап сопровождения на стоит оценивать отдельно, т.к. исправление ошибок можно отнести к продолжению тестирования, а внесение изменений – к новому проекту.
Типовое распределение стоимости между основными этапами (без сопровождения) выглядит следующим образом:
15% - спецификация – формулировка требований и условий разработки
25% - проектирование – разработка и верификация проекта
20% - разработка – кодирование и тестирование компонент
40% - интеграция и тестирование – объединение и сборочное тестирование продукта
Отклонения от этой схемы в зависимости от типа ПО выглядят следующим образом:
Для коробочного ПО характерна более высокая доля тестирования за счет сокращения прежде всего доли спецификации (до 5%)
Распределение стоимости заказного ПО зависит от его сложности. При сложном ПО также возрастает доля интеграции и тестирования, но за счет сокращения доли проектирования и разработки Доля спецификаций может возрастать. Сокращение доли проектирования и разработки достигается за счет применения опробованных проектных решений и повторного использования готовых компонент.
Применение опробованных решений и готовых компонент при создании коробочных продуктов позволяет повысить качество и сократить сроки разработки.
Еще вопросы
Для того, чтобы получить представление о том, в чем состоит накопленный программной инженерией опыт, попробуем разобраться в следующих вопросах:
Что такое программный процесс?
Что такое модель программного процесса?
Что такое методы программной инженерии?
Что такое CASE (Computer-Aided Software Engineering)?
Какими свойствами обладает хорошая программа?
Какие основные трудности стоят перед программной инженерией?
Программный процесс?
Одним из основных понятий программной инженерии является понятие жизненного цикла программного продукта и программного процесса.
Жизненный цикл – непрерывный процесс, начинающийся с момента принятия решения о создании ПО и заканчивающийся снятием его с эксплуатации. Жизненный цикл разбивается на отдельные процессы.
Процесс – совокупность действий и задач, имеющих целью достижение значимого результата. Основными процессами (иногда называют этапами или фазами) жизненного цикла являются:
Разработка спецификации требований (результат – описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать)
Разработка проекта программы (результат – описание того, как программа будет работать)
Кодирование (результат – исходный код и файлы конфигурации)
Тестирование программы (результат - контроль соответствия программы требованиям)
Документирование (результат – документация к программе)
Кроме основных, существует много дополнительных и вспомогательных процессов, связанных не созданием продукта, а с организацией работ (нефункциональные процессы): создание инфраструктуры, управление конфигурацией, управление качеством, обучение, разрешение противоречий, …
Процесс должен быть установлен. Полное установление процесса предполагает:
- Описание процесса – детальное описание действий и операций процесса Обучение процессу – проведение занятий с персоналом по освоению процесса Введение метрик – установление количественных показателей хода выполнения Контроль выполнения – измерение метрических показателей и оценка хода выполнения Усовершенствование – изменение процесса при меняющихся условиях применения
Применение полных (тяжелых) процессов требует дополнительных ресурсов (зачастую существенных) и далеко не всегда окупается полученным результатом. Поэтому, выбор состава процессов, степени их установленности (полноты установленности) в каждом конкретном случае может быть сделан по-разному в соответствии с выбранной моделью процесса.
Введение в программную инженерию
Современный мир все больше зависит от систем, построенных на основе вычислительной техники. Все больше технических устройств включают в себя элементы вычислительной техники и соответствующего управляющего программного обеспечения (ПО) в той или иной форме. В таких системах стоимость ПО порой составляет большую часть общей стоимости. Более того, стоимостные показатели отраслей, занимающихся производством ПО, становятся определяющими для экономики – как национальной, так и международной.
Целью инженерии программного обеспечения является эффективное создание программных систем. Программное обеспечение абстрактно и нематериально. Оно не имеет физической природы, отвергает физические законы и не подвергается обработке производственными процессами. Такой упрощенный взгляд на ПО показывает, что не существует физических ограничений на потенциальные возможности программных систем. С другой стороны, отсутствие материального наполнения порой делает ПО чрезвычайно сложным и, следовательно, трудным для понимания "объектом".
Инженерия программного обеспечения – сравнительно молодая научная дисциплина. Термин software engineering был впервые предложен в 1968 году на конференции, посвященной так называемому кризису программного обеспечения. Этот кризис был вызван появлением мощной (по меркам того времени) вычислительной техники третьего поколения. Новая техника позволяла воплотить в жизнь не реализуемые ранее программные приложения. В результате программное обеспечение достигло размеров и уровня сложности, намного превышающих аналогичные показатели у программных систем, реализованных на вычислительной технике предыдущих поколений.
Оказалось, что неформальный подход, применявшийся ранее к построению программных систем, недостаточен для разработки больших систем. На реализацию крупных программных проектов иногда уходили многие годы. Стоимость таких проектов многократно возрастала по сравнению с первоначальными расчетами, сами программные системы получались ненадежными, сложными в эксплуатации и сопровождении. Разработка программного обеспечения оказалась в кризисе. Стоимость аппаратных средств постепенно снижалась, тогда как стоимость ПО стремительно возрастала. Возникла необходимость в новых технологиях и методах управления комплексными сложными проектами разработки больших программных систем.
Такие методы составили часть инженерии программного обеспечения и в настоящее время широко используются, хотя, конечно же, не являются универсальными. Сохраняется много проблем в процессе разработки сложных программных систем, на решение которых затрачивается много времени и средств. Реализация многих программных проектов сталкивается с подобными проблемами, это дает право некоторым специалистам утверждать, что современная технология создания программного обеспечения находится в состоянии хронического недуга.
С другой стороны, возрастает как объем производства программного обеспечения, так и его сложность. Кроме того, сближение вычислительной и коммуникационной техники ставит новые требования перед специалистами по программному обеспечению. Это также является одной из причин возникновения проблем при разработке программных систем, как и то, что многие компании, занимающиеся производством ПО, не уделяют должного внимания эффективному применению современных методов, разработанных в рамках инженерии программного обеспечения. Дело не так плохо, как утверждают скептики, благодаря критике которых высвечиваются болевые точки, способные стать точками роста инженерии программного обеспечения.
По сравнению с 1968 годом сделан огромный скачок и развитие инженерии программного обеспечения значительно улучшило современное ПО. Теперь мы лучше понимаем те процессы, которые определяют развитие программных систем. Разработаны эффективные методы спецификации ПО, его разработки и внедрения. Новые средства и технологии позволяют значительно уменьшить усилия и затраты на создание больших и сложных программных систем.
Специалисты по программному обеспечению могут гордиться такими достижениями. Без современного сложного ПО было бы невозможно освоение космического пространства, не существовало бы Internet и современных телекоммуникаций, а все транспортные средства и виды транспортировки были бы более опасными и дорогостоящими. Инженерия программного обеспечения достигла многого за свою пока еще короткую жизнь, и ее значение как зрелой научной дисциплины еще более возрастет в XXI столетии.
Вопросы и ответы об инженерии программного обеспечения
Этот раздел построен в виде ответов на некоторые основные вопросы, касающиеся инженерии программного обеспечения. В данном разделе используется формат "списка FAQ" (Frequently Asked Questions – часто задаваемые вопросы). Такой формат обычно применяется в группах новостей Internet, предлагая новичкам ответы на часто задаваемые вопросы. Надеюсь, что подобный подход будет эффективен в качестве краткого введения в предмет инженерии программного обеспечения.
Вопросы и ответы, подробно рассматриваемые в этом разделе, компактно представлены в табл. 1.1.
Таблица 1.1. Часто задаваемые вопросы об инженерии программного обеспечения
Загрузка...
