Lecture 3

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.