К оглавлению

Моделирование программных систем

Настоящая статья открывает цикл, посвященный объектно-ориентированному (ОО) языку моделирования Unified Modeling Language (UML) и технологии разработки программного обеспечения Rational Unified Process (RUP). Цель написания статей данного цикла состоит в том, чтобы, не вдаваясь в детали, дать читателю общее представление о языке UML, являющимся стандартом ОО моделирования, и изложить начала процесса разработки программных систем (ПС) объектно-ориентированным методом, предполагающим использование UML.

Объектно-ориентированный подход

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

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

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

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

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

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

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

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

Для чего нужно моделирование

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

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

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

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

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

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

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

Еще раз следует подчеркнуть, что главное достоинство моделей – представление информации в наглядной графической форме. Для одинакового понимания графического представления разными людьми графическая нотация должна быть унифицирована, то есть должен использоваться язык, определяющий такую нотацию и ее семантику. Именно таковым и является Unified Modeling Language (UML).

Далее >>