Сделай Сам Свою Работу на 5

Конструкторско-технологическая часть





Содержание

Введение.. 3

1 Системотехническая часть.. 3

1.1 Описание предметной области.. 3

1.2 Постановка задачи.. 3

1.2.1 Цели проектирования. 3

1.2.1 Критерии эффективности, планируемые значения показателей эффективности проектируемой системы 3

1.3 Методы и алгоритмы решения задачи.. 3

1.3.1 Краткое описание методологии UML. 3

1.3.2 Краткое описание средства разработки проекта SoftwareIdeasModeller. 3

1.3.3 Краткое описание теории решения изобретательских задач. 3

1.4 Построение модели анализа.. 33

1.4.1 Диаграмма вариантов использования (Use Case Diagram) 33

1.4.2 Сценарии вариантов использования. 33

1.4.3 Диаграммы классов (Class Diagram) 36

1.4.3.1 Диаграмма сущностных классов. 36

1.4.3.2 Диаграмма классов управления. 36

1.4.3.3 Диаграмма граничных классов. 37

1.4.4 Диаграммы состояний (Statechart Diagram) 3

1.5 Расчет внешней памяти.. 3

1.6 Расчет оперативной памяти.. 3

1.7 Выбор КТС и расчет быстродействия системы.. 3

2 Конструкторско-технологическая часть.. 33

2.1 Обоснование архитектуры и средств программной реализации.. 33

2.1.1 Выбор СУБД.. 33

2.1.2 Выбор средств программной реализации. 33

2.2 Описание программной реализации системы.. 34

2.2.1 Описание структуры программного обеспечения. 3



2.2.2 Описание используемых классов и методов. 3

2.2.3 Физическая схема базы данных. 3

2.2.4 Диаграмма последовательности (Sequence Diagram) 3

2.2.5 Диаграмма кооперации (Сollaboration Diagram) 3

2.2.6 Диаграмма компонентов системы (Сomponent Diagram) 33

2.3 Разработка интерфейса программы.. 30

2.4 Программа и методика испытаний.. 30

2.4.1 Объект испытаний. 3

2.4.2 Цель испытаний. 3

2.4.3 Требования к программе. 3

2.4.4 Требования к программной документации. 3

2.4.5 Состав и порядок испытаний. 3

2.4.6 Методы испытаний. 3

2.5 Реализация контрольного примера.. 3

Заключение.. 3

Список использованных источников.. Ошибка! Закладка не определена.

ПРИЛОЖЕНИЕ А.. 3

Приложение Б.. 3

 


Введение

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

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



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

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

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



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


Системотехническая часть

1.1 Описание предметной области

 

Анализ многих тысяч изобретений позволил выявить, что при всём многообразии технических противоречий большинство из них решается 40 основными приёмами.

 

Работа по составлению списка таких приёмов была начата Г. С. Альтшуллером ещё на ранних этапах становления теории решения изобретательских задач. Для их выявления понадобился анализ более 40 тысяч авторских свидетельств и патентов. Приёмы эти и сейчас представляют для изобретателей большую эвристическую ценность. Их знание во многом позволяет облегчить поиск ответа.

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

Система приёмов, используемая в ТРИЗ, включает простые и парные (прием-антиприем). Простые приёмы позволяют разрешать технические противоречия. Среди простых приёмов наиболее популярны 40 основных приёмов. Парные приёмы состоят из приёма и антиприёма, с их помощью можно разрешать физические противоречия, так как при этом рассматривают два противоположных действия, состояния, свойства.

Стандарты на решение изобретательских задач представляют собой комплекс приёмов, использующих физические или другие эффекты для устранения противоречий. Это своего рода формулы, по которым решаются задачи. Для описания структуры этих приёмов Альтшуллером был создан вещественно-полевой (вепольный) анализ. Система стандартов состоит из классов, подклассов и конкретных стандартов. Эта система включает 76 стандартов. С помощью этой системы можно не только решать, но выявлять новые задачи и прогнозировать развитие технических систем. Она включает в себя:

· Технологические эффекты

· Физические эффекты

· Химические эффекты

· Биологические эффекты

· Математические эффекты

 

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

Физи́ческий эффе́кт — преобразование, при котором физическое воздействие на объект приводит к возникновению какого-то поля или действия. Как правило, это явления, связанные с преобразованием вида энергии или с изменением фазового состояния вещества.

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

Работу с комплексом осуществляют:

- изобретатель (подбор физических эффектов по параметрам);

- администратор БД (добавление контента в базу данных).

Перечень основных функций комплекса представлен на рисунке 1.

 

