Level: Intermediate
Fredrik
Ferm, ECAT Strategy Team Leader, IBM
15 Nov 2006
from The Rational Edge: Architectural frameworks such
as RUP SE and the Zachman Framework help us understand large
systems and how to view dependencies. But when an actual system
model is being examined by a team of analysts, misunderstandings
can still arise over what the various views within a model are
attempting to convey. The author proposes an improved approach to
describing the parts of a complex system model.
In many projects I have been
involved in, discussions with my colleagues about system models and
how to divide them into parts have been generally confused and not
very fruitful. I believe that one of the problems is that we lack a
common way of organizing and navigating models as well as thinking
about their structure. Therefore, I will in this article offer my
view of the problem and provide four dimensions that have been
useful for me when navigating through models of systems and
software.
A system model typically covers many aspects of the system. To
convey the information about all of these aspects, we need to
organize our model in some way, which means that the model must be
divided into parts according to some standardized rules. There are
many standard sets of such rules available that typically go by the
name "architectural frameworks." An architectural framework provides
information on what parts a system model should be made up of, and
thus what interesting aspects of the system the model must describe.
An architectural framework may provide many other things as well,
but for the purpose of this article, we will focus on the model
division aspects.
The IEEE1471 standard
There is actually a standard for architectural descriptions of
software systems: IEEE1471-2000. The standard defines a number of
terms, such as system, architecture, architectural description,
model, view, viewpoint, etc. It also specifies the relationships
between these terms in what is called the "Conceptual model of
architectural description," shown in Figure 1.1
Figure 1: IEEE1471 conceptual model
Now, let's consider some of the terms referenced in Figure 1. I
will discuss each of them below.
Model
As I noted earlier, models are abstractions of the system to be
built. They may be created using a number of techniques, including
the Unified Modeling Language (UML).
The description of a system and its architecture may be created
in one or more models. There are many ways to break up the
description into separate models, but, at least conceptually, we can
usually treat all of the model information as one single model.
View
Views represent individual pieces of the description or the
individual pictures that you would find in a model. A specific piece
of the information in a model may be viewed in zero, one, or more
views. If we use UML for our models, most views would come in the
form of UML diagrams of some type.
Viewpoint
If the model is the source of information and the views contain
representations of that information, the viewpoints define how the
view representations should be made. The viewpoint can be viewed as
a collection of rules regarding what type of information to present
and how to present it in each view. One might think of this as the
model being what we look at, the view being what we see, and the
viewpoint being the glasses that we look through.
As you see in Figure 1, the IEEE1471 standard states that each
viewpoint should address the concerns of one or more stakeholders.
This means that the mapping between the viewpoints and stakeholders
should be known.
Examples of architecture
frameworks
As noted above, there are many architecture frameworks available.
I will describe aspects of some of them here and in the next section
talk about how I see the division of models into parts.
RUP
The IBM Rational Unified Process®, or RUP®, contains an
architecture framework that is called "The 4+1 views of software
architecture."2
This framework describes five necessary views (or rather viewpoints
in the IEEE1471 sense) for software architecture. These views
(viewpoints) are illustrated in Figure 2.
Figure 2: The 4+1 views of software architecture
In the 4+1 view architectural framework, the views include:3
- Use-case view
Deals with WHAT the system should do.
This is expressed in terms of actors and use cases by following
standard use-case modeling techniques.
- Logical view
Deals with the logical structures of
the system -- i.e., how the system is broken down into logical
subsystems, their relationships, and their interactions.
- Process view
Deals with the threads of control that
the system runs. This is expressed in terms of processes and
threads.
- Implementation view
Explains how the system is
implemented in terms of file structures.
- Deployment view
Deals with how the system is run on
machines and the network connections between those
machines.
The 4+1 views of software architecture work well for
software-centric systems. If the system is more complex -- e.g., a
distributed system made up of hardware, software, and perhaps also
people -- then a more complex architectural framework is needed,
which brings us to the next architectural framework.
RUP SE
IBM Rational Unified Process for Systems Engineering (RUP SE) is
an extension of RUP that covers software engineering in order to
deal with the more complex problem of systems engineering. Many of
the concepts of RUP still apply, but some things are changed. For
example, in RUP SE, the architectural framework from RUP (4+1 views)
is replaced by another architectural framework called the "RUP SE
Model framework,"4
illustrated in Table 1.
Table 1: RUP SE Model framework
Model Levels |
Model Viewpoints |
Worker |
Logical |
Information |
Physical |
Process |
Geometric |
Context |
Role definition. Activity modeling. |
UML Context diagram. UML Use-case diagram
specification. |
UML enterprise data view containing extended
product data |
Domain-dependent views (e.g., S-space for
electromecanical) |
| Domain-dependent (such as highway modeling for
vehicles) |
Analysis |
UML partitioning of system in to human,
machine. Activity modeling and simulation. |
UML logical decomposition |
Product data conceptual schema (UML in
RoseRT/ReqPro) |
UML locality view |
UML process view (static diagrams) |
Parameterized geometric model. Layouts |
Design |
Operator instructions. Help
files. Workflow and transaction management. |
Software component design |
Product data schema |
ECM design |
Detailed process view. Timing diagrams. |
MCAD design |
Implementation |
Hardware, software
configuration |
The RUP SE Model framework specifies a set of views, as shown in
the cells of Table 1. For example, we see the views "Role
definition" and "UML locality view." Each of these views shows a
specific aspect of the system.
The views are organized into two dimensions. In the horizontal
dimension of Table 1, we see the model viewpoints, and in the
vertical dimension, we see the model levels (i.e., each view belongs
to a specific model level and a specific model viewpoint).
The first dimension, model viewpoints, corresponds to the
viewpoint concept of IEEE1471 as described above. In the RUP SE
Model framework, the model viewpoints represent different areas of
concern for the system model, typically the concerns of different
stakeholder groups.
The model viewpoints of the RUP SE Model framework fill much of
the same roles as the views do in the 4+1 views architectural
framework from RUP. They are not exactly the same set of model
viewpoints, but they each deal with a specific area of concern for
the system. Why have a different set of viewpoints in the RUP SE
Model framework? Because in systems engineering, you have to deal
with, for example, the people inside the system, which is not
necessary for software development covered by RUP. Therefore, the
RUP SE Model framework contains a worker viewpoint, something not
covered in the 4+1 views.
The second dimension of the RUP SE Model framework is the model
levels, which deals with levels of specification. This means that in
the higher model levels, the system is not highly specified, and the
information covers abstract issues of the system. The farther down
you go, the more detail is added, and therefore, you get a higher
level of specification. Furthermore, as you move down the model
levels, you realize the upper level through new model elements from
the lower level. This means that the usual workflow in the design of
a system means that you work your way from the top model level and
downwards to a higher level of detail.
Other architectural frameworks
There are many other examples of architectural frameworks besides
the two described above. The Department of Defense Architectural
Framework (DoDAF) stipulates a number of views5
that should be present in a system model of systems used by the US
military. In DoDAF, the views are divided into four groups: AV (All
View), OV (Operational View), SV (Systems View), and TV (Technical
Standards View). In these groups, we find examples of views such as
AV-1 (Overview and Summary Information), OV-5 (Operational Activity
Model), SV-1 (System Interface Description), and TV-2 (Technical
Standards Forecast).6
Another example is the Zachman Framework.7
The Zachman Framework takes a two-dimensional approach, dividing a
model into stakeholders (rows) and aspects of the architecture
(columns), as illustrated in Table 2.
Table 2: The Zachman Framework
| What (Data) |
How (Function) |
Where (Location) |
Who (People) |
When (Time) |
Why (Motivation) |
Scope {contextual}
Planner |
List of things important to the business |
List of processes that the business performs |
List of locations in which the business
operates |
List of organizations important to the
business |
List of events/cycles important for the
business |
List of business goals/strategies |
Enterprise
Model {conceptual}
Business
Owner |
e.g., Semantic Model |
e.g., Business Process Model |
e.g., Business Logistics System |
e.g., Workflow Model |
e.g., Master Schedule |
e.g., Business Plan |
System
Model {logical}
Designer |
e.g., Logical Data Model |
e.g., Application Architecture |
e.g., Distributed System Architecture |
e.g., Human Interface Architecture |
e.g., Process Structure |
e.g., Business Rule Model |
Technology
Model {physical}
Implementer |
e.g., Physical Data Model |
e.g., System Design |
e.g., Technology Architecture |
e.g.,Presentation Architecture |
e.g., Control Structure |
e.g., Rule Design |
Detailed
Representation {out of
context}
Subcontractor |
e.g., Data Definition |
e.g., Program |
e.g., Network Architecture |
e.g., Security Architecture |
e.g., Timing Definition |
e.g., Rule Definition |
Functioning System |
e.g., Data |
e.g., Function |
e.g., Network |
e.g., Organization |
e.g., Schedule |
e.g., Strategy |
Note that the Zachman Framework is not meant to be an
architectural framework for system models. Instead, it governs
enterprise architecture, which is usually a larger problem than
system modeling. But we can see that this framework has a lot in
common with the other examples shown. The Zachman Framework divides
the model in more than one dimension, and at the intersections of
these dimensions (the cells in the table), we find views that
describe the system we are modeling.
Introducing four system model
dimensions
So far I have discussed known architectural frameworks that are
described in the literature on system modeling. But, as noted in the
introduction, I have found that despite having these architectural
frameworks to rely on, people have a hard time navigating through a
system model. This leads to confusion and bad communication, which
in turn may lead to lower quality systems and delays of development
projects.
If used in system modeling, the 4+1 view model is
one-dimensional. It divides the system model into parts according to
one rule. The RUP SE Model framework introduces another dimension
that gives us more precision in our system model navigation, but I
think this is still not enough. I have come to the conclusion that
we should add two more dimensions so that we actually have four
interesting dimensions to work with in navigating a system model.
First dimension -- Viewpoint
My first dimension is the viewpoint dimension, which corresponds
to how the RUP SE Model framework looks at things. I feel that the
viewpoint dimension is important because it gives us a good
separation of concerns in our models. Furthermore, we may divide the
work in the separate viewpoints so that each viewpoint is handled by
a specific engineering discipline at the lower model levels. The
logical viewpoint may, for example, be handled by software
engineering, whereas the physical viewpoint may be handled by
hardware engineering.
The RUP SE model framework gives us a good starting point for
understanding which viewpoints to use in system engineering. These
are the viewpoints shown earlier in Table 1, described below in
Table 3.
Table 3: RUP SE Model viewpoints serve as the first
dimension in system modeling.
Viewpoint |
Expresses |
Concern |
Worker8 |
Roles and responsibilities of system workers
|
- Worker activities
- Human/system interaction
- Human performance specification
|
Logical |
Logical decomposition of the system as a
coherent set of UML subsystems that collaborate to provide the
desired behaviour |
- System functionality is adequate to realize use cases.
- System is extendible and maintainable.
- Internal reuse
- Good cohesion and connectivity
|
Physical |
Physical decomposition of the system and the
specification of the physical components |
- System physical characteristics are adequate to host
functionality and meet supplementary
requirements.
|
Information |
Information stored and processed by the
system |
- System has sufficient capacity to store data.
- System has sufficient throughput to provide timely
access to the data.
|
Geometric |
Spatial relationship between physical
components |
- Manufacturability
- Accessibility
- ...
|
Process |
Threads of control, which carry out the
computation elements |
- System has sufficient partitioning of processing to
support concurrency and reliability
needs.
|
Of course, we do not need to use all of these viewpoints for all
system models; instead we should only use the ones that make sense.
We may also add new viewpoints for specific system models. A
security viewpoint may, for example, be useful for the system models
with specific security requirements.
Second dimension -- Model level
The second dimension I use is the model level dimension from RUP
SE. This is necessary because we need to be able to express
ourselves at varying levels of precision and varying levels of
specification. Early on in a development effort, we do not have all
the details, but we'll need to be able to express what we know. As
development moves on, more details are added, and we thus move down
the model levels.
In modeling somewhat complex systems, it is probably a good idea
to retain model information created at higher levels, even though we
have moved on and filled in more details at the lower levels. This
is because a system description not covered in detail is helpful for
people who need an overview or are learning about the system. If we
provide all of the details at once (the lower levels), they might
have a hard time seeing the big picture. In addition, a single
abstract design (higher level) may be implemented in a number of
different ways, with varying performance and price points.
On the question on which model levels to use, I suggest that we
use the ones from RUP SE, unless there is a specific reason to add
or remove any model levels. The model levels from the RUP SE Model
framework are described in Table 4.
Table 4: RUP SE Model levels serve as the second
dimension in system modeling.
Model Level |
Expresses |
Context |
The system and its actors |
Analysis |
Initial system partitioning in each of the
viewpoints to establish the conceptual approach |
Design |
Realization of the analysis level to hardware,
software, and people |
Implementation |
Realization of the design model into specific
configurations |
Third dimension -- System level
The third dimension deals with system hierarchies and the current
view's position in that hierarchy. I will explain this by first
describing system hierarchies, then showing why we must treat these
hierarchy levels as a dimension. The concept is comparable to the
notion of "level of abstraction," a phrase used frequently, but
which I think is confusing to many people; I'll explain more about
this later.
System
hierarchies
If we use a bit of system theory reasoning, we can say that every
system has a border that separates its inside from its outside. The
inside of the system contains a number of "parts" that collaborate
to fulfill the purpose of the system -- i.e., that produce the
services the system delivers to its surroundings. In a
system-of-systems approach, we would view the "parts" inside the
system in focus as also being systems themselves, which means that
the larger system in focus is made up of a number of subsystems.
Similarly, these subsystems are made up of sub-subsystems, and we
can follow this hierarchical structure as deep into the system as
we'd like. Or, returning again to the larger system under
discussion, we could move higher in this hierarchy, noting that the
system in focus plays a role as a subsystem within its own
surrounding system.
This means that a typical system model will contain a somewhat
complex hierarchy of systems. Each of these systems may be modelled
in the same way (they are all systems), but it is important to
always keep track of which system we are modeling. For this reason,
I have introduced a third dimension: system level, which locates the
system in the overall system hierarchy.
Let's look at an example of a system hierarchy to make things
clearer. Imagine that the system we are modeling is a warship, and
let's use the term "system in focus" to denote the warship. This
system is made up of a number of subsystems -- e.g., a Command and
Control system, a Communications system, a Propulsion system, a
Sensor system, and some Weapons systems. In the hierarchy, these
systems live at a system level one level below the warship. If we go
in the other direction, we may say that our warship is working
inside a larger system, which is a fleet. The fleet contains the
warship as a subsystem and it may also have other subsystems, such
as supply ships. This example is illustrated9
in Figure 3.
Figure 3: A UML Class diagram illustrating a system
hierarchy
In Figure 3, we can clearly see three system levels, the level of
the system in focus, the level of the surrounding system, and the
level of the subsystems. Of course, there may be many more levels in
a real example, but this is enough to get the point across. Also
note that in a real example, a subsystem could support more than one
higher level system.
Why "system level" is a
dimension
Obviously, it is important to know the level of the system in
focus for any view of our system model. When we, for example, look
at our warship and see a view that illustrates how the Command and
Control, Sensors, and Weapons collaborate to combat a target, we do
this at the level of the warship. The reasoning on this level will
then provide requirements to the systems one level down -- i.e., the
Command and Control, Sensors, and Weapons systems. If we move down
one level and change the focus to be, for example, the Sensors
system, we now can see how the Sensors collaborate with the other
systems at this level, which are the Command and Control and the
Weapons.
In the example explained above, the Sensors system appears both
on the Warship level as well as the Sensors level. There is,
however, a difference between how it is presented and why it is part
of that level. At the Warship level, the Sensors are inside the
warship and they show up because they are needed to make the warship
fulfill its task. On the Sensors level, however, the Sensors are
themselves the system in focus; therefore, we are looking at the
outside of the Sensors system. Sometimes this distinction is
referred to as black-box (outside) vs. white-box (inside). In many
cases the black-box is used to understand the requirements of the
system in focus (in this case the Sensors system) but the white-box
is used to understand the implementation of the system in focus (in
that case the warship). Therefore the distinction between the two
ways of looking at the Sensors is important, and therefore it is
important to understand the specific system level for each view we
are looking at.
Relationship to level of
abstraction
Many times, I have heard people use the term "level of
abstraction" to mean the system level as explained above. I feel,
however, that this is an unfortunate term since "level of
abstraction" means many things to different people; for example,
some people use "level of abstraction" to mean not the system level,
but the model level, which, in my analysis, is a different dimension
altogether. I have been part of many discussions where these two
different meanings for the term were at the root of a
misunderstanding. Because of this, I choose not to use the term
"level of abstraction" at all, but instead clarify by using "system
level" and "model level."
Fourth dimension -- Description type
In addition to the three dimensions discussed above, a fourth
dimension deals with the type of description that each view
contains. This involves the selection of model elements that are
included in the view and also the purpose of the view.
City bus example
Let me explain this by an example. Let's consider a city bus as
our system in focus. One way of looking at the bus (and thus one
description type) is to look at the whole bus and to consider what
parts it is made up of.10
This would give us a view such as Figure 4, which shows that the bus
is made up of six subsystems that have dependencies on each other.
Figure 4: City bus contents
Another way of looking at the bus (and thus another description
type) is to consider a specific task that the bus performs. When we
look at one specific task, for example, the transportation of
people, perhaps fewer parts are involved. This could give us a
picture such as Figure 5.
Figure 5: Bus parts involved in transportation of
people
In Figure 5, we see that a subset of the total set of subsystems
is used when this specific task is performed by the bus.
Generalizing the
example
The examples provided in Figures 4 and 5 show the difference
between two description types. The two examples show model entities
(in this case, classes) selected from the same set of model
entities. But the selection is different, since we want to convey
different messages with the example views (in Figure 4, we want to
see the complete list of subsystems for some part of the bus, and in
Figure 5, we want to see the subsystems participating in a specific
task).
These different selection criteria do not correspond to any of
the other three dimensions I've described so far. They are not
related to viewpoints, since both examples (Figures 4 and 5) show
model entities from the logical viewpoint. They are also unrelated
to model level, since both examples live at the same level of
detail. Finally, the selection criteria are not related to system
level, since both examples deal with how the bus may be broken down
into parts.
These differences from the other three dimensions argue for a
fourth dimension in our system model, which deals with the specific
purpose of the view. This purpose can be to show all entities in a
specific part of the system or to show how the system works to
fulfill a specific task.11
I have chosen to call this dimension "description type."
The purposes explained above give us three description types,
noted here in boldface. Showing all entities in a specific part of
the system is covered by what I call contents
diagrams. Explaining how the system fulfills a specific task
is handled by realizations, which are divided into static
realizations and dynamic realizations. All three
description types are explained below.
Contents
Figure 4 is an example of a content diagram. It shows the
contents of the bus in the sense that it shows all parts (in this
case subsystem parts) of the bus.
The important aspect for this description type is that it looks
across one area of the system and, for that area, it shows all parts
and their relationships. The area in question may be the whole
system, one layer of the system, or some similar area. This
description type looks at the internal structure of the chosen area,
but I do not want to call this description type "structure" since
structure diagrams are something else in UML 2.
If we were to look at all content views of the system, we would
see all parts that the system is made of and how they relate to each
other. They would thus define all contents of the system.
Realizations: Static and
dynamic
In addition to the contents views, we also need to show how the
system works to fulfil its purpose. Somewhere in our model, we have
a description of the tasks that the system should do. This may be
expressed in terms of use cases or services. For each of these
tasks, we would create a realization that describes how the system
performs that task. We could also create realizations that describe
how the system solves specific problems.
Whatever the realization is about, it is typically made up of two
parts: static realization and dynamic realization.
A static realization is shown in Figure 5. The static
realization shows the parts of the structure that are involved in
the realization. In most cases, the parts that show up in a static
realization may belong to different areas of the content, which
means that they do not show up in the same content view. The static
realization will thus be one way of tying the areas of the content
together.
The dynamic realization describes how the parts shown in
the static realization collaborate to make things happen. This may
be expressed in terms of a UML sequence diagram, but it can also be
expressed in other ways. The important thing is that it describes
who does what, in what order it is done, and what messages are being
exchanged. Figure 6 shows a dynamic realization from the bus
example.
Figure 6: Dynamic realization Click to enlarge
Putting it
together
So, why do we really need to think about all of these four
dimensions? I have found that they are very helpful for two reasons:
to understand a specific view and to act as a map for the model to
be developed.
Understanding a specific view
When we consider a specific view (which in most cases is one or
more UML diagrams) in terms of these four dimensions, we understand
more about what the view is intended to show. For example, if we say
that the view is static realization from the physical perspective on
the bus system and on the analysis model level, we understand a good
deal about what the view is trying to convey. Describing the view in
this way helps us understand the message that the view provides and
also helps us understand how the view fits into the larger
picture.
Also, if people have conflicting ideas on where the view fits
into the four dimensions, that will inevitably lead to
misunderstandings. I have found this to be quite common while
discussing system models in places where the four dimensions are not
known. Therefore, the understanding of four dimensions themselves
and the understanding where a specific view fits into those four
dimensions help clarify misunderstandings.
Mapping the model
The second reason to understand the four dimensions is that they
can help us make a map of our model. Before and during a development
effort, the map can help us understand what parts of the model we
need to develop. After the development effort, the map may help us
understand what parts the model consists of so that we can more
easily navigate through it.
Such a map of the model may be expressed in terms of what
combinations of values from the four dimensions the model should
consist of. For example, we may say that we will develop the
logical, physical, and worker viewpoints; and that we will develop
structure views as well as realization views on those viewpoints;
and that we will do this on the topmost system level as well as
subsystems, etc.
A note on
practicalities
I don't want to suggest that you have to use all viewpoints, all
model levels, and all description types for every system level. You
should, as always, use only the parts that are relevant to your
project. This could mean that specific viewpoints, model levels,
system levels, or description types are skipped. Or it could mean
that specific combinations (for example, the dynamic realization in
the information viewpoint) are skipped. It could also mean that not
all dimensions are interesting. I have, for example, been in a
project where the model level dimension was not interesting since
the project was about creating an overview about the system and not
sorting out all the details.
Acknowledgements
First, I would like to thank the people who helped me develop the
ideas described in this article. This was done when I was working in
an engagement together with (among others) Håkan Beckman and Lars
Schylberg. Furthermore, I would like to thank Dave Brown and Jim
Densmore who helped me review the article. I also want to thank
Michael Perrow for his great edits and suggestions.
Notes
1 I have simplified the conceptual model of
architectural description somewhat so that concepts not interesting
for this article have been excluded.
2 This was originally described in an article by
Philippe Kruchten, "The 4+1 view model of architecture," IEEE
Software. 12(6), November 1995.
3 This description is somewhat simplified. The purpose
of this article is not to explain the 4+1 views in detail. Instead,
it is to show this as an example of an architectural framework.
4 Please note that this is not meant to be a complete
description of the RUP SE Model framework, but simply an example of
an architectural framework. There are many sources of information on
RUP SE, including a set of three articles by Murray Cantor. The
description of the RUP SE Model framework is in the second article:
Murray Cantor, "Rational Unified Process for Systems Engineering,
Part II: System architecture," The Rational Edge, September
2003.
5 The DoDAF framework uses the word "view," but they
are really viewpoints in the IEEE1471 sense. I will use the word
view to conform with the framework.
6 For a complete description of IBM's approach to
DoDAF, see Chris Widney, "An IBM Rational approach to the Department
of Defense Architecture Framework (DoDAF) Part 1: Operational view,"
The Rational Edge, March 2006, at http://www.ibm.com/developerworks/rational/library/mar06/widney/index.html;
and Chris Widney, "An IBM Rational approach to the Department of
Defense Architecture Framework (DoDAF) Part 2: System views," The
Rational Edge, March 2006, at http://www.ibm.com/developerworks/rational/library/apr06/widney/index.html
7 A new description of the Zachman Framework and its
relationship to RUP and UML can be found elsewhere in this issue of
The Rational Edge. See Vitalie Temnenco, "UML, RUP, and the
Zachman Framework: Better together," at http://www.ibm.com/developerworks/rational/library/nov06/temnenco/index.html
8 Please note the distinction between workers and
actors. Workers are people who work inside the system in
focus. Actors are parties (for example, persons) outside the system
in focus. The reason that the 4+1 view framework does not deal with
workers is that, according to the system definition used in RUP,
people may not be part of the system. In system engineering, they
certainly can be.
9 I have chosen to illustrate the hierarchy through a
UML model, where stereotyped classes represent the systems. The
relationships between a system and its subsystems are shown with the
owned element relationship from UML. This does not mean that this is
the only way to model a system hierarchy. You may model this in many
different ways. I have just chosen this way of modeling to
illustrate my example of systems subsystems and surrounding
systems.
10 This is not necessarily the best way to divide a
bus into parts. I just want to show an example of a total view of
parts.
11 There could possibly be other purposes as well, but
these seem to be enough for most system models.
About the author
 |
|
 |
Fredrik Ferm has worked for the Rational organization (now
IBM Rational software) since 2001. His focus is UML modeling,
requirements management, and systems engineering. He is the
strategist for the Rational team supporting the
telecommunications company Ericsson, IBM Rational's largest
customer. |
Rate this
page
|