Методы первичного сбора требований. Модели системы. Языки специфики требований. Оценка требований

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

Табл.1. Пример словаря  данных

Объектные модели

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

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

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

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

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

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

Идентификация объектов и  классов объектов считается наиболее сложной задачей в процессе объектно-ориентированной разработки систем. Определение объектов — это основа для анализа и проектирования системы.

Рис.7 Часть иерархии классов для библиотечной системы.

В UML класс объектов представлен  вертикально ориентированным прямоугольником  с тремя секциями (рис. 7).

1. В верхней секции располагается имя класса.
2. Атрибуты класса находятся в средней секции.
3. Операции, связанные с классом, приводятся в нижней секции прямоугольника.

 

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

 Модели наследования

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

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

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

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

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

Агрегирование объектов

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

Моделирование поведения объектов

Модели поведения объектов показывают операции, выполняемые объектами. В UML поведение объектов моделируется посредством сценариев. Кроме диаграмм последовательностей в UML предусмотрены также кооперативные диаграммы (collaboration diagrams4), показывающие последовательность сообщений, которыми обмениваются объекты. Они подобны диаграммам последовательностей, и здесь я па них не останавливаюсь.

  Инструментальные CASE-средства

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

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

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

Обычно туда входят:

1. Редакторы диаграмм предназначены для создания диаграмм потоков данных, иерархий объектов, диаграмм "сущность-связь" и т.д. Эти редакторы не только имеют средства рисования, но и поддерживают различные типы объектов, используемые в диаграммах.
2. Средства проектирования, анализа и проверки выполняют проектирование ПО и создают отчет об ошибках и дефектах в системной архитектуре. Они могут работать совместно с системой редактирования, поэтому обнаруженные ошибки можно устранить на ранней стадии процесса проектирования.
3. Центральный репозиторий позволяет проектировщику найти нужный проект и соответствующую проектную информацию.
4. Словарь данных хранит информацию об объектах, которые используются в структуре системы.
5. Средства генерирования отчетов на основе информации из центрального репозитория автоматически генерируют системную документацию.
6. Средства создания форм определяют форматы документов и экранных форм.
7. Средства импортирования и экспортирования позволяют обмениваться информацией из центрального репозитория различным инструментальным средствам.
8. Генераторы программного кода автоматически генерируют программы на основе проектов, хранящихся в центральном репозиторий.

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ОЦЕНКА  ТРЕБОВАНИЙ (ГОСТ Р ИСО/МЭК 12207)

 

Один из базовых стандартов в  области ИТ –ГОСТ Р ИСО/МЭК 12207 «Системная и программная инженерия. Процессы жизненного цикла программных  средств», введен в действие весной 2012 года. Это стандарт, определяющий процессы, которые описывают весь жизненный цикл ПО (программной системы), начиная с определения требований заказчиков к будущей системе  и заканчивая снятием ПО с эксплуатации. Он лежит в основе практически  всех современных промышленных технологий создания и эксплуатации ПО. 

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

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

Методологическая основа ГОСТ Р  ИСО/МЭК 12207 - разбиение процессов  на группы, которых в стандарте  вводится три»

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

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

Номера процессов в таблице соответствуют номерам разделов документа.

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

Таблица 2. Структура процессов жизненного цикла программных систем по ГОСТ Р ИСО/МЭК 12207

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

Задача (задание) должна(о) быть выражена(о) в виде требования, самообъявления, рекомендации или допустимого действия. С этой целью в ГОСТ Р ИСО/МЭК 12207 тщательно отобраны некоторые  вспомогательные глаголы для  выделения различий между видами задач:

- глагол "должна (shall)" использован  для выражения соглашения между  двумя или более сторонами;

- глагол "будет (will)" выражает объявление цели или  намерения одной из сторон;