CS 432 Object-Oriented Analysis and Design * 07/16/96 CS 432 Object-Oriented Analysis and Design Week 3 The Design Model *

What is Object-Oriented Design? The bridge between a user’s requirements and programming for the new system “Blueprints”, or design models, are necessary to build systems An adaptive approach to development Requirements and design are done incrementally within an iteration A complete set of designs may not be developed at one time

Overview of Object-Oriented Programs Object-oriented programs consist of a set of computing objects that cooperate to accomplish a result Each object has program logic and data encapsulated within it Objects send each other messages to collaborate Most object-oriented programs are event-driven Instantiation of a class creates an object based on the template provided by the class definition

Object-Oriented Design Models Identify all objects that must work together to carry out a use case Divide objects into groups for a multilayer design Interaction diagrams describe the messages that are sent between objects Includes sequence and communication diagrams Design class diagrams document and describe the programming classes

Object-Oriented Design Models (continued) Statecharts capture information about the valid states and transitions of an object Package diagrams denote which classes work together as a subsystem Design information is primarily derived from Domain model class diagrams Interaction diagrams

Object-Oriented Design Process Create a first-cut model of the design class diagrams Develop interaction diagrams for each use case or scenario (communication or sequence) Update the design class diagrams Method names, method parameters, attributes, attribute data types, and relationship multiplicity Partition the design class diagrams into related functions using package diagrams

Design Classes and Design Class Diagrams Design class diagrams are extensions of domain or analysis class model diagrams Elaborate on attribute details Define parameters and return values of methods Define the internal logic of methods A first-cut design class diagram is based on the domain model and engineering design principles Interaction diagrams are used to refine a design class diagram as development progresses

The Design Workflow The input to the design workflow is the set of analysis workflow artifacts These artifacts are iterated and incremented until they can be used by the programmers A major aspect of this iteration and incrementation is The identification of operations or methods The identification of method parameters and parameter data types The identification of attribute types, and Their allocation to the appropriate classes Relationships between classes – type and multiplicity

The Design Workflow (contd) Many other decisions have to be made as part of the design workflow, including Choice of programming language Deciding how much of existing information systems to reuse in the new information system Level of portability The allocation of each software component to its hardware component

The Design Workflow (contd) The case studies in this class are small-scale information systems Under 5,000 lines of Java or C++ code in length The Unified Process was designed for developing large-scale information systems 500,000 lines of code or more These information systems are at least 100 times larger than the case studies presented in this class Therefore, some aspects of the Unified Process are inapplicable to our case studies

The Design Workflow (contd) During the analysis workflow, a large information system is partitioned into analysis packages Each analysis package consists of a set of related classes that can be implemented as a single unit Example: Accounts payable, accounts receivable, and general ledger are typical analysis packages The concept underlying analysis packages is: It is easier to develop smaller information systems than larger information systems A large information system will be easier to develop if it can be decomposed into independent packages

The Design Workflow (contd) The idea of decomposing a large workflow into independent smaller workflows is carried forward to the design workflow The objective is to break up the upcoming implementation workflow into manageable pieces Subsystems

The Design Workflow (contd) Reasons why subsystems are utilized It is easier to implement a number of smaller subsystems than one large system If the subsystems are independent, they can be implemented by programming teams working in parallel The information system as a whole can then be delivered sooner

The Design Workflow (contd) The architecture of an information system includes The various component modules How they fit together The allocation of components to subsystems The task of designing the architecture is specialized It is performed by an information system architect

The Design Workflow (contd) The architect needs to make trade-offs Every information system must satisfy its functional requirements (the use cases) It also must satisfy its nonfunctional requirements, including Portability, reliability, robustness, maintainability, and security It must do all these things within budget and within the time constraint The architect must assist the client by laying out the trade-offs

The Design Workflow (contd) It is usually impossible to satisfy all the requirements, functional and nonfunctional, within the cost and time constraints Some sort of compromises have to be made The client has to Relax some of the requirements; Increase the budget; and/or Move the delivery deadline

The Design Workflow (contd) The architecture of an information system is critical The requirements workflow can be fixed during the analysis workflow The analysis workflow can be fixed during the design workflow The design workflow can be fixed during the implementation workflow But there is no way to recover from suboptimal architecture The architecture must immediately be redesigned

Traditional versus Object-Oriented Design In the traditional paradigm, the design phase consists of Architectural design The information system is decomposed into modules followed by Detailed design Algorithms and data structures are designed for each module

Traditional versus Object-Oriented Design (contd) Classes are modules Much of traditional architectural design is performed as part of class extraction in the object-oriented analysis workflow

Some Fundamental Design Principles Encapsulation Each object is a self-contained unit containing both data and program logic Object reuse Standard objects can be used over and over again within a system Information hiding Data associated with an object is not visible Methods provide access to data

Some Fundamental Design Principles (contd) Navigation visibility Describes which objects can interact with each other Coupling Measures how closely classes are linked Want LOW coupling Cohesion Measures the consistency of functions in a class Want HIGH cohesion Separation of responsibilities Divides a class into several highly cohesive classes

University System Use Case Diagram