Рисунок 1 – Дерево основных функций комплекса

 

1.2 Постановка задачи

1.2.1 Цели проектирования

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

Комплекс должен поддерживать все функции, приведенные на рисунке 1.

 

1.2.1 Критерии эффективности, планируемые значения показателей эффективности проектируемой системы

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

Для разрабатываемого программного комплекса выделим следующие показатели эффективности:

1. Режим работы – диалоговый

2. Тип архитектуры – интернет приложение

3. Время реакции системы:

- Максимальная периодичность выдачи отчетов 1 минута;

- Максимальное время отклика системы – 30 секунд.

4. Система должна удовлетворять СанПИН 2.2.2.4-03.

5. Условия работы средств вычислительной техники должны соответствовать ГОСТ 1.12.005; ГОСТ 1.12.007.

1.3 Методы и алгоритмы решения задачи

1.3.1 Краткое описание методологии UML

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — в разработке программного обеспечения это отраслевой стандарт визуального языка моделирования 3-го поколения[2], который служит в основном для моделирования программных систем. Однако использование UML не ограничивается моделированием программного обеспечения. Он может быть использован для моделирования технических средств; кроме того, этот язык употребляется для моделирования бизнес-процессов и организационных структур.

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

В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group), который был образован еще в 1989 году с целью разработки предложений по стандартизации объектных и компонентных технологий CORBA. В то время язык UML приобрел статус второго стратегического направления в работе OMG. Именно в OMG создается команда разработчиков под руководством Р. Соли, которая обеспечила дальнейшую работу по унификации и стандартизации языка UML. Усилия группы разработчиков, в которую входили также Г. Буч, Дж. Румбах и А. Джекобсон, привели к появлению первых документов, содержащих собственно описание языка 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. Эти компании обеспечили поддержку последующей работы по более точному определению нотации.

В январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный вариант ответа на запрос предложений RTP. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность, предполагала решение широкого класса задач. В результате работы инициативной группы в составе OMG была предложена пересмотренная версия 1.1 языка UML. Основное внимание при разработке языка UML 1.1 было уделено достижению большей ясности семантики по сравнению с UML 1.0, а также учету предложений новых партнеров. Эта версия языка была представлена на рассмотрение OMG, затем одобрена и принята в качестве стандарта OMG в ноябре 1997 года. История разработки и последующего развития языка UML графически представлена на рисунке 1.1.

В настоящее время все вопросы дальнейшей разработки языка UML сконцентрированы в рамках консорциума OMG. При этом статус языка UML определен как открытый для всех предложений по его доработке и совершенствованию. Сам язык UML не является чьей-либо собственностью и не запатентован кем-либо, хотя указанный выше документ защищен законом об авторском праве. В тоже время аббревиатура UML, как и некоторые другие (OMG, CORBA, ORB), является торговой маркой их законных владельцев, о чем следует упомянуть в данном контексте.

На рынке CASE-средств представлены десятки программных инструментов, поддерживающих нотацию языка UML 1.4-1.5 и обеспечивающих интеграцию, включая прямую и обратную генерацию кода программ, с наиболее распространенными языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk.

С каждым годом интерес к языку UML со стороны специалистов неуклонно возрастает. Язык UML повсеместно становится не только основой для разработки и реализации во многих перспективных инструментальных RAD-средcтвах, но и в CASE–средствах визуального и имитационного моделирования. Более того, заложенные в языке UML потенциальные возможности широко используются как для объектно-ориентированного моделирования систем, так и для документирования бизнес-процессов, а в более широком контексте – для представления знаний в интеллектуальных системах, которыми, по существу, станут перспективные сложные программно-технологические комплексы.

 

Рисунок 2 – История развития языка UML

 

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

1.3.2 Краткое описание средства разработки проекта SoftwareIdeasModeller

SoftwareIdeasModeller – программная платформа моделирования, которая поддерживает UML (Унифицированный Язык Моделирования). Она основана на версии UML 1.4 и поддерживает нотацию UML версии 2.0 и одиннадцать различных типов диаграмм. Она активно поддерживает подход MDA (Архитектура Управляемая Моделью) и концепцию профилей UML. StarUML превосходен в отношении настройки окружения пользователя и имеет высокую степень расширяемости в том, что касается его функциональных возможностей.

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

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

StarUML - платформа моделирования программ. Преимущества расширяемой платформы:

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

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

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

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

1.3.3 Краткое описание теории решения изобретательских задач

