469,623 Members | 1,497 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,623 developers. It's quick & easy.

.NET Limitations when implementing UML

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
Jul 21 '05 #1
6 2509
"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
Jul 21 '05 #2
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

Jul 21 '05 #3
"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

Jul 21 '05 #4
"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

Jul 21 '05 #5
"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


Jul 21 '05 #6
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


Jul 21 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Hajir Firooz | last post: by
4 posts views Thread by Markus Wankus | last post: by
3 posts views Thread by Jack | last post: by
5 posts views Thread by Roman | last post: by
5 posts views Thread by Martyn Lawson | last post: by
28 posts views Thread by Danny Liberty | last post: by
5 posts views Thread by Jon Davis | last post: by
reply views Thread by TonyJ | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.