Object Oriented Analysis and Design Using the UML Version 4.2

Object Oriented Analysis and Design Using the UMLVersion 4.2 Module 3: Introduction to Object Orientation

Objectives: Introduction to Object Orientation • Understand the basic principles of object orientation • Understand the basic concepts and terms of object orientation and the associated UML notation • Appreciate the strengths of object orientation • Understand some basic UML modeling mechanisms

Introduction to Object Orientation Topics • Basic Principles of Object Orientation • Basic Concepts of Object Orientation • Strengths of Object Orientation • General UML Modeling Mechanisms

Object Orientation Abstraction Encapsulation Modularity Hierarchy Basic Principles of Object Orientation

Salesperson Product Customer What is Abstraction? Manages Complexity

What is Encapsulation? • Hide implementation from clients • Clients depend on interface Improves Resiliency

What is Modularity? • The breaking up of something complex into manageable pieces Order Entry Order Processing System Order Fulfillment Billing Manages Complexity

Increasing abstraction Decreasing abstraction What is Hierarchy? Asset • Levels of abstraction Security RealEstate BankAccount Savings Checking Stock Bond Elements at the same level of the hierarchy should be at the same level of abstraction

Introduction to Object Orientation Topics • Basic Principles of Object Orientation • Basic Concepts of Object Orientation • Strengths of Object Orientation • General UML Modeling Mechanisms

Basic Concepts of Object Orientation • Object • Class • Attribute • Operation • Interface (Polymorphism) • Component • Package • Subsystem • Relationships

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

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

Professor Clark Representing Objects • An object is represented as rectangles with underlined names : Professor a + b = 10 ProfessorClark Class Name Only ProfessorClark : Professor Object Name Only Class and Object Name (stay tuned for classes)

What is a Class? • 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

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

Representing Classes • A class is represented using a compartmented rectangle a + b = 10 Professor Professor Clark

Class Name Professor name Attributes empID Operations create( ) save( ) delete( ) change( ) Class Compartments • 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)

Classes of Objects • How many classes do you see?

Professor Smith Professor Mellon Professor Jones The Relationship Between Classes and Objects • A class is an abstract definition of an object • It defines the structure and behavior of each object in the class • It serves as a template for creating objects • Objects are grouped into classes Objects Class Professor

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

CourseOffering addStudent deleteStudent getStartTime getEndTime What is an Operation? Class Operation

Manufacturer B Manufacturer C Manufacturer A What is Polymorphism? • The ability to hide many different implementations behind a single interface OO Principle:Encapsulation

Pyramid Cube Tube <<interface>> Shape Draw Move Scale Rotate What is an Interface? • Interfaces formalize polymorphism • Interfaces support “plug-and-play” architectures Realization relationship (stay tuned for realization relationships)

Pyramid Pyramid Cube Cube Tube Tube <<interface>> Shape Draw Move Scale Rotate Interface Representations Elided/Iconic Representation(“lollipop”) Shape Canonical (Class/Stereotype) Representation (stay tuned for realization relationships)

<<DLL>> Component Name Component Interface What is a Component? • A non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture • A component may be • A source code component • A run time components or • An executable component OO Principle:Encapsulation Source File Name <<EXE>> Executable Name

What is a Package? • A package is a general purpose mechanism for organizing elements into groups • A model element which can contain other model elements • Uses • Organize the model under development • A unit of configuration management OO Principle:Modularity Package Name

Realization <<subsystem>> Subsystem Name Subsystem Interface Interface What is a Subsystem? • A combination of a package (can contain other model elements) and a class (has behavior) • Realizes one or more interfaces which define its behavior OO Principles: Encapsulation and Modularity (stay tuned for realization relationship)

<<subsystem>> Component Name Component Interface Subsystems and Components • Components are the physical realization of an abstraction in the design • Subsystems can be used to represent the component in the design Design Model Implementation Model Component Name Component Interface OO Principles: Encapsulation and Modularity