Analysis Class Diagram

How to Create Design-Level Class Diagrams To create and evolve a design class diagram, you need to iteratively model: Classes Responsibilities Associations Inheritance relationships Composition associations Association classes Interfaces

Classes An object is any person, place, thing, concept, event, screen, or report applicable to your system. Objects both know things (they have attributes) and they do things (they have methods). A class is a representation of an object and, in many ways, it is simply a template from which objects are created. Classes form the main building blocks of an object-oriented application.  Although thousands of students attend the university, you would only model one class, called Student, which would represent the entire collection of students.

Classes Classes are typically modeled as rectangles with three sections: the top section for the name of the class, the middle section for the attributes of the class, and the bottom section for the methods of the class.

Attributes & Methods Attributes are the information stored about an object (or at least information  temporarily maintained about an object) Students have student numbers, names, addresses, and phone numbers. Methods are the things an object or class do. Students also enroll in courses, drop courses, and request transcripts. You should think of methods as the object-oriented equivalent of functions and procedures.

Responsibilities or Methods How to find responsibilities which are methods? Ask these questions: How am I going to be used? How am I going to collaborate with other classes? How am I described in the context of this system's responsibility? What do I need to know? What state information do I need to remember over time? What states can I be in?

Identifying Responsibilities or Methods Methods usually correspond to queries about attributes (and sometimes association) of the objects. Methods are responsible for managing the value of attributes such as query, updating, reading and writing.

Level of Detail An important consideration the appropriate level of detail. Consider the Student class modeled which has an attribute called Address. Notice how the Address class has been modeled to include an attribute for each piece of data it comprises and two methods have been added: one to verify it is a valid address and one to output it as a label (perhaps for an envelope). By introducing the Address class, the Student class has become more cohesive. The Address class could now be reused in other places, such as the Professor class, reducing your overall development costs. A student may live in a different location than his permanent mailing address, such as a dorm¾information the system may need to track. Having a separate class to implement addresses should make the addition of this behavior easier to implement.

Level of Detail in a Design-Level Class Diagram Class information: visibility and scope

Constructors Constructor methods provide a way of initializing an object. A constructor method has the same name as its class and is automatically invoked by the object-oriented programming environment (e.g., the Java Virtual Machine) when new instance objects of a class are created. As the return type of the constructor is always the same as the class and the constructor’s name, the return type is often omitted from the UML visual representation of the constructor. Since a constructor may also have parameters like any method, the parameters of a constructor can be used to assign initial values to the attributes of the object.

Constructor Example In programming source code, new instance objects are created by using the new command, which executes any code in the constructor, and returns the new object. // Create a new account object with id 12 and // assign it to the acct variable. Account acct = new Account(12); // Get the id of the new account object. int id = acct.getId();

Refactoring or Class Normalization A process in which you refactor the behavior of classes to increase their cohesion and/or to reduce the coupling between classes. A seminar is an offering of a course, for example, there could be five seminar offerings of the course "CS 208 Introduction to Computer Science."  The attributes name and fees were moved to the Course class and courseNumber was introduced.

Course with Accessor and Mutator Methods Depicts Course as it would appear with its getter and setter methods modeled

Associations (Binary Relationships) Objects are often associated with, or related to, other objects. Several associations exist: Students are ON WAITING LIST for seminars Professors INSTRUCT seminars Seminars are an OFFERING OF courses A professor LIVES AT an address Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship. When you model associations in UML class diagrams, you show them as a thin line connecting two classes The label, which is optional, although highly recommended, is typically one or two words describing the association. For example, professors instruct seminars.

Associations (contd) UML Notation: You also need to identify the multiplicity of an association. The multiplicity of the association is labeled on either end of the line, one multiplicity indicator for each direction

Multiplicity Indicators Meaning 0..1 Zero or one 1 One only 0..* Zero or more 1..* One or more n Only n (where n > 1) 0..n Zero to n (where n > 1) 1..n One to n (where n > 1)

Multiplicity: 1-to-1 (Bank Example) This multiplicity simply indicates that one Customer object owns exactly one Account Object, and the Account is owned by exactly one customer object.

Multiplicity: Many-to-1 (University Example)

Inheritance Relationships Similarities often exist between different classes. Very often two or more classes will share the same attributes and/or the same methods. Because you don’t want to have to write the same code repeatedly, you want a mechanism that takes advantage of these similarities. Inheritance models “is a” and “is like” relationships, enabling you to reuse existing data and code easily. When A inherits from B, we say A is the subclass of B and B is the superclass of A. The UML modeling notation for inheritance is a line with a closed arrowhead pointing from the subclass to the superclass.

Inheritance hierarchy

Guidelines For Identifying Super-sub Relationships: Top-down Look for noun phrases composed of various adjectives on class name. Example, Military Aircraft and Civilian Aircraft. Only specialize when the sub classes have significant behavior.

Guidelines For Identifying Super-sub Relationships: Bottom-up Look for classes with similar attributes or methods. Group them by moving the common attributes and methods to super class. Do not force classes to fit a preconceived generalization structure.

