You have been hired by HP Inc. (aka Happy Company, Inc) as a Java Developer (congratulations by the way!).It is Monday morning, your first day on the job, and your boss calls a very important emergency status meeting. As he goes around the table he notices you as a new hire and assigns you your first major project. Before you begin coding the system in Java, he requests that you design your object oriented system by using UML – a common object modeling tool used for object oriented languages. You recall from your first Java I class at college that Chapter 12 in your Java book discussed how to design an OO system; you review the chapter during your lunch hour and are now eager to get to work designing the system!
Please use standard UML notation for each diagram – you will find those standards in your text. You can use a simple tool such as Visio, PowerPoint or Word to update this document. You can even download an open source UML tool if you wish but it is not required! You can also use handwriting but it must be legible. If you feel that your hand writing is not legible think about using a software tool. Be aware: you may not think you were given all the information to design the system – that will happen when you work with your customer (the person or group that provides you the system requirements). This is very typical. You may make assumptions about the system if you feel it is missing something. This exercise is to acquaint you with UML and its notations. Once you design the system, the developers of the system would have a meeting to discuss this document and then appropriate updates are made. Some parts of this assignment only require you to diagram a ‘portion’ of the system. Please read the instructions for each diagram carefully.
A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals, and any dependencies between those use cases.
Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case.
A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.
An actor is a person, organization, or external system that plays a role in one or more interactions with the system.
A rectangle is drawn around the use cases, called the system boundary box, to indicate the scope of system. Anything within the box represents functionality that is in scope and anything outside the box is not.
An actor is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task.