Introduction to Object Modeling Object-oriented analysis (OOA) – an approach used to study existing objects to see if they can be reused or adapted for new uses define new or modified objects that will be combined with existing objects into a useful business computing application Object modeling – a technique for identifying objects within the systems environment and the relationships between those objects. Teaching Notes The object modeling technique prescribes the use of methodologies and diagramming notations that are completely different from the ones used for data modeling and process modeling. In the late 1980s and early 1990s many different object-oriented methods were being used throughout the industry. The most notable of these were Grady Booch’s Booch Method, James Rumbaugh’s Object Modeling Technique (OMT), and Ivar Jacobson’s Object-Oriented Software Engineering (OOSE). Object Oriented Analysis and Design

Introduction to the UML Unified Modeling Language (UML) – a set of modeling conventions that is used to specify or describe a software system in terms of objects. The UML does not prescribe a method for developing systems—only a notation that is now widely accepted as a standard for object modeling. Teaching Notes In 1994 Grady Booch and James Rumbaugh joined forces to merge their respective object-oriented development methods with the goal of creating a single, standard process for developing object-oriented systems. Ivar Jacobson joined them in 1995 and the three altered their focus to create a standard object modeling language instead of a standard object-oriented approach or method. Referencing their own work as well as countless others in the OO industry, the Unified Modeling Language (UML) version 1.0 was released in 1997. UML version 2.0 is expected to be released in late 2000. At the time of this writing, Booch, Rumbaugh, and Jacobson have developed and marketed an object modeling methodology called the Unified Method or Objectory. Object Oriented Analysis and Design

Object Oriented Analysis and Design Captures requirements and problem domain What to do Creates analysis models Use case view Static class view Design Makes strategic and tactical decisions to meet requirements How to do it (above code level) Creates design models Static class view State machine view Interaction view Object Oriented Analysis and Design

Contributions to the UML Harel Statecharts Meyer Before and after conditions Gamma, et al Frameworks and patterns, HP Fusion Operation descriptions and message numbering Booch Booch method Embley Singleton classes and high-level view Rumbaugh OMT Wirfs-Brock Responsibilities Jacobson OOSE Shlaer - Mellor Object lifecycles Odell Classification Object Oriented Analysis and Design

Basic Principles of Object Orientation Encapsulation Abstraction Hierarchy Modularity Object Oriented Analysis and Design

Object Oriented Analysis and Design What is Abstraction? Salesperson Not saying Which salesperson – just a salesperson in general!!! Discuss what makes a good abstraction with the students: Concise, Represents a single coherent concept, etc. Customer Product Manages Complexity Object Oriented Analysis and Design

Object Oriented Analysis and Design What is Encapsulation? Encapsulation is putting the “databits” and operations that manipulate them in the same place. Encapsulation DISALLOWS direct manipulation of things that have been encapsulated without utilising the supplied interface. Another example - the accelerator on a car. You put your foot down and car goes faster - this works on most cars, and you don’t worry about the cables, electronics, engine, etc. Hide implementation from clients Clients depend on interface How does an object encapsulate? What does it encapsulate? Improves Resiliency Object Oriented Analysis and Design

What is Modularity? Modularity supports separation of concerns. Another example of modularity is a car, which is made up of a body, chassis, engine, wheels, etc. The breaking up of something complex into manageable pieces Order Entry Order Processing System Order Fulfillment Billing Manages Complexity Object Oriented Analysis and Design

Object Oriented Analysis and Design What is Hierarchy? Hierarchy is not an organizational chart. Hierarchy is not a functional decomposition. Hierarchy is a taxonomic organization. The use of hierarchy makes it easy to recognize similarities and differences. For example, in botany, plants are organized into families, chemistry uses a periodic table to organize the elements. Another example -- telephone number, then a 0800 (free call) number, premium rate number, etc Levels of abstraction Asset Decreasing abstraction Increasing BankAccount Security RealEstate Savings Checking Stock Bond Elements at the same level of the hierarchy should be at the same level of abstraction Object Oriented Analysis and Design

