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

Содержание:

ВВЕДЕНИЕ

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

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

Общий процесс объектно-ориентированного проектирования состоит из нескольких крупных этапов:

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

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

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

1. КОНЦЕПЦИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

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

Таблица 1

Основные компоненты объектно-ориентированного проектирования программных средств

Компоненты	Содержание и функции
I Классы	Объединения однородных объектов, имеющих одинаковые атрибуты, структуру и поведение
Объекты	Реальности (сущности), описываемые границами, индивидуальными состояниями и поведением
Атрибуты	Характеристики класса, отражающие идентификацию, состояние и поведение конкретного объекта этого класса
Ассоциации	Отношение между классами, отражающее связи между объектами этих классов
Интерфейсы	Множества операций взаимодействия между объектами
Сообщения	Взаимодействия объектов, имеющие стимулы, отправителя и получателя
Операции	Возможные воздействия объекта на другой объект того же класса с целью вызвать отклик
Состояние	Ситуация, в течение которой объект выполняет деятельность или ожидает события
Инкапсуляция	Выделение и сокрытие части информации об объекте
Наследование	Совместное использование атрибутов и поведения объектов в пределах иерархической структуры для построения новых классов
Диаграмма последовательности	Диаграмма взаимодействия объектов, упорядоченных по времени их проявления

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

Существует ряд подходов к определению классов объектов:

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

— использование в качестве объектов ПС событий, объектов и ситуаций реального мира из области приложения (например самолетов, ролевых ситуаций менеджера) для реализации таких объектов, могут потребоваться специальные структуры хранения данных (абстрактные структуры данных);

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

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

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

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

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

— материальный предмет (или индивидуум);

— выполняемая роль;

— событие;

— взаимодействие (контракт);

— операционная процедура (обзор);

— организационная единица;

— место (банк);

— структура.

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

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

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

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

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

— представление с помощью существительного;

— описание объекта в терминах реального времени;

— возможность служить индикатором состояния;

— обладание типом данных;

— идентичность для объектов одного класса — может отличаться по значению, но не по сути;

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

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

— инкапсулирование внутри объекта;

— отклик на стимул-(сообщение);

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

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

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

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

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

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

Наследование определяет совместное использование атрибутов и поведение объектов в пределах иерархической структуры (суперклассов и/или подклассов). Каждый подкласс наследует все свойства — (атрибуты и операции) суперкласса (предка) и добавляет свои собственные уникальные свойства. Класс содержит описание всех атрибутов, ассоциаций и операций, входящих в объект, что является обобщением объекта. Каждый класс имеет набор наследуемых свойств — атрибутов, операций и ассоциаций. Эти структуры данных и алгоритмы немедленно становятся доступными для подклассов наследников. Класс может иметь потомков (подклассы), где потомок является специализацией предшественника. Потомок наследует (включает в себя) эту структуру и поведение общих предшественников, при этом он способен добавлять свои собственные атрибуты и операции. Такое отношение также известно как обобщение (генерализация). Наследование/специализация/обобщение является преимуществом метода ООП, поскольку поддерживает повторное использование классов. Благодаря применению этих понятий свойства суперклассов повторяются в каждом объекте подкласса, и таким образом поддерживается высокий фактор обновления. Изменения для атрибутов или операций немедленно наследуются всеми подклассами.

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

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

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

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

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

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

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

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

Язык моделирования UML не имеет определенных обозначений для типа моделей данных, что желательно для объектно-ориентированного процесса разработки ПС, где для описания систем используются объекты и их отношения. Если сущностям поставить в соответствие простейшие классы объектов (без ассоциированных методов), тогда в качестве моделей данных можно использовать модели классов UML совместно с именованными ассоциациями между классами.

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

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

— одни и те же динамические и статические модели описывают в разработке только «способы» взаимодействия с объектами;

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

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

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

— статические модели, которые описывают структуру системы в терминах классов объектов и взаимоотношений между ними, которые документируются на данном этапе, являются отношениями обобщения, отношениями «используют — используются» и структурными отношениями;

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

В языке моделирования UML поддерживается ряд возможных статических и динамических моделей:

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

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

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

