CS8592 OOAD UNIT 1 PPT

1. CS8592 OOAD
INTRODUCTION TO OOAD
WITH
OO BASICS
Dr.P.Mayil Vel Kumar
HOD/CSE
Karpagam Institute of Technology

2. CS8592 OOAD
• Object-Oriented Analysis (Overview)
– An investigation of the problem (rather than how a solution is
defined)
– During OO analysis, there is an emphasis on finding and
describing the objects (or concepts) in the problem domain.
– For example, concepts in a Library Information System include
Book, and Library.
– High level views found in the application domain.
– Oftentimes called domain objects; entitie

3. CS8592 OOAD
• Object-Oriented Design
– Emphasizes a conceptual solution that fulfills the
requirements.
– Need to define software objects and how they
collaborate to meet the requirements.
– For example, in the Library Information System, a
Book software object may have a title attribute and a
getChapter method.
• What are the methods needed to process the attributes?

4. 4
From Design to Implementation
Book
title
print()
public class Book {
public void print();
private String title;
}
Book
(concept)
Analysis
investigation
of the problem
Design
logical solution
Construction
code
Domain concept Representation in
analysis of concepts
Representation in an
object-oriented
programming language.
Can you see the services / responsibilities in the Book class?
CS8592 OOAD

5. CS8592 OOAD
Unified Process

6. CS8592 OOAD
Unified Process

7. CS8592 OOAD
Unified Process

8. CS8592 OOAD
Unified Process

9. CS8592 OOAD
Unified Process

10. CS8592 OOAD
UML diagrams
There are two broad categories of diagrams and they are again divided into
subcategories −
Structural Diagrams
Behavioral Diagrams
Structural Diagrams
The structural diagrams represent the static aspect of the system. These static
aspects represent those parts of a diagram, which forms the main structure and
are therefore stable.
These static parts are represented by classes, interfaces, objects, components,
and nodes. The 3 structural diagrams are −
•Class diagram
•Component diagram
•Deployment diagram

11. CS8592 OOAD
UML diagrams
Class Diagram
Class diagrams are the most common diagrams used in UML. Class diagram consists of
classes, interfaces, associations, and collaboration.
Class diagrams basically represent the object-oriented view of a system, which is static
in nature Active class is used in a class diagram to represent the concurrency of the
system.
Class diagram represents the object orientation of a system. Hence, it is generally used
for development purpose. This is the most widely used diagram at the time of system
construction.

12. CS8592 OOAD
UML diagrams
Component Diagram
Component diagrams represent a set of components and their relationships. These
components consist of classes, interfaces, or collaborations. Component diagrams
represent the implementation view of a system.
During the design phase, software artifacts (classes, interfaces, etc.) of a system are
arranged in different groups depending upon their relationship. Now, these groups are
known as components.
Finally, it can be said component diagrams are used to visualize the implementation.
Deployment Diagram
Deployment diagrams are a set of nodes and their relationships. These nodes are physical
entities where the components are deployed.
Deployment diagrams are used for visualizing the deployment view of a system. This is
generally used by the deployment team

13. CS8592 OOAD
UML diagrams
Behavioral Diagrams
Any system can have two aspects, static and dynamic. So, a model is considered as
complete when both the aspects are fully covered.
Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic
aspect can be further described as the changing/moving parts of a system.
UML has the following five types of behavioral diagrams −
•Use case diagram
•Sequence diagram
•Collaboration diagram
•State chart diagram
•Activity diagram

14. CS8592 OOAD
UML diagrams
Use Case Diagram
Use case diagrams are a set of use cases, actors, and their relationships. They represent
the use case view of a system.
A use case represents a particular functionality of a system. Hence, use case diagram is
used to describe the relationships among the functionalities and their internal/external
controllers. These controllers are known as actors.
Sequence Diagram
A sequence diagram is an interaction diagram. From the name, it is clear that the
diagram deals with some sequences, which are the sequence of messages flowing from
one object to another.
Interaction among the components of a system is very important from implementation
and execution perspective. Sequence diagram is used to visualize the sequence of calls
in a system to perform a specific functionality.

15. CS8592 OOAD
UML diagrams
Collaboration Diagram
Collaboration diagram is another form of interaction diagram. It represents the structural
organization of a system and the messages sent/received. Structural organization
consists of objects and links.
The purpose of collaboration diagram is similar to sequence diagram. However, the
specific purpose of collaboration diagram is to visualize the organization of objects and
their interaction.
State chart Diagram
Any real-time system is expected to be reacted by some kind of internal/external events.
These events are responsible for state change of the system.
State chart diagram is used to represent the event driven state change of a system. It
basically describes the state change of a class, interface, etc.
State chart diagram is used to visualize the reaction of a system by internal/external
factors.

16. CS8592 OOAD
UML diagrams
Activity Diagram
Activity diagram describes the flow of control in a system. It consists of activities
and links. The flow can be sequential, concurrent, or branched.
Activities are nothing but the functions of a system. Numbers of activity diagrams
are prepared to capture the entire flow in a system.
Activity diagrams are used to visualize the flow of controls in a system. This is
prepared to have an idea of how the system will work when executed.

