Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Учебник.doc
Скачиваний:
2
Добавлен:
01.03.2025
Размер:
2.04 Mб
Скачать

Вопросы для самоконтроля

1. Суть структурного метода анализа предметной области, принципы, модели, порядок разработки.

2. Мeтодология SADT, область применения..

3. Функциональная модель мeтодологии SADT, правила построения.

4. Типы связей между структурами.

5. Моделирование потоков данных.

6. Накопители данных, их разновидности и использование при моделировании.

7. Понятие миниспецификации, критерии завершения построения иерархии диаграмм.

8. Методология DFD в нотациях Гейна-Сарсона и Йордана-Де Марко.

9. ER диграммы – метод проектирования баз данных.

10. Сущности и связи.

11. Подтипы и супертипы.

12. Правила построения ER-диаграмм:

13. Связь между различными типами диаграмм.

14. Инфологическое и даталогическое проектирование.

15. Информационная модель предметной области "Библиотека".

16. Область применения структурного метода анализа предметной области, ограничения.

4.Объектно-ориентированная методология анализа и моделирования предметной области

4.1.Этапы развития uml и используемые методологии проектирования

4.1.1. Основные этапы развития uml.

Изложенный в предыдущем разделе структурный метод анализа предметных областей, как отмечалось ранее, обладает тем недостатком, что его использование затруднено при разработке сложных систем. Особенно трудно было с его помощью осуществлять разработку сложных программных комплексов, связанных не только с формализацией самой программной системы, но и с распределением работ между исполнителями и последующей стыковки разработанных фрагментов программ, а также с передачей информации о разрабатываемой программной подсистеме в случае замены специалиста.

До 1970-х годов размер (например, количество строк программного кода) считался главным показателем сложности разработки программ. Отчасти учмтывался и синтаксис самих строк. Трудоемкость программирования оценивалась "человеко-месяцем" или "человеко-годом", а квалификацию программиста связывали с количеством строк кода, достижимым для написания и отладки за период времени.

Проблемы создания такого программного обеспечения, выражались в:

превышении сроков сдачи проектов и перерасходе их бюджетов;

неудовлетворении заданным спецификациям;

затруднении модификации проектов.

Для преодоления этого кризиса с середины 1980-х развивалась объектно-ориентированная технология программирования, в результате чего проекты систем стали создаваться на основе визуального моделирования компонент (CBD – Component Based Development).

Свойства современных инструментов визуальной CBD-разработки::

  • Поддержка генерации кода и обратного проектирования (т.е. восстановление визуальной модели по программному коду) для ряда языков,

  • Поддержка визуального объектно-ориентированного моделирования и совместимость со стандартным языком описания моделей UML (Unified Modeling Language).

  • Ориентация на проектировщиков информационных систем, менеджеров и программистов, в том числе за счет обеспечения возможности декомпозиции системы по разнообразным аспектам с использованием визуального моделирования.

Таким образом в настоящее время широко известны два подхода к проведению декомпозиции системы при построении ее визуальной модели:

    • Структурный анализ/проектирование – в основе упорядочение событий/потоков данных (алгоритмическая декомпозиция).

    • Объектно-ориентированная декомпозиция, базирующаяся на выделении агентов, которые или сами действуют, или являются объектами действия.

Объектно-ориентированное проектирование включает объектно-ориентированную декомпозицию и визуальную нотацию для описания разнообразных моделей проектируемой системы. Оно состоит в объектной декомпозиции системы, а для визуального выражения логического (классы и объекты) и физического (модульная и процессорная архитектура) аспектов модели применяют различную нотацию.

Языки объектно-ориентированного моделирования появились в результате конкуренции между различными подходами к объектно-ориентированному методу анализа и проектирования (ООАП). Отдельные методики и графические нотации (IDEF0, IDEF1X) были стандартизованы.

К середине 1990-х наиболее известными стали методы:

  • Гради Буча (Grady Booch) - Booch или Booch'91, Booch Lite (позже - Booch'93);

  • Джеймса Румбаха (James Rumbaugh) - Object Modeling Technique (ОМТ, ОМТ-2);

  • Айвара Джекобсона (Ivar Jacobson) - Object-Oriented Software Engineering (OOSE).

Каждый из методов ориентирован на отдельные этапы ООАП. Например, OOSE содержал средства представления вариантов использования, важных на этапе анализа требований при проектировании бизнес-приложений. ОМТ-2 удобнее в анализе процессов обработки данных в информационных системах.

Метод Booch'93 стал наиболее популярным на этапах проектирования и разработки различных программных систем. Развитие языка UML началось с унификации методов Booch и ОМТ для объединения их достоинств, а далее с ними был интегрирован метод OOSE.

Сначала авторы предполагалась разработка унифицированного языка моделирования только для этих трех методик. Каждая из них показала эффективность для отдельных задач ООАП и требовалось устранение несоответствия отдельных понятий и обозначений. К новому языку моделирования предъявлялись следующие требования:

  • Моделирование и программного обеспечения, и других систем и бизнес-приложений с использованием объектно-ориентированных понятий.

  • Обеспечение взаимосвязи между базовыми понятиями моделей концептуального и физического уровней.

  • Масштабируемость моделей, что важно для сложных многоцелевых систем.

  • Мультиплатформенность, а также простота для аналитиков и программистов.

В настоящее время дальнейшую разработку языка UML ведет консорциум OMG, и последняя версия языка UML - UML 2.0.

К нынешнему дню созданы средства визуального программирования на базе UML, обеспечивающие интеграцию (включая прямую и обратную генерацию кода программ) с такими языками и средами программирования, как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Язык UML можно расширять без переопределения его ядра.