Лаврищева Е.М., Петрухин В.А. Методы и средства инженерии программного обеспечения

Подождите немного. Документ загружается.

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

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

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

понимания проблемы. Важно чтобы лица, работающие над проектом на разных

уровнях, имели возможность эффективно общаться друг с другом.

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

коллективе. Они должны способствовать эффективному достижению согласия и

управления разногласиями, давать возможность снижать сложность отношений в

группе сотрудников, работающих над проектом, особенно в повседневной работе при

создании высококачественного продукта.

Наиболее привычной и результативной моделью отношений между заказчиком и

проектировщиком является модель типа «учитель – ученик». На практике заказчик

наблюдает за работой проектировщика системы. Когда заказчик его не беспокоит,

проектировщик обращает внимание на примеры и сам отвечает себе на возникающие

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

поставленный вопрос для пояснения и удовлетворения проектировщика.

Это даже помогает разработчику разобраться в деталях своей работы и избавляет его

от описания излишних абстракций. Проектировщик должен сформировать свои

независимые идеи относительно проектировки будущей системы и постоянно

консультироваться с заказчиком, что избежать ошибок на самых ранних этапах

проектирования системы Использование данной модели на практике возможно только

при хороших взаимоотношениях между заказчиком и исполнителем проекта.

Контрольные вопросы и задания

1. Как называется этап ЖЦ разработки ПО, на котором фиксируется контракт

между заказчиком и исполнителем разработки?

2. Назовите действующих лиц процесса формирования требований.

3. Назовите источники сведений о требованиях.

4. Какова последовательность шагов по использованию действующей системы в новой

разработке?

5. Назовите категории классификации требований.

6. Цели и составляющие концептуального моделирования проблемы.

7. Что определяет онтология концептуального моделирования

проблемы?

8. Объясните суть отношений, с помощью которых строятся понятия: обобщение,

декомпозиция, абстракция, ассоциация.

10. Назовите элементы объектно-ориентированного моделирования программных

систем.

11. В чем состоит принцип сокрытия информации?

12. Определите концепция модели сценариев для сбора требований.

13. Дайте пояснения для нотации диаграммы сценариев и базовых отношений в них.

14. Назовите основные типы

объекты модели.

15. Приведите задачи трассировки требований.

16. Расскажите о принципах взаимоотношений между заказчиком и разработчиком

требований к системе.

Литература к теме 3

1. Леонов И.В. Введение в методологию разработки программного обеспечения при

помощи Rational Rose. Требования к системе и способы использования//

igorvleonov@esc.ru

2. Вигерс К.И. Разработка требований к ПО. Москва, 2004.– Русская редакция

Microsoft.–575c.

3. Pamela Zave, Michael Jackson, «Four Dark Corners of Requirements Engineering», ACM

Transactions on Software Engineering, January 1997, №1.

4. Jacobson I., Griss M., Jonsson P. Software Reuse. - N.-Y. - Addиson-Wesley, 1997. -

497p.

5. http:/www.rational.com.uml.html

6. Francisco A. C. Pinheiro, Joseph A. Goguen, «An Object - Oriented tool for Tracing

Requirements», «Software», Mach 1996, № 3.

Тема 4

МЕТОДЫ АНАЛИЗА И ПОСТРОЕНИЯ МОДЕЛЕЙ ПрО

Разработка ПС начинается с анализа предметной области (ПрО), которая

автоматизируется, для выделения в ней объектов, отношений между ними и операций

пополнения объектов модели ПрО новыми детализированными свойствами и

характеристиками. Наиболее разработанным методом программирования является

метод проектирования на основе стандарта и многообразие методов, построенных

на

основе объектно-ориентированного подхода и предназначенных для определения

объектных моделей (ОМ), близких к концептуальным моделям, и позволяющих на

их основе проводить проектирование структуры или архитектуры системы.

На этапе анализа ПрО при построении модели ОМ проводится выявление

