Use- Case Diagrams :

A use case illustrates a unit of functionality provided by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of “actors” (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases — either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality (e.g., all security administration related use cases). To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval. To draw an actor (indicating a system user) on a use-case diagram, you draw a stick person to the left or right of your diagram (and just in case you’re wondering, some people draw
prettier stick people than others). Use simple lines to depict relationships between actors and use cases

• A use-case diagram is typically used to communicate the high-levelfunctions of the system and the system’s scope
• As per the diagram, the band manager view a sales statistics report and the Billboard 200 report for the band’s CDs
• It also lets the record manager view a sales statistics report and the Billboard 200 report for a particular CD
• The diagram also tells us that our system delivers Billboard reports from an external system called Billboard
  Reporting Service

In addition, the absence of use cases in this diagram shows what the system doesn’t do. For example, it does not provide a way for a band manager to listen to songs from the different albums on the Billboard 200 – – i.e., we see no reference to a use case called Listen to Songs from Billboard 200. This absence is not a trivial matter. With clear and simple use-case descriptions provided on such a diagram, a project sponsor can easily see if needed functionality is present or not present in the system.

Sequence diagram :

Sequence diagrams show a detailed flow for a specific use case or even just part of a specific use case. They are almost self explanatory; they show the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects

A sequence diagram has two dimensions

• The vertical dimension shows the sequence of messages/calls in the time order that they occur
• the horizontal dimension shows the object instances to which the messages are sent

A sequence diagram is very simple to draw. Across the top of your diagram, identify the class instances (objects) by putting each class instance inside a box (Refer the below diagram). In the box, put the class instance name and class name separated by a space/colon/space ” : ” (e.g., myReportGenerator : ReportGenerator). If a class instance sends a
message to another class instance, draw a line with an open arrowhead pointing to the receiving class instance; place the name of the message/method above the line. Optionally, for important messages, you can draw a dotted line with an arrowhead pointing back to the originating class instance; label the return value above the dotted line. Personally, I always like to include the return value lines because I find the extra details make it easier to read.

Reading a sequence diagram is very simple. Start at the top left corner with the “driver” class instance that starts the sequence. Then follow each message down the diagram. Remember: Even though the example sequence diagram in above shows a return message for each sent message, this is optional.

By reading our sample sequence diagram in above, can see how to create a CD Sales Report. The aServlet object is our example driver. AServlet sends a message to the ReportGenerator class instance named gen. The message is labeled generateCDSalesReport, which means that the ReportGenerator object implements this message handler. On closer inspection, the generateCDSalesReport message label has cdId in parentheses, which means that aServlet is passing a variable named cdId with the message. When gen instance receives a generateCDSalesReport
message, it then makes subsequent calls to the CDSalesReport class, and an actual instance of a CDSalesReport called aCDReport gets returned. The gen instance then makes calls to the returned aCDReport instance, passing it parameters on each message call. At the end of the sequence, the gen instance returns aCDReport to its caller aServlet.