Final OOAD SRP 2024-25

Download as pdf or txt
Download as pdf or txt
You are on page 1of 91

V. R.

Siddhartha Engineering College


Department of Computer Science & Engineering
20CS5404F
OBJECT ORIENTED ANALYSIS AND DESIGN
SEMESTER READY PROGRAM (SRP)

Course Category: Programme Elective 1 Credits: 3


Course Type: Theory Lecture - Tutorial - Practice: 3-0-0
Prerequisites: Object Oriented Programming Continuous Evaluation: 30
Language Semester end Evaluation: 70
Total Marks: 100

SL.
SRP TASKS Page Numbers
NO.

1. Course Handout 1

3. Micro-Level Syllabus 11

4. Model Question Paper for Semester-end Examination 14

5. ALM (Question Paper with Rubrics) 17

6. Home Assignment Questions 28

8. Course Content (PPTs and Lecture Notes based on Course Type) 30

9. Question Bank for Slow Learners with BTL Levels 129

10. Question Bank for Fast Learners with BTL Levels 132
Course Handout

1
V. R. Siddhartha Engineering College
Department of Computer Science & Engineering
20CS5404F
OBJECT ORIENTED ANALYSIS AND DESIGN
Course Category: Programme Elective 1 Credits: 3
Course Type: Theory Lecture - Tutorial - Practice: 3-0-0
Prerequisites: Object Oriented Programming Continuous Evaluation: 30
Language Semester end Evaluation: 70
Total Marks: 100

COURSE OUTCOMES BTL POI

Upon successful completion of the course, the student will be able to:

CO Understand the basic concepts of object oriented analysis and design. K1 1.7.1, 2.5.1, 2.5.2
1
CO Apply object oriented methodologies for a given application. K3 1.7.1, 2.5.1,3.5.2,
2 3.5.6
CO Apply object oriented analysis process for any given application. K3 1.7.1, 2.5.1,3.5.2,
3 3.5.6
CO Illustrate the use of object oriented design process for a given application. K3 1.7.1, 2.5.1,3.5.2,
4 3.5.6
Contribution of Course Outcomes towards achievement of Program Outcomes
(1 – Low 2 - Medium 3 – High)
PO PO PO PO PO PO PO PO PO PO PO PO PSO1 PSO2
1 2 3 4 5 6 7 8 9 10 11 12

CO 2 3
1

CO 2 2 3 2
2

CO 2 2 3 2
3
CO 2 3 2
4
COURSE OUTCOME INDICATORS (COIs):
Highest BTL
CO No. BTL1 BTL2 BTL4 BTL5 BTL6
BTL 3
CO1 3 🗸 🗸
CO2 3 🗸 🗸 🗸
CO3 3 🗸 🗸 🗸
CO4 3 🗸 🗸 🗸

2
PROGRAM OUTCOMES & PROGRAM SPECIFIC OUTCOMES (POs/PSOs)

PROGRAM OUTCOMES
PO1: Engineering knowledge: Apply the knowledge of mathematics, science, engineering fundamentals, and an
engineering specialization to the solution of complex engineering problems.
PO2: Problem analysis: Identify, formulate, review research literature, and analyze complex engineering problems
reaching substantiated conclusions using first principles of mathematics, natural sciences, and engineering
sciences.
PO3: Design/development of solutions: Design solutions for complex engineering problems and design system
components or processes that meet the specified needs with appropriate consideration for the public health and
safety, and the cultural, societal, and environmental considerations.
PO4: Conduct investigations of complex problems: Use research-based knowledge and research methods
including design of experiments, analysis and interpretation of data, and synthesis of the information to provide
valid conclusions.
PO5: Modern tool usage: Create, select, and apply appropriate techniques, resources, and modern engineering
and IT tools including prediction and modeling to complex engineering activities with an understanding of the
limitations.
PO6: The engineer and society: Apply reasoning informed by the contextual knowledge to assess societal, health,
safety, legal and cultural issues and the consequent responsibilities relevant to the professional engineering
practice.
PO7: Environment and sustainability: Understand the impact of the professional engineering solutions in societal
and environmental contexts, and demonstrate the knowledge of, and need for sustainable development.
PO8: Ethics: Apply ethical principles and commit to professional ethics and responsibilities and norms of the
engineering practice.
PO9: Individual and team work: Function effectively as an individual, and as a member or leader in diverse teams,
and in multi-disciplinary settings.
PO10: Communication: Communicate effectively on complex engineering activities with the engineering
community and with society at large, such as, being able to comprehend and write effective reports and design
documentation, make effective presentations, and give and receive clear instructions.
PO11: Project management and finance: Demonstrate knowledge and understanding of the engineering and
management principles and apply these to one’s own work, as a member and leader in a team, to manage projects
and in multi-disciplinary environments.
PO12: Lifelong learning: Recognize the need for, and have the preparation and ability to engage in independent
and life-long learning in the broadest context of technological change.
PROGRAM SPECIFIC OUTCOMES
PSO1: Develop software applications/solutions as per the needs of Industry and society
PSO2: Adopt new and fast emerging technologies in Computer Science and Engineering

COURSE CONTENT

Unit-I: Introducing UML and UP. What is UML?, What is Unified Process?, Requirements, Requirements
Workflow, Use Case Modelling, Advanced use case modelling,
Unit-II:Analysis, The analysis workflow, Objects and Classes, Finding analysis classes, Relationships, Inheritance
and Polymorphism.
Unit-III: Analysis Packages, Use Case realization, Advanced Use Case realization, Activity Diagrams, Advanced
activity Diagrams.
Unit-IV: Design, The Design workflow, Design Classes, Refining analysis relationships, Interfaces and components,
Use case realization- Design, State Machines. Implementation, The Implementation work flow, Deployment
TEXT BOOKS

3
Text Books:
[1] Jim Arlow, Ila Neustatd, UML2 and the Unified Process, Practical Object Oriented Analysis and Design,
Second Edition ,Addison- Wesley Publication.
REFERENCE BOOKS
[1] Object Oriented Analysis Design and Implementation, An integrated approach, Second Edition, Springer
University Press.
[2] G. Booch, 1999, Object Oriented Analysis and design, 2nd Edition, Addison Wesley, Boston
[3] R. S.Pressman, 2010, Software Engineering A Practitioner’s approach, Seventh Edition, Tata McGraw Hill,
New Delhi.
[4] Rumbaugh, Blaha, Premerlani, Eddy, Lorensen, 2003, Object Oriented Modeling And design , Pearson
education, Delhi.

E-RESOURCES AND OTHER DIGITAL MATERIAL

[1] Object-Oriented Analysis and Design Prof. Partha Pratim Das Department of Computer Science and
Engineering Indian Institute of Technology-Kharagpur, https://nptel.ac.in/courses/106/105/106105153/
[2] Object Oriented Analysis and Design By Prof. Partha Pratim Das, Prof. Ansuman Banerjee, Prof. Kausik Datta
| IIT Kharagpur https://onlinecourses.nptel.ac.in/noc20_cs59/preview
[3] Introduction to Object Oriented Analysis and Design by James Lauren
https://www.youtube.com/watch?v=APyM4xCfxEQ

COURSE DELIVERY PLAN:

Book – T1
Teaching- Evaluatio
Sess. [CH
CO BTL Topic (s) Session Outcome Learning n
No. No][Page
Methods Componen
No] ts
1. 1 2 What is UML?, The Understand the concepts of T1[1][1-8] PPT/ Board A1, HA
birth of UML, MDA - UML,MDA and future
the future of UML scope of UML
2. 1 2 Why "unified"?, Objects Understand the objectives of T1[1][9-10] PPT/ Board A1, HA
and UML, UML UML, structure
structure,
3. 1 2 UML building blocks Understand types of T1[1][11- A1, HA
building blocks and their 15] PPT/ Board
usages
4. UML building blocks Understand types of T1[1][11- A1, HA
building blocks and their 15] PPT/ Board
usages
5. 1 1 UML common Understand various of T1[1][16- A1, HA
mechanisms common mechanisms and 23] PPT/ Board
their usages
6. 1 2 UML common Understand various T1[1][16- A1, HA
mechanisms, common mechanisms, 24] PPT/ Board/
Architecture architecture

4
Book – T1
Teaching- Evaluatio
Sess. [CH
CO BTL Topic (s) Session Outcome Learning n
No. No][Page
Methods Componen
No] ts
7. 1 2 UML Architecture , Understand what is UP T1[2][32,3 CT1, HA
What is UP & RUP? UP &RUP, their structure and 5-39]
PPT/ Board
– interative & processes
incremental Process,
8. 1 2 UP structure Understand different T1[3][51- PPT/ Board CT1, HA
Requirement Workflow, software requirements and 55]
Software requirements, how to define them.
Define requirements,
9. 1 3 organsing requirements, Understand how to find and T1[3][57- PPT/ CT1, HA
Finding requirements – organize the requirements. 59,61] Board/Case
case study, ATM Summarize the required study
requirements for ATM
10. 1 1 Use case Modeling, Identify the actors and their T1[4][69- PPT/ CT1, HA
What are actors – life time 74] Board/Visual
Identify, Time Sybthesis
video
11. 1 2 What are use cases – Identify the usecases and T1[4][91- PPT/ CT1, HA
Identify, usecase their association with actors 92] Board/LTC
diagram
12. 1 2 Advanced Usecase Identify the secondary T1[4][97- PPT/ Board CT1, HA
Modeling: Actor actors and use cases and 104]
Generalization, Usecase their relationship with the
generalization – primary events
insertion,
13. 1 2 extend, Avoid functional Understand the extends T1[4,5][10 PPT/ Board CT1, HA
decomposition relationship and avoidance 5-107,
of functional decompostion 112,134]
14. 2 3 Analysis workflow - Understand the workflow T1[6,7][12 PPT/ Board S1, HA
detail, UML object & details and learnt the 2][153,
class notation notations for an object and 158-159]
classes with specifications
15. 2 2 Finding classes by using Analyze the verbs and nouns T1[8][163- PPT/ Board S1, HA
noun/verb analysis, to find the classes 165]
16. 2 2 Finding classes by using To find the classes by CRC T1[8][165- PPT/ Board S1, HA
CRC analysis analysis 166]
17. 2 1 Finding classes by using To find the classes by RUP T1[8][167- PPT/ Board S1, HA
the RUP stereotypes analysis 169]
18. 2 2 Relationship, Link, To apply different T1[9][180- PPT/ S1, HA
Object diagram, relationship among the 185] Board/Quiz
Association, objects. Differences
between relationship, link
and association

