UML как стандарт для создания модели информационной системы

ВВЕДЕНИЕ

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

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

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

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

• технико-экономическое обоснование проектных решений, включающее определение, оптимизацию и обоснование технико-экономических показателей и характеристик проектируемой системы на основе заданных целевых критериев ее функционирования;

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

• управление ходом выполнения самого процесса проектирования, обеспечивающее:

- определение состава и этапности проектных работ;

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

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

- контроль хода реализации проекта;

• разработка проектно-конструкторской документации на систему.

В качестве средств методической и программно-технической поддержки процесса проектирования в соответствии с приведенной классификацией проектных работ можно выделить:

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

• для проектирования программной и информационной среды - компьютерное моделирование и CASE-технологии, а также соответствующие ПТС для проведения моделирования и программные CASE-продукты;

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

Объектно-ориентированное проектирование состоит в описании структуры и поведения проектируемой системы, то есть, фактически, в ответе на два основных вопроса:

· Из каких частей состоит система.

· В чём состоит ответственность каждой из частей.

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

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

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

UML как стандарт для создания модели информационной системы

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

Унифицированный язык моделирования ( Unified Modeling Language ) появился в конце 80-х в начале 90-х годов в основном благодаря усилиям Гради Буча, Джима Рамбо и Ивара Якобсона. В настоящее время консорциум OMG принял этот язык как стандартный язык моделирования, который предоставляет разработчикам четкую нотацию, позволяющую отображать модели общепринятыми и понятными каждому члену проекта графическими элементами.

Производство программного обеспечения – высокозатратный процесс. Стоимость разработки во многом зависит как от объема необходимой работы и от качества принимаемых решений.

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

Создание моделей позволяет более наглядно документировать решения. До реализации идей в коде понять и объяснить другим участникам проекта, как будет работать программа. А пользователям предоставление моделей позволяет понять, соответствует ли заявленная работа тому, что им действительно нужно.

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