Практика_Лексина_21ВИ1. Отчет по учебной (ознакомительной) практике Лексина А. О направление 09. 03. 02 Информационные системы и технологии
 Скачать 1.12 Mb.
|
Объектно-ориентированный анализ и проектирование информационных систем.Компьютерные и информационные технологии без преувеличения можно назвать наиболее динамичной областью современных знаний, которые концентрируют в себе самые последние достижения в сфере науки и техники. Появление новых моделей процессоров и комплектующих, версий операционных систем и программного обеспечения происходит на фоне постоянного усложнения не только отдельных физических и программных компонентов, но и лежащих в их основе концепций. Разработка и совершенствование информационных систем приводит к необходимости поддержания единого стиля для различных версий программ при их постоянной доработке и модификации. Трудоемкость создания современных приложений на начальных этапах проекта, как правило, оценивается значительно ниже реально затрачиваемых усилий, что служит причиной незапланированных расходов и затягивания окончательных сроков готовности программ. В процессе разработки приложений изменяются функциональные требования заказчика, что еще более отдаляет момент окончания работы программистов. Увеличение размеров программ вынуждает привлекать сверхштатных программистов, что, в свою очередь, требует дополнительных ресурсов для организации их согласованной работы. В разработке и внедрении современных корпоративных информационных систем принимает участие множество специалистов различной квалификации, для которых единообразное понимание архитектуры и функциональности является серьезной проблемой. Таким образом, все эти особенности приводят к настоятельной необходимости моделирования структуры и процесса функционирования программных систем до начала написания соответствующего кода. При этом непременным условием успешного завершения проекта становится построение предварительной модели программной системы. Модель (model) - абстракция физической системы, рассматриваемая с определенной точки зрения и представленная на некотором языке или в графической форме. С точки зрения общих принципов системного анализа одна и та же физическая система может быть представлена несколькими моделями. При этом назначение отдельной модели системы определяется характером решаемой проблемы. Основное требование к модели программной системы - она должна быть понятна заказчику и всем специалистам проектной группы, включая бизнес-аналитиков и программистов. Именно для разработки такой нотации потребовались усилия группы специалистов ведущих фирм производителей программного и аппаратного обеспечения, которые привели к появлению языка UML. Разработка и использование моделей языка UML осуществляется в рамках общей концепции объектно-ориентированного анализа и проектирования, которая, в свою очередь, является обобщением методологии объектно-ориентированного программирования. Нотации и семантика UMLСемантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний. Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста. Таким образом, применительно к UML, семантика и синтаксис определяют стиль изложения (построения моделей), который объединяет естественный и формальный языки для представления базовых понятий (элементов модели) и механизмов их расширения. Нотация представляет собой графическую интерпретацию семантики для ее визуального представления. В UML определено три типа сущностей: - структурная – абстракция, являющаяся отражением концептуального или физического объекта; - группирующая – элемент, используемый для некоторого смыслового объединения элементов диаграммы; - поясняющая (аннотационная) – комментарий к элементу диаграммы. В таблице 1.1 приведено краткое описание основных сущностей, используемых в графической нотации, и основные способы их отображения. Таблица 1.1. Сущности
Продолжение таблицы 2
Окончание таблицы
В некоторых источниках, в частности, выделяют также поведенческие сущности взаимодействия и конечные автоматы, но с логической точки зрения их следует отнести к диаграммам. Некоторые из приведенных выше сущностей в соответствии с приципами иерархического упорядочивания и декомпозиции подразумевают их подробное описание на диаграммах декомпозиции. На диаграмме верхнего уровня они помечаются особым значком или меткой. Таблица 1.2. Декомпозируемые сущности
В следующей таблице приведено описание всех видов отношений UML, используемых на диаграммах для указания связей между сущностями. Таблица 1.3. Отношения
Для ассоциации, агрегации и композиции может указываться кратность, характеризующая общее количество экземпляров сущностей, участвующих в отношении. Она, как правило, указывается с каждой стороны отношения около соответствующей сущности. Кратность может указываться следующими способами: - любое количество экземпляров, в том числе и ни одного - целое неотрицательное число – кратность строго фиксирована и равна указанному числу (например: 1, 2 или 5); - диапазон целых неотрицательных чисел "первое число .. второе число" (например: 1..5, 2..10 или 0..5); - диапазон чисел от конкретного начального значения до произвольного конечного "первое число .. *" (например: 1..*, 5..* или 0..*); - перечисление целых неотрицательных чисел и диапазонов через запятую (например: 1, 3..5, 10, 15..*). Если кратность не указана, то принимается ее значение, равное 1. Кратность экземпляров сущностей, участвующих в зависимости, обобщении и реализации, всегда принимается равной 1. В следующей таблице приведено описание механизмов расширения, применяемых для уточнения семантики сущностей и отношений. В общем случае, механизм расширения представляет собой строку текста, заключенную в скобки или кавычки. Таблица 1.4. Механизмы расширения
Помимо стереотипов, указываемых в виде строки текста в кавычках, на диаграммах могут использоваться графические стереотипы. На следующем рисунке приведены примеры стандартного и стереотипного отображения класса-сущности (см рис. 1.1).
Рис. 1.1. - Примеры стандартного и стереотипного отображения класса Диаграмма представляет собой группировку элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы. Диаграммы представляют собой, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами. В следующей таблице дана краткая характеристика диаграмм UML. Таблица 1.5 Диаграммы
Стандарт UML 2.x определяет также дополнительные, узкоспециализированные диаграммы: - диаграмму объектов (object diagram) - аналогична диаграмме классов, но вместо классов отображаются объекты; - диаграмму синхронизации (timing diagram) - описывает состояния объекта с течением времени; - композитную структурную диаграмму (composite structure diagram) - описывает порты (включая интерфейсы) класса для взаимодействия с другими классами; - профильную диаграмму (profile diagram) - аналогична диаграмме пакетов с описанием классов, входящих в них; - обзорную диаграмму взаимодействия (interaction overview diagram) - аналогична диаграмме последовательности, но со скрытыми фрагментами взаимодействия (фрагментами с меткой ref). Представляет собой контекстную (концептуальную) диаграмму последовательности, элементы которой будут конкретизированы на отдельных диаграммах декомпозиции []. В целях укрупненного концептуального представления внутренней архитектуры системы большинство Case-средств при построении диаграммы классов допускает использование устоявшихся графических стереотипов для так называемых классов анализа. Такая диаграмма называется диаграммой классов анализа, но не относится к перечню диаграмм, определенных стандартом UML. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
