Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

Безпека даних

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

Критерії відбору системи управління базами даних (СУБД)

Розвиток інформаційної системи зазвичай не вимагає розробки власної бази даних, оскільки легко використовувати існуюче ПЗ. Вибір СУБД не легкий. Багато аспектів розглядаються, наприклад, що база даних повинна бути реалізована однаково добре і у провайдера і на призначеній для користувача стороні.

Найважливіші критерії відбору СУБД:

· Продуктивність

Продуктивність описує швидкість реакції на запити і кількість обслуговуваних завдань.

· Масштабованість

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

· Функціональність

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

· Узгодження із стандартами

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

· Зручність і простота використання

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

· Надійність

Надійність позначає частоту відмов. Чим вище надійність - тим вище вартість.

Таким чином, повинно бути виконано балансування надійності (або потреба зупинки роботи) і витрат.

· Підтримка

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

· Середовище розробки

Середовище розробки описує, на яких апаратних засобах і програмному забезпеченні система працюватиме.

· Вартість

У вартість системи включені покупка, встановлення і експлуатація.

Реляційна база даних

Найзагальніші бази даних на ринку - реляційні бази даних.

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

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

На мал. 7.6.1. об'єктно-орієнтовану зразкову і реліционную модель показують для однієй системи. Об'єктно-орієнтована модель виразніша.

Малюнок 7.6.1. Неузгодженість об'єктно-орієнтованої зразкової і реліционной моделі.

Незручність в застосуванні реляційної моделі - також неузгодженість інтерфейсу доступу (наприклад, до SQL) і до мови програмування (наприклад, C++). Цю неузгодженість називають неузгодженістю імпедансу.

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

6. Оптимізація проекту

Буквальна і прямолінійна реалізація може призвести до дуже низької ефективності системи.

Причиною може бути швидкість виконання деяких функцій або пам'яті і дуже обширне використання пам'яті деякими системами.

У таких випадках слід зробити оптимізацію.

Для оптимізації роботи системи застосовуються наступні методи:

· використання статичних змінних замість динамічних,

· застосування вкладеного коду замість процедур, що викликаються,

· вибір типів з мінімальними величинами.

Ці методи можуть призвести до менш зрозумілого коду замість його оптимізації. Обробка помилок може стати складнішою або неможливою.

Кориснішим було б проведення оптимізації ще на етапі дизайну або навіть аналізу.

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

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

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

Оптимізація повинна бути пов'язана з аналізом буферизації в пам'яті і розглядом різних рівнів буферизації.

Обмеження середовища реалізації

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

Типовими обмеженнями в переході від аналітичної моделі до моделі дизайну є:

· відсутність множинного наслідування;

· відсутність наслідування;

· відсутність віртуальних методів;

· відсутність складних атрибутів;

· відсутність мультимедійних типів.

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

Малюнок 7.7.1. Приклад подолання множинного наслідування.

7. Фізична структура системи

Одним із завдань етапу дизайну - описати фізичну структуру системи.

Вона включає:

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

· Декомпозиція системи на конкретні програми.

· Фізичний розподіл даних і програм.

Малюнок 7.8.1. Позначення фізичної структури (Booch).

Малюнок 7.8.2. Графічний опис структури апаратури.

8. Правильність і якість проекту

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

Правильний проект повинен бути:

· завершеним;

· сумісним;

· узгодженим;

· повинна зберегтися семантика позначень.

Малюнок 7.9.1. Приклад компіляції в C++.

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

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

Правильність класу і діаграм станів

Всі діаграми проекту повинні бути веріфіковані.

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

· ациклічні відносини узагальнення-спеціалізації,

· варіанти відносин циклічного об'єднання,

· класи, що не мають відношення до інших класів, не повинні бути включені. Але іноді таке трапляється,

· введення в специфікацію методів, що мають відношення до вводу, виводу і специфікації результата.

Якість системи

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

Узгодженість

Узгодженість описує ступінь відповідності частин системи один одному і взаємини операцій. Критерії декомпозиції дуже важливі. Вони визначають вид узгодженості.

Критерії декомпозиції:

· Випадкова декомпозиція. Розділення на модулі відбувається із-за неможливості обхватити всю систему в різних завданнях.

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

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

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

· Функціональна декомпозиція. Всі компоненти потрібні для виконання однієї функції.

Рівні зв'язку між компонентами

У хорошому проекті зв'язки між компонентами повинні бути слабкі. Це визначає декомпозицію проекту на частини, а ПЗ - на модулі.

Малюнок 7.9.2. Рівні зв'язку між компонентами.

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

Прозорість

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

· Представлення реальності

Компоненти і їх зв'язки повинні представляти структуру системи. Тісні зв'язки проекту з реальністю дозволяє полегшити його розуміння і підтримку.

· Узгодженість і рівень зв'язків компонентів

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

· Зрозуміла термінологія

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

· Зрозуміла і повна специфікація

Специфікація повинна бути написана на зрозумілій користувачеві мові. Слід уникати професійного сленгу.

· Відповідна складність компонентів на кожному рівні.

Застосування наслідування і методів в класах спрощує розуміння проекту.

9. Нефункціональні вимоги на етапі проектування

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

Повинні бути враховані такі вимоги:

1. Вимоги до робочих характеристик.

2. Вимоги до інтерфейсу (протоколи, формати файлів).

3. Експлуатаційні вимоги.

4. Вимоги до ресурсів (число процесорів, об'єм вінчестера).

5. Контрольні вимоги.

6. Тестові вимоги.

7. Вимоги документування.

8. Вимоги безпеки.

9. Вимоги портативності.

10. Вимоги якості.

a. підбір методу проектування

b. можливість повторного використання

c. підбір інструментів

d. можливість зовнішнього доступу

11. Вимоги по надійності.

12. Інструкція по технічному обслуговуванню.

13. Можливість усунення відмов або несправностей.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Складена модель даних	\|	Детальний документ проекту

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.008 сек.