Модель подсистемы является одной из наиболее важных и полезных статических моделей, поскольку показывает, как можно организовать систему в виде логически связанных групп объектов. В UML пакеты являются структурами инкапсуляции и не отображаются непосредственно в объектах разрабатываемой системы. Существует несколько способов создания, применения и введения новых определений для моделей ООП с использованием диаграмм вариантов использования сценариев, диаграмм действий, диаграмм класс/объект, а также диаграмм сотрудничества, взаимодействия, перехода состояния, контекста данных и словаря данных. Некоторые вводятся сверху-вниз, другие — снизу-вверх, и все они итеративно определяются заново с помощью сотрудничества.

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

Статическое представление объектно-ориентированной разработки проекта — диаграммы взаимодействия и сотрудничества отображают взаимодействия, которые пространственно ориентированы на окружение модели и характеризуют классы и ассоциации (экземпляры и связи). Целью сотрудничества является определение способов реализации вариантов использования. Диаграмма сотрудничества отображает отношения между экземплярами объектов. Поведение реализуется с помощью набора объектов, обменивающихся входными сигналами в рамках общего взаимодействия, что позволяет достичь поставленной цели. Для представления механизмов, применяемых при разработке, важно обращать внимание только на определенные объекты и изучать взаимодействие между ним. Рассматриваемые объекты всегда выделяются из большей системы, в которой данные объекты являются лишь компонентами.

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

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

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

Механизм состояния определяет набор понятий, которые могут использоваться для моделирования дискретного поведения с помощью конечных систем переходных состояний. Экземпляры событий генерируются в результате определенного действия в пределах системы или ее окружения. Затем событие ориентируется на одну или несколько целей. Средства, с помощью которых экземпляры событий транспортируются к месту назначения, зависят от типа действия, цели, свойств среды коммуникации и многих других факторов. В некоторых случаях это происходит практически мгновенно и вполне надежно, в то время как в других случаях могут происходить периодические задержки передачи, потеря событий, переупорядочивание или дублирование. Поддерживается полная гибкость при моделировании различных типов коммуникационных возможностей. Событие получено, если оно размещено в очереди событий по целевому назначению. Событие отправлено, если оно извлечено из очереди событий и доставлено к механизму состояния для обработки. С этой точки зрения на него ссылаются как на текущее событие. Наконец, событие поглощено, если завершена его обработка. Поглощенное событие становится недоступным для обработки. Никакие требования не предъявляются к интервалам времени между получением события, отправлением и поглощением.

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

2. МЕТОДЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

К проектированию ИС непосредственное отношение имеют два направления деятельности:

1) проектирование ИС конкретных организаций на базе готовых программных и аппаратных компонентов;

2) проектирование компонентов ИС и инструментальных средств, ориентированных на многократное применение при разработке многих конкретных автоматизированных систем.

Сущность первого направления можно охарактеризовать словами «системная интеграция» (другое близкое понятие имеет название консалтинг). Разработчик ИС должен быть специалистом в области системотехники, хорошо знать соответствующие международные стандарты, состояние и тенденции развития информационных технологий и программных продуктов, владеть инструментальными средствами разработки приложений (CASE-средствами) и быть готовым к восприятию и анализу автоматизируемых процессов в сотрудничестве со специалистами-прикладниками.

Существует ряд фирм, специализирующихся на разработке проектов ИС (например, Price Waterhouse, ЛАНИТ, LUXOFT и др.)

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

В России действует государственный стандарт на стадии создания автоматизированных систем ГОСТ 34.601-90.(ПРИЛОЖЕНИЕ 2) Существует и международный стандарт на стадии жизненного цикла программной продукции (ISO 12207:1995). (ПРИЛОЖЕНИЕ 1) Как собственно ИС, так и компоненты ИС являются сложными системами, и при их проектировании нужно использовать один из стилей проектирования:

• нисходящее (Top-of-Design), четкая реализация нисходящего

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

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

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

относящаяся к поочередной реализации частей системы);

• восходящее (Bottom-of-Design);
• эволюционное (Middle-of-Design).

Чаще всего применяют нисходящий стиль блочно-иерархического проектирования.

Рассмотрим этапы нисходящего проектирования ИС.

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

Предпроектные исследования проводят путем анализа деятельности предприятия (компании, учреждения, офиса), на котором создает или модернизируется ИС. При этом нужно получить, ответы на вопросы:

1. Что устраивает в существующей технологии?

2. Что можно улучшить?

3. Кому это нужно и, следовательно, каков будет эффект?

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

На основе анализа результатов обследования строят модель, отражающую деятельность предприятия на данный момент (до реорганизации). Такую модель называют «As Is (как есть). Далее разрабатывают исходную концепцию ИС. Эта концепция включает в себя предложения по изменению структуры предприятия, взаимодействию подразделений, информационным потокам, что выражается в модели «To Be» (Как должно быть).

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

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

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

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

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

При концептуальном проектировании применяют ряд спецификаций, среди которых центральное место занимают модели преобразования, хранения и передачи информации. Модели, полученные в процессе обследования предприятия, являются моделями его функционирования. В процессе разработки ИС модели, как правило, претерпевают существенные изменения (переход or «As Is» к «То Be») и в окончательном виде модель «То Ве» рассматривают в качестве модели проектируемой ИС.

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

• Функциональная модель системы описывает совокупность выполняемых

системой функций.

• Информационная модель отражает структуры данных – их состав и

взаимосвязи.

• Поведенческая модель описывает информационные процессы (динамику

функционирования), в ней фигурируют такие категории, как состояние

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

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

• Структурная модель характеризует построение системы – состав подсистем, их взаимосвязи.

Содержанием последующих этапов нисходящего проектирования (согласно ГОСТ 34.601-90, это стадия разработки технического проекта, рабочей документации, ввода в действие) являются уточнение перечней приобретаемого оборудования и готовых программных продуктов, построение системной среды, детальное инфологическое проектирование баз данных и их первоначальное наполнение, разработка собственного оригинального ПО, которая, в свою очередь, делится на ряд этапов нисходящего проектирования. Эти работы составляют содержание рабочего проектирования. После этого следуют закупка и инсталляция программно-аппаратных средств, внедрение и опытная эксплуатация системы.

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

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

3. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

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

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

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

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

— словарь данных хранит информацию об объектах, которые используются в структуре системы;

— средства генерирования отчетов на основе информации из центрального репозитория автоматически генерируют системную документацию;

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

— средства импортирования и экспортирования позволяют обмениваться информацией из центрального репозитория различным инструментальным средствам;

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

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

4. ПРЕИМУЩЕСТВА И НЕДОСТАТКИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

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

4.1 Преимущества объектно-ориентированного проектирования

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

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

• Апелляция к когнитивным способностям человека.

• Создание гибких систем, допускающих модификацию.

• Стимулирование повторного использования программных компонент.

• Уменьшение риска, связанного с разработкой.

• Использование выразительной мощи объектно-ориентированных языков программирования.

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

4.2 Недостатки объектно-ориентированного проектирования

Теневой стороной объектно-ориентированной технологии являются связанные с ней риски. Новаторское исследование этих рисков было проведено в статье Хантоса (Hantos), который указал, что "классические объектно-ориентированные концепции Бертрана Мейера (Bertrand Meyer) превратились в список десяти основных не зависящих от методологии программирования рисков, предложенный Барри Боемом (Barry Boehm)". Анализируя работу Мейера, Хантос сформулировал следующий список объектно-ориентированных концепций, которые были преобразованы в список рисков Боема.

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

данных.

• Сокрытие информации с помощью абстракции и инкапсуляции.

• Наследование, позволяющее организовывать родственные элементы.

• Полиморфизм, позволяющий выполнять операции, которые можно

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

• Специальные методы анализа и проектирования.

• Объектно-ориентированные языки.

• Среды разработки, облегчающие создание объектно-ориентированных

систем.

• Разработка по контракту — мощный метод для решения проблем,

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

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

участки.

• Распределение объектов, облегчающее создание мощных распределенных

систем.

• Объектные базы данных, позволяющие преодолеть границы типов данных

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

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

1. Дефицит кадров.

2. Нереалистичные графики работ, сметы и процессы.

3. Дефицит готовых коммерческих продуктов, внешних компонентов и

наследуемого программного обеспечения.

4. Недостатки архитектуры, эффективности или пользовательского

интерфейса.

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

6. Непрерывный поток изменяющихся требований.

7. Недостатки сторонних субподрядчиков.

8. Развитие компьютерных наук.

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

