21295

Мета та завдання дисципліни

Лекция

Информатика, кибернетика и программирование

CASEтехнологія являє собою методологію проектування ІС а також набір інструментальних засобів що дозволяють в наочній формі моделювати предметну область аналізувати цю модель на всіх етапах розробки і супроводу ІС і розробляти програми відповідно до інформаційними потребами користувачів. Поняття моделі та моделювання Модель це об'єкт або опис об'єкта системи для заміщення однієї системи оригіналу іншою системою для кращого вивчення оригіналу або відтворення будьяких його властивостей. Слово модель лат. При моделюванні...

Украинкский

2013-08-02

88.5 KB

3 чел.

Лекція 1. Мета та завдання дисципліни

Введення в предметну область

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

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

  Для успішної реалізації проекту об'єкт проектування (ІС) повинен бути, перш за все, адекватно описаний, повинні бути побудовані повні і несуперечливі функціональні та інформаційні моделі ІС.

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

  У 70-х і 80-х роках при проектуванні ІС була розроблена і почала застосовуватися структурна методологія, що надає в розпорядження розробників строгі формалізовані методи опису ІС і прийнятих технічних рішень. Дана методологія заснована на наочній графічній техніці: для опису різного роду моделей ІС використовуються схеми та діаграми. Наочність і строгість коштів структурного аналізу дозволила розробникам і майбутнім користувачам системи з самого початку неформально брати участь у її створенні, обговорювати і закріплювати розуміння основних технічних рішень. Однак, широке застосування цієї методології і дотримання її рекомендаціям при розробці конкретних ІС зустрічалося досить рідко, оскільки при неавтоматизованої (ручний) розробці це практично неможливо.

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

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

  З іншого боку, розробники ІС історично завжди стояли останніми в ряду тих, хто використовував інформаційні технології для підвищення якості, надійності та продуктивності у своїй власній роботі (так званий феномен «шевця без чобіт»).

  Перераховані фактори сприяли появі програмно-технологічних засобів спеціального класу - CASE-засобів, що реалізують CASE-технологію моделювання та проектування ІС. Термін CASE (Computer Aided Software Engineering [КОМП'ЮТЕР ЕЙДІД СОФТВЕА Інженіринг] - програмна інженерія з комп'ютерною підтримкою) використовується в даний час у дуже широкому сенсі. Первинне значення терміна CASE, обмежене питаннями автоматизації розробки тільки лише програмного забезпечення (ПО), в даний час набуло нового змісту, що охоплює процес розробки складних ІС у цілому. Тепер під терміном CASE-засоби розуміються програмні засоби, що підтримують процеси створення і супроводу ІС, включаючи аналіз і формулювання вимог, моделювання прикладного ПЗ (додатків) і баз даних, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління і управління проектом, а також інші процеси. CASE-засоби разом із системним ПЗ і технічними засобами утворюють повну середовище розробки ІС.

  Появі CASE-технології та CASE-засобів передували дослідження в області методології програмування. Програмування знайшло риси системного підходу з розробкою і впровадженням мов високого рівня, методів структурного і модульного програмування, мов проектування і засобів їх підтримки, формальних і неформальних мов описів системних вимог і специфікацій і т.д. Крім того, появі CASE-технології сприяли і такі фактори, як:

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

  CASE-технологія являє собою методологію проектування ІС, а також набір інструментальних засобів, що дозволяють в наочній формі моделювати предметну область, аналізувати цю модель на всіх етапах розробки і супроводу ІС і розробляти програми відповідно до інформаційними потребами користувачів. Більшість існуючих CASE-засобів засновано на методологіях структурного або об'єктно-орієнтованого аналізу і проектування, що використовують специфікації у вигляді діаграм або текстів для опису зовнішніх вимог, зв'язків між моделями системи, динаміки поводження системи та архітектури програмних засобів.

  Успішне впровадження CASE-засобів повинно забезпечити такі вигоди як:

• високий рівень технологічної підтримки процесів розробки та супроводу ПО;
• позитивний вплив на деякі або всі з перерахованих факторів: продуктивність, якість продукції, дотримання стандартів, документування;
• прийнятний рівень віддачі від інвестицій в CASE-засоби.

Поняття моделі та моделювання

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

  Побудова моделі - системна задача, що вимагає аналізу та синтезу вихідних даних, гіпотез, теорій, знань фахівців.

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

  При моделюванні більшості систем абсолютна подібність неможливо, і основна мета моделювання - модель досить добре повинна відображати функціонування модельованої системи.

  Проблема моделювання складається з трьох завдань:

  •  побудова моделі;
  •  дослідження моделі;
  •  використання моделі.

  Класифікацію моделей проводять за різними критеріями.

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

  Як правило модель включає в себе: об'єкт О, суб'єкт (не обов'язковий) А, завдання Z, ресурси B, середу моделювання С.

  Модель можна уявити формально у вигляді: М = < O, Z, A, B, C >.

  Основні властивості будь-якої моделі:

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

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

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

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

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

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

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

Особливості та проблеми проектування складних інформаційних систем

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

  До теперішнього часу створення таких систем нерідко виконувалося на інтуїтивному рівні із застосуванням неформалізованих методів, заснованих на практичному досвіді, експертних оцінках і дорогих експериментальних перевірках якості функціонування ПЗ. За даними Інституту програмна інженерія (США) до 2000 року близько 80% всього експлуатованого програмного забезпечення розроблялося взагалі без використання будь-яких дисципліни проектування, методом «code and fix» [КОД ЕНД ФІКС] (кодування і виправлення помилок).

  Проблеми розробки складних програмних комплексів випливають з його властивостей. Ще в 1975 р. Фредерік Брукс (найвідоміший американський вчений у галузі теорії обчислювальних систем), проаналізувавши свій унікальний на ті часи досвід керівництва найбільшим проектом розробки операційної системи OS/360 для компанії IBM, визначив перелік невід'ємних властивостей ПЗ: складність, узгодженість, змінність і незрима.

  Що ж стосується сучасних великомасштабних проектів ПЗ, то вони характеризуються, як правило, наступними особливостями:

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

  Наприкінці 60-х років минулого століття в США було відмічено явище під назвою «software crisis» [СОФВЕА КРИЗА] (криза програмного забезпечення). Це виражалося в тому, що великі проекти стали виконуватися з відставанням від графіка або з перевищенням кошторису витрат, розроблений продукт не володів необхідними функціональними можливостями, продуктивність його була низька, якість одержуваного програмного забезпечення не влаштовувало споживачів.

  Аналітичні дослідження та огляди, що виконуються протягом ряду останніх років провідними зарубіжними аналітиками, показували не дуже обнадійливі результати. Так, наприклад, результати досліджень, виконаних у 2007 році компанією Standish Group, яка проаналізувала роботу 364 американських корпорацій та підсумки виконання понад 23 тисяч проектів, пов'язаних з розробкою ПЗ, виглядали наступним чином:

  •  тільки 16,2% завершилися в термін, не перевищили запланований бюджет і реалізували всі необхідні функції і можливості;
  •  52,7% проектів завершилися з запізненням, витрати перевищили запланований бюджет, необхідні функції не були реалізовані у повному обсязі;
  •  31,1% проектів були анульовані до завершення;
  •  для двох останніх категорій проектів бюджет середнього проекту виявився перевищеним на 89%, а термін виконання - на 122%.

  У 2008 році процентне співвідношення трьох перерахованих категорій проектів лише трохи змінилося в кращу сторону (26%, 46% і 28% відповідно).

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

  У числі основних причин можливих невдач, на думку аналітиків, фігурують:

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

  Об'єктивна потреба контролювати процес розробки складних інформаційних систем, прогнозувати і гарантувати вартість розробки, терміни і якість результатів привела в кінці 60-х років минулого століття до необхідності переходу від кустарних до індустріальних способів створення ПЗ і появі сукупності інженерних методів і засобів створення ПЗ, об'єднаних спільним назвою «програмна інженерія» (software engineering).

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

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

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

  Одна з причин поширеності «хаотичного» процесу створення ПЗ - прагнення заощадити на стадії розробки, не витрачаючи часу і коштів на навчання розробників та впровадження технологічного процесу створення ПЗ. Основна причина складності впровадження - в «тяжкості» технологічних процесів. «Важкий» процес володіє наступними особливостями:

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

  Альтернативою «важкого» процесу є адаптивний (гнучкий) процес, заснований на принципах «швидкої розробки ПЗ», яка інтенсивно розвивається в останнє десятиліття.


 

А также другие работы, которые могут Вас заинтересовать

85475. «Ми творці життя – батьки і діти, невмирущий, мужній родовід» – до дня української родини 61.5 KB
  Мета: Формувати у студентів родинні почуття, прищепити відчуття приналежності до народу з міцним родовим корінням, багатими традиціями, звичаями; прослухати поезії та пісні про сенс людського життя, навчити студентів розуміти і збагачувати рідну мову; розвивати творчі здібності, активність, мислення...
85476. Здорова сім’я – здорова держава (родинне свято у 1 класі) 2.65 MB
  Мета: Вчити дітей здорового способу життя. Формувати навички доброзичливого спілкування з людьми. Виховувати потребу займатися фізкультурою і спортом заради зміцнення здоров’я. Свято проходить у спортивному залі. По обидва боки від плаката - українські народні загадки, приказки...
85477. Сценарій родинного свята «Щастя бути разом» 74.5 KB
  Прекрасно, коли в сім’ї панують мир і злагода, взаєморозуміння, повага, кохання, вірність, теплота, затишок. Через сім’ю ми – діти, виходимо в суспільство. В сім’ї нам вручають естафету досвіду поколінь, котру ми повинні нести далі, щоб передати її своїм дітям і тим самим майбутньому.
85478. Батько і мати 47.5 KB
  Є скарби, заховані в землю, є такі, що розташовані на поверхні і передаються з покоління в покоління. чаруючи людську душу. До таких скарбів належать пам’ять роду, його звичаї, традиції. Мамина пісня, батьківська хата, бабусина вишиванка, дідусева казка - все це наша родослівна пам’ять.
85479. ДОЛЯ МОЄЇ РОДИНИ В ДОЛІ УКРАЇНИ 80 KB
  Формувати уявлення про родину як частину суспільства, про роль і місце родини в житті людини, дослідити минуле своїх родин, пов’язане з історією України; виховувати шанобливе ставлення до батьків, старших і молодших членів сім’ї, розвивати навички спілкування в сім’ї, що сприяють родоводу...
85480. Творчість Г.С.Сковороди 30.5 KB
  Вчитель: Добру справу завжди починають рукостисканням яке означає взаємоповагу довіру готовність спільно плідно працювати. Вчитель: Активізуємо наші знання про діалог. Що таке діалог Що повинні памятати під час складання діалогу Вчитель: Перед вами конверти в них завдання: група отримала тему треба...
85481. Урок-путешествие по чтению «Сказки А.С.Пушкина» 47.5 KB
  А для кого они Для вас Мы знаем вы любите игры Песни загадки и пляски Но нет интересней для детворы Чем наши волшебные сказки. На какие две группы делятся все известные вам сказки Сказки бывают народные а бывают авторские Чем авторская сказка отличается от народной Авторы народных сказок...
85482. Ю.Збанацький «Гвардії Савочка» 1.7 MB
  Вчити учнів виразно читати та розуміти текст, навчати добору робочого матеріалу до роботи над текстом, розвивати читацькі інтереси учнів, навички стислого переказу, увагу, мовлення. Збагатити знання учнів про мужність народу в роки Великої Вітчизняної війни, участь у ній дітей, виховувати глибоку вдячність...
85483. Особенности развития мышления у подростков в условиях раннего выбора профильного обучения 1.48 MB
  В то же время повсеместное внедрение профильного обучения осуществляется на основе имеющихся образовательных ресурсов учебных заведений, которые далеко не всегда отвечают задачам модернизации образования – в этом случае может происходить простое натаскивание учащихся тем же педагогом за счет увеличения количества часов.