WEEK CHAPTER CONTENTS
9th Week CHAPTER 1 Introduction, Modeling Concepts, UML overview
10th Week CHAPTER 2 Basic Structural Modeling
11th Week CHAPTER 3 Class and Object Diagrams
Basic Behavioral Modeling-I: Use cases, Use
12th Week CHAPTER 4
case diagrams, Activity diagrams
Basic Behavioral Modeling-II: Interactions,
13th Week CHAPTER 5
Interaction diagrams
Advanced Behavioral modeling – State Chart or
14th Week CHAPTER 6
State machine diagram
15th Week CHAPTER 7 Architectural Modeling
Subject Name: Object Oriented Analysis and Design
Teacher Name: Prabaharan
OOAD COURSE SYLLABUS WITH
LEARNING OUTCOMES
VNR Vignana Jyothi Institute of Engineering & Technology
III Year B.Tech CSE – II Sem
Object Oriented Analysis and Design
Course Objectives:
Understand the importance and basic concepts and of object oriented modeling,
1. Specify, analyze and design the use case driven requirements for a particular system.
2. Model the event driven state of object and transform them into implementation
specific layouts.
3. Identify, Analyze the subsystems, various components and collaborate them
interchangeably.
Syllabus
UNIT-I Introduction to UML: Importance of modeling, principles of modeling,object
oriented modeling, conceptual model of the UML, Architecture,Software Development Life
Cycle.
UNIT-II Basic Structural Modeling: Classes, Relationships, Common mechanisms and
diagrams.
Advanced Structural Modeling: Advanced classes, advanced relationships,Interfaces, Types
and Roles, Packages, Common modeling techniques.
UNIT-III
Class and Object Diagrams: Terms, concepts, modeling techniques for class and object
diagrams, Common modeling techniques.
Basic Behavioral Modeling-I: Interactions, Interaction diagrams, Common modeling
techniques
UNIT-IV Basic Behavioral Modeling-II: Use cases, Use case diagrams, Activity diagrams,
Common modeling techniques.
Advanced Behavioral Modeling: Events and signals, state machines, processes and Threads,
time and space, state chart diagrams, Common modeling techniques.
UNIT-V Architectural Modeling: Component, Deployment, Component diagrams,
Deployment diagrams, Common modeling techniques, Case Studies
TEXT BOOKS
1. Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language
User Guide, Pearson Education
2. Hans-Erik Eriksson, Magnus Penker, Brian Lyons, David Fado: UML 2 Toolkit,
WILEY-Dreamtech India Pvt. Ltd.
REFERENCES
1. Meilir Page-Jones: Fundamentals of Object Oriented Design in UML, Pearson
Education.
2. Atul Kahate: Object Oriented Analysis & Design, The McGraw-Hill.\
3. Mark Priestley: Practical Object-Oriented Design with UML,TATA McGrawHill
4. Appling UML and Patterns: An introduction to Object – Oriented Analysis and
Design and Unified Process, Craig Larman, Pearson Education.
Program Outcomes:
On the successful completion of this course, Students will be able to
CO1. Analyse, design, document the requirements through use case driven approach.
CO2.Identify, analyse, and model structural and behavioural concepts of the system.
CO3.Develop,explore the conceptual model into various scenarios and applications.
CO4.Apply the concepts of architectural design for deploying the code for software.
The Importance of Modeling
Unsuccessful software projects fail in their own unique ways,
but all successful projects are alike in many ways. There are
many elements that contribute to a successful software
organization; one common thread
is the use of modeling.
Modeling is a proven and well-accepted engineering
technique. We build architectural models of houses
and high rises to help their users visualize the final product.
We may even build mathematical models in
order to analyze the effects of winds or earthquakes on our
buildings.
Modeling is not just a part of the building industry. It would
be inconceivable to deploy a new aircraft or
an automobile without first building models• from computer
models to physical wind tunnel models to
full-scale prototypes. New electrical devices, from
microprocessors to telephone switching systems require
some degree of modeling in order to better understand the
system and to communicate those ideas to
others. In the motion picture industry, storyboarding, which
is a form of modeling, is central to any
production. In the fields of sociology, economics, and
business management, we build models so that we
can validate our theories or try out new ones with minimal
risk and cost.
What, then, is a model? Simply put,
A model is a simplification of reality.
A model provides the blueprints of a system. Models may
encompass detailed plans, as well as more general plans that
give a 30,000-foot view of the system under consideration.
Why do we model?
There is one fundamental reason.
We build models so that we can better understand the
system we are developing.
Through modeling, we achieve four aims.
1. Models help us to visualize a system as it is or as we want
it to be.
2. Models permit us to specify the structure or behavior of a
system.
3. Models give us a template that guides us in constructing a
system.
4. Models document the decisions we have made.
Modeling is not just for big systems. Even the software
equivalent of a dog house can benefit from some modeling.
However, it's definitely true that the larger and more
complex the system, the more important modeling becomes,
for one very simple reason:
We build models of complex systems because we cannot
comprehend such a system in its entirety.
Principles of Modeling
The use of modeling has a rich history in all the engineering
disciplines. That experience suggests four basic principles of
modeling. First,
The choice of what models to create has a profound
influence on how a problem is attacked and how a solution is
shaped.
In other words, choose your models well. The right models
will brilliantly illuminate the most wicked development
problems, offering insight that you simply could not gain
otherwise; the wrong models will mislead you, causing you
to focus on irrelevant issues.
Second,
Every model may be expressed at different levels of precision.
If you are building a high rise, sometimes you need a 30,000-
foot view• for instance, to help your investors visualize its
look and feel. Other times, you need to get down to the level
of the studs• for instance, when there's a tricky pipe run or
an unusual structural element.
Third,
The best models are connected to reality.
A physical model of a building that doesn't respond in the
same way as do real materials has only limited value; a
mathematical model of an aircraft that assumes only ideal
conditions and perfect manufacturing can mask some
potentially fatal characteristics of the real aircraft. It's best to
have models that have a clear connection to reality, and
where that connection is weak, to know exactly how those
models are divorced from the real world. All models simplify
reality; the trick is to be sure that your simplifications don't
mask any important details.
In software, the Achilles heel of structured analysis
techniques is the fact that there is a basic disconnect
between its analysis model and the system's design model.
Failing to bridge this chasm causes the system as conceived
and the system as built to diverge over time. In object-
oriented systems, it is possible to connect all the nearly
independent views of a system into one semantic whole.
Fourth,
No single model is sufficient. Every nontrivial system is best
approached through a small set of nearly independent
models.
