Макетирование.

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

Основная цель макетирования – снять неопределенности в требованиях заказчика. Макетирование (прототипирование) – это процесс создания модели необходимого программного продукта. Модель может принимать одну из трех форм:

1. Бумажный макет или макет на основе ПК(отображает или рисует диалог между человеком и машиной).

2. Работающий макет – выполняет некоторую часть нужных функций.

3. Существующая программа – характеристики которой должны быть позже улучшены.

К

Ожидания заказчика

Построение/уточнение макета

Оценка макета заказчиком

ак показано на рисунке, макетирование основывается на многоразовом повторении итераций, в которых участвуют разработчик и заказчик.

Последовательности действий при макетировании представлены на следующем рисунке.

М

Макетирование

Сбор и уточнение требований

Быстрое проектирование

Построение макета

Оценка макета заказчиком

Уточнение макета

Продолжить?

ДА?

НЕТ

Конструирование продукта

Конец

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

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

Достоинства макетирования: обеспечивает определения полных требований к ПО.

Недостатки макетирование: заказчик может принять макет за продукт, разработчик может принять макет за продукт.

Объясним недостатки: когда заказчик видит работающую версию ПО, он перестает понимать, что детали макета скреплены «соплями», он забывает, что в гонке за работающим вариантом оставлены нерешенные вопросы качества и удобства сопровождения ПО. Когда заказчику говорят, что продукт должен быть перестроен, он начинает злиться и требовать что бы макет в три приема был превращен в рабочий продукт. Очень часто это негативно сказывается на управлении разработкой ПО.

Лекция 1(продолжение) 9.12

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

Стратегии конструирования ПО.

Существует 3 стратегии конструирования ПО:

1. Одноразовый проход(водопадная стратегия) – линейная последовательность этапов конструирования.

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

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

Характеристики конструирования ПО, в соответствии условиям стандарта IEEE/EIA 12207.2 приведены в таблицу:

Стратегия конструирования	На начало процесса определены все требования?	Множество циклов конструирования?	Промежуточное ПО распространяется?
Одноразовый подход	Да	Нет	Нет
Инкрементная(запланировано улучшение продукта)	Да	Да	Мб
Эволюционная	Нет	Да	Да

Лекция 1(продолжение) 12.12

Инкрементная модель

Ср №1-3 читать

Чмырь «объектно-ориентированное моделирование»

Чмырь, варламов «юмл чето-там»

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

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

Анализ

проектирование

кодирование

тестирование

Современная реализация инкрементного подхода – экстремальное программирование XP. Оно ориентированное на очень маленькие приросты функциональности.

Лекция 2 12.12

Объектно-ориентированная декомпозиция сложной системы. Принципы объектно-ориентированного представления программных систем.

Рассмотрение какой-либо сложной системы требует применения техники декомпозиции - разбиение на составляющие элементы. Известны две схемы декомпозиции: алгоритмическая и объектно-ориентированная декомпозиция. В основе алгоритмичной декомпозиции лежит разбиение на действия – алгоритмы, эта схема представления используется в обычных ПС. Объектно-ориентированная декомпозиция обеспечивает разбиение на автономные особы – объекты реального или виртуального мира. Эти особы(объекты) «большие» элементы, каждый из них несет в себе и описание действия и описание данных.

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

Абстрагирование

Аппарат абстракции – это удобный инструмент, для борьбы со сложностью реальных систем. Создавая понятие интереса какого-либо задания, мы отвлекаемся(абстрагируемся) от несущественных характеристик конкретных объектов, определяя только существенные характеристики. Значит абстрагирование сводится, к формированию абстракции. Каждая абстракция фиксирует основные характеристики объекта, которые отличают его от других видов объектов и обеспечивают ясные границы понятий. Абстракция концентрирует внимание на внешнем представлении объекта, позволяет отделить основное в поведение объекта от его реализации. Абстракцию удобно строить путём выделения обязанностей объекта.

Инкапсуляция

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

Инкапсуляция является процессом разделения элементов абстракции на секции с разной видимостью. Инкапсуляция служит для отделения интерфейса абстракции от её реализации.

Модульность

В языках C++, Pascal, ADA 95, абстракции классов и объектов, формируют логическую структуру системы. При производстве физической структуры, эти абстракции помещаются в модули. В больших системах, где классов сотни, модули помогают управлять сложностью, модули служат физическими контейнерами в который оглашаются классы и объекты логической разработки.

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

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

Иерархическая организация

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

1)структура из классов(«is a-иерархия»)

2)структура из объектов(«part of-иерархия»)

Чаще всего is а-иерархическая структура строится с помощью наследования. Наследование определяет где класс разделяет структуру или поведение определенные одно в другом(одинарное наследование) или в нескольких других(множественное наследование).

Лекция 2 19.12