5
Book – T1
Teaching- Evaluatio
Sess. [CH
CO BTL Topic (s) Session Outcome Learning n
No. No][Page
Methods Componen
No] ts
19. 2 2 Dependencies, Apply dependencies and T1[9][195, PPT/ Board S1, HA
Generalizations- class generalizations among the 206-207,
generalizations classes
20. 2 2 Polymorphism Apply polymorphism T1[9]211- PPT/ Board S1, HA
relationship on a class 213]
21. 3 1 What is Package? Name To understand the package T1[11][228 PPT/ Board CT2, HA
Space, Nested packages and its structure. -228]
22. 3 3 Package Dependencies To identify the suitable T1[11][224 PPT/ Board CT2, HA
dependencies and apply -231]
among the packages
23. 3 1 What are Usecase To identify the usecase T1[12][242 PPT/ Board CT2, HA
Ralizatio, Elements, realization and other -247]
interactions, Lifelines & elements
messagges
24. 3 2 Interaction Daigrams: Understand the concepts of T1[12][249 PPT/ Board CT2, HA
Sequence diagrams Interaction diagrams and -263]
identify their elements
25. 3 3 Communication Apply the concepts to T1[12][264 PPT/ Board CT2, HA
diagrams construct communication -379]
daigrams
26. 3 2 Advanced Usecase Understand the concepts of T1[13][274 PPT/ Board CT2, HA
Realization: advanced use case diagrams -281]
Interactions, Parameters,
Gates, Continuations
27. 3 3 Advanced Usecase Design the activity diagrams T1[13][288 PPT/ Board CT2, HA
Realization: -300]
Interactions, Parameters,
Gates, Continuations
28. 3 3 Activity diagrams: Apply the activity diagram T1[13][301 PPT/ Board CT2, HA
Activities, Partitions, concepts to design an -307]
Action Node, Call Node, activity diagram
Control Nodes
29. 3 3 Advanced Activity Apply the concepts to T1[14][311 PPT/ CT2, HA
Diagram: Connectors, construct communication -313] Board/Case
diagrams study

30. 3 3 Advanced Activity Understand the concepts of T1[14][314 PPT/ Board CT2, HA
Diagram: Exceptions advanced activity daigrams -316]
31. 4 2 Design: Design Work Understand the design work T1[16][331 PPT/ Board CT2, HA
Flow, artifacts flow concepts and artifacts -333]
32. 4 2 Design Classes: What Understand the concepts of T1[17][344 PPT/ Board CT2, HA
are design classes, Interaction diagrams and -347]
Anatomy identify their elements

6
Book – T1
Teaching- Evaluatio
Sess. [CH
CO BTL Topic (s) Session Outcome Learning n
No. No][Page
Methods Componen
No] ts
33. 4 3 Design classes complete Apply the concepts to T1[17][460 PPT/ Board CT2, HA
specification construct communication -472]
diagrams
34. 4 3 Refining Analysis Apply various relationships T1[18][360 PPT/ CT2, HA
Relationships : Design, among the components -367] Board/Group
Aggregation, Discussion

35. 4 2 Composition, Design the activity diagrams T1[18][368 PPT/ Board S2, HA
Association, Refined with the refined -375]
Relationships relationships
36. 4 1 Interfaces and Understand the concepts of T1[19][389 PPT/ Board S2, HA
Components: What is Interaction diagrams and -393]
interface identify their elements
37. 4 4 Interface realization vs. Apply the knowledge to T1[19][394 PPT/ Board S2, HA
inheritance, Component design component daigrams -402]
38. 4 2 Use case realization- Understand the concepts of T1[19][416 PPT/ Board S2, HA
Design, interaction usecase realization -419]
diagrams in design
39. 4 4 Timing Daigrams, State Design the activity diagrams T1[20][427 PPT/ Board S2, HA
Machines: State -430]
diagrams, states
40. 4 4 Implementation – Understand the concepts of T1[21][439 PPT/ Board S2, HA
Implementation state machine and identify -446]
workflow, artifacts the states
41. 4 2 Deployment – Diagram, Design the implementation T1[23][476 PPT/ Board S2, HA
artifacts diagram -479]
42. 4 3 Deployment – Diagram, Design the deployment T1[24][483 PPT/ Board S2, HA
artifacts diagrams -486]

PRACTICAL COMPONENT

List of Experiments supposed to finish in Open Lab Sessions:


• Assigned different applications as a part of cast studies to design and develop using visual paradigm tool,
or any online tools.

COURSE TIME TABLE


Course Conduct

Theory Lecture 3 Sections | 72 Students each | 3 Lectures per week


Class Room | Course Coordinator 1 Tutorial per week
Practical 3 Sections | 72 Students each | 1 P per week | each 2 hrs.
1 Batch | 3 Instructors | 72 Computers 90 minutes Experiment |
30 minutes Evaluation for 25 students per
instructor

7
Hour 1 2 3 4 5 6 7 8 9
08:30 09:30 10:30 11:30 12:30 01:30 02:30 03:30 04:30
Day Component 09:30 10:30 11:30 12:30 01:30 02:30 03:30 04:30 05:30

Mon Theory OOAD


Tue Theory OOAD

LUNCH
L
Wed Theory A
B
OOAD
Thr Theory
OOAD
Fri Theory
Sat Theory

REMEDIAL CLASSES:

Supplement course handout, which may perhaps include special lectures and discussions that would be
planned, and schedule notified accordingly.

SELF-LEARNING:

Assignments to promote self-learning, survey of contents from multiple sources.

S.N Topics CO Evaluations References/MOOCS


1 Design classes 3 Assig/Sess-II https://nptel.ac.in/courses/106105153
Home Assig
2 Designing of state chart 4 Assig/Sess-II https://nptel.ac.in/courses/106105153
Diagram Home Assig

DELIVERY DETAILS OF CONTENT BEYOND SYLLABUS:


Content beyond syllabus covered (if any) should be delivered to all students that would be planned, and
schedule notified accordingly.

S.N Advanced Topics, CO POs ALM References/MOOCS


Additional &PSOs
Reading, Research
papers and any
1 Interaction 3 PO2, Case https://nptel.ac.in/courses/106105153
Diagrams at Low PSO1 Study,
and High Level Expert
Talk
2 Usecase diagrams at 4 PO3, Quiz, https://nptel.ac.in/courses/106105153
High and Low level PSO1 Expert
Talk

8
THEORY COURSESWITH 2/3/4 CREDITS -EVALUATION PLAN:

Evaluation Evaluation Assessme Duration


Marks CO1 CO2 CO3 CO4
Type Component ntDates (Hours)

Blooms Taxonomy Level


ClassTest-I
ClassTest -I Max Marks: 10 M 45 Min ✓
Dates
Sessional –I
Sessional -I Max Marks:12 M Dates 75 Min ✓ ✓
Classtest-II
In-Semester Classtest-II Max Marks: 10 M 45 Min
Dates
Summative Sessional –II
Evaluation Sessional -II Max Marks: 12 M Dates 75 Min ✓ ✓
Total = 30 % Home
Max Marks: 5 M Home Assignment ✓ ✓ ✓ ✓
Assignment
Students are informed that upon completion of CCNA-1 course (LTC) and submission
of certificate, full Home Assignment marks will be awarded.
Attendance Max Marks: 3 M Continuous evaluation
End-Semester
Summative Semester End End
Max Marks: 70M 3 hrs
Evaluation Exam Se
Total = 70 % m Dates

ATTENDANCE POLICY

Three marks in each theory course shall be given for regularity in a graded manner as given in Table 3.

PLAGIARISM POLICY

Use of unfair means in any of the evaluation components will be dealt with strictly, and the case will
be reported to the examination committee.

COURSE TEAM MEMBERS, CHAMBER CONSULTATION HOURS AND CHAMBER VENUE


DETAILS:

Each instructor will specify his / her chamber consultation hours during which the student can contact
him / her in his / her chamber for consultation.

Chamber
Chamber Chamber
Consultation Signature of
S.No. Name of Faculty Consultation Consultation
Timings for each Course faculty
Day (s) Room No
day
1 Ms M.Madhavi All Working 4 PM - 5 PM 156
days

9
GENERAL INSTRUCTIONS
Students should come prepared for classes and carry the text book(s) or material(s) as prescribed by the
Course Faculty to the class.

NOTICES
All notices will be communicated through the institution email.
All notices concerning the course will be displayed on the Google Classroom.

Course Instructor :

Course Coordinator:

HEAD OF DEPARTMENT

10
Micro-Level Syllabus

11
V. R. Siddhartha Engineering College
Department of Computer Science & Engineering
MICRO LEVEL SYLLABUS

Class B Tech Regulation VR20

Subject Code 20CS5404F Year & Semester III Year & V Semester

Title of the Subject OBJECT ORIENTED ANALYSIS AND DESIGN

UNIT Book – T1
Topic (s)
[CH No][Page No]
I What is UML?, The birth of UML, MDA - the future of UML T1[1][1-8]
Why "unified"?, Objects and UML, UML structure, T1[1][9-10]
UML building blocks T1[1][11-15]
UML building blocks T1[1][11-15]
UML common mechanisms T1[1][16-23]
UML common mechanisms, Architecture T1[1][16-24]
What is UP & RUP? UP – interative & incremental Process, UP T1[2][32,35-39]
structure
Requirement Workflow, Software requirements, Define T1[3][51-55]
requirements,
organsing requirements, Finding requirements – case study, T1[3][57-59,61]
ATM
Use case Modeling, T1[4][69-74]
What are actors – Identify, Time
What are use cases – Identify, usecase diagram T1[4][91-92]
Advanced Usecase Modeling: Actor Generalization, Usecase T1[4][97-104]
generalization – insertion
extend, Avoid functional decomposition T1[4,5][105-107, 112,134]
II Analysis workflow -detail, UML object & class notation T1[6,7][122][153, 158-159]
Finding classes by using noun/verb analysis, T1[8][163-165]
Finding classes by using CRC analysis T1[8][165-166]
Finding classes by using the RUP stereotypes T1[8][167-169]
Relationship, Link, Object diagram, Association, T1[9][180-185]
Dependencies, Generalizations- class generalizations T1[9][195,206-207,
Polymorphism T1[9]211-213]
III What is Package? Name Space, Nested packages T1[11][228-228]
Package Dependencies T1[11][224-231]
What are Usecase Ralizatio, Elements, interactions, Lifelines & T1[12][242-247]
messagges
Interaction Daigrams: Sequence diagrams T1[12][249-263]
Communication diagrams T1[12][264-379]
Advanced Usecase Realization: Interactions, Parameters, Gates, T1[13][274-281]
Continuations
Activity Diagrams: Activities, Partitions, Action Node, T1[13][288-300]
Activity diagrams: Call Node, Control Nodes T1[13][301-307]
Advanced Activity Diagram: Connectors, T1[14][311-313]

