- •Поняття технології конструювання програмного забезпечення.
- •Класичний життєвий цикл.
- •Макетування.
- •Характеристика стратегій конструювання пз.
- •Інкрементна модель.
- •Спіральна модель.
- •Важковагові та полегшені процеси. Xp – процес.
- •Швидка розробка додатків, rad.
- •Компонентно-орієнтована модель. Моделі якості процесів конструювання.
- •Сторони зацікавлені в продукції.
- •Користувачі. Покупці. Інвестори.
- •Вимоги до пз кожної з сторін.
- •Атрибути якості пз: практичність, відмовостійкість, надійність, ремонтопридатність.
- •Визначення архітектури пз.
- •Опис архітектури пз.
- •Універсальна мова моделювання (uml).
- •Інші базові засоби для створення архітектури.
- •Основні компоненти мови. Призначення мови. Термінологія uml.
- •Процес керування проектом. Планування.
- •Планування проектних задач.
- •Розмірно-орієнтовані метрики.
- •Функціонально-орієнтовані метрики.
- •Виконання оцінки проекту на основі loc- та fp-метрик.
- •Дослідження під моделей моделі cocomo, cocomo II.
- •Конструктивна модель вартості.
- •Модель композиції додатку.
- •Модель раннього етапу проектування.
- •Модель етапу пост архітектури.
- •Структурний аналіз.
- •Основи проектування програмних систем.
- •Класичні методи проектування.
- •Основні поняття та принципи тестування пз.
- •Особливості тестування «білого ящику».
- •Способи тестування базового шляху.
- •Способи тестування умов.
- •Спосіб тестування потоків даних.
- •Тестування циклів.
- •Особливості тестування «чорного ящику».
- •Спосіб розбиття по еквівалентності.
- •Спосіб аналізу граничних значень.
- •Спосіб діаграм причин-наслідків.
- •Дослідження способів структурного та функціонального тестування на прикладах.
- •Методика тестування програмних систем.
- •Тестування правильності.
- •Системне тестування .
- •Мистецтво налагоджування.
- •Основні принципи об’єктна-орієнтованої методології розробки програмної системи (оом пс).
- •Оо Аналіз.
- •Об’єкти та класи.
- •Діаграми в uml.
- •Механізми розширення в uml.
- •Діаграма варіантів використання.
- •Дослідження діаграми варіантів використання.
- •Діаграма класів.
- •2. Асоціації:
- •Дослідження діаграми класів.
- •Діаграма станів.
- •Дослідження діаграми станів.
- •Діаграма діяльності.
- •Дослідження діаграми діяльності.
- •Діаграма послідовності.
- •Дослідження діаграми послідовності.
- •Діаграма кооперації.
- •Дослідження діаграми кооперації.
- •Діаграма компонентів.
- •Дослідження діаграми компонентів.
- •Діаграма розгортування.
- •Дослідження діаграми розгортування.
- •Загальні відомості case-засобів.
- •Case-засоби. Класифікація case-засобів.
- •Порівняння життєвого циклу програмного забезпечення при традиційній розробці і розробці з використанням case-засобів.
- •Концептуальні основи case-технології.
- •Технологія впровадження –засобів.
- •Оцінка і вибір –засобів.
- •Засоби функціонального моделювання.
- •Характеристики case–засобів Silverrun.
- •Характеристики case–засобів jam.
- •Загальна характеристика case-системи Rational Rose.
- •Розробка діаграм у середовищі Rational Rose.
- •Початок роботи над проектом у середовищі Rational Rose.
Оцінка і вибір –засобів.
Розглянемо модель процесу оцінки і вибору, яка описує найбільш загальну ситуацію оцінки і вибору, а також показує залежність між ними. Оцінка і вибір можуть виконуватися незалежно один від одного або разом, кожен з цих процесів вимагає застосування певних критеріїв.
Процес оцінки і вибору може переслідувати декілька цілей:
- оцінка декількох CASE-засобів і вибір одного чи декількох з них;
- оцінка одного чи декількох з CASE-засобів і збереження результатів для подальшого використання;
- вибір одного чи декількох з CASE-засобів з використанням результатів попередніх оцінок.
Вхідною інформацією для процесу оцінки є:
- визначення потреб користувача;
- цілі і обмеження проекту;
- дані про доступні CASE-засоби;
- список критеріїв, що використовуються в процесі оцінки.
Результати оцінки можуть включати результати попередніх оцінок. При цьому не треба забувати, що набір критеріїв, які використовувалися для попередньої оцінки, повинні бути сумісними з поточним набором. Конкретний варіант реалізації процесу (оцінка і вибір, оцінка для майбутнього вибору або вибір, що базується на попередніх оцінках) визначається перерахованими вище цілями.
Засоби функціонального моделювання.
Для рішення задачі функціонального моделювання на базі структурного аналізу традиційно застосовуються два типи моделей: SADT-діаграми і діаграми потоків даних.
DFD - показують зовнішні джерела і стоки даних, визначають процеси обробки і потоки даних, ідентифікують сховища даних (накопичувачі). Структура потоків даних зберігається в Словнику даних. Будь-яка DFD може бути деталізована DFD нижнього рівня і т.д. поки не досягнена доцільна деталізація. У випадку наявності в модельованій системі програмної/програмувальної частини (тобто практично завжди) перевага, як правило, віддається DFD по наступним розуміннях.
1) DFD із самого початку створювалися як засіб проектування програмних систем (тоді як SADT - як засіб проектування систем узагалі) і мають більш багатий набір елементів, що адекватно відбивають їхню специфіку (наприклад, сховища даних є прообразами файлів чи баз даних).
2) Наявність міні-специфікацій DFD-процесів нижнього рівня дозволяє перебороти логічну незавершеність SADT (а саме обрив моделі на деякому досить низькому рівні, коли подальша її деталізація стає безглуздою) і побудувати повну функціональну специфікацію розроблювальної системи.
3) Існують (і підтримуються поруч CASE-пакетів) алгоритми автоматичного перетворення ієрархії DFD у структурні карти, що демонструють міжмодульні і внутрімодульні зв'язки, а також ієрархію модулів, що в сукупності з міні-специфікаціями є завершеним завданням для програміста.
Нарешті, у частині автоматизованої підтримки моделей приблизно 85-90% існуючих CASE-пакетів підтримують DFD і лише 2-3% - SADT.
Характеристики case–засобів Silverrun.
CASE-засіб Silverrun американської фірми Сomputer Systems Advisers, Inc. (CSA) використовується для аналізу і проектування ІС бізнес-класу [22] і орієнтоване більшою мірою на спіральну модель ЖЦ. Воно застосовно для підтримки будь-якої методології, заснованої на роздільному побудові функціональної та інформаційної моделей (діаграм потоків даних і діаграм "сутність-зв'язок").
Структура та функції
Silverrun має модульну структуру і складається з чотирьох модулів, кожен з яких є самостійним продуктом і може набуватися і використовуватися без зв'язку з іншими модулями.
Модуль побудови моделей бізнес-процесів у формі діаграм потоків даних (BPM - Business Process Modeler) дозволяє моделювати функціонування обстежуваної організації або створюваної ІВ. У модулі BPM забезпечена можливість роботи з моделями великої складності: автоматична перенумерация, робота з деревом процесів (включаючи візуальне перетягування гілок), від'єднання і приєднання частин моделі для колективної розробки.
Модуль концептуального моделювання даних (ERX - Entity-Relationship eXpert) забезпечує побудова моделей даних "сутність-зв'язок» , не прив'язаних до конкретної реалізації.
Модуль реляційного моделювання (RDM - Relational Data Modeler) дозволяє створювати деталізовані моделі "сутність-зв'язок", призначені для реалізації в реляційної базі даних.