The second distinguishing aspect of RUP is that it
is architecture-centric. As we saw in the first lesson
of this mini-course, a software architecture is a view
of the entire system that represents all high level
principal design decisions. Another way to see this is
by saying that use cases define the function of
the system, where as architecture defines the form of
the system. Use cases give the functionality, architecture tells
you how the system should be structured to provide the functionality.
So how do we define a software architecture in the rational
unified process. Also in this case this happens through
a sort of a iterative process. We start by creating a rough
outline of the system. And in this case we do it
independently from the functionality. So this is just the general structure
of the system. For example, we model aspects such as the
platform on which the system will run, the overall style. For example,
whether it's a client server or a peer to peer
system and so on. We then use the key use cases
in our use case diagram to define the main subsystems of
my architecture. For example, in the case of a banking IT
system, one of these subsystems might be the withdrawal system. So
what will happen in that case is that we will have
some use case that refers to the withdrawal activity, and by
analyzing that use case, we'll realize that we need a subsystem
that implements that piece of functionality. So again, we use
the key use cases to identify and define the key
subsystems for my architecture. So once we have that we
keep refining the architecture by using additional use cases. So
considering more and more pieces of functionality that will help
us to refine the architecture of the system and also
leveraging our increasing understanding of the system that we're modeling.
And this will continue until we are happy with the
architecture that we define.