12
UNIT Book – T1
Topic (s)
[CH No][Page No]
Advanced Activity Diagram: Exceptions T1[14][314-316]
IV Design: Design Work Flow, artifacts T1[16][331-333]
Design Classes: What are design classes, Anatomy T1[17][344-347]
Design classes complete specification T1[17][460-472]
Refining Analysis Relationships : Design, Aggregation, T1[18][360-367]
Composition, Association, Refined Relationships T1[18][368-375]
Interfaces and Components: What is interface T1[19][389-393]
Interface realization vs. inheritance, Component T1[19][394-402]
Use case realization- Design, interaction diagrams in design T1[19][416-419]
Timing Daigrams T1[20][427-430]
State Machines: State diagrams, states T1[21][439-446]
Implementation – Implementation workflow, artifacts T1[23][476-479]
Deployment – Diagram, artifacts T1[24][483-486]

M.Madhavi

13
MODEL QUESTION PAPER

14
MODEL QUESTION PAPER
VELAGAPUDI RAMAKRISHNA SIDDHARTHA ENGINEERING COLLEGE
(AUTONOMOUS)
III/IV B. Tech (SEMESTER V)
OBJECT ORIENTED ANALYSIS & DESIGN
20CS5404F
Time: 3 Hours Max. Marks 70
BL – Bloom’s Taxonomy Levels (K1- Remembering, K2- Understanding, K3 – Applying, K4 –
Analyzing, K5 – Evaluating, K6 - Creating)
CO – Course Outcomes; PO – Program Outcomes; PI Code – Performance Indicator Code
PART-A is compulsory
Answer ONE question from each unit of PART-B

Part – A

Each question carries ONE mark BL CO PI CODE

1. Define UML. K1 1 1.7.1


2. Draw a structure of UML System architecture. K2 1 1.7.1
3. List out the artifacts of a metamodel. K2 2 1.7.1

4. In which phase of a workflow the main work of analysis will begin? K2 2 1.7.1
5. What is a package? K2 3 1.7.1
6. Differentiate between call node & control node. K2 3 1.7.1
7. What is analysis class? K1 3 1.7.1
8. Model a state machine to a light bulb. K3 4 1.7.1

9. Is implementation model part of the design model? K3 4 1.7.1


10. What will be mapped with the deployment diagram? K2 4 1.7.1
Part-B
UNIT-1
Marks BL CO PI Code
2 (a) Summarize in detail about different building blocks. 7 K1 1 1.7.1
(b) Identify the system use cases and illustrate the functioning of a 8 K2 1 1.7.1, 2.5.2
Mobile Banking App by drawing an advanced use case diagram.

[OR]
3. (a) Describe the birth of UML. Also identify and demonstrate the 7 K1 1 1.7.1, 2.5.1
functional and non functional requirements for the case study of
automated teller machine (ATM).
(b) Illustrate UP iterative and incremental process and its structure in 8 K2 1 1.7.1
detail with a neat diagram

15
UNIT- II
Marks BL CO PI Code
4 (a) Explain how to apply CRC analysis to find the classes in detail 7 K3 2 1.7.1,

(b) Illustrate the probable attributes and operations that will be used to 8 K3 2 1.7.1,
model the class diagram and Object diagram for the library 3.5.2
management system.
[OR]
5 (a) Show and demonstrate a Noun/ verb phase analysis approach for 7 K3 2 1.7.1,
. identifying the classes in the process of constructing a class 3.5.2
diagram for an E- Commerce application.
(b) Summarize different approaches used used for finding the classes, 8 K2 2 1.7.1,
attributes & responsibilities. 3.5.6
UNIT- III
Marks BL CO PI Code
6 (a) Identify the users, actors and their behavior those are involved in the 9 K3 3 1.7.1,
ATM system for designing a sequence diagram and illustrate its 2.5.1
functionality.
(b) Can a sequence diagram replace by communication diagram? If yes, 8 K3 3 1.7.1,
illustrate the process by considering an example.
[OR]
7 (a) Elaborate different relationships and their stereotypes by considering 7 K3 3 1.7.1
suitable examples for showing the semantic connections between
things.
(b) A University conducts examination and the results are announced. 8 K3 3 1.7.1,
Identify a problem statement. Apply the following requirements to 3.5.6
draw an activity diagram
a. Print the marks in the register number order semester wise for
each department
b. Print the Arrear list semester wise.
c. Prepare a Rank list for each department.
UNIT- IV
Marks BL CO PI Code
8 (a) Explain in detail about how to refine the analysis relationships with 8 K2 4 1.7.1
suitable examples.
(b) Illustrate the relationship between the design model and 7 K3 4 1.7.1,
implementation model with an example. 2.5.1

[OR]
9 (a) Model and demonstrate a timing diagram for the timing constraints 8 K3 4 1.7.1,
of electronic circuits. 3.5.6
(b) Demonstrate Behavioral state machines and protocol state machines 7 K2 4 1.7.1
with a suitable example.

16
ACTIVE LEARNING METHODOLOGY

17
V. R. Siddhartha Engineering College
Department of Computer Science & Engineering
III/IV B. Tech – Object Oriented Analysis & Design (20CS5404F)
STUDENT-CREATED PPT, CHARTS, MATRICES, FLOWCHARTS,
MODELS:
Students are encouraged to build charts, matrices, flowcharts, and models as
contexts for extending their understanding of key course-specific concepts.

Procedure : Faculty can provide the basic guide lines and the skeleton for the
students to develop their presentation.
2. Faculty remains as a facilitator and limits himself/herself to asking probing
and meaningful questions.

18
V. R. Siddhartha Engineering College
Department of Computer Science & Engineering
III/IV B. Tech – Object Oriented Analysis & Design (20CS5404F)
Roleplay Rubrics

Topic: Sequence Diagram for ATM Transactions

Procedure:

• Provides a case study of transaction in ATM Machines. Ask the students to perform a
roleplay
• 5 Roles selected here i.e customer, Bank, Trusted Third party for card, Bank, and
Secure Transaction channel to play by the students.

Marks to be 5M 3M 1M
awarded
Identifies the offered Accurately identifies Accurately Identifies the Does not
role and plays it with the role and performs role and performs it identifies the
perfection it admirably satisfactorily role at all

19
V. R. Siddhartha Engineering College
Department of Computer Science & Engineering
III/IV B. Tech – Object Oriented Analysis & Design (20CS5404F)
Quiz Rubrics

Topic: Interaction Diagrams

Procedure:

• Assigns the topic to the students for homework.


• Review the student’s preparation by conducting a quiz/test that includes various levels
of degree of difficulty.

Marks to be awarded 5M 4M 2M
Identifies and summarize Accurately Accurately Identifies Partial
the answers to the posted identifies, effective but not assessed attempt to the
query assessing properly queries

20
V. R. Siddhartha Engineering College
Department of Computer Science & Engineering
III/IV B. Tech – Object Oriented Analysis & Design (20CS5404F)
Case Studies Rubrics

Procedure
• Provides list of case studies which could be complete the task by a group.
• Ask the group to design a class diagram with the suitable operations and attributes, a
use case diagram with the actors and use cases and a sequence diagram with the flow
of actions among the objects.
• Uses either visual parading and any online tool to design the diagrams.
• The case study includes description for each diagram.

Marks to be 5M 3M 1M
awarded
Identifies the Accurately identifies Identifies the problem Identifies the
problem and the problem and and effectively problem but poor
Analyze and effectively analyze and analyze but poor analyze and design
design the system design the system design the system the system

21
HOME ASSIGNEMENT QUESTIONS

22
V. R. Siddhartha Engineering College
Department of Computer Science & Engineering
Home Assignment Questions – Case Studies
Class B Tech Regulation VR20
Subject Code 20CS5404F Year & Semester III Year & V Semester
Title of the Subject OBJECT ORIENTED ANALYSIS AND DESIGN

S.No Designing of UML models for the following systems


1 Sensory software for reading and listening drug description
2 Application for Assessment of Quality of Textbook/ Reference Books/ E- Book
3 Wrong Posture Muscle Strain Detector Using PoseNet
4 Proximity-Based Music Pause System
5 Lumpy disease detection in cattle using deep learning
6 Tailor Connect: Bridging the gap between customers and tailors in the digital era
7 Empowering Small-Scale Farmers: An Intelligent Crop Selection System
8 Hostel Finder Application Development
9 Smart Food Bin Using IoT
10 Virtual Exploration - An Immersive Experience
11 Multi-facial object recognition based automatic attendence system
Analysis of vehical density and adaptive traffic light control using intelligent traffic
12 management system
13 Fake logo detection using deeplearning
14 Detection of dermatophytosis in cats using deep learning
Web-Based Agriculture Recommendation System using Deep Learning for Crop, Fertilizers
15 and Pesticides
16 Library visitor counting system
17 Automated sleep analysis using deeplearning
18 An App for Video translator and summarizer
19 Durg Recommender System for Customized Clinical Prescription
20 Blood Report Analysis
21 Demodex detection in dogs
22 Application for Electricity bill Calculation using Machine Learning
23 E-learning platform
24 Games For Blind people
25 Reviving and enrichment of ancient heritage(kondapalli bommallu)
26 Monitoring fluid level of inverter

23
Course Content

24
25-11-2023

e asic re ise o is t at e can ode so t are and ot er


s ste s as co ections o interactin o ects
ere are t o as ects to a ode
t is descri es at t es o o ects are i ortant or
ode in t e s ste and o t e are re ated
t is descri es t e i e c c es o t ese o ects and
o t e interact it eac ot er to de i er t e re uired s ste
unctiona it

ntroducin and P

at is at is ni ied
Process

e uire ents

e uire ents or o

se ase ode in
and t e ni ied Process econd diti on
Practica ect riented na si s and esi n d anced use case ode in
ddison es e Pu ication

in s in s are t e nouns o a ode


t in s a e artitioned into
t e nouns o a ode suc as c ass inter ace
ntroducin and P co a oration use case acti e c ass co onent node
t e er s o a ode suc as interactions acti ities
at is e ni ied ode in an ua e is a enera ur ose
isua ode in an ua e or s ste s state ac ines
t e ac a e ic is used to rou se antica re ated
e ni ied Process P is a et odo o it te s us t e or ers acti ities and ode in e e ents into co esi e units
arti acts t at e need to uti i e er or or create in order to ode a so t are
s ste t e note ic a e a ended to t e ode to ca ture
ad oc in or ation er uc i e a e o stic note

ro ides isua s nta or ode in ri t t rou t e so t are


de e o ent i e c c e ro re uire ents en ineerin to i e entation
as een used to ode e er t in ro ard rea ti e e edded s ste s
to ana e ent decision su ort s ste s
ode s t e or d as s ste s o interactin o ects n o ect is a co esi e c uster o data and
unction is an ua e neutra and at or neutra
atura it as e ce ent su ort or ure an ua es a ta a a etc
a t ou P and its ariants are ro a t e re erred de e o ent rocesses
or s ste s can and does su ort an ot er so t are en ineerin rocesses ts o n interna
conce ts a iant tries to e consistent and uni or in its a ication o a s a set o interna
conce ts t doesn t as et a a s succeed ut it is sti a i i ro e ent on rior atte ts

