Home Forums Official Forum- Navsingh Creating the POST Design Class Diagrams

This topic contains 4 replies, has 1 voice, and was last updated by  Yuvi 2 years, 11 months ago.

  • Author
  • #1830


    Creating the POST Design Class Diagrams
    1. Identifying Software Classes
     The first step in the creation of design class diagrams is to
    identify those classes that participate in the software
     These can be done by scanning all the interaction diagrams
    and listing the classes mentioned

    Note that many of the concepts in the conceptual model,
    such as Cashier, Manager and Item, are not present in the
     There is no need – for the current development cycle – to
    represent them in software.

    2. Add method names

     The methods of each class can be identified by analyzing
    the collaboration diagrams.
     For example, if the message makeLineItem is sent to an
    instance of class Sale, then class Sale must define a
    makeLineItem method:

  • #1831


    3. Adding more type information
     The type of the attributes, method parameters, and
    method return values may all optionally be shown.
     The question as to whether to show this information
    or not should be considered in the following context:
     If it is being created in a CASE tool with automatic code
    generation, full and exhaustive details are necessary.
     If it is being created for software developers to read,
    exhaustive detail may adversely effect the noise-to-value

  • #1832


    4. Adding Associations and Navigability
     In a design class diagram, associations are chosen by
    a Spartan software-oriented, need-to-know criterion
    i.e. what associations are required to satisfy visibility
    needs indicated by the interaction diagrams.
     This is in contrast with associations in the conceptual
    model, which may be justified by the intention to
    enhance comprehension of the problem domain.
     Here are common situations suggesting a need to
    define an association:
     A sends a message to B.
     A creates an instance B.
     A needs to maintain a connection to B.

  • #1833


    5. Adding Dependency Relationships:
     The UML includes a general dependency relationship
    which indicates that one element has knowledge of
    another element.
     It is illustrated with a dashed arrowed line.
     In class diagrams the dependency relationship is
    useful to depict non-attribute visibility between
     In other words, parameter, global, or locally declared
     For example, the POST software object receives a
    return object of type ProductSpecification from the
    specification message it sent to a ProductCatalog

  • #1834


    Creating Design Class Diagram

    Apply the following complete strategy to create a
    Design Class Diagram:
    1. Identify all the classes participating in the software
     Do this by analyzing the interaction diagrams.
    2. Draw them in a class diagram
    3. Duplicate the attributes from the associated concepts
    in the conceptual model.
    4. Add method names by analyzing the interaction
    5. Add type information to the attributes and methods.
    6. Add the associations necessary to support the required
    attribute visibility.
    7. Add navigability arrows to the associations to indicate
    the direction of attribute visibility
    8. Add dependency relationship lines to indicate nonattribute

The forum ‘Official Forum- Navsingh’ is closed to new topics and replies.