В связи с этим значение языка UML существенно возрастает, поскольку он все более приобретает черты языка представления знаний. При этом наличие в языке UML изобразительных средств для представления структуры и поведения модели позволяет достичь адекватного представления декларативных и процедурных знаний и, что не менее важно, установить между этими формами знаний семантическое соответствие. Все эти особенности языка UML позволяют сделать вывод о том, что он имеет самые серьезные перспективы уже в ближайшем будущем.
Принято считать, что сам термин алгоритм происходит от имени средневекового математика Аль- Хорезми, который в 825 г. описал правила выполнения арифметических действий в десятичной системе счисления.
Появление и интенсивное использование условных операторов и оператора безусловного перехода стало предметом острых дискуссий среди специалистов по программированию. Дело в том, что бесконтрольное применение в программе оператора безусловного перехода goto способно серьезно осложнить понимание кода. Соответствующие программы стали сравнивать со спагетти, называя их bowl of spaghetti, имея в виду многочисленные переходы от одного фрагмента программы к другому, или, что еще хуже, возврат от конечных операторов программы к ее начальным операторам. Ситуация казалась настолько драматичной, что в литературе зазвучали призывы исключить оператор goto из языков программирования. Именно с этого времени принято считать хорошим стилем программирования – программирование без goto.
Сейчас попытки оценить профессионализм программиста количеством строк программного кода могут вызвать лишь улыбку собеседника. Действительно, используя встроенные мастера современных инструментариев разработки (MS Visual C++ или Inprise/Borland Delphi), даже новичок может за считанные секунды последовательным нажатием кнопок диалоговых меню создать работоспособное приложение, содержащее сотни строк программного кода и состоящее из десятка отдельных файлов проекта.
Приведенное выше определение класса является достаточно общим. В последующих главах по мере изучения материала этот термин будет уточняться на основе установления семантических связей с другими понятиями объектно-ориентированного анализа и проектирования.
Как будет видно из дальнейшего изложения, иерархическая схема организации понятий не тождественна иерархии классов, поскольку взаимосвязи между классами могут иметь и другие качественные особенности. С другой стороны, иерархия понятий является более общей категорией по сравнению с иерархией уровней абстракции классов ООП.
Степень затемнения фона на приведенном выше рисунке имеет более глубокий смысл, чем может показаться на первый взгляд. Если ассоциировать реализацию программного модуля с. водой в аквариуме, то видимость объектов, находящихся в воде, будет зависеть от степени ее чистоты или загрязнения. В ООП существуют различные варианты доступа к свойствам и методам классов, которые получили название видимости свойств и методов. В этом случае использование различных форм видимости для компонентов классов удобно ассоциировать с прозрачностью фона рисунка или видимостью в воде аквариума. Более детальное рассмотрение различных форм видимости приводится в части II книги.
В рассмотренном выше примере использовалась одна из принятых нотаций в некоторых языках программирования (например, в Object Pascal) для обозначения принадлежности метода тому или иному классу. В соответствии с этой нотацией, вначале указывается имя класса, в котором определен метод, а затем через точку имя самого метода. Если метод определен в некотором подклассе, то должна быть указана вся цепочка классов, начиная с наиболее общего из них. При этом характерным признаком метода является пара скобок, которые используются для указания списка аргументов или формальных параметров данного метода.
Рассматривая различные этапы ЖЦ программы, следует отметить одно важное обстоятельство. А именно, если появление RAD-инструментариев позволило существенно сократить сроки этапа программирования, то отсутствие соответствующих средств для первых двух этапов долгое время сдерживало процесс разработки приложений. Развитие методологии ООАП было направлено на автоматизацию второго, а затем и первого этапов ЖЦ программы.
Аббревиатура UML допускает соответствующий перевод и последующее сокращение, но ввиду неудобочитаемости получающегося «УЯМ» было решено использовать исходный термин на всем протяжении книги. Частично это можно объяснить уже сложившейся традицией применения оригинальных терминов, таких как CASE, RAD, DLL, ISDN и целого ряда других.
Термин «моделирование» имеет довольно много смысловых оттенков, например, моделирование одежды или моделирование прически. Не отрицая важности этих сфер творчества, следует отметить, 'что все эти аспекты моделирования лежат за пределами книги. Рассмотрение особенностей языка UML связано с вопросами логического или информационного моделирования систем.
Создается впечатление, что ситуация с заданием множеств более или менее понятна. Но это впечатление обманчиво. Даже не говоря об известных парадоксах теории множеств, как быть с «множеством» мыслей отдельного человека? Или множеством всех красок, которые встречаются в природе? Однако такие каверзные случаи мы рассматривать не будем, ограничив круг ситуаций такими, в которых идентификация отдельных элементов множеств не превращается в серьезную проблему. С другой стороны, процесс моделирования сложных систем сопряжен именно с подобного рода трудностями.
При выборе обозначений для множеств допускается некоторый произвол, который не всегда понятен лицам, далеким от математики. Однако здесь уместна аналогия с выбором имен для переменных и процедур в языках высокого уровня, когда программист сам решает, как ему обозначать соответствующую конструкцию в программе.
Проблема бесконечного могла бы показаться отвлеченной и имеющей некоторый философский оттенок, если бы не ее связь с моделированием сложных систем. Так, при рассмотрении некоторой предметной области с целью построения ее модели приходится выделять конечное число сущностей, образующих определенный «скелет» будущей модели. И это при том, что реальность предметов допускает бесконечное рассмотрение их свойств, атрибутов и взаимосвязей.
Вообще говоря, графы бывают двух различных типов. Рассмотренное выше определение относится к неориентированному графу, т. е. к такому графу, у которого связывающие вершины ребра не имеют направления или ориентации. Кроме неориентированных графов существуют ориентированные графы, которые определяются следующим образом.
Ориентированный граф также задается в виде двух множеств G=(V, E), где V={v1, v2, ...,vn} – множество вершин графа, а E={е1, е2,...,еm] – множество дуг графа. Натуральное число n определяет общее количество вершин конкретного графа, а натуральное число m – общее количество дуг графа. При этом каждая дуга еk=Е ориентированного графа G имеет свое начало– некоторую единственную вершину vi=V и конец – некоторую единственную вершину vj=V, В отличие от ребра, дуга всегда имеет обозначение со стрелочкой, которая направлена к конечной вершине дуги. Множество дуг ставит в соответствие каждому ориентированному графу некоторое бинарное отношение PG, состоящее из всех пар вида <vi, vj>, где vi, vj=V. При этом пара <vi, vj> принадлежит отношению PG в том и только в том случае, если вершины vi и vj соединяются в графе G некоторой дугой еk=Е с началом в вершине viи концом в вершине vj.
