Классификация современных CASE-средств

Современные CASE-системы классифицируются по следующим признакам:

1) по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);

2) по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);

4) по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ,

ориентированные на локальную вычислительную сеть (ЛВС),

ориентированные на глобальную вычислительную сеть (ГВС)

и смешанного типа;

5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

6) по типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).

Процесс внедрения CASE-средств состоит из следующих этапов: определение потребностей в CASE-средствах; оценка и выбор CASE-средств; выполнение пилотного проекта; практическое внедрение CASE-средств.

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

22. Технологии OLAP и хранилища данных. Назначение, виды и варианты реализации хранилищ данных.

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

Хранилище данных (англ. Data Warehouse) — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базе систем управления базами данных и систем поддержки принятия решений. Данные, поступающие в хранилище данных, как правило, доступны только для чтения. Данные из OLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов и OLAP-анализ не использовал ресурсы транзакционной системы и не нарушал её стабильность. Как правило, данные загружаются в хранилище с определённой периодичностью, поэтому актуальность данных может несколько отставать от OLTP-системы.

Как правило, выделяют три разновидности хранения данных: − многомерный OLAP (multidimensional OLAP, MOLAP) представляет собой«OLAP в чистом виде», т.е. технологию, основанную на хранении данных подуправлением специализированных многомерных СУБД; − реляционный OLAP

(relational OLAP, ROLAP) – технология, основанная на хранении многомерной информации в реляционных базах данных, на основе одной или нескольких схем типа «звезда» или «снежинка»; − гибридный OLAP (hybrid OLAP, HOLAP) – технология, при которой одна часть данных хранится в многомерной базе, а другая часть – в реляционной. При этом

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

Варианты реализации ХД: Виртуальное ХД. В его основе - репозиторий метаданных, которые описывают источники информации, SQL-запросы для их считывания и процедуры обработки и предоставления информации. Непосредственный доступ к последним обеспечивает ПО промежуточного слоя. В этом случае избыточность данных нулевая. Конечные пользователи фактически работают с транзакционными системами напрямую со всеми вытекающими отсюда плюсами (доступ к "живым" данным в реальном времени) и минусами (интенсивный сетевой трафик, снижение производительности OLTP-систем и реальная угроза их работоспособности вследствие неудачных действий пользователей-аналитиков).Витрины данных - это набор тематически связанных БД, которые содержат информацию, относящуюся к отдельным аспектам деятельности корпорации. По сути дела, витрина данных - это облегченный вариант ХД, содержащий только тематически объединенные данные. Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные. Витрина данных, естественно, существенно меньше по объему, чем корпоративное ХД, и для его реализации не требуется особо мощная вычислительная техника.Глобальное ХД.В последнее время все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать ХД в качестве единственного источника интегрированных данных для всех витрин данных.

23 Применение технологии размерного моделирования при организации хранилищ данных.

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

Рассмотрим основные особенности техники моделирования хранилищ данных с помощью Erwin.

ERwin поддерживает методологию моделирования хранилищ благодаря использованию специальной нотации для физической модели - Dimensional. Наиболее простой способ перейти к нотации Dimensional в ERwin - при создании новой модели (меню File / New). Моделирование Dimensional сходно с моделированием связей и сущностей для реляционной модели, но отличаются целями. Реляционная модель акцентируется на целостности и эффективности ввода данных. Размерная (Dimensional) модель ориентирована в первую очередь на выполнение сложных запросов к БД.

Схема звезда обычно содержит одну большую таблицу, называемую таблицей факта ( fact table) , помещенную в центр, и окружающие ее меньшие таблицы, называемые таблицами размерности ( dimensional table) , соединенные c таблицей факта в виде звезды радиальными связями. В этих связях таблицы размерности являются родительскими, таблица факта - дочерней.

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

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

24Аналитические информационные системы: архитектура, особенности, уровни применения.

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

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

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

Первая подсистема традиционно базируется на технологии оперативной обработки транзакций OLTP (On-Line Transaction

Processing). В основе второй лежит концепция хранилищ данных (Data Warehouse).

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

Часто, наряду с общим хранилищем данных предприятия, используют витрины данных (Data Mart), представляющие собой специализированные аналитические базы данных по конкретному подразделению или аспекту деятельности предприятия. В соответствии с этим хранилище данных может иметь как двухуровневую (источники данных - хранилище данных), так и трехуровневую (источники данных - общее хранилище данных - специализированные аналитические базы данных) архитектуру.