322
323
324
t e a is not t e territor
e a e our se ection ro t e ast arra o ossi e in or ation a in t ese t ree i ters
de etion in or ation is i tered out
unctiona re uire ent is a state ent o at t e s ste s ou d doit is a state ent o s ste distortion in or ation is odi ied t e re ated ec anis s creation and a ucination
unction enera i ation in or ation is a stracted into ru es e ie s and rinci es a out trut and a se ood
or e a e i ou ere co ectin re uire ents or an auto ated te er ac ine ou i t
identi t e o o in unctiona re uire ents on t a ucinate a so ution
s conte t ree uestions
e s ste s a c ec t e a idit o t e inserted card isten
on t ind read
e s ste s a a idate t e P nu er entered t e custo er a e atience
e s ste s a dis ense no ore t an a ainst an card in an our eriod uestionnaires

non unctiona re uire ent is a constraint aced on t e s ste or our s ste t ere a are no su stitute or inter ie s
e t e o o in non unctiona re uire ents
ou decide to use uestionnaires it out doin an inter ie s ou
e s ste s a e ritten in a ind ourse in an i ossi e situation ere ou ust decide on a ist
e s ste s a co unicate it t e an usin it encr tion e s ste o uestions e ore ou no t e ri t uestions to as
s a a idate an card in t ree seconds or ess
e s ste s a a idate a P in t ree seconds or ess

e e sta e o ders to artici ate in a or s o to identi e re uire ents e or s o s ou d ocus on


rainstor in
e artici ants in t e eetin s ou d e a aci itator a re uire ents en ineer and t e e sta e o ders and
do ain e erts
e rocedure is as o o s
ain t at t is is a true rainstor
ideas are acce ted as ood ideas
deas are recorded ut not de ated ne er ar ue a out so et in ust rite it do n and t en o e on
er t in i e ana ed ater
s t e tea e ers to na e t eir e re uire ents or t e s ste
rite eac re uire ent on a stic note
tic t e note on a a or ite oard
ou a t en c oose to iterate o er t e identi ied re uire ents and note additiona attri utes a ainst eac one
ter t e eetin ana e t e resu ts and turn t e into re uire ents
e uire ents en ineerin is an iterati e rocess ere ou unco er re uire ents as ou re ine our understandin
o t e needs o t e sta e o ders ou a need to o d se era or s o s o er ti e as our understandin
dee ens

325
at are actors
n actor s eci ies a ro e t at so e e terna entit ado ts en interactin it our s ste direct t a
re resent a user ro e or a ro e a ed anot er s ste or iece o ard are t at touc es t e oundar o
our s ste

use case descri es e a ior t at t e s ste e i its to ene it one or ore actors se case enera i ation actors out e a ior co on to one or ore
o ind use cases as use cases into a arent use case
o does eac actor use t e s ste and se case enera i ation is used en ou a e one or ore use cases
at does t e s ste do or eac actor
t at are rea s ecia i ations o a ore enera case
e e erence anua u au de ines a use case as s eci ication o
ust i e actor enera i ation ou s ou d on use t is en it
se uences o actions inc udin ariant se uences and error se uences t at a s ste si i ies our use case ode
su s ste or c ass can er or interactin it outside actors n use case enera i ation t e c i d use cases re resent ore s eci ic
use case is so et in an actor ants t e s ste to do t is a case o use o t e or s o t e arent
s ste a s eci ic actor e c i dren a
use cases are a a s started an actor in erit eatures ro t eir arent use case
use cases are a a s ritten ro t e oint o ie o t e actors add ne eatures
o erride c an e in erited eatures

denti in use cases


e est a o identi in use cases is to start it t e ist o actors and t en consider o eac actor is
oin to use t e s ste sin t is strate ou can o tain a ist o candidate use cases ac use case
ust e i en a s ort descri ti e na e t at is a er rase a ter a t e use case is doin so et in

326
327
e ations i s

Unit-II

c ass re resents a co ection o o ects a in sa e


c aracteristic ro erties t at e i it co on e a ior
reation o an o ect as a e er o a c ass is ca ed
instantiation
n o er ie ect asics ect state and ro erties us o ect is an instance o a c ass
e a ior et ods essa es n or ation idin a e a c ass
ass ierarc e ations i s ssociations to t e center
re ations dentit na ic indin Persistence a to denote t e radius o t e circ e
eta c asses ect oriented s ste de e o ent i e o e o its o erations can e de ined as o o s
c ce ind rea et od to ca cu ate area
ind ircu erence et od to ca cu ate
circu erence

e ro e o a c ass is to t e state
e ations i s
and e a iour

sed to

et o o ects

is si an

e or e a e ac
indi idua car o ect i a ea

328
e ations i s
e ations i s

e ations i s
e ations i s

is rea a stron or o

co onents a e on one o ner


co onents cannot e ist inde endent o t eir o ner
co onents i e or die it t eir o ner
e ac car as an en ine t at can not e s ared it
ot er cars

a or art o t e a re ate ut a not e


essentia to it e a a so e ist inde endent o t ea re ate
e es a e ist inde endent o t e a

329
n eritance

ne o ee r o n oin oined
etire etired
ect c asses a in erit attri utes and ser ices ro
oo oo it tit e dd e ar ent a ai a e
ect riented reser ed ot er o ect c asses
na sis esi n
sa e a e no end n oiced n oiced n eritance re resents t e enera i ation o a c ass
ance cance ed

ect ass essa e Passin

ass is a descri tion o a set o o ects t at s are t e


sa e attri utes o erations et ods re ations i and
se antics
ect c asses are te ates or o ects e a e used
to create o ects
n o ect re resents a articu ar instance o a c ass

nca su ation
va e attri utes and et ods are enca su ated it in t e
c ass t e cannot e seen c ients o t e c ass
l et ods de ine t e inter ace t at t e c ass ro ides to
its c ients

32
10
essa e Passin d anta es o n eritance

t is an a straction ec anis ic a e used to


c assi entities

t is a reuse ec anis at ot t e desi n and t e


ro ra in e e

e in eritance ra is a source o or anisationa


no ed e a out do ains and s ste s

n eritance
enera isation ierarc

ect c asses a in erit attri utes and ser ices ro


ot er o ect c asses

n eritance re resents t e enera i ation o a c ass

u ti e n eritance
oo oice recordin u ti e in eritance
ut or ea er
dition uration
Pu ication date ecordin date at er t an in eritin t e attri utes and ser ices ro a
sin e arent c ass a s ste ic su orts u ti e
in eritance a o s o ect c asses to in erit ro se era
su er c asses

a in oo an ead to se antic con icts ere attri utes ser ices


a es it t e sa e na e in di erent su er c asses a e di erent
se antics

a es c ass ierarc reor anisation ore co e

32
11
s ecia eature o o ect oriented s ste is t at e er o ect as its o n uni ue and i uta e
identit n o ect s identit co es into ein en t e o ect is created and continues to re resent t at
o ect ro t en on is identit ne er is con used it anot er o ect e en i t e ori ina o ect as
een de eted

Po or is n an o ect s ste
or uni ue identi ier
o ect identit o ten is i e ented t rou so e ind o

e a i it o di erent o ects to er or t e a ro riate


et od in res onse to t e sa e essa e is no n as
e rocess o deter inin d na ica at run ti e ic unctions to in o e is ter ed
o or is
e se ection o t e a ro riate et od de ends
a in t ison
deter t ination
e ear ier at co i e ti e is ca ed
c ass used to create t e o ect tatic indin o ti i es t e ca s d na ic indin occurs en o or ic ca s are
issued
na ic indin a o s so e et ods in ocation decisions to e de erred unti t e
in or ation is no n

s ecia eature o o ect oriented s ste is t at e er o ect as its o n uni ue and i uta e
identit n o ect s identit co es into ein en t e o ect is created and continues to re resent t at
o ect ro t en on is identit ne er is con used it anot er o ect e en i t e ori ina o ect as
een de eted

n an o ect s ste o ect identit o ten is i e ented t rou so e ind o


or uni ue identi ier

e rocess o deter inin d na ica at run ti e ic unctions to in o e is ter ed

a in t is deter ination ear ier at co i e ti e is ca ed


tatic indin o ti i es t e ca s d na ic indin occurs en o or ic ca s are
issued
na ic indin a o s so e et ods in ocation decisions to e de erred unti t e
in or ation is no n

The main work in analysis begins toward


◦ the end of the Inception phase and
◦ the main focus of the Elaboration phase, along with requirements.
The Main aim of analysis workflow is
◦ To produce an analysis model.

32
12
A. Analysis artefacts -Metamodel

Two key artifacts are as follows


a. Analysis classes
b. use case realizations

32
13
B. UP analysis workflow
It has 4 stages. Those are as follows
• Architectural analysis;
• Analyze a use case;
• Analyze a class;
• Analyze a package

C. Analysis model - rules of thumb:


• 50 to 100 analysis classes in the analysis model.
• only include classes - the vocabulary of the problem domain related
• Do not make implementation decisions;
• Focus on classes and associations - minimize coupling;
• Use inheritance where there is a natural hierarchy of abstractions;
• keep it simple!

2. Objects and classes:


• Object Notation:

• Class Notation:

32
14
3. Finding Classes
• The way of finding the classes are as follows
1. by using noun/verb analysis
2. by using CRC analysis
3. by using the RUP stereotypes
4. from other sources
a. Noun/verb analysis:
a. Nouns and noun phrases in the text indicate classes or attributes of classes.
b. Verbs and verb phrases indicate responsibilities or operations of a class.
Procedure:
◦ The first step in noun/verb analysis is to collect as much relevant information as possible.
◦ Suitable sources of information are
◦ the requirements model;
◦ the use case model;
◦ the project glossary;
◦ anything else (architecture, vision documents, etc.).
◦ After collecting the documentation, analyze it in a very simple way by highlighting the
following:
◦ nouns - for example, flight;
◦ noun phrases - for example, flight number;
◦ verbs - for example, allocate;
◦ verb phrases - for example, verify credit card.
b. By using CRC analysis
• CRC Stands for class, responsibilities, and collaborators.
• It is a brainstorming technique.
• It captures on sticky notes the important things in the problem domain.

CRC analysis procedure:


