Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Основи конструювання

Фундаментальні основи конструювання програмного забезпечення включають:

· Мінімізація складності

· Очікування змін

· Конструювання з можливістю перевірки

· Стандарти у конструюванні

Перші три концепції застосовуються не тільки до конструювання, але й проектування, і лежать в основі сучасних методологій управління життєвим циклом програмних систем.


Мінімізація складності (Minimizing Complexity)

 

Основною причиною того, чому люди використовують комп'ютери в бізнес-цілях, є обмежені можливості людей в обробці і зберіганні складних структур і великих обсягів інформації, зокрема, протягом тривалого періоду часу. Це міркування є однією з основних рушійних сил у конструюванні програмного забезпечення: мінімізація складності. Потреба у зменшенні складності впливає на всі аспекти конструювання і особливо критична для процесів верифікації (перевірки) і тестування результатів конструювання, тобто самих програмних систем.

Зменшення складності у конструюванні програмного забезпечення досягається за допомогою звертання особливої уваги на створення простого коду, який легко читається, іноді на шкоду прагненню зробити його ідеальним (наприклад, з точки зору гнучкості або слідування тим чи іншим уявленням про красу, витонченість коду, вправність тих чи інших прийомів тощо). Це не означає, що повинно обмежуватися застосування тих чи інших розвинених мовних можливостей використовуваних засобів програмування. Мається на увазі "лише" надання більшої значимості читаності коду, простоті тестування, прийнятного рівня продуктивності та задоволенню заданих критеріїв, замість постійного вдосконалення коду, не оглядаючись на терміни, функціональність і інші характеристики та обмеження проекту.

Мінімізація складності досягається, зокрема, за рахунок слідування стандартам, використанням низки специфічних технік кодування і підтримкою практик, спрямованих на забезпечення якості в конструюванні. Радять слідувати наступним правилам:

• розділити систему на підсистеми на рівні архітектури, щоб у кожний момент часу концентруватися на меншій частині системи;

• ретельно визначати інтерфейси класів, проте передавати лише дійсно потрібні параметри, щоб можна було певною мірою ігнорувати внутрішню будову класів;

• уникати глобальних даних, тому що їх використання значно збільшує процент коду, що треба утримувати в голові в кожний момент часу;

• уникати глибоких ієрархій наслідування, вкладеності циклів та операторів goto, оскільки їх можна замінити на більш прості структури;

• визначити підхід до обробки помилок, систематично використовувати механізм виключень;

• підтримувати класи і методи досить короткими, не дозволяти їх розмірам досягати розмірів цілих програм;

• використовувати зрозумілі імена змінних.

Очікування змін (Anticipating Changes)

 

Більшість програмних систем змінюються з плином часу. Причин цьому - безліч. Очікування змін є однією з рушійних сил конструювання програмного забезпечення. Програмне забезпечення не є ізольованим від зовнішнього оточення (як системного, так і з точки зору галузі діяльності, для автоматизації задач і проблем якого воно застосовується). Більш того, програмні системи є частиною середовища, що змінюється, і повинні змінюватися разом з нею, а, іноді, і бути джерелом змін самого середовища.

Очікування змін підтримується рядом технік кодування та форматування. Цілі хорошого форматування:

• Точно представляти логічну структуру коду (програмістами зазвичай використовуються відступи та інші символи, що не відображаються);

• Одноманітно показувати логічну структуру коду;

• Покращувати читабельність (хороша структура форматування спрощує читання коду);

• Витримувати процедуру виправлення (кращі схеми форматування добре переносять модифікацію коду).

Наведемо приклад невдалого стилю форматування для оператора case.

 

switch (ballColor) {

case BallColor_Blue: Rollout();

break;

case BallColor_Orange: SpinOnFinger();

break;

case BallColor_White: KnockCoverOff();

break;

case BallColor_WhiteAndBlue: if (mainColor == BallColor_White) {

KnockCoverOff();

}

else if (mainColor == BallColor_Blue) {

RollOut();

}

break;

default: FatalError("Unrecognized kind of ball.");

break;

}

 

