1 / 18

Distributed Java Programming

Distributed Java Programming. Class #1 August 20, 2002. Stands for Unified Modeling Language It is a culmination of 15 years of effort to properly define and model object-oriented systems. It is based on the OO Methodologies of: Grady Booch (Clouds) Ivar Jacobson (Use Cases)

roana
Download Presentation

Distributed Java Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Distributed Java Programming Class #1 August 20, 2002

  2. Stands for Unified Modeling Language It is a culmination of 15 years of effort to properly define and model object-oriented systems. It is based on the OO Methodologies of: Grady Booch (Clouds) Ivar Jacobson (Use Cases) James Rumbaugh (OMT) What is UML?

  3. UML is a modeling language. It lets us takes a problem, visualize it and clearly understand it before we begin writing code. UML consists of a lot of different tools. However we are going to focus on three core tools for use in this class: Use Cases Class Diagrams Interaction Diagrams Lets dive into it Yeah, but What is UML?

  4. Use cases are tool for capturing how a users interacts with an existing system or a new system that is being built. A use case is a discrete and well-defined action that is carried out by a user to reach a specific goal. Use cases usually involve two pieces of documentation: A Use Case Diagram A Use Case Specification Document Use Case and Use Case Analysis

  5. A Use Case Diagram

  6. Use Case Piece: The Actor • Actors are a role a user is playing in the system. • An actor can carry out many tasks within a system. • Actors do not have to be people. They can be other systems. • Often times, particularly large projects listing the actors are a good place to start.

  7. Use Case Piece: The Use Case • Represents a discrete task to be carried out by end user. • Can also represent a more complex task. • Granularity is the key here. You use case diagram clearly communicate the major tasks in the application will carry out.

  8. Generalization and Actors Generalization and Use Cases The Use of Include More About Use Cases

  9. Generalization and Actors

  10. Generalization allows us to capture roles that share responsibilities. Using generalization when modeling the actors in your system allows you to easily define security roles for each user. Do not try to jam too many actor generalizations on one screen. It makes things difficult to read and understand. Generalization and Actors

  11. Generalization and Use Cases

  12. Sometimes one process will build on the functionality of another process. The generalization in a use case is very similar to an inheritance hierarchy in a class diagram. In our example previously, the generalization shown between “Deposit Check” and “Deposit Payment” are very similar. “Deposit Check” puts the money into your bank account. “Deposit Payment” puts the money against a liability owed to the bank. Generalization and Use Cases

  13. The Include Statement

  14. The include statement allows you to indicate that the functionality provided in one use case is used in another use case. It is a time saving measure. Particularly when you have to translate your use case diagrams into use case specifications. The Include Statement

  15. More rigorous definition of a specific use case. Defines the pre and post conditions for a use case. Defines any exceptions that can occur and how they must be handled. Defines each of the individual steps involved within the user case. See the hand out for an example use case specification. Use Case Specification

  16. Use case diagrams are useful tools for communicating with business users about the development team’s understanding of a set of processes. Keep your use case diagrams simple. Use cases decompose complex processes in easy to understand pieces. Use case specification documents are what the development team will be working off of when they begin coding. The definitions for a use case specification must be rigorous. If your use cases are designed properly, they should represent one discrete piece of functionality on a project plan. Closing Thoughts……

  17. Take an existing business process at your work (Or make one up) Build a use case diagram demonstrating how 1 or more roles perform various use cases. Proper notation is required and the process you pick must have 3 – 4 use cases in it. Take one use case and write a full user specification. Based upon your use case, build a class diagram. Show all classes derived from the use case Show their properties, methods and access levels. Show multiplicity and any inheritance relationships that may exist between. Assignment 1

  18. Resources Martin Fowler UML Distilled Second Edition Safari-informit.com Poseidon UML www.gentleware.com UML Resource Centerwww.rational.com/uml

More Related