Файл: МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ ИНФРОМАЦИОННЫХ СИСТЕМ.pdf

Рис. Нотация диаграммы компонентов

Диаграмма развёртывания

Диаграмма развертывания (deployment diagram) наряду с отражением состава и взаимосвязей компонентов концепции демонстрирует, равно как они на физическом уровне расположены в вычисляемыых ресурсах в период выполнения.

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

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

Рис. Нотация диаграммы развёртывания

3.3. Правила языка UML

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

В языке UML имеются семантические правила, позволяющие корректно и однозначно определять:

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

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

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

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

3.4. Общие механизмы языка UML

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

• спецификации (Specifications);
• дополнения (Adornments);
• принятые деления (Common divisions);
• механизмы расширения (Extensibility mechanisms).

4. Характеристика Case – средств проектирования информационных систем

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

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

Наиболее трудоемкими стадиями разработки ПО считаются периоды формирования требований и проектирования, в процессе которых CASE- средства обеспечивают качество принимаемых технических заключений и подготовку проектной документации. При данном большую значимость представляют методы визуального представления информации. Это подразумевает создание разнообразных графических моделей (диаграмм), использование разнообразной цветовой палитры, сквозную проверку синтаксических законов. Графические средства моделирования предметной области дают возможность разработчикам в наглядном варианте изучать существующую ИС, менять её в соответствии с установленными целями и имеющимися ограничениями.

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

4.1. ModelMaker

Case – средство ModelMaker – это инструмент объектно - ориентированного проектирования информационных систем. Он основан на последних стандартах языка проектирования UML.

ModelMaker создана голландской фирмой ModelMaker Tools. Она работает с Delphi, но в то же время частью Delphi не является и устанавливается как отдельная программа.

CASE – инструмент ModelMaker делает за вас значительную часть «рутинной работы» по написании программного кода, позволяя разработчику сосредоточиться на творческой стороне этого процесса.

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

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

ModelMaker, как и другие CASE - средства проектирования, позволяет вести удобное документирование проекта

4.2. Rational Unified Process

Рациональный унифицированный процесс (Rational Unified Process, RUP) — использует спиральную методологию разработки программного обеспечения. Методологией занимается компанией Rational Software, обновляют продукт примерно один раз в полгода. Использует язык моделирования в общей базе Unified Modelling Language (UML).

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

RUP хорошо укомплектован, и большое внимание уделяют начальным стадиям разработки — анализу и моделированию. Таким образом, эта методология нужна для снижение коммерческих рисков (risk mitigating) посредством обнаружения ошибок на ранних стадиях разработки.

Технические риски (assesses) оцениваются и «расставляются» согласно приоритетам в ранних стадиях цикла разработки, а далее пересматриваются с течением периода и с развитием проекта в процесс дальнейшихитераций. Новые цели возникают зависимо от ценностей данных рисков. Выпуск версий распределяются таким образом, что наиболее главные ошибки устраняются первыми.

Процесс предполагает эволюционные модели; итерация цикла разработки точно соответствует определенной версии модели программного обеспечения. Каждая из итераций (workflow) имеет элементы управления жизненным циклом ПО: анализ и дизайн (моделирование), реализация, интегрирование, тестирование, внедрение. В этом RUP является реализацией спиральной модели, но довольно чаще всего изображается в виде графической таблицы.с

4.3 JSD

Методология JSD (Jackson Structured Development) имеет свой стиль создание программных систем; он отличается от стиля, принятого в методологиях SA/SD или OMT. Методология JSD, разработанная Майклом Джексоном в середине 80-х годов, особенно имеет большой спрос в Европе.

В методологии JSD не делают различий между этапами анализа требований к системе и этапами ее разработки; они объединяются в один большой этап разработки спецификаций проектируемой системы. На этом этапе решается такие вопросы "что должно быть сделано"; вопрос "как это должно быть сделано" реализуется на другом этапе - этапе реализации системы. Методология JSD часто применяется для проектирования систем реального времени.

Как и другие методологии, JSD использует систему графических обозначений, хотя эта методология и менее ориентирована на графику, чем методологии SA/SD и OMT.

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

• • разработка действий и объектов;
  • разработка структуры объектов;
  • разработка исходной модели;
  • разработка функций;
  • разработка временных ограничений;
  • реализация системы.

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

5. Архитектура

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

Архитектура — это совокупность существенных решений касательно:

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

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

Вид с точки зрения прецедентов (Use case view) охватывает факты, которые представляют действия системы, наблюдаемое окончательными пользователями, специалистами и тестировщиками. Данный тип специфицирует не реальную организацию программной системы, а эти двигающие силы, с которых находится в зависимости формирование системной архитектуры. В стиле UML постоянные нюансы данного типа переходят диаграммами фактов, а динамические — диаграммами взаимодействия, состояний и действий.