Хранилище данных автоматически собирает операционные данные, согласовывая их и объединяя в предметно-ориентированный формат, который нужен работникам управления. Данные в хранилище данных не предназначены для модификации.

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

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

Уровни метаданных информационно-аналитической системы



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

25 Основные принципы объектно-ориентированного проектирования ПО ИС. Абстракция, наследование, апсуляция, полиморфизм. Edit

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

26Язык визуального моделирования UML: этапы развития, структура. Состав диаграмм в UML-модели.

История развития языка UML берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из Rational Software Corporation начали работу по унификации методов Booch и ОМТ. Хотя сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Румбах сосредоточили усилия на полной унификации результатов своей работы. Проект так называемого унифицированного метода (Unified Method) версии 0.8 был подготовлен и опубликован в октябре 1995 года. Осенью того же года к ним присоединился А. Джекоб-сон, главный технолог из компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя предыдущими.
Вначале авторы методов Booch, ОМТ и OOSE предполагали разработать унифицированный язык моделирования только для этих трех методик. С одной стороны, каждый из этих методов был проверен на практике и показал свою конструктивность при решении отдельных задач ООАП. Это давало основание для дальнейшей их модификации на основе устранения имеющегося несоответствия отдельных понятий и обозначений. С другой стороны, унификация семантики и нотации должна была обеспечить некоторую стабильность на рынке объектно-ориентированных CASE-средств, которая необходима для успешного продвижения соответствующих программных ин-струментариев. Наконец, совместная работа давала надежду на существенное улучшение всех трех методов.
Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и А. Дже-кобсон сформулировали следующие требования к языку моделирования. Он должен:
• Позволять моделировать не только программное обеспечение, но и более широкие классы систем и бизнес-приложений, с использованием объектно-ориентированных понятий.
• Явным образом обеспечивать взаимосвязь между базовыми понятиями для моделей концептуального и физического уровней.

• Обеспечивать масштабируемость моделей, что является важной особенностью сложных многоцелевых систем.
• Быть понятен аналитикам и программистам, а также должен поддерживаться специальными инструментальными средствами, реализованными на различных компьютерных платформах.
Последующая работа над языком UML должна была учесть все эти обстоятельства.
В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group). Хотя консорциум OMG был образован еще в 1989 году с целью разработки предложений по стандартизации объектных и компонентных технологий CORBA, язык UML приобрел статус второго стратегического направления в работе OMG. Именно в рамках OMG создается команда разработчиков под руководством Ричарда Соли, которая будет обеспечивать дальнейшую работу по унификации и стандартизации языка UML. В июне 1995 года OMG организовала совещание всех крупных специалистов и представителей входящих в консорциум компаний по методологиям ООАП, на котором впервые в международном масштабе была признана целесообразность поиска индустриальных стандартов в области языков моделирования под эгидой OMG.
Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML версии 0.9 (июнь 1996 г.) и версии 0.91 (октябрь 1996 г.).
В это же время стало ясно, что некоторые компании и организации видят в языке UML линию стратегических интересов для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный вариант ответа на запрос предложений RTP. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность и предполагала решение широкого класса задач.
Очередной этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3 (alpha R5). Последней версией языка UML на момент написания книги является UML 1.3, которая описана в соответствующем документе – «OMG Unified Modeling Language Specification», опубликованном в июне 1999 года.

Диаграммы UML

Диаграммы UML предназначены для визуального отображения моделей и их компонентов.

UML 2.0 содержит 13 типов диаграмм. В том числе:

Структурные диаграммы:

- Диаграмма классов –показывает классы, их атрибуты и связи между классами.

- Диаграмма компонентов –показывает компоненты и связи между ними.

- Структурная диаграмма –показывает внутреннюю структуру классов и связи с внешним миром.

- Диаграмма развертывания - показывает, как ПО размещается на аппаратуре (серверах, рабочих станциях...).

- Диаграмма объектов – показывает структуру системы в конкретный момент времени, объекты, их атрибуты...

- Диаграмма пакетов – показывает, как система раскладывается на крупные составные части и связи между этими частями

Диаграммы поведения:

- Диаграмма действия– показывает потоки информации в системе.

- Диаграмма состояния– представляет собой конечный автомат, показывающий функционирование системы.

- Диаграмма вариантов использования – показывает работу системы с точки зрения пользователей.

Диаграммы взаимодействия

- Диаграмма кооперации – показывает структурную организацию участвующих во взаимодействии объектов.

- Диаграмма взаимодействия (новация UML 2.0).

- Диаграмма последовательности –показывает временную упорядоченность событий.

- Временная диаграмма – диаграмма связана с временными рамками проекта.