Guidelines For Identifying Super-sub Relationships: Reusability Move attributes and methods as high as possible in the hierarchy. At the same time do not create very specialized classes at the top of hierarchy. This balancing act can be achieved through several iterations.

Guidelines For Identifying Super-sub Relationships: Multiple inheritance Avoid use of multiple inheritance. It is also more difficult to understand programs written in multiple inheritance system. Java does not support multiple inheritance but C++ does.

Multiple Inheritance One way to achieve the benefits of multiple inheritance is to inherit from the most appropriate class and add an object of other class as an attribute. In essence, a multiple inheritance can be represented as an aggregation of a single inheritance and aggregation. This meta model reflects this situation Multiple Inheritance Single Inheritance Aggregation

Abstract Classes & Inheritance The Person class is abstract: objects are not created directly from it, and it captures the similarities between the students and professors. Abstract classes are modeled with their names in italics, as opposed to concrete classes, classes from which objects are instantiated, whose names are in normal text. Both classes had a name, e-mail address, and phone number, so these attributes were moved into Person. The Purchase Parking Pass method is also common between the two classes. By introducing this inheritance relationship to the model, the amount of work to be performed was reduced. Instead of implementing these responsibilities twice, they are implemented once, in the Person class, and reused by Student and Professor.

Aggregation Relation An aggregation is an association that supports a loose relation between objects in which one object is considered a “part of” the other object in the relation. Consider the relation between a Computer and a Printer. “a Computer may be attached to 0 or more Printers; at any one point in time a Printer is connected to 0 or 1 Computer; over time, many Computers may use a given Printer; the Printer may exist even if there are not attached Computers the Printer is, in a very real sense, independent of the Computer.”

Composition Relation A composition relation is a stronger form of aggregation that should be used when the part class has no independent existence from the whole. For example, since a customer’s account would not exist in a system without the customer, it qualifies as a composite relation. In this capacity an Account should be though of as being part-of a customer.

Composition Relation (contd) Another example: A building is composed of one or more rooms, and then, in turn, that a room may be composed of several subrooms (you can have recursive composition)

Customer Order from a Retail Catalog

Video Store Example 1 1..* 1 0..1 Multiplicity Customer Simple Aggregation Class Abstract Class Rental Invoice Rental Item 1..* 1 0..1 Composition Simple Association Generalization Checkout Screen DVD Movie VHS Movie Video Game

Association Classes The association between the two classes may be modeled as a class You use this when you have many-to-many relationships like the association class in an ERD

Interfaces The C# and Java programming languages allow for the creation of interface entities that capture a collection of methods representing a public interface. (C++ uses abstract classes) An interface is similar to an abstract class that does not have any concrete methods at all. An interface is simply a collection of method signatures. A List interface provides a nice example of the benefits of using interfaces.

Interfaces (contd)

Interfaces (contd) Interfaces are implemented, “realized” in UML parlance, by classes and components To realize an interface a class or component must implement the operations.  Any given class or component may implement zero or more interfaces and one or more classes or components can implement the same interface.

Polymorphism Polymorphism means many forms and concerns the ability of an object to dynamically take on a different form depending on the runtime context. Although technically correct, this definition is a bit misleading since the object does not exactly change form, but instead the way in which it’s viewed by other objects changes. We should also note that polymorphism involves the behavior of objects.

Polymorphism (contd) Consider the following three class fragments taken from a graphical user interface application. The abstract Component class represents a generic component that captures the common functionality of graphical widgets that can be displayed on a canvas/window. The Button and TextField classes share the common functionality, having an (x, y) position in the window and responding to messages requesting them to paint themselves on the canvas, erase themselves, and move themselves from one location to another.

Polymorphism (contd)

Polymorphism (contd) Assume we are given a List of component objects which we wish to draw on the screen. The following pseudo-code would accomplish this desire: ForEach component In the list Do Send the component a paint() message; Polymorphism concerns the fact that although we are sending messages to Component objects, the actual method that handles the message will be executed as part of a Button or TextField object. When an object receives a message, the most specific method of it’s parent class or it’s ancestors will execute. However, the key point isn’t what method executes, but what the type of object is receiving the message.

Signatures and Method Overloading A significant difference between procedural functions and object-oriented methods concerns method overloading, which is based on the concept of signatures. A method signature is the combination of its visibility, name, parameter cardinality (number of parameters), the types of these parameters, and its return type. For example, all of the methods in the following list have different signatures: +getId():int OR -getId():int // Visibility differs +getBalance():int // Different name +withdraw(amount:int):void // Different name +withdraw(amount:float):void // Parameter type differs +withdraw(id: int,amount:float):void// Different parameter cardinality Note that current object-oriented programming languages require that all methods in the same class and with the same name have the same return type.

Overloading An overloaded method occurs when two or more methods with the same name in the same class have different signatures. For example, the Withdraw method in the following example class is overloaded. In this example the withdraw method is overloaded since the parameter type of the single parameter is different in each method. When an object of this Account class receives a withdraw method, the object-oriented execution environment (e.g., the Java Virtual Machine) will dynamically select and execute the withdraw method with the corresponding parameter type.