17. CS8592 OOAD
UML diagrams
Use Case Diagrams
Introduction and importance
• Use cases are widely regarded as one of the
important artifacts needed to successfully
develop complex software systems
• Use cases define the scope of the system and
clarify the behavioral system requirements

18. CS8592 OOAD
UML diagrams
Use Case Diagrams
Introduction and importance
• Provide a basis for a coherent conceptual
understanding of the system under
consideration without requiring knowledge of
software design or implementation
technology
• Used as organized means of capturing domain
expertise

19. CS8592 OOAD
UML diagrams
Use Case Diagrams
Introduction and importance
• Can be used to track the progress of the
system development effort
• Provide means to trace requirements to the
design
• Provide the basis for developing system
acceptance tests

20. Use Case Driven
Req.ts Impl. Test
Use Cases bind these workflows together
Analysis Design

21. Use Cases Drive Iterations
• Drive a number of development activities
– Creation and validation of the system’s
architecture
– Definition of test cases and procedures
– Planning of iterations
– Creation of user documentation
– Deployment of system
• Synchronize the content of different models

23. Use Case Diagrams
Introduction and importance
• The identification of use cases and actors
occurs during the initial requirements
analysis phase of a project
• The use cases most essential to the
system are selected, analyzed, and
specified.

24. Use Case Diagrams
Introduction and importance
• These essential use cases eventually
become the basis for defining the
architecture of the system during the first
iterations of system development
• The use cases are then allocated to
iterative releases, which are planned and
eventually executed

25. Use Case Diagrams
Introduction and importance
• In the requirements phase of each
delivery, the use cases allocated to that
delivery are analyzed and completely
specified
• the use cases would then be realized by
domain level analysis/design using class
and interaction diagrams

26. Use Case Diagrams
Introduction and importance
• The domain level realization is further
refined into a detailed design that typically
employs class and interaction diagrams
and often includes state transition
diagrams and/or decision tables.

27. outline
• Review of development phases and UML Development – Overview
• Requirements Engineering and the Requirements model
• Introduction and importance of Use Case Diagrams
• Use Case Diagram Rules
• Examples of Use Case diagrams
• Requirements Elicitation Process
1. Identify Actors
2. Identify Scenarios
3. Identify Use Cases
4. Refine Use Cases
5. Identify Relationships between actors and Use Cases
6. Identify Initial Analysis Objects
7. Identify Non-functional requirements

28. Use Case Diagrams
Use Case Diagram Rules
– Use a “stick man” figure for an actor, and show
the actor’s name below the stick man
– The UML standard allows for the option of
using a class rectangle with the stereotype
«actor»
Command End
Item Hardware
User
«actor»
Sensor
<<Stereotype>>

29. Use Case Diagram Rules
• The only valid relationship between an actor
and another actor is generalization
User Super User
Run Applications Install Applications
A User can Run Applications.
A Super User can Install
Applications and Run
Applications, since a Super
User is a specialization of
User.

30. Use Case Diagram Rules
• Use only the following relationships between
use cases
– Use the include relationship to show that the
behavior of one use case is wholly and
unconditionally used in another use case
– Use the generalization relationship to show that a
use case is a specialization of another use case

31. Use Case Diagram Rules
• the include relationship
Perform Transaction
Send Command Receive Response
Application «include» «include»
The Perform Transaction
use case includes the
processing specified by
both the Send Command
and Receive Response
use cases.

32. Use Case Diagram Rules
• the generalization relationship
Validate Identity Identif y by f ingerprint scan
Identif y by retinal scan
Identif y by badge scan
Customer

33. Use Case Diagram Rules
• Use the extend relationship to show that one
use case conditionally augment (or extend)
the behavior of another use case.

34. Example of Extends relationship

35. Use Case Diagram Rules
• Extension points for a base use case are identified
within the specification of that base use case
• These are the locations where another use case may
extend the base use case. These extension points are
optionally shown in a diagram by listing them in a
compartment of the base use case bubble under the
heading “extension points
• The extending relationship identifies, within
parenthesis, the extension point(s) in the use case
being extended

36. Log In
extension pt::
Set Priv ileges
User
Grant Administrator Priv ledges
<<extends>>
(Set Priv ileges)
[Administrator Login ev ent]]
Identify, within brackets, the condition under
which the extension is executed

37. Example of Extends, includes, and generalization
relationships

38. Use Case Diagram Rules
• There must be one extension point listed for
each segment identified in the extension use
case
• Although considered optional, it is
recommended that the extending relationship
also identify, within brackets, the condition
under which the extension is executed

39. Examples of Use Case Diagrams
Example 1: Medical Clinic Software,
could be missing use case relations
Each use-case is described further by textual document and by
Scenarios developed using UML sequence diagrams

40. Example 2: E-Commerce Application (Incomplete)
Missing a link between “Place Requisition” and “Supplier”
and missing use case relationships
Customer Supplier
Bank
Browse Catalog
Confirm Shipment
Process Delivery Order
Send Invoice
Place Requisition
Confirm Delivery

41. Example 3: Coffee Maker, “waiting state”
Not a good name for a use-case (bad example)

42. Example 4: Anesthesia System
(Incomplete)

43. Example 5:
Automated
Air
Traffic
Control
System
(AATCS)