Objects, Attributes, & Instances Object – something that is or is capable of being seen, touched, or otherwise sensed, and about which users store data and associate behavior. Person, place, thing, or event Employee, customer, instructor, student Warehouse, office, building, room Product, vehicle, computer, videotape Attribute – the data that represent characteristics of interest about an object. Object instance – each specific person, place, thing, or event, as well as the values for the attributes of that object. Teaching Notes There are several concepts that object-oriented analysis is based on. Some of these concepts require a totally new way of thinking about systems and the development process. These concepts have presented a formidable challenge to veteran developers who must relearn how they have traditionally viewed systems. Object-oriented approaches to systems development are concerned with identifying attributes that are of interest regarding an object. It is important to note that with advances in technology, attributes have evolved to include more than simple data characteristics. Today, objects may include newer attribute types, such as a bitmap or a picture sound, or even video. Have students provide examples of objects, instances of objects, and their attributes that exist in the classroom. For instance, pen is an object, the pen I use is an instance of that object, color of ink is an attribute. Object Oriented Analysis and Design

Object Oriented Analysis and Design What is an Object? Informally, an object represents an entity, either physical, conceptual, or software Physical entity Conceptual entity Software entity Truck Chemical Process Linked List Object Oriented Analysis and Design

A More Formal Definition An object is a concept, abstraction, or thing with sharp boundaries and meaning for an application An object is something that has: State Behavior Identity Object Oriented Analysis and Design

Object Oriented Analysis and Design Representing Objects An object is represented as rectangles with underlined names Professor Clark a + b = 10 : Professor ProfessorClark Class Name Only Object Name Only ProfessorClark : Professor Class and Object Name Object Oriented Analysis and Design

What is a Class? A class has been called a “cookie cutter” for objects. A class is a description of a group of objects with common properties (attributes), behavior (operations), relationships, and semantics An object is an instance of a class A class is an abstraction in that it: Emphasizes relevant characteristics Suppresses other characteristics OO Principle: Abstraction Object Oriented Analysis and Design

Object Oriented Analysis and Design Sample Class Class Course Properties Name Location Days offered Credit hours Start time End time Behavior Add a student Delete a student Get course roster Determine if it is full a + b = 10 Object Oriented Analysis and Design

Object Oriented Analysis and Design Representing Classes A class is represented using a compartmented rectangle a + b = 10 Professor Professor Clark Object Oriented Analysis and Design

Object Oriented Analysis and Design Class Compartments In Rose: You may select which compartments are displayed via Diagram Object Properties for the diagram element. You may select which items appear in which compartments using the Edit Compartment function for the diagram element. A class is comprised of three sections The first section contains the class name The second section shows the structure (attributes) The third section shows the behavior (operations) Professor name empID create( ) save( ) delete( ) change( ) Class Name Attributes Operations Object Oriented Analysis and Design

Object Oriented Analysis and Design Exercise: How many classes could you find here? Jet Drone VTOL Military Space Shuttle Glider Helicopter Object Oriented Analysis and Design Turboprop Airship

Object Oriented Analysis and Design What is an Attribute? Object Class Attribute Attribute Value :CourseOffering number = 101 startTime = 900 endTime = 1100 CourseOffering number startTime endTime :CourseOffering number = 104 startTime = 1300 endTime = 1500 Object Oriented Analysis and Design

Object Oriented Analysis and Design What is an Operation? CourseOffering addStudent deleteStudent getStartTime getEndTime Class Operation Object Oriented Analysis and Design

What is Polymorphism? Polymorphism will be addressed in more detail in the Class Design module. Another example of polymorphism: There is a toddler sitting in front of some blocks and a teenager siting in front of a piano. An adult walks into the room and says “play”. The toddler plays with the blocks and the teenage plays the piano. Another example - car accelerator on different cars. The ability to hide many different implementations behind a single interface Manufacturer A Manufacturer B Manufacturer C OO Principle: Encapsulation Object Oriented Analysis and Design

