Приклад опису предметної області з використанням Unified Modeling Language (UML) при розробці програмних систем

Моделювання предметної області є одним з найбільш важливих етапів робіт при проектуванні програмних систем масштабу підприємства.


В даний час для цілей моделювання предметної області на ринку програмних продуктів представлений широкий спектр CASE-засобів. Найбільш популярними в нашій странеCASE-засобами є Rational Rose, BPwin, Silverrun, Process Analyst. Моделювання предметної області в цих коштах має швидше багато спільного, ніж відмінного. Проте важливим, з нашої точки зору, є комплексність підходу і використання єдиної уніфікованої нотації, не тільки на етапі моделювання предметної області, але і на наступних етапах розробки програмної системи, як це має місце в CASE Rational Rose.


У цій статті на конкретному прикладі демонструється можливий підхід до моделювання предметної області з використанням уніфікованої нотації, заснований на застосуванні Уніфікованої Мови Моделювання (Unified Modeling Language) (UML), і гармонійно поєднує в собі переваги структурних і об'єктних методів проектування в CASE Rational Rose.


Отже, основними завданнями при моделюванні предметної області є опис:



  1. Бізнес-процесів підприємства;
  2. Дійових осіб бізнес-процесів та їх функцій, що підлягають автоматизації в прив'язці до структури автоматизується підприємства;
  3. Бізнес-сутностей;
  4. Сценаріїв виконання бізнес-функцій, що підлягають автоматизації;
  5. Станів бізнес-сутностей;
  6. Бізнес-правил.

Опис бізнес-процесів використовуються для опису технології виконання виробничої завдання, що підлягає автоматизації. На основі описаної технології визначаються види діяльності, які слід автоматизувати (Бізнес-вимоги до майбутньої програмної системи).


При описі бізнес-процесів повинні бути виявлені зв'язки між різними підрозділами підприємства при вирішенні конкретних виробничих завдань (горизонтальні зв'язки). І тільки в цьому випадку опис бізнес-процесів може вважатися коректним.


На рис. 1 представлений приклад опису бізнес-процесів з використанням діаграми діяльності (activity diagram) UML і CASE Rational Rose.


Розглянуто задачу, яку слід автоматизувати: "Оприбуткування товару на складі підприємства від продавця".

Рис. 1. Опис технології роботи складу
при оприбуткуванні товару від продавця


На діаграмі зображені види діяльності пов'язані з вирішенням завдання, що підлягає автоматизації, вхідні і вихідні документи або дані, пов'язані з конкретною діяльністю, виконавці діяльності та підрозділи, в яких вона виконується.


На основі опису бізнес-процесів з використанням діаграми діяльності (activity diagram) Визначаються види діяльності, які слід автоматизувати.


З прикладу на рис. 1 видно, що такими є (функції відзначені кольором) такі види діяльності:



  1. Виписує доручення;
  2. Виписує прийомний акт у двох примірниках;
  3. Реєструє товар у картотеці;
  4. Передає екземпляр акта в бухгалтерію;
  5. Отримує прибутковий акт.

Слід зазначити: наш значний досвід при описі бізнес-процесів з використанням різних CASE-засобів, наприклад, BPwin, Silverrun, Process Analyst і Rational Rose показав, що найбільш зрозумілим описом бізнес-процесів для обговорення його з експертами предметної області та отримання від них конструктивних зауважень є представлена вище нотація в CASE Rational Rose.


На наш погляд, причинами цього є:



  1. Відповідність парадигми діаграми діяльності поданням користувачів про бізнес-процесі на рівні зв'язків з управління, а не по інформації як, наприклад, в BPwin;
  2. Чітке рольовий вираз відповідальностей за ту чи іншу діяльність;
  3. Можливість поєднання в діаграмах опис документів, пов'язаних з діяльністю та їх станів;
  4. Розвинена нотація опису станів бізнес-сутностей (при використанні об'єктів;
  5. Чітко відслідковують горизонтальні зв'язки між підрозділами, що дозволяє структурувати процеси предметної області (абсолютно необхідно для наступних етапів проектування).

Наступним кроком при описі предметної області є розробка моделі структури підприємства, на якій відображені тільки дійові особи і ті їх функції, які слід автоматизувати. Модель відображає ієрархічну структуру підприємства (вертикальні зв'язки).


На основі цієї моделі будується модель функцій системи.


Модель структури підприємства будується на основі опису бізнес-процесів. У моделі відображаються тільки ті відділи, ті дійові особи і їх функції, які будуть автоматизовані. Побудова моделі можна виробляти поетапно, в міру опису бізнес-процесів. Діаграм з бізнес-процесів може бути дуже багато, але модель зі структурою підприємства повинна бути одна.


На рис. 2-7 представлені модель структури підприємства, побудована з використанням діаграми функцій UML (use case diagram).

Рис. 10. Приклад діаграми станів (state diagramm) З описом станів приймального акта


При описі предметної області не слід забувати про моделювання бізнес-правил. Моделі бізнес-правил предметної області будуть основою для моделювання правил програмної системи. Для моделювання бізнес-правил можуть використовуватися діаграми діяльностей (activity diagram) і діаграми класів (class diagram). Діаграми діяльностей (activity diagram) можуть використовуватися для моделювання наприклад, алгоритмічно описуваних правил, діаграми класів (class diagram) – Для моделювання структурних правил.


Отже, підводячи підсумок вище сказаного про опис предметної області при розробці програмних систем, зазначимо таке:


1. Опис предметної області має включати не тільки опис бізнес-процесів, але й опис структури автоматизується підприємства, його дійових осіб, їх автоматизуються функцій, документів, пов'язаних з автоматизованими функціями, інших бізнес-сутностей, сценаріїв реалізації бізнес-функцій і станів бізнес-сутностей;



2. Результати бізнес-моделювання в CASE Rational Rose легко можуть бути перетворені в документацію відповідну промисловим стандартам розробки програмних систем.


3. Повний та детальний опис предметної області вкрай зручно робити в CASE засобі, що підтримує універсальна мова моделювання UML.


На відміну від CASE Rational Rose популярні в нашій країні BPwin, Silverrun, Process Analyst не мають поки повноцінної підтримки всіх перерахованих вище етапів бізнес-моделювання. Що обмежує сферу їх застосування.


Опис предметної області з використанням UML добре сприймається експертам предметної області і не вимагає від них ніякої спеціальної підготовки для розуміння поданих ним на розгляд моделей.


Наприклад, як показав наш досвід, моделі процесів, побудовані в BPwin, викликають труднощі при розумінні їхніми експертами предметної області. Це призводить до того, що експерти стають пасивними слухачами при обговоренні опису бізнес-процесів і їм по суті нав'язується розуміння бізнес-процесів аналітиками. Помилки неправильного опису бізнес-процесів потім виявляються, на жаль, на більш пізніх етапах розробки програмної системи.


На закінчення хотілося б відзначити, що ми не нав'язуємо своєї думки щодо переваг або недоліків того чи іншого CASE-засоби, але на наш погляд, використання CASE Rational Rose та інших CASE-засобів, що підтримують UML для цілей, визначених у статті, є кращим.


PS Автори висловлюють глибоку вдячність слухачам курсу "Об'єктний аналіз та проектування програмних систем з використанням CASE Rational Rose", Регулярно читаного в Навчально-консалтинговому центрі Interface Ltd, за участь у розробці прикладу за описом предметної області для цілей проектування програмної системи в якості експертів предметної області.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*