DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE

THEORY COURSE FILE

CS3591 : COMPUTER NETWORKS
ACADEMIC YEAR: 2023-2024 (EVEN Semester)
CONTENTS
1. Institute V/M; Department V/M/PEO;PO/PSO statements
2. Course Syllabus
3.Concept map
4. Course Information Sheet with course objectives, course outcomes, PO/PSO Mapping,
Mapping-Justification, Gaps in Syllabus, Topic beyond syllabus/Contemporary topics,
Delivery methods, etc
5. Model Lesson plan
6. Student’s Name List
7. Time Table
8. Lecture notes (unit wise)
9. Sample PPT print out (Unit wise)
10. Unit wise Question bank
11. Unit wise Handout notes
12. University Question papers (Last 3 Years)
13. Internal Question papers with Answer key
14. Assignment (Minimum 3 with Multiple Topics)
15. Tutorial sheets-separate sheets (If applicable)
16. Gaps & plans for Add on Programs (Plan and Schedule)
17. Result Analysis, Remedial/Corrective action
18. Innovative Method Adopted- Description
19. Topics beyond syllabus-References
20. Course Outcomes Assessment
21. Log Book
Prepared by
Ms.G.Jini Mol
Assistant Professor/CSE
 DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE
COLLEGE VISION & MISSION STATEMENT
Vision
To incubate value based technical education and produce outstanding women graduate
to compete with the technological challenges with right attitude towards social
empowerment.
Mission
• To equip necessary resources and to establish sufficient infrastructure for a beneficial
process of learning that paves the way for making ideal technocrats.
• To educate and make the students efficient with necessary skills and to make them
industry ready engineers.
• To establish high-level learning and research skills to confront technological scenarios.
• To provide valuable resources for social empowerment and lifelong learning process.

COMPUTER SCIENCE AND ENGINEERING

Vision

To produce eminent skilled women engineers in the field of Artificial Intelligence And
Data Science to solve challenges in the society.

Mission

⚫ To nourish the core competence in the domain of Artificial Intelligence and Data
Science by continuously improving the resources.
⚫ To produce virtuous engineers by imparting the value of honesty, courage and
tenderness to serve the society.
⚫ To enrich the skills to meet the industrial requirement in the field of Artificial
intelligence.
PROGRAM EDUCATIONAL OBJECTIVES (PEO’s)

PEO1: Develop actionable competency in the realm of Artificial Intelligence & Data
Science to solve socially relevant problems.

PEO2: Develop world class solutions with the professional knowledge gained by lifelong
learning and Work in multi-disciplinary teams, communicate effectively.

PEO3: Pursue higher education and research in the field of Artificial Intelligence and Data
Science.

Program Outcomes (PO'S)

1. Engineering knowledge: Apply the knowledge of mathematics, science, engineering
fundamentals, and an engineering specialization to the solution of complex engineering
problems.
2. 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.
3. 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.
4. 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.
5.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.
6. 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.
7. 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.
8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities and
norms of the engineering practice.
9. Individual and team work: Function effectively as an individual, and as a member or leader
in diverse teams, and in multidisciplinary settings.
10. 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.
11. Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to ones own work, as a member and
leader in a team, to manage projects and in multidisciplinary environments.
12. Life-long 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 PROGRAM (PSO’S)

PSO 1: Implement Artificial Intelligence and data science tools like data analytics, machine
learning and neural networks to build new algorithms for a successful career and
entrepreneurship.

PSO 2: Apply the knowledge in various fields of healthcare, education, intelligent

transportation, and the multidisciplinary field of Artificial Intelligence and Data Science.

PSO 3: Graduates will gain practical proficiency with emerging technologies and open source
software in the field of Artificial Intelligence and Data Science
CS3591 COMPUTER NETWORKS LTPC
3 0 24
COURSE OBJECTIVES:
✓ To understand the concept of layering in networks.
✓ To know the functions of protocols of each layer of TCP/IP protocol suite.
✓ To visualize the end-to-end flow of information.
✓ To learn the functions of network layer and the various routing protocols.
✓ To familiarize the functions and protocols of the Transport layer.
UNIT I INTRODUCTION AND APPLICATION LAYER 10
Data Communication - Networks – Network Types – Protocol Layering – TCP/IP Protocol
suite – OSI Model – Introduction to Sockets - Application Layer protocols: HTTP – FTP –
Email protocols (SMTP - POP3 - IMAP - MIME) – DNS – SNMP

UNIT II TRANSPORT LAYER 9

Introduction - Transport-Layer Protocols: UDP – TCP: Connection Management – Flow
control - Congestion Control - Congestion avoidance (DECbit, RED) – SCTP – Quality of
Service.

UNIT III NETWORK LAYER 7

Switching : Packet Switching - Internet protocol - IPV4 – IP Addressing – Subnetting - IPV6,
ARP, RARP, ICMP, DHCP

UNIT IV ROUTING 7
Routing and protocols: Unicast routing - Distance Vector Routing - RIP - Link State Routing
– OSPF – Path-vector routing - BGP - Multicast Routing: DVMRP – PIM.

UNIT V DATA LINK AND PHYSICAL LAYERS 12

Data Link Layer – Framing – Flow control – Error control – Data-Link Layer Protocols –
HDLC – PPP - Media Access Control – Ethernet Basics – CSMA/CD – Virtual LAN –
Wireless LAN (802.11) - Physical Layer: Data and Signals - Performance – Transmission
media- Switching – Circuit Switching.
45 PERIODS
30 PERIODS
COURSE OUTCOMES:
On completion of the course, the students will be able to:
o CO 1: Explain the basic layers and its functions in computer networks.
o CO2:Understand the basics of how data flows from one node to another.
o CO3: Analyze routing algorithms.
o CO4: Describe protocols for various functions in the network.
o CO5: Analyze the working of various application layer protocols.
 9

TEXT BOOKS:
1. James F. Kurose, Keith W. Ross, Computer Networking, A Top-Down Approach
Featuring the Internet, Eighth Edition, Pearson Education, 2021.
2. Behrouz A. Forouzan, Data Communications and Networking with TCP/IP Protocol
Suite, Sixth Edition TMH, 2022.
REFERENCES:
1. Larry L. Peterson, Bruce S. Davie, Computer Networks: A Systems Approach, Fifth
Edition, Morgan Kaufmann Publishers Inc., 2012.
2. William Stallings, Data and Computer Communications, Tenth Edition, Pearson
Education, 2013.
3. Nader F. Mir, Computer and Communication Networks, Second Edition, Prentice Hall,
2014.
4. Ying-Dar Lin, Ren-Hung Hwang, Fred Baker, “Computer Networks: An Open Source
Approach”, McGraw Hill, 2012.
 CONCEPT MAP

TCP/IP Protocol Quality of

Protocol suite Transport-Layer
Service Protocols
Layering

OSI Model SCTP

Network
Types Congestion avoidance IPV6, ARP, RARP,
(DECbit,RED) ICMP, DHCP
INTRODUCTION
AND APPLICATION
LAYER
Networks Congestion
TRANSPORT LAYER Subnetting
Control
Data
Communication Connection IP Addressing
Management
UDP
Schedules

Routing and protocols Flow control

NETWORK
LAYER
Unicast
BGP COMPUTER NETWORKS
routing
IPV4 RARP,
CP

Distance Vector Internet protocol

Routing ROUTING
Circuit
Flow Switching
DVMRP – PIM control
Error
Data Link
control
Layer Data-Link Layer
Link State
Routing DATA LINK AND Protocols
Framing PHYSICAL LAYERS
OSPF CSMA/CD
Media Access Control
HDLC

Virtual LAN Ethernet Transmission

Basics PPP media
 DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE
III YEAR / IV SEMESTER
COURSE DATA SHEET
PROGRAM: AI&DS DEGREE: B.Tech
COURSE: Recommender System SEMESTER: 04 CREDITS: 04
COURSE CODE: CS3591 COURSE TYPE: ELECTIVE
REGULATION: 2021
COURSE AREA/DOMAIN: AI&DS CONTACT HOURS: 5 hours/Week.
CORRESPONDING LAB COURSE LAB COURSE NAME (IF ANY):
CODE (IF ANY): CS8581

SYLLABUS:
UNIT DETAILS HOURS
INTRODUCTION AND APPLICATION LAYER

Data Communication - Networks – Network Types – Protocol

I Layering – TCP/IP Protocol suite – OSI Model – Introduction to 6

Sockets - Application Layer protocols: HTTP – FTP – Email protocols

(SMTP - POP3 - IMAP - MIME) – DNS – SNMP
TRANSPORT LAYER
Introduction - Transport-Layer Protocols: UDP – TCP: Connection
II 6
Management – Flow control - Congestion Control - Congestion
avoidance (DECbit, RED) – SCTP – Quality of Service
NETWORK LAYER
III Switching : Packet Switching - Internet protocol - IPV4 – IP 6
Addressing – Subnetting - IPV6, ARP, RARP, ICMP, DHCP
ROUTING
Routing and protocols: Unicast routing - Distance Vector Routing -
IV 6
RIP - Link State Routing – OSPF – Path-vector routing - BGP -
Multicast Routing: DVMRP – PIM.
 DATA LINK AND PHYSICAL LAYERS
Data Link Layer – Framing – Flow control – Error control – Data-Link
Layer Protocols – HDLC – PPP - Media Access Control – Ethernet
V Basics – CSMA/CD – Virtual LAN – Wireless LAN (802.11) - 6
Physical Layer: Data and Signals - Performance – Transmission
media- Switching – Circuit Switching.

Total hours 30

TEXT/REFERENCE BOOKS:
T/R BOOK TITLE/AUTHORS/PUBLICATION
T1 James F. Kurose, Keith W. Ross, Computer Networking, A Top-Down Approach
Featuring the Internet, Eighth Edition, Pearson Education, 2021.
T2 Behrouz A. Forouzan, Data Communications and Networking with TCP/IP Protocol
Suite, Sixth Edition TMH, 2022

COURSE PRE-REQUISITES:
Course Course Name Description Sem
Code
CS8392 Problem Solving and Python OOPS Concepts 3
Programming

CS8494 Database Management 4

Systems

COURSE OBJECTIVES:
1 To understand the concept of layering in networks.
2 To know the functions of protocols of each layer of TCP/IP protocol suite.

3 To visualize the end-to-end flow of information.

4 To learn the functions of network layer and the various routing protocols.
5 To familiarize the functions and protocols of the Transport layer.
COURSE OUTCOMES:
S No DESCRIPTRION PO(1..12) & PSO(1..2) MAPPING
 1 Explain the basic layers and its functions
in computer networks.
2 Understand the basics of how data flows
from one node to another.
3 Analyze routing algorithms.
4 Describe protocols for various functions in
the network.
5 Analyze the working of various
application layer protocols.

COURSE OUTCOMES VS POS MAPPING (HIGH:3; MEDIUM:2; LOW:1):

S NO PO1 PO2 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 PSO1 PSO2 PS03

CO505.1 3 1 2 3 0 0 0 0 1 1 3 1 3 2 1
CO505.2 3 2 1 2 2 0 0 0 2 2 2 1 3 2 3
CO505.3 2 2 3 2 1 0 0 0 3 3 1 2 1 1 3
CO505.4 1 3 1 3 1 0 0 0 1 2 1 1 1 3 1
CO505.5 3 3 1 1 2 0 0 0 2 2 2 2 2 2 2
Average 2 2 2 2 2 0 0 0 2 2 2 1 2 2 2

PO1 Engineering Knowledge PO7 Environment and PSO1 Domain Skills1

Sustainability
PO2 Problem Analysis PO8 Ethics PSO2 Domain Skills2
PO3 Design/Development of PO9 Individual and Team PSO3 Domain Skills3
Solutions Work
PO4 Conduct Investigations of PO10 Communication
Complex Problems
PO5 Modern Tool Usage PO11 Project Management and
Finance
PO6 The Engineer and Society PO12 Life-long Learning:

JUSTIFICATION FOR MAPPING

PO/PSO
SNO MAPPED JUSTIFICATION
CO505.1
 CO505.2

CO505.3

CO505.4

CO505.5

GAPES IN THE SYLLABUS - TO MEET INDUSTRY/PROFESSION REQUIREMENTS, POs:

SNO DESCRIPTION PROPOSED ACTIONS
1 Assignment
TOPICS BEYOND SYLLABUS/ADVANCED TOPICS/DESIGN:
 1.

WEB SOURCE REFERENCES:

1 Lec 26: Dimensionality Problem and Principal Component Analysis - NPTEL IIT
Guwahati - https://youtu.be/nh4dXjSKO20?si=IqL6IUqupeXhd2Qc
2 Lecture 49 — SVD Gives the Best Low Rank Approximation (Advanced) | Stanford
- Artificial Intelligence - All in One - https://youtu.be/c7e-D2tmRE0?si=Z3F3CtLyh-
xLCd0b
3 Classification - NPTEL-NOC IITM -
https://youtu.be/32M5v9jJtJ0?si=DOyHAD3gSyJebNQ9
4 Lecture 43 — Collaborative Filtering | Stanford University - Artificial Intelligence -
All in One - https://youtu.be/h9gpufJFF-0?si=n34QFjhAMQsJec_O
5 Lecture 45 — Evaluating Recommender Systems | Stanford University - Artificial
Intelligence - All in One - https://youtu.be/VZKMyTaLI00?si=idPpXHRZn_lYQ4fV
DELIVERY / INSTRUCTIONAL METHODOLOGIES:

☐ MD1: Oral Presentation ☐ MD2: Power Point ☐ MD3: Tutorial

(Chalk & Talk) Presentation
☐ MD4: Hands on ☐ MD5: Seminar / Guest ☐ MD6: Videos
Demonstration Lecture
☐ MD7: Field Visit ☐ MD8: Role Play ☐ MD9: Chart and Model

ASSESSMENT METHODOLOGIES - DIRECT

☐ Internal Test - I ☐ Internal Test - II ☐ Internal Test - III

☐ Assignment - I ☐ Assignment - II ☐ Assignment - III
☐ Model Exam ☐ Course Seminar ☐ Course Quiz

ASSESSMENT METHODOLOGIES - INDIRECT

☐ Assessment of Course Outcomes (by ☐ Student Feedback on Faculty

Student Feedback)
☐ Assessment of Mini / Major Projects (by ☐ Others
External Expert)

Prepared by faculty Approved by HOD

 COURSE /ASSESSMENT SCHEDULE

Academic Year :2023-2024

Year/Branch/Sec./Sem :III AI&DS/04
Course Code/Name : CS3591 / COMPUTER NETWORKS
Regulation :2021
Course Category Code :243
Course Credit :4
Course Faculty :Dr.T.Sunitha
Course Coordinator :Nil
Tentative dates for Assessment Tests:
Internal Assessment Test I :
Internal Assessment Test II :
Tentative dates for Assignments:
Assignment 1 :
Assignment 2 :

Lecture Hours

Unit No. of hours Allotted as per syllabus No. of hours Planned

UNIT I 6
UNIT II 6
UNIT III 6
UNIT IV 6
UNIT V 6
Total Hours 30
 UNIT I- Unified Process and Use Case Diagrams

Sl Proposed Actual Pertaini Highest Mode Deliver

.N Lecture Lecture ng Cognitiv of y
Topic Outcomes
o. Period Period CO(s) e Level Delive Resour
ry ces
1 Data CO1 K3 MD1 T1
Communication
2 Networks CO1 K3 MD1 T1,T2
3 Network Types CO1 K3 MD1 T1,T2
4 Protocol Layering CO1 K3 MD1 T1
5 TCP/IP Protocol CO1 K3 MD1 T1
suite
6 OSI Model CO1 K3 MD1 T1
7 Introduction to CO1 K3 MD1 T1
Sockets
8 Application Layer CO1 K3 MD1 T1
protocols: HTTP
9 FTP CO1 K3 MD1 T1
10 Email protocols CO1 K3 MD3 T1
(SMTP - POP3 -
IMAP - MIME)
11 DNS CO1 K3 MD3 T1
12 SNMP CO1 K3 MD1 T1

Signature of Staff In charge Signature of HOD

UNIT II- Static UML Diagrams

Sl.N Proposed Actual Pertaini Highest Mode of Deliver

o. Lecture Lecture ng CO(s) Cognitiv Delivery y
Topic Outcomes
Period Period e Level Resour
ces
1 Introduction
2 Item profiles
 TCP: Connection
Management
3 Flow control
4 Congestion Control
5 - Congestion
avoidance (DECbit,
RED)
6 SCTP
7 Quality of Service
8
9
10 26/7/19,7 CO2 K3 MD1 T1 Learned When to
use Class Diagrams

Signature of Staff In charge Signature of HOD

UNIT III - Dynamic and Implementation UML Diagrams

Sl.No Proposed Actual Pertainin Highest Mode of Deliver

. Lecture Lecture g CO(s) Cognitiv Delivery y
Topic Outcomes
Period Period e Level Resour
ces
1 Switching : CO3 K3 MD1 T1
Packet
Switching
2 Internet CO3 K3 MD1 T1
protocol
3 IPV4 CO3 K3 MD1 T1,T2
4 IP Addressing CO3 K3 MD1 T1
5 Subnetting CO3 K3 MD3 T1
6 IPV6 CO3 K3 MD1 T1
7 ARP CO3 K3 MD1 T1
8 RARP CO3 K3 MD1 T1
9 ICMP CO3 K3 MD1 T1,T2

Signature of Staff In charge Signature of HOD

 UNIT IV- Design Patterns

Sl.No. Proposed Actual Pertaini Highest Mode of Delivery

Lecture Topic Lecture ng Cognitive Delivery Resources Outcomes
Period Period CO(s) Level
1 Introduction Routing 16/8/19,7 CO4 K2 MD1 T1
and protocols:
Unicast routing
2 Distance Vector CO4 K2 MD1 T1
Routing
RIP CO4 K2 MD1 T1
3 Link State Routing CO4 K2 MD1 T1
4 OSPF CO4 K2 MD1 T1
5 Path-vector routing CO4 K2 MD1 T1
6 BGP CO4 K2 MD1 T1
7 Multicast Routing: CO4 K2 MD1 T1
DVMRP
8 PIM CO4 K2 MD1 T1

Signature of Staff In charge Signature of HOD

UNIT V - Testing

Sl.No. Proposed Actual Pertai Highest Mode Delivery

Lecture Lecture ning Cogniti of Resource
Topic Outcomes
Period Period CO(s) ve Deliver s
Level y
1 Data Link Layer CO5 K1 MD1 T2

2 Framing CO5 K1 MD1 T2

3 Flow control CO5 K1 MD1 T2
4 Error control CO5 K1 MD1 T2
5 Data-Link Layer CO5 K1 MD1 T2
Protocols
6 HDLC CO5 K1 MD1 T2
7 PPP CO5 K1 MD1 T2
8 Media Access Control CO5 K1 MD1 T2
9 Ethernet Basics CO5 K1 MD1 T2
10 CSMA/CD CO5 K1 MD1 T2
11 Virtual LAN CO5 K1 MD1 T2
12 Wireless LAN CO5 K1 MD1 T2
(802.11)
13 Physical Layer: Data CO5 K1 MD1 T2
and Signals
14 Performance CO5 K1 MD1 T2
15 Transmission media CO5 K1 MD1 T2
16 Switching CO5 K1 MD1 T2
17 Circuit Switching. CO5 K1 MD1 T2

Signature of Staff In charge Signature of HOD

DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE

ACADEMIC YEAR 2023-2024 (EVEN SEMESTER)

III YEAR / IV SEMESTER
STUDENTS NAMELIST

SI NO. Register Number Name

1. 960220104001 Aarthi.S.P
2. 960220104002 Abinaya.R.K
3. 960220104003 Abiraina.P.A
4. 960220104004 Abisha.C
5. 960220104005 Abisha.D
6. 960220104006 Abisha.S
7. 960220104007 Adjaya Sree.S
8. 960220104008 Afrin.N
9. 960220104009 Ahalya.G
10. 960220104010 Ajatha.B.S
11. 960220104011 Akalya.K
12. 960220104012 Akshaya.S
13. 960220104014 Anitta.M.Das
14. 960220104015 Anlin Breesha.T
15. 960220104016 Anusha.V
16. 960220104017 Anusuya.S
17. 960220104018 Archana.R.D
18. 960220104019 Asberyl Sheraphin.I
19. 960220104020 Asha.A.C
20. 960220104021 Asha.M
21. 960220104022 Ashika.H
22. 960220104023 Ashika.N
23. 960220104024 Ashika.R.V
24. 960220104025 Ashlina.J
25. 960220104026 Ashmika.G
26. 960220104027 Ashna Chinju
27. 960220104028 Asley Rejeese.R
28. 960220104029 Aslin Kani.C.S
29. 960220104030 Auslin.M
30. 960220104031 Behima Joseni.J
31. 960220104032 Benshika.B.V
32. 960220104033 Bershika. R.S
33. 960220104034 Bincia Shine.R
 34. 960220104035 Britney Spierce.G
35. 960220104036 Deva Jesma.V
36. 960220104037 Dhanusha.D.N
37. 960220104038 Dheepthika.G.A
38. 960220104039 Evangalin Reshmi.J
39. 960220104040 Gafna Noelin.S
40. 960220104041 Gayathri.J.M
41. 960220104042 Geji Reashma.A
42. 960220104043 Harshini.M
43. 960220104044 Hathoon Beevi.S
44. 960220104045 Jebisha. G
45. 960220104046 Jeshiya.J
46. 960220104047 Jeya Pradeesha.S
47. 960220104048 Jijin Jora.N.S
48. 960220104049 Jika Shirose.R.M
49. 960220104050 Joevisha Mergil.S
50. 960220104051 Jovita M Bibyana
51. 960220104052 Kaviya.K
52. 960220104055 Lakshmi.V.V
53. 960220104079 Roshini C M

Faculty Incharge HOD/CSE

 DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE
TIME TABLE FOR ACADEMIC YEAR (2023 - 2024) – EVEN SEMESTER
PROGRAMME : B.Tech
YEAR / SEMESTER :II/IV
NAME OF THE SUBJECT : CS3591 & COMPUTER NETWORKS
NAME OF THE FACULTY : Dr.T.Sunitha DESIGNATION : Assistant Professor

Days/Period I
II III IV V VI VII VIII
Monday
CS3591 CS3591

Tuesday
CS3591

Wednesday
CS3591

Thursday CS3591

Friday
CS3591 CS3591

Faculty Signature HOD/CSE

 DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE

CS3591 - COMPUTER NETWORKS

FOURTH SEMESTER –SAMPLE NOTES

UNIT 1

INTRODUCTION AND APPLICATION LAYER

UNIFIED PROCESS

❖ The UP is an iterative process. The UP promotes several best practices iterative

development.
❖ In this approach, development is organized into a series of short, fixed-length (for
example, four week) mini-projects called iterations; the outcome of each is a tested,
integrated, and executable system.
❖ Each iteration includes its own requirements analysis, design, implementation, and
testing activities.

What is Iterative and Evolutionary Development?

❖ Development is organized into a series of short, fixed-length mini-projects called

iterations; the outcome of each is a tested, integrated, and executable partial system.
❖ Each iteration includes its own requirements analysis, design, implementation, and
testing activities.
❖ The system grows incrementally over time, iteration by iteration, and thus this approach
is also known as iterative and incremental development

Advantages of UP:

❖ Rapid feedback from users and developers

❖ Then adapt to changes in the next iteration (adaptive development)
❖ Visible progress
❖ Start with high risk
❖ Manage complexity by dividing the problem into smaller ones

Risk-Driven and Client-Driven Iterative Planning?

In risk-driven and client-driven iterative planning, the goals of the early iterations are chosen
to
 1) identify and drive down the highest risks, and
