Построение диаграммы классов

1. Откройте Главную диаграмму классов (окно Browser > Logical View >Main) или создайте новую диаграмму (.Logical View >New>Class Diagram). (рис.20)

2. Для того чтобы создать пакеты, переносят их непосредственно на рабочий стол Rational Rose из строки инструментов текущей диаграммы, или выполняют последовательность: Logical View>New>Package.Пакеты соединяют стрелками, если необходимо показать их связи.

3. Внутри каждого пакета можно создать вложенную диаграмму классов. Для этого можно щелкнуть мышкой на значке пакета на рабочем столе или в окне броузера выполнить последовательность <Package>>New> Class Diagram.

4. Для того чтобы создать классы, переносят их непосредственно на рабочий стол Rational Rose из строки инструментов текущей диаграммы, выполняют последовательность: Logical View>New>Class (для общих классов), создают класс в конкретном пакете (<Package> >New>Class) или перетаскивают уже существующий класс из окна броузера на рабочий стол.

5. Спецификации, атрибуты и операции классов можно задать из контекстного меню на рабочем столе или в окне броузера (Open Specifikation, New Attribute и New Operation).

8. Методы и средства организации метаинформации проекта ЭИС

9. Разработка схемы и логической модели БД RRose. Переход к реляци­онной модели БД.

10. Система управления информационными потоками как средство интеграции приложений ЭИС.

Информационные потоки ЭИС

ЭИС связывает объект и систему управления между собой и с внешней средой через информационныепотоки.

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

2. Информационный поток из системы во внешнюю среду — отчетная инфор­мация, финансоваяинформация в государственные органы, инвесторам, кредито­рам, потребителям; маркетинговаяинформация потенциальным потребителям.

3. Информационный поток из системы управления на объект управления — (прямая связь)представляет совокупность плановой нормативной и распорядитель­ ной информации для осуществленияхозяйственных процессов.

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

11. Механизм пакетов в диаграммах RRose. Назначение и реализация

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

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

12. Проектирование документальных БД: анализ предметной области, разработка состава и структуры БД, проектирование логико-семантического комплекса

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

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

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

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

Однако взятый в отдельности любой из этих методов не может дать достаточно информации для проектирования рациональной структуры БД. Поэтому при проектировании БД целесообразно совместно использовать эти два подхода. Если схематично представить процесс проектирования БД на внешнем уровне, то он состоит из таких работ:

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

2) Изучение и анализ оперативных первичных документов.

3) Изучение нормативно-справочных документов.

4) Изучение процессов преобразования входных сообщений в выходные.

Результатом проектирования на внешнем уровне будет перечень атрибутов (реквизитов) оперативной и условно-постоянной информации, которые необходимо хранить в БД, с указанием источников их получения и формы представления.

13. Атрибуты классов RRose. Возможные значения, инструменты построения диаграмм

Атрибут - это значение, характеризующее объект в его классе. Примеры атрибутов: категория, баланс, кредит (атрибуты объектов класса счет); имя, возраст, вес (атрибуты объектов класса человек) и т.д.

– Public (общий, открытый). Это значение видимости предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута. В таком случае класс Company может изменить значение атрибута Address класса Employee. В соответствии с нотацией UML общему атрибуту предшествует знак «+».

– Private (закрытый, секретный). Соответствующий атрибут не виден никаким другим классом. Класс Employee будет знать значение атрибута Address и сможет изменять его, но класс Company не сможет его ни увидеть, ни редактировать. Если это понадобится, он должен попросить класс Employee просмотреть или изменить значение этого атрибута, что обычно делается с помощью общих операций. Закрытый атрибут обозначается знаком «–» в соответствии с нотацией UML.

– Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам. Допустим, что у нас имеется два различных 23 типа сотрудников – с почасовой оплатой и на окладе. Таким образом, мы получаем два других класса HourlyEmp и SalariedEmp, являющихся потомками класса Employee. Защищенный атрибут Address можно просмотреть или изменить из классов Employee, HourlyEmp и SalariedEmp, но не из класса Company. Нотация UML для защищенного атрибута – это знак «#».

– Package or Implementation (пакетный). Предполагает, что данный атрибут является общим, но только в пределах его пакета. Допустим, что атрибут Address имеет пакетную видимость. В таком случае он может быть изменен из класса Company, только если этот класс находится в том же пакете. Этот тип видимости не обозначается никаким специальным значком.

14. Проектирование фактографических БД: методы проектирования; концептуальное, логическое и физическое проектирование

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

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

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

Совокупность средств и способов реализации схемы базы данных в конкретной СУБД составляет модель организации данных

