Приклад: ООП і структури зберігання. Стек

⇐ ПредыдущаяСтр 3 из 50Следующая ⇒

Постановка завдання: Необхідно розробити структуру зберігання Стек. Примітки:

• Не враховувати необхідність перерозподілу пам'яті.

• Вважати, що елементи цілого типу. Аналіз і проектування.

Дані:

• MemSize - максимальна кількість елементів.

• DataCount - кількість елементів в стеку.

• pMem - покажчик на пам'ять для зберігання значень. Операції:

• IsFull - перевірка на повноту.

• IsEmpty - перевірка на порожнечу.

• Get - узяти елемент з вершини.

• Put - покласти елемент в стек.

Розглянемо модель і фінальний результат нашого проектування (використовується нотація UML):

Рис.8.3. Рис. 3.4.

Повторне використання

Ідея повторного використання.

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

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

Девіз: не треба винаходити велосипед, якщо він вже винайдений.

Достоїнства повторного використання.

Достоїнства повторного використання (по Соммервілю [1]):

• Підвищення надійності.

• Зменшення проектних рисок.

• Ефективне використання фахівців.

• Дотримання стандартів (приклад: призначений для користувача інтерфейс).

• Прискорення розробки.

Повторне використання досягається за рахунок наступних прийомів (видів

використання):

• Компонентна розробка. Частина компонентів вже розроблені раніше, мають чітко описаний інтерфейс. Вони використовуються як "цегла" в новій системі.

• Використання патернів (шаблонів) проектування. Застосовуються відомі підходи до вирішення деяких проблем, що зустрічалися раніше.

• Використання стандартних прикладних (MKL, MFC) і системних (API) бібліотек.

Візуальне моделювання. Історія мови UML

При вивченні матеріалів по візуальному моделюванню і мові UML як основне джерело рекомендується класична книга [2]. Додатково рекомендується наступна книга: G.

Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language Reference Manual - Second Edition, Addison-Wesley, 2004. Велика кількість матеріалів може бути знайдене на сайті www.uml.org.

Ідея візуального моделювання

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

Як вирішувати цю проблему? На допомогу приходить моделювання. Під моделлю зазвичай розуміють спрощене представлення об'єктів і явищ реального миру.

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

Завдання моделювання [2]:

• Візуалізація системи в її деякому стані.

• Визначення структури і поведінки системи.

• Отримання шаблону для створення системи.

• Документування ухвалених рішень. Принципи моделювання [2]:

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

• Кожна модель може бути втілена з різним ступенем абстракції.

• Кращі моделі - ті, що ближче до реальності.

• Якнайкращий підхід при розробці складної системи - використовувати декілька майже незалежних моделей.

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

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

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

• Візуалізація спрощує розуміння проекту в цілому.

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

• Візуалізація робить обговорення конструктивним і зрозумілим.

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

UML (unified modeling language) - це мова для візуалізації, специфікації, конструювання, документування елементів програмних систем. UML - мова загального призначення, призначена для об'єктного моделювання.

Історія мови UML

До 1994 року існувало декілька нотацій для візуального відображення ухвалюваних проектних рішень і декілька методів аналізу і проектування. У 1994 році відбулася знакова подія - Grady Booch і James Rumbaugh, співробітники фірми Rational Software, об'єднали свої методи проектування і аналізу, створивши так званий Unified method. З цієї миті процес стандартизації домовленостей увійшов до робочого ритму. Приведемо важливі віхи цього шляху:

• 1994: Grady Booch & James Rumbaugh (Rational Software) об'єднали методи Booch

(проектування) і OMT (аналіз) ->Unified method.

• 1995: приєднався Ivar Jacobson (автор методу OOSE). Згодом група авторів Booch, Rumbaugh і Jacobson разом випустила не одну книгу, що стала бестселером (наприклад, див. список літератури). Цю трійцю жартівливо називали "Three amigos", натякаючи на те, як жарко вони сперечалися з приводу ухвалюваних рішень.

• 1996 - Ідея про Unified Modeling Language (three amigos).

• 1996 - створений консорціум UML Partners під керівництвом three amigos.

• Червень, Жовтень 1996 - UML 0.9 & UML 0.91.

• Січень 1997 - специфікації UML 1.0 запропоновані OMG (Object Management Group).

• Серпень 1997 - специфікації UML 1.1 запропоновані OMG.

• Листопад 1997 - UML 1.2 - результат адаптації OMG.

• Червень 1999 - UML 1.3.

• Вересень 2001 - UML 1.4.

• Березень 2003 - UML 1.5. Прийнятий стандарт:

• ISO/IEC 19501:2005 Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2.

• Жовтень 2004 - UML 2.0.

Структура мови UML

Моделі UML

UML дозволяє описувати систему наступними моделями:

• Модель функціонування (показує, як описується функціональність системи з погляду користувача).

• Об'єктна модель (показує, як виглядає проект системи з погляду об'єктного підходу).

• Динамічна модель (показує, як взаємодіють один з одним компоненти системи в динаміці, з часом). Демонструє, які процеси відбуваються в системі.

Діаграми UML

Діаграми UML призначені для візуального відображення моделей і їх компонентів. UML 2.0 містить 13 типів діаграм. Зокрема:

• Структурні діаграми (6).

• Діаграми поведінки (3).

• Діаграми взаємодії (4).

Розглянемо кожну з груп докладніше.

Структурні діаграми:

• Діаграма класів - показує класи, їх атрибути і зв'язки між класами.

• Діаграма компонентів - показує компоненти і зв'язки між ними.

• Структурна діаграма - показує внутрішню структуру класів і зв'язку із зовнішнім світом.

• Діаграма розгортання - показує, як ПЗ розміщується на апаратурі (серверах, робочих станціях...).

• Діаграма об'єктів - показує структуру системи в конкретний момент часу, об'єкти, їх атрибути...

• Діаграма пакетів - показує, як система розкладається на крупні складові частини і зв'язки між цими частинами

Діаграми поведінки:

• Діаграма дії - показує потоки інформації в системі.

• Діаграма стану - є кінцевий автомат, що показує функціонування системи.

• Діаграма варіантів використання - показує роботу системи з погляду користувачів.

Діаграми взаємодії

• Діаграма кооперації - показує структурну організацію об'єктів, що беруть участь у взаємодії.

• Діаграма взаємодії (новація UML 2.0).

• Діаграма послідовності - показує тимчасову впорядкованість подій.

• Тимчасова діаграма - діаграма пов'язана з тимчасовими рамками проекту.

Поняття UML

Для опису структури: Актор, Атрибут, Клас, Компонент, Інтерфейс, Об'єкт, Пакет. Для опису поведінки: Дія, Подія, Повідомлення, Метод, Операція, Стан, Варіант

використання.

Для опису зв'язків: Агрегація, Асоціація, Композиція, Залежність, Спадкоємство. Деякі інші поняття: Стереотип, Множинність, Роль.

Дата добавления: 2018-05-09; просмотров: 361; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 1 234 5 6 7 8 9 10 Следующая ⇒

Мы поможем в написании ваших работ!