Relationships • Association • Aggregation • Composition • Dependency • Generalization • Realization

Association Name Works for Professor University Professor University Association Class Relationships: Association • Models a semantic connection among classes Role Names Employee Employer

Student Schedule Relationships: Aggregation • A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts Whole Part Aggregation

Student Schedule Relationships: Composition • A form of aggregation with strong ownership and coincident lifetimes • The parts cannot survive the whole/aggregate Part Whole Aggregation

Association: Multiplicity and Navigation • Multiplicity defines how many objects participate in a relationships • The number of instances of one class related to ONE instance of the other class • Specified for each end of the association • Associations and aggregations are bi-directional by default, but it is often desirable to restrict navigation to one direction • If navigation is restricted, an arrowhead is added to indicate the direction of the navigation

0..* * 1..* 0..1 2..4 2, 4..6 Association: Multiplicity • Unspecified • Exactly one • Zero or more (many, unlimited) • One or more • Zero or one • Specified range • Multiple, disjoint ranges 1

Student Schedule Example: Multiplicity and Navigation Each of the above represent business rules and/or design decisions. Relationship design is covered in more detail in the Class Design module. • A Student may or may not have a Schedule. A Student may have more than one Schedule (for different semesters). • A Schedule is associated with only one Student. Multiplicity 1 0..* Navigation • A Student is aware of what Schedules he has, but a Schedule is not aware of what student it is for.

Relationships: Dependency • A relationship between two model elements where a change in one may cause a change in the other • Non-structural, “using” relationship Client Supplier Component Class Supplier Client Package Dependency relationship ClientPackage SupplierPackage Dependency relationship

A dependency relationship is a weaker form of relationship showing a relationship between a client and a supplier where the client does not have semantic knowledge of the supplier. • A dependency relationship denotes a semantic relationship between model elements, where a change in the supplier may cause a change in the client. • A dependency relationship in the UML is like the using relationship in Booch. • A plain, unadorned dependency relationship is sufficient for most of the using relationships you'll encounter. • However, if you want to specify a shade of meaning, the UML defines a number of stereotypes that may be applied to dependency relationships.

stereotypes dependency relationships among classes and objects • 1. bind • Specifies that the source instantiates the target template using the given actual parameters • the relationship between a template container class and an instantiation of that class would be modeled as a bind dependency. Bind includes a list of actual arguments that map to the formal arguments of the template. • 2. derive • Specifies that the source may be computed from the target • You'll use derive when you want to model the relationship between two attributes or two associations, one of which is concrete and the other is conceptual. For example, a Person class might have the attribute BirthDate (which is concrete) as well as the attribute Age (which can be derived from BirthDate, so is not separately manifest in the class). You'd show the relationship between Age and BirthDate by using a derive dependency, showing Age derived from BirthDate.

3. permit • Specifies that the source is given special visibility into the target • You'll use permit when you want to allow a class to access private features of another class, such as found with C++ friend classes. • 4. instanceOf • Specifies that the source object is an instance of the target classifier. Ordinarily shown using text notation in the form source : Target

5. instantiate • Specifies that the source creates instances of the target • These last two stereotypes let you model class/object relationships explicitly. You can use instanceOf when you want to model the relationship between a class and an object in the same diagram, or between a class and its metaclass; usually, however, this is shown using text syntax. You'll use instantiate when you want to specify that a class creates objects of another class. 6. powertype • Specifies that the target is a powertype of the source; a powertype is a classifier whose objects are the children of a given parent • You'll use powertype when you want to model classes that classify other classes, such as you'll find when modeling databases.

7. refine • Specifies that the source is at a finer degree of abstraction than the target • You'll use refine when you want to model classes that represent the same concept at different levels of abstraction. For example, during analysis you might encounter a Customer class which, during design, you refine into a more detailed Customer class, complete with its implementation. • 8. use • Specifies that the semantics of the source element depends on the semantics of the public part of the target

Object Oriented Analysis and Design Using the UML Version 4.2