.NET Limitations when implementing UML

[Martyn Lawson]

Hi,

I am currently working as an Analyst on a .NET Web Project using ASP.NET and
C#.NET.

I have a couple of, at least what should be, quick questions:

1. My understanding of UML says that the Controller classe of a Sequence
Diagram should be implemented as a private class within a component.
However, my Programmer has said that since the ASP code lives outside the
component, the Controller must be implemented as public. Is this correct? If
so, doesn't this force the controller to become an interface for the
component?

2. On a similar point. UML suggests that each component should have at least
one Interface (although more may be used). In my project I have decided to
use a single Interface for a component with 5 entities. However, my
Programmer has said that unless all entities have the same methods (which
they don't) then the same interface cannot be used. Is this correct? If so,
what is the point in combining like entities into a single component?

Any help would be greatly appreciated,
Cheers
Martyn Lawson

[Niki Estner]

"Martyn Lawson" <Ma**********@discussions.microsoft.com> wrote in
news:55**********************************@microsof t.com...

Hi,

I am currently working as an Analyst on a .NET Web Project using ASP.NET
and
C#.NET.

I have a couple of, at least what should be, quick questions:

1. My understanding of UML says that the Controller classe of a Sequence
Diagram should be implemented as a private class within a component.
However, my Programmer has said that since the ASP code lives outside the
component, the Controller must be implemented as public. Is this correct?
If
so, doesn't this force the controller to become an interface for the
component?
Sequence diagrams show what's happening in your app, the temporal order of
events (meaning the english word "event", not the C# keyword...). These
events are usually function calls. (and, of course .net *does* have function
calls) But I've also seen sequence diagrams showing windows messages or HTTP
requests. It depends on what you want to model with the UML diagram.

There is no "right way to implement" these diagrams.
2. On a similar point. UML suggests that each component should have at
least
one Interface (although more may be used). In my project I have decided to
use a single Interface for a component with 5 entities. However, my
Programmer has said that unless all entities have the same methods (which
they don't) then the same interface cannot be used. Is this correct? If
so,
what is the point in combining like entities into a single component?

Your programmer is correct. That's the whole point of an interface. (You
shouldn't use them if you don't know what they're good for only because some
UML book told you every component "should have one")

Niki

[Martyn Lawson]

Thanks Niki,

The second point confirms what my Programmer has been telling me but does go
against everything I've read about OOAD and UML. But if that's how .NET
implements them then i'll re-work all my sequence diagrams - great!!!

However, I do not really understand what you meant regarding the first
point. I understand that Sequence Diagrams can be used to model a variety of
things and perhaps confused things by mentioning ASP.

The question is really that Controller classes in UML are private and can
therefore only be seen by classes in the same component. Since the boundary
class (in our situation the ASP page) is not in the component (VS.NET
project) it cannot see the Controller. Is the only available option to make
the Controller a public class?

Any further help would be appreciated.
Cheers,
Martyn...

"Niki Estner" wrote:

"Martyn Lawson" <Ma**********@discussions.microsoft.com> wrote in
news:55**********************************@microsof t.com...

Hi,

I am currently working as an Analyst on a .NET Web Project using ASP.NET
and
C#.NET.

I have a couple of, at least what should be, quick questions:

1. My understanding of UML says that the Controller classe of a Sequence
Diagram should be implemented as a private class within a component.
However, my Programmer has said that since the ASP code lives outside the
component, the Controller must be implemented as public. Is this correct?
If
so, doesn't this force the controller to become an interface for the
component?

Sequence diagrams show what's happening in your app, the temporal order of
events (meaning the english word "event", not the C# keyword...). These
events are usually function calls. (and, of course .net *does* have function
calls) But I've also seen sequence diagrams showing windows messages or HTTP
requests. It depends on what you want to model with the UML diagram.

There is no "right way to implement" these diagrams.

2. On a similar point. UML suggests that each component should have at
least
one Interface (although more may be used). In my project I have decided to
use a single Interface for a component with 5 entities. However, my
Programmer has said that unless all entities have the same methods (which
they don't) then the same interface cannot be used. Is this correct? If
so,
what is the point in combining like entities into a single component?

Your programmer is correct. That's the whole point of an interface. (You
shouldn't use them if you don't know what they're good for only because some
UML book told you every component "should have one")

Niki

[Niki Estner]

"Martyn Lawson" <Ma**********@discussions.microsoft.com> wrote in
news:BA**********************************@microsof t.com...

Thanks Niki,

The second point confirms what my Programmer has been telling me but does
go
against everything I've read about OOAD and UML. But if that's how .NET
implements them then i'll re-work all my sequence diagrams - great!!!
I'm sorry, but then you probably misunderstood everything you've read...
(Java interfaces have the same semantics, so do UML interfaces)
However, I do not really understand what you meant regarding the first
point. I understand that Sequence Diagrams can be used to model a variety
of
things and perhaps confused things by mentioning ASP.
The point is that there's absolutely no need to implement a sequence diagram
with some kind of controller class.
Maybe you confused that with a design pattern?
The question is really that Controller classes in UML are private and can
therefore only be seen by classes in the same component. Since the
boundary
class (in our situation the ASP page) is not in the component (VS.NET
project) it cannot see the Controller. Is the only available option to
make
the Controller a public class?
Not sure if I got that question: The idea of a private class is that it's
not visible outside the enclosing assembly. If you want it to be visible,
make it public. ("private" in UML has very similar semantics)

Niki
Any further help would be appreciated.
Cheers,
Martyn...

"Niki Estner" wrote:

"Martyn Lawson" <Ma**********@discussions.microsoft.com> wrote in
news:55**********************************@microsof t.com...

> Hi,
>
> I am currently working as an Analyst on a .NET Web Project using
> ASP.NET
> and
> C#.NET.
>
> I have a couple of, at least what should be, quick questions:
>
> 1. My understanding of UML says that the Controller classe of a
> Sequence
> Diagram should be implemented as a private class within a component.
> However, my Programmer has said that since the ASP code lives outside
> the
> component, the Controller must be implemented as public. Is this
> correct?
> If
> so, doesn't this force the controller to become an interface for the
> component?

Sequence diagrams show what's happening in your app, the temporal order
of
events (meaning the english word "event", not the C# keyword...). These
events are usually function calls. (and, of course .net *does* have
function
calls) But I've also seen sequence diagrams showing windows messages or
HTTP
requests. It depends on what you want to model with the UML diagram.

There is no "right way to implement" these diagrams.

> 2. On a similar point. UML suggests that each component should have at
> least
> one Interface (although more may be used). In my project I have decided
> to
> use a single Interface for a component with 5 entities. However, my
> Programmer has said that unless all entities have the same methods
> (which
> they don't) then the same interface cannot be used. Is this correct? If
> so,
> what is the point in combining like entities into a single component?

Your programmer is correct. That's the whole point of an interface. (You
shouldn't use them if you don't know what they're good for only because
some
UML book told you every component "should have one")

Niki

[Niki Estner]

"Martyn Lawson" <Ma**********@discussions.microsoft.com> wrote in
news:BA**********************************@microsof t.com...

Thanks Niki,

The second point confirms what my Programmer has been telling me but does
go
against everything I've read about OOAD and UML. But if that's how .NET
implements them then i'll re-work all my sequence diagrams - great!!!

Hi Martyn,

I just re-read that part, and maybe I misunderstood your first post. To
clarify this: a class implementing an interface has to implement all the
methods that are defined in the interface. Thus, two classes implementing
the same interface both have to implement these methods (unless they are
abstract classes). Of course, all the other methods in these classes aren't
touched by this.

Niki

[UAError]

"Martyn Lawson" <Ma**********@discussions.microsoft.com>
wrote:

Thanks Niki,

The second point confirms what my Programmer has been telling me but does go
against everything I've read about OOAD and UML. But if that's how .NET
implements them then i'll re-work all my sequence diagrams - great!!!

> Programmer has said that unless all entities have the same methods (which
> they don't) then the same interface cannot be used. Is this correct? If
> so,
> what is the point in combining like entities into a single component?

The statement "unless all entities have the same methods
(which they don't) then the same interface cannot be used"
isn't entirely accurate (in UML or .NET). A better way of
putting it is: "classes implementing an interface have to
implement all the interface's methods". The point of an
interface is to get the benefits of polymorphism without the
dangers of multiple inheritance. When a "client object"
communicates through an interface with a "server object" it
(the client object) doesn't care who's doing the job - just
that the job is being done. Generally each class will have
its own set of specific methods which will not be accessible
through the interface - these methods often deal with the
configuration (not to be confused with the constructor's
construction) of the object. The configuration is usually
done by an Abstract Factory Method or Class to decouple the
"client object" from the implementing "server object".
However, I do not really understand what you meant regarding the first
point. I understand that Sequence Diagrams can be used to model a variety of
things and perhaps confused things by mentioning ASP.

Even in UML a private class cannot communicate with the
world outside of the deployment component - unless that
class implements a public interface and a public Abstract
Factory hands out a reference to an instance of the class in
the shape of an interface reference.

In ASP.NET the controller should be accessible to the page
if the page (code behind) and the controller are in the same
assembly and the protection level is specified as "internal"
rather than "private" (this means other assemblies will not
be able to access the controller class).

If you need to communicate across assembly boundaries you
could have the private controller class implement a public
interface (you will still require a public abstract factory)
- that way you can drop in a "new and improved" controller
class later without the pages getting wise to it, or if
required use different controller implementations in
different contexts.

In general you may also be experiencing an "impedance
mismatch" between the analysis, design and implementation
model.

Who is to say the UML is correct? Has it been verified by a
competent design tool? (Many design tools let you do things
that make very little sense).
The question is really that Controller classes in UML are private and can
therefore only be seen by classes in the same component. Since the boundary
class (in our situation the ASP page) is not in the component (VS.NET
project) it cannot see the Controller. Is the only available option to make
the Controller a public class?

Any further help would be appreciated.
Cheers,
Martyn...

"Niki Estner" wrote:

"Martyn Lawson" <Ma**********@discussions.microsoft.com> wrote in
news:55**********************************@microsof t.com...

> Hi,
>
> I am currently working as an Analyst on a .NET Web Project using ASP.NET
> and
> C#.NET.
>
> I have a couple of, at least what should be, quick questions:
>
> 1. My understanding of UML says that the Controller classe of a Sequence
> Diagram should be implemented as a private class within a component.
> However, my Programmer has said that since the ASP code lives outside the
> component, the Controller must be implemented as public. Is this correct?
> If
> so, doesn't this force the controller to become an interface for the
> component?

Sequence diagrams show what's happening in your app, the temporal order of
events (meaning the english word "event", not the C# keyword...). These
events are usually function calls. (and, of course .net *does* have function
calls) But I've also seen sequence diagrams showing windows messages or HTTP
requests. It depends on what you want to model with the UML diagram.

There is no "right way to implement" these diagrams.

> 2. On a similar point. UML suggests that each component should have at
> least
> one Interface (although more may be used). In my project I have decided to
> use a single Interface for a component with 5 entities. However, my
> Programmer has said that unless all entities have the same methods (which
> they don't) then the same interface cannot be used. Is this correct? If
> so,
> what is the point in combining like entities into a single component?

Your programmer is correct. That's the whole point of an interface. (You
shouldn't use them if you don't know what they're good for only because some
UML book told you every component "should have one")

Niki

[Martyn Lawson]

Hi

Thanks to you both for your detailed replies. This has sparked some
discussion within our Development department so i'm sure we'll get to a
satisfactory outcome.

Thanks again,
Martyn

"UAError" wrote:

"Martyn Lawson" <Ma**********@discussions.microsoft.com>
wrote:

Thanks Niki,

The second point confirms what my Programmer has been telling me but does go
against everything I've read about OOAD and UML. But if that's how .NET
implements them then i'll re-work all my sequence diagrams - great!!!

> Programmer has said that unless all entities have the same methods (which
> they don't) then the same interface cannot be used. Is this correct? If
> so,
> what is the point in combining like entities into a single component?

The statement "unless all entities have the same methods
(which they don't) then the same interface cannot be used"
isn't entirely accurate (in UML or .NET). A better way of
putting it is: "classes implementing an interface have to
implement all the interface's methods". The point of an
interface is to get the benefits of polymorphism without the
dangers of multiple inheritance. When a "client object"
communicates through an interface with a "server object" it
(the client object) doesn't care who's doing the job - just
that the job is being done. Generally each class will have
its own set of specific methods which will not be accessible
through the interface - these methods often deal with the
configuration (not to be confused with the constructor's
construction) of the object. The configuration is usually
done by an Abstract Factory Method or Class to decouple the
"client object" from the implementing "server object".

However, I do not really understand what you meant regarding the first
point. I understand that Sequence Diagrams can be used to model a variety of
things and perhaps confused things by mentioning ASP.

Even in UML a private class cannot communicate with the
world outside of the deployment component - unless that
class implements a public interface and a public Abstract
Factory hands out a reference to an instance of the class in
the shape of an interface reference.

In ASP.NET the controller should be accessible to the page
if the page (code behind) and the controller are in the same
assembly and the protection level is specified as "internal"
rather than "private" (this means other assemblies will not
be able to access the controller class).

If you need to communicate across assembly boundaries you
could have the private controller class implement a public
interface (you will still require a public abstract factory)
- that way you can drop in a "new and improved" controller
class later without the pages getting wise to it, or if
required use different controller implementations in
different contexts.

In general you may also be experiencing an "impedance
mismatch" between the analysis, design and implementation
model.

Who is to say the UML is correct? Has it been verified by a
competent design tool? (Many design tools let you do things
that make very little sense).

The question is really that Controller classes in UML are private and can
therefore only be seen by classes in the same component. Since the boundary
class (in our situation the ASP page) is not in the component (VS.NET
project) it cannot see the Controller. Is the only available option to make
the Controller a public class?

Any further help would be appreciated.
Cheers,
Martyn...

"Niki Estner" wrote:

"Martyn Lawson" <Ma**********@discussions.microsoft.com> wrote in
news:55**********************************@microsof t.com...
> Hi,
>
> I am currently working as an Analyst on a .NET Web Project using ASP.NET
> and
> C#.NET.
>
> I have a couple of, at least what should be, quick questions:
>
> 1. My understanding of UML says that the Controller classe of a Sequence
> Diagram should be implemented as a private class within a component.
> However, my Programmer has said that since the ASP code lives outside the
> component, the Controller must be implemented as public. Is this correct?
> If
> so, doesn't this force the controller to become an interface for the
> component?

Sequence diagrams show what's happening in your app, the temporal order of
events (meaning the english word "event", not the C# keyword...). These
events are usually function calls. (and, of course .net *does* have function
calls) But I've also seen sequence diagrams showing windows messages or HTTP
requests. It depends on what you want to model with the UML diagram.

There is no "right way to implement" these diagrams.

> 2. On a similar point. UML suggests that each component should have at
> least
> one Interface (although more may be used). In my project I have decided to
> use a single Interface for a component with 5 entities. However, my
> Programmer has said that unless all entities have the same methods (which
> they don't) then the same interface cannot be used. Is this correct? If
> so,
> what is the point in combining like entities into a single component?

Your programmer is correct. That's the whole point of an interface. (You
shouldn't use them if you don't know what they're good for only because some
UML book told you every component "should have one")

Niki