◦ It always be used in conjunction with noun/verb analysis
◦ It is a two-phase activity.
Phase 1: Brainstorm - gather the information
◦ The participants are
◦ OO analysts,
◦ stakeholders, and
◦ Domain experts.
◦ A facilitator
◦ The procedure is as follows.
◦ Explain that this is a true brainstorm:
◦ All ideas are accepted as good ideas.
◦ Ideas are recorded but not debated - never argue about
something.
◦ Just write it down and then move on.
◦ Everything will be analyzed later.

32
15
◦ Ask the team members to name the "things" that operate in their
business domain - for example, customer, product:
◦ Write each thing on a sticky note - it is a candidate class, or attribute of
a class.
◦ Stick the note on a wall or whiteboard.
◦ Ask the team to state responsibilities that those things might have record
these in the responsibilities compartment of the note.
◦ Working with the team, try to identify classes that might work together:
◦ To identify classes
◦ Rearrange the them
◦ draw lines between them
Phase 2: Analyze information
◦ The participants are OO analysts and domain experts.
◦ How do you decide which sticky notes should ·become classes and which should
become attributes?
◦ Analysis classes must represent a crisp abstraction in the problem domain.
◦ If a note logically seems to be a part of another note, this is a good indication that it
represents an attribute.
◦ If a note doesn't seem to be particularly important or has very little interesting
behavior, see if it can be made an attribute of another class.
◦ If in doubt about a note just make it a class.
We can always refine the model later
c. Finding classes by using the RUP stereotypes:
◦ According to RUP, it helps to identify three distinct types of analysis class during analysis
activity.
1. «boundary»,
2. «control», and
3. «entity» classes.
◦ A useful technique comes from RUP in the form of RUP stereotypes.
◦ It is an optional technique.
◦ Use it as a complement the core noun/verb and CRC card analysis techniques.
1. Finding «boundary» classes
a. It exist on the boundary of the system and communicate with external actors.
b. According to RUP there are three types of «boundary» class – Next slide
c. Each communication between an actor and a use case in the model must be
enabled by some object in a system.
d. These objects are instances of boundary classes.

Here the classes are classified as follows:


• user interface classes –
o classes that interface between the system and humans;
• system interface classes –
o classes that interface with other systems
32
16
• Device interface classes –
o classes that interface with external devices such as sensors.
Boundary class is indicated by considering what the actor represents. Analysis classes only have key
attributes and very high-level responsibilities. «boundary» class represents a GUI.


2. Finding «control» classes
a. These classes are controllers.
b. It coordinate system behavior that corresponds to one or more use cases.
c. Find control classes by considering the behavior of the system (Use cases).
d. If a controller class has a very complicated behavior then
e. break it down into two or more simpler controllers.
Case study:
System: Designing a course registration
Control class: CourseRegistrationController - that coordinates the whole process.
such a class has a complex behaviour
The CourseRegistrationController might be decomposed into
Registrar, CourseManager, and PersonnelManager classes
3. Finding «entity» classes
• These classes model information about something.
• It has simple behavior that getting and setting values.
• Classes that represent persistent information. Ex: addresses, People (Also
called Entity classes)
• Entity classes Characteristics are as follows
i. Cut across many use cases;
ii. are manipulated by control classes;
iii. provide information to, and accept information from, boundary classes;
iv. represent key things managed by the system (e.g., Customer);
v. are often persistent.
• Entity classes express the logical data structure of the system
d. Finding classes from other sources
• Like others it is also a worthy.
• Physical objects such as Ex: aircraft, people, and hotels may all indicate
classes.
• Paperwork is another rich source of classes. Ex: invoices, orders, and
bankbooks
• Known interfaces to the outside world Ex: screens, keyboards, peripherals,
and other systems
• Conceptual entities - crucial to the operation of the business. Ex: reward card
e. Relationship
• Relationships are semantic (meaningful) connections between modeling
element.
• Few types of relationships
32
17
i. between actors and use cases (association);
ii. between use cases and use cases (generalization, «include», «extend»);
iii. between actors and actors (generalization).
Link:

• A link is a semantic connection between two objects.


• It allows messages to be sent from one object to the other

f. Object Diagrams
• It shows objects and their relationships.
• It derived from the class diagrams. So it depends on class diagram.
• Object diagram is an instance of a class daigram

UML 2 specification allows three different modeling idioms


a. all crosses are suppressed;
b. bidirectional associations have no arrows;
c. unidirectional associations have a single arrow.
g. Associations:
• Associations are relationships between classes.
• Links connect objects.
• Associations connect classes.
• Objects are instances of classes,
• Links are instances of associations.

32
18
Association: Multiplicity

Case Study : Multiplicity:


◦ a Company can have exactly seven employees;
◦ a Person can be employed by exactly one Company (i.e., in this model a Person can't have
more than one job at a time);
◦ a BankAccount can have exactly one owner;
◦ a BankAccount can have one or many operators;
◦ a Person may have zero to many BankAccounts;
◦ a Person may operate zero to many BankAccounts.

32
19
Note:
a. There to be a link between two objects, there must be an association between
the classes of those objects.
b. Links depend on associations

Example: Class Diagram to Object Diagram


Case Study:
Let us consider the following situation and draw an object diagram from the class diagram to
the situation of “ e custo er placed the order”

Dependencies:

◦ It indicates a relationship between two or more model elements.


◦ Use dependencies to model relationships between classifiers where one classifier depends on
the other.

◦ UML 2 specifies three basic types of dependency,

32
20

Type of Stereotypes or Types


Dependencies
Usage ◦ «use»:client makes use of the supplier
◦ «call»: It is between operations
◦ «parameter»:The supplier is a parameter of the client operation
◦ «send»:The client is an operation that sends the supplier
◦ «instantiate»The client is an instance of the supplier.
Abstraction ◦ «trace»: supplier and the client represent the same concept but are in different
models.
◦ «substitute»: the client may be substituted for the supplier at runtime.
◦ «refine» : used between elements in the same model.
◦ «derive»: thing can be derived in some way from some other thing.
Permission ◦ «access»: It is between packages.
◦ «import»: similar to «access»
◦ «permit»: Visibility based accesing

Generalization – Class Generalization


◦ Generalization applies to all classifiers. Generalization applied to
◦ use cases and
◦ actors, and
◦ classes

32
21
Polymorphism:
◦ Polymorphism means "many forms.
◦ Polymorphic operations have many implementations.
◦ Example:
◦ Shape::draw() and
◦ Shape::getArea().
◦ Encapsulation, inheritance, and polymorphism are the "three pillars" of OO.

◦ Let Canvas is a class.

32
22
32
23
ects a e a i eti e e are e icit created and can e ist or a eriod
o ti e t at traditiona as een t e duration o t e rocess in ic t e ere
created i er or a data ase can ro ide su ort or o ects a in a on er
i e ine on er t an t e duration o t e rocess or ic t e ere created ro a
an ua e ers ecti e t is c aracteristic is ca ed

n o ect can ersist e ond a ication session oundaries durin ic


t e o ect is stored in a i e or a data ase in so e i e or data ase or e o ect
can e retrie ed in anot er a ication session and i a e t e sa e state and
re ations i to ot er o ects as at t e ti e it as sa ed e i eti e o an o ect
can e e icit ter inated

s a c ass an o ect c ass is an o ect a c ass e on s to a


c ass ca ed a eta c ass or a c ass o c asses
or e a e c asses ust e i e ented in so e a er a s
it dictionaries or et ods instances and arents and et ods to
er or a t e or o ein a c ass is can e dec ared in a c ass
na ed
e eta c ass a so can ro ide ser ices to a ication ro ra s
suc as returnin a set o a et ods instances or arents or re ie
or e en odi ication

37
24
UNIT -III

1. Packages
◦ A organize model elements (including other packages) and diagrams into
pa groups.
ck ◦ It is a container.
ag ◦ Each package has its own namespace – All names must be unique.
e ◦ It provides a namespace for its members.
is ◦ Elements inside a package can be given a visibility.
th ◦ These indicates whether they are visible to clients of the package.
e Notation:
ge ◦ The package icon is a folder, and
ne ◦ the package name may be shown on the tab
ra
l
p
ur
p ◦ It can be used
os ◦ To provide an encapsulated namespace within which
e all names must beunique;
U ◦ To group semantically related elements;
M ◦ To define a "semantic boundary" in the model;
L ◦ To provide units for parallel working and configuration management.
m
ec
ha
ni
s
m
.
◦ pa
ck
ag
e
is
a
lo
gi
ca
l
gr
o
u
pi
n
g
m
ec
ha
ni
s
m
.
◦ T
o
◦ This is useful when
there is
◦ A lot of nesting, or
◦ Complex nesting, that be confused to show with embedding.
◦ Elements in the Users package can access all elements in the
Library package byusing unqualified names.
◦ But elements in library must use the qualified names i.e
Users::Librarian & Users::Borrower to access the elements in the users package

Syntax:

Package Dependencies:

◦ Any package that has a dependency relationship with the


Membership package will beable to see the public elements of that
package (ClubMembership, Benefits, etc.)
◦ But will not be able to see
the private element
JoiningRules.

Nested

Packages Package dependency types:


e static structure of a system.
2. Use ◦ Use case realizations:
case ◦ It shows how instances of the analysis classes
Real interact to the systemfunctionality.
izati ◦ It is the dynamic view of the system
on
• U
se
ca
se
re
al
iz
at
io
n
is
fu
n
da
m
en
ta
ll
y
a
pr ◦ The main goals for use case realization in analysis are as follows
oc ◦ Find out which analysis classes interact to realize the behavior
es specified by a usecase.
s ◦ Find out what messages instances of these classes need to
of send to each other torealize the specified behavior.
re ◦ Analysis classes
fi ◦ Key operations
◦ Key attributes
ne
◦ Important relationships between analysis classes
m
◦ Update the following models with the information get from use case
en realization.
t. ◦ Use case model,
◦ A ◦ Requirements model, and
na ◦ Analysis classes
ly Usecase Realization Elements:
si
s Let the use case realizations be an implicit part of the backplane of the model.
cl
as
se
s
m The main elements of usecase realization are as follows
o 1. Analysis class Diagram
de 2. Interaction Diagrams
l 3. Special Requirements
th
4. U nication diagrams,
s ◦ Interaction overview diagrams, and
e ◦ Timing diagrams.
c ◦ OO modeling is an iterative process.
a
s 3. Interactions:
e ◦ It is unit of behavior of a classifier.
R ◦ This classifier, known as the context classifier.
e ◦ It provides the context for the interaction.
f ◦ An interaction may used as
i ◦ Temporary or Global variable
n ◦ In use case realization, the context classifier is a use case.
e ◦ The key elements in interaction diagrams are lifelines and messages.
m Lifelines:
e ◦ A lifeline represents a single participant in an interaction.
n ◦ It represents how an instance of a specific classifier participates in the
t interaction.
s ◦ Each lifeline has
◦ An optional name,
◦ A type, and
◦ An optional selector

