Having found a component that could possibly be used in an application should

Having found a component that could possibly be used

  • geektron
  • 27
  • 100% (1) 1 out of 1 people found this document helpful

This preview shows page 9 - 11 out of 27 pages.

Having found a component that could possibly be used in an application, should it be used? The following factors are typical in making this decision. Considering a Component for Reuse Is the component documented thoroughly? If not, can it be? How much customization of the application is required? Has the component been tested thoroughly? If not, can it be? To decide on reuse, a table comparing the costs can be developed, similar to the make-vs.-buy example that was shown in the topic “Project Tools and Support” of Module 2, Lecture 4 ( please review this topic (../module02/metcs682_W2L2T03_projectTools.htm) ). Sequence and Data Flow Diagrams for Detailed Design Some detailed designs are best communicated via detailed sequence diagrams or detailed data flow diagrams. We used sequence diagrams and data flow diagrams in specifying requirements - especially as an aid to selecting business objects - but it was not necessary to select actual function names at that stage. When we come to detailed design, however, function (method) names must be identified. The two outlines below provide guidance on what needs to be done with sequence diagrams and data flow
Image of page 9
diagrams to carry out detailed design. The sections following this one provide details and examples. Refining Models for Detailed Design: Sequence Diagrams 1. Begin with the sequence diagrams (system sequence diagrams) constructed for detailed requirements and/or architecture (if any) corresponding to the use cases 2. Introduce additional use cases, if necessary, to describe how parts of the design typically interact with the rest of the application 3. Provide sequence diagrams (detailed sequence diagrams) with complete details 1. Be sure that the exact objects and their classes are specified 2. Select specific function names in place of natural language (calls of one object to another to perform an operation which the first object needs) Refining Models for Detailed Design: Data FlowDiagrams 1. Gather data flow diagrams (DFDs) constructed for detailed requirements and/or architecture (if any) 2. Introduce additional DFDs, if necessary, to explain data and processing flows 3. Indicate what part(s) of the other models the DFDs correspond to. 1. e.g., "the following DFD is for each Account object" 4. Provide all details on the DFDs 1. Indicate clearly the nature of the processing at each node 2. Indicate clearly the kind of data transmitted 3. Expand processing nodes into DFDs if the processing description requires more detail Detailed Sequence Diagrams Recall that use cases can be utilized to express requirements, and that we also use them to determine the key business objects for the application. For the detailed design phase, we provide classes with the methods referenced in the sequence diagrams.
Image of page 10
Image of page 11

You've reached the end of your free preview.

Want to read all 27 pages?

  • Spring '19
  • Detailed Design, Detailed Designs

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture