[UML Forum] Component Diagram

[Peter Wkc]

Hello to all, this component diagram is for my FYP.

I program a VoIP + supply order system,

My component is GUI, VoIP and supply order.

Any other you all can think of ?
I wonder there is no connection between GUI with VoIP and supply order
but there is connection between VoIP and supply order.

Please clarify.

Thanks.

--
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To post to this group, send email to umlf...@googlegroups.com.
To unsubscribe from this group, send email to umlforum+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umlforum?hl=en.

[H. S. Lahman]

Responding to Wkc...

> Hello to all, this component diagram is for my FYP.
>

The purpose of these forums is not to do your classroom assignments for
you. Grinding through it yourself is part of the learning process. So
the best you will get are some broad hints...

> I program a VoIP + supply order system,
>
> My component is GUI, VoIP and supply order.
>
> Any other you all can think of ?
>

This application doesn't access a persistent data store? Are you going
to implement IP communications in the same subject matter with business
logic like checking input correctness? Think about all the things your
application actually has to do and break them down by subject matter.

'Supply order' sounds suspiciously like an object that would implement
the subject matters of the other components.

A great deal depends on the complexity of the requirements. This CD
might be fine for a very simple application but if this is going to be
an enterprise application of a Fortune 500, you might have dozens of
components.

> I wonder there is no connection between GUI with VoIP and supply order
> but there is connection between VoIP and supply order.
>

GUI is not connected to either of the others? How do user requests in
the GUI get converted to orders without communicating with other components?

--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html

[Peter Wkc]

On Apr 28, 10:53 pm, "H. S. Lahman" <h.lah...@verizon.net> wrote:
> Responding to Wkc...
>

> > Hello to all, thiscomponentdiagramis for my FYP.

>
> The purpose of these forums is not to do your classroom assignments for
> you. Grinding through it yourself is part of the learning process. So
> the best you will get are some broad hints...
>
> > I program a VoIP + supply order system,
>

> > Mycomponentis GUI, VoIP and supply order.

>
> > Any other you all can think of ?
>
> This application doesn't access a persistent data store? Are you going
> to implement IP communications in the same subject matter with business
> logic like checking input correctness? Think about all the things your
> application actually has to do and break them down by subject matter.
>
> 'Supply order' sounds suspiciously like an object that would implement
> the subject matters of the other components.
>
> A great deal depends on the complexity of the requirements. This CD
> might be fine for a very simple application but if this is going to be
> an enterprise application of a Fortune 500, you might have dozens of
> components.
>
> > I wonder there is no connection between GUI with VoIP and supply order
> > but there is connection between VoIP and supply order.
>
> GUI is not connected to either of the others? How do user requests in
> the GUI get converted to orders without communicating with other components?

I also not understand here why the GUI get converted to orders ?

I not asking you all to do my assignment but i need verification and
advise from you all.

This is my component diagram.
http://umlforum.googlegroups.com/web/Component.GIF?hl=en&gda=aO4Vyz8AAADq066sJ8TOZKmNDs6x9cOa6FVehLDpPi0R2hicn4WOqeyuz2wHfHq4yKvVy4kRjeCccyFKn-rNKC-d1pM_IdV0&gsc=ctxVLAsAAACpTM7gBBI8KHGvkDyODF8o

Thanks.

[H. S. Lahman]

Responding to Wkc...

I wonder there is no connection between GUI with VoIP and supply order
but there is connection between VoIP and supply order.
      

GUI is not connected to either of the others? How do user requests in
the GUI get converted to orders without communicating with other components?
    

I also not understand here why the GUI get converted to orders ?
  

I was agreeing with you that GUI needs to be connected to somebody.

The GUI is not converted; the data that the user provides to the GUI must eventually be converted into a Supply Order. But to do that the data must be sent to the Supply Order (or whoever creates it) and that requires some kind of logical connection path. [In this case, which is presumably a distributed system, that path would lead through the VoIP service.]

I not asking you all to do my assignment but i need verification and
advise from you all.

This is my component diagram.
http://umlforum.googlegroups.com/web/Component.GIF?hl=en&gda=aO4Vyz8AAADq066sJ8TOZKmNDs6x9cOa6FVehLDpPi0R2hicn4WOqeyuz2wHfHq4yKvVy4kRjeCccyFKn-rNKC-d1pM_IdV0&gsc=ctxVLAsAAACpTM7gBBI8KHGvkDyODF8o

  

I'm afraid I don't understand the diagram. QT is a new player; what does it do? Or are you mixing interfaces, objects and components in the diagram? I am also confused about why a GUI would need VoIP message transfer. Note that if it is a hybrid UI, you probably need two separate subsystems for the UI because voice and GUI input requires vastly different processing, which implies vastly different subject matters. (They would need synchronization, so there would be a connection between them as well as to VoIP.)

Typically one uses the Component Diagram for one of two purposes. One is to describe the large-scale structure of the system at the subsystem level. One just describes what the subsystems are and how they are related in a client/service flow of requirements. That is, the CD is a directed, acyclic graph with more abstract, problem-specific client subsystems at the top and more detailed, generic (reusable) service subsystems at the bottom. One can also associate specific interfaces (aka bridges) with the components to clarify communication between them. This is typically the top level of top-down design in OOA/D. One then associates Class Diagrams, Interaction Diagrams, Statecharts, and what have you with the individual subsystems to describe what goes on inside the components for low level design.

The other use of the CD is for describing low-level composition of entities in a bottom-up fashion like COM widgets. That is an object-based approach with some roots in functional programming rather than an OO approach so I won't deal with it here.

In OOA/D one defines subsystems based on cohesive problem space subject matters with stable boundaries. So message transmission mechanisms, UI mechanisms, and business logic elements would typically be in different subsystems (aka UML components) because those subject matters are vastly different. Since UI and VoIP are low level, generic services they would be at the bottom of the diagram. Also, one rarely nests subsystems except for very large systems where complex subsystems need to be deployed on a largely standalone basis.

So the Component Diagram itself identifies ScVoIP through its title and the diagram just needs GUI, Supply Order, VoIP, and whatever QT is as components. But those components need to be connected to manage the data flow from user to Supply Order.

As it happens, by convention one often places architectural infrastructure components at the bottom of the CD without cluttering the diagram with connections to clients above them. That's because most of the subsystems will utilize architectural infrastructure. So in a more complex distributed application VoIP and Window Socket might, indeed, be sitting alone at the bottom of the diagram with no connections; it would be implied that all the higher level components utilized those message passing services. But Supply Order is not a lower level architectural infrastructure, so it would be at the top of the diagram. And in a simple situation like this one probably would draw the connections with VoIP.

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html