ТРИЗ — теория решения изобретательских задач — область знаний, исследующая механизмы развития технических систем с целью создания практических методов решения изобретательских задач. "Цель ТРИЗ: опираясь на изучение объективных закономерностей развития технических систем, дать правила организации мышления по многоэкранной схеме" Автор ТРИЗ — Генрих Саулович Альтшуллер.

 

Появление ТРИЗ было вызвано потребностью ускорить изобретательский процесс, исключив из него элементы случайности: внезапное и непредсказуемое озарение, слепой перебор и отбрасывание вариантов, зависимость от настроения и т. п. Кроме того, целью ТРИЗ является улучшение качества и увеличение уровня изобретений за счёт снятия психологической инерции и усиления творческого воображения.

 

Основные функции и области применения ТРИЗ:

 

· решение изобретательских задач любой сложности и направленности;

· прогнозирование развития технических систем;

· пробуждение, тренировка и грамотное использование природных способностей человека в изобретательской деятельности (прежде всего образного воображения и системного мышления);

· совершенствование коллективов (в том числе творческих) по направлению к их идеалу (когда задачи выполняются, но на это не требуется никаких затрат).

ТРИЗ не является строгой научной теорией. ТРИЗ представляет собой обобщённый опыт изобретательства и изучения законов развития науки и техники.

 

В результате своего развития ТРИЗ вышла за рамки решения изобретательских задач в технической области, и сегодня используется также в нетехнических областях (бизнес, искусство, литература, педагогика, политика и др.).

Когда техническая проблема встаёт перед изобретателем впервые, она обычно сформулирована расплывчато и не содержит в себе указаний на пути решения. В ТРИЗ такая форма постановки называется изобретательской ситуацией. Главный её недостаток в том, что перед инженером оказывается чересчур много путей и методов решения. Перебирать их все трудоёмко и дорого, а выбор путей наудачу приводит к малоэффективному методу проб и ошибок.

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

На практике идеальный конечный результат редко достижим полностью, однако он служит ориентиром для изобретательской мысли. Чем ближе решение к ИКР, тем оно лучше.

Получив инструмент отсечения неэффективных решений, можно переформулировать изобретательскую ситуацию в стандартную мини-задачу: «согласно ИКР, всё должно остаться так, как было, но либо должно исчезнуть вредное, ненужное качество, либо появиться новое, полезное качество». Основная идея мини-задачи в том, чтобы избегать существенных (и дорогих) изменений и рассматривать в первую очередь простейшие решения.

Формулировка мини-задачи способствует более точному описанию задачи:

· Из каких частей состоит система, как они взаимодействуют?

· Какие связи являются вредными, мешающими, какие — нейтральными, и какие — полезными?

· Какие части и связи можно изменять, и какие — нельзя?

· Какие изменения приводят к улучшению системы, и какие — к ухудшению?

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

ТРИЗ выделяет 3 вида противоречий (в порядке возрастания сложности разрешения):

· административное противоречие: «надо улучшить систему, но я не знаю как (не умею, не имею права) сделать это». Это противоречие является самым слабым и может быть снято либо изучением дополнительных материалов, либо принятием/снятием административных решений.

· техническое противоречие: «улучшение одного параметра системы приводит к ухудшению другого параметра». Техническое противоречие — это и есть постановка изобретательской задачи. Переход от административного противоречия к техническому резко понижает размерность задачи, сужает поле поиска решений и позволяет перейти от метода проб и ошибок к алгоритму решения изобретательской задачи, который либо предлагает применить один или несколько стандартных технических приёмов, либо (в случае сложных задач) указывает на одно или несколько физических противоречий.

· физическое противоречие: «для улучшения системы, какая-то её часть должна находиться в разных физических состояниях одновременно, что невозможно». Физическое противоречие является наиболее фундаментальным, потому что изобретатель упирается в ограничения, обусловленные физическими законами природы. Для решения задачи изобретатель должен воспользоваться справочником физических эффектов и таблицей их применения.

 

1.4 Построение модели анализа

1.4.1 Диаграмма вариантов использования (Use Case Diagram)

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

Комментарии к вариантам использования:

- регистрация – в системе для дальнейшего использования функционала поп просмотру статистики по наиболее популярным физическим эффектам и патентам;

- авторизация – вход в систему по ранее созданной учетной записи;

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

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

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

- ведение справочника типов энергии – ведение названий типов энергии;

- ведение справочника выполняемых функций – ведение названий выполняемых функций;

- просмотр статистики по наиболее популярным физическим эффектам – ознакомление с 10 наиболее популярными физическими эффектами;