Другая разновидность иерархической организации – part of-иерархическая структура – базируется на отношении агрегации. Агрегация не является уникальным понятием для объектно-ориентированных систем, но все же агрегация особенно полезна совместно с наследованием:

1. Агрегация обеспечивает физическую группировку логически связанной структуры.

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

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

ДЗ: 4-5 лекции в ср.

Лекция 3 19.12

Характеристика объектов. Виды отношений между объектами.

Рассмотрим внимательнее объекты – конкретные сущности, которые существуют во времени и пространстве.

Объект – это конкретное представление абстракции. Он имеет индивидуальность, состояние и поведение. Структура и поведение подобных объектов определены в их общем классе.

Термины «экземпляр класса» и «объект» взаимозаменяемы. На рисунке приведен пример объекта, который имеет определенный набор свойств и операций.

Индивидуальность – это характеристика объекта, которая отличает его от всех других объектов.

Состояние объекта характеризуется перечислением всех свойств объекта и текущими значениями всех этих возможностей.

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

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

Операция обозначает обслуживание, которое объект предлагает своим клиентам. Возможны 5 видов операций клиента над объектом:

1. Модификатор – изменяет состояние объекта

2. Селектор – дает доступ к состоянию, но не изменяет его

3. Итератор – доступ к содержанию объекту по частям строго в определенном порядке

4. Конструктор – создает объект и инициализирует его состояние

5. Деструктор – уничтожает объект и освобождает занятую им память

Примеры:

Модификатор – пополнить(КГ)

Селектор – какой вес(:integer).

Итератор – показатьасортименттоваров(string)

Конструктор – создать робот совместно(параметры)

Деструкция – уничтожить робот( )

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

Гибридные языки(С++, ADO95) позволяют писать операции, как свободные подпрограммы(вне классах). Пример:

В общем случае все методы и свободные подпрограммы, которые ассоциируются с конкретным объектом, создает его протокол. Протокол определяет оболочку допустимого поведения объекта и потому содержит в себе целостное(статическое и динамическое) представление объекта. Большой протокол полезно делить на логически группы поведений. Эти группы, которые делят пространство поведением объекта, означают роли, которые может играть объект. Принцип выделения ролей иллюстрирует рисунок:

С точки зрения внешней среды, важное значение имеет такое понятие, как обязательства объекта.

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

В конце отметим: наличие у объекта внутреннего состояния означает, что порядок выполнения ними операций очень важен. Иначе говоря, объект может представляться, как независимый автомат. По аналогии с автоматами можно выделять активные и пассивные объекты.

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

Виды отношений между объектами

В поле зрения развернутого ПО находятся не объекты-одиночки, а взаимодействующие объекты. Значит, самовзаимодействие объектов реализует поведение системы. У Буча есть цитата «самолет – это набор элементов, каждый из которых по своей природе стремится упасть на землю, но ценой общих беспрерывных усилий преодолевает эту тенденцию».

Отношения между парами объектов основываются на взаимной информации про разрешенные операции и ожидаемое поведение. Особенно интересны 2 вида отношений между объекта: связи и агрегация.

Связи

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

1. Объект-клиент вызывает операции объекта-поставщика

2. Один объект перемещает данные к другому объекту

Можно сказать, что связи являются рельсами между станциями-объектами, по которым ездят «трамваи-сообщения».

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

26.12

Как участник связи, объект может играть одну из трех ролей:

1. Актер – объект, который может влиять на другие объекты, но никогда не склонен к действиям других объектов.

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

3. Агент – объект, который может, как влиять на другие объекты, так и использоваться ими. Агент создается для выполнения работы от имени актера или другого агента.

Видимость объектов.

Рассмотрим 2 объекта А и Б, между которыми есть связь. Для того, что бы объект А мог послать сообщение в объект Б, нужно что бы Б был видим для А. Различают 4 формы видимости между объектами:

1. Объект–поставщик(сервер) – глобальный для клиента.

2. Объект-поставщик(сервер) – является параметром операции клиента.

3. Объект-поставщик(сервер) – является частью объекта-клиента.

4. Объект-поставщик(сервер) – является локально оглашенным объектом в операции клиента.

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

Агрегация.

Связи означают равноправные (клиент-серверные) отношения между объектами.

Агрегация обозначает отношения объектов «иерархия-целое-часть». Агрегация обеспечивает возможность перемещения от целого (агрегата) к его частям (свойствам). Агрегация может обозначать, а может и не обозначать физическое включение части в целое.

Фотка физическая агрегация.

Фотка логическая агрегация.

Значит, между объектами существует 2 вида отношений – связи и агрегация. Какое выбрать? При выборе вида отношений должны учитываться следующие факторы:

1. Связи обеспечивают низкое сцепление(связь) между объектами.

2. Агрегация инкапсулирует части как секреты целого.