2) build visible features that the client cares most about.

Risk-driven iterative development includes more specifically the practice of architecture-

centric iterative development, meaning that early iterations focus on building, testing, and
stabilizing the core architecture.

Best practices and key concepts in UP:

• tackle high-risk and high-value issues in early iterations

• continuously engage users for evaluation, feedback, and requirements
• build a cohesive, core architecture in early iterations
• continuously verify quality; test early, often, and realistically
• apply use cases where appropriate
• do some visual modeling (with the UML)
• carefully manage requirements
• practice change request and configuration management
UP Phases:
Four phases are:
1.Inception
2.Elaboration
3.Construction.
4.Transition.
1.Inception
❖ Approximate vision, business case, scope, vague estimates.
❖ Inception is a feasibility phase, where just enough investigation is done to support a
decision to continue or stop.

2.Elaboration

❖ In this phase the core architecture is iteratively implemented, and high-risk issues are
mitigated, refined vision, iterative implementation of the core architecture, resolution
of high risks, identification of most requirements and scope, more realistic estimates
are made.

Figure: Schedule-oriented terms in the UP.

3.Construction-Iterative implementation of the remaining lower risk and easier elements, and
preparation for deployment.

4.Transition -Beta tests, deployment.

UML DIAGRAMS

❖ The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems.
❖ Unified Modeling Language (UML) is a standardized general-purpose modeling
language in the field of software engineering.
❖ The standard is managed, and was created by, the Object Management Group. UML
includes a set of graphic notation techniques to create visual models of software-
intensive systems.

There are two broad categories of diagrams and they are again divided into subcategories −

1. Structural Diagrams
2. Behavioral Diagrams

1. 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 four structural diagrams are
a) Class diagram
b) Object diagram
c) Component diagram
d) Deployment diagram

A)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.

b)Object Diagram
 ➢ Object diagrams can be described as an instance of class diagram. Thus, these diagrams
are more close to real-life scenarios where we implement a system.
➢ Object diagrams are a set of objects and their relationship is just like class diagrams.
They also represent the static view of the system.
➢ The usage of object diagrams is similar to class diagrams but they are used to build
prototype of a system from a practical perspective.

c)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.
d)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.
2)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 −

a) Use case diagram

b) Sequence diagram
c) Collaboration diagram
d) State chart diagram
e) Activity diagram

a)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.

b)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.

c)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.

d)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.

e)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.

RELATING USECASES:

Use cases can be related to each other. Organizing use cases into relationships has no
impact on the behavior or requirements of the system. It is simply an organization mechanism
to improve communication and comprehension of the use cases, reduce duplication of text, and
improve management of the use case documents.

Relationships of use case:

The Three relationships of use cases are:

 1.The include Relationship
2.The extend Relationship
3.The generalize Relationship

1.The include Relationship:

❖ This is the most common and important relationship.

❖ It is common to have some partial behavior that is common across several use
cases.
❖ For example, the description of paying by credit occurs in several use cases,
including Process Sale, Process Rental, Contribute to Lay-away Plan, and so
forth.
❖ For example: UC1: Process Sale

Main Success Scenario:

1 . Customer arrives at a POS checkout with goods and/or services to purchase. .

7. Customer pays and System handles payment.

Extensions:

7b. Paying by credit: Include Handle Credit Payment.

7c. Paying by check: Include Handle Check Payment.

UC12: Handle Credit Payment

Level: Sub function Main Success Scenario:

1. Customer enters their credit account information.

2. System sends payment authorization request to an external Payment Authorization

Service System, and requests payment approval.

3. System receives payment approval and signals approval to Cashier.

4. ...

Extensions:

2a. System detects failure to collaborate with external system:

1 . System signals error to Cashier.

2. Cashier asks Customer for alternate payment.

2.The extend Relationship

The extend relationship provides an answer. The idea is to create an extending or

addition use case, and within it, describe where and under what condition it extends the
behavior of some base use case.

UC1: Process Sale (the base use case)

Extension Points: VIP Customer, step

1 . Payment, step 7. Main Success Scenario: 1 . Customer arrives at a POS checkout

with goods and/or services to purchase. … 7. Customer pays and System handles payment. …

UC15: Handle Gift Certificate Payment (the extending use case)

… Trigger: Customer wants to pay with gift certificate. Extension Points: Payment in
Process Sale. Level: Sub function Main Success Scenario: 1 . Customer gives gift certificate to
Cashier. 2. Cashier enters gift certificate ID. …

This is an example of an extend relationship. Extension points are labels in the base use
case which the extending use case references as the point of extension, so that the step
numbering of the base use case can change without affecting the extending use case—
indirection yet again.

1.8.3.The generalize Relationship:

This is an optional relationship.

It adds another level of complexity to use cases.

Figure: Use case include relationship in the Use-Case Model.

The extend relationship notation is illustrated in the following Figure

 Figure :The extend relationship

UNIT II

TRANSPORT LAYER

CLASS DIAGRAM

Class diagram is a static diagram. It represents the static view of an application. Class
diagram describes the attributes and operations of a class and also the constraints imposed on
the system. Class diagram shows a collection of classes, interfaces, associations,
collaborations, and constraints. It is also known as a structural diagram.

A class notation consists of three parts:

1. Class Name
• The name of the class appears in the first partition.
2. Class Attributes
• Attributes are shown in the second partition.
• The attribute type is shown after the colon.
• Attributes map onto member variables (data members) in code.
3. Class Operations (Methods)
• Operations are shown in the third partition. They are services the class provides.
• The return type of a method is shown after the colon at the end of the method
signature.
• The return type of method parameters are shown after the colon following the
parameter name.
• Operations map onto class methods in code
Two Perspectives of class diagram:

i) Conceptual perspective

ii)Software perspective

Domain model and Define model

Classifier

A UML classifier is "a model element that describes behavioral and structure features”. In
class diagrams the two most classifiers are regular classes and interfaces.

UML Attributes

They can be shown in several ways.

Attribute text notation and Attribute line notation:

The full format of the attribute text notation is:

visibility name : type multiplicity = default {property-string}

visibility marks include + (public), - (private), and so forth.

 • a navigability arrow pointing from the source (Register) to target (Sale) object
indicating a Register object has an attribute of one sale
• multiplicity at the target end, but not the source end
• Role name (current sale) only at the target end to show the attribute name.

Notes, Comments, Constraints, and Method Bodies

• a UML note or comment is displayed as a dog eared rectangle with a dashed line
to the annotated element
• a UML constraint, in which case it must be encased in braces '{…}'
• a method body the implementation of a UML operation

Operations

The format of the operation syntax is:

visibility name (parameter-list) : return-type {property-string}

Operations are usually assumed public if no visibility is shown. The property string contains
arbitrary additional information, such as exceptions that may be raised, if the operation is
abstract, and so forth.

For example:

+getPlayer( name : String ) : Player {exception IOException}

An operation is not a method. A UML operation is a declaration, with a name,

parameters, return type, exceptions list, and possibly a set of constraints of pre-and post-
conditions.

Methods

A UML method is the implementation of an operation; if constraints are defined,

the method must satisfy them.

Keywords

A UML keyword is a textual adornment to categorize a model element. Most keywords

are shown in guillemet (« ») but some are shown in curly braces, such as {abstract}.Some
of the key words are

Stereotypes, Profiles, and Tags

• A stereotype represents a refinement of an existing modeling concept and is defined

within a UML.
 • Profile is a collection of related stereotypes, tags, and constraints to specialize the use
of the UML for a specific domain or platform, such as a UML profile for project
management or for data modeling.
• The stereotype declares a set of tags, using the attribute syntax. When an element
(such as the Square class) is marked with a stereotype, all the tags apply to the
element, and can be assigned values.

UML Properties and Property Strings

In the UML, a property is "a named value denoting a characteristic of an element. A

property has semantic impact

Properties of elements may be presented in many ways, but a textual approach is to use the
UML property string {name1=value1, name2=value2} format, such as {abstract,
visibility=public}.

Generalization, Abstract Classes

Generalization in the UML is shown with a solid line and fat triangular arrow from
the subclass to superclass. Generalization is a taxonomic relationship between a more general
classifier and a more specific classifier. Each instance of the specific classifier is also an
indirect instance of the general classifier.

Abstract classes and operations can be shown either with an {abstract} tag (useful when
sketching UML) or by italicizing the name

Dependency

The UML includes a general dependency relationship that indicates that a client
element (of any kind, including classes, packages, use cases, and so on) has knowledge of
another supplier element and that a change in the supplier could affect the client.

Dependency is illustrated with a dashed arrow line from the client to supplier.

There are many kinds of dependency; here are some common types in terms of objects and
class diagrams:

• having an attribute of the supplier type

• an attribute, a parameter variable, a local variable, a global variable, or class
visibility
• receiving a parameter of the supplier type
• the supplier is a superclass or interface

Class Relationships
A class may be involved in one or more relationships with other classes.

Relationship Names

• Names of relationships are written in the middle of the association line.

• Good relation names make sense when you read them out loud:
• "Every spreadsheet contains some number of cells",
• "an expression evaluates to a value"
• They often have a small arrowhead to show the direction in which direction to read
the relationship, e.g., expressions evaluate to values, but values do not evaluate to
expressions.

Figure : Class Visibility Examples

In the example above:

• attribute1 and op1 of MyClassName are public

• attribute3 and op3 are protected.
• attribute2 and op2 are private.

ELABORATION

Elaboration is the initial series of iterations during which the team does serious investigation,
implements (programs and tests) the core architecture, clarifies most requirements, and tackles
the high-risk issues.