- просмотр статистики по наиболее популярным патентам – ознакомление с 10 наиболее популярными патентами;

 

- Подбор физических эффектов по виду энергии – выбор вида энергии для подборки физических эффектов.

 

- Подбор физических эффектов по выполняемым функциям – выбор выполняемой функции для подборки физических эффектов.

 

- Просмотр списка названий подобранных патентов – просмотр патентов, подобранных по физическим эффектам.

 

- Просмотр описания патента – подробный просмотр патента.

 

Рисунок 3 – Диаграмма вариантов использования

1.4.2 Сценарии вариантов использования

1) Вариант использования: Вести справочник физических эффектов

 

Краткое описание: Дает возможность администратору БД вести справочник физических эффектов.

 

Актант: Администратор БД

 

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

 

Основной поток событий:

1) В главном меню администратор БД щелкает надпись “Физические эффекты”.

2) Система открывает форму со справочником физических эффектов с таблицей, содержащей столбцы «Название физического эффекта», «Описание физического эффекта», «Типы энергии» и «Выполняемые функции». Также около каждой записи имеются надписи «Добавить запись», «Удалить запись», «Редактировать запись». Таблица заполнена записями физ. Эффектов, которые можно отбирать по типу энергии и выполняемому действию выбираю критерий в выпадающем списке над таблицей с соответствующим подключенным справочником. Также имеется кнопка «Вернуться в главное меню».

 

3) Администратор БД щелкает кнопку «Редактировать запись».

А1: Щелкнута кнопка «Вернуться в главное меню».

А2: Щелкнута кнопка «Добавить запись».

А3: Щелкнута кнопка «Удалить запись».

 

4) Система открывает форму редактирования выбранной записи с полями ввода «Название физического эффекта» и полем «Описание физического эффекта». Также на форме имеются кнопки «Сохранить» и «Отмена».

 

5) Администратор БД щелкает на поле «Название физического эффекта» и меняет название физического эффекта на необходимое. Аналогичным образом происходит процесс редактирования поля «Описание физического эффекта».

А4: Щелкнута кнопка «Отмена».

 

6) Администратор БД нажимает кнопку «Сохранить».

А4: Щелкнута кнопка «Отмена».

 

7) Система изменяет соответствующую запись в справочнике физических эффектов и закрывает форму редактирования, а затем возвращает Администратора БД на форму с обновленным справочником физических эффектов.

Вариант использования завершается успешно.

 

Альтернативы:

А1: Щелкнута кнопка «Вернуться в главное меню»

А1.1 Система закрывает форму справочника физических эффектов и возвращает Администратора БД в главное меню.

Вариант использования завершается.

 

А2: Щелкнута кнопка «Добавить запись»

 

А2.1 Система открывает форму редактирования выбранной записи с полями ввода «Название физического эффекта» и полем «Описание физического эффекта». Также на форме имеются кнопки «Сохранить» и «Отмена»

 

А2.2 Администратор БД щелкает по полю «Название физического эффекта» и вводит название физического эффекта. Аналогичным образом происходит процесс ввода «Описание физического эффекта».

 

А2.2 А1: Нажата кнопка «Отмена»

А2.2А1.1 Система закрывает форму добавления, изменения в БД не сохраняются, а затем возвращает Администратора БД на форму справочника физических эффектов. Выполняется пункт 3 основной последовательности.

 

А2.3 Администратор БД нажимает кнопку «Сохранить».

А2.2 А1: Нажата кнопка «Отмена»

А2.2А1.1 Система закрывает форму добавления, изменения в БД не сохраняются, а затем возвращает Администратора БД на форму справочника физических эффектов. Выполняется пункт 3 основной последовательности.

 

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

 

А3 Щелкнута кнопка «Удалить запись»

А3.1 Система выводит диалоговое окно с надписью «Подтвердите удаление физического эффекта» и кнопками «Подтвердить» и «Отмена».

 

А3.2 Администратор БД щелкает кнопку «Подтвердить»

А3.2 А1: Нажата кнопка «Отмена»

А3.2 А1.1 Система закрывает диалоговое окно, не удаляя запись. На экране – форма справочника физических эффектов в исходном виде.

 

Вариант использования завершается.

 

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

 

А4 Нажата кнопка «Отмена»

А4.1 Система закрывает форму редактирования, изменения в БД не сохраняются, а затем возвращает Администратора БД на форму справочника физических эффектов в исходном виде. Выполняется пункт 3 основной последовательности.

 

2) Вариант использования: Просмотр статистики

 

Краткое описание: Дает возможность авторизованному пользователю просматривать статистику по наиболее популярным физическим эффектам и по наиболее популярным патентам.

 

Актант: Авторизованный пользователь

 

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

 

Основной поток событий:

1) В главном меню авторизованный пользователь щелкает пункт “Статистика”.

 

2) Система открывает страницу со ссылками «Популярные физические эффекты» и «Популярные патенты» во фрейме.

 

3) Авторизованный пользователь левой кнопкой мыши нажимает на ссылку «Популярные физические эффекты»

А1 Щелкнута кнопка «Популярные патенты»

 

4) Система открывает новую страницу во фрейме с таблицей, содержащей поля «Название физического эффекта», «Краткое описание физического эффекта» и «Число использований». Записи в таблице упорядочены по популярности (число использований); данные выводятся по 10 элементам списка.

 

5) Авторизованный пользователь просматривает список физических эффектов и закрывает браузер.

 

Вариант использования завершается успешно.

 

Альтернативы:

А1. Щелкнута кнопка «Популярные патенты»

А1.1 Система открывает новую страницу во фрейме с таблицей, содержащей поля «Название патента», «Краткое описание патента» и «Число использований». Записи в таблице упорядочены по популярности (число использований); данные выводятся по 10 элементам списка.

А1.2 Авторизованный пользователь просматривает список патентов и закрывает браузер.

 

Вариант использования завершается.

1.4.3 Диаграммы классов (Class Diagram)

1.4.3.1 Диаграмма сущностных классов

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

Диаграмма сущностных классов комплекса представлена на рисунке 4.

 

Рисунок 4 – Диаграмма сущностных классов

1.4.3.2 Диаграмма классов управления

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

Диаграмма классов управления комплекса представлена на рисунке 5.

Рисунок 5 – Диаграмма классов управления

1.4.3.3 Диаграмма граничных классов

Объекты этих классов реали­зуют интерфейсы системы с внешней средой и различными пользователями.

Диаграмма классов управления комплекса представлена на рисунке 6.

 

Рисунок 6 – Диаграмма граничных классов

 

1.4.4 Диаграммы состояний (Statechart Diagram)

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

Диаграмма состояний для комплекса представлена на рисунке 7.

 

 

Рисунок 7 – Диаграмма состояний системы

 

1.5 Расчет внешней памяти

Проведём расчёт необходимой внешней памяти, воспользовавшись формулой:

(1)

где – объем необходимой внешней памяти;

– объем внешней памяти, необходимый операционной системе;

– объем внешней памяти, необходимый для дополнительно необходимого ПО;

– объем внешней памяти, требующихся для размещения СУБД;

– объем внешней памяти, необходимый программе;

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

Учитывая, что требования к клиенту и серверу различны, следует рассчитать два значения: для сервера и для клиента.

Сервер

Для расчёта примем, что программа функционирует в операционной системе Microsoft Windows 2003 Server, которой необходимо внешней памяти.

В качестве СУБД используется Microsoft SQL Server 2008 r2.

В качестве дополнительного ПО выступает платформа Microsoft .NET Framework 4.0 и web-сервер Internet Information Server 6 (IIS). После установки .NET Framework занимает 450 Мб, IIS – 150 Мб.

 

Для расчета объема хранимых данных предположим наихудший случай: система будет функционировать 2 года (за это время она морально устареет и будет заменена). Индекс ориентировочно составляет 15% от основного объема данных. Расчет данных на 2 года представлен в таблице 1.

 

Таблица 1 – Расчет объема данных

Имя таблицы БД Размер записи, байт Максимальное количество записей Размер индекса, байт Итого, байт
Пользователь
Роль
Документ
Физический эффект
Тип энергии
Выполняемые функции
Тип документа
ВСЕГО        

 

= 2 Мбайт = 0,002Гб;

= 1+ 0,001 + 0,5+ 0,28+ 0,002 = 1,8Гб;

Клиент

Считаем, что клиент работает под управлением ОС Windows XP Home Edition. Для работы ему больше ничего не требуется, кроме Internet Explorer c установленным плагином Silverlight, который входит в поставку операционной системы, поэтому

 

1.6 Расчет оперативной памяти

Проведем расчет необходимого объема ОЗУ, воспользовавшись формулой:

(2)

где – объем необходимой оперативной памяти;

– объем оперативной памяти, необходимый операционной системе;

– объем оперативной памяти, необходимый для дополнительно необходимого ПО;

 








Не нашли, что искали? Воспользуйтесь поиском по сайту:



©2015 - 2024 stydopedia.ru Все материалы защищены законодательством РФ.