Третий и самый «низкий» уровень представления информации в фактографических ИС выражается внутренней схемой базы данных, определяющей структуру организации и особенности хранения информационных массивов, в которых и находятся собственно сами данные - Физическое проектирование.

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

15. Определение операции в языке UML. Типы операций в RRose

16. Анализ проекта. Оценка выбора технических и программных средств реализации проекта, наличие типовых проектных решений.

17. Определение связи между классами на языке UML

Классы в UML изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии — определить типы объектов системы и различного рода статические связи между ними.

Классы отображают типы объектов системы.

Между классами возможны различные отношения, представленные

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

- обобщения, связывающие обобщенные классы соспециализированными;

- ассоциации, отражающие структурные отношения между объектами классов.

18. Проектирование информационного обеспе­чения ЭИС. Состав, содержание и принципы организации информационного обеспечения ЭИС

19. Типовое проектирование ЭИС. Технологии параметрически-ориентированного и модельно-ориентированного проектирования

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

20. Этапы построения диаграмм в RRose. Роль и назначение описания потока событий

 

21. Диаграммы размещения в RRose. Назначение и физическая сущность диаграмм

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

Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. Ее основными элементами являются узел (вычислительный ресурс) и соединение - канал взаимодействия узлов (сеть).

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

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

Жизненный цикл информационных систем — Жизненный цикл информационной системы это процесс ее построения и развития.
Жизненный цикл информационной системы -- период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из эксплуатации.

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

2. Итерационная модель — это модель с итерационными возвратами на предыдущий этап после выполнения очередного этапа. Создание комплексных ЭИС предполагает проведение увязки проектных решений, полученных при реализации отдельных задач. Применяемый подход к проек-ю — «снизу вверх», т. е. От задач к подсистемам, создает необх-ть итерационных возвратов при комплектации проектных решений по отдельным задачам в общие системные решения. При этом возникает потребность в пересмотре ранее сформулированных требований. Из-за большого числа итераций возникают разногласия в выполненных проектных решениях и документации. Длительный ЖЦ разработки ЭИС заканчивается этапом внедрения, за которым начинается ЖЦ создания новой ЭИС.

3. Прототипная модель (спиральная), предполагающая разработку последовательности прототипов ЭИС. Использует подход к организации проектирования «сверху вниз», когда сначала определяется состав функциональных подсистем, а затем выполняется постановка отдельных задач. Сначала разрабатываются общесистемные вопросы: организация интегрированной БД, технология сбора, передачи и накопления информации, а затем технология решения конкретных задач. Программ-ние осущес-ся по направлению от головного программного модуля комплекса к модулям, исполняющим отдельные функции. При этом на 1-ый план выходят вопросы взаимодействия интерфейсов прогр-х модулей м/у собой и с БД. На 2-ой план — реализация алгоритмов. В основе спиральной модели ЖЦ лежит применение прототипной RAD-технологии (rapid application development -быстрая разработка приложений). ЭИС разрабатывается путем расширения программных прототипов, начиная с детализации требований к ИС, заканчивая детализацией программного кода. При прототипной технологии уменьшается число итераций и кол-во ошибок и несоответствий. Проектирование более быстрое, упрощается создание проектной документации. Для боле точного соответствия ЭИС документации применяется ведение общесистемного репозитория в рамках использования САSЕ-средств. ЖЦ при использовании RAD-технологий включает 4 основные стадии:

· Анализ и планирование информационной стратегии. Пользователи вместе со специалистами разработчиками участвуют в идентификации проблемной области.

· Проектирование — пользователи принимают участие в техническом проектировании под руководством разработчиков.

· Конструирование — специалисты-разработчики проектируют рабочую версию ЭИС с использование языков 4-го поколения (4GL-graphics language).

· Внедрение — специалисты-разработчики обучают пользователей работе в среде ЭИС.

23. UML – язык объектного моделирования. Его назначение и особенности применения

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

Назначение языка UML:

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

2. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области.

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

4. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.

5. Поощрять развитие рынка объектных инструментальных средств

6. Способствовать распространению объектных технологий и соответствующих понятий ООАП

7. Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

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

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

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

• Графические символы, изображаемые вблизи от тех или иных визуальных элементов диаграмм.

24. Диаграммы компонентов. Их назначение и взаимосвязь с другими объектами модели. Диаграммы компонентов моделируют физический уровень системы. На них изображаются компоненты ПО и связи между ними. На такой диаграмме обычно выделяют два типа компонентов: исполняемые компоненты и библиотеки кода.

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

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

25. Автоматизированное проектирование ЭИС с использованием CASE – технологии. Функционально-ориентированный и объектно-ориентированный подходы.