Elaboration Process often consists of between two and four iterations; each iteration is
recommended to be between two and six weeks, unless the team size is massive. Each iteration
is time boxed, meaning its end date is fixed; if the team is not likely to meet the date,
requirements are placed back on the future tasks list, so that the iteration can end on time with
a stable and tested release

Elaboration in one sentence: Build the core architecture, resolve the high-risk elements,
define most requirements, and estimate the overall schedule and resources.

Some key ideas and best practices that will manifest in elaboration include

i) do short time boxed risk-driven iterations

ii) start programming early

iii) adaptively design, implement, and test the core and risky parts of the architecture

iv) test early, often, realistically

v) adapt based on feedback from tests, users, developers

vi) write most of the use cases and other requirements in detail, through a series of workshops,
once per elaboration iteration

Artifacts in Elaboration

Table below lists sample artifacts that may be started in elaboration, and indicates the issues
they address

SI.NO Artifacts Comment

1 Domain Model. This is a visualization of the domain concepts; it is similar to a static
information model of the domain entities.
2 Design Model This is the set of diagrams that describes the logical design. This
includes software class diagrams, object interaction dia- grams, package
diagrams, and so forth.
3 Software Architecture A learning aid that summarizes the key architectural issues and their
Document resolution in the design. It is a summary of the out- standing design ideas
and their motivation in the system.

4 Data Model This includes the database schemas, and the mapping strategies between
object and non-object representations.
5 Test Model A description of what will be tested, and how.
6 Implementation Model This is the actual implementation — the source code, executable,
database, and so on.
 7 Use-Case A description of the user interface, paths of navigation, usability models,
Storyboards,UI and so forth.
Prototypes

UNIT III

NETWORK LAYER

BASIC SEQUENCE DIAGRAM NOTATION

Messages

Each message between objects is represented with a message expression on a filled-arrowed[3]

solid line between the vertical lifelines (see Figure 15.7). The time ordering is organized from
top to bottom of lifelines.

Focus of Control and Execution Specification Bars

Sequence diagrams may also show the focus of control using an execution specification
bar. The bar is optional.

Figure: Messages and focus of control with execution specification bar.

Reply or Returns

There are two ways to show the return result from a message:

• Using the message syntax returnVar = message(parameter).

 • Using a reply (or return) message line at the end of an activation bar.

Figure: Two ways to show a return result from a message

Messages to "self" or "this"

Message being sent from an object to itself by using a nested activation bar.

Figure: Messages to "this."

Creation of Instance

Object creation notation is shown in dashed line with filled arrow ( synchronous message), or
open (stick arrow) if an asynchronous call.

Figure :Instance creation and object lifelines.

Object Destruction

The explicit destruction of an object can be shown with <<destroy>>sterotype message with
larger X.

Figure:Object destruction.

Frames

Frames are regions or fragments of the diagrams; they have an operator or label (such as loop)
and a guard .The [boolean test] guard should be placed over the lifeline to which it belongs.

Figure: Example UML frame.

The following table summarizes some common frame operators:

Conditional Messages

An OPT frame is placed around one or more messages. Notice that the guard is placed over the
related lifeline.

Mutually Exclusive Conditional Messages

An ALT frame is placed around the mutually exclusive alternatives

Iteration Over a Collection

A common algorithm is to iterate over all members of a collection (such as a list or map),
sending the same message to each.
Nesting of Frames

Frames can be nested. It is shown in following

System Sequence Diagrams:

A system sequence diagram (SSD) is a fast and easily created artifact that illustrates input and
output events related to the systems under discussion. They are input to operation contracts and
most importantly object design.

Figure SSD for a Process Sale scenario.

❖ The UML includes sequence diagrams as a notation that can illustrate actor interactions
and the operations initiated by them.
❖ A system sequence diagram is a picture that shows, for one particular scenario of a use
case, the events that external actors generate, their order, and inter-system events.
 ❖ All systems are treated as a black box; the emphasis of the diagram is events that cross
the system boundary from actors to systems.

UML STATE MACHINE DIAGRAMS AND MODELING

❖ A UML state machine diagram, , illustrates the interesting events and states of an object,
and the behavior of an object in reaction to an event.
❖ Transitions are shown as arrows, labeled with their event.
❖ States are shown in rounded rectangles.
❖ It is common to include an initial pseudo-state, which automatically transitions to
another state when the instance is created.

Figure :State machine diagram for a telephone

❖ A state machine diagram shows the lifecycle of an object: what events it experiences,
its transitions, and the states it is in between these events.
❖ It need not illustrate every possible event; if an event arises that is not represented in
the diagram, the event is ignored as far as the state machine diagram is concerned.
❖ Therefore, we can create a state machine diagram that describes the lifecycle of an
object at arbitrarily simple or complex levels of detail, depending on our needs.

Events, States, and Transitions

An event is a significant or noteworthy occurrence.

For example A telephone receiver is taken off the hook.
A state is the condition of an object at a moment in time the time between events.
For exampleA telephone is in the state of being "idle" after the receiver is placed on
the hook and until it is taken off the hook
A transition is a relationship between two states that indicates that when an event
occurs, the object moves from the prior state to the subsequent state.
 For exampleWhen the event "off hook" occurs, transition the telephone from the "idle"
to "active" state.

How to Apply State Machine Diagrams?

State-Independent and State-Dependent Objects

❖ If an object always responds the same way to an event, then it is considered state-
independent (or modeless) with respect to that event.
❖ For example, if an object receives a message, and the responding method always does
the same thing. The object is state-independent with respect to that message.
❖ If, for all events of interest, an object always reacts the same way, it is a state-
independent object. By contrast, state-dependent objects react differently to events
depending on their state or mode.

Guideline

❖ Consider state machines for state-dependent objects with complex behavior, not for
state-independent objects .For example, a telephone is very state-dependent.
❖ The phone's reaction to pushing a particular button (generating an event) depends on
the current mode of the phone off hook, engaged, in a configuration subsystem, and so
forth.
❖ In general, business information systems have few complex state-dependent classes.

Modeling State-dependent Objects

Broadly, state machines are applied in two ways:

❖ To model the behavior of a complex reactive object in response to events.

❖ To model legal sequences of operations rotocol or language specifications.This
approach may be considered a specialization of #1, if the "object" is a language,
protocol, or process. A formal grammar for a context-free language is a kind of state
machine.

The following is a list of common objects which are often state-dependent, and for which it
may be useful to create a state machine diagram:

Complex Reactive Objects

1. Physical Devices controlled by software

Phone, car, microwave oven: They have complex and rich reactions to events, and
the reaction depends upon their current mode.
2. Transactions and related Business Objects
How does a business object (a sale, order, payment) react to an event? For
example, what should happen to an Order if a cancel event occurs? And understanding
 all the events and states that a Package can go through in the shipping business can help
with design, validation, and process improvement.
3. Role MutatorsThese are objects that change their role.
A Person changing roles from being a civilian to a veteran. Each role is
represented by a state.

Protocols and Legal Sequences

a) Communication Protocols TCP, and new protocols, can be easily and clearly
understood with a state machine diagram. The diagram illustrates when operations are
legal. For example, a TCP "close" request should be ignored if the protocol handler is
already in the "closed" state.
b) UI Page/Window Flow or NavigationWhen doing UI modeling, it can be useful to
understand the legal sequence between Web pages or windows; this is often complex.
A state machine is a great tool to model UI navigation

c) UI Flow Controllers or SessionsThis is related to UI navigation modeling, but

specifically focused on the server-side object that controls page flow. These are usually
server-side objects representing an ongoing session or conversations with a client. For
example, a Web application that remembers the state of the session with a Web client
and controls the transitions to new Web pages, or the modified display of the current
Web page, based upon the state of the session and the next operation that is received.
d) Use Case System Operations
system operations for Process Sale: makeNewSale, enterItem, should arrive in a legal
order; for example, endSale should only come after one or more enterItem operations.
Usually, the order is trivially obvious, but if complex, a state machine can model this,
treating the use case itself as an object.
e) Individual UI Window Event Handling
Understanding the events and legal sequences for one window or form. For example,
the Edit-Paste action is only valid if there is something in the "clipboard" to paste.

UNIT IV

ROUTING

CREATOR
Mainly used to create an instance of a class.
Problem : Who should be responsible for creating a new instance of some class?
Solution :
Assign class B the responsibility to create an instance of class A if one or more of the following
is true:
• B aggregates A objects.
• B contains A objects.
• B records instances of A objects.
 • B closely uses A objects.
• B has the initializing data that will be passed to A when it is created (thus B is an Expert
with respect to creating A).
• B is a creator of A objects.
If more than one option applies, prefer a class B which aggregates or contains class A.

Example:

In the POS application, who should be responsible for creating a SalesLineltem

instance? By Creator, we should look for a class that aggregates, contains, and so on,
SalesLineltem instances. Consider the partial domain model given in Figure4.2

.
Figure:Partial domain model.

Since a Sate contains (in fact, aggregates) many SalesLineltem objects, the Creator pattern
suggests that Sale is a good candidate to have the responsibility of creating SalesLineltem
instances. This leads to a design of object interactions as shown in Figure 4.3.

Discussion: Creator guides assigning responsibilities related to the creation of objects, a very
common task. The basic intent of the Creator pattern is to find a creator that needs to be
connected to the created object in any event. Choosing it as the creator supports low coupling.

Contraindications: Often, creation requires significant complexity, such as using recycled

instances for performance reasons, conditionally creating an instance from one of a family of
similar classes based upon some external property value, and so forth.

Benefits:

• Low coupling (described next) is supported,

• lower maintenance dependencies and
• higher opportunities for reuse.
• Increased clarity

Related Patterns or Principles:

 • Low Coupling
• Concrete Factory
• Abstract factory
INFORMATION EXPERT (OR EXPERT)

Information Expert assigns responsibility to the class that has the information needed to
fulfill the responsibility.

Problem: What is a general principle of assigning responsibilities to objects?

Solution: Assign a responsibility to the information expert the class that has the information
necessary to fulfill the responsibility.

A Design Model may define hundreds or thousands of software classes, and an application may
require hundreds or thousands of responsibilities to be fulfilled. During object design, when
the interactions between objects are defined, we make choices about the assignment of
responsibilities to software classes. Done well, systems tend to be easier to understand,
maintain, and extend, and there is more opportunity to reuse components in future applications.

Example : In the NextGEN POS application, some class needs to know the grand total of a
sale.

It is necessary to know about all the SalesLineltem instances of a sale and the sum of their
subtotals

Figure: Partial interaction and class diagrams.

In terms of an interaction diagram, this means that the Sale needs to send get-Subtotal messages
to each of the SalesLineltems and sum the results;
 Figure : Calculating the Sale sub total

To fulfill the responsibility of knowing and answering its subtotal, a SalesLineltem needs to
know the product price. The ProductSpecification is an information expert on answering its
price; therefore, a message must be sent to it asking for its price.

Figure : Calculating the Sale sub total

To fulfill the responsibility of knowing and answering the sale’s total, three responsibilities
were assigned to three design classes of objects as follows.

SI NO Design Class Responsibility

1 Sale knows sale total
2 SalesLineltem knows line item subtotal
3 ProductSpecification knows product price

Discussion: Information Expert is frequently used in the assignment of responsibilities; it is a

basic guiding principle used continuously in object design. Expert is not meant to be an obscure
or fancy idea; it expresses the common "intuition" that objects do things related to the
information they have.

Contraindications: There are situations where a solution suggested by Expert is undesirable,

usually because of problems in coupling and cohesion

Benefits:

• Information encapsulation is maintained, since objects use their own information to

fulfill tasks.
• supports low coupling, which leads to more robust and maintainable systems.
• encourage more cohesive "lightweight" class definitions that are easier to understand
and maintain.
• High cohesion is usually supported (another pattern discussed later).

Related Patterns or Principles:

• Low Coupling
• High cohesion
LOW COUPLING

Coupling is a measure of how strongly one element is connected to, has knowledge of, or
relies on other elements.

An element with low (or weak) coupling is not dependent on too many other elements; "too
many" is context-dependent, but will be examined. These elements include classes,
subsystems, systems, and so on.

A class with high (or strong) coupling relies on many other classes. Such classes may be
undesirable;

Problem: How to support low dependency, low change impact, and increased reuse?.

Solution: Assign a responsibility so that coupling remains low.

Example: Consider the following partial class diagram from a NextGen case study:

payment Register Sale

Assume we have a need to create a Payment instance and associate it with the Sale.
What class should be responsible for this? Since a Register "records" a Payment in the real-
world domain, the Creator pattern suggests Register as a candidate for creating the Payment.
The Register instance could then send an addPayment message to the Sale, passing along the
new Payment as a parameter. A possible partial interaction diagram reflecting this is shown in
Figure 4.7

Figure 4.7 Register creates Payment.

This assignment of responsibilities couples the Register class to knowledge of the Payment
class. UML notation: Note that the Payment instance is explicitly named p so that in message
2 it can be referenced as a parameter. An alternative solution to creating the Payment and
associating it with the Sale is shown in Figure 4.8

Figure: Sale creates Payment.

Discussion: Low Coupling is a principle to keep in mind during all design decisions; it is an
underlying goal to continually consider.

In object-oriented languages common forms of coupling from TypeX to TypeY include:

• Type X has an attribute (data member or instance variable) that refers to a Type Y
instance, or Type Y itself.
• A Type X object calls on services of a TypeY object.
• Type X has a method that references an instance of Type Y, or Type Y itself, by any
means.
• Type X is a direct or indirect subclass of Type Y.
• Type Y is an interface, and Type X implements that interface.

Contradictions:

High coupling to stable elements and to pervasive elements is seldom a problem.

Benefits
 • not affected by changes in other components
• simple to understand in isolation
• convenient to reuse
• Related Patterns or Principles:
• Protected variation

HIGH COHESION

In terms of object design, cohesion is a measure of how strongly related and focused the
responsibilities of an element are.

An element with highly related responsibilities, and which does not do a tremendous amount
of work, has high cohesion. These elements include classes, subsystems, and so on.

A class with low cohesion does many unrelated things, or does too much work. Such classes
are undesirable;

Problem: How to keep complexity manageable?

Solution: Assign a responsibility so that cohesion remains high

Example: The same example problem used in the Low Coupling pattern can be analyzed for
High Cohesion. Assume we have a need to create a (cash) Payment instance and associate it
with the Sale. What class should be responsible for this? Since Register records a Payment in
the real-world domain. The Register instance could then send an addPayrnent message to the
Sale, passing along the new Payment as a parameter, as shown in Figure 4.9

Figure: Register creates Payment.

The second design below delegates the payment creation responsibility to the Sale, and the
second design supports both high cohesion and low coupling, it is desirable.
 Figure: Sale creates Payment

Discussion :Like Low Coupling, High Cohesion is a principle to keep in mind during all design
decisions; it is an underlying goal to continually consider. It is an evaluative principle that a
designer applies while evaluating all design decisions.

Here are some scenarios that illustrate varying degrees of functional cohesion:

• Very low cohesion -A class is solely responsible for many things in very dif ferent
functional areas.
• Low cohesion - A class has sole responsibility for a complex task in one func tional
area.
• High cohesion - A class has moderate responsibilities in one functional area and
collaborates with other classes to fulfill tasks.
• Moderate cohesion - A class has lightweight and sole responsibilities in a few different
areas that are logically related to the class concept, but not to each other.
• Modular design – Modularity is the property of a system that has been decomposed
into a set of cohesive and loosely coupled modules.

Benefits:

• Clarity and ease of comprehension of the design is increased.

• Maintenance and enhancements are simplified.
• Low coupling is often supported.
highly related functionality is increased

STRUCTURAL PATTERN (BRIDGE)

Intent: The Bridge pattern separates an object's abstraction from its implementation so that you
can vary them independently.

Also Known As:Handle/Body

There are 2 parts in Bridge design pattern:

1. Abstraction
2. Implementation

Motivation:

• The bridge pattern allows the Abstraction and the Implementation to be developed
independently and the client code can access only the Abstraction part without being
concerned about the Implementation part.
• The abstraction is an interface or abstract class and the implementer is also an interface
or abstract class.
• It increases the loose coupling between class abstraction and it’s implementation.

Participants:

• Abstraction – core of the bridge design pattern and defines the crux. Contains a
reference to the implementer.
• Refined Abstraction – Extends the abstraction takes the finer detail one level below.
Hides the finer elements from implementers.
• Implementer – It defines the interface for implementation classes. This interface does
not need to correspond directly to the abstraction interface and can be very different.
Abstraction imp provides an implementation in terms of operations provided by
Implementer interface.
• Concrete Implementation – Implements the above implementer by providing concrete
implementation.

Structor:
Collaborations:Abstraction forwards client request to its implementor object.

Consequences:

• Decoupling interface and implementation

• Improved extensibility
• Hiding implementation details from clients.

Implementation:

• In situations where there is only one implementations creating an abstract Implementer

class is not necessary.
• Creating the right implementer object –if abstraction knows about all
ConcreteImplementor classes then it can instantiate one of them in its constructor based
on the constructor parameter.

BEHAVIORAL PATTERN - STRATEGY

Intent:

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy
lets the algorithm vary independently from clients that use it.

Also known as: policy

Motivation:

Defining classes that encapsulate different line breaking algorithms. An

algorithm that's encapsulated in this way is called a strategy.

Applicability:

Use the Strategy pattern when

• many related classes differ only in their behavior.

• you need different variants of an algorithm.
• An algorithm uses data that clients shouldn't know about
• A class defines many behaviors, and these appear as multiple
conditional statements in its operations.

Participants:

• Strategy -declares an interface common to all supported algorithms.

• ConcreteStrategy - implements the algorithm using the Strategy interface
• Context - maintains a reference to a Strategy object.
Collaborations:

• Strategy and Context interact to implement the chosen algorithm.

• A context may pass all data required by the algorithm to the strategy when the
algorithm is called.
• Alternatively, the context can pass itself as an argument to
Strategy operations.
• A context forwards requests from its clients to its strategy.

Structure:

Consequences:

• Families of related algorithms. Hierarchies of Strategy classes define a family of

algorithms or behaviors for contexts to reuse. Inheritance can help factor out common
functionality of the algorithms.
• An alternative to sub classing. Inheritance offers another way to support a variety of
algorithms or behaviors.
UNIT V
DATA LINK AND PHYSICAL LAYERS

OBJECT ORIENTED METHODOLOGIES

• Rumbaugh’s Methodology
• Booch Methodology
• Jacobson Methodology
• Patterns
 • Framework

INTRODUCTION:

Many methodologies are available to choose from for the system development. Each
methodology is based on modelling the business problem and implementation in an object
oriented fashion. The Rumbaugh method has a strong method for producing object models.
Jacobson et al have a strong method for producing user-driven requirement and object oriented
analysis model. Booch has a strong method for producing detailed object oriented design
models.

Rumbaugh’s Object Modelling Technique:

• Rumbaugh’s describes a method for the analysis, design and implementation of a system
using an object oriented technique. OMT consists of four phases which can be performed
iteratively

i) Analysis – results are objects, dynamic and functional models.

ii) System design – gives a structure of the basic architecture.
iii) Object design – produces a design document.
iv) Implementation – produces reusable code.
• OMT separates modelling in to three different parts
i)Object Model – presented by object model and the data dictionary
ii)Dynamic model - presented by the state diagrams and event Flow diagrams.
iii)Functional Model – presented by data flow and constraints.

i) Object model

• Object model describes the structure of objects in a system, their identity and
relationships to other objects, attributes, and operations.
• the object model is represented graphically with an object diagram.
• The object diagram contains classe4s interconnected by association lines.
• Each class represents a set of individual objects.
• The boxes in figure5.1 represents classes and the filled triangle represents associations

ii)Dynamic model

• OMT state transition diagram is a network of states and events.

• Each state receives one or more events, at which it makes the transition to the next state.
• The next state depends on the current state as well as the events.
• State transition diagrams for the bank application user interface is given in figure 5.2,
inwhich Round boxes represents states and Arrows represents transitions
 Figure : The OMT Object model of a bank system

Figure : State transition diagram for a bank system

iii)Functional model
Functional Modelling gives the process perspective of the object-oriented analysis
model and an overview of what the system is supposed to do. It defines the function of the
internal processes in the system with the aid of Data Flow Diagrams (DFDs). It depicts the
 functional derivation of the data values without indicating how they are derived when they
are computed, or why they need to be computed.
Functional Modelling is represented through a hierarchy of DFDs. The DFD is a
graphical representation of a system that shows the inputs to the system, the processing
upon the inputs, the outputs of the system as well as the internal data stores. DFDs illustrate
the series of transformations or computations performed on the objects or the system, and
the external controls and objects that affect the transformation. Data Flow Diagrams use
four primary symbols
1. The process is any function being performed
2.The data flow shows the direction of data element movement.
3. The data store is a location where data are stored.
4. An external entity is a source or destination of a data element.

Rumbaugh OMT methodology provides one of the strong tolls set for the analysis and design
of object-oriented system.

The Booch Methodology:

• Booch methodology is a widely used object-oriented method that helps to design your
system using the object paradigm. It covers the analysis and design phases of an object
oriented system.
 • Is criticized for his large set of symbols.
• It consists of the following diagrams:
.
i)Object diagrams.
ii)State transition diagrams.
iii) Module diagrams.
iv) Process diagrams.
v)Class diagrams
vi) Interaction diagrams.

BOOCH methodology prescribes two processes. They are

i)Macro development process
ii)Micro development process.

i) Macro development process

The macro process serves as a controlling frame work for the micro process and can take
weeks or months. The primary concern of macro process is technical management of the system

Steps involved:

1.Conceptualization.
Establish the core requirements and develop a prototype.
2.Analysis and development of the model

Use the class diagram to describe the roles and responsibilities of objects. Use the
object diagram to describe the desired behaviour of the system.

3.Design or create the system architecture.

 Use the class diagram to decide what classes exist and how they relate to each other,
the object diagram to decide what mechanisms are used, the module diagram to map out where
each class and object should be declared, and the process diagram to determine to which
processor to allocate a process.
4.Evolution or implementation.- Refine the system through much iteration.
5.Maintenance.- Make localized changes to the system to add new requirements and eliminate
bugs.
ii)Micro development process
Each macro development process has its own micro development process. The micro
development process is a description of the day-to-day activities. Steps involved here are

1.Identify classes and objects.

2.Identify classes and object semantics.
3.Identify classes and object relationships.
4. Identify classes and object interfaces and implementation.

Jacobson Methodology

JACOBSON methodologies are

❖ Object-oriented business engineering (OOBE)

❖ Object-oriented software engineering (OOSE) -It covers the entire life cycle and Stress
traceability (enables reuse of analysis and design work) both forward and backward
Use cases

Use cases are Scenarios for understanding system requirements. A use case is an
interaction between users and a system. The use case model captures the goal of the user and
the responsibility of the system to its users. Use cases are described as one of the following

✓ Non formal text with no clear flow of events.

✓ Text easy to read but with a clear flow of events to follow
✓ Formal style using pseudo code.
 ✓ The use case design must contain
✓ How and when the use case begins and ends
✓ Interaction between use case and its actors
✓ How and when concepts of the problem domain are handled
✓ How and when the use case will need data stored in the system
✓ Exception to the flow of events
Can be viewed as concrete or abstract (not initiated by actors).
✓ Understanding system requirements
✓ Interaction between user and system
✓ It captures the goal of the user and responsibility of the system to its users.
✓ It captures the goal of the user and responsibility of the system to its users.

Object oriented software Engineering: Objectory

OOSE is also called Objectory is a method of object oriented development with the
specific aim to fit the development of large, real time systems. Development process is also
called as use case driven development. The system development method based on OOSE is a
process for the industrialized development of the software. Objectory is built around several
different models

✓ Use case model: The use-case model defines the outside and inside of the system
behaviour.
✓ Domain Object Model: The objects of the real worlds are mapped in to the domain
object model.
✓ Analysis Object Model: The analysis object model presents how the source code
should be carried out and written.
✓ Implementation model: The implementation model represents the implementation
of the System
 ✓ Test model: The test model constitutes the test plans, specification and reports.

Object oriented business Engineering-Object oriented business engineering(OOBE) is object

modelling at the enterprise level.

❖ Analysis phase: The analysis phase defines the system to be built in terms of the
• problem-domain object model
• the requirements model
• analysis model

❖ Design and Implementation phase: The implementation environment must be identified for
the design model.
❖ Testing phase: This level includes unit testing, integration testing and system testing.

TESTING STATEGIES

Black box testing

In black box testing,you try various inputs and examine the resulting output;you can
learn what the box does but nothing about how this conversion is implemented.Black box
testing works very niecsly in testing objects in an object-oriented environment. The black box
testing technique also can be used for scenario-based tests,where the system's inside may not
be available for inspection but the input and output are defined through use cases or other
analysis information.
White box testing
White box testing assumes that the specific logic is important and must be tested to
guarantee the system's proper functioning. The main use of the White box is in error-based
testing ,when you already have tested all objects of an application and all external or public
methods of an object that you believe to be of greater importance.
Two types of path testing are statement testing coverage and branch testing coverage:
• Statement testing coverage: The main idea of statement testing coverage
is to test every statement in the object's method by executing it at least once.
• Branch testing coverage: The main idea behind branch testing coverage is to
perform enough tests to ensure that every branch alternative has been executed at least
once under some test.
Top down testing
Top down testing assumes that the main logic or object interactions and systems
messages of the application need more testing than an individual object's methods or supporting
logic. A top-down strategy can detect the serious design flaws early in the implementation.
Bottom-up testing
 Bottom-up testing starts with the details of the system and proceeds to higher levels
by a progressive aggregation of details until they collectively fit the requirements for the
system. This approach is more appropriate for testing the individual objects in a system.
Additional testing included here are
Data Conversion Testing
When a company migrates data to a new software, it becomes vulnerable. Once the
transfer of information has begun, digital assets are quite literally hanging in the balance. Any
errors could cause massive file corruption or even data loss. That’s why extensive conversion
testing to confirm the compatibility between old and new systems is important.
These tests also check for functionality in the application and uncover hidden defects.
Data conversion testing should be performed before, during, and after the migration process.
This minimizes the risk of permanently lost data.
Unit Testing
Unit testing is a software testing method by which individual units of source code which are
sets of one or more computer program modules together with associated control data, usage
procedures, and operating procedures are tested to determine whether they are fit for use.
Regression Testing
• Regression testing is the process of retesting the modified part of the software and
ensuring that no new error have been introduced into previously tested code due to these
modifications as whenever we modify any software, we need to retest it.
• Thus, regression testing tests both the modified source code and other parts of the
source code that may be affected by the change.
Functional Testing :
• Functional Testing is a type of testing that can be used to assess the features and
functionality of the system or software product.
• Functional testing has a special feature with the help of which each and every function
of a software product so that it can be verified with requirement specifications.
Checking a software product for its functionalities is the prime objective of functional
testing. It mainly focuses on:
1. Basic Usability: It deals with basic usability testing of software product which
involves basic functionalities of user interface and navigation through pages.
2. Mainline Functions: Main functions and features are tested of the software
product.
3. Accessibility: To check, how much the software product is accessible to users.
4. Error Conditions: Error conditions either generate warnings or displays error
messages, if any.
Non-Functional Testing:
• Non-functional testing is the type of testing which can be used to assess the non-
functional requirements of the software product rather than the functional requirements.
• The non-functional requirement can include the performance of the software product,
its scalability, or its usability.
• It provides a great influence on customers regarding their satisfaction with the product.
• Non-Functional testing deals with:
o The time taken by the software product to complete a particular task.
o The response time of the software product.
o Compatibility of the software product.
o Compliance of the software product.

DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE

CS3591 – COMPUTER NETWORKS

FOURTH SEMESTER

QUESTION BANK

UNIT 1- INTRODUCTION AND APPLICATION LAYER

PART A QUESTIONS

1.What is Object-Oriented Analysis?

During object-oriented analysis there is an emphasis on finding and describing the objects or
concepts in the problem domain. For example, in the case of the flight information system,
some of the concepts include Plane, Flight, and Pilot.

2. What is Object-Oriented Design?

During object-oriented design (or simply, object design) there is an emphasis on defining
software objects and how they collaborate to fulfill the requirements. The combination of these
two concepts shortly known as object oriented analysis and design.

3. What is Object-Oriented Analysis and Design?

During object-oriented analysis there is an emphasis on finding and describing the objects or
concepts in the problem domain. For example, in the case of the flight information system,
some of the concepts include Plane, Flight, and Pilot.

During object-oriented design (or simply, object design) there is an emphasis on defining
software objects and how they collaborate to fulfill the requirements. The combination of these
two concepts shortly known as object oriented analysis and design.

4. What is Analysis and Design?

Analysis emphasizes an investigation of the problem and requirements, rather than a solution.
Design emphasizes a conceptual solution (in software and hardware) that fulfills the
requirements, rather than its implementation. For example, a description of a database schema
and software objects.

5. Define Design Class Diagrams

A static view of the class definitions is usefully shown with a design class diagram. This
illustrates the attributes and methods of the classes.

6. What is the UML?

The Unified Modeling Language is a visual language for specifying, constructing and
documenting the artifacts of systems.
7. What are the three ways and perspectives to Apply UML?

Ways - UML as sketch, UML as blueprint, UML as programming language

Perspectives-Conceptual perspective, Specification (software) perspective, Implementation
(Software) perspective.

8. What is Inception?

Inception is the initial short step to establish a common vision and basic scope for the Project.
It will include analysis of perhaps 10% of the use cases, analysis of the critical non-Functional
requirement, creation of a business case, and preparation of the development Environment so
that programming can start in the elaboration phase. Inception in one Sentence: Envision the
product scope, vision, and business case.

9. What Artifacts May Start in Inception?

Some sample artifacts are Vision and Business Case, Use-Case Model, Supplementary
Specification, Glossary, Risk List & Risk Management Plan, Prototypes and proof-ofconcepts
etc.

10. Define Requirements and mention its types.

Requirements are capabilities and conditions to which the system and more broadly, the project
must conform.
1. Functional
2. Reliability
3. Performance
4. Supportability

11. What are Actors?

An actor is something with behavior, such as a person (identified by role), computer system,
or organization; for example, a cashier.

12. What is a scenario?

A scenario is a specific sequence of actions and interactions between actors and the system; it
is also called a use case instance. It is one particular story of using a system, or one path through
the use case; for example, the scenario of successfully purchasing items with cash, or the
scenario of failing to purchase items because of a credit payment denial.

13. Define Use case. A use case is a collection of related success and failure scenarios that
describe an actor using a system to support a goal. Use cases are text documents, not diagrams,
and use-case modeling is primarily an act of writing text, not drawing diagrams.

14. What are Three Kinds of Actors?

Primary actor, Supporting actor, offstage actor.

15. What Tests Can Help Find Useful Use Cases?

1. The Boss Test

2. The EBP Test
3. The Size Test 16.

17.What are Use Case Diagrams?

A use case diagram is an excellent picture of the system context; it makes a good context
diagram that is, showing the boundary of a system, what lies outside of it, and how it gets used.
It serves as a communication tool that summarizes the behavior of a system and its actors.

18. What are Activity Diagrams?

A diagram which is useful to visualize workflows and business processes. These can be a useful
alternative or adjunct to writing the use case text, especially for business use cases that describe
complex workflows involving many parties and concurrent actions.

19. List the relationships used in use cases?

1.Include
2.Extend
3.Generalize
20.List out the steps for finding use cases.

❖ Identifify the actor Name the use cases

❖ Describe the usecse by using terminologies.

21. What is an object?

An object is a combination of data and logic; the representation of some real-world entity.

22. What is the main advantage of object-oriented development?

• High level of abstraction

• Seamless transition among different phases of software development
• Encouragement of good programming techniques.
• Promotion of reusability.

23. What is Object Oriented System development methodology?

Object oriented system development methodology is a way to develop software by building

self-contained modules or objects that can be easily replaced, modified and reused.

24. Distinguish between method and message in object.

Method Message

i) Methods are similar to functions, procedures or subroutines in more traditional programming

languages. Message essentially are non-specific function calls.

ii) Method is the implementation. Message is the instruction.

iii) In an object oriented system, a method is invoked by sending an object a message. An object
understands a message when it can match the message to a method that has the same name as
the message.

PART B QUESTIONS
1.What is the unified process?Is the UP iterative and incrementa?Expalin.
2.Explain about Unified process phases?
3.Explain about use case model for a case study of your choice?
4.List out the various UML diagrams?
5.Write about Inception
6.Discuss about relationships in use case diagrams?

PART C QUESTIONS

1. Draw the use case diagram FOR Online recruitment system.

2. Draw the use case diagram for the following:
A coffee machine dispense coffee to customers. Customers order coffee by selecting a
recipe from a set of recipes. Customers pay for the bill using coins. Change is given back, if
any. The service staff loads ingredients(coffee power,milk,sugar,water,chocolate) into the
coffee machine. The service staff can also add a recipe by indicating the name of the coffee,
the units coffee power, milk,sugar to be added as well as the cost of the coffee?
3. Design a use case diagram for a library management system with the following actors:
Librarian, Member, and Administrator. Include at least eight use cases and show their
interactions
4. For the library management system, develop a use case scenario for the "Borrow Book"
use case. Include interactions between the Member and the Librarian.

UNIT 2- TRANSPORT LAYER

PART A QUESTIONS

1. What is domain model? List the steps involved in creating a domain model.
A domain model is a visual representation of conceptual classes or real- world objects
in a domain of interest. They have also been called conceptual models, domain object models,
and analysis object models.
The steps involved in creating a domain model are
1. Find the conceptual classes
2. Draw them as classes in a UML class diagram
3. Add associations and attributes
2. List the elements not suitable in a domain model.
The elements not suitable in a domain model are:
1. Software artifacts, such as a window or a database, unless the domain being modeled
are of software concepts, such as a model of graphical user interfaces.
 2. Responsibilities or methods.
3.State the reason to avoid adding many associations.
.We need to avoid adding too many associations to a domain model.
In discrete mathematics, in a graph with n nodes, there can be associations to other
nodes a potentially very large number. A domain model with 20 classes could have 190
associations’ lines! Many lines on the diagram will obscure it with "visual noise." Therefore,
be parsimonious about adding association lines.
4. What is 100% rule?
100% of the conceptual Super class’s definition should be applicable to the subclass.
The subclass must conform to 100% of the Super class’s attributes and associations.
5. Write the guidelines followed in defining a super class.
The guidelines are:
Create a super class in a generalization relationship to subclasses when :
1. The potential conceptual subclasses represent variations of a similar concept
2. The subclasses will confirm to the 100% and Is-A rules
3. All subclasses have the same attribute that can be factored out and expressed in the super
class
4. All subclasses have the same association that can be factored out and related to the super
Class
6. What are the strong motivations to partition a conceptual class with subclasses?
The following are the strong motivations to partition a class into subclasses :
Create a conceptual subclass of a super class when :
1. The subclass has additional attributes of interest
2. The subclass has additional associations of interest
3. The subclass concept is operated on, handled, reacted-to, or manipulated differently than
the super class or other subclasses
7. Define – Requirements
Requirements are capabilities and conditions, to which the system and more broadly,
the project must conform,
1) The UP promotes a set of best practices, one of which is to manage requirements.
2) In the context of changing and unclear stakeholder’s wishes – Managing requirements means
a systematic approach to finding, documenting, organizing, and tracking the changing
requirements of a system.
A prime challenge of requirements analysis is to find, communicate, and remember (To write
down) what is really needed, in a form that clearly speaks to the client and development team
members.
8. List the types and categories of requirements.
In the UP, requirements are categorized as the following,
1. 2) Functional - features, capabilities, security.
2. 3) Usability - human factors, help, documentation.
3. 4) Reliability - frequency of failure, recoverability, predictability.
4. 5) Performance - response times, throughput, accuracy, availability, resource usage.
5. 6) Supportability - adaptability, maintainability, internationalization, configurability.
9.Define Class Diagram.
Class diagram is a static diagram. It represents the static view of an application. Class
diagram describes the attributes and operations of a class and also the constraints imposed on
the system. Class diagram shows a collection of classes, interfaces, associations,
collaborations, and constraints. It is also known as a structural diagram
10. Define Classifier
A UML classifier is "a model element that describes behavioral and structure features".
In class diagrams the two most classifiers are regular classes and interfaces.
11.Define Generalization
Generalization in the UML is shown with a solid line and fat triangular arrow from
the subclass to superclass. Generalization is a taxonomic relationship between a more general
classifier and a more specific classifier. Each instance of the specific classifier is also an
indirect instance of the general classifier.
12. Define Abstract Classes
Abstract classes and operations can be shown either with an {abstract} tag (useful
when sketching UML) or by italicizing the name.
13.Define elaboration
Elaboration is the initial series of iterations during which the team does serious
investigation, implements (programs and tests) the core architecture, clarifies most
requirements, and tackles the high-risk issues.
14. Why Description Classes are used?
• To retrieve the details of an item which does not exist anywhere else
• .To maintains a record of an item that carries information apart from its basic details.
15. Shared Aggregation—Hollow Diamond
 Shared aggregation means that the multiplicity at the composite end may be more than
one, and is signified with a hollow diamond. It implies that the part may be simultaneously in
many composite instances.

PART B QUESTIONS
1.Explain in detail about class diagrams?
2.Discuss about elaboration?
3.Write about the relationship between sequence diagrams and use case?
4.Explain about associations and compositions
5. Describe the strategies used to identify conceptual classes. Describe the steps to create a
domain model used for representing conceptual classes.
6. Analyze the concepts of Descriptions classes with the mobile phone Domain.
7. Discuss the uses, concepts and notations are used in Sequence Diagram
8. Analyze the guidelines to define a conceptual subclass with suitable example.
PART C QUESTIONS
1.Describe the strategies used to identify the conceptual classes? Describe the steps to create
a Domain model for representing the conceptual classes?
2.Write about elaboration and discuss the differences between elaboration and inception
with suitable diagrams for University domain?
3. For the Next Gen POS systems design, explain the following Conceptual class
hierarchies. (i). Conceptual super class (3) (ii).Conceptual subclass (4) (iii). Authorization
Transaction classes.(4) (iv). Abstract Conceptual classes. (4)
4. Classify the following Items and justify your answer. (15) Bike, tiger , chair, man, dog,
lion, child, spider, crocodile, fish, boat, aeroplane, mango, pineapple, deer, horse.

UNIT 3- NETWORK LAYER

PART A QUESTIONS

1.What is an activity diagram?

A UML activity diagram shows sequential and parallel activities in a process. They are useful
for modeling business processes, workflows, data flows, and complex algorithms. Basic UML
activity diagram notation illustrates an action, partition, fork, join, and object node. In essence,
this diagram shows a sequence of actions, some of which may be parallel. Most of the notation
is self-explanatory;

2.What is meant by System Sequence Diagrams? APRIL/MAY-2011

A system sequence diagram (SSD) is a picture that shows, for a particular scenario of a use
case, the events that external actors generate their order, and inter-system events. All systems
are treated as a black box; the emphasis of the diagram is events that cross the system boundary
from actors to systems.

System behavior is a description of what a system does, without explaining how it does it. One
Part of that description is a system sequence diagram. Other parts include the Use cases, and
system contracts(tobediscussedlater).

4. What is meant by Inter-System SSDs?

SSDs can also be used to illustrate collaborations between systems, such as between the Next
Gen POS and the external credit payment authorizer. However, this is deferred until a later
iteration in the case study, since this iteration does not include remote systems collaboration.
4. Define System Events and the System Boundary.

5. How to Naming System Events and Operations?

System events (and their associated system operations) should be expressed at the level of
intent rather than in terms of the physical input medium or interface widget level.

It also improves clarity to start the name of a system event with a verb Thus "enter item" is
better than "scan" (that is, laser scan) because it captures the intent of the operation while
remaining abstract and noncommittal with respect to design choices about what interface is
used to capture the system event.

6. What is meant by interaction diagram?

The term interaction diagram is a generalization of two more specialized UML diagram types;
both can be used to express similar message interactions: . Collaboration diagrams . Sequence
diagrams

7. What is meant by link?

A link is a connection path between two objects; it indicates some form of navigation And
visibility between the objects is possible . More formally, a link is an instance of an association.
For example, there is a link or path of navigation from a Register to a Sale, along which
messages may flow, such as the make 2 Payment message.

8. What is meant by Messages?

Each message between objects is represented with a message expression and small arrow
indicating the direction of the message. Many messages may flow along this link. A sequence
number is added to show the sequential order of messages in the current thread of control.

9. How to create an instance?

Any message can be used to create an instance, but there is a convention in the UML to use a
message named create for this purpose. If another (perhaps less obvious) message name is used,
the message may be annotated with a special feature called a UML stereotype, like so: «create».
The create message may include parameters, indicating the passing of initial values. This
indicates, for example, a constructor call with parameters in Java.

10.Define Events, States, and Transitions. APRIL/MAY-2011

An event is a significant or noteworthy occurrence. For example: A telephone receiver is taken

off the hook. A state is the condition of an object at a moment in time—the time between
events. For example:

• A telephone is in the state of being "idle" after the receiver is placed on the hook and until it
Is taken off the hook. A transition is a relationship between two states that indicates that when
an event occurs, the Object moves from the prior state to the subsequent state. For example: •
When the event "off hook" occurs, transition the telephone from the "idle" to "active" state.

11. What is meant by State chart Diagrams?

A UML state chart diagram, illustrates the interesting events and states of an object, and the
behavior of an object in reaction to an event. Transitions are shown as arrows, labeled with
their event. States are shown in rounded rectangles. It is common to include an initial pseudo-
state, which automatically transitions to another state when the instance is created.

12. State chart Diagrams in the UP?

There is not one model in the UP called the "state model." Rather, any element in any model
(Design Model, Domain Model, and so forth) may have a state chart to better understand or
communicate its dynamic behavior in response to events. For example, a state chart associated
with the Sale design class of the Design Model is itself part of the Design Model.

13. Utility of Use Case State chart Diagrams.

- Hard-coded conditional tests for out-of-order events - Use of the State pattern (discussed in
a subsequent chapter) - disabling widgets in active windows to disallow illegal events (a
desirable approach) - A state machine interpreter that runs a state table representing a use case
State chart diagram.

14. List out the types of Events.

-External event Internal event Temporal event

15. Define External event.

External event—also known as a system event, is caused by something (for example, an actor)
outside our system boundary. SSDs illustrate external events. Noteworthy external events
precipitate the invocation of system operations to respond to them.
- When a cashier presses the "enter item" button on a POS terminal, an external event has
occurred.

16. Define internal event.

Internal event—caused by something inside our system boundary. In terms of software, an

internal event arises when a method is invoked via a message or signal that was sent from
another internal object. Messages in interaction diagrams suggest internal events. - When a
Sale receives a make Line item message, an internal event has occurred.
17. Define temporal event.

Temporal event—caused by the occurrence of a specific date and time or passage of time. In
terms of software, a temporal event is driven by a real time or simulated-time clock.

-Suppose that after an end Sale operation occurs, a make Payment operation must occur within
five minutes, otherwise the current sale is automatically purged.

PART B QUESTIONS

1.What is the purpose of state chart diagrams?How to draw state chart diagram?Explain

2.Discuss about UML deployment and component diagrams.Draw the diagrams for banking
application?

3.Explain UML activity diagram with example?

3.Explain about sequence diagram?

4. Describe UML state machine diagram and modeling.

5. (i).Compare sequence diagram and communication diagram with suitable example.

(ii).Explain the Concepts of frames in UML.

6. Compare sequence versus collaboration diagram with suitable example

PART C QUESTIONS

1.Draw the UML diagrams for the following applications:

a)ATM system

b)Library management system.

2.Draw the UML diagram for Airline reservation systems.

3.Construct the Sequence diagram for NEXTGEN POS.

4. Consider the Hospital Management System application with the following

requirements

(i) System should handle the in-patient, out-patient information through receptionist.

(ii) Doctors are allowed to view the patient history and give their prescription.
(iii) There should be a information system to provide the required information.

Give the state chart, component and deployment diagrams.

5. With suitable example explain the notations used in Sequence Diagram for the foll: Object

Destruction, frames, Conditional Message, Mutually exclusive message, Iterations over a

collection.

UNIT-IV - ROUTING

PART A QUESTIONS

1. Distinguish between coupling and cohesion.

Cohesion Coupling
1 Cohesion refers to what the class (or module) It refers to how related are two classes /
modules and how dependent they are on each
will do. Low cohesion would mean that the
other. Being low coupling would mean that
class does a great variety of actions and is not
changing something major in one class should
focused on what it should do. High cohesion
not affect the other. High coupling would make
would then mean that the class is focused on
your code difficult to make changes as well as
what it should be doing, i.e. only methods
to maintain it, as classes are coupled closely
relating to the intention of the class
together, making a change could mean an entire
system revamp

2 High cohesion within modules Low coupling betweenmodules.

3 Increased cohesion and decreased coupling The most effective method of decreasing
do
coupling and increasing cohesion is
leads to good software design.
design by interface

2. List the steps involved in mapping design to code.

 The steps involved in mapping design to code are,

1. Class and interface definitions

The required visibility and associations between classes are indicated by the interaction

diagrams.

2. Method definitions

A method body implementation may be shown in a UML note box. It should be placed

within braces, it is semantic influence. The syntax may be pseudo-code, or any language 3.
3.Mention the Interface and Domain Layer Responsibilities.

The UI layer should not have any domain logic responsibilities. It should only be responsible
for user interface tasks, such as updating widgets. The UI layer should forward requests for
all domain-oriented tasks on to the domain layer, which is responsible for handling them.

4. Define patterns.

A pattern is a named problem/solution pair that can be applied in new context, with advice
on how to apply it in novel situations and discussion of its trade-offs.

5. List out GRASP Patterns?

• Information Expert .
• Creator .
• High Cohesion .
• Low Coupling .
• Controller

6. What is meant by responsibilities? List the types of responsibilities.

The UML defines a responsibility as “a contract or obligation of a classifier”.

Responsibilities are related to the obligations or behavior of an object in terms of its role. The
responsibilities are of the following two types: doing and knowing.
Doing responsibilities of an object include:

• doing something itself, such as creating an object or doing a calculation

• initiating action in other objects

• controlling and coordinating activities in other objects

Knowing responsibilities of an object include:

• knowing about private encapsulated data

• knowing about related objects

• knowing about things it can derive or calculate

7. Who is creator?

Solution Assign class B the responsibility to create an instance of class A if one or more of
the following is true:

• B aggregates an object.
• B contains an object.
• B records instances of objects.
• B closely uses objects.
• B has the initializing data that will be passed to A when it is created (thus B is
an Expert with respect to creating A).
• B is a creator of an object.
• If more than one option applies, prefer a class B which aggregates or contains
class A.

8. List out some scenarios that illustrate varying degrees of functional cohesion

• Very low cohesion

• low cohesion
• High cohesion
• Moderate cohesion
9. Define Modular Design.

Coupling and cohesion are old principles in software design; designing with objects does not
imply ignoring well-established fundamentals. Another of these. Which is strongly related to
coupling and cohesion? is to promote modular design.

10. What are the advantages of Factory objects?

• Separate the responsibility of complex creation into cohesive helper objects.

• Hide potentially complex creation logic.

• Allow introduction of performance-enhancing memory management strategies, such as

object caching or recycling.

11. Designing for Non-Functional or Quality Requirements.

Interestingly—and this a key point in software architecture—it is common that the large-
scale themes, patterns, and structures of the software architecture are shaped by the designs
to resolve the non-functional or quality requirements, rather than the basic business logic.

12. What is meant by Abstract Class Abstract Factory?

A common variation on Abstract Factory is to create an abstract class factory that is accessed
using the Singleton pattern, reads from a system property to decide which of its subclass
factories to create, and then returns the appropriate subclass instance. This is used, for
example, in the Java libraries with the java.awt.Toolkit class, which is an abstract class
abstract factory for creating families of GUI widgets for different operating system and GUI
subsystems.

14. What is meant by Fine-Grained Classes?

Consider the creation of the Credit Card, Driver’s License, and Check software objects. Our
first impulse might be to record the data they hold simply in their related payment classes,
and eliminate such fine-grained classes. However, it is usually a more profitable strategy to
use them; they often end up providing useful behavior and being reusable.
15. Define coupling. APIRAL/MAY-2011

The degree to which components depend on one another. There are two types of
coupling, "tight" and "loose". Loose coupling is desirable for good software engineering but
tight coupling may be necessary for maximum performance. Coupling is increased when the
data exchanged between components becomes larger or more complex.

PART B QUESTIONS

1. What is GRASP? Explain the GRASP patterns creator, Information Expert, low coupling,
High cohesion?

2. Explain in detail about Adaptor, singleton, Factory.

3. Explain GRASP: designing objects with responsibilities.

4. Describe the features of Low Coupling and High Coupling with suitable example.

5. i) Compare Cohesion and Coupling with Suitable example)

ii) State Roles and Patterns while Developing systems

7. i) Differentiate Bridge and Adapter.

ii) How will you Design the Behavioral Pattern.

PART C QUESTIONS

1. Compare cohesion and coupling with suitable examples?

2. How will you design behavioral pattern?

3. Consider the following design goals. Indicate the candidate patterns(s) you would consider
to satisfy each goal:

a) Given a legacy banking application, encapsulate the existing business logic component.

b) Given a chess program, enable future developers to substitute the planning algorithm
that describes the next move with a better one. .
 c) Given a chess program, enable a monitoring component to switch planning algorithms
at runtime, based on the opposing player's style and response time.

d) You are developing a system that stores its data on a Unix file system. You antcipate
that you will port future versions of the system to other operating systems that provide
different file systems.

