Шаблоны или классы, которые параметризуются

План

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

1.2 Интерфейсы

1.3 Объекты

1.4 Шаблоны или классы, которые параметризуются

1.5 Рекомендации по построению диаграмм классов

1.6 Архитектура

1.7 Жизненный цикл разработки ПО

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

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

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

Для выделения или идентификации компонентов наглядной области было предложено несколько способов и правил. Сам этот процесс получил название концептуализации наглядной области. При этом под компонентой понимают некоторую абстрактную единицу, которая владеет функциональностью, то есть может производить определенные действия, связанные с решением поставленных заданий. На предыдущем этапе концептуализации рекомендуется использовать так называемые CRC -карточки (Component, Responsibility, Collaborator - компоненту, обязанность, сотрудники)[1]. Для каждой выделенной компоненты наглядной области разрабатывается собственная CRC -карточка (рис. 1.1).

Рис. 1.1. Общий вид CRC -карточки для описания компонентов наглядной области

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

Разделение процесса разработки сложных программных приложений на отдельные этапы способствовало становлению концепции жизненного цикла программы. Под жизненным циклом (ЖЦ) программы понимают совокупность взаимосвязанных и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее использования. Стандарт ISO/IEC 12207, хотя и описывает общую структуру ЖЦ программы, не конкретизирует деталь выполнения тех или других этапов. Согласно принятым взглядам ЖЦ программы состоит из следующих этапов:

Анализа наглядной области и формулировки требований к программе

Проектирование структуры программы

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

Внедрение программы

Сопровождения программы

Отказы от использования программы

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

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

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

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

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

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). Появление первых CASE -средств было встречено с определенной настороженностью. Со временем появились как захваченные Отзывы об их приложении, так и критические оценки их возможностей. Причин для таких противоречивых мыслей было несколько. Первая из них заключается в том, что ранние CASE -средства были простой надстройкой над некоторой системой управления базами данных (СУБД). Хотя визуализация процесса разработки концептуальной схемы БД имеет важное значение, она не разрешает проблем разработки дополнений других типов.

Вторая причина имеет более сложную природу, поскольку связана с графической нотацией, реализованной в том или другом CASE -средстве. Если языки программирования имеют строгий синтаксис, то попытки предложить соответствующий синтаксис для визуального представления концептуальных схем БД были восприняты далеко неоднозначно. Появилось несколько подходов, которые детальнее будут рассмотрены в разделе 2. На этом фоне появление унифицированного языка моделирования (Unified Modeling Language, UML), который ориентирован на решение заданий первых двух этапов ЖЦ программ, было воспринято с большим оптимизмом всем содружеством корпоративных программистов.

Аббревиатура UML допускает соответствующий перевод и дальнейшее сокращение, но принимая во внимание нелегкость для чтения "УЯМ", которое выходит, было решено употреблять начальный термин на всем протяжении книги. Частично это можно объяснить традицией применение оригинальных терминов, что уже сложилась, таких как CASE, RAD, DLL, ISDN и целого ряда других.

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

Интерфейсы

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

Рис. 1.2. Пример графического изображения интерфейса на диаграмме классов

Объекты

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

Для графического изображения объектов используется такой же символ прямоугольника, что и для классов. Отличия оказываются при указании имен объектов, которые в случае объектов обязательно подчеркиваются (рис. 1.3). При этом запись имени объекта есть рядком тексту "имя объекта :имя класса", разделенную двоеточием (рис. 1.3 а, б). Имя объекта может быть отсутствующим, в этом случае предусматривается, что объект является анонимным, и двоеточие указывает на данное обстоятельство (рис. 1.3, г). Быть отсутствующим может и имя класса. Тогда указывается просто имя объекта (рис. 1.3, в). Атрибуты объектов принимают конкретные значения.

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

Рис. 1.3. Пример графического изображения объектов на диаграммах языка UML

Шаблоны или классы, которые параметризуются

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

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

Рис. 1.4. Графическое изображение шаблона на диаграмме классов

Шаблон не может быть непосредственно использован в качестве класс, поскольку содержит неопределенные параметры. Чаще всего как шаблон выступает некоторый суперкласс, параметры которого уточняются в его классах-потомках. Очевидно, в этом случае между ними существует отношение зависимости с ключевым словом "bind", когда класс-клиент может использовать некоторый шаблон для своей дальнейшей параметризации. В более редком случае между шаблоном и формуемым от него классом имеет место отношение обобщения с преемничеством свойств шаблона (рис. 1.5). В данном примере отмечен тот факт, что класс "Адрес" может быть получен из шаблона Связний_спісок на основе актуализации формальных параметров "S, к, l" фактическими атрибутами "улица, дом, квартира".

Этот же шаблон может использоваться для задания (инстанцирования) другого класса, скажем, классу "Точки_на_плоськості". В этом случае класс "Точки_на_плоськості" актуализирует те же формальные параметры, но с другими значениями, например, "Ьтсг<коордінати_точки, х, в>. Концепция шаблонов является достаточно могучим средством в ООП, и потому ее использование в языке UML позволяет не только сократить размеры диаграмм, но и корректнее всего управлять преемничеством свойств и поведения отдельных элементов модели.

Рис. 1.5. Пример использования шаблона на диаграмме классов

Не нашли, что искали? Воспользуйтесь поиском по сайту: