03 Методы проектирования. UML. CASE. Шаблоны.pptx

основе структурного проектирования лежит последовательная декомпозиция - целенаправленное структурирование на

отдельные составляющие.

В результате декомпозиции получается иерархическая модульная структура.

В зависимости от объекта структурирования различают:
функционально-ориентированные методы;
методы структурирования данных.

потоков данных (Data Flow Diagram - DFD), в нотации Йодана-Де

Марко или Гейна-Сарсона - BPWin, PowerDesigner.
Модели процессов IDEF0, IDEF3 – BPWin.
Диаграммы «сущность-связь» (Entity-Relationship Diagram - ERD) в нотации Чена, Баркера, IE, IDEF1x – ERWin, PowerDesigner.
Диаграммы декомпозиции.
Диаграммы «состояния - переходы» (STD) и конечные автоматы.
Структурные схемы – блок-схемы.

Криса Гэйна (Chris Gane) и Триш Сэрсон (Trish Sarson):
Разработка DFD,

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

Подход прекрасно подходит для бизнес-анализа и системного анализа.
С помощью нотации DFD хорошо описывалась процедурная логика программ, написанных в прошлом на языках типа COBOL или Clipper.

инженерия»
Фазы информационной инженерии:
Разрабатывается функциональная модель и концептуальная модель предметной области

всего предприятия.
Выделяются подсистемы. Строятся ER-модели и матрицы «сущности-процессы».
Системное проектирование. Формируется детальная модель, которая включает диаграммы: декомпозиции процессов, зависимости процессов, потоков данных, действий, структур данных.
Выполняется детальное конструирование процедур обработки данных.

Джеймс Мартин (James Martin)

Клайв Финкельштейн (Clive Finkelstein)

В основе метода лежат 2 положения:
1) данные, циркулирующие в организации, дают более стабильную базу для проектирования систем, чем процедуры по их обработке;
2) данные должны рассматриваться независимо от того, как они сейчас обрабатываются.

approach) представляет систему в виде взаимодействующих объектов, которые имеют собственное

локальное состояние и могут выполнять набор операций, определяемых этим состоянием.

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

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

Объектно-ориентированная технология (ООТ) – это совокупность языков, инструментальных средств и методологии, предназначенных для разработки ПО, ядром которого являются объекты.

система разбивается на «активные сущности» (объекты или компоненты), которые взаимодействуют

друг с другом, обмениваясь сообщениями и находясь в отношении «клиент-сервер». Сообщения, которые может принимать объект, определены в его интерфейсе. В этом смысле посылка сообщения «объекту-серверу» эквивалентна вызову соответствующего метода объекта.

:A

:B

:C

1. op1()

1.1. op2()

Клиент

Сервер

Techniques)
абстрагирование,
инкапсуляция,
модульность,
иерархия,
типизация,
параллелизм,
сохраняемость.

выделяет существенные характеристики некоторого объекта, отличающие его от всех других

видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.

- это процесс отделения друг от друга элементов объекта, определяющих

его устройство и поведение; инкапсуляция служит для того, чтобы изолировать контрактные обязательства абстракции от их реализации.

Абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством.

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

В интерфейсной части собрано все, что касается взаимодействия данного объекта с другими объектами.

- это свойство системы, которая состоит из внутренне связанных, но

слабо сцепленных между собой модулей.

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

В большинстве языков интерфейс модуля отделен от его реализации.

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

это упорядочение абстракций, расположение их по уровням.
Образование из абстракций иерархической

структуры упрощает понимание сложных систем.

Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия "is-a") и структура объектов (иерархия "part of").

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

Наследование позволяет применять общие компоненты более логично по сравнению со структурным анализом и проектированием.

это способ защититься от использования объектов одного класса вместо другого,

или по крайней мере управлять таким использованием.

Класс реализует понятие типа.

Типизация может быть сильной или слабой, со статическим или динами-ческим связыванием имен с типами.

- это свойство, отличающее активные объекты от пассивных.
Объектная модель хороша

для распределенных систем, поскольку она неявно разбивает программу на: (1) распределенные единицы и (2) сообщающиеся субъекты.

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

Унификация принципов параллелизма для объектов позволила создать параллельные языки программирования.

Эта тема рассматривает организацию процессов, задач и потоков для обеспечения эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.

Persistence)
Сохраняемость - способность объекта существовать во времени, переживая породивший его

процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.

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