функциональных задач и требований к их реализации и выполнению. Требования

формируются разработчиком и

заказчиком совместно, они документируются и

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

Далее рассматривается два направления проектирования архитектуры системы,

основанные на применении:

1) объектно-ориентированных методов (например, OOAS, OOA, OMT и др.);

2) стандартных и общесистемных методов (Гост ГОСТ 34.601-90, ER-

моделирование и др.).

4.1. Объектно–ориентированные методы анализа и построения моделей

ПрО

Наиболее распространенными методами объектно-ориентированного анализа

ПрО, широко используемые в практике программирования являются следующие:

– метод OOAS, позволяющий выделить объекты реального мира ПрО, определить

сущности, свойства и отношения объектов и из них построить информационную

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

(dataflow) [1];

– метод OOA позволяет провести анализ, определить требований к ПрО,

специфицировать потоки данных в ПрО в виде диаграммной модели [2];

– метод SD структурного проектирования структуры системы, данных и программы

преобразования входных данных в выходные с помощью структурных карт Джексона

[3-5];

– методология OOAD позволяет построить модели ПрО с помощью ER-

моделирования, понятий и их отношений с использованием структурных диаграмм,

диаграмм «сущность-связь» и матрицы информационного управления [6, 7];

– объектное OMT моделирование объектной, динамической, функциональной моделей

и взаимодействия объектов [8, 9];

– метод Г.Буча, включающий классы, суперклассы и операции наследования,

полиморфизма и упрятывания информации об объектах, дополненный вариантами

использования Джекобсона для задания сценариев работы системы и задач ПрО и

диаграммными средствами Румбаха, в результате имеем UML-метод для анализа ПрО

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

взаимодействующих объектов [10, 11];

– метод построения объектной эталонной модели в CORBA и предоставления набора

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

функционирования объектных компонентов распределенных приложений [12, 13];

– метод генерации частей систем из готовых компонентов (generative programming),

объединивший в себе возможности ООП, компонентного и аспектного

проектирования и развитый средствами многоразового использования отдельных

членов семейства программ ПрО, функциональные и нефункциональные требования

представляются в модели характеристик и др. [12].

Наиболее используемым практическим методом проектирования объектной

модели ПрО, является метод, реализованный в системе CORBA. Основным элементом

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

ПрО. Объекту соответствует одна или несколько операций обращения к методу

объекта. Объекты группируются в типы, а их экземпляры

в подтипы/супертипы.

Объекты инкапсулируют методы реализации, которые невидимы во внешнем

интерфейсе, операции объектов вызывают этот метод для выполнения. Под влиянием

этих операций объект получает некоторое состояние. Специализация типа определяется

постепенно на этапах стратегии, анализа, проектирования и реализации объектов.

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

Общая характеристика разновидностей объектно

–ориентированных методов

показывает, что они имеют много общих черт (например, ER-моделирование), и свои

специфические особенности. Их разработчики вводили в метод необходимые новые

понятия, которые семантически совпадали с другими, ранее определенными.

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

Предлагаемый метод основан на объектно-ориентированном подходе, теории

множеств и предназначен для выявления сущностей ПрО, формализации представления

объектов и их отношений. При этом при построении концептуальной модели

используются следующие понятия.

Объекты ПрО - это абстрактные образы ПрО с множеством свойств и

характеристик, их определение зависит от уровня абстракции и совокупности

полученных о них знаний. Спецификация объекта включает:

<имя объекта > <концепт>,

где <имя объекта> – идентификатор, строка из литер и десятичных чисел;

< концепт > – некоторый денотат, определяющий объект реального мира в

соответствии с интерпретацией сущности моделируемой ПрО.

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

представляются описанием свойств и характеристик, специфических для ПрО, и

задач, которые выполняются в системе. Пространство ПрО делится на пространство

задач и решений. Пространство задач – это сущности, концепты, понятия ПрО, а

пространство решений – это множество функциональных компонентов, которым

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

Модель ПрО строится с использованием словаря терминов, точных определений

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

системе, а также множества синонимов и классифицированных логических

взаимосвязей между этими терминами.

Концептуальная модель – это модель ПрО из сущностей и отношений, разработанная

без ориентации на программные и технические средства выполнения задач ПрО,

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

Под концептом понимается абстрактное собрание сущностей ПрО, которые имеют

одни и те же характеристики. Все сущности ПрО, которые объединяет концепт

согласуются с характеристиками, которые в системе ассоциируются с атрибутами.

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

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

заведомо определенным набором общих атрибутов для данной группы концептов.

Атрибут - это абстракция, которой владеют все абстрагированные концепты

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

концепта. Множество объединенных в группу атрибутов, имеет идентификатор группы

атрибутов. Множество идентификаторов групп могут быть объединены в класс и иметь

идентификатор класса.

Концепт вместе со своими атрибутами в информационной концептуальной модели

представляется графически или в текстовом виде.

Отношение - это абстракция набора связей, которые имеют место или возникают

между разными видами объектов ПрО, абстрагированные как концепты. Каждая связь

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

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

добавляются вспомогательные атрибуты, ссылки на идентификаторы отношений.

Некоторые отношения образуются как следствие существования других отношений.

Выделение сущностей ПрО проводиться с учетом отличий, определяемых

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

мира, обладают поведением, обусловленным свойствами и отношениями с другими

объектами, структурно упорядочиваются посредством применения теоретико-

множественных операций (принадлежности, объединения, пересечения, разности и др.)

к множеству (классу) объектов для установления отношений между объектами..

Объекты могут находиться в отношениях, или связях между собой.

Различаются статические (постоянные) связи, которые

не изменяются или изменяются

редко, и динамические связи, которые имеют определенные состояния и изменяться на

протяжении сеанса функционирования системы.

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

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

данных является реляционная модель, в которой не разрешается иметь множественные

(повторяемые) значения атрибутов, и

добавление выполняется по таким правилам:

а) в случае связи 1:1 дополнительный атрибут может определяться для одного из

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

связи;

б) в случае связи 1:N дополнительный атрибут предоставляет объекту N экземпляров,

принимающих участие в связи;

в) в случае связи N:M создается ассоциативный объект, который фиксирует пару

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

Такой объект, кроме своего названия, имеет первым атрибутом идентификатор первого

из связанных экземпляров объектов, а вторым атрибутом - идентификатор экземпляра

второго.

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

эволюции может существенно влиять на ход решения соответствующей задачи. Для

таких случаев связи обязательно строится ассоциативный объект и определяется

модель состояний (см. тема 3.). Для представления состояния ассоциативного объекта в

состав его атрибутов добавляется атрибут, который фиксирует его текущее состояние.

Среди определенных действий, которые сопровождают переходы в состояния для

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

ассоциативного объекта (если новая пара экземпляров вступает в связь) и его

уничтожения (если связь

прерывается).

4.1.2. Метод анализа и построения моделей С.Шлаер и С.Меллора

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

множества доменов проблемных областей, каждый из которых представляет собой

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

Продуктом анализа домена есть три модели:

– информационная модель

системы или онтология домена;

– модель состояний объектов, определенных в составе информационной модели (или

онтологии);

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

Ниже рассматриваются эти модели.

4.1.2.1. Информационная модель

Под информационной моделью понимается совокупность объектов предметной области

и связи (отношения) между ними. Представление информационной модели в данном

методе базируется на известной реляционной модели данных. Для построения этой

модели проводится выявление существенных объектов домена и предоставление

им уникальных и значимых (мнемонических) названий. При этом учитываются

следующие возможные категорий объектов:

– реальные предметы мира, имеющие физическое воплощение;

– абстракции физических предметов этого мира;

– абстракции или цели использования этих предметов определяются абстрактными

действиями, изменяющими их состояния;

