2012_Посібник_з_дисципліни_ТКП. Кафедра автоматизованих систем обробки інформації І управління посібник з дисципліни
 Скачать 3.1 Mb.
|
|
Алгоритм виділення ЕВР: 1. Визначте рамки системи. 2. Ідентифікуйте основних виконавців. 3. Для кожного виконавця визначте його завдання. Складіть ієрархію відповідно до рекомендацій по виділенню ЕВР. 4. Визначте прецеденти, що задовольняють потреби кожного виконавця, і надайте їм імена відповідно до завдань. 5. Питання, що задаються при визначенні виконавців: а. Хто запускає і вимикає систему? б. Хто є системним адміністратором? в. Хто здійснює управління користувачами і безпекою? г. Чи відноситься час до числа виконавців, іншими словами, чи повинна система виконувати будь-які дії у відповідь на події часу? д. Хто контролює діяльність і продуктивність системи, оновлення ПЗ, аналіз ... Таблиця 2.2 - Приклад визначення завдань Виконавець Завдання Касир Оформляє продаж Оформляє кредити Виконує повернення товару Реєструє виручку Системний адміністратор Додає користувачів Змінює параметри користувачів Видаляє користувачів Управляє безпекою Управляє системними таблицями Стилі опису прецедентів Базовий. Передбачає виклад на рівні намірів користувача та обов'язків системи, а не на рівні їхніх конкретних дій. При такому стилі опису не потрібно заглиблюватися в деталі технології і механізму реалізації, особливо при розгляді питань, пов'язаних з інтерфейсом користувача. Конкретний. При такому стилі опису проектні рішення, пов'язані з інтерфейсу. У тексті опису можуть, наприклад, навіть міститися копії екранів, описуватися елементи управління та інші елементи призначеного для користувача інтерфейсу. Ступінь формалізації опису прецедентів Стиснутий - анотація у вигляді одного абзацу. Зазвичай вона описує тільки головний успішний сценарій. Вільний - неформальний стиль опису. Опис прецеденту займає кілька абзаців і охоплює різні сценарії. Розгорнутий - найбільш детальний стиль опису. При такому підході детально описуються всі кроки і варіанти розвитку сценарію, а також передумови і результати. 33 Передумови і постумови Передумови (preconditions) - це перелік передумов, які завжди повинні виконуватися до початку сценарію прецеденту. Постумови (postconditions). Описують, які умови обов'язково повинні виконуватися в разі успішного завершення сценарію. Методи опису прецедентів а. В одну колонку. б. У кілька колонок. Підхід «під управлінням прецедентів» (use-case driven development) Вимоги в основному формулюються при описі прецедентів. Прецеденти - важливий етап ітеративного планування. На кожній ітерації реалізуються деякі сценарії або цілі прецеденти. Описи прецедентів вносять істотний внесок в оцінювання результату. Розробка програми полягає в реалізації прецедентів. Тобто група розробників продумує способи взаємодії об'єктів або архітектуру підсистем для реалізації прецедентів. Діаграми послідовності Для певного сценарію прецеденту показує генеруються зовнішніми виконавцями події, їх порядок, а також події, що генеруються всередині самої системи. При цьому всі системи розглядаються як "чорний ящик". Призначення даної діаграми - відображення подій, що передаються виконавцями системі через її кордони. Сценарій прецеденту - це його окремий випадок чи реальний шлях його реалізації. Діаграма послідовності будується на підставі опису прецеденту 34 SequenceDiagram_1 Видача карточку клієнту Видача чека Вибір операції "Видача чека" Запит на видачу чека Запит на видачу чека Видача готівки(100грн) Зняття суми з рахунку(100грн) Перевірка суми (100грн) Зняття грошей з рахунку (100грн) Введення суми (100грн) Запит про суму зняття грошей Вибір операції зняття грошей() Запит на проведення операції Перевірка PIN-коду Відкриття рахунку Введення PIN-коду Запит PIN-коду Ініціалізація екрана Читанння інформації про карточку Отримання карточки пристроєм Клієнт Пристрій зчитування карточки з банкомату Екран банкомату Рахунок клієнта Касовий апарат Видача карточку клієнту Видача чека Вибір операції "Видача чека" Запит на видачу чека Запит на видачу чека Видача готівки(100грн) Зняття суми з рахунку(100грн) Перевірка суми (100грн) Зняття грошей з рахунку (100грн) Введення суми (100грн) Запит про суму зняття грошей Вибір операції зняття грошей() Запит на проведення операції Перевірка PIN-коду Відкриття рахунку Введення PIN-коду Запит PIN-коду Ініціалізація екрана Читанння інформації про карточку Отримання карточки пристроєм Рисунок 2.2 – Приклад діаграми послідовності Питання для самоперевірки 1. Опишіть прецеденти типу «чорний ящик». 2. Алгоритми виділення елементарних бізнес-процесів (ЕВР). 3. Що таке передумова та постумова ? 4. З якою метою здійснюють перелік передумов та постумов? 5. Яке основне призначення діаграми послідовності ? Література: [2, с.73-97]; Завдання на СРС: [3, с. 183-195]. 35 2.2 Діаграми послідовності. Діаграми комунікації. Структура теми : – Діаграми послідовності. – Діаграми комунікації. Діаграма послідовності SequenceDiagram_1 Видача карточку клієнту Видача чека Вибір операції "Видача чека" Запит на видачу чека Запит на видачу чека Видача готівки(100грн) Зняття суми з рахунку(100грн) Перевірка суми (100грн) Зняття грошей з рахунку (100грн) Введення суми (100грн) Запит про суму зняття грошей Вибір операції зняття грошей() Запит на проведення операції Перевірка PIN-коду Відкриття рахунку Введення PIN-коду Запит PIN-коду Ініціалізація екрана Читанння інформації про карточку Отримання карточки пристроєм Клієнт Пристрій зчитування карточки з банкомату Екран банкомату Рахунок клієнта Касовий апарат Видача карточку клієнту Видача чека Вибір операції "Видача чека" Запит на видачу чека Запит на видачу чека Видача готівки(100грн) Зняття суми з рахунку(100грн) Перевірка суми (100грн) Зняття грошей з рахунку (100грн) Введення суми (100грн) Запит про суму зняття грошей Вибір операції зняття грошей() Запит на проведення операції Перевірка PIN-коду Відкриття рахунку Введення PIN-коду Запит PIN-коду Ініціалізація екрана Читанння інформації про карточку Отримання карточки пристроєм Рисунок 2.3 - Приклад діаграми послідовності Діаграми комунікації. Діаграми комунікацій (до UML 1.4 називалася Collaboration diagrams - діаграма кооперації) акцентує увагу на організації об'єктів, що приймають участь у взаємодії. 36 Рисунок 2.4 - Діаграми послідовності Рисунок 2.5 - Діаграма комунікації Відмінності від діаграми послідовності: Перше - це показ шляху. Для опису зв'язку одного об'єкта з іншим є можливість приєднати стереотип шляху. Порядковий номер повідомлення. Для позначення вкладеності використовується десяткова нотація Дьюї: Нотація Дьюї: 1 - перше повідомлення; 1.1 - перше повідомлення, вкладене в повідомлення 1; 1.2-друге повідомлення, вкладене в повідомлення 1 і т.д.). Рівень вкладеності не обмежений. Для кожного зв'язку можна показати кілька повідомлень (ймовірно, що посилаються різними відправниками), і кожне з них повинно мати унікальний порядковий номер. 37 Рисунок 2.6 - Діаграма комунікації Рисунок 2.7 - Діаграма послідовності 38 Рисунок 2.8 - Елементи діаграми комунікації у CASE засобі Enterprise Architect Питання для самоперевірки 1. Які основні елементи діаграми послідовності ? 2. Які основні елементи діаграми комунікації? 3. Що спільного між діаграмою послідовності та комунікації? 4. Які основні відмінності між діаграмою послідовності та діаграмою комунікації? Література: [2, с.98-146]; [3, с.194-231]; Література на СРС: [9, с. 262-299]. 39 2.3 Модель предметної області Структура теми : – Представлення моделі предметної області. – Концептуальні класи. – Стратегії ідентифікації концептуальних класів Представлення моделі предметної області Основна ідея моделі предметної області: 1. Модель предметної області являє класи понять реального світу, а не програмні компоненти. 2. Це не набір діаграм, що описують програмні класи або програмні об'єкти з їх обов'язками 3. Модель предметної області - це візуальне подання концептуальних класів або об'єктів реального світу в термінах предметної області. 4. Такі моделі називають також концептуальними моделями об'єктів предметної області або об'єктними моделями аналізу Мовою UML модель предметної області представляється у вигляді набору діаграм класів, на яких не визначені жодні операції. Модель предметної області може відображати наступне: 1. Об'єкти предметної області або концептуальні класи. 2. Асоціацію між концептуальними класами. 3. Атрибути концептуальних класів. Рисунок 2.9 - Модель предметної області Модель предметної області ілюструє концептуальні класи або словник предметної області. 40 Неформально, концептуальний клас - це уявлення ідеї або об'єкта. Якщо говорити більш строго, то концептуальний клас можна розглядати в термінах символів, змісту та розширення. Символи (symbol) - слова або образи, що представляють концептуальний клас. Зміст (intension) - визначення концептуального класу. Розширення (extension) - набір прикладів, до яких застосовується концептуальний клас. Рисунок 2.10 - Елементи концептуальних класів Моделі предметної області та декомпозиція Програмні системи можуть бути дуже складними, тому декомпозиція (за принципом ''розділяй і володарюй ") - це загальна стратегія боротьби зі складністю проблеми за рахунок її поділу на дрібні складові частини. Знову про відмінність від структурного підходу При структурному підході до проектування систем завдання розбивається на процеси або функції. При об'єктно-орієнтованому - на основні поняття або сутності предметної області. Не слід виключати з розгляду концептуальні класи тільки на тій підставі, що з аналізу вимог не слід очевидна необхідність їх запам'ятовування. Цей критерій часто застосовується при розробці реляційних баз даних, проте не годиться для створення моделей предметної області) або концептуальний клас не має атрибутів. 41 Концептуальні класи без атрибутів цілком припустимі, як припустимі і концептуальні класи, що грають «поведінкову», а не інформаційну роль в предметної області. Стратегії ідентифікації концептуальних класів Два способи виявлення концептуальних класів: 1. З використанням списку категорій концептуальних класів. 2. На основі виділення іменників. Для моделювання предметної області застосовується і інший чудовий прийом - шаблони аналізу. Шаблони - це готові моделі предметної області, створені фахівцями. Таблиця 2.3 - Використання списку категорій концептуальних класів Категорія концептуальних класів Приклади Фізичні і матеріальні об’єкти Register(Реєстр), Airplane(Літак) Специфікації, елементи проектних рішень чи опису об’єктів ProducSpecification(Специфікація товару ) FilightDescription(Опис польоту) Місця Store(Магазин) Airport(Аеропорт) Транзакції Sale(Продаж), Payment(Платіж), Reservation(Резервування) Елементи транзакції SaleLineItem(Елементи продаж) Ролі людей Cashier(Касир), Pilot(Пілот) Контейнери інших об’єктів Store(Магазин), Bin(Бункер), Airplane(Літак) Вміст контейнерів Item(Елемент), Passenger(Пасажир) Інші комп’ютери чи електромеханічні системи, зовнішні по відношенню до даної системи CreditPaymentautorizationSystem(Система авторизації кредитних платежів) AirTrafficControl(Система управління рухом) Визначення концептуальних класів за допомогою виявлення іменників Основний успішний сценарій (або основний процес): 1. Покупець підходить до касового апарату POS-системи з вибраними товарами. 2. Касир відкриває нову продаж, 3. Касир вводить ідентифікатор товару. 4. Система записує найменування товару і видає його опис, ціну та загальну вартість. 5. Ціна обчислюється на основі набору правил, Касир повторює дії, описані в пп. 3-4 для кожного найменування товару. 6. Система обчислює загальну вартість покупки з податком. 7. Касир повідомляє покупцеві загальну вартість і пропонує сплатити покупку. 42 8. Покупець оплачує покупку, система обробляє платіж. 9. Система реєструє продаж, відправляє інформацію про неї зовнішньої бухгалтерської системі. Модель предметної області - це візуалізація важливих понять зі словника предметної області. П: Звідки брати необхідні терміни? В: З опису прецедентів. Ці описи - багате джерело для ідентифікації іменників. Одні з цих іменників можуть бути представлені у вигляді концептуальних класів, інші можуть представляти концептуальні класи, не мають відношення до даної ітерації (наприклад, «бухгалтерська система» або «комісійні» ), а треті - у вигляді атрибутів цих концептуальних класів. Принципи створення моделі предметної області 1. Складіть список кандидатів на роль концептуальних класів на основі списку категорій і методу, аналізу текстового опису для поточної ітерації розробляння. 2. Відображення їх в моделі предметної області. 3. Додайте необхідні асоціації, що відображають зв'язку, для яких потрібно виділення пам'яті. 4. Додайте атрибути, необхідні для виконання інформаційних вимог (обговорюється в наступному розділі). 5. Імена і моделі: стратегія побудови карт. 6. Використовувати застосовуються на даній території назви. 7. Виключати несуттєві деталі. 8. Не додавати об'єкти, які існують на цій території. Розглянемо деякі терміни, пов'язані з уніфікованим процесом розробляння і використовувані в UML. Концептуальний клас - поняття з реального світу. Розглядається в концептуальному ракурсі. В рамках UP модель предметної області містить концептуальні класи. Програмний клас - клас, що представляє специфікацію або реалізацію програмного компонента, незалежно від процесу або методу. Клас проектування - елемент моделі проектування UP. Це синонім програмного класу, однак з певних причин автору хотілося акцентувати увагу на тому, що даний клас має відношення до моделі проектування. В контексті UP класи проектування відносять або до ракурсу специфікації або до реалізації. Клас реалізації - клас, реалізований на об'єктно-орієнтованій мові, наприклад на Java. Клас - у мові UML - це загальний клас, що представляє або поняття реального світу (концептуальний клас), або програмну сутність (програмний клас). 43 Рисунок 2.11 - Приклади артефактів Питання для самоперевірки 1. Що таке модель предметної області? 2. З якою метою створюють модель предметної області ? 3. Які основні принципи створення моделі предметної області ? 4. Що таке концептуальний клас ? 5. Яка різниця між концептуальним класом, програмним класом та класом проектування ? 44 Література: [2, с.147-188]; Завдання на СРС: [9, с. 120-130]. 45 2.4 Шаблони проектування Структура теми : – Шаблоны GRASP – Шаблон Information Expert – Шаблон Creator – Шаблон High Cohesion – Шаблон Low Coupling Шаблоны GRASP Шаблони GRASP (General Responsibility Assignment Software Patterns) дозволяють зрозуміти принципи об'єктного проектування. Такі шаблони ще називають шаблонами розподілу обов'язків В UML зобов'язання позначається як resposibility. Описують поведінку об'єктів. 2 основних типи: 1. Знання (knowing) 2. Дія (doing) Обов’язки типу doing – виконання дій самим об'єктом (наприклад: створення екземпляра, виконання розрахунку); – ініціювання дій інших об'єктів (наприклад: отримати стан рахунку); – управління діями інших об'єктів і їх координація. Обов’язки типу knowing – наявність інформації про закриті інкапсульовані дані; – наявність інформації про зв’язані об'єкти; – наявність інформації про наслідки і обчислювані величини. Досвід розробників об'єктно-орієнтованих систем сформулювали загальні принципи і рішення в розробці ПЗ. Принципи структурували і структурували, далі розділили на шаблони з іменами. Шаблон повинен містити інформацію про застосування в різних ситуаціях. Шаблон – це - а. Іменування пара «проблема / рішення». б. Шаблон одного розробника - будівельний блок іншого розробника в. Шаблони не містять нових ідей Шаблон Information Expert Проблема: який найбільш загальний принцип розподілу обов'язків в об'єктно- орієнтованому проектуванні? Рішення: призначити обов'язок акумуляції інформаційному експерту - класу у якого є інформація, необхідна для виконання обов'язків. Рекомендації: Інформаційним експертом може бути не один клас, а кілька. Приклад Необхідно розрахувати загальну суму продажі. Існують класи проектування "Продаж", "ТоварПродажа" (продаж окремого виду товару в рамках продажу в цілому), "ТоварСпеціфікація" (опис конкретного виду товару). Необхідно розподілити обов'язки з надання інформації і розрахунку між цими класами. |