What is an Interface? Interfaces formalize polymorphism Interfaces are not abstract classes, as abstract classes allow you to provide default behavior for some/all of their methods. Interfaces provide no default behavior. Interfaces formalize polymorphism Interfaces support “plug-and-play” architectures Tube Shape Draw Move Scale Rotate <<interface>> Pyramid Cube Object Oriented Analysis and Design

Object Oriented Analysis and Design Inheritance (cont.) Teaching Notes The terms Generalization and Specialization will be defined on the next slide. Walk the students through this diagram. The Person object has an attribute last name. Therefore the Student and Teacher objects that are based on Person also have an attribute last name as well as their own attributes (GPA or rank). The Person object has a method walk. Therefore Student and Teach also have a method walk as well as their own methods (enroll or lecture). Object Oriented Analysis and Design

Generalization/Specialization, Supertype, and Subtype Generalization/specialization – a technique wherein the attributes and behaviors that are common to several types of object classes are grouped (or abstracted) into their own class, called a supertype. The attributes and methods of the supertype object class are then inherited by those object classes. Supertype – an entity that contains attributes and behaviors that are common to one or more class subtypes. Also referred to as abstract or parent class. Subtype – an object class that inherits attributes and behaviors from a supertype class and then may contain other attributes and behaviors that are unique to it. Also referred to as a child class and, if it exists at the lowest level of the inheritance hierarchy, as concrete class. Teaching Notes The previous slide illustrates these terms. The class supertype will have one or more one-to-one relationships to object class subtypes. These relationships are sometimes called “IS A” relationships (or “WAS A” or “COULD BE A”) because each instance of the supertype “is also an” instance of one or more subtypes. Object Oriented Analysis and Design

UML Representation of Generalization/Specialization Teaching Notes Have students identify what attributes and methods are inherited by the STUDENT and TEACHER classes. Object Oriented Analysis and Design

Object Oriented Analysis and Design Exercise: Refine the number of classes here? Jet Drone VTOL Military Space Shuttle Glider Helicopter Object Oriented Analysis and Design Turboprop Airship

Inheritance Relationship A class can Inherit the instance variables, interfaces, and instance methods of another class. The class inherit them as if they were defined in the class. A class providing the inheritance is a base class The class getting the inheritance is a derived class A derived class can override/extend the base class The base class methods can be redefined The base class can define new variables and methods A derived class can be used anyplace a base class can be used. The derived class ISA a base class. Object Oriented Analysis and Design

Multiple Inheritance Relationship A derived class can inherit from multiple base classes It will contain all the variables and methods of every base class. The derived class ISA base class for every base class inherited This class can be used any place any of the original base classes could be used. Object Oriented Analysis and Design

Object/Class Relationships Object/class relationship – a natural business association that exists between one or more objects and classes. Teaching Notes Objects and classes do not exist in isolation. The things they represent interact with and impact one another to support the business mission. An object/class relationship is graphically illustrated in UML as a connecting line between two classes. This relationship is commonly referred to as an association. The line is labeled with a verb phrase that describes the association. All associations are implicitly bidirectional, meaning that they can interpreted in both directions. The figure above shows the complexity or degree of each association. For example, in the above business assertions, we must also answer the following questions: Must there exist an instance of CUSTOMER for each instance of ORDER? Yes! Must there exist an instance of ORDER for each instance of CUSTOMER? No! How many instances of ORDER can exist for each instance of CUSTOMER? Many! How many instances of CUSTOMER can exist for each instance of ORDER? One! Object Oriented Analysis and Design

Multiplicity and UML Multiplicity Notations Multiplicity – the minimum and maximum number of occurrences of one object/class for a single occurrence of the related object/class. Teaching Notes Because all associations are implicitly bidirectional, multiplicity must be defined in both directions for every association. Object Oriented Analysis and Design

