Шляхом побудови дерева виводу.
ВАРІАНТ № 18
Екосистема програмного забезпечення.
Сценарії створення збірок
Методи відновлення граматичного розбору при наявності помилок в програмах.
Розгляньте наступну ситуацію: у Вас є застаріле банківське програмне забезпечення, що виконує функції біллінгу. Для нього повністю відсутня документація. Вам поставили завдання виконати повторну інженерію цього ПЗ з метою перенесення його на сучасну апаратну платформу, причому нова версія має працювати так само чітко і надійно, як і застаріла версія. Визначте набір процесів, підходів, засобів (інструментів) та тестів для вирішення поставленого завдання.
На прикладі програмного забезпечення підготовленого до експлуатації перерахуйте та розкрийте зміст основних дій пов’язаних з впровадженням і експлуатацією програмного забезпечення.
+18.1.Екосистема програмного забезпечення.
Екосистеми програмного забезпечення - неформальна мережа (юридично незалежні) одиниці, які мають позитивний вплив на економічний успіх програмного продукту і користь з цього продукту".
Складається з множини програмних рішень, які дозволяють, підтримувати та автоматизувати діяльність та керувати учасниками у відповідній соціальній або бізнес-екосистемі та організаціями, які надають ці рішення“.
В цих визначеннях виділяють три загальних поняття: (1) суб'єкти, організації і підприємства, (2) мережа, (3) програмне забезпечення.
Екосистеми програмного забезпечення є множина учасників, які функціонують як єдине ціле і взаємодіють із загальним ринком програмного забезпечення і послуг, а також відносини між ними.
Ці відносини часто основані на єдиній технологічній платформі або ринку і діють шляхом обміну інформацією, ресурсами і артефактами.
Екосистеми програмного забезпечення зазвичай регулюються і управляються однією або декількома координаційними сторонами. Як правило, ці координатори також керують «основою технологією», на якій основана екосистема, наприклад, комерційна компанія, яка будує програмну платформу. Координатори екосистем програмного забезпечення визначені в якості стимуляторів росту екосистеми програмного забезпечення, які мають засоби, щоб вплинути на розвиток основної платформи або екосистеми. Як правило, вони є також (частково), відповідальні за подальший розвиток основної платформи.
Роль програмної платформи в екосистемі програмного забезпечення суттєва. Якщо екосистема формується навколо чогось, контролююча частина повинна з’ясувати рівень свободи для створюємої цінності, при цьому контролююча частина отримує лише невелику її частину.
Базова технологія - визначення екосистеми програмного забезпечення показує, що в цілому лежить в основі екосистеми. Дослідження свідчать, що всі екосистеми програмного забезпечення засновані на технологіях. Використовуються такі типи технології як, програмна платформа, платформа послуг і стандарти програмного забезпечення. Деякі екосистеми програмного забезпечення підтримуються навіть декількома програмними платформами, така як Microsoft ISV, яка заснована на Microsoft CRM, SharePoint, Exchange.
Технологічна база для екосистем програмного забезпечення це програмна платформа, навколо якої інші учасники екосистеми можуть взаємодіяти. Це такі платформи, як Force.com і платформи HubSpot, які доступні тільки в Інтернеті і не можуть бути встановлені окремо на сервері клієнта.
Екосистема програмного забезпечення застосовується на основі платформи програмного забезпечення сервісів та стандартів і координується приватними особами або спільнотами комерційного ринку або багатотоварних ринків, до яких учасники можуть приєднуватись безкоштовно, після відбору або після внесення оплати
+18.2.Сценарії створення збірок
Самые распространенные сценарии Team Build:
Однократная ежедневная сборка. Большинство групп используют плановые сборки, чтобы регулярно обеспечивать двоичными файлами группу тестирования и других пользователей.
Ежедневные сборки и сборки в процессе непрерывной интеграции.Некоторые группы предпочитают использовать процесс непрерывной интеграции, чтобы обеспечить своим разработчикам быструю обратную связь при каждом событии регистрации изменений. Непрерывная интеграция хороша для небольших групп, а вот сервер сборки большой группы, вероятнее всего, будет перегружен из-за высокой частоты формирования событий регистрации изменений и более длительного времени сборки. Когда такое происходит, можно использовать скользящую сборку, которая позволяет выполнять сборку не так часто, но при этом не делая больших перерывов между событием регистрации изменений и получением результатов сборки.
Несколько лабораторий сборки, каждая из которых создает ежедневную сборку и сборки в процессе непрерывной интеграции. Очень большим группам для улучшения качества сборок и своевременного их выполнения, скорее всего, потребуются более сложные решения. Используя регистрацию изменений с порогом качества и отклоняя дефектные изменения прежде, чем они будут зарегистрированы в системе контроля версий, можно сократить сбои при сборках. Группы, использующие ветвление, могут использовать несколько серверов сборки, по одному на каждую ветвь, чтобы каждая сборка была ориентирована на цели своей ветви. Например, ветви интеграции создают сборки для целей интеграции, тогда как ветви разработки создают сборки для целей разработки.
+18.3.Методи відновлення граматичного розбору при наявності помилок в програмах.
Під час виявлення помилки аналізатор не повинен закінчувати свою роботу і «піднімати паніку», а повинен відмітити і відобразити помилку, що виникла помилка в певному місці і продовжити роботу над рештою коду..
Для вирішення цієї ситуації застосовують два підходи.
Перший з них використовує «зовнішній символ» - передбачаєтьтся, що у цьому випадку компілятор здійснює пропуск символів, доки не зустріне «вираз».
Тобто, аналізатор індикує (индицирует) помилку і шукає перший символ, що закінчує конструкцію.
Наприклад, у виразі 2+3 відсутній +. Тоді аналізатор продовжує пошук 3 і переходить до наступного етапу.
Приклад другого випадку: у переліку ідентифікаторів відсутня кома.
повинно бути: а, в, с, d....
а насправді: а в, с, d...
тоды аналызатор повідомляє, що згідно з конструкцією після «а» повианна бути кома і продовжує роботу.
========
Часто основні дії по виявленню помилок і відновленню після них концентруються у фазі синтаксичного аналізу.
Одна з причин цього полягає в тому, що багато помилок за своєю природою є синтаксичними або виявляються, коли потік токенів, що йде від лексичного аналізатора, порушує визначаючі мова програмування граматичні правила.
Друга причина полягає в точності сучасних методів розбору; вони дуже ефективно виявляють синтаксичні помилки в програмі. Обробник помилок синтаксичного аналізатора має просту формульовану мету:
він повинен ясно і точно повідомляти про наявність помилок;
він повинен забезпечувати швидке відновлення після помилки, щоб продовжити пошук подальших помилок;
він не повинен істотно уповільнювати обробку коректної програми.
+***18.4.Розгляньте наступну ситуацію: у Вас є застаріле банківське програмне забезпечення, що виконує функції біллінгу. Для нього повністю відсутня документація. Вам поставили завдання виконати повторну інженерію цього ПЗ з метою перенесення його на сучасну апаратну платформу, причому нова версія має працювати так само чітко і надійно, як і застаріла версія. Визначте набір процесів, підходів, засобів (інструментів) та тестів для вирішення поставленого завдання.
Изменение документации, в зависимости от исходного состояния проекта и новых требований к документированию, может затрагивать разные виды спецификаций проекта. На рис. 3 показана модель восстановления и переработки спецификаций проекта, в которой можно выделить процессы двух основных видов: редокументирование и обратная инженерия [2]. Редокументирование реализует изменения формы представления спецификаций определенного этапа разработки, без использования спецификаций других этапов. Обратная инженерия реализует восстановление или изменение (путем реализации процессов прямой инженерии) спецификаций определенного этапа разработки на основе спецификаций других этапов.
Артефакты, получаемые в результате проектирования ПО, создаются в рамках определенной системы (модели) проектирования. В ней можно выделить следующие основные элементы: парадигму проектирования, языки специфицирования, инструментальные средства проектирования и документирования. Сейчас одним из наиболее совершенных и перспективных процессов разработки ПО-унифицированный процесс разработки (Rational Unified Process - RUP) [5]. В RUP проектирование основано на объектно-ориентированной парадигме, а для специфицирования проекта и его результатов используется язык Unified Modeling Language (UML) [6]. В настоящее время RUP поддерживается семейством продуктов IBM Rational [7]. В рамках RUP, при выполнении рабочих процессов разрабатывается ряд моделей, которые представляются с использованием языка UML. К основным относят следующие модели [5, 7]: требований; анализа, проектирования, развертывания, реализации, тестирования. Основываясь на анализе фаз и рабочих процессов RUP можно распределить эти модели по видам спецификаций (рис.1) следующим образом [5]:
− требований – модель требований;
− проектные – модели анализа и проектирования;
− реализации – модели развертывания, реализации и тестирования.
Очевидно, что для эффективной переработки исходной документации проекта на соответствие моделям RUP необходимо провести предварительное сопоставление их содержания. В таблице приведено сопоставление моделей и артефактов RUP [5, 9] c видами исходных документов проектов ПО, определяемых стандартом [8]. Сопоставление проведено на основе анализа их назначения, семантики и содержания. Кроме того, в таблице приведены типы процессов, обеспечивающие переработку содержимого исходных документов, и исполнители, в качестве которых могут выступать эксперты или соответствующие CASE-инструменты [10]. Сопоставление моделей и артефактов RUP документам стандарта.
1. Начать нужно с определения того, что у нас есть по программе, исходные тесты, БД. Зафиксировать текущее состояние системы для сверения с результатами последующих изменений.
2. Работы по описанию архитектур начинаются фактически на начальном этапе, когда определяется состав оборудования и стандартное программное обеспечение (ПО), необходимые для инсталляции и запуска существующей зафиксированной системы. Тем самым фактически определяются архитектуры БД, оборудования и стандартного ПО, телекоммуникаций. Все архитектуры представляются в нотации UML и при необходимости дополняются текстовыми описаниями. Поостренные архитектурные модели в процессе реинжиниринга будут уточняться и дополняться.
3. Построение функциональной модели, диаграммы вариантов использования
4. Анализ требований к системе (функциональных и нефункциональных)
5. На основе полученных спецификаций провести проектирование системы.
6. Провести реализацию системы
7. Провести тестирование системы методами белого ящика и черного ящика, для проверки связей между компонентами и правильности интеграции компонентов, провести модульное тестирование, сверяя результаты с прошлой системой
+***18.5.На прикладі програмного забезпечення підготовленого до експлуатації перерахуйте та розкрийте зміст основних дій пов’язаних з впровадженням і експлуатацією програмного забезпечення.