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

- модель состоит из  последовательно расположенных  этапов (как и «водопад») в пределах  одного витка спирали;

- внутри витка спирали  этапы не имеют обратной связи. Анализ результата осуществляется  в конце витка и инициирует  новый виток спирали;

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

- этапы могут перекрываться  во времени в пределах одного  витка спирали;

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

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

- процесс ориентирован  на развитие и модификацию  системы в процессе ее проектирования, на анализ рисков и издержек в процессе проектирования.

Рисунок 3 - Спиральная модель жизненного цикла.

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

Специалистами отмечаются следующие преимущества спиральной модели:

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

• ориентация на развитие и модификацию системы в процессе ее проектирования;

• анализ риска и издержек в процессе проектирования.

Именно поэтому спиральная модель служит в настоящее время основой для создания методологий проектирования систем.

1.5. Унифицированный язык  моделирования  UML

 

Мощный толчок к разработке унифицированного языка объектно-ориентированного моделирования Unified Modeling Language (UML)  дало распространение объектно-ориентированных языков программирования в конце 1980-х — начале 1990-х годов. Пользователям хотелось получить единый язык моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода и давал бы четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (Grady Booch), OMT-2 (Jim Rumbaugh), OOSE — Object-Oriented Software Engineering (Ivar Jacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, OMT-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки.

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

Создание UML началось в октябре 1994 г., когда Джим Рамбо и Гради Буч из Rational Software Corporation стали работать над объединением своих методов OMT и Booch. Осенью 1995 г. увидела свет первая черновая версия объединенной методологии, которую они назвали Unified Method 0.8. После присоединения в конце 1995 г. к Rational Software Corporation Айвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее распространенных объектно-ориентированных методологий были объединены и направлены на создание UML.

В настоящее время консорциум пользователей UML Partners включает в себя представителей таких грандов информационных технологий, как Rational Software, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, Platinum Technology.

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

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

UML — это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

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

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

1.5.1. Виды диаграмм

 

В UML выделяют девять типов диаграмм:

• диаграммы классов (Class Diagrams);
• диаграммы объектов (Object Diagrams);
• диаграммы прецедентов/ вариантов использования (Use Case Diagrams);
• диаграммы последовательностей (Sequence Diagrams);
• диаграммы кооперации/ сотрудничества (Collaboration Diagrams);
• диаграммы состояний (Statechart Diagrams);
• диаграммы деятельности (Activity Diagrams);
• диаграммы компонентов (Component Diagrams);
• диаграммы развертывания/ размещения (Deployment Diagrams).

Рассмотрим некоторые из них.

 

1.5.2. Диаграммы вариантов  использования

 

Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. «Каждая функциональность» изображается в виде «прецедентов использования»  или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой, которое при этом:

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

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

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

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

 
Рисунок 4 - Связи на диаграммах прецедентов.

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

 

1.5.3. Диаграммы классов

 

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

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

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

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

На рис. 5 приведено графическое изображение класса «Заказ» в нотации UML.

 
Рисунок 5 -  Изображение класса в UML.

Видимость свойства указывает на возможность его использования другими классами. Один класс может «видеть» другой, если тот находится в области действия первого и между ними существует явное или неявное отношение. В языке UML определены три уровня видимости:

• public (общий) — любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции;
• protected (защищенный) — только любой потомок данного класса может пользоваться его защищенными свойствами. Обозначаются знаком «#»;
• private (закрытый) — только данный класс может пользоваться этими свойствами. Обозначаются символом «-» .

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

• instance (экземпляр) — у каждого экземпляра класса есть собственное значение данного свойства;
• classifier (классификатор) — все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием).

Возможное количество экземпляров класса называется его кратностью. В UML можно определять следующие разновидности классов:

• не содержащие ни одного экземпляра — тогда класс становится служебным (Abstract);
• содержащие ровно один экземпляр (Singleton);
• содержащие заданное число экземпляров;
• содержащие произвольное число экземпляров.

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

Между классами возможны различные отношения, представленные на рис. 6:

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

 
Рисунок 6 - Отображение связей между классами.

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

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

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