UNIT 5 – DATA LINK AND PHYSICAL LAYERS

PART A QUESTIONS

1. Write about the four phases in OMT?

OMT consists of four phases. They are

✓ Analysis-The results are objects and dynamic & functional models.

✓ System design-The results are a structure of the basic architectureof the system along with
high-level strategy decisions.
✓ Object Design-Produces a design document, consisting of detailed
✓ objects static, dynamic and functional models

Implementation-This activity produces reusable, extendible, robust code.

2. What do you mean by object diagram?

• The object model of OMT is represented graphically with an object diagram.

• The object diagram contains classes interconnected by association lines.
• Each class represents a set of individual objects.
• The association lines establish relationships among the classes. Each association line
represents a set of links from the objects of one class to theobjects of another class

3. What are the primary symbols used in Data Flow Diagrams?

Data flow diagrams use four primary symbols:

• The process is any function being performed.(verify password in theATM)

• The data flow shows the direction of data element movement.(PINcode)
 • The data store is a location where data are stored.(Account in ATM)
• An external entity is a source or destination of a data element .(theATM card reader)

4. What are the diagrams used in Booch methodology?

The Booch methodology consists of the following diagrams:

Class diagrams.

Object diagrams.

State transition diagrams.

Module diagrams.

Process diagrams.

Interaction diagrams.

5. Give the steps involved in Macro development process in Booch methodology.

The macro development process consists of the following steps:

o Conceptualization- Establish the core requirements and develop a prototype.

o Analysis and development of the model-Use the class diagram to describe the roles and
responsibilities of objects. Use the object diagram to describe the desired behaviour of the
system.

o Design or create the system architecture. -Use the class diagram to decide what classes exist
and how they relate to each other, the object diagram to decide what mechanisms are used, the
module diagram to map out where each class and object should be declared, and the process
diagram to determine to which processor to allocate a process.

o Evolution or implementation- Refine the system through much iteration.

o Maintenance-Make localized changes to the system to add new requirements and eliminate

bugs.

6. Give the steps involved in Micro development process in Booch methodology.

The micro process is a description of the day-to-day activities by a single or small group of
software developers. It consists of the following steps.

1. Identify classes and objects.

2. Identify class and object semantics.
 3. Identify class and object relationships.
4. Identify class and object interface and implementation.

7. Write briefly about Use Cases.

Use cases are scenarios for understanding system requirements. A use case is an interaction
between users and a system. The use-case model captures the goal of the user and the
responsibility of the system to its users. The use-case model employs extends and uses
relationships. The use cases are described as one of the following:

o Non-formal text with no clear flow of events

o Text with a clear flow of events

o Formal style using pseudo code.

8. Write short note on Objectory.

Object-oriented software engineering (OOSE), also called Objectory, is a method or object-

oriented development with the specific aim to fit the development of large, real-time systems.
Objectory, is a disciplined process forthe industrialized development of software, based on a
use-case driven design. Objectory is built around several different models:

Use case-model.

Domain object model.

Analysis object model.

Implementation model.

Test model.

9. Define proto-patterns.

A proto-pattern is the “pattern in waiting” which is not yet known to recur. It is the pattern
waiting to undergo some degree of peer scrutiny or review.

10.Define patterns template. Give some examples for components in pattern.

Every pattern must be expressed in the form of a rule which is called as a

template. It should establish a relationship between a context, a system of forces

which arises in the context, and a configuration. Some of the essential

components are:
 • Name

• Problem

• Context

• Forces

• Solution

• Examples

11. Define anti-patterns.

An anti-pattern represents a worst practice while a pattern represents a best

practice. Anti-patterns come in two varieties:

• Those describing a bad solution to a problem that resulted in a bad situation.

• Those describing how to get out of a bad situation

12.Define pattern mining. Give the steps involved in capturing pattern.

The process of looking for patterns to document is called pattern mining sometimes called
reverse architecting. The steps involved are:

Focus on practicability-Patterns should describe proven solutions to problems rather than the
latest scientific results.

Aggressive disregard of Originality-Pattern writers do not need to be the original inventor of

the solution.

Non anonymous review- Pattern submissions are shepherded rather than reviewed.

Writers’ workshops instead of presentations- Rather than being presented by the authors,
the patterns are discussed in the writers’ workshops.

13. Define frame work.

A frame work is a way of presenting a generic solution to a problem that can be applied to all
levels in a development. Frameworks are a way of delivering application development patterns.
A framework provides architectural guidance, captures the design decisions that are common
to its application domain and thus emphasize design reuse over code reuse.

14. Give the differences between design patterns and frameworks.

The major differences between design patterns and frameworks are as follows:
 o A framework is executable software whereas design patterns represent knowledge
and experience about the software.

o Design patterns are more abstract than frameworks.

15.Why do we go for unified approach?

The main motivation for going to unified approach is to combine the best practices, processes,
methodologies, and guidelines along with UML (UnifiedModeling Language) notations and
diagrams for better understanding object oriented concepts and system development.

16.Write short note on UA proposed Repository.

The repository allows the maximum reuse of previous experience and previously defined
objects, patterns, frameworks, and user interfaces in an easily accessible manner with a
completely available and easily utilized format.

17.Define model.

A model is an abstract representation of a system, constructed to understand the system prior

to building or modifying it. It is a model of a simplified representation of reality. Models can
represent static or dynamic situations.

18.Explain about the types of model.

• Static model-It can be viewed as a snapshot of a system’s parameters at rest or a specific

point in time. They are needed to represent the structural or static aspect of a system. The UML
class diagram is an example of static model.

• Dynamic model-It can be viewed as a collection of procedures or behaviors that taken

together reflect the behavior of a system over time. Dynamic modelling is the most useful
during the design and implementation phases of the system development. The UML interaction
diagrams and activity models are examples of dynamic models.

19.What is software quality assurance?

Quality Assurance (QA) is defined as an activity to ensure that an organization is providing

the best possible product or service to customers. QA focuses on improving the processes to
deliver Quality Products to the customer. An organization has to ensure, that processes are
efficient and effective as per the quality standards defined for software products. Quality
Assurance is popularly known as QA Testing.

20.What is unit testing?

Unit testing is a software testing method by which individual units of source code which are
sets of one or more computer program modules together with associated control data, usage
procedures, and operating procedures are tested to determine whether they are fit for use.

PART B QUESTIONS

1.Explain briefly about Rumbaugh’s Methodology.

2.Explain Booch Methodology in detail.

3.Explain various testing strategies.

4 Write short notes about Jacobson Methodology.

5.Expalin Patterns and various pattern templates.

6.Briefly explain about Framework.

7. Develop the test cases for Bank ATM System .Sketch the Class diagram, Object diagram
and State transition diagram based on Booch methodology.

PART C QUESTIONS

1. Explain in detail about test plan

2. Discuss the various issues in OO testing?

3. Construct the guidelines for developing test plans. (15) ( Create )

• You may have requirements that dictate a specific appearance orformat for your test
plan.

• The test plan should contain a schedule and a list of required resources.

• After you have determined what types of testing are necessary, you need to document

specifically what you are going to do.

• A configuration control system provides a way of tracking the changes to the code. At
a minimum, every time the code changes, a record should be kept that tracks which
module has been changed, who changed it, and when it was altered.

• A well thought out design tends to produce better code and result in more complete
testing, so it is a good idea to try to keep the plan up to date.

• At the end of each month or as you reach each milestone, take time to complete routine
updates
4. Design a burglar alarm system with necessary diagrams based on Booch methodology. List
down the micro development process steps for the alarm system.

Question Paper Code 90161

B.E/B.Tech DEGREE EXAMINATIONS, NOVEMBER/DECEMBER 2019
FOURTH Semester
ARTIFICIAL INTELLIGENCE AND DATA SCIENCE
CS3591– COMPUTER NETWORKS
(Common to Computer and Communication Engineering)
(Regulations 2017)
Time:3hours Maximum:100Marks

PART-A

1. Define an object? Give example.

2. What is a use case diagram?

3. Define multiplicity of association?

4. What is an association class? Give example.

5. Outline the advantages of modeling a state machine diagram.

6. What is a deployment diagram?

7. Define coupling and cohesion?

8. What is a design pattern?

9. Define software quality assurance.

10. What is unit testing?

PART-B
11. a) i) Outline the steps to be followed to identify actors and use cases.

ii) What is inception? Outline the tasks that a project team performs during inception.
 (OR)

b) Let’s say you own a small baking company, where you make and design custom cakes
for different occasions. You now wish to take your business online, so that you could cater to
a large customer base. You hire a web development company to build an online cake store for
you. This software product is built on the basis of the Unified Process Model(UPM).

Define and explain UPM with its phases for developing the above online banking company.

12. a) i) Outline aggregation and composition, with an example.

ii) Elaborate generalization and specialization with an example.

(OR)

b) Outline the steps in modelling a sequence diagram with an example.

13. a) What is the purpose, how to draw and where to use UML component diagrams?
Illustrate with an example.

(OR)

b) Why to use an activity diagrams? Outline the steps in modelling an activity diagram
with an example.

14. a) Outline the GRASP principles with suitable example.

(OR)

b) What are GoF patterns? Outline the application of GoF design patterns with suitable
example.

15. a) Outline the object oriented testing strategies.

(OR)

b) What is a test case? Describe in detail the test case design for OO software with
relevant examples.

PART-C

16. a) Develop a use case model for activities involved in ordering food in a restaurant from
the point when the customer enters a restaurant to the point when he leaves the restaurant.

(OR)
 b) Model a class diagram for a “Library Management System”. State the functional
requirements you are considering.
 ARUNACHALA COLLEGE OF ENGINEERING FOR WOMEN
DEPARTMENT OF CSE
INTERNAL TEST I
CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
CLASS: III CSE A & B
PART A (10*2=20)
1 CO1 K4 Design a partial domain model of Dice game.
2 CO1 K4 What is usecase? List its types.
3 CO1 K1 What is UML? List its types.
4 CO1 K1 Define requirements. Mention its types.
5 CO1 K1 List out the artifacts in elaboration.
6 CO1 K1 What is OOA and OOD?
7 CO1 K1 List out the process sale steps.
8 CO1 K1 Define class diagram.
9 CO1 K1 What is black box usecase?
10 CO1 K1 What tests help to find useful usecases?

PART B (2*15=30)
11.a.i CO1 K2 Describe in detail about inception(10)
11.a.ii CO1 K4 Design usecase diagram for any real time scenarios.(5)
OR
11b.i CO1 K2 Explain in detail about nextGen POS.(10)
11b.ii CO1 K4 Design usecase diagram for library management.(5)
12.a. CO1 K2 Explain in detail about relating usecases(15)
OR
12.b.i CO1 K4 Design usecase diagram for university exam registration.(7)
12.b.ii CO1 K2 Explain in detail about unified process.(8)
 ARUNACHALA COLLEGEOF ENGINEEERING FOR WOMEN
MANAVILAI, VELLICHANTHAI- 629 203
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
INTERNAL EXAM – II
Class: S5 CSE-A&B
Total Marks: 50
Subject Name & Code : Object Oriented Analysis and Design/ CS8592 Time :
9.10 – 10.40AM

PART-A (10x2=20 marks)

Question Cognitive
Questions CO
No. Level
1 Define Requirement. CO 2 K1
2 Define description classes. CO 2 K1
3 What is aggregation? Illustrate with example. CO 2 K2
4 Write the guidelines followed in defining a super class CO 2 K1
5 Define Elaboration ? list its artifacts. CO 2 K1
6 Define event, state, transition. Illustrate with example CO 3 K2
7 What is external event? CO 3 K1
8 Compare internal , temporal event. CO 3 K1
9 What is meant by state chart diagram? CO 3 K1
10 What is activity diagram ? CO 3 K1

PART-B (2x15=30marks)
Question Cognitive
Questions CO
No. Level
11)a.i Explain in detail about conceptual class hierarchy with CO 2 K2
neat example(10)
ii Implement the partial domain model of POS with CO 2 K3
attributes(5)
OR
11)bi. Explain domain model Refinement in detail(10) CO 2 K2
 ii Implement the partial domain model of POS with CO 2 K3
necessary associations(5)
12)a. Explain detail about SSD with necessary notations. (15) CO 3 K2
OR
12)b.i Explain package diagram in detail with its required CO 3 K2
symbols.(10)

ii) Design the Activity diagram for POS(5) CO3 K3

 ARUNACHALA COLLEGE OF ENGINEERING FOR WOMEN
DEPARTMENT OF CSE
Internal Assessment III
CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
CLASS: III CSE A & B Time: 1.5hrs
PART A (10*2=20)

1 CO4 K1 What is GRASP?

2 CO4 K2 What is meant by responsibilities? List out its types
3 CO4 K1 Define coupling.
4 CO4 K2 Define cohesion.
5 CO4 K1 Who is creator?
6 CO5 K1 Define anti pattern.
7 CO5 K1 What is frame work?
8 CO5 K1 What do you mean by UA?
9 CO5 K1 Write short notes on UA based repository.
10 CO5 K1 Define pattern template and list the components.
PART B (2*15=30)

11.a. CO4 K2 Explain the following pattern.

i.Bridge
ii.Information Expert
iii.Factory

11.b. CO4 K3 How will you map design to code? Convert your NextGen POS
design into its code
12.a. CO 5 K3 Explain the Rumbaugh’s object Modeling technique and create
the model for it
OR
12.b. CO5 K2 Explain in detail about test case and test plan.
 ARUNACHALA COLLEGE OF ENGINEERING FOR WOMEN
DEPARTMENT OF CSE
INTERNAL TEST I-Answer key
CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
CLASS: III CSE A & B
PART A (10*2=20)

1 CO1 K4 Design a partial domain model of Dice game.

2 CO1 K4 What is usecase? List its types.

Use cases are text stories widely used to discover and record
requirements.They are text stories of some actor using a system to meet
goals.Types are concrete use case ,abstract use case, base use case.
3 CO1 K1 What is UML? List its types.
The Unified Modeling Language is a visual language for specifying,
constructing and documenting the artifacts of systems. There are two broad
categories of diagrams and they are again divided into subcategories −
1. Structural Diagrams
2. Behavioral DiagramS

4 CO1 K1 Define requirements. Mention its types.

Requirements are capabilities and conditions to which the system and more
broadly, the project must conform.
1. Functional
2. Reliability
3. Performance
4. Supportability
5 CO1 K1 List out the artifacts in elaboration.
1. Domain Model.
2. Design Model
3. Software Architecture Document
4. Data Model
5. Test Model
6. Implementation Model
7. Use-Case Storyboards,UI Prototypes
 6 CO1 K1 What is OOA and OOD?
During object-oriented analysis there is an emphasis on finding and
describing the objects or concepts in the problem domain. For example,
in the case of the flight information system, some of the concepts include
Plane, Flight, and Pilot.

During object-oriented design (or simply, object design) there is an

emphasis on defining software objects and how they collaborate to fulfill
the requirements. The combination of these two concepts shortly known as
object oriented analysis and design.
7 CO1 K1 List out the process sale steps.
1. Customer arrives at a POS checkout with goods and/or services to
purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price, and
running total. Price calculated from a set of price rules. Cashier repeats
steps 2-3 until indicates done.
5. System presents total with taxes calculated.
6. Cashier tells Customer the total, and asks for payment.
7. Customer pays and System handles payment
. 8. System logs the completed sale and sends sale and payment information
to the external Accounting (for accounting and commissions) and
Inventory systems (to update inventory).
9. System presents receipt.
10.Customer leaves with receipt and goods (if any).

8 CO1 K1 Define class diagram.

A static view of the class definitions is usefully shown with a design class
diagram. This illustrates the attributes and methods of the classes.
9 CO1 K1 What is black box usecase?
The black-box views of a system describe a software system's external
behavior. The internal workings of the software system, such as the internal
software objects and their interactions, are not shown in the black-
box views. Black-box views show how the system interfaces with its actors and
other external objects.
10 CO1 K1 What tests help to find useful usecases?
1. The Boss Test
2. The EBP Test
3. The Size Test 16.

PART B (2*15=30)

5.a.i CO1 K2 Describe in detail about inception(10)

 Inception is the initial short step to establish a common vision and basic scope for the
project.Inception is Envision the product scope, vision, and business case..

5.a.ii CO1 K4 Design usecase diagram for any real time scenarios.(5)

OR
5b.i CO1 K2 Explain in detail about nextGen POS.(10)
❖ The case study is the NextGen point-of-sale (POS) system
❖ A POS system is a computerized application used (in part) to record sales and
handle payments;
Architectural Layers
 A typical object-oriented information system is designed in terms of several