Сохраняемость приводит к созданию объектно-ориентированным базам данных (OODB, object-oriented databases).

Language)
Грэди Буч
(Grady Booch)
Джеймс Рамбо
(James Rumbaugh)
Ивар Якобсон
(Ivar Jacobson)
Первая версия

UML 1.0 опубликована в январе 1997 года.
Последняя версия UML 2.4.1 опубликована в августе 2011 года.
Развивается консорциумом OMG (Object Management Group), www.uml.org

Object-Oriented Software Engineering

Object-Modeling Technique

Booch method

diagrams)
1.1. Классов (Class - сlass)
1.2. Компонентов (Component - component)
1.3.

Композитной/составной структуры (Composite structure - сlass)
1.4. Кооперации (Collaboration) (UML2.0)
1.5. Развёртывания (Deployment - deployment)
1.6. Объектов (Object - object)
1.7. Пакетов (Package - package)
1.8. Профилей (Profile) (UML2.2)

diagrams)
2.1. Деятельности (Activity- activity)
2.2. Автомата / Состояний (State machine /

Statechart – state machine)
2.3. Вариантов использования (Use case - use case)
2.4. Диаграммы взаимодействия (Interaction diagrams):
2.4.1. Коммуникации (Communication - comm) (UML2.0) / Кооперации (UML1.x)
2.4.2. Обзора взаимодействия (Interaction overview - intover) (UML2.0)
2.4.3. Последовательности (Sequence - sd)
2.4.4. Синхронизации (Timing - timing) (UML2.0)

ПО
Модель вариантов использования
Модель анализа
Модель проектирования
Модель развёртывания
Модель реализации
Модель тестирования

Rational кооперации называют реализациями вариантов использования.
Динамическая составляющая
Статическая составляющая
Кооперация –

это описание совокупности объектов, взаимодействующих для реализации определённого поведения и достижения некоторой цели.

объектов — технология повторного использования проекта в отличие от повторного

использования кода.

Шаблон обеспечи­вает скелет решения проблемы, который должен быть настроен и расширен, чтобы он мог выполнять полезную функцию. Настройка включает написание определенного кода, который «заполняет пробелы» в шаблоне (то есть, кото­рый реализует различные элементы шаблона, приспосабливая их к оконча­тельному структурному и поведенческому проекту).

книги Эриха Гаммы
Параметризованные, то есть настраиваемые кооперации называют паттернами –

patterns (образцами).
Паттерн как шаблон проекта означает и объяс­няет лучшие и широко подтвержденные теорией и практикой решения задач проектирования.
Он является решением типичной проблемы в определенном контексте.

кооперации

(pattern) — образец (шаблон структуры ПО) и
фреймворк (framework) —

каркас (шаблон приложения).

Наиболее известные шаблоны приложений — системы пла­нирования ресурсов предприятия (enterprise resource planning — ERP) типа SAP R/3. ERP-системы предлагают и проектирование, и повтор­ное использование кода. Это базовые пакеты ПО. ПО настраивается и расши­ряется в соответствии с перечнем потребностей клиента. Настройка выполняется в пределах скелетного проекта, заданного шаблоном.
Application framework - каркас приложений (интегрированная среда, содержащая библиотеки классов и определяющая структуру разрабатываемого приложения). Например, MFC application framework - каркас приложения на основе библиотеки базовых классов Microsoft.
 
Шаблон обеспечивает структурное проектирование системы. В этом смысле, каждый шаблон является структурным шаблоном независимо от того, является ли он программным продуктом типа ERP-системы или только идеей проекта и условием, наложенным на коллектив разработчиков.

проектирования
Аббревиатура CASE (Computer-aided Software Engineering — автоматизированная разработка ПО) обозначает

специальный тип программного обеспечения, предназначенного для автоматизации некоторых этапов разработки, в том числе и проектирования.

Средства проектирования компонентов программного обеспечения и информационного обеспечения обеспечивают:
моделирование структуры и поведения компонентов ПО как на логическом уровне так и на физическом;
логическое и физическое моделирование данных, автоматическое преобразование моделей данных в «третью нормальную форму», автоматическую генерацию схем БД и описаний форматов файлов на уровне программного кода.

Rational Software)

(Computer Associaties)

Visual Studio 2010 Ultimate
Borland Together 2005 for Microsoft Visual Studio

.NET

ПО за счет средств автоматического контроля (прежде всего, контроля проекта);

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