However, I found in one particular
seminar that an unusual group of people had gathered: engineers, including telecommunication
engineers, but not a single software developer. They planned a
large project that was to include software, but also construction work, hardware,
and other disciplines. As the training course went on I reduced the software aspect
and explained the analysis and design techniques in more general terms. What the
attendants gained from this was an excellent approach for their project.
This particular constellation of attendants has not been an exceptional case
from then on. It was followed by more seminars, workshops, and coaching contracts
that were not attended by software developers, but by engineers from other
disciplines who wanted to familiarize themselves with system analysis and design
using UML for their work. I found myself thinking more and more about issues,
ideas, and further considerations: How much software does UML actually contain?
How can I describe requirements in UML for non-software fi elds? How do I handle
hybrid systems? I gradually became aware of the fact that the UML language and
the approaches it supports can be used in many fi elds independently of software.
Pages:
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45