Хантос изобразил полученные результаты в виде диаграммы отображения, из которой следует, что риски традиционной разработки программного обеспечения, указанные Боемом, характерны и для объектно-ориентированного анализа и проектирования. В качестве положительного свойства Хантос показал, что некоторые понятия объектно-ориентированного анализа и проектирования позволяют уменьшить риски, описанные Мейером. В частности, концепция "архитектуры и экземпляров" позволяет уменьшить риск, связанный с "непрерывным потоком изменяющихся требований" и "недостатками сторонних субподрядчиков". Концепция "абстракции и инкапсуляции" также позволяет уменьшить риск, связанный с "непрерывным потоком изменяющихся требований".

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Балдин, К. В. Информатика: учеб, для вузов / К. В. Балдин, В. Б. Уткин. М.: Проект, 2003. 304 с.
2. Беляев, М. А. Основы информатики: учеб, для вузов / М. А. Беляев, В. В. Лысенко, Л. А. Малинина. Ростов-н/Д: Феникс, 2006. 352 с.
3. Брукшир, Д. Информатика и вычислительная техника / Д. Брукшир. СПб.: Питер, 2004. 620 с.
4. Головко, В. А. Нейронные сети: обучение, организация и применение: учеб, пособие для вузов / В. А. Головко. М.: ИПРЖР, 2001. Кн. 4. 256 с.

ПРИЛОЖЕНИЕ 1

Международный стандарт ISO/IEC 12207: 1995-08-01

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

Стандарт ISO/IEC 12207 состоит из крупных обобщенных процессов: приобретение,поставка, разработка и т.д.

В стандарте ISO/IEC 12207 описаны пять основных процессов жизненного цикла программного обеспечения:

1) процесс приобретения определяет действия предприятия - покупателя информационной системы, программного продукта или службы программного обеспечения;

2) процесс поставки определяет действия предприятия-поставщика по снабжению покупателя информационной системой, программным продуктом или службы программного обеспечения;

3) процесс разработки определяет действия предприятия-разработчика, который разрабатывает принципы построения программного изделия и собственно программный продукт;

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

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

Кроме пяти основных процессов, ISO/IEC 12207 оговаривает восемь вспомогательных процессов, которые являются неотъемлемой частью всего жизненного цикла системы:

1) процесс решения проблем;

2) процесс документирования;

3) процесс управления конфигурацией;

4) процесс обеспечения качества;

5) процесс верификации;

6) процесс аттестации;

7) процесс совместной оценки;

8) процесс аудита.

В стандарте ISO/IEC 12207 также определяются четыре организационных процесса:

1) процесс управления;

2) процесс создания инфраструктуры;

3) процесс усовершенствования;

4) процесс обучения.

В стандарте ISO/IEC 12207 имеется дополнительный процесс, позволяющий адаптировать стандарт к условиям конкретного проекта.

Рассмотрим особенности стандарта ISO/IEC 12207.

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

Ценность стандарта ISO/IEC 12207 заключается в том, что он дает набор задач, характеристик качества, критериев оценки, охватывающих все проектные ситуации. Например, для характеристики требования к программному обеспечению предусмотрено 10 классов характеристик качества:

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

2) внешние связи (интерфейс) с единицей программного обеспечения;

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

4) спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и травм персонала;

5) спецификации защищенности информации;

6) человеческие факторы (по эргономике и инженерной психологии);

7) определение данных и требований к базам данных;

8) установочные и приемочные требования поставляемого программного продукта в местах эксплуатации;

9) документация пользователя;

10) требования сервиса пользователя.

При использовании стандарта стороны-участники ответственны:

1) за выбор модели жизненного цикла для разрабатываемого проекта;

2) адаптацию процессов и задач к этой модели;

3) выбор и применение методов разработки программного обеспечения;

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

ПРИЛОЖЕНИЕ 2

ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств.

5.2.2.2 Специальные процессы программных средств

5.2.2.2.1 Процессы реализации программных средств

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

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

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

а) процесс анализа требований к программным средствам;

b) процесс проектирования архитектуры программных средств;

c) процесс детального проектирования программных средств;

d) процесс конструирования программных средств;

e) процесс комплексирования программных средств;

f) процесс квалификационного тестирования программных средств.

5.2.2.2.2 Процессы поддержки программных средств

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

a) процесс менеджмента документации программных средств;

b) процесс менеджмента конфигурации программных средств;

c) процесс обеспечения гарантии качества программных средств;

d) процесс верификации программных средств;

e) процесс валидации программных средств;

f) процесс ревизии программных средств;

g) процесс аудита программных средств;

h) процесс решения проблем в программных средствах.

5.2.2.2.3 Процессы повторного применения программных средств

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

Процессами повторного применения программных средств являются:

a) процесс проектирования доменов;

b) процесс менеджмента повторного применения активов;

c) процесс менеджмента повторного применения программ