UNIT 1

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.

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.

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.

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.

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.

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.

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

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

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

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

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.

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

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.

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.

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.

RELATIONSHIP Association Dependency Generalization Realization Aggregation Composition Specialization

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

NOTATIONS USED IN UML

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.

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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