Pertemuan 8 Object Oriented Modeling and Design
References Rumbaugh, James et al., Object Oriented Modeling and Design, 1991, Prentice Hall, Inc., USA, ISBN: 0 13 629841 9 9 Coad, Peter and Yourdon, Edward, Object Oriented Analysis, 1991, Prentice Hall, Inc., USA, ISBN: 0 13 630013 8 Booch, Grady et al., Object Oriented Analysis and Design with Applications, 3 rd edition, 2007, Pearson Education, Inc., USA, ISBN: 0 201 89551 X IBM Software Group, Mastering Object Oriented Analysis and Design with UML 2.0, Module 2: Concepts of Object Orientation, 2013 Igor Ivkovic, Lecture Notes, University of Waterloo.
Review Inheritance Polymorphism Aggregation g
Inheritance Inheritance is a relationship among classes wherein one class shares the structure and/or behavior defined in one (single inheritance) or more (multiple inheritance) other classes. Classes with no instances are called abstract classes. Inheritance therefore defines an is a hierarchy among classes, in which a subclass inherits it from one or more superclasses. An alternate approach to inheritance involves a language mechanism called delegation, in which objects delegate their behavior to related objects. Example: ElectricalData (sub class) inherits from the Superclass TelemetryData (super class) The class ElectricalData inherits the structure and behavior of the class TelemetryData but adds to its structure (the additional voltage data), redefines its behavior (the function transmit) to transmit the additional data, and can even add to its behavior (the function currentpower, a function to provide the current power level).
Single Inheritance (1) Example of single inheritance relationships deriving from the superclass TelemetryData. Each directed line denotes an is a relationship. For example, CameraData is a kind of SensorData, which in turn is a kind of TelemetryData.
Single Inheritance (2) Single inheritance: the subclass inherits from only one superclass (has only one parent). A subclass that augments its superclasses is said to use inheritance for extension. A subclass that constrains the behavior of its superclasses is said to use inheritance for restriction.
Multiple Inheritance Multiple inheritance: the subclass inherits from more than one superclass (has multiple parents). The class Security is a kind of Asset as well as a kind of InterestBearingItem. The class BankAccount is a kind of Asset, as well as a kind of InsurableItem and InterestBearingItem. Two problems present when we have multiple Two problems present when we have multiple inheritance: How do we deal with name collisions from different superclasses? How do we handle repeated inheritance?
Polymorphism (1) Polymorphism is a concept in type theory wherein a name may denote instances of many different classes as long as they are related by some common superclass. Any object denoted by this name is thus able to respond to some common set of operations in different ways. With polymorphism, an operation can be implemented differently by the classes in the hierarchy. A subclass can extend the capabilities of its superclass or override the parent s operation.
Polymorphism (2) The ability to hide many different implementations behind a single interface. There may be one or many implementations of a given interface. Every implementation of an interface must fulfill the requirements of that interface. In some cases, the implementation can perform more than the basic interface requirements. For example, the same remote can be used to control any type of television (implementation) that supports the specific interface that the remote was designed to be used with. Manufacturer A Manufacturer B Manufacturer C OO Principle: Encapsulation Remote Control
Interface (1) A declaration of a coherent set of public features and obligations. A contract between providers and consumers of services. Examples of interfaces are: Provided interface The interfaces that the element exposes to its environment. Required interface The interfaces that the element requires from other elements in its environment in order to be able to offer its full set of provided functionality.
Interface (2) Interfaces are the key to the plug-and-play ability of an architecture: Any classifiers (for example, classes, subsystems, components) that realize the same interfaces may be substituted t for one another in the system, thereby supporting the changing of implementations without affecting clients. Interfaces formalize polymorphism.they allow us to define polymorphism in a declarative way, unrelated to implementation. Two elements are polymorphic with respect to a set of behaviors if they realize the same interfaces. In other words, if two objects use the same behaviors to get different, but similar results, they are considered to be polymorphic. A cube and a pyramid can both be drawn, moved, scaled, and rotated, but they look very different. You have probably heard that polymorphism is one of the big benefits of object orientation, but without interfaces there is no way to enforce it, verify it, or even express it except in informal or language-specific ways. Formalization of interfaces strips away the mystery of polymorphism and gives us a good way to describe, in precise terms, what polymorphism is all about. Interfaces are testable, verifiable, and precise.
Example: A Provided Interface The ball notation is best used when you only need to denote the existence of an interface. If you need to see the details of the interface (for example, the operations), then the class/stereotype representation is more appropriate. From The Random House Collegiate Dictionary: Elide: to pass over; omit; ignore. Canonical: authorized; recognized; accepted. Elided/Iconic Representation ( ball ) Canonical (Class/Stereotype) Representation Remote Sensor <<interface>> RemoteSensor Manufacturer A Manufacturer B Manufacturer C Manufacturer A Manufacturer B Manufacturer C
Example: Connecting Interfaces Manufacturer A Remote Control Manufacturer B Remote Sensor Manufacturer C Remote Control <<interface>> RemoteSensor Manufacturer A Manufacturer B Manufacturer C
Example: A Required Interface The socket notation is best used when you only need to denote the existence of an interface. If you need to see the details of the interface (for example, the operations), then the class/stereotype representation is more appropriate. From The Random House Collegiate Dictionary: Elide: to pass over; omit; ignore. Canonical: authorized; recognized; accepted. Remote Control Remote Control Remote Sensor <<interface>> Remote Sensor Elided/Iconic Representation ( socket ) (socket) Canonical (Class/Stereotype) Representation
Aggregation (1) Student 1 0..1 Schedule An aggregation is a special form of association that models a whole part relationship between an aggregate (the whole) and its parts. An aggregation g is an Is a part of relationship. Multiplicity is represented like other associations. The class TemperatureController denotes the whole, and the p, class Heater is one of its parts.
Aggregation (2) There are many examples of aggregation: a library contains books, departments are made up of employees, a computer is composed of a number of devices. To model an aggregation, the aggregate (department) has an aggregation association to the its constituent parts (employee). A hollow diamond is attached to the end of an association path on the side of the aggregate (the whole) to indicate aggregation. An aggregation relationship that has a multiplicity greater than one for the aggregate is called shared. Destroying the aggregate does not necessarily destroy the parts. By implication, a shared aggregation g forms a graph or a tree with many roots. Shared aggregations are used where there is a strong relationship between two classes. Therefore, the same instance can participate in two different aggregations.
Composition (1) Student 1 0..* Schedule A composition is a stronger form of association in which the composite has sole responsibility for managing its parts such as their allocation and deallocation. It is shown by a diamond filled adornment on the opposite end. The relationship from Student to Schedule is modeled as a p composition because if you got rid of the Student, you would get rid of any Schedules for that Student.
Composition (2) Composition is used when: Properties need independent identities Multiple classes have the same properties Properties have a complex structure and properties p of their own Properties have complex behavior of their own Properties have relationships of their own Otherwise use attributes t
Structured Class A structured class contains parts or roles that form its structure t and realize its behavior Describes the internal implementation structure The parts themselves may also be structured classes Allows hierarchical structure to permit a clear expression of multilevel models. A connector is used to represent an association in a particular A connector is used to represent an association in a particular context Represents communications paths among parts
Structured Class Notation parta : CompositionPart connector partb : SharedPart A part or role is shown by using the symbol for a class (a rectangle) with the syntax: rolename : Typename [ multiplicity l ] All three may be omitted. If multiplicity is omitted, it defaults to one. parts A reference to an external object (one not owned by the enclosing object) is shown by a dashed rectangle.
Class Diagram versus Structure Diagram Class Diagram Structure Diagram Student Student 1 1 shared : Schedule [0..*] shared 0..* Schedule 0..* comp Schedule comp : Schedule [0..*]
Example: Structure Diagram As the system is further decomposed, each of the parts may be a structured class which contains parts themselves. This is a very effective method to visualize the system architecture. Course Registration System : StudentManagementSystem : BillingSystem : CourseCatalogSystem
Generalization (1) A relationship among classes where one class shares the structure and/or behavior of one or more classes Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses Single inheritance Multiple inheritance Is an is a kind of relationship
Generalization (2) The subclass may be used where the superclass is used, but not vice versa. The child inherits from the parent. Generalization is transitive. You can always test your generalization by applying li the is a kind of rule. You should always be able to say that t your specialized class is a kind of the parent class. The terms generalization and inheritance are generally interchangeable. If you need to distinguish, generalization is the name of the relationship, while inheritance is the mechanism that the generalization relationship represents/models.
Dependency (1) Relationship between two model elements where a change in one may cause a change in the other. Non structural, using 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 A dependency relationship denotes a semantic relationship between model elements, where a change in the supplier may cause a change in the client.
Dependency (2) Class Component The <<use>> stereotype is implicit pctand ddoesdoes not need to be shown. Client Client Supplier Supplier Dependency relationship Dependency relationship lti Dependency relationship Package ClientPackage SupplierPackage
Realization (1) Realization is a semantic relationship between two classifiers. One classifier serves as the contract that the other classifier agrees to carry out. Found between: Interfaces and the classifiers that realize them Use cases and the collaborations that realize them Interfaces and the classifiers that realize them Component Class <<subsystem>> Subsystem <<interface>> InterfaceName <<interface>> InterfaceName <<interface>> InterfaceName Use cases and the collaborations that realize them Collaboration UseCase
Realization (2) The realizes relationship is a combination of a dependency and a generalization. It is not true generalization, as only the contract t (that t is to say, operation signature) is inherited. This mix is represented in its UML form, which is a combination of dependency and generalization. The realizes relationship may be modeled as a dashed line with a hollow arrowhead pointing at the contract classifier (canonical form), or when combined with an interface, as a ball (elided form). Again, from The Random House Collegiate Dictionary: Elide: to pass over; omit; ignore. Canonical: authorized; recognized; accepted.
Port A port is a structural feature that encapsulates the interaction between the contents of a class and its environment. Port behavior is specified by its provided and required interfaces Permits the internal structure to be modified without affecting external clients External clients have no visibility to internals A class may have a number of ports Each port has a set of provided and required interfaces Since the port is a structural element, it s created and destroyed along with its structured class. Another class connected to a port may request the provided services from the owner of the port but must also be prepared to supply the required services to the owner.
Port Notation A port is shown as a small square with the name placed nearby. portname Ports may be public, protected or private
Port Types Ports can have different implementation types Service Port Is only used for the internal implementation of the class Behavior Port Requests on the port are implemented directly by the class Relay Port Requests on the port are transmitted to internal parts for implementation The use of service ports are rare because the main purpose of ports is to encapsulate communication with the environment. These ports are located inside the class boundary. Behavior ports are shown by a line from the port to a small state symbol (a rectangle with rounded corners). This is meant to suggest a state machine, although other forms of behavior implementation are also permitted.
Example: Structure Diagram with Ports Structured Class Name Behavior Port Relay Port Service Port parta partb
Diagram Depiction (1) Each diagram has a frame, a heading compartment in the upper left corner, and a contents area. If the frame provides no additional value, it may be omitted and the border of the diagram area provided by the tool will be the implied frame. <heading> <contents area>
Diagram Depiction (2) A heading compartment is a string contained in a name tag (a rectangle with cutoff corner) in the upper leftmost corner with the following syntax: [<kind>]<name>[<parameters>] This <kind> can be: activity - activity diagram, package - class diagram, package diagram, communication - y y g, p g g, p g g, communication diagram, component - component diagram, class - composite structure diagram, deployment - deployment diagram, intover - interaction overview diagram, object - object diagram, state machine - state machine diagram, sd - sequence diagram, timing - timing diagram, use case - use case diagram
Notes MaintainScheduleForm There can be up to one MaintainScheduleForm per user session. A comment that is added to include more information on the diagram May be added to any UML element A dog eared rectangle May be anchored to an element with a dashed line
Requirement The purpose p of Requirements is to: Establish and maintain agreement with the customers and other stakeholders on what the system should do. Give system developers a better understanding of the requirements of the system. Delimit the system. Provide a basis for planning the technical contents of the iterations. Provide a basis for estimating cost and time to develop the system. Define a user interface of the system.
Relevant Requirements Artifacts (1) Use Case Model Actors Use Cases Glossary... Use Case Specifications Supplementary Specification
Relevant Requirements Artifacts (2) The Use-Case Model describes what the system will do. The Use-Case Model serves as a contract between the customer, the users, and the system developers. It allows customers and users to validate that the system will become what they expected and allows system developers to ensure that what they build is what is expected. The Use-Case Model consists of use cases and actors. Each use case in the model is described in detail, showing step-by-step how the system interacts with the actors and what the system does in the use case. The Use-Case Specification is the document where all of the use-case properties are documented (for example, brief description and use-case flows of events). Note: The OOAD course requirements documentation includes Use-Case Specifications because it is the textual description that will drive Analysis and Design activities. (Use-case specifications only include the textual use-case properties.) The Glossary defines a common terminology for all models and contains textual descriptions of the required system. The Supplementary Specification contains those requirements that do not map to a specific use case (for The Supplementary Specification contains those requirements that do not map to a specific use case (for example, nonfunctional requirements). The Supplementary Specification is an important complement to the Use-Case Model. Together they capture all requirements (functional and nonfunctional) that need to be described for a complete System Requirements Specification.
System Behavior? System behavior is how a system acts and reacts. It is the outwardly visible and testable activity of a system. System behavior is captured in use cases. Use cases describe the system, its environment, and the relationship lti between the system and its environment.
Major Concepts in Use Case Modeling An actor represents anything that interacts with the system. An actor represents a coherent set of roles that users of the system play when interacting with these use cases. Typically, an actor represents a human, a hardware device, or some other external system. In UML 2, actors should be named whenever possible. A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor. A use case describes what a system does, but it does not specify how it does it. Whenever space permits, put the name of the use case inside the icon. Use Case Actor
Use Case Model (1) A model that describes a system s functional requirements in terms of use cases A model of the system s intended functionality (use cases) and its environment (actors) Student View Report Card Register for Courses Login
Use Case Model (2) The Use-Case Model serves as a contract between the customer and the developers. Because it is a very powerful planning instrument, the Use-Case Model is generally used in all phases of the development cycle. When the customer approves the Use-Case Model, it s a mutual understanding with the development team of what the customer wants. You can use the model to discuss the system with the customer during development. Potential users use the Use-Case Model to better understand the system. Designers use it as a basis for their work and to get a system overview. Testers use it to plan testing activities (use case and integration testing) as early as possible. Those developing the next version of the system use it to understand how the existing version works. Documentation writers use the use cases as a basis for writing the system user guides. The architect uses the Use-Case Model to identify architecturally significant functionality. The manager uses it to plan and follow up on use-case modeling and subsequent design.
The Benefits of a Use Case Model (1) Communication with the end users and domain experts: Provides buy-in at an early stage of system development. Ensures a mutual understanding of the requirements. Identification of system users and what the system should do: Establishes the requirements for the system interfaces. Verification that all requirements have been captured: Ensures that the development team understands the requirements. The Use-Case Model is also used to identify the actors that interact with y the system. Because they represent system users, actors help delimit the system and give a clearer picture of what it is supposed to do. Use cases are developed on the basis of the actors' needs, ensuring that the system will turn out to be what the users expected.
The Benefits of a Use Case Model (2) Use Case Communication Ident tification Verification End User Domain Expert Users
Example Answer the following questions: View Report Card Register for Courses Course Catalog Maintain Professor Information 1. Which use cases can a student perform? Student t A professor? The Course Catalog? 2. If Charlie is a student and professor, which use cases can he execute? 3. Describe the functionality of this system. Login Registrar Maintain Student Information 4. Describe the actor relationships for the Close Registration and Select Courses To Teach use cases. Professor 5. Which use case needs to run first, Register for Courses or View Report Card? Select Courses to Teach Submit Grades Billing System Close Registration
Another Example
Use Case Specifications (1) Name Use Case Model Brief description Flow of Events Actors Relationships Activity diagrams Use Cases Use Case diagrams Special requirements Pre conditions Post conditions Other diagrams... Use Case Specifications
Use Case Specifications (2) The use case has a set of properties as shown in the graphic. The use-case properties may be documented in use-case specifications, which can include the items listed below: Brief description describes the role and purpose of the use case. Flow of events are textual descriptions of what the system does with regard to the use case. There can be multiple flows of events for example, a basic flow and alternative flows. Relationships are associations. The use case can include and extend relationships that the use case participates in. Activity diagrams can be used to illustrate the structure of the flow of events. Use-case diagrams can be used to show the relationships involving the use case. Special requirements is a textual description that collects all use-case requirements, like nonfunctional requirements, that are not considered in the Use-Case Model, yet need to be taken care of during design or implementation. Pre-conditions define a constraint on the system regarding when the use case may start. Post-conditions define a constraint on the system that applies after the use case has terminated. Other diagrams can be used to illustrate the use case, like hand-drawn sketches or screen captures from an user-interface prototype.
Another Type of Use Case Specifications (1) Describe the system Name Overview Actor Use case Describe the use case scenario Use case name Description Participating actor Extend (from base) Quality requirement Related requirement (inclusion & extension) Main course / typical flow Entry condition / pre condition Exit condition / post condition Alternate course Exception
Another Type of Use Case Specifications (2) Hotel Reservation System: Description: Hotel reservation system is a system that Overview The following terms and entities are specific to the system Potential guest are can Room reservation can Actor: potential guest, frequent traveler Use case: make room reservation, make facility reservation,
Another Type of Use Case Specifications (3) Use case: make room reservation Description: the make room reservation use case allows the actor (reserver) t0 Participating actor: reserver Quality requirement: reserver will receive respond from the system in less than 3 seconds Related requirement: guarantee reservation, upgrade reservation, Main course: successful credit card transaction Pre condition: actor reach the hotel s website wanting to make reservation Post condition: actor has a confirmed room reservation 1. The use case starts when the actor 2. prompts for 3. this use case ends when the actor
Another Type of Use Case Specifications (4) Alternate course Pre condition: at step 15 of the main course, the actor will be asked to fill a survey 1 2 Exception Pre condition: at step 3 of the main course, the actor Post condition: i 1 2
Relationship Generalization: multiple use cases or actors with commonality can be generalize into one use case or actor. Include: common behavior of more than one use case is referenced as a separate instance. Extend: additional use case extension of the base use case.
Example: Generalization Generalizing actor Generalizing use case
Include
Extend
Scenario: Manage Course Information
Scenario: Create New Course
Scenario: Modify Existing Course