Syntax:
◦ Name - To the lifeline within the interaction.
◦ Type - The name of the classifier of which the lifeline represents an
instance.
◦ Selector –
◦ A Boolean condition that may be used to select a single
instance that satisfiesthe condition.
◦ If there is no selector, a lifeline refers to an arbitrary instance of the
classifier.
◦ Selectors are only valid

Messages:

◦ r
a
m
s
,
◦ C
o
m
m
u
◦ I type has a (multiplicity > 1) so that there are many instancesfrom
f which to choose.
t ◦ The selector selects an instance of Account that has an id of "1234".
h ◦ Lifelines are drawn with the same icon and
e ◦ Have a vertical dashed "tail" when they are used in sequence diagrams.
◦ Types of messages are
◦ Synchronous,
◦ Asynchronous, and
◦ Return messages
◦ synchronous message:
◦ The sender waits for the receiver to finish executing the requested operation.
◦ Asynchronous message:
◦ The sender does not wait but continues to the next step
◦ Return Messages: Receiver sends response to the senders call

Loops representations:
Parameters

◦ To supply different values to the interaction.


◦ Let FindStudent( ... ) and FindCourse( ... ), two parameterized interactions.

◦ Pass specific values in to the interactions as parameters.


◦ The two interaction occurrences have return values that are assigned to the temporary
variables theStudent and theCourse.
◦ These temporary variables exist in the scope of the sequence diagram

Gates:

◦ Gates are the inputs and outputs of interactions.


◦ A gate is a point on the sequence diagram frame.
◦ Use gates when an interaction to be triggered by a lifeline.
◦ That is not part of the interaction
◦ This point connects a message outside the frame to a message inside the frame.
◦ Both these messages must have a matching signature.
◦ New sequence diagrams with gates are as follows
◦ FindStudent and FindCourse have explicit inputs and outputs.
Continuation
◦ Continuations provide a way to connect different interactions.
◦ Ssyntax
◦ It is drawn as a label inside a rounded rectangle
◦ Especially one interaction finishes, leaving its lifelines in a specific state, and other
interactions may pick up at that point and continue.
◦ Continuations allow an interaction fragment
◦ To indicate that its flow terminates in such a way that it can be picked up and
continued by another interaction fragment.
◦ When (Continuation = = first item) – indicates the fragment is continuing from
previous fragment.
◦ When (Continuation = = Last item) – indicates the point at which fragment finishes.
◦ Note: Communication diagrams emphasize the structural aspects of an interaction.

4. Activity Diagram:
◦ Activity diagrams are OO flowcharts.
◦ Activity refer to features of its context
◦ To model a process as an activity that consists of a collection of nodes connected by
edges.
◦ In UML 1, activity diagrams were special cases of state machines.
◦ Every state had an entry action.
◦ It specified some process or function that occurred when the state was entered.
◦ In UML 2, activity diagrams have completely new semantics based on Petri Nets.
◦ It has two advantages
◦ The Petri Net formalism provides greater flexibility in modeling different
types of flow.
◦ It shows a clear distinction between activity diagrams and state machines.
◦ Activities are typically attached to
◦ use cases;
◦ classes;
◦ interfaces;
◦ components;
◦ collaborations;
◦ operations.
◦ Uses:
◦ To model business processes and workflows.
◦ To flowchart operations.
◦ A good activity diagram is focused on system's dynamic behavior.
◦ Activity diagrams used in many UP workflows.
◦ Activity diagrams are most commonly used in the following ways.
◦ In the Analysis workflow:
◦ To model the flow in a use case in a graphical way.
◦ To model the flow between use cases.
◦ In Design:
◦ To model the details of an operation;
◦ To model the details of an algorithm.
◦ In Business modeling:
◦ To model a business process.

Activities:
◦ Activities are networks of nodes connected by edges.
◦ There are three categories of node:
◦ Action nodes
◦ Control nodes
◦ Object nodes
◦ Edges represent flow through the activity.
◦ There are two categories of edge:
◦ Control flows
◦ Object flows
Nodes

Action nodes Control nodes Object nodes

Represent discrete
units of work that are Control the flow Represent objects
atomic within the through the activity; used in the activity.
activity;

Actions

control flows object flows

Represent the flow Represent the flow of


of control though objects through the
the activity; activity.

Action Nodes:
◦ Action nodes execute when
◦ There is a token simultaneously on each of their input edges AND
◦ The input tokens satisfy all of the action node local preconditions.
Action Nodes Types:

Call Action Node:


This type of node can invoke an activity; a behavior; an operation
Time Event Action Node:

Control nodes:
◦ It manage the flow of control within an activity

Case studies:
5. Advanced Activity Diagrams

Connectors:
It can break long edges that are hard to follow and untangle edges that cross.

Exception Handling
◦ Handle errors through a mechanism called exception handling.
◦ If an error is detected in a protected piece of code,
◦ An exception object is created and flow of control jumps to an exception
handler.
◦ Exception handler processes the exception object.
◦ The exception object contains error information.
◦ It is used by the exception handler.
◦ The exception handler may terminate the application or try to make a recovery.
◦ The information in the exception object is often saved to an error log.
Syntax:
◦ Exception handling in activity diagrams by using
◦ Exception pins,
◦ Protected nodes, and
◦ Exception handlers
Note:
Exception handling is often a design issue rather than an analysis issue
◦ Exception Pins
◦ It represents the output of an exception object.
◦ Syntax: A small equilateral triangle
◦ Exception Handlers
◦ It process exceptions generated by a node.
◦ Protected Nodes
◦ When a node has an associated exception handler, it is known as a protected
node

Case study 1:

Swimlane based Sales Process by considering control nodes, object nodes and action nodes
with the flow edges
Description:

The token originates at the initial node. A customer places an order, which is received by the
company's sales department. The first decision is to either accept or reject the order. The two
guard conditions, [rejected] and [accepted], are mutually exclusive. If the token takes the
[rejected] branch, it immediately reaches the merge and appears on its output edge. After the
order is closed, the token reaches the activity final node, which immediately ends the process
instance. If the token takes the [accepted] branch, the order is filled. When the token reaches
the fork, two tokens are generated. The upper token causes the order to be shipped, and the
lower token stimulates a series of actions to invoice the customer and eventually receive
payment.
Case study 2:
Manufacture sales process

