Реализация продукции на основе Case-средств

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

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

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

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

    В диаграмме классов могут участвовать  связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоцирование (association). Для проектирования реляционных БД наиболее важны вторая и третья категории связей. Поэтому по поводу связей-зависимостей мы будет очень кратки.  

    Связи-зависимости  

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

    Связи-обобщения  

    Связью-обобщением называется связь между общей  сущностью, называемой суперклассом, или  родителем, и более специализированной разновидностью этой сущности, называемой подклассом, или потомком. Обобщения  иногда называют связями “is a”, имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.  

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

    Связи-ассоциации  

    Ассоциацией называется структурная связь, показывающая, что объекты одного класса некоторым  образом связаны с объектами  другого или того же самого класса. Допускается, чтобы оба конца  ассоциации относились к одному классу. В ассоциации могут связываться два класса, и тогда она называется бинарной. Допускается создание ассоциаций, связывающих сразу n классов (они называются n-арными ассоциациями). Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами. 
 
 

      

    Рис.3 Диаграмма концептуальных классов 
 
 

    3.2.2. Диаграмма программных классов

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

    

    Рис.4 Диаграмма программных классов

    3.2.3. Диаграмма последовательности

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

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

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

    

    Рис.5 Диаграмма последовательности 
 
 
 
 

    3.3. Проектирование схемы  базы данных

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

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

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

    В процессе проектирования схему данных удобно представлять с помощью следующих  моделей (см. рис. 8.2):

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

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

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

    

    Рис.6 Схема базы данных 
 
 
 
 
 
 
 
 
 
 
 
 
 

    Заключение 

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

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

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

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

1. Моделирование бизнеса: средства и методы, Чеботарева В.
2. CASE-технологии. Современные методы и средства проектирования информационных систем, Вендров А.М.
3. CASE-технологии: практическая работа в Rational Rose, Трофимов С.А.
4. http://www.interface.ru/ca/bpwin.htm - описание bpwin.
5. http://www.citforum.ru/
6. http://www.intuit.ru/
7. UML 2 и Унифицированный процесс: практический объектно-ориентированный анализ и проектирование, 2-е издание, Джим Арлоу, Айла Нейштадт

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

    Приложение

    Схема декомпозиции: