ПІДРУЧНИК (набір 2) - Блог Nkpages

Опубліковано 9 грудня 2010 р. Nkpages

набір

РІЗНІ МЕТОДИ АНАЛІЗУ ІНФОРМАЦІЙНОЇ СИСТЕМИ

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

ПОНЯТТЯ ОБ'ЄКТУ

Об'єктно-орієнтоване програмування - це процес комп'ютерного моделювання набору елементів частини реального світу (званого доменом) у набір обчислювальних сутностей. Ці ІТ-суб’єкти називаються об'єктів. Це комп’ютерні дані, що об’єднують основні характеристики елементів реального світу (розмір, колір тощо).

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

ОБ’ЄКТНІ МЕТОДИ

Об’єктне моделювання полягає у створенні обчислювального представлення цікавих елементів реального світу, незалежно від реалізації, що означає незалежність від мови програмування. Отже, мова йде про визначення наявних об’єктів та ізоляцію їх даних та функцій, які їх використовують. Для цього були розроблені методи. У період з 1970 по 1990 рр. Багато аналітиків розробляли об'єктно-орієнтовані підходи, завдяки чому до 1994 р. Було понад 50 об'єктних методів. Однак насправді з’явилося лише 3 методи:

Ø метод OMT Румбо

Ø Метод БУЧ Буча '93

Ø метод Якобсона OOSE (об’єктно-орієнтована інженерія програмного забезпечення)

З 1994 р. Румбо та Буч (до яких у 1995 р. Приєднався Якобсон) об'єднали зусилля з розробки Єдиного методу 0,8, враховуючи переваги кожного з попередніх методів.

Уніфікований метод з версії 1.0 стає UML (Unified Modeling Language), універсальним позначенням для об’єктного моделювання.

UML не є методом, оскільки не представляє жодного процесу. Як такий UML є об'єктом моделювання формалізму. Таким чином, метод слова, який іноді використовують зловживання мовою на наступних сторінках, не слід розуміти як "підхід".

UML 1.0 подано до OMG (Objet Management Group) в січні 1997 р., Але він буде прийнятий до листопада 1997 р. У його версії 1.1, дата, з якої UML стає міжнародним стандартом.

Короткий зміст розвитку цієї моделі моделювання:

Ø У 1995 році: уніфікований метод 0,8 (інтегрування методів Буча '93 та OMT)

Ø У 1995 році: UML 0.9 (з інтеграцією методу OOSE)

Ø У 1996 році: UML 1.0 (запропонований OMG)

Ø У 1997 році: UML 1.1 (стандартизований OMG)

Ø У 1998 році: UML 1.2

Ø У 1999 році: UML 1.3

Ø У 2000 році: UML 1.4

Ø У 2003 році: UML 1.5

Останні версії специфікацій можна завантажити з веб-сайту OMG.

Цей метод представляє засіб специфікації, представлення та побудови компонентів комп’ютерної системи. За допомогою методу UML, наприклад, об'єкт представляється таким чином:

45789: Серійний номер

32 літри: кількість бензину

ІНТЕРЕС ОБ'ЄКТНОГО МЕТОДУ

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

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

Ø По-перше, абстрактний дизайн об’єктної моделі (це роль об’єктного методу), по-друге, реалізація за допомогою об’єктно-орієнтованої мови (наприклад, C ++/Java/...)

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

СТАНДАРТИЗАЦІЯ OMG

Таким чином, необхідно, щоб метод об'єкта був визначений строго та унікально, щоб усунути двозначності. Було визначено багато об'єктних методів, але жоден з них не зміцнився через відсутність стандартизації. Ось чому всі гравці в ІТ-світі заснували OMG у 19889 році (Група управління об’єктами), некомерційна організація, метою якої є розробка стандартів, що гарантують сумісність між програмами, запрограмованими за допомогою мови об'єктів, та функціонуючими в неоднорідних мережах (різних типів).

З 1997 року UML став стандартом OMG, що дозволило йому зарекомендувати себе як метод розробки об'єктів і бути визнаним та використовуваним багатьма компаніями.

UML базується на МЕТА-МОДЕЛІ

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

ü Мова без двозначностей

ü Універсальна мова, яка може слугувати опорою для будь-якої об’єктно-орієнтованої мови

ü Спосіб визначення структури програми

ü Візуальне зображення, що дозволяє спілкуватися між акторами одного проекту

ü Просте графічне позначення, зрозуміле навіть спеціалістам, що не належать до ІТ

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

UML ЯК ПОВНА ВІЗУАЛІЗАЦІЯ СИСТЕМИ

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

Таким чином, CdCF розподіляється між різними компаніями, що надають послуги (у випадку субпідряду) у формі тендеру, на який компанії реагуватимуть із зазначенням вартості, кінцевого терміну тощо, коли компанія отримає ринок та вирішить ( якщо у неї є вибір) вибрати об’єктно-орієнтовану мову, вона повинна спочатку створити модель (саме тут входить UML), щоб:

ü Представити клієнту спосіб, яким він має намір розробляти програмне забезпечення

ü Надайте всім учасникам проекту (широкомасштабна заявка, як правило, здійснюється модулями, розробленими різними групами)

Таким чином, якщо модель не відповідає замовнику, її буде «просто» модифікувати, на відміну від безпосередньо реалізованого додатка (який би мобілізував набагато більше персоналу на більш тривалий період), що означає марну трату грошей. Менш важливо для сервісної компанії, а також краща ймовірність доставки вчасно (ми зазвичай говоримо про термін) заявка відповідно до вимог замовника (якщо заявка відповідає моделі, представленій замовнику, останній навряд чи може заперечити справедливість програмного забезпечення).