Object Orientation An alternative approach to systems development No longer a fad Includes concepts, tools, methodologies and languages Represents a fundamentally different way of looking at systems and breaking them down into parts

What is an object? An object has both data and operations An object’s data is the information about the object An object’s operations represent things that happen that affect the object’s data This is called encapsulation An object represents a major element of the system Merges the process-driven and data-driven perspectives

Example: Banking Object Customer Object Account data: operations: Name = “Joe Smith” Address = “434 Maple St., Metro City, MD 92388” operations: new_customer change_address delete_customer Object Account data: AccountNumber = 2543238 DateOpened = “12/15/1998” CurrentBalance = 123.52 AccountType = “checking” operations: new_account make_deposit make_withdrawal close_account

Instantiation Class = a collection of objects, all of which have the same set of attributes (different values) and operations The objects that belong to a class are called instances of that class The class is instantiated when an object of that class is created Example: Joe Smith is an instance of Customer

Specialization and Generalization Classes can form a hierarchy, where more general classes are specialized into more specific classes Example: The class Student can be specialized into the classes Undergraduate Student and Graduate Student Example: The classes Frozen Food, Canned Food, and Perishable Food can be generalized into the class Food Item

Specialization and Generalization Student Food Item Frozen Food Perishable Food Undergraduate Student Graduate Student Canned Food

Inheritance A child class inherits all its parent’s attributes and operations A child class can also have other attributes and operations that did not come from the parent A child class can override an inherited operation with another operation with the same name - one form of polymorphism

OO Tools for Analysis & Design Use cases - scenarios that describe user’s requirements from the user’s point of view Class diagram - defines the class hierarchy State diagram - defines the events that affect objects Sequence diagram - the logical design of a use case

Use Cases Each use case represents a complete scenario describing how the system is used by some actor An actor represents a role that a user plays; one user can play several roles Use case scenarios are initiated by the actor, and can involve more than one actor There can be relationships between use cases

<< extends >> Use Case Diagram Rent video Return video Video Store Clerk Video Store Customer << extends >> Calculate late fees

Class Diagrams Similar to ER diagrams, except operations are added Classes are like entities Attributes are the same concept Associations are like relationships Operations are new Shows the hierarchy of classes and their specializations and generalizations

Class Diagram Examples Account Customer Account# DateOpened CurrentBalance AccountType new_account make_deposit make_withdrawal close_account Name Address new_customer change_address delete_customer Owns 1..* 0..* owner owner_type

Class Diagram Examples Medical Complaint description Diagnose() Gastrointestinal foodDiary Upper Respiratory coughType Muscular/Skeletal areaOfBody Other Complaint

Class Diagram Examples PhotoEquipment Model# price make Test() Lens Test(Camera) Camera filmType Test(Lens, Flash) 0..* Flash 1..* 1..* 1..* 0..* fits uses Test(Camera) 0..* requires quantity requires quantity Battery size type 0..1 0..1

State Diagrams A state of an object is some condition that it satisfies; most objects have many possible states, but they are in only one state at a time An event is something that occurs at a specified point in time that changes an object’s state A state transition is when an object changes from one state to another as a result of an event

State Diagram Example Customer Prospective Current Former Makes purchase / LastPurchaseDate = CurrentDate Makes inquiry Prospective 6 months Current Makes purchase / LastPurchaseDate = CurrentDate [CurrentDate - LastPurchaseDate > 1 year] Former 3 years Makes purchase / LastPurchaseDate = CurrentDate

Rapid Application Development Motivated by the need for shorter development cycles A general strategy for developing systems faster, not a specific methodology or technique Appropriate when the number one concern is to produce a system quickly

Basic RAD Concepts Streamlining the SDLC process User involvement combining phases eliminating iteration User involvement helps ensure quick acceptance at end helps eliminate iteration Integrated CASE tools rapid prototyping minimizing effort to transform prototype to working system

Tools used in RAD Prototyping Code generation quickly design and generate parts of interface Code generation eliminates need for handwriting source code generates software from a design Visual development environments facilitates coding, especially implementing GUI interfaces JAD

RAD Advantages Products developed more quickly End product is more closely aligned with user needs because of less time between requirements and delivery Often lower costs System more aligned with user needs Makes it possible to produce systems in rapidly changing environments

RAD Disadvantages Quality often suffers interface consistency lacking no adherence to standards reusability and maintainability No time for in-depth understanding of the organizational environment risk of a major mismatch that is not understood until the end of the process High dependence on user’s willingness to be involved throughout the process