Control flows to the first activity, where the customer requests a quote (Request quote).
Control remains in an activity until that activity is completed; then the control follows the
outgoing arrow. When the request for the quote is complete, the Manufacturer generates a quote
(Generate quote). Then the Customer reviews the quote (Review quote).
The next construct is a branch, represented by a diamond. Each outgoing arrow from a
branch has a guard. The guard represents a condition that must be true in order for control to
flow along that path. Guards are written as short condition descriptions enclosed in brackets.
After the customer finishes reviewing the quote in Figure, if it is unacceptable the process
reaches a final state and terminates. A final state is represented with a target (the bull's-eye). If
the quote is acceptable, then the Customer places an order (Place order). The Manufacturer
enters (Enter order), produces (Produce order), and ships the order (Ship order).
At a fork, control splits into multiple concurrent threads. The notation is a solid bar with
one incoming arrow and multiple outgoing arrows. After the order ships in Figure, control
reaches a fork and splits into two threads. The Customer receives the order (Receive order). In
parallel to the Customer receiving the order, the Manufacturer generates an invoice (Generate
invoice), and then the customer receives the invoice (Receive invoice). The order of activities
between threads is not constrained. Thus, the Customer may receive the order before or after
the Manufacturer generates the invoice, or even after the Customer receives the invoice.
At a join, multiple threads merge into a single thread. The notation is a solid bar with
multiple incoming arrows and one outgoing arrow. In Figure, after the customer receives the
order and the invoice, then the customer will pay (Pay). All incoming threads must complete
before control continues along the outgoing arrow.
Finally, in Figure, the Customer pays, the Manufacturer records the payment (Record
payment), and then a final state is reached. Notice that an activity diagram may have multiple
final states. However, there can only be one initial state.
There are at least two uses for activity diagrams in the context of database design.
Activity diagrams can specify the interactions of classes in a database schema. Class diagrams
capture structure, and activity diagrams capture behavior. The two types of diagrams can
present complementary aspects of the same system. For example, one can easily imagine
that Figure illustrates the usage of classes named Quote, Order, Invoice, and Payment. Another
use for activity diagrams in the context of database design is to illustrate processes surrounding
the database. For example, database life cycles can be illustrated using activity .
UNIT -IV
1. Design Classes

Design Workflow and Artifacts:


◦ After Architectural design, the next activities are
◦ Design a class and
◦ Design a use case
◦ These two activities occur concurrently and iteratively.

Difference between Analysis Class and Design Class


Analysis Class:
◦ Analysis is about modelling what the system should do.
◦ Capture the required behaviour of the system.
◦ An operation here is a high-level logical specification of a piece of functionality
offered by a class.
◦ Each analysis class operation is refined into one or more detailed and fully specified
operations that can be implemented as source code.
Design Class:
◦ According to UP perspective, Design class is a good basis for creating source code
◦ A Design classes come from the problem domain and the solution domain.
◦ how that behaviour may be implemented
◦ Specify exactly how each class will fulfil its responsibilities.
◦ Design classes that are small, self-contained, cohesive units.
◦ One high-level analysis operation may actually resolve into one or more implementable
design operations.
What are design classes?
◦ Design classes are classes whose specifications have been completed to such a degree that
they can be implemented.
◦ Design is about modeling how that behavior may be implemented.
◦ Design classes come from two sources i.e
◦ the problem domain and
◦ the solution domain.
Problem Domain:
◦ In analysis, the source of classes is the problem domain.
◦ The set of requirements that describes the problem are trying to solve.
◦ A refinement of analysis classes.
◦ One analysis class may become zero, one, or more design classes;
◦ A «trace» relationship between an analysis class and the one or more design classes
that describe its implementation.
Solution domain:
◦ - utility class libraries;
◦ - middleware;
◦ - GUI libraries;
◦ - reusable components;
◦ - implementation-specific details.
Analysis Class
◦ Analysis is about modeling what the system should do.
◦ Why may an analysis class refine into one or more design classes or interfaces?
Ans: an analysis class is specified at a very high level of abstraction.
◦ When you move this class into design, you must fully specify all of the operations and
attributes
Anatomy of a design class:
◦ With analysis classes, trying to capture the required behavior of the system without worrying
about how this behavior is going to be implemented.
◦ With design classes, to specify exactly how each class will fulfill its responsibilities.
◦ To do this, must do the following:
◦ Complete the set of attributes and fully specify them including
◦ Name,
◦ Type,
◦ Visibility, and
◦ ( optionally) a default value;
◦ Complete the set of operations and fully specify them including
◦ Name,
◦ Parameter list, and
◦ Return type.

2. Refining Analysis Relationships


◦ Analysis associations refined to design relationships that are directly implementable in the
target OO language.
◦ To design associations involves several procedures:
◦ Refining associations to aggregation or composition relationships where appropriate;
◦ implementing one-to-many associations;
◦ implementing many-to-one associations;
◦ implementing many-to-many associations;
◦ implementing bidirectional associations;
◦ implementing association classes.
◦ All design associations must have
◦ navigability;
◦ multiplicity on both ends.
◦ All design associations should have an association name, or a role name on at least the target
end.
Aggregation and Composition:
◦ In design, refine an association relationship into an aggregation relationship or a stronger
form of aggregation known as the composition.
◦ Aggregation –
◦ This is a loose type of relationship between objects.
◦ Type of whole-part relationship.
◦ In a whole-part relationship, one object (the whole) uses the services of another
object (the part).
◦ Ex: A computer and its peripherals.

◦ A Computer may be attached to 0 or more Printers;


◦ At any one point in time, a Printer is connected to 0 or 1 Computer;
◦ Over time, many Computers may use a given Printer;
◦ The Printer may exist even if there are no attached Computers;
◦ The Printer is, in a very real sense, independent of the Computer.
Aggregation is transitive.

◦ Transitivity means that if C is part of B and B is part of A, then C is also part of A.


Aggregation is asymmetric:

◦ An object can never be part of itself.

Association is symmetric –

◦ An object associated to itself.

Composition –
◦ This is a very strong type of relationship between objects
◦ Ex: A tree and its leaves.
◦ Composition is a stronger form of aggregation and has similar semantics.
◦ It is a whole-part relationship and is both transitive and asymmetric.
◦ In composition, the parts have no independent life outside of the whole.
◦ In composition, each part belongs to at most one and only one whole.
◦ In aggregation a part may be shared between wholes.
◦ If the composite is destroyed, it must either destroy all its parts, or give responsibility
for them over to some other object.
◦ The composite has sole responsibility for the life cycle and disposition of its parts,

How to refine Analysis?


◦ In analysis,
◦ Use simple associations without really considering thesemantics of the relationship.
◦ In design,
◦ Use as specific as possible.
◦ Ex: Refine associations into one of the aggregation or composition relationships.
◦ Add multiplicities and role names to the association if they are absent;
◦ Decide which side of the association is the whole, and which is the part;
◦ Look at the multiplicity of the whole side-if it is 0 .. 1 or exactly 1, use composition;
otherwise, use aggregation;
◦ Add navigability from the whole to the part-design associations must be
unidirectional.
Reified relationships:
◦ Some relationships are pure analysis artifacts and must be made implementable by the
process of reification.
◦ Many-to-many associations
◦ Bidirectional associations
◦ Association classes
Many-to-many associations:
◦ Reify the relationship into a class;
◦ Decide which side is the whole and use aggregation, composition, or association as
appropriate.

Bidirectional associations:
Replace with a unidirectional aggregation or composition from whole to part, and a unidirectional
association or dependency from part to whole.

Association classes:
◦ Decide which side is the whole and which is the part;
◦ Replace with a class (usually with the same name as the association class);
◦ Add a constraint in a note to indicate that objects on each end of the reified relationship must
form a unique pair.
3. Interfaces:
◦ An interface specifies a named set of public features.
◦ Objectives:
◦ To separate the specification of functionality from its implementation by a classifier
or a class or a subsystem.

Components:
◦ A component is a modular and replaceable part of a system that encapsulates its content.
◦ Components are structured classifiers.
◦ It has
◦ Attributes and
◦ Operations and
◦ Participate in association and generalization relationships
◦ Components can represent:
◦ a physical entity (such as an EJB: Enterprise JavaBean component);
◦ a logical entity (such as a subsystem).
◦ Component-based development is about constructing software from plug-in parts.

◦ White box View:


◦ It exposes the internal details of the component.
◦ It can show
◦ Provided Interfaces,
◦ required interfaces,
◦ realizations, or
◦ associated artifacts
Components are often shown simply as black boxes with their
• supplied and
• required interfaces attached to them

◦ The Part ” component provides two interfaces of type IParty and !Address.
◦ These interfaces are represented as balls.
◦ The MailinglistManager component requires two interfaces of type! A d d r e s s
andIPostBox.
◦ These are represented as sockets.
◦ There is an assembly connector between the Party component and the
MailinglistManager component. This shows that the MailinglistManager is
communicating with the Party component via the provided! Address interface.
◦ In this model the Party component is acting as a fasade to decouple the
MailinglistManager component from the details of the Address component.

4. Timing Diagram:
◦ Timing diagrams model timing constraints.
◦ Use timing diagrams to show how an object changes state over time.
◦ t = o: The :Siren is in the state Off.
◦ t = 10: There is an intruder event,
:Siren transitions to the state Sounding lntruderAlarm.
◦ t = 25: The intruder alarm can sound for no more than 15 minutes because of local
regulations on alarms.
◦ The :Siren transitions to the state Resting.
◦ It must stay in this state for 30 minutes
(again, because of local laws).
◦ t = 35: There is an intruder event but the
◦ :Siren is Resting so it can't sound.
◦ t = 55: The :Siren transitions back to the state Off.
◦ t = 65: There is another intruder event.
◦ The :Siren transitions from the state Off to the state SoundinglntruderAlarm.
◦ t = 75: There is a fire event.
◦ The :Siren transitions from the state SoundinglntruderAlarm to the state
SoundingFireAlarm.
◦ t = 100: The interaction finishes, leaving the
◦ :Siren in the state SoundingFireAlarm.
One more way of representation of timing diagram is
5. State Machines: State Diagrams/ Behavioral
◦ States are rounded rectangles.
◦ The initial start State (filled circle) and stop state (bull's eye).
◦ Transitions indicate possible paths between states and are modeled by an arrow.
◦ Events are written over the transitions that they trigger.

◦ State machines model the dynamic behavior of a reactive object.


◦ State machine diagrams contain a single state machine for a single reactive object.
◦ There are two types of state machines:
◦ Behavioral state machines:
◦ Model the behavior of a context classifier;
◦ States in behavioral state machines may contain zero or more actions and
activities;
◦ Protocol state machines:
◦ Model the protocol of a context classifier;
◦ States in protocol state machines have no actions or activities.

◦ Actions
◦ Pieces of work that are instantaneous and uninterruptible:
◦ Occur within a state, Associated with an internal transition;
◦ Occur outside a state, Associated with an external transition.
◦ Activities
◦ Pieces of work that take a finite time (Predetermined) and are interruptible:
◦ Occur only within a state.
◦ State
◦ A semantically significant condition of an object.
◦ Object state is determined by:
◦ object attribute values;
◦ relationships to other objects;
◦ activities the object is performing.
State
Definition
◦ It is a condition or situation during the life of an object during which it satisfies some
condition, performs some activity, or waits for some event.
◦ The state of an object varies over time.
◦ but at any particular point it is determined by
◦ the object attribute values;
◦ the relationships it has to other objects;
◦ the activities it is performing.
Syntax

6. Implementation workflow
◦ The implementation workflow is the main focus of the Construction phase.
◦ It begins in earnest in the Elaboration phase.
◦ Implementation is about transforming a design model into executable code.
◦ The main focus of this is to produce executable code.
◦ There are two cases to explicit implementation modeling activity,
◦ If intend to generate code directly from the model,
◦ It will need to specify details such as source files and components (unless you
take the modeling tool defaults).
◦ If doing a component-based development (CBD) to reuse components,
◦ The allocation of design classes and interfaces to components
becomes a strategic issue.
◦ Model this first, rather than leave it to the individual programmer.
◦ The implementation model is part of the design model.

7. Deployment – Diagram, artifacts

◦ It falls under structural diagramming family .


◦ It describes an aspect of the system itself – Describes the physical deployment of
information generated by the software program on hardware components.
◦ The main components of deployment diagram are
◦ Nodes – Three Dimensional Boxes, Basic S/w or H/W elements.
◦ Lines – Relationship between the nodes.
◦ Components –S/W Element - A rectangle with two tabs.
◦ Node as container - A node that contains another node inside of it.
◦ Artifact – A Product developed by the software – Symbolized by a rectangle +
Name + <<Artifact>>
◦ Stereotype – A device contained within a node then presents at the top of the
node with <<stereotype>>
◦ Deployment diagram applications
◦ Shows which software elements are deployed by which hardware elements.
◦ Illustrate the runtime processing for hardware.
◦ Provide a view of the hardware s ste ’s topology.

Example:
◦ The deployment diagram maps the software architecture to the hardware architecture.
◦ Two forms of deployment diagram.
◦ Descriptor form: deployment diagram - artifacts deployed on nodes.
◦ Instance form: deployment diagram - artifact instances deployed on node instances.
◦ Descriptor form –
◦ Contains nodes, relationships between nodes, and artifacts.
◦ A node represents a type of hardware (such as a PC).
◦ Similarly, an artifact represents a type of physical software artifact such as a Java
JAR file.
◦ Instance form –
◦ Contains node instances, relationships between node instances, and artifact instances.
◦ A node instance represents a specific, identifiable piece of hardware (such as Jim's
PC).
◦ An artifact instance represents a specific instance of a type of software, such as the
particular copy of FrameMaker (www.adobe.com) used to write this, or a particular
JAR file.
◦ If you don't know (or don't care about) the details of specific instances, you can use
anonymous instances.
◦ The construction of the deployment diagram is therefore a two-step process.
◦ In the design workflow, focus mainly on node or node instances and connections.
◦ In the implementation workflow, focus on assigning artifact instances to node
instances (instance form), or artifacts to nodes (descriptor form).
◦ A node represents a type of computational resource.
◦ Nodes can be nested in nodes.

◦ Two standard stereotypes


◦ «device» the node represents a type of physical device such as a PC or a Sun Fire
server.
◦ «execution environment» - the node represents a type of execution
environment for software such as an Apache web server or the JBoss EJB
(Enterprise JavaBeans) container.
◦ An artefact represents the specification of a real world thing such as a file.
◦ Artifacts are deployed on nodes.
◦ Ex:
◦ Source files;
◦ executable files;
◦ scripts;
◦ database tables;
◦ documents;
◦ outputs of the development process, e.g., a UML model
Case Studies:

1. Design and illustrate the process of a Phone call system by considering various
states.

Refer: https://circle.visual-paradigm.com/phone-call/

2. Apply collobaration diagram steps to show the process of ATM Withdrawal.


Collaboration Diagram
Question Bank for Slow Learners with BTL
Levels

102
V. R. Siddhartha Engineering College
Department of Computer Science & Engineering
Question Bank for Slow Learners with BTL Levels

Class B Tech Regulation VR20


Subject Code 20CS5404F Year & Semester III Year & V Semester
Title of the Subject OBJECT ORIENTED ANALYSIS AND DESIGN

CO BTL
UNIT -1
1. Write a short note on birth of UML and its objects. CO1 1
2. Explain in detail about UML Building blocks. CO1 1
3. Explain in detail about UML Common Mechanisms and architecture. CO1 1
4. Draw and discuss about UML system architecture views and their associations. CO1 2
5. Illustrate UP iterative and incremental process and its structure in detail with a neat CO1 2
diagram
6. Write a short note on MDP. CO1 1
7. Illustrate the functioning of a Mobile Banking App by drawing an advanced use CO2 3
case diagram.
8. What is meant by Unified Process? CO1 1
9. Differentiate between UP and RUP. CO2 2
10. Analyse the function of building blocks of UML in detail. CO2 2
11. Apply UML approach to shows the functioning of ATM system using Class CO2 3
diagram and elaborate its requirements in detail.
12. Illustrate the role of 4+1 architecture in Unified modelling language. CO1 2
13. Apply and elaborate UML approach to analyse and design Library application CO2 3
system using usecase diagram.
14. Illustrate in detail about the stages of UML Birth and History of UP. CO1 2

UNIT -II
15. Illustrate the probable attributes and operations that will be used to model the class CO3 3
diagram and usecase daigram for the library management system.
16. How to find the classes by using CRC analysis ? Explain in detail about its CO2 3
procedure.
17. How to apply Noun/ verb analysis for identifying the classes in the process of
constructing a class diagram for an E- Commerce application? Elaborate in detail CO3 3
with a neat diagram
18. Elaborate the components in the notations of class and object with an example. CO1 2
19. Elaborate different relationships and their stereotypes by considering suitable CO1 2
examples for showing the semantic connections between things.
20. Analyse and summarize the process of CRC analysis to find the classes. CO2 2
21. Mention the workflow artifacts. CO1 1
22. List out various types of relationships in UML CO1 1
23. Summarize in detail about Generalization and Polymorphism functions those are CO2 2
considering as main pillars of OO by considering canvas as a main class.
24. llustrate the process of finding the classes using RUP sterotypes with a case study. CO2 3
25. Design and illustrate the suitable objects and their association to each other for the CO3 2
ATM system.
26. Write the main aim of analysis workflow. CO1 1

103
27. Draw a class notation with all the features. CO1 2

UNIT _III
28. What is a package? CO1 1
29. Explain about interaction diagrams in detail. CO2 2
30. Draw the sequence diagram for ATM application. CO3 3
31. Draw the activity diagram for ATM Application. CO3 3
32. Explain about advanced use case realization in detail. CO2 2
33. Differentiate between call node & control node CO3 3
34. What are design classes? CO1 1
35. Summarize different notations of nested packages. Also elaborate the types of CO2 2
package dependencies relationships.
36. Draw and discuss about the functioning of Manufacturer sales process using CO3 3
interaction diagram.
37. Illustrate the process advanced usecase realizations in detail. CO3 3
38. Illustrate the responsibilities of different package dependencies. CO3 3
39. Illustrate the functioning of various types of action nodes and control nodes with CO3 3
the notations.
UNIT -IV
CO3 3
40. How Analysis Classes defer from Design Classes? Discuss in detail by showing the
extended notations.
CO3 3
41. How to refine analysis Relationship? Illustrate the concept in detail with examples.
42. Is aggregation satisfies the transitive rule?
CO2 2
43. Structure Components with white box view
CO2 2
44. What are the major factors of projects failure?
CO1 1
45. Why Analysis associations could be refined? In design how could refine an
CO1 1
association relationships? Elaborate.
46. Analyse and Design the Real Estate system application connections with the UML
CO4 3
Deployment diagram by discussing the objectives of the associated components and
their notations.
47. Write a short note on the following concepts
CO2 2
a. Interfaces Components Components with white box view
48. Use three different types of timing diagrams view to show how an object changes
CO4 3
state over time in Siran Alarm System Where considered the Intruder Detection and
Fire Detections are as the constraints.
49. Illustrate the process of Bank loan using State diagram including the objectives of
CO3 3
its components.
50. Write a short note on implementation workflow with neat diagrams
CO2 2
51. Analyse and Design the Real Estate system application connections with the UML
CO4 3
Deployment diagram by discussing the objectives of the associated components and
their notations.
CO1 1
52. What are the terms and concepts of state machine?
CO1 1
53. What are the major factors of projects failure?
CO3 3
54. Analyse and Design the deployment diagram for ATM Applications.
CO2 2
55. Explain about interface and components with an example.

104
Question Bank for Fast Learners with BTL
Levels

105
V. R. Siddhartha Engineering College
Department of Computer Science & Engineering
Question Bank for Fast Learners with BTL Levels

Class B Tech Regulation VR20


Subject Code 20CS5404F Year & Semester III Year & V Semester
Title of the Subject OBJECT ORIENTED ANALYSIS AND DESIGN

CO BTL
UNIT -1
56. Write a short note on birth of UML and its objects. CO1 1
57. Explain in detail about UML Building blocks. CO1 1
58. Explain in detail about UML Common Mechanisms and architecture. CO1 1
59. Draw and discuss about UML system architecture views and their CO1 2
associations.
60. Illustrate UP iterative and incremental process and its structure in detail CO1 2
with a neat diagram
61. Write a short note on MDP. CO1 1
62. Describe the functional and nonfunctional requirements for the case CO2 3
study automated teller machine (ATM).
63. Illustrate the functioning of a Mobile Banking App by drawing an CO2 2
advanced use case diagram.
64. Draw and discuss the process of E- Commerce Platform by using an CO2 2
advanced use cases concepts.
65. What is meant by Unified Process? CO1 1
66. Differentiate between UP and RUP. CO2 2
67. Describe the association and realization relationship. CO2 2
68. Analyse the function of building blocks of UML in detail. CO2 3
69. Apply UML approach to shows the functioning of ATM system using CO2 3
Class diagram and elaborate its requirements in detail.
70. Illustrate the role of 4+1 architecture in Unified modelling language. CO1 2
71. Apply and elaborate UML approach to analyse and design Library CO2 3
application system using usecase diagram.
72. Illustrate in detail about the stages of UML Birth and History of UP. CO1 2

UNIT -II

73. Illustrate the probable attributes and operations that will be used to model
the class diagram and usecase daigram for the library management CO3 3
system.
74. How to find the classes by using CRC analysis ? Explain in detail about
its procedure. CO2 3
75. How to apply Noun/ verb analysis for identifying the classes in the
process of constructing a class diagram for an E- Commerce application? CO3 3
Elaborate in detail with a neat diagram
CO1 1
76. List out the artifacts of a metamodel.
CO2 2
77. In which phase of a workflow the main work of analysis will begin?
CO1 1

106
78. Write the thumb rules of analysis model. CO1 2
79. Elaborate the components in the notations of class and object with an
example. CO1 2
80. Elaborate different relationships and their stereotypes by considering
suitable examples for showing the semantic connections between things. CO2 2
81. Analyse and summarize the process of CRC analysis to find the classes. CO1 1
82. Mention the workflow artifacts. CO2 2
83. How can utilise the subtypes of “ sa e” dependency. CO1 1
84. List out various types of relationships in UML CO3 3
85. Draw and illustrate the process of a class diagram for the following case
study. A school has exactly 50 employees. Each employee has a bank
account that can operated by have one or more operators. CO2 2
86. Summarize in detail about Generalization and Polymorphism functions
those are considering as main pillars of OO by considering canvas as a
main class. CO2 3
87. llustrate the process of finding the classes using RUP sterotypes with a
case study. CO3 2
88. Design and illustrate the suitable objects and their association to each
other for the ATM system. CO1 1
89. Write the main aim of analysis workflow. CO1 2
90. Draw a class notation with all the features. CO2 1
91. Mention the subtypes of Abstraction dependency relationship. CO2 2
92. Where can do apply Generalization?

UNIT _III
93. What is a package? CO1 1
94. Analyse and illustrate the users, actors and their behaviour must be CO3 3
depicted by showing a sequence diagram for the ATM system
application.
95. Explain about interaction diagrams in detail. CO2 2
96. A University conducts examinations and the results are announced. CO4 3
Identify a problem statement. Also analyse and draw an activity diagram
by considering the following requirements
a. Print the marks in the register number order semester wise for
each department
b. Print the Arrear list semester wise.
c. Prepare a Rank list for each department.
97. Draw the sequence diagram for ATM application. CO3 3
98. Draw the activity diagram for ATM Application. CO3 3
99. Explain about advanced use case realization in detail. CO2 2
100. Differentiate between call node & control node CO2 2
101. What are design classes? CO1 1
102. Summarize different notations of nested packages. Also elaborate the CO2 2
types of package dependencies relationships.
103. Draw and discuss about the functioning of Manufacturer sales process CO3 3
using interaction diagram.
104. Design and Elaborate the process of UML activity diagram for the Bank CO4 3
ATM system using different control nodes and action nodes.
105. Illustrate the process advanced usecase realizations in detail.
CO3 3

107
106. Design Swimlane based Activity diagram for Sales Process by applying CO4 3
the control nodes, object nodes and action nodes using different flow
edges.
107. Illustrate the responsibilities of different package dependencies. CO3 3
108. Illustrate the functioning of various types of action nodes and control CO3 3
nodes with the notations.

UNIT -IV
109. How Analysis Classes defer from Design Classes? Discuss in detail CO3 3
by showing the extended notations.
110. How to refine analysis Relationship? Illustrate the concept in detail CO3 3
with examples.
111. Is aggregation satisfies the transitive rule? CO2 2
112. Structure Components with white box view CO2 2
113. What are the major factors of projects failure? CO1 1
114. Why Analysis associations could be refined? In design how could CO1 1
refine an association relationships? Elaborate.
115. Analyse and Design the Real Estate system application connections CO4 3
with the UML Deployment diagram by discussing the objectives of the
associated components and their notations.
116. Write a short note on the following concepts CO2 2
a. Interfaces
b. Components
c. Components with white box view
117. Use three different types of timing diagrams view to show how an CO4 3
object changes state over time in Siran Alarm System Where considered
the Intruder Detection and Fire Detections are as the constraints.
118. Illustrate the process of Bank loan using State diagram including the CO3 3
objectives of its components.
119. Write a short note on implementation workflow with neat diagrams CO2 2
120. Analyse and Design the Real Estate system application connections CO4 3
with the UML Deployment diagram by discussing the objectives of the
associated components and their notations.
121. What are the terms and concepts of state machine? CO1 1
122. What are the major factors of projects failure? CO1 1
123. Analyse and Design the deployment diagram for ATM Applications. CO3 3
124. Explain about interface and components with an example. CO2 2

108

You might also like