Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
АВПЗ_НМП.doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
520 Кб
Скачать
☆

Діаграми uml, що пояснюють внутрішній устрій системи

Деякі автори [3] рекомендують використати при описі вимог діаграми UML, що описують створювану систему через її компоненти (класи, об'єкти), відношення і взаємодії між ними. Цей підхід має свої обмеження.

Діаграма класів. Для створення діаграми класів необхідно:

  1. Здійснити пошук класів (ключових компонентів проблемної області).

  2. Для кожного знайденого класу визначити його ім'я, основні атрибути, операції і (чи) відповідальності.

  3. Досліджувати відношення знайдених класів.

Класи на діаграмі представлені у вигляді прямокутників, відношення – у вигляді ліній, що зв'язують прямокутники. Лінії різного типу графічно відрізняються різним штрихуванням і стрілками.

Як правило, виділяють 3 рівні абстракції класів [1]: концептуальний рівень, рівень специфікації, рівень реалізації. Аналіз вимог слід супроводжувати діаграмами, що відбивають концептуальний рівень. На цьому рівні при описі класів доцільно вказати їх найменування і відношення. Атрибути і операції можна не вказувати, або ввести тільки основні, відклавши їх дослідження на пізніші стадії деталізації.

Відношення, що підлягають аналізу на концептуальному рівні, - це:

асоціація (іменований зв'язок)

залежність (зміни в одному класі призводять до змін в іншому)

узагальнення / генералізація (родо– та видове відношення)

агрегація (відношення «частина–ціле»)

композиція (відношення «частина-ціле», що однозначно регламентує кількість і склад частин цілого).

Діаграма класів показує статичну структуру проблемної області. Для аналізу взаємодії об'єктів - екземплярів класу в ході реалізації варіанту використання на UML передбачені дві діаграми взаємодії: діаграма кооперації і діаграма послідовності.

Альтернативні мови моделювання

Діаграма потоків даних (data flow diagram, DFD) – один з основних інструментів структурного аналізу і проектування інформаційних систем, що існували в епоху, попередню UML.

Для опису діаграм DFD використовуються дві нотації – Йодана (Yourdon) і Гейна-Сарсона (Gane - Sarson), що відрізняються синтаксисом. На рис.8.4. проілюстровано нотацію Гейна-Сарсона.

Рис.8.4. Діаграма DFD за нотацією Гейна-Сарсона

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

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

Крім того, нотація DFD підтримує поняття підсистеми – структурної компоненти системи, що розробляється.

Нотація DFD – зручний засіб для формування контекстної діаграми, тобто діаграми, що показує ПС, що розробляється, у комунікації із зовнішнім середовищем. Це - діаграма верхнього рівня в ієрархії діаграм DFD. Її призначення – обмежити рамки системи, визначити, де закінчується система, що розробляється, і починається середовище. Інші нотації, що якнайчастіше використовують при формуванні контекстної діаграми, – діаграма SADT, діаграма use case UML.

Серед різноманіття моделей, що використовуються в аналізі систем, слід окремо відмітити ще дві нотації, що дозволяють описати складні багатоальтернативні взаємодії компонент інформаційної системи - нотацію IDEF3 [4] і eePC – діаграму ARIS [5].

Для моделювання вимог до систем з розгалуженою логікою К.Вігерс рекомендує використовувати таблиці і дерева рішень [6]. Часто на практиці бувають корисні діаграми сутність-зв'язок і SADT - діаграми [4].

Література до теми:

  1. Фаулер М, Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделированияПер. с англ. - М.:Мир, 1999. - 191 с.

  2. Леоненков Самоучитель UML

  3. Мацяшек ЛешекАнализ требований и проектирование систем. Разработка информационных. Пер. с англ. - М.: ИД "Вильямс", 2002. - 432 с.

  4. Маклаков С.ВBpwin Erwin Case-средства разработки информационных систем Москва "ДиалогМифи " – 2000

  5. Орлов C. Технологии разработки программного обеспечения: Учебник – СПб.: Питер, 2002. - 464 с.

  6. Вигерс К. Разработка требований к программному обеспечению. Пер, с англ. - М.:ИТД "Русская Редакция", 2004–576с.