МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
РОСІЙСЬКИЙ ДЕРЖАВНИЙ ТОРГОВЕЛЬНО-ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ
ВОЛГОГРАДСЬКИЙ ФІЛІЯ
КОНТРОЛЬНА РОБОТА
За дисципліни: В«Інформаційні технології в економіціВ»
Варіант № 13
Виконала:
Перевірила:
к.с.н. ст. препод.
Дмитрієва І.С.
ШИФР: ЕІ УП СПО-2007-108
ВОЛГОГРАД 2010
Зміст
1. Суть і область застосування CASE-технологій. Функціонально-модульний і об'єктно-орієнтований підходи до розробки
1. Суть і область застосування CASE -технологій. Функціонально-модульний і об'єктно-орієнтований підходи до розробки
Абревіатура CASE розшифровується як Computer Aided Software Engineering. Цей термін широко використовується в даний час. На етапі появи подібних засобів, термін CASE вживався лише у відношенні автоматизації розробки програмного забезпечення. Сьогодні CASE засоби мають на увазі процес розробки складних ІС в цілому: створення та супровід ІС, аналіз, формулювання вимог, проектування прикладного ПО і баз даних, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління і управління проектом, а також інші процеси. Таким чином, CASE-технології утворюють цілу середовище розробки ІС.Ітак, CASE-технологія являє собою методологію проектування програмних систем, а також набір інструментальних засобів, що дозволяють в наочній формі моделювати предметну область, аналізувати цю модель на всіх етапах розробки і супроводу ІС і розробляти додатки відповідно з інформаційними потребами користувачів. Більшість існуючих CASE-засобів засновано на методологіях структурного або об'єктно-орієнтованого аналізу і проектування, що використовують специфікації у вигляді діаграм або текстів для опису зовнішніх вимог, зв'язків між моделями системи, динаміки поведінки системи та архітектури програмних засобів. Головні складові CASE-продукту такі:
В· методологія (Method Diagrams) , яка задає єдиний графічний мову і правила роботи з ним;
В· графічні редактори (Graphic Editors) , які допомагають малювати діаграми; виникли з поширенням PC і GUI, так званих В«upper caseВ» технологій;
В· генератор : по графічному поданням моделі можна згенерувати вихідний код для різних платформ (так звана low case частина CASE-технології);
В· репозиторій , своєрідна база даних для зберігання результатів роботи програмістів.
CASE-технологій успішно застосовуються для побудови практично усіх типів систем ПЗ, проте стійке положення вони займають у наступних областях:
1. Забезпечення розробки ділового та комерційного ПЗ. Широке застосування CASE технологій обумовлено масовістю цієї прикладної області, в якій CASE застосовується не тільки для розробки ПЗ, але і для створення моделей систем, що допомагають коммерческімім структурам вирішувати задачі стратегічного планування, управління фінансами, визначення політики фірм, навчання персоналу та ін (цей напрямок отримало свою власну назву бізнес-аналіз);
2. Розробка системного та керуючого ПО. Активне застосування CASE-технологій пов'язано з великою складністю даної проблематики і з прагненням підвищити ефективність робіт.
Різні статистичні огляди свідчать сьогодні про ефективність застосування CASE засобів в процесі розробки програмних систем. Однак відсоток невдач все ж існує і досить великий. Зрозуміло, існують свої недоліки застосування технологій, значимими є недоліки з боку аспектів бізнесу:
В· CASE-засоби не обов'язково дають негайний ефект; він може бути отриманий тільки через якийсь час;
В· реальні витрати на впровадження CASE-засобів звичайно набагато перевищують витрати на їх придбання;
В· CASE-засоби забезпечують можливості для одержання істотної вигоди тільки після успішного завершення процесу їх впровадження.
Зважаючи різноманітної природи CASE-засобів було б помилково робити які-небудь беззастережні твердження щодо реального задоволення тих чи інших очікувань від їх впровадження. Можна перерахувати такі чинники, ускладнюють визначення можливого ефекту від використання CASE-засобів:
В· широке розмаїтість якості і можливостей CASE-засобів;
В· щодо невеликий час використання CASE-засобів в різних організаціях і брак досвіду їх застосування;
В· широке різноманітність в практиці впровадження різних організацій;
В· відсутність детальних метрик і даних для вже виконаних і поточних проектів;
В· широкий діапазон предметних областей проектів;
В· різна ступінь інтеграції CASE-засобів в різних проектах.
На даний момент в технології розробки програмного забезпечення існують два основні підходи до розробки інформаційних систем, що відрізняються критеріями декомпозиції: функціонально-модульний (Структурний) і об'єктно-орієнтований.
Функціонально-модульний підхід заснований на принципі алгоритмічної декомпозиції з виділенням функціональних елементів і встановленням суворого порядку виконуваних дії. Головним недоліком функціонально-модульного підходу є одне спрямованість інформаційних потокової недостатня зворотний зв'язок. У випадку зміни вимозі до системи це приводить до повного перепроектування, тому помилки, закладені на ранніх етапах, сильно позначаються на тривалості і вартості розробки. Іншою важливою проблемою є неоднорідність інформаційних ресурсів, що використовуються в більшості інформаційних систем. У силу цих причин в даний час найбільше поширення набув об'єктно-орієнтований підхід, що пояснюється наступними причинами:
В· можливістю збірки програмної системи з готових компонентів, які можна використовувати повторно;
В· можливістю накопичення проектних рішень у вигляді бібліотек класів на основі механізмів спадкування;
В· простотою внесення змін в проекти за рахунок інкапсуляції даних в об'єктах;
В· швидкої адаптацією додатків до мінливих умов за рахунок використання властивостей успадкування та поліморфізму;
В· можливістю організації паралельної роботи аналітиків, проектувальників і програмістів.
Ідеальне об'єктно-орієнтоване САSЕ-засіб повинен містити чотири основні блоки: аналіз, проектування, розробка та інфраструктура.
Основні вимоги до блоку аналізу:
В· можливість вибору виведеної на екран інформації з усієї сукупності даних, що описують моделі;
В· узгодженість діаграм при зберіганні їх в репозитарії;
В· внесення коментарів в діаграми та відповідну документацію для фіксації проектних рішень;
В· можливість динамічного моделювання в термінах подій;
В· підтримка декількох нотацій (хоча б три нотації - м.Буча, І.Джекобсона і ОМТ).
Основні вимоги до блоку проектування:
В· підтримка всього процесу проектування додатку;
В· можливість роботи з бібліотеками, засобами пошуку та вибору;
В· можливість розробки користувальницького інтерфейсу;
В· підтримка стандартів ОLE, ActiveX і доступ до бібліотек HTML або Java;
В· підтримка розробки розподілених або двох-і триланкових клієнт-серверних систем (робота з CORBA, DCOM, Internet).
Основні вимоги до блоку реалізації:
В· генерація коду повністю з діаграм;
В· можливість доопрацювання додатків в клієнт-серверних САSЕ-засобах типу Power Builder;
В· реінжиніринг кодів і внесення відповідних змін у модель системи;
В· наявність засобів контролю, які дозволяють виявляти не відповідність між діаграмами та генерованими кодами і виявляти помилки як на стадії проектування, так і на стадії реалізації.
Основні вимоги до блоку інфраструктури:
В· наявність репозиторія на основі бази даних, що відповідає за генерацію коду, реінжиніринг, відображення коду на діаграмах, а також забезпечує відповідність між моделями і програмними кодами;
В· забезпечення командної роботи (багатокористувацької роботи та управління версіями) і реінжинірингу.