– взаимодействия - это отношение между объектами;

– спецификации – это представление правил, стандартов, критериев качества и

ограничений на использование системы.

Для классов объектов выбираются уникальные имена, устанавливаются атрибуты и

устанавливаются связи между объектами.

Атрибуты объектов. Для списка выявленных объектов определяются их характерные

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

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

объектов. За атрибутом закрепляется имя, уникальное в границах этого класса.

Для каждого из выбранных атрибутов определяются возможные значения (типы

значений) одним из следующих способов:

– задание числового диапазона;

– перечисление возможных значений;

– ссылка на документ, в котором определены возможные значения;

– правила генерации значений.

Идентификаторы объектов. Для объекта задается идентификатор в виде одного или

нескольких атрибутов, значение или совокупность значений которых однозначно

выделяют экземпляр объекта среди других в классе. Примером идентификатора может

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

плательщика налогов и др. Совокупность таких атрибутов может зависеть от

области определения объекта.

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

Атрибуты объектов представляются как атрибуты отношений согласно следующих

правил:

– каждый экземпляр объекта обязательно имеет одно значение (значение не может быть

неопределенным или отсутствующим);

– атрибут одномерен и не имеет нескольких значений одновременно;

– если идентификатор составляется из нескольких имен атрибутов, все указанные

имена атрибутов, кроме первого, относятся к первому указанному имени объекта.

Связи объектов. После определения состава классов объектов домена и присущих им

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

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

или одного

и того же класса. Рассмотрим несколько видов связи:

1) проект имеет исполнителей, которые заняты в проекте;

2) руководитель управляет исполнителями, т.е. исполнитель подчинен руководителю;

3) исполнитель занимает комнату, т.е. комната занята исполнителем.

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

экземпляра определенного класса объектов находиться в отношениях (связях) с

экземпляром

другого класса или одного и того же класса. Существенной

особенностью связей является количество экземпляров объектов, которые

одновременно могут принимать в них участие.

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

– один к одному (1:1), в связи принимают участие по одному экземпляру с каждой

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

и руководит лично только одним проектом);

– один ко многим (1:n), один экземпляр объекта некоторого класса может

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

или того же класса (пример, руководитель может иметь несколько подчиненных, но у

каждого из них один шеф);

– много ко многим (m: n ), в связи могут принимать участие несколько экземпляров

объектов с каждой стороны.

Метод С.Шлаер и С.Меллора предусматривает специальную графическую нотацию

для фиксации связей, базирующихся на диаграммах метода Чена сущность - связь

(entity–relations) [3] для представления информационной модели проблемной области,

суть которого заключается в следующем.

Связи между объектами

изображаются стрелками, указывающими направление связи.

Возле рамки объекта, принимающей участие в связи, на линии стрелки указывается

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

двунаправленной стрелкой, имеющей по одному "наконечнику" стрелки с каждой

стороны, связь 1:n обозначается стрелкой, имеющей два "наконечника" со стороны

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

наконец, по два "наконечника" с каждой стороны имеет стрелка, означающая связь

вида n : m.

Над стрелкой может указываться название (имя) связи. Связи могут быть

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

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

участия в связи,

и обозначаются буквой "у" в конце стрелки.

Отношение, имеющее особый вес для представления онтологии и выражающее

общность и различие между классами объектов, является отношением наследования .

Оно представляется с помощью, так называемой, диаграммы классов. На рис.4.1.

приведен пример такой диаграммы.

Матрица

– тип элемента

– количество строк

– количество столбцов

Матрица с неполным

заполнением

является

Диагональная Ленточная Разреженная

Рис.4.1. Пример диаграммы класса

Построенная диаграмма информационной модели сопровождается неформальным

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

участие.

4.1.2.2. Модель состояний

Данная модель предназначена для отображения динамики изменений, происходящих в

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

одного класса объектов согласно понятия класса имеют одинаковое поведение.

