1. UNIT 1

2. WHY OBJECT ORIENTED PROGRAMMING
Object-oriented programming was developed because limitations were discovered in earlier approaches to programming.
C, Pascal, FORTRAN, and similar languages are procedural languages.
These language tells the computer to do something:
Get some input,
add these numbers,
divide by 6,
display that output.

3. WHY OBJECT ORIENTED PROGRAMMING
Developing a program for real world application is complex in Procedural Language
Class room
Mobile version upgrade
Etc..
But in Object Oriented Programming we can develop the program for the real word applications, by using Class and Object.

4. 1.OOAD ?
The proverb “OWNING A HAMMER DOESN`T MAKE ONE AN ARCHUTECTURE “ is especially true with respect to object technology .
First want to know
What are classes?
What are their objects?
What are their attributes?
For this we go for Object Oriented Analysis and Design which deals with analysis and design of domain object.

5. INTRODUCTION TO OOAD What is Object Oriented Analysis(OOA)?
Analysis is the method for emphasize an investigation of the problem and requirements rather than the solution.
Analysis- an overall investigation of the requirements for the project.
Object Oriented Analysis –an investigation of domain objects.

6. What is Object Oriented Design ?
Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem.
What is Object Oriented Programming ?
Object-oriented programming (OOP) is a programming paradigm that represents concepts as "objects" that have data fields (attributes that describe the object) and associated procedures known as methods.

7. What is Object Oriented Analysis and Design ?
Object Oriented Analysis and Design (OOAD) is a method of analysis and design during software development process. OOAD consider a problem domain and logical solution from the perspective of objects.
OBJECTS
1.PHYSICAL OBJECTS :
These object have physical existence. They can be seen with eyes
Eg.
Student, Patient, Car etc.
2.CONCEPTUAL OBJECTS :
These object have no physical existence. They exit only in the concept of problem domain.
Bank account, course offered etc.

8. REASON FOR OBJECT MODEL
High level of abstraction
Transition among different phases of software development
Encouragement of good programming
Promotion of reusability

9. REPRESENTATION OAD proceeds as follow Construction Analysis Design
Code
Studying the problem
Logical solution

10. For hospital management system hospital
Hospital  class patient doctor
patient object
Patient
Patient Id
Name
Address
Diseases

11. 2.UML UNIFIED MODELING LANGUAGE
Abstract representation of a system
Model is a simplified representation of reality
Model
Static model
Dynamic model

12. STATIC MODELING
It is used to specify structure of the objects that exist in the problem domain.
These are expressed using class, object and USECASE diagrams.
DYNAMIC MODELING
It refers representing the object interactions during runtime.
It is represented by sequence, activity, collaboration and state chart diagrams.

13. FEATURES OF UML
A way of visually showing the overall architecture of the system
A way of showing the same system from different points of view (abstraction)
A standard graphical set of shapes representing generic objects within a system
A standard way of documenting the attributes (data) of each object
A way of defining functions / methods that can change the state of each object
A way of showing how the objects interact with one another
Making it possible to generate code directly from an UML diagram

14. 7 PRIMARY GOALS IN THE DESIGN OF UML
Provide users a ready - to use expressive visual modeling language so they can develop and exchange meaningful models.
Provide extensibility and specialization mechanism to extend the core concepts.
Be independent of particular programming language and development process.
Provide a formal basis for understanding the modeling language.
Encourage the growth of the OO tools market.
Support higher - level development concepts.
Integrate best practices and methodologies.

15. COMPONETS OF UML THINGS RELATIONSHIP DIAGRAM
The abstractions that are first-class citizens in a model.
RELATIONSHIP
Relationships tie these things together.
DIAGRAM
Diagrams group interesting collections of things.

16. THINGS
Structural Things : These are nouns and static parts of model. They are classes, interface, use case, active class, components and nodes.
Behavioral Things: These are verbs and dynamic part of UML. They are interaction, state machine, activity.
Grouping Things: These are the organizational parts of UML. They are packages
Annotational Things: These are the explanatory parts of model.

17. RELATIONSHIP
Association
Dependency
Generalization
Realization
Aggregation
Composition
Specialization

18. DIAGRAMS
Class diagram
Use case diagram
Behavior Diagram
Interaction Diagram
Sequence diagram
Collaboration diagram
Activity diagram
State-chart diagram
Implementation diagram
Deployment diagram
Component diagram
STATIC MODEL
DYNAMIC MODEL

19. NOTATIONS USED IN UML

20. 3.UNITED PROCESS (UP) PHASE
The UNIFIED APPROACH to software development revolves around (but is not limited to) the following processes and components.
The UA processes are:
Use-case driven development.
Object-oriented analysis.
Object-oriented design.
Incremental development and prototyping.
Continuous testing.
The idea behind the UA is not to introduce yet another methodology.
The main motivation here is to combine the best practices, processes, methodologies, and guidelines along with UML notations and diagrams.

22. UA OBJECT-ORIENTED ANALYSIS: USE-CASE DRIVEN
The use-case model captures the user requirements.
The objects found during analysis lead us to model the classes.
The interaction between objects provide a map for the design phase to model the relationships and designing classes.

23. UA OBJECT-ORIENTED DESIGN
Booch provides the most comprehensive object-oriented design method.
However, Booch methods can be somewhat imposing to learn and especially tricky to figure out where to start.
UA realizes this by combining Jacobson et al.'s analysis with Booch's design concept to create a comprehensive design process.

24. ITERATIVE DEVELOPMENT AND CONTINUOUS TESTING
The UA encourages the integration of testing plans from day 1 of the project.
Usage scenarios or Use Cases can become test scenarios; therefore, use cases will drive the usability testing.

25. UA METHODS AND TECHNOLOGY
Unified modeling language (UML) used for modeling.
Layered approach.
Repository for object-oriented system development patterns and frameworks.
Promoting Component-based development.

26. MODELING BASED ON THE UNIFIED MODELING LANGUAGE
The UA uses the unified modeling language (UML) to describe and model the analysis and design phases of system development.

27. THE UA PROPOSED REPOSITORY
The requirement, analysis, design, and implementation documents should be stored in the repository, so reports can be run on them for traceability.
This allows us to produce designs that are traceable across requirements, analysis, design, implementation, and testing.

28. THREE-LAYER ARCHITECTURE
They are represented to the user (through an interface) or how they are physically stored.
User Interface layer
Business Layer
Access Layer

30. CASE STUDY POS(Point Of Sale) SYSTEM
The Point-of-Sale terminal is a computerized system used to record sales and handle payments; it is typically used in a retail store
It includes
hardware components -computer and bar code scanner
software to run the system.
Applications generally can be divided into 3 layers
– User interface
– Application logic
– Other components/layers

31. Applications generally can be divided into 3 layers
– User interface
– Application logic
– Other components/layers

33. INCEPTION OF POS SYSTEM
Inception means envision( imagine, predict) the product scope, vision and business case. It is the initial short step to establish a common vision and basic scope for the project
It will include analysis of the use cases & critical non-functional requirements, creation of a business case, and preparation of the development environment
The components to identified in the requirements inception are
Overview Statement
Customers
Goals
System function
System attributes

34. USE CASE MODELING POS SYSTEM
Use case is a sequence of transactions, in which each transaction is involved from outside the system and make the internal objects to interact with one another and with the surrounding of the system
Notations used in USE CASE
Actor
Use Case

35. List of Use Cases
List of Actors
Ranking the Use Case
Rules to be consider during the Use Case development

36. USE CASE RELATIONS Three types of relations between Use Cases INCLUDE
Included use case embodies common behavior
EXTEND
Extending use case adds behavior
GENERALIZATION
One use case is a special case of another
Use case generalization