architectural layers or subsystems . The following is not a complete list, but provides
an example:
• User Interface—graphical interface; windows.
• Application Logic and Domain Objects—software objects representing domain
concepts (for example, a software class named Sale) that fulfill application
requirements.
• Technical Services—general purpose objects and subsystems that provide
supporting technical services, such as interfacing with a database or error logging.
These services are usually application-independent and reusable across several
systems
5b.ii CO1 K4 Design usecase diagram for library management.(5)

6.a. CO1 K2 Explain in detail about relating usecases(15)

 Use cases can be related to each other. Organizing use cases into relationships
has no impact on the behavior or requirements of the system. It is simply an
organization mechanism to improve communication and comprehension of the use
cases, reduce duplication of text, and improve management of the use case documents.
Relationships of use case:
The Three relationships of use cases are:
1.The include Relationship
2.The extend Relationship
3.The generalize Relationship
1.The include Relationship:
❖ This is the most common and important relationship.
❖ It is common to have some partial behavior that is common across
several use cases.
❖ For example, the description of paying by credit occurs in several use
cases, including Process Sale, Process Rental, Contribute to Lay-away
Plan, and so forth.

2The extend Relationship

The extend relationship provides an answer. The idea is to create an extending
or addition use case, and within it, describe where and under what condition it extends
the behavior of some base use case.

1.8.3.The generalize Relationship:

This is an optional relationship.
It adds another level of complexity to use cases.
OR
6.b.i CO1 K4 Design usecase diagram for university exam registration.(7)
6.bii CO1 K2 Explain in detail about unified process.(8)
The UP is an iterative process. The UP promotes several best practicesiterative
development. In this approach, development is organized into a series of short, fixed-
length (for example, four week) mini-projects called iterations; the outcome of each is
a tested, integrated, and executable system.
Advantages of UP:
❖ Rapid feedback from users and developers
❖ Then adapt to changes in the next iteration (adaptive development)
❖ Visible progress
❖ Start with high risk
❖ Manage complexity by dividing the problem into smaller ones
1.2.2Risk-Driven and Client-Driven IterativePlanning?
In risk-driven and client-driven iterative planning,the goals of the early iterations are
chosen to
1) identify anddrive down the highest risks, and
2) build visible features that the client cares most about.
Risk-driven iterative development includes more specifically the practice of
architecture-centric iterative development, meaning that early iterations focus on
building, testing, and stabilizing the core architecture.
1.2.4. UP Phases:
Four phases are:
1.Inception
2.Elaboration
3.Construction.
4.Transition.
1.Inception
Approximate vision, business case, scope, vague estimates. Inception is a feasibility
phase, where just enough investigation is done to support a decision to continue or
stop.
2.Elaboration
In this phase the core architecture is iteratively implemented, and high-risk issues are
mitigated, refined vision, iterative implementation of the core architecture, resolution
of high risks, identification of most requirements and scope, more realistic estimates
are made.
3.Construction
Iterative implementation of the remaining lower risk and easier elements, and
preparation for deployment.
4.Transition
Beta tests, deployment.
 ARUNACHALA COLLEGEOF ENGINEEERING FOR WOMEN
MANAVILAI, VELLICHANTHAI- 629 203
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
INTERNAL EXAM – II-Answer key

Class: S5 CSE-A&B Total Marks: 50

Subject Name & Code : Object Oriented Analysis and Design/ CS8592
PART-A (10x2=20 marks)
Quest
Cognitive
ion Questions CO
Level
No.

Define Requirement.

Requirements are capabilities and conditions to which the system and

more broadly, the project must conform.

1. Functional
1 CO 2 K1
2. Reliability

3. Performance

4. Supportability

Define description classes.

Description classes contains description about a product and used to

2 • To retrieve the details of an item which does not exist anywhere CO 2 K1

else
• To maintains a record of an item that carries information apart
from its basic details.

What is aggregation? Illustrate with example.

Shared aggregation means that the multiplicity at the composite end

may be more than one, and is signified with a hollow diamond. It implies
that the part may be simultaneously in many composite instances.

3 CO 2 K2
 Write the guidelines followed in defining a super class

The guidelines are:

Create a super class in a generalization relationship to subclasses when :

1. The potential conceptual subclasses represent variations of a similar

concept

2. The subclasses will confirm to the 100% and Is-A rules

4 CO 2 K1
3. All subclasses have the same attribute that can be factored out and
expressed in the super

class

4. All subclasses have the same association that can be factored out and
related to the super

Class

Define Elaboration ? list its artifacts.

Elaboration is the initial series of iterations during which the

team does serious investigation, implements (programs and tests) the
5 CO 2 K1
core architecture, clarifies most requirements, and tackles the high-risk
issues.

Define event, state, transition. Illustrate with example

An event is a significant or noteworthy occurrence. For example: A

telephone receiver is taken off the hook.

A state is the condition of an object at a moment in time—the time

between events. For example:A telephone is in the state of being "idle"
6 after the receiver is placed on the hook and until it Is taken off the hook. CO 3 K2

A transition is a relationship between two states that indicates that when

an event occurs, the Object moves from the prior state to the subsequent
state. For example: When the event "off hook" occurs, transition the
telephone from the "idle" to "active" state.
 What is external event?

External event—also known as a system event, is caused by something

(for example, an actor) outside our system boundary. SSDs illustrate
7 CO 3 K1
external events. Noteworthy external events precipitate the invocation of
system operations to respond to them.

Compare internal , temporal event.

Internal event—caused by something inside our system boundary. In

terms of software, an internal event arises when a method is invoked via
a message or signal that was sent from another internal object.
8 CO 3 K1
Temporal event—caused by the occurrence of a specific date and time
or passage of time. In terms of software, a temporal event is driven by a
real time or simulated-time clock.

What is meant by state chart diagram?

There is not one model in the UP called the "state model." Rather, any
element in any model (Design Model, Domain Model, and so forth)
9 CO 3 K1
may have a state chart to better understand or communicate its dynamic
behavior in response to events.

What is activity diagram ?

A UML activity diagram shows sequential and parallel activities in a

process. They are useful for modeling business processes, workflows,
10 CO 3 K1
data flows, and complex algorithms. Basic UML activity diagram
notation illustrates an action, partition, fork, join, and object node

PART-B (2x15=30marks)
Quest
Cognitive
ion Questions CO
Level
No.

11)a.i Explain in detail about conceptual class hierarchy with neat example(10) CO 2 K2

A conceptual superclass definition is more general or encompassing

than a subclass definition.
 For example, consider the superclass Payment and its sub
classes. Assume the definition of Payment is that it represents the
transaction of transferring money for a purchase from one party to
another, and that all payments have an amount of money transferred.

Figure 2.23 Payment class hierarchy.

A CreditPayment is a transfer of money via a credit institution which

needs to be authorized. My definition of Payment encompasses and is
more general than my definition of CreditPayment

Generalization and Class Sets

Conceptual subclasses and super classes are related in terms of set

membership. All the members of a conceptual subclass set are
members of their superclass set.

For example, in terms of set membership, all instances of the set

CreditPayment are also members of the set Payment.
 ii Implement the partial domain model of POS with attributes(5) CO 2 K3

OR

11)bi. Explain domain model Refinement in detail(10) CO 2 K2

Refine the domain model with generalization,

specializations, associations, classes, time intervals, composition and
packages.

Generalization

The concepts CashPayment, CreditPayment, and Check Payment are

all very similar. In this situation, it is possible ( to organize them into
a generalization-specialization class hierarchy (or simply class
hierarchy) in which the superclass Payment represents a more general
concept, and the subclasses more specialized ones.

Generalization is the activity of identifying commonality among

concepts and defining superclass (general concept) and subclass
(specialized concept) relationships. It is a way to construct taxonomic
classifications among concepts which are then illustrated in class
 hierarchies. Identifying a superclass and subclasses is of value in a
domain model because their presence allows us to understand concepts
in more general, refined and abstract terms. It leads to economy of
expression, improved comprehension and a reduction in repeated
information.

Figure 2.22 Class hierarchy with separate and shared

arrow notations.

UML notation— the generalization relationship between elements is

indicated with a large hollow triangle pointing to the more general
element from the more specialized one .

ii Implement the partial domain model of POS with necessary CO 2 K3

associations(5)
12)a. Explain detail about SSD with necessary notations. (15) CO 3 K2

Messages

Each message between objects is represented with a message

expression on a filled-arrowed[3] solid line between the vertical
lifelines (see Figure 15.7). The time ordering is organized from top to
bottom of lifelines.

Focus of Control and Execution Specification Bars

Sequence diagrams may also show the focus of control using an

execution specification bar. The bar is optional.

Reply or Returns

Using the message syntax returnVar = message(parameter).

Messages to "self" or "this"

Message being sent from an object to itself by using a nested

activation bar.

Figure3.8 . Messages to "this."

Creation of Instance

Object creation notation is shown in dashed line with filled arrow (

synchronous message), or open (stick arrow) if an asynchronous call.
 Figure 3.9.Instance creation and object lifelines.

Object Destruction

The explicit destruction of an object can be shown with

<<destroy>>sterotype message with larger X.

Figure3.10. Object destruction.

Frames

Frames are regions or fragments of the diagrams; they have an operator

or label (such as loop) and a guard .The [boolean test] guard should be
placed over the lifeline to which it belongs.
 Conditional Messages

An OPT frame is placed around one or more messages. Notice that the
guard is placed over the related lifeline.

Nesting of Frames

Frames can be nested.

OR

12)b.i Explain package diagram in detail with its required symbols.(10) CO 3 K2

Package:
 Package is a namespace used to group together elements that are
semantically related and might change together.

Basic notations in package diagram:

package:

Use a tabbed folder to illustrate packages.Name of the package can

be written on the tab or inside the folder.

Visibility:

Visibility markers signify who can access theInformation contained

within the package.

Private visibility: attribute/operation is not accessible to anything

outside the package.

Public visibility: allows an attribute or an operation to be viewed by

other packages.

Protected package: attribute/operation is only visible to package that

inherit it.

Dependency:

Dependency defines a relationship in which changes to one package

will affect another package.

Import is a type of dependency that grants one package access to the

contents of another package

Example:
 Figure Layers shown with UML package diagram notation.

When to use package diagrams:

1. It is used in large scale systems to picture dependencies

between major elements in the system
2. Package diagrams represent a compile time grouping
mechanism.

ii) Design the Activity diagram for POS(5) C K3

O3
 ARUNACHALA COLLEGE OF ENGINEERING FOR WOMEN
DEPARTMENT OF CSE
Internal Assessment III –Ans key
CS8592 OBJECT ORIENTED ANALYSIS AND DESIGN
CLASS: III CSE A & B
PART A (10*2=20)

1 CO4 K1 What is GRASP?

The GRASP patterns are a learning aid to help you understand essential object
design, and apply design reasoning in a methodical, rational, explainable way. This
approach to understanding and using design principles is based on patterns of
assigning responsibilities.
2 CO4 K2 What is meant by responsibilities? List out its types
The UML defines a responsibility as “a contract or obligation of a
classifier”.
 Doing responsibilities of an object include:
• doing something itself, such as creating an object or doing a calculation
• initiating action in other objects
• controlling and coordinating activities in other objects
Knowing responsibilities of an object include:
• knowing about private encapsulated data
• knowing about related objects
• knowing about things it can derive or calculate

3 CO4 K1 Define coupling.

It refers to how related are two classes / modules and how dependent they are on
each other. Being low coupling would mean that changing something major in
one class should not affect the other.
4 CO4 K2 Define cohesion.
Cohesion refers to what the class (or module) will do. Low cohesion would mean
that the class does a great variety of actions and is not focused on what it should
do
5 CO4 K1 Who is creator?
Solution Assign class B the responsibility to create an instance of class A if one
or more of the following is true:
• B aggregates an object.
• B contains an object.
• B records instances of objects.
6 CO5 K1 Define anti pattern.
An anti-pattern represents a worst practice while a pattern represents a best
practice. Anti-patterns come in two varieties:
1.Those describing a bad solution to a problem that resulted in a badsituation.
2.Those describing how to get out of a bad situation

7 CO5 K1 What is frame work?

A frame work is a way of presenting a generic solution to a problem that can be
applied to all levels in a development. Frameworks are a way of delivering
application development patterns.
8 CO5 K1 What do you mean by UA?
The main motivation for going to unified approach is to combine the best practices,
processes, methodologies, and guidelines along with UML (UnifiedModeling
Language) notations and diagrams for better understanding object oriented
concepts and system development.

9 CO5 K1 Write short notes on UA based repository.

The repository allows the maximum reuse of previous experience and previously
defined objects, patterns, frameworks, and user interfaces in an easily accessible
manner with a completely available and easily utilized format.
10 CO5 K1 Define pattern template and list the components.
Every pattern must be expressed in the form of a rule which is called as a
template. It should establish a relationship between a context, a system of forces
which arises in the context, and a configuration. Some of the essential
components are:
Name
Problem
 Context
Forces
Solution
Examples

PART B (2*15=30)

11.a. CO4 K2 Explain the following pattern.

i.Bridge
Intent: The Bridge pattern separates an object's abstraction from its implementation
so that you can vary them independently.
Also Known As:Handle/Body
There are 2 parts in Bridge design pattern :
3. Abstraction
4. Implementation
Motivation:
• The bridge pattern allows the Abstraction and the Implementation to be
developed independently and the client code can access only the Abstraction
part without being concerned about the Implementation part.
• The abstraction is an interface or abstract class and the implementor is also an
interface or abstract class.
• It increases the loose coupling between class abstraction and it’s
implementation.
Participants:
• Abstraction – core of the bridge design pattern and defines the crux. Contains
a reference to the implementer.
• Refined Abstraction – Extends the abstraction takes the finer detail one level
below. Hides the finer elements from implemetors.
• Implementer – It defines the interface for implementation classes. This
interface does not need to correspond directly to the abstraction interface and
can be very different. Abstraction imp provides an implementation in terms of
operations provided by Implementer interface.
• Concrete Implementation – Implements the above implementer by providing
concrete implementation.

ii.Information Expert
Information Expert assigns responsibility to the class that has the information
needed to fulfill the responsibility.
Problem: What is a general principle of assigning responsibilities to objects?
Solution: Assign a responsibility to the information expertthe class that has the
information necessary to fulfill the responsibility.
.Example : In the NextGEN POS application, some class needs to know the grand
total of a sale.
It is necessary to know about all the SalesLineltem instances of a sale and the sum
of their subtotals. In terms of an interaction diagram, this means that the Sale needs
to send get-Subtotal messages to each of the SalesLineltems and sum the results;
 Figure 4.5 Calculating the Sale sub total
To fulfill the responsibility of knowing and answering its subtotal, a SalesLineltem
needs to know the product price. The ProductSpecification is an information expert
on answering its price; therefore, a message must be sent to it asking for its price.

Calculating the Sale sub total

Benefits:
• Information encapsulation is maintained, since objects use their own
information to fulfill tasks.
• supports low coupling, which leads to more robust and maintainable
systems.
• encourage more cohesive "lightweight" class definitions that are easier to
understand and maintain.
• High cohesion is usually supported (another pattern discussed later).

iii.Factory
Intent: Define an interface for creating an object, but let
subclasses decide which class to instantiate.Factory Method lets
a class defer instantiation to subclases.
Also Known As:Virtual Constructor

Motivation:
• Frameworks use abstract classes to define and maintain relationships between
 objects.
• A framework is often responsible for creating these objects as well.
• Consider a framework for applications that can present
multiple documents to the user.
• Two key abstractions in this framework are the classes Application and
Document.
• Both classes are abstract, and clients have to
subclass them to realize their application-specific
implementations.

Applicability:
Use the Factory Method pattern when
• a class can't anticipate the class of objects it must create.
• a class wants its subclasses to specify the objects it creates.
• classes delegate responsibility to one of several helper
subclasses
Srructure:

Participants:
• Product (Document) – defines the interface of objects the
factory method creates.
• ConcreteProduct (MyDocument) – implements the Product
interface.
• Creator (Application) - m declares the factory method, which returns
an object of type Product. Creator may also define a default
implementation of the factory method that returns a default
ConcreteProduct object.

11.b. CO4 K3 How will you map design to code? Convert your NextGen POS design into its code
Map design artifacts to code in an object oriented language. Implementation in
an object-oriented programming language requires writing source code for:
• class and interface definitions
• method definitions
Creating Class Definitions from DCDs
At the very least, DCDs depict the class or interface name, superclasses, method
 signatures, and simple attributes of a class. This is sufficient to create a basic
class definition in an object-oriented programming language.

Figure 4.17 SalesLineItem in Java.

