- •Міністерство освіти та науки України в.В. Литвин, н.Б. Шаховська Проектування інформаційних систем
- •Передмова наукового редактора серії підручників «комп’ютинґ»
- •1.1. Складність програмного забезпечення
- •1.2. Структура складних систем
- •1.2.1. Приклади складних систем
- •1.2.2. П'ять ознак складної системи
- •1.2.3. Організована і неорганізована складність
- •1.3. Методи подолання складності
- •1.3.1. Роль декомпозиції
- •1.3.3. Роль абстракції
- •1.3.4. Роль ієрархії
- •1.4. Про проектування складних систем
- •1.4.1. Інженерна справа як наука і мистецтво
- •1.4.2. Сенс проектування
- •4. Методи подолання складності.
- •2.1. Базові означення
- •2.2. Методи проектування інформаційних систем
- •2.3. Види інформаційних систем
- •2.4. Рівні моделей даних
- •3. Види інформаційних систем.
- •3.1. Методологія процедурно-орієнтованого програмування
- •3.2. Методологія об'єктно-орієнтованого програмування
- •3.3. Методологія об'єктно-орієнтованого аналізу і проектування
- •3.4. Методологія системного аналізу і системного моделювання
- •4.1. Передісторія. Математичні основи
- •4.1.1. Теорія множин
- •4.1.2. Теорія графів
- •4.1.3. Семантичні мережі
- •4.2. Діаграми структурного системного аналізу
- •4.3. Основні етапи розвитку uml
- •3. Семантичні мережі.
- •5.1. Принципи структурного підходу до проектування
- •5.2. Структурний аналіз
- •5.3. Структурне проектування
- •5.4. Методологія структурного аналізу
- •5.5. Інструментальні засоби структурного аналізу та проектування
- •6.1. Основні елементи
- •6.2. Типи зв’язків
- •6.3. Техніка побудови
- •6.4. Діаграма бізнес – функцій
- •6.4.1. Призначення діаграми бізнес-функцій
- •6.4.2. Основні елементи
- •7.1. Призначення діаграм потоків даних та основні елементи
- •7.1.1. Зовнішні сутності
- •7.1.2. Процеси
- •7.1.3. Накопичувачі даних
- •7.1.4. Потоки даних
- •7.2. Методологія побудови dfd.
- •8.1. Діаграма «сутність-зв’язок»
- •8.2. Діаграма атрибутів
- •8.3. Діаграма категоризації
- •8.4. Обмеження діаграм сутність-зв’язок
- •8.5. Методологія idef1
- •9.1. Основні елементи
- •9.2. Типи керуючих потоків
- •9.3. Принципи побудови
- •10.1. Структурні карти Константайна
- •10.2. Структурні карти Джексона
- •11.1. Призначення case-технологій
- •11.2. Інструментальний засіб bPwin
- •11.2.4. Інші діаграми bpWin
- •11.2.5. Моделі as is і to be
- •11.3.1. Основні властивості
- •11.3.2. Стандарт idef1x
- •11.4. Програмний засіб Visio
- •12.1. Системний аналіз області наукових досліджень
- •12.1.1. Аналіз предметної області
- •12.2. Системний аналіз біржі праці
- •12.2.1. Дерево цілей
- •12.2.2. Опис об’єктів предметної області
- •12.2.3. Концептуальна модель
- •14.1. Еволюція об'єктної моделі
- •14.1.1. Основні положення об'єктної моделі
- •14.2. Складові частини об'єктного підходу
- •14.2.1. Парадигми програмування
- •14.2.2. Абстрагування
- •14.2.3. Інкапсуляція
- •14.2.4. Модульність
- •14.2.5. Ієрархія
- •14.2.7. Паралелізм
- •14.2.8. Збереженість
- •14.3. Застосування об'єктної моделі
- •14.3.1. Переваги об'єктної моделі
- •14.3.2. Використання об'єктного підходу
- •14.3.3. Відкриті питання
- •15.1. Природа об'єкта
- •15.1.1. Що є й що не є об'єктом?
- •15.1.2. Стан
- •15.1.3. Поведінка
- •15.1.4. Ідентичність
- •Void drag(DisplayItem I); // Небезпечно
- •15.2. Відношення між об'єктами
- •15.2.1. Типи відношень
- •15.2.2. Зв'язки
- •15.2.3. Агрегація
- •15.3. Природа класів
- •15.3.1. Що таке клас?
- •15.3.2. Інтерфейс і реалізація
- •15.3.3. Життєвий цикл класу
- •15.4. Відношення між класами
- •15.4.1. Типи відношень
- •15.4.2. Асоціація
- •15.4.3. Успадкування
- •15.4.4. Агрегація
- •15.4.5. Використання
- •15.4.6. Інсталювання (Параметризація)
- •15.4.6. Метакласи
- •15.5. Взаємозв'язок класів і об'єктів
- •15.5.1. Відношення між класами й об'єктами
- •15.5.2. Роль класів і об'єктів в аналізі й проектуванні
- •16.1. Важливість правильної класифікації
- •16.1.1. Класифікація й об’єктно-орієнтовне проектування
- •16.1.2. Труднощі класифікації
- •16.2. Ідентифікація класів і об'єктів
- •16.2.1. Класичний і сучасний підходи
- •16.2.2. Об’єктно-орієнтований аналіз
- •16.3. Ключові абстракції й механізми
- •16.3.1. Ключові абстракції
- •16.3.2. Ідентифікація механізмів
- •17.1. Призначення мови uml
- •17.2. Загальна структура мови uml
- •17.3. Пакети в мові uml
- •17.4. Основні пакети мета-моделі мови uml
- •17.5. Специфіка опису мета-моделі мови uml
- •17.6. Особливості зображення діаграм мови uml
- •18.1. Варіант використання
- •18.2. Актори
- •18.3. Інтерфейси
- •18.4. Примітки
- •18.5. Відношення на діаграмі варіантів використання
- •18.5.1. Відношення асоціації
- •13.5.2. Відношення розширення
- •18.5.3. Відношення узагальнення
- •18.5.4. Відношення включення
- •18.6. Приклад побудови діаграми варіантів використання
- •18.7. Рекомендації з розроблення діаграм варіантів використання
- •19.1. Клас
- •19.1.1. Ім'я класу
- •19.1.2. Атрибути класу
- •19.1.3. Операція
- •19.2. Відношення між класами
- •19.2.1. Відношення залежності
- •19.2.2. Відношення асоціації
- •19.2.3. Відношення агрегації
- •19.2.4. Відношення композиції
- •19.2.5. Відношення узагальнення
- •19.3. Інтерфейси
- •19.5. Шаблони або параметризовані класи
- •19.6. Рекомендації з побудови діаграми класів
- •20.1. Автомати
- •20.2. Стан
- •20.2.1. Ім'я стану
- •20.2.2. Список внутрішніх дій
- •20.2.3. Початковий стан
- •20.2.4. Кінцевий стан
- •20.3. Перехід
- •20.3.2. Сторожова умова
- •20.3.3.Вираз дії
- •15.4. Складений стан і підстан
- •20.4.1. Послідовні підстани
- •20.4.2. Паралельні підстани
- •15.5. Історичний стан
- •20.6. Складні переходи
- •15.6.1. Переходи між паралельними станами
- •20.6.2. Переходи між складеними станами
- •20.6.3. Синхронізуючі стани
- •20.7. Рекомендації з побудови діаграм станів
- •21.1. Стан дії
- •21.2. Переходи
- •21.5. Рекомендації до побудови діаграм діяльності
- •22.1.1. Лінія життя об'єкта
- •22.1.2. Фокус керування
- •22.2. Повідомлення
- •22.2.1. Розгалуження потоку керування
- •22.2.2. Стереотипи повідомлень
- •22.2.3. Тимчасові обмеження на діаграмах послідовності
- •22.2.4. Коментарі або примітки
- •22.3. Приклад побудови діаграми послідовності
- •22.4. Рекомендації з побудови діаграм послідовності
- •23.1. Кооперація
- •23.2.1. Мультиоб'єкт
- •23.2.2. Активний об'єкт
- •23.2.3. Складений об'єкт
- •23.3. Зв'язки
- •23.3.1. Стереотипи зв'язків
- •23.4. Повідомлення
- •23.4.1. Формат запису повідомлень
- •23.5. Приклад побудови діаграми кооперації
- •23.6. Рекомендації з побудови діаграм кооперації
- •24.1. Компоненти
- •24.1.1. Ім'я компоненту
- •24.1.2. Види компонент
- •24.2. Інтерфейси
- •24.3. Залежності
- •24.4. Рекомендації з побудови діаграми компонент
- •25.1. Вузол
- •25.2. З'єднання
- •25.3. Рекомендації з побудови діаграми розгортання
- •26.1. Загальна характеристика case-засобу Rational Rose
- •26.2. Особливості робочого інтерфейсу Rational Rose
- •26.1.1. Головне меню програми
- •26.1.2. Стандартна панель інструментів
- •26.1.3. Вікно браузера
- •26.1.4. Спеціальна панель інструментів
- •26.1.5. Вікно діаграми
- •26.1.6. Вікно документації
- •26.1.7. Вікно журналу
- •26.3. Початок роботи над проектом у середовищі Rational Rose
- •26.4. Розроблення діаграми варіантів використання в середовищі Rational Rose
- •26.5. Розроблення діаграми класів у середовищі Rational Rose
- •26.6. Розроблення діаграми станів у середовищі Rational Rose
- •26.7. Розроблення діаграми послідовності в середовищі Rational Rose
- •26.8. Розроблення діаграми кооперації в середовищі Rational Rose
- •26.9. Розроблення діаграми компонентів у середовищі Rational Rose
- •26.10. Розроблення діаграми розгортання в середовищі Rational Rose
19.1.2. Атрибути класу
У другій зверху секції прямокутника класу записуються його атрибути (attributes) або властивості. У мові UML прийнята певна стандартизація запису атрибутів класу, яка підкоряється деяким синтаксичним правилам. Кожному атрибуту класу відповідає окремий рядок тексту, який складається з квантора видимості атрибуту, імені атрибуту, його кратності, типу значень атрибуту й, можливо, його початкового значення:
<квантор видимості><ім’я атрибуту>[кратність]:
<тип атрибуту> = <початкове значення>{рядок-властивість}
Квантор видимості може приймати одне з трьох можливих значень і, відповідно, відображається за допомогою спеціальних символів:
Символ "+" позначає атрибут із зоною видимості типу загальнодоступний (public). Атрибут із цією зоною видимості доступний або видимий з будь-якого іншого класу пакету, у якому визначена діаграма.
Символ "#" позначає атрибут із зоною видимості типу захищений (protected). Атрибут із цією зоною видимості недоступний або невидний для всіх класів, за винятком підкласів даного класу.
Символ "-" позначає атрибут із зоною видимості типу закритий (private). Атрибут із цією зоною видимості недоступний або невидний для всіх класів без виключення.
Квантор видимості може бути опущений. У цьому випадку його відсутність просто означає, що видимість атрибуту не вказується. Ця ситуація відрізняється від прийнятих за умовчанням угод у традиційних мовах програмування, коли відсутність квантора видимості трактується як public або private. Проте замість умовних графічних позначень можна записувати відповідне ключове слово: public, protected, private.
Примітка
Оскільки мова UML інваріантна щодо реалізації своїх конструкцій у конкретних мовах програмування, семантика окремих кванторів видимості не є строго фіксованою. Значення цих кванторів повинні додатково уточнюватися текстом пояснення на природній мові або угодою з використання відповідних програмно-залежних синтаксичних конструкцій.
Ім'я атрибуту є рядком тексту, який використовується як ідентифікатор відповідного атрибуту і тому має бути унікальним в межах даного класу. Ім'я атрибуту є єдиним обов'язковим елементом синтаксичного позначення атрибуту.
Кратність атрибуту характеризує загальна кількість конкретних атрибутів даного типу, що входять до складу окремого класу. У загальному випадку кратність записується у формі рядка тексту у квадратних дужках після імені відповідного атрибуту:
[нижня_границя1 .. верхня_границя1, нижня_границя2.. верхня_границя2 ..., нuжня_гpaнuцяk .. верхня_границяk],
де нижня_границя і верхня_границя є додатніми цілими числами, кожна пара яких служить для позначення окремого замкнутого інтервалу цілих чисел, у якого нижня (верхня) межа дорівнює значенню нижня_границя (верхня_границя). У цілому дане умовне позначення кратності відповідає теоретико-множинному об'єднанню відповідних інтервалів. Верхнею_границею може використовуватися спеціальний символ "*", який означає довільне позитивне ціле число. Іншими словами, це означає необмежене зверху значення кратності відповідного атрибуту.
Значення кратності з інтервалу слідують в монотонно зростаючому порядку без пропуску окремих чисел, що знаходяться між нижньою й верхньою межами. При цьому дотримуються наступного правила: відповідні нижні і верхні межі інтервалів включаються в значення кратності. Якщо кратність задається єдиним числом, то кратність атрибуту приймається рівною цьому числу. Якщо ж вказується єдиний знак "*", то це означає, що кратність атрибуту може бути довільним додатнім цілим числом або нулем.
Як приклад розглянемо наступні варіанти задання кратності атрибутів.
[0..1] означає, що кратність атрибуту може набувати значення 0 або 1. При цьому 0 означає відсутність значення для даного атрибуту.
[0..*] означає, що кратність атрибуту може набувати будь-якого додатного цілого значення більше-рівне 0. Ця кратність може бути записана коротше у вигляді простого символу - [*].
[1.:*] означає, що кратність атрибуту може набувати будь-якого додатного цілого значення більше-рівне 1.
[1..5] означає, що кратність атрибуту може набувати будь-якого значення з чисел: 1, 2, 3, 4, 5.
[1..3,5,7] означає, що кратність атрибуту може набувати будь-якого значення з чисел: 1, 2, 3, 5, 7.
[1..3,7.. 10] означає, що кратність атрибуту може набувати будь-якого значення із чисел: 1, 2, 3, 7, 8, 9, 10.
[1..3,7..*] означає, що кратність атрибуту може набувати будь-якого значення з чисел: 1, 2, 3, а також будь-яке ціле значення більше-рівне 7.
Якщо кратність атрибуту не вказана, то за замовчанням вона набуває значення рівне 1..1, тобто в точності 1.
Типом атрибуту є вираз, семантика якого визначається мовою специфікації відповідної моделі. У нотації UML тип атрибуту іноді визначається залежно від мови програмування, яку передбачається використовувати для реалізації даної моделі. У простому випадку тип атрибуту вказується рядком тексту, що має осмислене значення в межах пакету або моделі, до якої відноситься даний клас.
Можна навести наступні приклади задання імен і типів атрибутів класів:
колір:Соlоr – тут колір є іменем атрибуту, Color – іменем типу даного атрибуту. Вказаний запис може визначати традиційно використовувану RGB-модель (червоний, зелений, синій) для представлення кольору. В цьому випадку ім'я типу Color якраз і характеризує семантичну конструкцію, яка застосовується в більшості мов програмування для подання кольору.
ім’я_співробітника [1..2] : String – тут ім’я_співробітника є іменем атрибуту, який служить для подання інформації про ім'я конкретного співробітника. Тип атрибуту String (Рядок) вказує на той факт, що окреме значення імені є рядком тексту з одного або двох слів (наприклад, "Кирило" або "Дмитро Іванович"). Оскільки в багатьох мовах програмування існує тип даних String, використання відповідного англомовного терміну не викликає непорозуміння у більшості програмістів. Проте, хоча в мові UML всі терміни даються в англомовному поданні, використання як тип атрибуту Рядок в даній ситуації не виключається і визначається тільки міркуваннями зручності.
видимість:Boolean – тут видимість є іменем абстрактного атрибуту (курсив тут не випадковий), який може характеризувати наявність візуального представлення відповідного класу на екрані монітора. У цьому випадку тип Boolean означає, що можливими значеннями даного атрибуту є одне з двох логічних значень: істина (true) або хибно (false). При цьому значення істина може відповідати наявності графічного зображення на екрані монітора, а значення хибно – його відсутності, про що додатково вказується в тексті пояснення. Оскільки кратність атрибуту видимість не вказана, вона набуває значення 1 за замовченням. У цій ситуації англомовне ім'я типу атрибуту цілком виправдане наявністю відповідного базового типу в мовах програмування. Абстрактний характер такого атрибуту позначається курсивним текстом у записі даного атрибуту.
форма:Багатокутник – тут ім'я атрибуту форма може характеризувати такий клас, який є геометричною фігурою на площині. У цьому випадку тип атрибуту Багатокутник вказує на той факт, що окрема геометрична фігура може мати форму трикутника, прямокутника, ромба, п'ятикутника і будь-якого іншого багатокутника, але не кола чи еліпса. Цілком очевидно, що в даній ситуації використання відповідного англомовного терміну навряд чи доцільно, оскільки тип Багатокутник не є базовим для мов програмування.
Початкове значення служить для задання деякого початкового значення для відповідного атрибуту в момент створення окремого екземпляра класу. Тут необхідно дотримуватися правила приналежності значення типу конкретного атрибуту. Якщо початкове значення не вказане, то значення відповідного атрибуту не визначене на момент створення нового екземпляра класу. З іншого боку, конструктор відповідного об'єкту може перевизначити початкове значення в процесі виконання програми, якщо в цьому виникає необхідність.
Як приклади початкових значень атрибутів можна навести наступні доповнені вище варіанти визначення атрибутів:
колір:Соlоr = (255, 0, 0) – в RGB-моделі кольору це відповідає чистому червоному кольору як початкове значення для даного атрибуту.
ім’я_співробітника[1..2]:String = Іван Іванович – можливо, це нетиповий випадок, який, швидше, відповідає ситуації ім’я_керівника [2]: String = Іван Іванович.
видимість:Вооlеаn = істина – може відповідати ситуації, коли в момент створення екземпляру класу створюється видиме на екрані монітора вікно, що відповідає цьому об'єкту.
форма:Багатокутник= прямокутник – навряд чи вимагає коментарів, оскільки тут мова йде про геометричну форму створюваного об'єкту.
При визначенні атрибутів можуть бути використані дві додаткові синтаксичні конструкції – це підкреслення рядка атрибуту й текст пояснення у фігурних дужках.
Підкреслення рядка атрибуту означає, що відповідний атрибут може приймати підмножину значень з деякої області значень атрибуту, визначеної його типом. Ці значення можна розглядати як набір однотипних записів або масив, які в сукупності характеризують кожний об'єкт класу.
Наприклад, якщо деякий атрибут заданий у вигляді форма: Прямокутник, то це означатиме, що всі об'єкти цього класу можуть мати декілька різних форм, кожна з яких є прямокутником. Іншим прикладом може служити визначення атрибуту у вигляді номер_рахунку:Integer, що може означати для об'єкту Співробітник наявність деякої підмножини рахунків, загальна кількість яких заздалегідь не фіксується.
Рядок-властивість служить для вказівки значень атрибуту, які не можуть бути змінені в програмі під час роботи з цим типом об'єктів. Фігурні дужки якраз і позначають фіксоване значення відповідного атрибуту для класу в цілому, яке повинні приймати всі новостворювані екземпляри класу без виключення. Це значення береться за початкове значення атрибуту, яке не може бути перевизначене в подальшому. Відсутність рядка-властивості за замовченням трактується так, що значення відповідного атрибуту може бути змінене в програмі. Наприклад, рядок-властивість в записі атрибуту заробітна_зарплата:Currency={$500} може служити для позначення фіксованої заробітної плати для кожного об'єкту класу "Співробітник" певної посади в деякій організації. З іншого боку, запис даного атрибуту у вигляді заробітна_зарплата: Currency = $500 означає щось інше, а саме – при створенні нового екземпляра Співробітник (аналогія – прийом на роботу нового співробітника) для нього встановлюється за замовченням заробітна плата в $500. Проте для окремих співробітників можуть бути зроблені виключення як в одну, так і в іншу сторону, про що необхідно додатково передбачити в програмі.