27Диаграмма вариантов использования как концептуальное представление системы. Основные элементы диаграмм вариантов использования. Отношения включения, расширения и обобщения.

Диаграмма вариантов использования (use case diagram) — диаграмма, на которой изображаются отношения между актерами и вариантами использования.

Диаграмма вариантов использования - это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки.

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

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

Актер (actor) — согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними.

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

Отношение (relationship) — семантическая связь между отдельными элементами модели.

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

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

Отношение ассоциации – одно из фундаментальных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм. Применительно к диаграммам вариантов использования ассоциация служит для обозначения специфической роли актера при его взаимодействии с отдельным вариантом использования.

Включение (include) в языке UML — это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем. При этом отношением зависимости (dependency) является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого).

Отношение расширения (extend) определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.

В языке UML отношение расширения является зависимостью, направленной к базовому варианту использования и соединенной с ним в так называемой точке расширения.

28.Понятие класса и объекта в объектно-ориентированной модели. Описание класса в модели UML. Определение атрибутов и операций класса.

Диаграммаклассов (class diagram) является основным логическим представлением модели и содержит детальную информацию о внутреннем устройстве объектно-ориентированной программной системы или об архитектуре программной системы. Диаграммы классов используются для моделирования статического вида системы с точки зрения проектирования. Диаграмма классов - диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношений между ними. Используется в следующих целях: для моделирования словаря системы; для моделирования простых коопераций. Кооперация - это сообщество классов, интерфейсов и других элементов, работающих совместно для обеспечения некоторого кооперативного поведения; для моделирования логической схемы базы данных.

Классом называется именованное описание совокупности объектов с общими атрибутами, операциями, связями и семантикой. Пример изображения класса на диаграмме классов показан на рисунке 1.

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

Операция класса - это именованная услуга, которую можно запросить у любого объекта этого класса. Операция – это абстракция того, что можно делать с объектом.

После определения классов на диаграмме следует показать отношения между классами. Существуют отношения следующих типов: отношение зависимостипоказывает, что изменение одного класса влечет изменение другого класса. Чаще всего применяется, когда один класс использует другой в качестве аргумента;отношение ассоциации– структурная связь, показывающая, что объекты одного класса некоторым образом связаны с объектами другого или того же самого класса. Кратностью роли ассоциации называется характеристика, указывающая, сколько объектов класса с данной ролью может или должно участвовать в каждом экземпляре ассоциации;отношение агрегации – специальная форма ассоциации, которая служит для представления отношения типа "часть-целое" между агрегатом (целое) и его составной частью;отношение композиции – разновидность отношения агрегации, при которой составные части целого имеют такое же время жизни, что и само целое. Эти части уничтожаются вместе с уничтожением целого.

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

29Стереотипы классов в UML для построения моделей ПО и бизнес-систем.

Стереотипы классов

Стереотипы – это механизм, позволяющий разделять классы на категории. Приняты следующие стандартные стереотипы классов:

- класс-сущность (entity class) —пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы. Обычно каждый класс-сущность в системе представлен таблицей базы данных;

- граничный класс (boundary class) —класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы. К таким классам относятся все формы, отчеты, интерфейсы. Для каждого актера должен существовать как минимум один граничный класс;

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

30Отношения между классами и их отображение на диаграмме классов в UML-модели

Отношения между классами

После определения классов на диаграмме следует показать отношения между классами. Существуют отношения следующих типов:

- отношение зависимостипоказывает, что изменение одного класса влечет изменение другого класса. Чаще всего применяется, когда один класс использует другой в качестве аргумента;

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

- отношение агрегации – специальная форма ассоциации, которая служит для представления отношения типа "часть-целое" между агрегатом (целое) и его составной частью;

- отношение композиции – разновидность отношения агрегации, при которой составные части целого имеют такое же время жизни, что и само целое. Эти части уничтожаются вместе с уничтожением целого.

Примеры изображения отношений на диаграммах показаны на рисунке 2.

31Этапы построения диаграммы классов: концептуальная модель классов и модель классов этапа анализа.

Существуют три различные точки зрения на построение диаграмм классов или любой другой модели:

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

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

точка зрения реализации: классы диаграммы соответствуют реальным классам программной системы.

Запустить IBM Rational Rose 2003. Открыть учебную модель, созданную в лабораторной работе.

Создать в логическом представлении браузера новую диаграмму классов Add New Order.

Создать классы-сущности

Дата добавления: 2018-02-15; просмотров: 779; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 123 Следующая ⇒

Мы поможем в написании ваших работ!