При додаванні варіантів із довшими назвами потрібно буде зрушувати всі варіанти і код, що до них відноситься. Великі відступи ускладнюють розміщення додаткової логіки. Якщо у циклах Ви використовуєте відступ розміром 3 пробіли, тоді краще слідувати форматуванню, наведеному нижче:

 

switch (ballColor) {

case BallColor_Blue:

Rollout();

break;

case BallColor_Orange:

SpinOnFinger();

break;

case BallColor_White:

KnockCoverOff();

break;

case BallColor_WhiteAndBlue:

if (mainColor = BallColor_White) {

KnockCoverOff();

}

else if (mainColor = BallColor_Blue) {

RollOut();

}

break;

default:

FatalError("Unrecognized kind of ball.");

break;

}

 

Корисно також буде використовувати типову організацію файлу з вихідним кодом на С++:

ü Коментар з описом файлу

ü Файли, які підключаються директивою #include

ü Визначення констант (для декількох класів)

ü Перечислення (для декількох класів)

ü Визначення макросів

ü Визначення типів (для декількох класів)

ü Глобальні змінні та функції, що імпортуються

ü Глобальні змінні та функції, що експортуються

ü Змінні та функції, що видимі лише у цьому файлі

ü Класи (разом з визначеннями констант, перечислень і типів, що відносяться до конкретного класу)

 

 

Конструювання з можливістю перевірки (Constructing for Verification)

"Конструювання для перевірки" (а саме такий сенс закладений в оригінальній назві даної підтеми) припускає, що побудова програмних систем повинна вестися таким чином, щоб сама програмна система допомагала вести пошук причин збоїв, будучи прозорою для застосування різних методів перевірки (і, до речі, внесення необхідних змін), як на стадії незалежного тестування (наприклад, інженерами-тестувальниками), так і в процесі операційної діяльності - експлуатації, коли особливо важлива можливість швидкого виявлення та виправлення помилок що виникають.

Серед технік, спрямованих на досягнення такого результату конструювання:

• огляд, оцінка коду (code review – систематична перевірка вихідного коду програми з метою виявлення та виправлення помилок – застосовувалася для ядра Linux, пакету для створення тривимірної графіки Blender);

• модульне тестування (unit-testing – процес перевірки на коректність окремих модулів вихідного коду програми)

• структурування коду для та разом із застосуванням автоматизованих засобів тестування (automated testing)

• обмежене застосування складних або важких для розуміння мовних структур

Стандарти у конструюванні (Standards in Constructing)

 

Стандарти, які безпосередньо застосовуються при конструюванні, включають:

· Комунікаційні методи (наприклад, стандарти форматів документів і оформлення вмісту)

· Мови програмування і відповідні стилі кодування (наприклад, Java Language Specification, що є частиною стандартної документації JDK - Java Development Kit і Java Style Guide, що пропонує загальний стиль кодування для мови програмування Java)

· Платформи (наприклад, стандарти програмних інтерфейсів для викликів функцій операційного середовища, такі як прикладні програмні інтерфейси платформи Windows - Win32 API, Application Programming Interface або.NET Framework SDK, Software Development Kit)

· Інструменти (не в термінах середовищ розробки, але можливих засобів конструювання - наприклад, UML як один зі стандартів для визначення нотацій для діаграм, що представляють структура коду і його елементів або деяких аспектів поведінки коду)

Використання зовнішніх стандартів. Конструювання залежить від зовнішніх стандартів, пов'язаних з мовами програмування, використовуваним інструментальним забезпеченням, технічними інтерфейсами і взаємним впливом конструювання програмного забезпечення та інших галузей знань програмної інженерії (в тому числі, пов'язаних дисциплін, наприклад, управління проектами). Стандарти створюються різними органами, наприклад, консорціумом OMG - Object Management Group (зокрема. Стандарти CORBA, UML, MDA,...), міжнародними організаціями з стандартизації такими, як ISO/IEC, IEEE, TMF,..., виробниками платформ, операційних середовищ і т.д. (Наприклад, Microsoft, Sun Microsystems, CISCO, NOKIA,...), виробниками інструментів, систем управління базами даних і т.п. (Borland, IBM, Microsoft, Sun, Oracle,...). Розуміння цього факту дозволяє визначити достатній і повний набір стандартів, які застосовуються у проектній команді або організації в цілому.