Adding Reference Attributes
A reference attribute is an attribute that refers to another complex object, not to
a primitive type such as a String, Number, and so on.
Reference Attributes and Role Names
The next iteration will explore the concept of role names in static
structure diagrams. Each end of an association is called a role. Briefly, a role
name is a name that identifies the role and often provides some semantic context
as to the nature of the role.

Role names may be used to generate instance variable name

Creating Methods from Interaction Diagrams
The sequence of these messages translates to a series of statements in the method
definition.
 Figure 4.20The enterltem interaction diagram.
The enterltem message is sent to a Register instance; therefore, the enterltem
method is defined in class Register.
public void enterltem ( ItemID itemID, int qty)
Message 1: A getSpecification message is sent to the ProductCatalog to retrieve
a ProductSpecification.
ProductSpecif ication spec = catalog. getSpecif ication( itemID );
Message 2: The makeLineltem message is sent to the Sale. sale .
makeLineltemf spec, qty);
Order of Implementation
Classes need to be implemented from least-coupled to most-coupled.

Possible order of class implementation and testing.

12.a. CO 5 K3 Explain the Rumbaugh’s object Modeling technique and create the model for it
Rumbaugh’s describes a method for the analysis, design and implementation of a
system using an object oriented technique. OMT consists of four phases which can
be performed iteratively
 i) Analysis – results are objects, dynamic and functional models.
ii) System design – gives a structure of the basic architecture.
iii) Object design – produces a design document.
iv) Implementation – produces reusable code.
• OMT separates modelling in to three different parts
i)Object Model – presented by object model and the data dictionary
ii)Dynamic model - presented by the state diagrams and event Flow diagrams.
iii)Functional Model – presented by data flow and constraints.
i) Object model
• Object model describes the structure of objects in a system, their identity and
relationships to other objects, attributes, and operations.
• the object model is represented graphically with an object diagram.
• The object diagram contains classe4s interconnected by association lines.
• Each class represents a set of individual objects.
• The boxes in figure5.1 represents classes and the filled triangle represents
associations
ii)Dynamic model
• OMT state transition diagram is a network of states and events.
• Each state receives one or more events, at which it makes the transition to the
next state.
• The next state depends on the current state as well as the events.
• State transition diagrams for the bank application user interface is given in
figure 5 inwhich Round boxes represents states and Arrows represents
transition

Figure The OMT Object model of a bank system

 Figure State transition diagram for a bank system
iii)Functional model
1. The OMT data flow diagram (DFD) shows the flow of data between
Different processing in a business.
2. Data Flow Diagrams use four primary symbols
1. The process is any function being performed
2.The data flow shows the direction of data element movement.
3. The data store is a location where data are stored.
4. An external entity is a source or destination of a data element.
 Rumbaugh OMT methodology provides one of the strong tolls set for the analysis
and design of object-oriented system.

OR
12.b. CO5 K2 Explain in detail about test case and test plan.
TEST CASES-To have a comprehensive testing scheme,the test must cover all
methods or a good majority of them.All the services of your system must be
checked by at least one test.To test a system,you must construct some test input
cases,then describe how the output will look.Next,perform the tests and compare
the outcome with the expected output.The good news is the use cases developed
during analysis can be used to describe the usage test cases.
The objective of testing as follows:
• Testing is the process of executing a program with the intent of finding
errors.
• A good case is the one that has a high probability of detecting an as-yet
undiscovered error.
• A successful test case is the one that detects an as-yet undiscovered error.
We need to specify the result as follows
1. Drop down the File Menu and Select Open.
2. Try opening the following types of files:
• A file that is there (should work).
• A file that is not there (should get an Error message).
• A file name with international characters (should work).
 • A file type that the program does not open (should get an
message or conversion dialog box).
TEST PLAN
A test plan is developed to detect and identify potential problems before delivering
the software to its users. Your users might demand a test plan as one item delivered
with the program. In other cases, no test plan is required, but that does not mean
should not have one. A test plan offers a road map for testing activities, whether
usability, user satisfaction, or quality assurance tests. It should state the test
objectives and how to meet them.
The test plan need not be very large; in fact, devoting too much time to the
plan can be counterproductive.
The following steps are needed to create a test plan
Objectives of the test: Create the objectives and describe how to achieve them.
For eg, if the objective is usability of the system, that must be started and also how
to realize it.
Development of a test case: Develop test data, both input and expected output,
based on the domain of the data and the expected behaviours that must be tested
Test analysis: This step involves the examination of the test output and the
documentation of the test results. If bugs are detected, then this is reported and the
activity centers on debugging. After debugging, step 1 through 3 must be repeated
until no bugs can be detected.
All passed tests should be repeated with the revised program, called
regression testing, which can discover errors introduced during the debugging
process. when sufficient testing is believed to have been conducted, this fact should
be reported, and testing for this specific product is complete.
Most software companies also use beta testing, a popular, inexpensive, and
effective way to test software on a select group of the actual users of the system. This
is in contrast to alpha testing, where testing is done by in house testers, such as
programmers, software engineers, and internal users.

Faculty Incharge HOD/CSE

 ARUNACHALA COLLEGE OF ENGINEERING FOR WOMEN
MANAVILAI, VELLICHANTHAI – 629 203
DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE
CS3591- COMPUTER NETWORKS
FOURTH Semester
Assignment No : 1
GIVEN DATE: TARGET DATE:

Batch Register Name Assignment Topic CO

Number

1. 960220104001 Aarthi.S.P Design a use case diagram for a library management system
with the following actors: Librarian, Member, and
960220104002 Abinaya.R.K Administrator. Include at least eight use cases and show their
interactions
960220104003 Abiraina.P.A 1

960220104004 Abisha.C

960220104005 Abisha.D

2 960220104006 Abisha.S A coffee vending machine dispenses coffee to customers.

Customers order coffee by selecting the recipe from the set of
960220104007 Adjaya Sree.S recipe, customer pay for the coffee using coins change is given
back if any to the customer, the service staff loads ingredients
960220104008 Afrin.N 1
coffee powder, milk, sugar, water ,chocolate into the coffee
machine. The service staff can also add a recipe by indicating
960220104009 Ahalya.G
the name of coffee, the unit of coffee powder, milk, sugar,
water and chocolate to be added as well the cost of the coffee.
960220104010 Ajatha.B.S
Construct the use case diagram for the above.

3 960220104011 Akalya.K For the library management system, develop a use case
scenario for the "Borrow Book" use case. Include interactions
960220104012 Akshaya.S between the Member and the Librarian.
960220104014 Anitta.M.Das 1

960220104015 Anlin Breesha.T

960220104016 Anusha.V

4 960220104017 Anusuya.S A library lends books and magazines to member who is

registered in the system, it also maintains the purchase of new
960220104018 Archana.R.D book and magazines for the library. A member can serve book
 960220104019 Asberyl and magazine that is not currently available in the library. So 1
Sheraphin.I that when it is returned or purchased by library it must be
updated. The books transactions are stored in the database,the
960220104020 Asha.A.C fine list while the member returns the book after the due date
must be generated .Prepare the use case diagram for this
960220104021 Asha.M scenario

5. 960220104022 Ashika.H Create a use case diagram for a university course registration
system. Identify the primary actors and at least five use cases.
960220104023 Ashika.N

960220104024 Ashika.R.V 1

960220104025 Ashlina.J

960220104026 Ashmika.G

6 960220104027 Ashna Chinju Draw a use case diagram for a hotel reservation system.
Include the roles of guests, hotel staff, and the reservation
960220104028 Asley Rejeese.R system, and identify key use cases.
960220104029 Aslin Kani.C.S 1

960220104030 Auslin.M

960220104031 Behima Joseni.J

7 960220104032 Benshika.B.V For the hotel reservation system, provide detailed use case
descriptions for the use cases "Make a Reservation" and
960220104033 Bershika. R.S "Cancel a Reservation".
960220104034 Bincia Shine.R 1

960220104035 Britney Spierce.G

960220104036 Deva Jesma.V

8. 960220104037 Dhanusha.D.N Design a use case diagram for a library management system
with the following actors: Librarian, Member, and
960220104038 Dheepthika.G.A Administrator. Include at least eight use cases and show their
interactions.
960220104039 Evangalin 1
Reshmi.J

960220104040 Gafna Noelin.S

960220104041 Gayathri.J.M

9 960220104042 Geji Reashma.A

960220104043 Harshini.M
 960220104044 Hathoon Beevi.S Analyze the use case diagram of an ATM system. Identify the 1
actors and use cases, and discuss how the use case diagram
960220104045 Jebisha. G helps in understanding the system requirements.
960220104046 Jeshiya.J

10 960220104047 Jeya Pradeesha.S Create a use case diagram for a ride-sharing application (like
Uber or Lyft). Include actors such as Driver, Rider, and
960220104048 Jijin Jora.N.S System, and at least seven use cases.
960220104049 Jika Shirose.R.M 1

960220104050 Joevisha Mergil.S

960220104051 Jovita M Bibyana

11. 960220104052 Kaviya.K Create a use case diagram for a university course registration
system. Identify the primary actors and at least five use cases.
960220104055 Lakshmi.V.V

960220104079 Roshini C M 1

Faculty Incharge HOD/CSE

 ARUNACHALA COLLEGE OF ENGINEERING FOR WOMEN
MANAVILAI, VELLICHANTHAI – 629 203
DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE
CS3591- COMPUTER NETWORKS
FOURTH Semester
Assignment No : 2
GIVEN DATE: TARGET DATE:

Batch Register Name Assignment Topic CO

Number

1. 960220104001 Aarthi.S.P Construct the Partial domain model of Bank ATM

960220104002 Abinaya.R.K

960220104003 Abiraina.P.A 2

960220104004 Abisha.C

960220104005 Abisha.D

2 960220104006 Abisha.S Develop a sequence diagram for the use case "Borrow Book"
in a library management system, illustrating interactions
960220104007 Adjaya Sree.S between the Member, Librarian, Book Inventory, and
Notification System.
960220104008 Afrin.N 3

960220104009 Ahalya.G

960220104010 Ajatha.B.S

3 960220104011 Akalya.K Construct the State chart diagram of ATM

960220104012 Akshaya.S

960220104014 Anitta.M.Das 3

960220104015 Anlin Breesha.T

960220104016 Anusha.V

4 960220104017 Anusuya.S Create a class diagram for a university course registration

system. Identify and include classes such as Student, Course,
960220104018 Archana.R.D
 960220104019 Asberyl Professor, and Registration, along with their attributes and 2
Sheraphin.I methods.

960220104020 Asha.A.C

960220104021 Asha.M

5. 960220104022 Ashika.H Create an activity diagram for the use case "User Registration"
in a web application. Include activities such as entering details,
960220104023 Ashika.N validating input, and creating an account.
960220104024 Ashika.R.V 3

960220104025 Ashlina.J

960220104026 Ashmika.G

6 960220104027 Ashna Chinju Create a class diagram for a hospital management system,
focusing on relationships such as one-to-many, many-to-many,
960220104028 Asley Rejeese.R and one-to-one. Include classes like Hospital, Doctor, Patient,
Appointment, and Medical Record.
960220104029 Aslin Kani.C.S 2

960220104030 Auslin.M

960220104031 Behima Joseni.J

7 960220104032 Benshika.B.V Create a sequence diagram for the "Login" use case in a web
application, covering both successful and unsuccessful login
960220104033 Bershika. R.S scenarios. Include interactions with the User, Login Page,
Authentication System, and User Profile.
960220104034 Bincia Shine.R 3

960220104035 Britney Spierce.G

960220104036 Deva Jesma.V

8. 960220104037 Dhanusha.D.N Analyze the domain model of a restaurant management system.

Identify the key entities and their relationships, and explain
960220104038 Dheepthika.G.A how this model helps in understanding the system structure.
960220104039 Evangalin 2
Reshmi.J

960220104040 Gafna Noelin.S

960220104041 Gayathri.J.M

9 960220104042 Geji Reashma.A Create a collaboration diagram for the use case "Schedule
Appointment" in a hospital management system, showing
960220104043 Harshini.M
 960220104044 Hathoon Beevi.S interactions between the Patient, Receptionist, Doctor, and 3
Appointment System classes.
960220104045 Jebisha. G

960220104046 Jeshiya.J

10 960220104047 Jeya Pradeesha.S Discuss the role of domain models in the overall UML
modeling process. How do they complement other UML
960220104048 Jijin Jora.N.S diagrams like use case diagrams and sequence diagrams? Use
examples from a hotel reservation system.
960220104049 Jika Shirose.R.M 2
Construct the Partial domain model of Bank ATM
960220104050 Joevisha Mergil.S

960220104051 Jovita M Bibyana

2

11. 960220104052 Kaviya.K Create a class diagram for a hospital management system,
focusing on relationships such as one-to-many, many-to-many,
960220104055 Lakshmi.V.V and one-to-one. Include classes like Hospital, Doctor, Patient,
Appointment, and Medical Record.
960220104079 Roshini C M 2

Faculty Incharge HOD/CSE

 ARUNACHALA COLLEGE OF ENGINEERING FOR WOMEN
MANAVILAI, VELLICHANTHAI – 629 203
DEPARTMENT OF ARTIFICIAL INTELLIGENCE AND DATA SCIENCE
CS3591 - COMPUTER NETWORKS
FOURTH Semester
Assignment No : 3
GIVEN DATE: TARGET DATE:

Batch Register Name Assignment Topic CO

Number

1. 960220104001 Aarthi.S.P List and briefly describe the nine GRASP patterns. Provide an
example scenario where each pattern might be applicable.
960220104002 Abinaya.R.K

960220104003 Abiraina.P.A 4

960220104004 Abisha.C

960220104005 Abisha.D

2 960220104006 Abisha.S For a university course registration system, identify the

controller classes and describe their responsibilities. Create a
960220104007 Adjaya Sree.S diagram to illustrate the relationships between these
controllers and other system components.
960220104008 Afrin.N 4

960220104009 Ahalya.G

960220104010 Ajatha.B.S

3 960220104011 Akalya.K Design the class diagram oh ATM and map this to its
equivalent code
960220104012 Akshaya.S

960220104014 Anitta.M.Das 4

960220104015 Anlin Breesha.T

960220104016 Anusha.V

4 960220104017 Anusuya.S
 960220104018 Archana.R.D Design a domain model using Object-Oriented Methodologies
for a smart home automation system. Include classes,
960220104019 Asberyl relationships, and attributes relevant to the system's 5
Sheraphin.I functionality.

960220104020 Asha.A.C

960220104021 Asha.M

5. 960220104022 Ashika.H Discuss the application of the "Protected Variations" pattern

in a content management system (CMS) to handle different
960220104023 Ashika.N types of content (e.g., articles, videos, images). Provide an
example scenario
960220104024 Ashika.R.V 4

960220104025 Ashlina.J

960220104026 Ashmika.G

6 960220104027 Ashna Chinju Explain the core principles of Object-Oriented Methodologies

(OOM) in software development. How do these principles
960220104028 Asley Rejeese.R differ from procedural programming approaches?
960220104029 Aslin Kani.C.S 5

960220104030 Auslin.M

960220104031 Behima Joseni.J

7 960220104032 Benshika.B.V Evaluate the suitability of the Object-Oriented Software

Engineering (OOSE) methodology for developing a large-
960220104033 Bershika. R.S scale e-commerce platform. Discuss its strengths and potential
challenges in such a project context.
960220104034 Bincia Shine.R 5

960220104035 Britney Spierce.G

960220104036 Deva Jesma.V

8. 960220104037 Dhanusha.D.N Design test cases for a login feature in a web application.
Include positive and negative scenarios, boundary value tests,
960220104038 Dheepthika.G.A and equivalence partitioning
960220104039 Evangalin 5
Reshmi.J

960220104040 Gafna Noelin.S

960220104041 Gayathri.J.M

9 960220104042 Geji Reashma.A Explain in detail about UA approach

 960220104043 Harshini.M

960220104044 Hathoon Beevi.S 5

960220104045 Jebisha. G

960220104046 Jeshiya.J

10 960220104047 Jeya Pradeesha.S Compare and contrast Agile and Waterfall methodologies with
respect to their compatibility with Object-Oriented
960220104048 Jijin Jora.N.S Programming (OOP) principles. Discuss the advantages and
disadvantages of each in an OOP context.
960220104049 Jika Shirose.R.M 5
List and briefly describe the nine GRASP patterns. Provide an
960220104050 Joevisha Mergil.S example scenario where each pattern might be applicable.

960220104051 Jovita M Bibyana

4

11. 960220104052 Kaviya.K Explain the core principles of Object-Oriented Methodologies

(OOM) in software development. How do these principles
960220104055 Lakshmi.V.V differ from procedural programming approaches?
960220104079 Roshini C M 5

Faculty Incharge HOD/CSE