Базовыми понятиями модели динамики поведения объектов являются:

– состояние объекта, которое определяется текущими значениями отдельных его

атрибутов;

– состояние объекта изменяется в результате произошедших действий или стимулов;

– состояние домена, которое определяется совокупностью состояний его объектов;

– изменение состояния объекта сопровождается некоторыми процессами, которые

определены для каждого состояния.

Для фиксации динамических аспектов требований как отражения поведения

объектов в рассматриваемом методе предложены две альтернативные нотации:

графическая, которая называется диаграммой переходов состояний (ДПС) и

табличная, которая называется таблицей переходов состояний (ТПС).

Построение модели состояний начинается с выделения среди определенных в

информационной модели классов объектов тех, которые имеют динамическое

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

имеют жизненный цикл от создания экземпляра объекта и до его разрушения.

Для каждого из выделенных объектов определяются:

1) множество состояний, в которых объект может находиться;

2) множество инцидентов или событий, которые побуждают экземпляры класса

изменять свое состояние;

3) правила перехода для каждого из зафиксированных состояний, как указание на новое

состояние экземпляра данного класса, если произойдет некоторое событие из

множества событий тогда, когда объект находится

в данном состоянии;

4) действия или процессы для каждого из определенных состояний, которые

выполняются при переходе в данное состояние.

Для представления этой информации в нотации диаграммы перехода состояний

предусматривается следующее:

– каждое состояние, определенное для класса объектов, получает название и

порядковый номер, уникальную метку и название;

– состояние обозначается рамкой, содержащей номер

и название состояния;

– переход от состояния к состоянию изображается направленной дугой, помеченной

меткою и названием события, обусловившего переход;

– начальное состояние обозначается стрелкой, направленной к соответствующей

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

создания (или инициализации);

– заключительное состояние задает конец жизненного цикла экземпляра объекта, если

экземпляр продолжает существовать или разрушается, обозначается оно пунктирной

рамкой;

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

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

Для изменения состояния экземпляра класса объектов выполняются действия:

– обработка информации, переданной в сообщении о событии;

– изменение определенного атрибута объекта;

– вычисления;

– генерация операции для некоторого экземпляра класса;

– генерация события, сообщение о котором должно передается внешнему по

отношению к данному домену объекту (например, человеку-оператору другой

системе);

– передача сообщения о событии от внешних объектов;

– взаимодействие с двумя специфическими объектами – таймером и системными

часами, где таймер служит для измерения интервала времени и встроен системным

образом в данный метод.

Атрибутами таймера являются:

– уникальный идентификатор экземпляра таймера;

– интервал времени, через который будет подан сигнал о наступлении некоторого

события;

– метка наступающего события, при условии, что остаток времени равен нулю;

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

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

(например, духовой шкаф печи) для определения наступления события, данными

которого есть значения атрибутов таймера. Предусмотрены события для установки

таймера в нуль и

его уничтожения.

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

которого можно читать его атрибуты - показатели системного времени (минуты,

часы, день, месяц, год).

Альтернативой для графической нотации диаграммы перехода состояний является

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

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

объект событий - столбцом. Клетка таблицы перехода состояний определяет состояние,

которое приобретает объект, если соответствующее столбику событие произойдет,

когда он находился в состоянии, соответствующему строке. При этом допускается,

чтобы некоторые комбинации событие / состояние не приведут к изменению состояния

экземпляра объекта. Такие клетки таблицы содержат указание "событие игнорируется".

Отдельные комбинации событие / состояние могут быть запрещены, тогда в

соответствующих клетках помещается текст "не может быть". Заметим, что при

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

определяются отдельной нотацией.

При выборе диаграммы или таблицы состояний перехода аргумент будет в пользу

диаграммы из–за ее наглядности и определенности действий, тогда как табличная

форма служит для фиксации всех возможных комбинаций состояние/событие, чем

обеспечивается полнота и непротиворечивость заданных требований. Все сказанное