Кожна програмна система протягом свого існування проходить з певною послідовністю фази або стадії від задуму до його втілення в програми, експлуатацію та вилучення. Така послідовність фаз називається життєвим циклом розробки (Software life cycle processes). На кожній фазі відбувається певна сукупність процесів, кожен з яких породжує певний продукт, використовуючи певні ресурси.

Усі продукти всіх процесів програмної інженерії являють собою певні описи — тексти вимог до розробки, погодження домовленостей, документацію, тексти програм, інструкції з експлуатації тощо.

Головними ресурсами програмної інженерії, які визначають ефективність її розробок, є час і вартість цих розробок.

Різновиди діяльності, котрі становлять процеси життєвого циклу програмної системи, зафіксовано в міжнародному стандарті ISO/IEC 12207: 1995—0801: Informational Technology - Software life cycle processes.

 

Згідно з наведеним стандартом, усі процеси поділено на три групи:

· головні процеси;

· допоміжні процеси;

· організаційні процеси.

 

До головних процесів віднесено такі:

· процес придбання, який ініціює життєвий цикл системи та визначає організацію-покупця автоматизованої системи, програмної системи або сервісу;

· процес розроблення, який означає дії організації — розробника програмного продукту;

· процес постачання, який означає дії під час передавання розробленого продукту покупцеві;

· процес експлуатації, який означає дії з обслуговування системи під час її використання — консультації користувачів, вивчення їхніх побажань тощо;

· процес супроводження, який означає дії з керування модифікаціями, підтримки актуального стану та функціональної придатності, інсталяцію та вилучення версій програмних систем у користувача.

 

У свою чергу, до процесу розроблення входять такі процеси:

· інженерія вимог до системи;

· проектування;

· кодування й тестування.

 

До допоміжних процесів віднесено ті, що так чи інакше забезпечують якість продукту. Терміном якість продукту позначено сукупність властивостей, які зумовлюють можливість задоволення потреб замовника, котрий сформулював їх у формі вимог на розробку.

До організаційних процесів віднесено менеджмент розробки, створення структури організації, навчання персоналу, визначення відповідальності кожного з учасників процесів життєвого циклу розробки.

Стандарт ISO/IEC 12207:1995 - 0801: Informational Technology - Software life cycle processes є головним чинником визначення змісту діяльності у сфері програмної інженерії, і всі знання, яких потребують професіонали з програмної інженерії, формулюються стосовно процесів, визначених цим стандартом.

Зупинимося докладніше на процесах розробки програмного забезпечення, які в сукупності мають забезпечити шлях від усвідомлення потреб замовника до передавання йому готового продукту. На цьому шляху виділяють низку характерних робіт:

· Визначення вимог. Збір та аналіз вимог замовника виконавцем і подання їх у нотації, яка є зрозумілою як для замовника, так і для виконавця.

· Проектування. Перетворення вимог до розробки в послідовність проектних рішень щодо способів реалізації вимог: формування загальної архітектури програмної системи та принципів її прив’язки до конкретного середовища функціонування; визначення детального складу модулів кожної з архітектурних компонент.

· Реалізація. Перетворення проектних рішень на програмну систему, яка реалізує такі рішення.

· Тестування. Перевірка кожного з модулів та способів їхньої інтеграції; тестування програмного продукту в цілому (так звана верифікація); тестування відповідності функцій працюючої програмної системи вимогам (requirements), поставленим до неї замовником (так звана валідація).

· Експлуатація та супроводження готової програмної системи.

Базовими вітчизняними нормативними документами в галузі програмної інженерії є:

· ДСТУ 2873-94. Системи обробки інформації. Програмування. Терміни та визначення.

· ДСТУ 2941-94. Системи оброблення інформації. Розроблення систем. Терміни та визначення.

· ДСТУ 4302:2004. Інформаційні технології. Настанови щодо документування комп’ютерних програм.

· ДСТУ ISO/IEC 12119:2003. Інформаційні технології. Пакети програм тестування і вимоги до якості.

· ДСТУ ISO/IEC 14764:2002. Інформаційні технології. Супроводження програмного забезпечення.

· ДСТУ ISO/IEC 90003:2006. Програмна інженерія. Настанови щодо застосування ІSO 9001:2000 до програмного забезпечення (ІSO/ІЕС 90003:2004, IDT)

· ДСТУ ISO/IEC TR 12182:2004. Інформаційні технології. Класифікація програмних засобів (ISO/IEC TR 12182:1998, IDT)

· ДСТУ ISO/IEC 14598-1:2004. Інформаційні технології. Оцінювання програмного продукту. Частина 1. Загальний огляд (ISO/IEC 14598-1:1999, IDT)

· ДСТУ ISO/IEC 15288:2005. Інформаційні технології. Процеси життєвого циклу системи (ISO/IEC 15288:2002, IDT)

· ДСТУ ISO/IEC 15939:2008. Інженерія систем і програмних засобів. Процес вимірювання.

· ДСТУ 3327-96. Методика випробування процесорів мов програмування. Загальні вимоги.

· ДСТУ ISO/IEC TR 14369:2003. Інформаційні технології. Мови програмування, їхнє середовище та системний інтерфейс. Настанова щодо підготовки незалежних від мов специфікацій послуг.

· ДСТУ 4072:2001. Інформаційні технології. Мови програмування, їхнє середовище та системний інтерфейс. Настанова щодо підготовки незалежних від мов виклик процедур.

· ДСТУ ISO/IEC 2382-15:2005. Інформаційні технології. Словник термінів. Частина 15. Мови програмування (ISO/IEC 2382-15:1999, IDT)

· дсту 3008-95. "Документація. Звіти у сфері науки і техніки Структура і правила оформлення". К.: Держстандарт України,1995. – 75 с.

· ГОСТ 2.106-96. Единая система конструкторской документации. Текстовые документы. Изд. Офиц – К.: Госстандарт Украины, 1998. – 47 с.

· гост 2.109-73 ЕСКД. Основные требования к чертежам – М., 1978.

· ГОСТ 2.105-95. Единая система конструкторской документации. Общие требования к текстовым документам. Изд. Офиц – К.: Госстандарт Украины, 1996.

· Гост 7.32-91. Система стандартов по информации, библиотечному и издательскому делу. Отчет о научно-исследовательской работе. Структура и правила оформления

Використання внутрішніх стандартів. Певні стандарти, угоди та процедури можуть бути також створені усередині організації або навіть команди, що працює над проектом. Ці стандарти підтримують координацію між певними видами діяльності, групами операцій, мінімізують складність (у тому числі при взаємодії членів команди та за її межами), можуть бути пов'язані з питаннями очікування та обробки змін, ризиків і питаннями конструювання для перевірки та подальшого тестування. У поєднанні із зовнішніми стандартами, внутрішні стандарти покликані визначити загальні правила гри для всіх членів команди, домовившись про терміни, процедури та інші значущі угоди, незалежно від ступеня формалізації процесів конструювання зокрема і процесів життєвого циклу в загальному випадку.

Рекомендована література

1. Совершенный код. Мастер-класс / Пер. с англ. — М.: Издательско- торговый дом «Русская Редакция»; СПб.: Питер, 2005. — 896 стр.: ил.

2. IEEE – SWEBOK Guide V3, ch. 4.

<== предыдущая лекция | следующая лекция ==>
Місце конструювання у процесі розробки ПЗ | Основні складові інформатики
Поделиться с друзьями:


Дата добавления: 2014-01-04; Просмотров: 701; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.011 сек.