Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ptp-dev] PTP Resource Managment design

Resource Manager Design:

This is a preliminary design for the PTP Resource Management system.
This is the design of the first phase product, which is limited in
scope to viewing the state of the resource manager.  This includes the
machines, jobs, queues, and nodes that are under the resource
manager's control.

I have not yet reconciled this design with the current PTP design.  I
will be doing that in coming days.

I will follow this post with a more detailed text listing the
classes, their responsibilities, and their collaborations (CRCs).
I'll have that post out tomorrow.

I've included two UML class diagrams.  The first diagram is the overall
structure of the Resource Management system.  The second diagram is
the beginnings of the UI-views system design.

Please take a look at and comment on this design.

The following are clarifications for the use of these UML diagrams.

I) Class Diagrams

  1) Solid Associations

       i) Navigability implies the existence of an operation
          that returns one or more objects of the navigable type.

      ii) Arrow denotes navigability in one direction

     iii) No arrows denotes navigability in both directions

      iv) If the role name is present then the operation is
          named then the associated set, get, add, and/or remove
          operation is based on that name.

       v) For example, if interface IPQueue has a navigation association
          to interface IPJob with multiplicity *, then there exists an
	  operation (dropping the "I" in IPJob as the operation
          basename),
	  	  public IPJob[] getPJob(),
	  and there are likely to be the methods,
		  public void addPJob(IPJob job)
		  public void removePJob(IPJob job)
	  defined in interface IPQueue.

      vi) If the association is navigable from a class it implies that
          the definition exists in the class

  2) Class Attributes

        i) All attributes are represented by private members,
           even if noted as public (+)

       ii) Public attributes denote the existence of a get and
           possibly a set operation in the class.  This also
           implies that the associated definitions of the operation
           bodies exist in the class

  3) Operations

        i) Any non-abstract operations that are explicitly displayed in
	   derived classes are meant as definitions or overrides

Regards,
Randy
-- 
Randy M. Roberts
rsqrd@xxxxxxxx
work: (505)665-4285

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."  -- Benjamin Franklin

Attachment: core.pdf
Description: Adobe PDF document

Attachment: uiviews.pdf
Description: Adobe PDF document


Back to the top