Object Oriented Analysis and Design Aggregation Aggregation – a relationship in which one larger “whole” class contains one or more smaller “parts” classes. Conversely, a smaller “part” class is part of a “whole” larger class. Teaching Notes Aggregation relationships do not support inheritance. Their benefit lies in the ability to send a message to the parent class and that message is automatically applied to all the child classes. Have students provide other examples of objects where aggregation relationships are appropriate (car – or any bill of material, church, order-line item, etc.). Object Oriented Analysis and Design

Object Oriented Analysis and Design Composition Composition – an aggregation relationship in which the “whole” is responsible for the creation and destruction of its “parts.” If the “whole” were to die, the “part” would die with it. Teaching Notes All composition relationships are aggregation relationships. But not all aggregation relationships are composition relationships. Compare Figure 11-6a and 11-6b and note the different UML notations. Compare Figure 11-6a and 11-6b and ask students why composition is appropriate for the Book and Chapter classes but not for the Team class. Object Oriented Analysis and Design

Contains Relationship A class can contain another class. The class contains another class by having an Instance Variable of the class in it’s specification The composition of classes into a single class allow a simpler abstraction to be defined for a highly complex group of classes. Example: HomeStereoSystem Class HomeStereoSystem { Tuner itsTuner; CDPlayer itsCDPlayer; Equalizier itsEqualizer; }; Object Oriented Analysis and Design

Object Oriented Analysis and Design Messages Message – communication that occurs when one object invokes another object’s method (behavior) to request information or some action Teaching Notes The object sending a message does not need to know how the receiving object is organized internally or how the behavior is to be accomplished, only that it responds to the request in a well-defined way. A message can be sent only between two objects that have an association between them. Object Oriented Analysis and Design

Object Oriented Analysis and Design Polymorphism Polymorphism means “Many Form” Two objects are polymorphic if they have the same interface and different behavior. This allows clients to use them without knowing their true behavior. Object Oriented Analysis and Design

Object Oriented Analysis and Design Polymorphism Polymorphism – literally meaning “many forms,” the concept that different objects can respond to the same message in different ways. Override – a technique whereby a subclass (subtype) uses an attribute or behavior of its own instead of an attribute or behavior inherited from the class (supertype). Teaching Notes Polymorphism supports reusability in that the same message can be sent to different objects and be interpreted different ways. For example, let’s say we have a method called “Compute Pay” and two objects named FULL-TIME EMPLOYEE and PART-TIME EMPLOYEE. The same “compute pay” message can be sent to both objects but how each object reacts/responds to the message is different. A full-time employee’s pay may be composed of a weekly salary (minus deductions) whereas a part-time employee only gets paid for the hours worked (minus deductions). When the PART-TIME EMPLOYEE object receives a message to “compute pay,” it will override the behavior of the EMPLOYEE supertype and use its own behavior. But because of polymorphism, the object sending the message never knows the difference. Object Oriented Analysis and Design

Relationships: Association Associations connect instances of two or more classes together for some duration (as opposed to a dependency relationship, which represents a temporary association between two instances). Dependency relationships will be discussed in the Class Design module. Do not use relationship/role names if they add no value/information to the model. Remember, readability and understandability of the model are key -- only add information that adds value, not clutter to the diagrams. Models a semantic connection among classes Professor University Works for Class Association Association Name Role Names University Professor Employee Employer Object Oriented Analysis and Design

Object Oriented Analysis and Design Uses Relationship A class uses another class without containing it. The class gets access to the object when it’s passed to a class interface as an argument. Example: HomeStereoSystem::Play(CD&) The play interface of HomeStereoSystem takes a Compact Disc (CD) object which it can use. Object Oriented Analysis and Design

Object Oriented Analysis and Design Abstract Classes Used to hold common operations and data Used in inheritance hierarchy Derived (child) classes provide implementations Documented with class name in italics Can also use {abstract} property Shape {abstract} +move() +erase() : void {abstract} +draw() : void {abstract} Object Oriented Analysis and Design

Object Oriented Analysis and Design UML Interfaces Abstract class with 0 methods or data is an interface Defines public behavioral contract Says nothing about the implementation May be implemented by one or more classes Implementation called a realization This is how COM works Documented with <<interface>> keyword Object Oriented Analysis and Design

