|
|
Метод проектирования ИС «снизу-вверх» и «сверху-вниз».Снизу-вверх Информационная система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия. Основная цель - не создание тиражируемых продуктов, а обслуживание текущих потребностей конкретного учреждения. Такой подход отчасти сохраняется и сегодня. Проблема данного метода: В рамках "лоскутной автоматизации" достаточно хорошо обеспечивается поддержка отдельных функций, но: · практически полностью отсутствует стратегия развития комплексной системы автоматизации, · объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему. Сверху-вниз Существует потребность в достаточно стандартных программных средствах автоматизации деятельности различных учреждений и предприятий. Разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Системы начали проектироваться "сверху-вниз" в предположении, что одна программа должна удовлетворять потребности многих пользователей. Проблемы данного метода: Накладываются существенные ограничения на возможности разработчиков по формированию структуры базы данных, экранных форм, по выбору алгоритмов расчета. Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия. Материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели. 3. Объектная структура и функциональная структура проектируемой информационной системы Объектная структура Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования).
На внешнем уровне детализации модели выделяются: - основные виды материальных объектов (например, сырье и материалы, полуфабрикаты, готовые изделия, услуги), - основные виды информационных объектов или документов (например, заказы, накладные, счета и т.д.). На концептуальном уровне построения модели предметной области: - уточняется состав классов объектов, - определяются их атрибуты и взаимосвязи. Таким образом строится обобщенное представление структуры предметной области. Далее концептуальная модель на внутреннем уровне отображается в виде: - файлов базы данных, - входных и выходных документов ИС. Динамические объекты представляются единицами переменной информации или документами Статические объекты представляются единицами условно-постоянной информации в виде списков, номенклатур, ценников, справочников, классификаторов. Функциональная структура Функция (операция) - некоторый преобразователь входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций - бизнес-процесс. Функция бизнес-процесса может порождать объекты любой природы (материальные, денежные, информационные). Бизнес-процессы и информационные процессы неразрывны, то есть функции материального процесса не могут осуществляться без информационной поддержки. Функция может быть представлена: - одним действием, - некоторой совокупностью действий. Каждой функции может соответствовать некоторый процесс, в котором могут существовать свои подпроцессы. Функциональная декомпозиция возможна, пока каждая из подфункций не будет представлять некоторую недекомпозируемую последовательность действий. На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов. Обычно таких функций насчитывается 15–20. На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций. На внутреннем уровне отображается структура информационного процесса в компьютере: определяются иерархические структуры программных модулей, реализующих автоматизируемые функции.
Методология IDEF0 есть этап развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). В основе методологии лежат четыре основных понятия: - функциональный блок, - интерфейсная дуга, - декомпозиция, - глоссарий. Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, "производить услуги"). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом: - верхняя сторона имеет значение "Управление" (Control); - левая сторона имеет значение "Вход" (Input); - правая сторона имеет значение "Выход" (Output); - нижняя сторона имеет значение "Механизм" (Mechanism). Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком. С помощью интерфейсных дуг отображают различные объекты, определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и др.) Любой функциональный блок должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую, т.к.каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга). Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram). Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели. Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение "туннеля" (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из "туннеля") только на этой диаграмме. Такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. 5. Модели жизненного цикла информационной системы Жизненный цикл ИС - некоторая последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления. Модель жизненного цикла - структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования. Классический (каскадный) жизненный цикл В классическом жизненном цикле разработка рассматривается как последовательность этапов, где переход на следующий этап происходит только после полного завершения работ на текущем этапе. Выделяются следующие этапы: - системный анализ - анализ требований - проектирование - кодирование - тестирование - сопровождение Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе но не в разработке новой программы. Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования. Недостатки классического жизненного цикла: 1) реальные проекты часто требуют отклонения от стандартной последовательности шагов; 2) цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично); 3) результаты проекта доступны заказчику только в конце работы. Макетирование (прототипная модель) Основная цель макетирования — снять неопределенности в требованиях заказчика. Макетирование– это процесс создания модели требуемого программного продукта. Модель может принимать одну из трех форм: 1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог); 2) работающий макет (выполняет некоторую часть требуемых функций); 3) существующая программа (характеристики которой затем должны быть улучшены). Макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик (→Ожидание заказчика→Построение / уточнение макета→Оценка макета заказчиком→) Достоинство макетирования: обеспечивает определение полных требований к ПО. Недостатки макетирования: - заказчик может принять макет за продукт; - разработчик может принять макет за продукт. Инкрементная модель Инкрементная модель является классическим примером инкрементной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования. Каждая линейная последовательность включает стадии анализа, проектирования, кодирования и тестирования и вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — возможности компоновки страницы. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность. По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт. Спиральная модель Спиральная модель базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент — анализ риска, отсутствующий в этих парадигмах.
1. Планирование - определение целей, вариантов и ограничений. 2. Анализ риска - анализ вариантов и распознавание/выбор риска. 3. Конструирование - разработка продукта следующего уровня. 4. Оценивание - оценка заказчиком текущих результатов конструирования. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. Достоинства спиральной модели: 1) наиболее реально (в виде эволюции) отображает разработку программного обеспечения; 2) позволяет явно учитывать риск на каждом витке эволюции разработки; 3) включает шаг системного подхода в итерационную структуру разработки; 4) использует моделирование для уменьшения риска и совершенствования программного изделия. Недостатки спиральной модели: 1) повышенные требования к заказчику; 2) трудности контроля и управления временем разработки. Компонентно-ориентированная модель Компонентно-ориентированная модель является развитием спиральной модели и тоже основывается на эволюционной стратегии конструирования. В этой модели конкретизируется содержание квадранта конструирования — оно отражает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов Достоинства компонентно-ориентированной модели: 1) уменьшает на 30% время разработки программного продукта; 2) уменьшает стоимость программной разработки до 70%; 3) увеличивает в полтора раза производительность разработки 6. Диаграмма вариантов использования Визуальное моделирование в UML представляется как процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели программной системы. Диаграмма вариантов использования (use case diagram) описывает то, что система будет делать в процессе функционирования. Разработка диаграммы вариантов использования преследует цели: - Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы. - Сформулировать общие требования к функциональному поведению проектируемой системы. - Разработать исходную концептуальную модель системы для ее последующей детализации. - Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. Суть диаграммы состоит в том, что проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью вариантов использования. Актер – любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему. Вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. При этом ничего не говорится о том, как реализовано взаимодействие актеров с системой Цель варианта использования: определить законченный аспект или фрагмент поведения некоторой сущности без раскрытия внутренней структуры этой сущности. Вариант использования изображается на диаграмме в виде эллипса. Множество вариантов использования в целом должно определять все возможные стороны ожидаемого поведения системы. Стандартным графическим обозначением актера на диаграммах является фигурка «человечка», под которой записывается конкретное имя актера. Имя актера должно быть информативным с точки зрения семантики. Вполне подходят для этой цели наименование должностей в компании. Актер всегда находится вне систем. Примечания (notes) в языке UML предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта Отношения В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования: - отношение ассоциации - в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм. - отношение расширения - отмечает тот факт, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования. - отношение обобщения - служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. - отношение включения - указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. 7. Диаграмма классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. На диаграмме не указывается информация о временных аспектах функционирования системы. Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции. Обязательным элементом обозначения класса является его имя. Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов (возможно, одной диаграммой). Рекомендуется в качестве имен использовать существительные, записанные по практическим соображениям без пробелов. Именно имена классов образуют словарь предметной области при ООАП Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным классом. В языке UML принята стандартная запись атрибутов класса. Каждому атрибуту соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения. Квантор видимости может принимать одно из трех возможных значений и отображается при помощи специальных символов: - символ «+» обозначает атрибут с областью видимости типа общедоступный (public); - символ «#» обозначает атрибут с областью видимости типа защищенный (protected); - символ «-» обозначает атрибут с областью видимости типа закрытый (private). Квантор видимости может быть опущен. В этом случае его отсутствие означает, что видимость атрибута не указывается. Операция представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Базовыми отношениями между классами в языке UML являются: • Отношение зависимости - указывает некоторое семантическое отношение между двумя классами, которое не является отношением ассоциации, обобщения или реализации • Отношение ассоциации - соответствует наличию некоторого отношения между классами • Отношение обобщения – Данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. • Отношение агрегации - имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности. • Отношение реализации
Каждая прикладная система характеризуется не только структурой, но и некоторым поведением или функциональностью. Для представления поведения на логическом уровне необходимо ответить на вопрос: «В процессе какого поведения система обеспечивает необходимую функциональность?» Главное предназначение диаграммы состояний – описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых событий. Диаграмма состояний – граф специального вида, который представляет некоторый автомат. Вершинами графа являются состояния и некоторые другие типы элементов автомата (псевдосостояния), которые изображаются соответствующими графическими символами. Дуги графа служат для обозначения переходов из состояния в состояние. Автомат (state machine) в языке UML представляет собой некоторый формализм для моделирования поведения элементов модели и системы в целом. Простейшим примером визуального представления состояний и переходов на основе автоматов может служить ситуация с исправностью технического устройства. В этом случае имеется два самых общих состояния: «исправен» и «неисправен» и два перехода: «выход из строя» и «ремонт». Графически такая информация может быть представлена в виде диаграммы состояний технического устройства:
Основными понятиями в автомате являются состояние и переход. Главное различие между ними: длительность нахождения системы в отдельном состоянии существенно превышает время, которое затрачивается на переход из одного состояния в другое. Для графа состояний системы вводят в рассмотрение специальные свойства. Одно из таких свойств – выделение из всей совокупности состояний двух специальных: начального и конечного. Хотя на диаграмме состояний время нахождения системы в том или ином состоянии явно не учитывается, предполагается, что последовательность изменения состояний упорядочена во времени. Каждое последующее состояние всегда наступает позже предшествующего ему состояния. Следующее свойство графа состояний – достижимость состояний. Это свойство характеризует потенциальную возможность перехода системы из рассматриваемого состояния в некоторое другое состояние. Список внутренних действий Эта секция содержит перечень внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого элемента в данном состоянии. Простой переход (simple transition) – отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением некоторых действий, а переход во второе состояние будет возможен после завершения этих действий, а также после удовлетворения некоторых дополнительных условий. В этом случае говорят, что переход срабатывает, или происходит срабатывание перехода. Срабатывание перехода может зависеть не только от наступления некоторого события, но и от выполнения определенного условия, называемого сторожевым условием. Объект переходит из одного состояния в другое в том случае, если произошло указанное событие и сторожевое условие приняло значение «истина». Составное состояние (composite state) – такое сложное состояние, которое состоит из других вложенных в него состояний. Для того, чтобы можно было учитывать ту часть деятельности, которая была выполнена на момент выхода из некоторого состояния и не начинать все сначала, в языке UML существует историческое состояние. Оно используется для запоминания того из последовательных подсостояний, которое было текущим в момент выхода из составного состояния
Для моделирования процесса выполнения операций в языке UML используются диаграммы деятельности. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой операции в предыдущем состоянии. Диаграммы деятельности можно считать частным случаем диаграмм состояний. В языке UML деятельность – совокупность отдельных вычислений, выполняемых автоматом. Отдельные элементарные вычисления могут приводить к некоторому результату или действию. На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой. Состояние действия – специальный случай состояния с некоторым входным действием и по крайней мере одним выходящим из состояния переходом. Использование состояния действия заключается в моделировании одного шага выполнения алгоритма или потока управления. Действие может быть записано на естественном языке, некотором псевдокоде или языке программирования. Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния. Диаграмму деятельности принято располагать так, чтобы действия следовали сверху вниз. При построении диаграммы деятельности используются только нетриггерные переходы, т.е. такие, которые срабатывают сразу после завершения деятельности или выполнения соответствующего действия. Этот переход переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии. Диаграммы деятельности могут быть использованы не только для спецификации алгоритмов вычисления или потоков управления, но и для моделирования бизнес-процессов. В этом случае действия желательно ассоциировать с конкретным подразделением компании. В этом случае подразделение несет ответственность за реализацию отдельных действий. Действия на диаграмме деятельности выполняются над теми или иными объектами. Эти объекты либо инициируют выполнение действий, либо определяют некоторый результат этих действий. Диаграмма деятельности строится для отдельного класса, варианта использования, отдельной операции класса или целой подсистемы. На начальных этапах проектирования построение диаграммы деятельности начинают с выделения под-деятельностей, которые в совокупности образуют деятельность подсистем.
Любые виды информационного взаимодействия между элементами системы должны быть сведены к отправке и приему сообщений между ними. Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Рассматриваются два аспекта взаимодействия: - взаимодействия объектов можно рассматривать во времени – для этого используются диаграммы последовательности. - можно рассматривать структурные особенности взаимодействия объектов – для этого используются диаграммы кооперации. На диаграмме последовательности изображаются те объекты, которые непосредственно участвуют во взаимодействии и не показываются статические ассоциации с другими объектами. Диаграмма последовательности имеет как бы два измерения. Первое измерение – слева направо в виде вертикальных линий каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Крайний слева объект – инициатор взаимодействия. Правее изображается другой объект, который непосредственно взаимодействует с первым. Все объекты образуют порядок, определяемый степенью активности этих объектов. Второе измерение диаграммы последовательности – вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Сообщения, расположенные на диаграмме последовательности выше инициируются раньше тех, которые расположены ниже. Масштаб на оси времени не указывается. Линия жизни объекта изображается пунктирной вертикальной линией, связанной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе – может участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности. Отдельные объекты, выполнив свою роль в системе, могут быть разрушены, чтобы освободить занимаемые ими ресурсы. В процессе функционирования объектно-ориентированных систем объекты могут находиться в активном состоянии или в состоянии пассивного ожидания. Для выделения подобной активности объектов в языке UML применяется понятие фокуса управления. Фокус управления изображается в форме вытянутого узкого прямоугольника. Верхняя сторона – начало активности, нижняя сторона – окончание активности. Данный прямоугольник может заменить линию жизни объекта если на всем ее протяжении он является активным. Инициатором взаимодействия в системе может быть актер или внешний пользователь. В этом случае актер изображается на диаграмме последовательности самым первым объектом слева со своим фокусом управления. Каждое взаимодействие описывается совокупностью сообщений, которыми участвующие в нем объекты обмениваются между собой. Сообщение – законченный фрагмент информации, который отправляется одним объектом другому. Прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено. Иногда отправителя сообщения называют клиентом, а получателя – сервером. При этом сообщение от клиента имеет форму запроса некоторого сервиса, а реакция сервера на запрос после получения сообщения может быть связана с выполнением определенных действий или передачи клиенту необходимой информации тоже в форме сообщения. В языке UML могут встречаться несколько разновидностей сообщений: - для вызова процедур и выполнения операций - явно обозначающие асинхронное сообщение между двумя объектами в некоторой процедурной последовательности - для возврата из вызова процедуры. В отдельных случаях объект может посылать сообщения самому себе, инициируя рефлексивные сообщения.
Диаграмма компонентов определяет архитектуру разрабатываемой системы. Во многих средах разработки модуль или компонент соответствует файлу. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними. Диаграмма компонентов разрабатывается для следующих целей: - Визуализации общей структуры исходного кода программной системы. - Спецификации исполняемого варианта программной системы. - Обеспечения многократного использования отдельных фрагментов программного кода. - Представление физической схемы базы данных Для представления физических сущностей в языке UML применяется специальный термин – компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели. В качестве простых имен компонентов принято использовать имена исполняемых файлов (.exe), имена динамических библиотек (.dll), имена Web-страниц (.html), имена текстовых файлов (.txt,.doc) или файлов справки (.hlp), имена файлов баз данных (DB) или имена файлов с исходными текстами программ (.h,.cpp,.java), скрипты (.pl,.asp) и др. Имена компонентов будут определяться особенностями синтаксиса соответствующего языка программирования. В языке UML выделяют три вида компонентов: - компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций: динамически подключаемые библиотеки, Web-страницы и файлы справки; - компоненты-рабочие продукты. Как правило – это файлы с исходными текстами программ. - компоненты исполнения, представляющие исполняемые модули – файлы с расширением exe. Интерфейсы Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов. Отношение зависимости служит для представления связи, когда изменение одного элемента модели оказывает влияние или приводит к изменению другого элемента модели. Зависимости могут связывать компоненты и импортируемые этим компонентом интерфейсы, а также различные виды компонентов между собой. Наличие стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Одновременно на диаграмме может присутствовать другой компонент, который реализует этот интерфейс. Внесение изменений в исходные тексты программ или динамические библиотеки приводят к изменениям самого компонента. На диаграмме компонентов могут быть представлены отношения зависимости между компонентами и реализованными в них классами. В данном случае из диаграммы компонентов не следует, что классы реализованы этим компонентом. Рекомендации по построению: - До начала разработки необходимо принять решение о выборе вычислительных платформ и операционных систем, о выборе баз данных и языков программирования. - Необходимо решить, из каких физических частей (файлов) будет состоять программная система. - После общей структуризации физического представления системы необходимо дополнить модель интерфейсами и схемами базы данных. - Завершающий этап построения диаграммы компонентов связан с установлением взаимосвязей между компонентами и отношений реализации.   ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...  Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...  Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычислить, когда этот...  Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор... Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:
|
Модель определяет четыре действия, представляемые четырьмя квадрантами спирали.