This document discusses object oriented programming using Java and provides an overview of Unified Modeling Language (UML). It describes UML diagrams including use case diagrams, class diagrams, interaction diagrams, activity diagrams and state chart diagrams. It focuses on use case diagrams, explaining the different elements like actors, use cases, relationships between use cases, system boundary and packages. It provides examples of a use case diagram for a hospital management system.

1. CST 205 Object Oriented Programming using Java
CST 281 Object Oriented Programming
(As per KTU 2019 Syllabus)
Module 1, Lecture 3

2. Module 1
► Approaches to Software Design. Functional Oriented Design, Object
Oriented Design, Case Study of Automated Fire Alarm System
► Object Modeling Using Unified Modeling Language. Basic Object Oriented
concepts, UML diagrams, Use case model, Class diagram, Interaction diagram,
Activity diagram, State chart diagram
► Introduction to Java Java programming. Environment and Runtime
Environment, Development Platforms - Standard, Enterprise. Java Virtual
Machine, Java compiler, Bytecode, Java applet Java Buzzwords, Java program
structure, Comments, Garbage Collection, Lexical Issues

3. Unified Modeling Language (UML)
● UML (Unified Modeling Language) is a general-purpose, graphical modeling
language in the field of Software Engineering
● Developed to help system and software developers for specifying, visualizing,
constructing, and documenting the artifacts of software systems
● UML was created by the Object Management Group (OMG)
● UML is not a programming language, it is rather a visual language.
● UML is a visual language for developing software blueprints (designs).
● For example, while constructing buildings, a designer or architect develops the
building blueprints. Similarly, we can also develop blueprints for a software
system.

4. Unified Modeling Language (UML)
● UML is the most commonly and frequently used language for building software
system blueprints
● UML can be used for business modeling and other non software systems
● In UML there are a lot of different diagrams to get used to.
● The reason for this is that it is possible to look at a system from many different
viewpoints of the stakeholders.
● A software development will have many stakeholders playing a part
○ Analysts
○ Designers
○ Coders
○ Testers
○ Quality Assurance
○ The Customer
○ Technical Authors

5. UML Diagrams
● UML is linked with object
oriented design and
analysis
● Structure Diagrams :
Capture static aspects or
structure of a system
● Behavior Diagrams:
Capture dynamic aspects
or behavior of the system

7. Use Case Diagram
● A UML use case diagram is the primary form of system/software requirements.
● It is a behavior diagram to illustrate a set of actions or use cases that a system
can perform in tandem with one or more external users of the system (actors)
● The purpose of a use case diagram in UML is to demonstrate the different ways
that a user might interact with a system.
● It is an effective technique for communicating system behavior in the user's terms
by specifying all externally visible system behavior.
● It does not show the order in which steps are performed to achieve the goals of
each use case.
● Use case diagrams are typically developed in the early stage of development
○ Developed by analysts together with domain experts to gather the requirements of a system.
○ Identify the external and internal factors influencing the system.
○ Show the interaction among the requirements and actors
○ Can be used to validate a systems architecture
○ Drive implementation and generate test cases

8. Is it really needed?

9. Use Case Diagram - Actor
● Represent “stick man” icon.
● One actor can be associated with multiple
use cases in the system
● Actor is someone who interacts with use
case (system function).
● Actor is an outsider to the system
boundary who plays a role in the operating
the system/business.
● Actor triggers use case(s). Actor is not an
insider to the system.
● Actor has a responsibility toward the
system (inputs), and Actor has
expectations from the system (outputs).

10. Use Case Diagram - Use case
● Horizontally shaped ovals that represent the different uses that a user might have
● A use case represents a distinct functionality of a system, a component, a
package, or a class
● Represents a system function (automated or manual)
● Each Actor must be linked to a use case, while some use cases may not be linked
to actors.

11. Structuring use case diagrams with relationship
There can be 5 relationship types in a use
case diagram.
1. Association between actor and use
case
2. Generalization of a use case
3. Generalization of an actor
4. Extend between two use cases
5. Include between two use cases

12. Use Case Diagram - Association
● A line between actors and use cases
● The participation of an actor in a use case is shown by connecting an actor
to a use case by a solid link.
● An actor must be associated with at least one use case
● Actors may be connected to use cases by associations, indicating that the
actor and the use case communicate with one another using messages.
● UML allows the use of multiplicity (cardinality) at one or both ends of
association between the actor and the use case

13. Generalization of an Actor
● Generalization of an actor means that one actor can inherit the role of the other
actor.
● The descendant inherits all the use cases of the ancestor.
● The descendant has one or more use cases that are specific to that role.
● In the example, how many use cases are there for NFRC customer?

14. Use case Generalization
● A use-case-generalization is a directed relationship from a
child use case to a parent use case, specifying how a child
can specialize all behavior and characteristics described for
the parent
● A parent use case may be specialized into one or more child
use cases that represent more specific forms of the parent.
● Neither parent nor child is necessarily abstract, although the
parent in most cases is abstract.
● A child inherits all structure, behavior, and relationships of
the parent.

15. Extend relationship between two use cases
● Extend is a directed relationship that specifies how and when the behavior defined in
extending (optional) use case can be inserted into the the extended use case.
● The extending use case is dependent on the extended (base) use case.
● The extended (base) use case must be meaningful on its own.
● The optional extending use case is triggered conditionally at an extension point.
● An extension point is a feature of an extended use case, by which it decides to extend its
functionality by inserting the extending use case.
● Extension points may be shown in a compartment of the use case oval symbol under the
heading extension points. Each extension point must have a name.

16. Include relationship between two use cases
● Use case include is a directed relationship between two use
cases which is used to show that behavior of the included
use case is inserted into the behavior of the including use
case
● Include relationship show that the behaviour of the included
use case is part of the including (base) use case.
● The main reason for this is to reuse the common actions
across multiple use cases and to simplify complex use
cases.
● The base use case is incomplete without the included
use case.
● The included use case is mandatory and not optional.

17. Use Case Diagram - System boundary
● An optional box that sets a system scope to use cases.
● All use cases outside the box would be considered outside the scope of that
system. If no box is given, all use cases are within the system scope.
● The system boundary is potentially the entire system as defined in the
requirements document.
● For large and complex systems, each module may be the system boundary.

18. Use case diagram - Packages
● Packages are optional UML constructs that enable you to organize model
elements (such as use cases) into groups.
● Packages are depicted as file folders and can be used on any of the UML
diagrams, including both use case diagrams and class diagrams

19. Business Use Case modeling notations
● Support for business modeling is declared as a goal of UML, but UML specification does
not provide any notations for business use cases.
● Business use cases were introduced in Rational Unified Process (RUP).
● Business use case should produce a result of observable value to a business actor.
● Defines what happens in the business when the use case is requested by business
actor, it describes complete workflow or business process.
● Business use case is represented in RUP with use case oval and a line crossing it.
● Business Actor is represented in RUP by "stick man" icon with a line crossing its
head.
● Not defined in UML specification.

20. Use case diagram of a Hospital Management System

21. END OF LECTURE 3

22. References
● Rajib Mall, Fundamentals of Software Engineering, 4th edition, PHI, 2014.
● UML Diagrams - www.uml-diagrams.org
● GeeksforGeeks - www.geeksforgeeks.org
● Wikipedia - www.wikipedia.org
● Tutorialspoint - www.tutorialspoint.com
● Disclaimer - This document contains images/texts from various internet
sources. Copyright belongs to the respective content creators. Document is
compiled exclusively for study purpose and shall not be used for commercial
purpose.