Object Oriented Analysis and Design Operation Signatures The "signature" of an operation is the combination of its: name parameters Operations with the same signature are the same operation Must be in different classes Operations with different signatures are different operations Can be in the same class Object Oriented Analysis and Design

Overloading Operations Many OO languages allow operations to be overloaded The name is the same, but the parameters are different A class can implement an operation in different ways depending on the number and type of parameters Example void print(String& text){…} void print(String& text, ostream& output){…} Object Oriented Analysis and Design

Modeling with UML Interaction Diagrams Two types of Interaction Diagrams Communication Diagrams In UML 1.x, called Collaboration Diagrams Sequence Diagrams The two types are semantically equivalent Difference is on what each emphasizes Communication – Class relationships Sequence – Time sequences Object Oriented Analysis and Design

UML Communication Diagrams Visually shows object relationships Useful for showing the structure of an algorithm i.e. Nested interactions are clearly shown Object Oriented Analysis and Design

Object Oriented Analysis and Design Diagram Elements Objects Messages One-way communication Messages to other objects Messages to self Sequence numbers Conditionals Iteration Object Oriented Analysis and Design

UML Communication Diagram Example Format of classes: [Var_name] : class_name Object Oriented Analysis and Design

UML Communication Diagram Options Sequence numbers Can be flat or nested 1, 2, 3, … or 1, 2, 2.1, 2.2, 2.2.1, 3, … Nested (Dewey decimal) specified by UML Can contain letters indicating thread of control A2, A3, B2, B3 Messages can contain guards Conditional execution 4 : [condition] some operation Classes can communicate with themselves Object Oriented Analysis and Design

Using Communication Diagrams Model a single instance through a scenario Use separate diagrams or parts of diagrams to model alternate scenarios Object Oriented Analysis and Design

Sequence Diagram Elements Time Objects Object Lifelines Object creation Object destruction Object Activity Messages Messages to other objects Messages to self Synchronization Returns Conditionals Iteration Object Oriented Analysis and Design

Sequence Diagram Basics Time moves down Time is relative Exact timings require a Timing Diagram Lifeline shows when object is active on stack Dashed line when inactive Double line when active Object Oriented Analysis and Design

UML Sequence Diagram Example Object Oriented Analysis and Design

Sequence Diagram Options Return arrows are optional Data on return arrows is optional Stack activation lines for recursion or self-calls Arrow format is important Synchronous flow: solid line, filled arrowhead Asynchronous flow: solid line, stick or half arrowhead (UML 1.3) Return: dashed line, stick arrowhead Messages can have guards Variable names Parameter values Object Oriented Analysis and Design

Using Sequence Diagrams Model a single instance through a scenario Use separate diagrams or parts of diagrams to model alternate scenarios Object Oriented Analysis and Design

When to use Sequence Diagrams Model the behavior of collaborating objects over time Model behavior of several objects in a single use case Visualizing collaborations between several objects Object Oriented Analysis and Design

Object Oriented Analysis and Design UML Activity Diagrams Diagram elements: Start and End symbols Activities Forks and Joins Branches and Merges Guards Swimlanes Object Oriented Analysis and Design

Activity Diagram Example Object Oriented Analysis and Design

Example of an Activity Diagram No additional notes. Object Oriented Analysis and Design

When to Use Activity Diagrams Analyzing a use case Understanding workflow Describing a complicated algorithm Modeling multithreaded or parallel behavior Object Oriented Analysis and Design

Object Oriented Analysis and Design UML State Diagrams Diagram elements: Start and End symbols States May have an associated activity Transitions Event Guard Action Object Oriented Analysis and Design

Object Oriented Analysis and Design State Diagram Example Object Oriented Analysis and Design

When to use State Diagrams DON'T use them for every class in the system Describing the behavior of an object across several use cases When a system is heavily event-driven Object Oriented Analysis and Design