Аннотация Рассматриваются вопросы, связанные с анализом предметной области и выделением требований к разрабатываемой программной системе, а также основные графические модели, используемые в этих деятельностях — диаграммы потоков данных и вариантов использования. Ключевые слова Анализ предметной области, схема Захмана, модели предметной области, диаграммы потоков данных, диаграммы сущностей и связей, функции ПО, требования к ПО, варианты использования, действующие лица, диаграммы вариантов использования. Текст лекции
Анализ предметной области
Для того, чтобы разработать программную систему, приносящую реальные выгоды определенным пользователям, необходимо сначала выяснить, какие же задачи она должна решать для этих людей и какими свойствами обладать. Требования к ПО определяют, какие свойства и характеристики оно должно иметь для удовлетворения потребностей пользователей и других заинтересованных лиц.
Однако сформулировать требования к сложной системе не так легко. В большинстве случаев будущие пользователи могут перечислить набор свойств, который они хотели бы видеть, но никто не даст гарантий, что это — исчерпывающий список.
О проектировании БД. Описание предметной области.
Кроме того, часто сама формулировка этих свойств будет непонятна большинству программистов: могут прозвучать фразы типа «должно использоваться и частотное, и временное уплотнение каналов», «передача клиента должна быть мягкой», «для обычных швов отмечайте бригаду, а для доверительных — конкретных сварщиков», и это еще не самые тяжелые для понимания примеры. Чтобы ПО было действительно полезным, важно, чтобы оно удовлетворяло реальные потребности людей и организаций, которые часто отличаются от непосредственно выражаемых пользователями желаний.
Для выявления этих потребностей, а также для выяснения смысла высказанных требований приходится проводить достаточно большую дополнительную работу, которая называется анализом предметной области или бизнес-моделированием , если речь идет о потребностях коммерческой организации. В результате этой деятельности разработчики должны научиться понимать язык, на котором говорят пользователи и заказчики, выявить цели их деятельности, определить набор задач, решаемых ими.
В дополнение стоит выяснить, какие вообще задачи нужно уметь решать для достижения этих целей, выяснить свойства результатов, которые хотелось бы получить, а также определить набор сущностей, с которыми приходится иметь дело при решении этих задач. Кроме того, анализ предметной области позволяет выявить места возможных улучшений и оценить последствия принимаемых решений о реализации тех или иных функций.
После этого можно определять область ответственности будущей программной системы — какие именно из выявленных задач будут ею решаться, при решении каких задач она может оказать существенную помощь и чем именно. Определив эти задачи в рамках общей системы задач и деятельностей пользователей, можно уже более точно сформулировать требования к ПО. Анализом предметной области занимаются системные аналитики или бизнес-аналитики , которые передают полученные ими знания другим членам проектной команды, сформулировав их на более понятном разработчикам языке. Для передачи этих знаний обычно служит некоторый набор моделей, в виде графических схем и текстовых документов. Анализ деятельности крупной организации, такой, как банк с сетью региональных отделений, нефтеперерабатывающий завод или компания, производящая автомобили, дает огромные объемы информации. Из этой информации надо уметь отбирать существенную, а также надо уметь находить в ней пробелы — области деятельности, информации по которым недостаточно для
Декомпозиция предметной области (на примере магазина)
четкого представления о решаемых задачах. Значит, всю получаемую информацию надо каким-то образом систематизировать. Для систематизации сбора информации о больших организациях и дальнейшей разработки систем, поддерживающих их деятельность, применяется схема Захмана (автор — John Zachman, [1,2]) или архитектурная схема предприятия (enterprise architecture framework) .
| Мотивация | Люди | Данные | Функции | Место | Время | |
| Контекст | ||||||
| Модель бизнеса | ||||||
| Системная | ||||||
| модель | ||||||
| Технологическая | ||||||
| модель | ||||||
| Детальное | ||||||
| представление | ||||||
| Работающая | Стратегия и | Структура | Данные | Выполняемые | Географическое | Планы |
| организация | тактика | организации | функции | расположение и | ||
| сети |
Таблица 5. Схема Захмана. Приведены примеры моделей для отдельных клеток. В основе схемы Захмана лежит следующая идея: деятельность даже очень большой организации можно описать, используя ответы на простые вопросы — зачем, кто, что, как, где и когда, — и разные уровни рассмотрения.
Обозначенные 6 вопросов определяют 6 аспектов рассмотрения. • Цели организации и базовые правила, по которым она работает. • Персонал, подразделения и другие элементы организационной структуры, связи между ними. • Сущности и данные, с которыми имеет дело организация. • Выполняемые организацией и различными ее подразделениями функции и операции над данными. • Географическое распределение элементов организации и связи между географически разделенными ее частями. • Временные характеристики и ограничения на деятельность организации, значимые для ее деятельности события. Также выделены несколько уровней рассмотрения, из которых при бизнес-моделировании особенно важны три верхних. • Самый крупный — уровень организации в целом, рассматриваемой в ее развитии совместно с окружением, уровень общего планирования ее деятельности. Этот уровень содержит долговременные цели и задачи организации как цельной системы, основные связи организации с внешним миром и основные виды ее деятельности.
• Уровень бизнеса, на котором организация рассматривается во всех аспектах как отдельная сущность, имеющая определенную структуру, которая соответствует ее основным задачам. • Системный уровень, на котором определяются концептуальные модели всех аспектов организации, без привязки к конкретным их воплощениям и реализациям, например, логическая модель данных в виде набора сущностей и связей между ними, логическая архитектура системы автоматизации в виде набора узлов, с привязанными к ним функциями и пр. Наиболее удобной формой представления информации при анализе предметной области являются графические диаграммы различного рода.
Они позволяют достаточно быстро зафиксировать полученные знания, быстро восстанавливать их в памяти и успешно объясняться с заказчиками и другими заинтересованными лицами. Набросать рисунок из прямоугольников и связывающих их стрелок обычно можно гораздо быстрее, чем записать соответствующий объем информации, и на рисунке за один взгляд видно гораздо больше, чем в тексте.
Изредка встречаются люди, лучше ориентирующиеся в текстах и более адекватно их понимающие, но чаще рисунки все же более удобны для иллюстрации мыслей и объяснения сложных вещей. Рисунок 16. Схема деятельности компании в нотации Йордана-ДеМарко.
Часто для описания поведения сложных систем и деятельности крупных организаций используются диаграммы потоков данных (data flow diagrams) . Эти диаграммы содержат 4 вида графических элементов: процессы , представляющие собой любые трансформации данных в рамках описываемой системы, хранилища данных , внешние по отношению к системе сущности и потоки данных между элементами трех предыдущих видов. Используются несколько систем обозначений для перечисленных элементов, наиболее известны нотация Йордана-ДеМарко (Yourdon-DeMarco, [3,4]) и нотация Гэйна-Сарсона (GaneSarson, [5]), обе предложенные в 1979 году.
Рис. 16 показывает диаграмму потоков данных, которая описывает деятельность компании, управляющей небольшим магазином. Эта диаграмма изображена в нотации Йордана-ДеМарко: процессы изображаются кружками, внешние сущности — прямоугольниками, а хранилища данных — двумя горизонтальными параллельными линиями. На Рис. 17 изображена та же диаграмма в нотации Гейна-Сарсона: на ней процессы —
прямоугольники со скругленными углами, внешние сущности — прямоугольники с тенью, а хранилища данных — вытянутые горизонтально прямоугольники без правого ребра. Рисунок 17. Схема деятельности компании в нотации Гэйна-Сарсона.
Процессы на диаграммах потоков данных могут уточняться: если некоторый процесс устроен достаточно сложно, для него можно нарисовать отдельную диаграмму, описывающую потоки данных внутри этого процесса. На ней показываются те элементы, с которыми этот процесс связан потоками данных, и составляющие его более мелкие процессы и хранилища.
Таким образом, возникает иерархическая структура процессов. Обычно на самом верхнем уровне находится один процесс, представляющий собой систему в целом, и набор внешних сущностей, с которыми она взаимодействует. На Рис. 18 показана возможная детализация процесса «Управление персоналом».
Диаграммы потоков данных появились как один из первых инструментов представления деятельности сложных систем при использовании структурного анализа . Для представления структуры данных в этом подходе используются диаграммы сущностей и связей (entityrelationship diagrams, ER diagrams) [6], изображающие набор сущностей предметной области и связей между ними. И сущности, и связи на таких диаграммах могут иметь атрибуты.
Пример такой диаграммы представлен на Рис. 19. Хотя методы структурного анализа могут значительно помочь при анализе систем и организаций, дальнейшая разработка системы, поддерживающей их деятельность, с использованием объектно-ориентированного подхода часто требует дополнительной работы по переводу полученной информации в объектно-ориентированные модели. Методы объектно-ориентированного анализа предназначены для обеспечения более удобной передачи информации между моделями анализируемых систем и моделями разрабатываемого ПО. В качестве графических моделей в этих методах вместо диаграмм потоков данных используются рассматривавшиеся при обсуждении RUP диаграммы вариантов использования, а вместо диаграмм сущностей и связей — диаграммы классов.
Рисунок 18. Детализация процесса «Управление персоналом». Однако диаграммы вариантов использования несут несколько меньше информации по сравнению с соответствующими диаграммами потоков данных: на них процессы и хранилища в соответствии с принципом объединения данных и методов работы с ними объединяются в варианты использования, и остаются только связи между вариантами использования и действующими лицами (аналогом внешних сущностей). Для представления остальной информации каждый вариант использования может дополняться набором разнообразных диаграмм UML — диаграммами деятельностей, диаграммами сценариев, и пр. Обо всех этих видах диаграмм будет рассказано в лекции, посвященной архитектуре программного обеспечения.
| Заказ | Заказанный товар | Товар |
| Дата | Наименование | |
| Количество единиц | ||
| Стоимость | Цена за единицу |
| Товар у поставщика | ||
| Цена за единицу | ||
| Клиент | ||
| Размер партии | ||
| Имя | Поставщик | Стоимость доставки |
| Адрес | ||
| Название | ||
| Адрес | ||
| Реквизиты |
Рисунок 19. Модель сущностей и связей. 52
Источник: studfile.net
Описание предметной области с использованием UML при разработке программных систем
Моделирование предметной области является одним из наиболее важных этапов работ при проектировании программных систем масштаба предприятия.
В настоящее время для целей моделирования предметной области на рынке программных продуктов представлен широкий спектр CASE-средств. Наиболее популярными в нашей стране CASE-средствами являются Rational Rose, CA BPwin, Silverrun, Sybase PowerDesigner. Моделирование предметной области в этих средствах имеет больше сходств, чем различий. Однако немаловажным, с нашей точки зрения, является комплексность подхода и использование единой унифицированной нотации не только на этапе моделирования предметной области, но и на последующих этапах разработки программной системы, как это имеет место в Rational Rose.
В настоящей статье на конкретном примере демонстрируется возможный подход к моделированию предметной области с использованием унифицированной нотации, основанный на применении унифицированного языка моделирования (Unified Modeling Language, UML) и гармонично сочетающий в себе достоинства структурных и объектных методов проектирования в Rational Rose.
Итак, основными задачами при моделировании предметной области являются описания [1, 2]:
- бизнес-процессов предприятия;
- действующих лиц бизнес-процессов и их функций, подлежащих автоматизации в привязке к структуре автоматизируемого предприятия;
- бизнес сущностей;
- сценариев выполнения бизнес-функций, подлежащих автоматизации.
- состояний бизнес-сущностей;
- бизнес-правил.
Описание бизнес-процессов используется для описания технологии выполнения производственной задачи, подлежащей автоматизации [1]. На основе описанной технологии определяются виды деятельности, которые следует автоматизировать (бизнес-требования к будущей программной системе).
При описании бизнес-процессов должны быть выявлены связи между различными подразделениями предприятия при решении конкретных производственных задач (горизонтальные связи). И только в этом случае описание бизнес-процессов может считаться корректным.
На рис. 1 представлен пример описания бизнес-процессов с использованием диаграммы деятельности (Activity Diagram) UML и Case Rational Rose.
Рассмотрена задача, которую следует автоматизировать: «Оприходование товара на складе предприятия от продавца».
На диаграмме обозначены виды деятельности, связанные с решением задачи, подлежащей автоматизации, входные и выходные документы или данные, связанные с конкретной деятельностью, исполнители различных видов деятельности, а также подразделения, в которых данный вид деятельности выполняется.
На основе описания бизнес-процессов с использованием диаграммы деятельности (Activity Diagram) определяются виды деятельности, которые следует автоматизировать.
Из примера на рис. 1 видно, что таковыми являются (отмечены цветом) следующие виды деятельности:
- выписывает доверенность;
- выписывает приемный акт в двух экземплярах;
- регистрирует товар в картотеке;
- передает экземпляр акта в бухгалтерию;
- получает приходный акт.
Следует отметить, что накопленный авторам опыт при описании бизнес-процессов с использованием различных CASE-средств, например BPwin, Silverrun, Power Designer и Rational Rose, показал, что наиболее понятным описанием бизнес-процессов для обсуждения его с экспертами предметной области и получения от них конструктивных замечаний является представленная выше нотация в Rational Rose.
На наш взгляд, это объясняется следующими причинами:
- соответствие парадигмы диаграммы деятельности представлению пользователей о бизнес-процессе;
- четкое ролевое выражение ответственностей за ту или иную деятельность;
- возможность совмещения в диаграммах описания документов, связанных с деятельностью и их состояний;
- развитая нотация описания состояний бизнес-сущностей (при использовании объектов).
- четко отслеживаемые горизонтальные связи между подразделениями, что позволяет структурировать процессы предметной области (абсолютно необходимо для последующих этапов проектирования).
Следующим шагом при описании предметной области является разработка модели структуры предприятия, на которой отражены только действующие лица и их функции, подлежащие автоматизации. Модель отражает иерархическую структуру предприятия (вертикальные связи) [1].
На основе этой модели строится модель функций системы.
Модель структуры предприятия строится на основе описания бизнес-процессов. В модели отражаются только те отделы, те действующие лица и их функции, которые будут автоматизированы. Построение модели можно производить поэтапно, по мере описания бизнес-процессов. Диаграмм с бизнес-процессами может быть очень много, но модель со структурой предприятия должна быть одна.
На рис. 2-7 представлена модель структуры предприятия, построенная с использованием диаграммы функций UML (Use CASE Diagram).
Особенностью модели структуры предприятия является наличие связей по управлению, что в дальнейшем позволит произвести декомпозицию системы на подсистемы последующих уровней и на стадиях анализа и проектирования эффективно применить объектные модели и методы для разработки структуры программных компонентов и данных.
Следующей задачей при описании предметной области является моделирование документов [2].
Цель моделирования документов — описать атрибуты документов, их типы, значения, правила формирования для проектирования пользовательского интерфейса системы, проектирования базы данных системы; формирования альбома выходных форм системы.
На рис. 8 представлен пример модели документа «Приемный акт», разработанный с использованием диаграммы классов (Class Diagram) языка UML в CASE Rational Rose.
Дополнительным преимуществом при моделировании документов в Rational Rose является возможность присоединение к модели документа или бизнес-сущности описания его внешнего вида с примером, подготовленным, например, в редакторе Microsoft Word.
В некоторых случаях при моделировании предметной области следует описать сценарий работы действующего лица с бизнес-сущностями и состояние бизнес-сущностей.
Сценарии функций предметной области могут использоваться при проектировании сценариев работы пользователя с будущей системой, описание состояний бизнес-сущностей — для проектирования пользовательского интерфейса (справочника состояний бизнес-сущностей) и базы данных программной системы. К тому же наличие сценариев бизнес-функций в дальнейшем позволит уточнить функциональные требования к системе.
На рис. 9 представлен пример описанного с использованием диаграммы последовательности действий UML (Sequence Diagram) сценария работы кладовщика с карточкой товара и накладной а на рис. 10 — пример диаграммы состояний приемного акта, описанного с использованием диаграммы состояний (State Diagram).
При описании предметной области не следует забывать о моделировании бизнес-правил [2]. Модели бизнес-правил предметной области будут являться основой для моделирования правил программной системы. Для моделирования бизнес-правил могут использоваться диаграммы деятельностей (Activity Diagram) и диаграммы классов (Class Diagram). Диаграммы деятельностей могут использоваться для моделирования, например, алгоритмически описываемых правил, диаграммы классов — для моделирования структурных правил.
Итак, подводя итог вышесказанному об описании предметной области при разработке программных систем, отметим следующее:
- Описание предметной области должно включать не только описание бизнес-процессов но и описание структуры автоматизируемого предприятия, его действующих лиц, их автоматизируемых функций, документов, связанных с автоматизированными функциями, прочих бизнес-сущностей, сценариев реализации бизнес-функций и состояний бизнес-сущностей:
- модель бизнес-процессов используется для определения бизнес-требований к разрабатываемой системе и выявления всех связей между подразделениями, принимающими участие в решении конкретной задачи;
- модель структуры предприятия используется для отражения действующих лиц предприятия, их автоматизируемых функций в привязке к подразделениям, в которых эти функции выполняются. На основе модели структуры предприятия разрабатывается модель функций системы;
- модели документов, бизнес-сущностей используются при проектировании пользовательского интерфейса, базы данных, формирования альбома выходных форм системы;
- модели сценариев реализации бизнес-функций используются при проектировании сценариев пользовательского интерфейса;
- модели состояний бизнес-сущностей используются при проектировании пользовательского интерфейса и базы данных системы;
- модели бизнес-правил используются при моделировании правил программной системы.
- Результаты бизнес-моделирования в CASE-средстве Rational Rose могут быть легко преобразованы в документацию, соответствующую промышленным стандартам разработки программных систем.
- Полное и детальное описание предметной области очень удобно производить в CASE-средстве, поддерживающем универсальный язык моделирования UML.
В отличие от CASE Rational Rose популярные в нашей стране BPwin, Silverrun, Process Analist не имеют пока полноценной поддержки всех перечисленных выше этапов бизнес-моделирования, что ограничивает сферу их применения.
Описание предметной области с использованием UML хорошо воспринимается экспертами предметной области и для понимания представленных им на рассмотрение моделей не требует никакой специальной подготовки.
К примеру, как показывает опыт авторов, модели процессов, построенные в BPwin, вызывают трудности при понимании их экспертами предметной области. Это приводит к тому, что эксперты становятся пассивными слушателями при обсуждении описания бизнес-процессов и им, по существу, навязывается понимание бизнес-процессов аналитиками. Ошибки неправильного описания бизнес-процессов затем выявляются, но к сожалению, на более поздних этапах разработки программной системы.
В заключение хотелось бы отметить, что мы не навязываем своего мнения относительно достоинств или недостатков того или иного CASE-средства, но, на наш взгляд UML использование Rational Rose и других CASE-средств, поддерживающих для целей, обозначенных в статье, является предпочтительным.
- Chris Marshal, Enterprise Modeling with UML. Designing Successful Software through Business Analysis;
- Rational Unified Proсess.
- ПК и комплектующие
- Настольные ПК и моноблоки
- Портативные ПК
- Серверы
- Материнские платы
- Корпуса
- Блоки питания
- Оперативная память
- Процессоры
- Графические адаптеры
- Жесткие диски и SSD
- Оптические приводы и носители
- Звуковые карты
- ТВ-тюнеры
- Контроллеры
- Системы охлаждения ПК
- Моддинг
- Аксессуары для ноутбуков
- Принтеры, сканеры, МФУ
- Мониторы и проекторы
- Устройства ввода
- Внешние накопители
- Акустические системы, гарнитуры, наушники
- ИБП
- Веб-камеры
- KVM-оборудование
- Сетевые медиаплееры
- HTPC и мини-компьютеры
- ТВ и системы домашнего кинотеатра
- Технология DLNA
- Средства управления домашней техникой
- Планшеты
- Смартфоны
- Портативные накопители
- Электронные ридеры
- Портативные медиаплееры
- GPS-навигаторы и трекеры
- Носимые гаджеты
- Автомобильные информационно-развлекательные системы
- Зарядные устройства
- Аксессуары для мобильных устройств
- Цифровые фотоаппараты и оптика
- Видеокамеры
- Фотоаксессуары
- Обработка фотографий
- Монтаж видео
- Операционные системы
- Средства разработки
- Офисные программы
- Средства тестирования, мониторинга и диагностики
- Полезные утилиты
- Графические редакторы
- Средства 3D-моделирования
- Веб-браузеры
- Поисковые системы
- Социальные сети
- «Облачные» сервисы
- Сервисы для обмена сообщениями и конференц-связи
- Разработка веб-сайтов
- Мобильный интернет
- Полезные инструменты
- Средства защиты от вредоносного ПО
- Средства управления доступом
- Защита данных
- Проводные сети
- Беспроводные сети
- Сетевая инфраструктура
- Сотовая связь
- IP-телефония
- NAS-накопители
- Средства управления сетями
- Средства удаленного доступа
- Системная интеграция
- Проекты в области образования
- Электронный документооборот
- «Облачные» сервисы для бизнеса
- Технологии виртуализации
| 1999 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2000 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2001 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2002 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
Популярные статьи
В настоящем обзоре мы рассмотрим модель моноблока от компании HP, которая является признанным лидером в производстве компьютеров как для домашнего использования, так и для офисов. Моноблок HP 205 G4 22 — модель нового семейства, которая построена на базе процессоров AMD последнего поколения и отличается неплохой производительностью вкупе с привлекательной ценой
Швейцарская компания Logitech G представила беспроводную игровую мышь Logitech G PRO X Superlight. Новинка предназначена для профессиональных киберспортсменов, а слово Superlight в ее названии указывает на малый вес этой модели, который не превышает 63 г. Это почти на четверть меньше по сравнению с анонсированным пару лет тому назад манипулятором Logitech G PRO Wireless
Как показало недавнее исследование Кембриджского университета — количество людей, которые пользуются сегодня криптовалютами, приближается к размеру населения небольшой страны и это только начало, мир меняется. Поэтому компания ASRock разработала и выпустила в продажу весьма необычную материнскую плату — H110 PRO BTC+, которую мы и рассмотрим в этом обзоре
Компания Rapoo анонсировала в Китае беспроводную клавиатуру Ralemo Pre 5 Fabric Edition. Новинка выполнена в формате TKL (без секции цифровых клавиш) и привлекает внимание оригинальным дизайном. Одна из отличительных особенностей этой модели — верхняя панель, обтянутая тканью с меланжевым рисунком
Линейку компьютерных мониторов MSI пополнила модель Optix MAG301 CR2, адресованная любителям игр. Она оборудована ЖК-панелью типа VA со сверхширокоформатным (21:9) экраном изогнутой формы (радиус закругления — 1,5 м). Его размер — 29,5 дюйма по диагонали, разрешение — 2560×1080 пикселов
Каталог продукции компании SilverStone пополнил комплект MS12. Он позволяет создать портативный накопитель на базе стандартного SSD типоразмера M.2 2280 с интерфейсом PCI Express
Компания ADATA Technology анонсировала твердотельные накопители серии XPG Spectrix S20G. Они предназначены для оснащения игровых ПК и, как утверждают их создатели, сочетают высокую производительность и эффектный внешний вид
Линейку видеоадаптеров ASUS на базе графических процессоров NVIDIA пополнила модель GeForce RTX 3070 Turbo (заводской индекс TURBO-RTX3070-8G), предназначенная для оснащения игровых ПК. Одной из особенностей новинки является конструкция системы охлаждения
КомпьютерПресс использует
Источник: compress.ru
Объектно-ориентированный анализ предметной области
В данной расчётно-пояснительной записке содержится информация по заданию на курсовую работу по дисциплине объектно-ориентированное программирование.
Предметная область курсовой работы «Офисная мебель».
Оглавление
Основная часть. 5
1. Изучение и описание предметной области. 5
2. Постановка задачи. 6
3. Объектно-ориентированный анализ предметной области. 7
4. Проектирование классов. 8
5. Логическая структура программы.. 12
6. Модульная структура программы.. 15
7. Проектирование интерфейса. 16
8. Тестирование программы.. 17
Список литературы.. 25
Приложение 1. Техническое задание. 26
Приложение 2. Текст программы.. 31
Приложение 3. Руководство пользователя. 59
Введение
В данной курсовой работе рассмотрены основные этапы объектно-ориентированного программирования на языке С++, реализован алгоритм выполнения поставленной задачи, а также выполнена трансляция кода в исполняемый файл.
Задача данной курсовой работы заключается в разработке иерархии родственных классов, корневой класс которой абстрактный базовый класс (класс-интерфейс), для моделирования и обработки данных предметной области набором отложенных методов — полиморфная обработка родственных объектов. Кроме того, реализация функций обработки данных, файловый вводвывод и ввод данных с клавиатуры, вывод данных на дисплей. Также необходимо предусмотреть обработку различных исключительных ситуаций и проверить работу всех функций.
Основная часть
Изучение и описание предметной области
Объектно-ориентированное программирование (ООП) — это способ организации кода в программе путем его группировки в виде объектов, то есть отдельных элементов, которые включают информацию (значения данных) и функции. Объектно-ориентированный подход к организации программы позволяет группировать определенные фрагменты информации вместе с часто используемыми функциями или действиями, связанными с этой информацией.
Инкапсуляция — это механизм программирования, объединяющий вместе код и данные, которыми он манипулирует, исключая как вмешательство извне, так и неправильное использование данных. В объектно-ориентированном языке данные и код могут быть объединены в совершенно автономный черный ящик. Внутри такого ящика находятся все необходимые данные и код. Когда код и данные связываются вместе подобным образом, создается объект. Иными словами, объект — это элемент, поддерживающий инкапсуляцию.
Наследование — это процесс, посредством которого один объект может приобретать свойства другого. Точнее, объект может наследовать основные свойства другого объекта и добавлять к ним черты, характерные только для него. Наследование является важным, поскольку оно позволяет поддерживать концепцию иерархии классов. Применение иерархии классов делает управляемыми большие потоки информации.
Полиморфизм — это свойство, которое позволяет одно и то же имя использовать для решения двух или более схожих, но технически разных задач. Целью полиморфизма, применительно к объектно-ориентированному программированию, является использование одного имени для задания общих для класса действий. Выполнение каждого конкретного действия будет определяться типом данных. Ключевым в понимании полиморфизма является то, что он позволяет вам манипулировать объектами различной степени сложности путём создания общего для них стандартного интерфейса для реализации похожих действий.
Абстрактный класс – это класс, который может использоваться лишь в качестве базового класса для некоторого другого класса. Класс является абстрактным, если он содержит хотя бы одну чистую виртуальную функцию.
При изучении и описании предметной области использовалась следующая литература [Джесс Либерти, Брэдли Л. Джонс Освой самостоятельно C++ за 21 день].
Предметная область курсовой работы согласно варианту «Офисная мебель».
Офисная мебель — основная функциональная составляющая любого рабочего интерьера. По своим эксплуатационным признакам она относится к категории малых архитектурных форм, ориентированных на создание максимально комфортной деловой среды.
Постановка задачи
Задание на курсовую работу включает в себя:
— Разработку иерархии родственных типов, корневой класс которой абстрактный базовый класс (класс-интерфейс), для моделирования и обработки данных предметной области набором отложенных методов — полиморфная обработка родственных объектов.
— Реализацию функций обработки данных (сортировка и поиск по выбранным полям и задаваемым диапазонам значений, другие функции, в том числе перегруженные).
— Реализацию файлового ввода/вывода и ввода данных с клавиатуры, вывода данных на дисплей.
— Создание обработчиков различных исключительных ситуаций.
— Проверку работы всех функций и оформление результатов проверки протоколом тестирования.
Программа должна выполнять следующие функции:
— Создание объектов классов;
— Поиск по таблице;
— Ввод данных с клавиатуры;
— Вывод данных на экран;
— Запись и чтение из файла для каждого класса;
— Очистка данных в таблице;
— Удаление выбранной строки в таблице;
— Обработка исключительных ситуаций, таких как добавление элемента некорректного типа данных; сохранение данных из таблицы, содержащих некорректный тип данных; загрузка данных из файла, содержащих некорректный тип данных;
— Полиморфная обработка родственных объектов.
Средой функционирования программного продукта является персональный компьютер на операционной системе Windows XP и выше. Среда программирования Visual Studio 2012 и выше на языке C++.
Параметры технических средств:
— Процессор с частотой 2 ГГц и выше;
— Наличие мыши и клавиатуры;
— Не менее 1 Гбайт оперативной памяти;
— 50 Мбайт свободной памяти – для установки;
— Монитор типа 640×480 или более высокой разрешающей способности.
Объектно-ориентированный анализ предметной области
Для описания предметной области была разработана следующая контекстная диаграмма классов (рис. 1.):
Рис. 1. Контекстная диаграмма классов
Офисная мебель по данной контекстной диаграмме разделена на 3 разновидности от базового класса Мебель: Сиденье, Шкаф, Стол. Каждая разновидность офисной мебели содержит свои собственные производные классы. От Сиденье происходят 2 производных класса Кресло и Диван. От Шкаф происходят Гардероб и Шкаф для документации. От Стол идут такие классы как Рабочий стол и Переговорный стол.
Все выше перечисленные классы относятся к класс-интерфейсу Office, с помощью которого осуществляется полиморфизм родственных классов.
Источник: megaobuchalka.ru