OBJECT-ORIENTED DESIGN JEAN SIMILIEN

WHAT IS OBJECT-ORIENTED DESIGN? Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design.

WHAT ARE THE CHARACTERISTICS OF OBJECT ORIENTED DESIGN? Class definitions – Basic building blocks OOP and a single entity which has data and operations on data together Objects – The instances of a class which are used in real functionality – its variables and operations Abstraction – Specifying what to do but not how to do; a flexible feature for having a overall view of an object’s functionality.

WHAT ARE THE CHARACTERISTICS OF OBJECT ORIENTED DESIGN(CON’T…)? Encapsulation – Binding data and operations of data together in a single unit – A class adhere this feature Inheritance and class hierarchy – Reusability and extension of existing classes Polymorphism – Multiple definitions for a single name - functions with same name with different functionality; saves time in investing many function names Operator and Function overloading

WHAT ARE THE CHARACTERISTICS OF OBJECT ORIENTED DESIGN(CON’T…)? Generic classes – Class definitions for unspecified data. They are known as container classes. They are flexible and reusable. Class libraries – Built-in language specific classes Message passing – Objects communicates through invoking methods and sending data to them. This feature of sending and receiving information among objects through function parameters is known as Message Passing.

EXAMPLE OF OBJECT-ORIENTED DESIGN

OBJECT-ORIENTED DEVELOPMENT PROCESS

CONSISTENCY The use of models consisting of different sub-models within software development has numerous advantages. Different persons may work on different sub-models simultaneously driving forward the development of the system. Different types of sub-models allow the separation of different aspects of the system to be built such as structural aspects or dynamic behavior of system components.

PERSPECTIVE OF OBJECT-ORIENTED DESIGN A model is meant to capture some salient aspects of a system or problem domain. Dependent on what features are considered as most important, different means will be chosen to construct a model. Even within the confines of an object-oriented approach, there appear to be radically different perspectives of the modeling required in the various phases of the software life- cycle.

OBJECT-ORIENTED REQUIREMENTS ANALYSIS Developing object models during requirements analysis usually simplifies the transition to object-oriented design and programming. In object-oriented requirements analysis, you should model real-world entities using object classes.

USE CASES A use-case is a representation of a discrete set of work performed by a use (or another system) using the operational system. A use-case model consists of actors and use cases. An actor is an external entity that interacts with the system and a use case represents a sequence of related actions initiated by an actor to accomplish a specific goal

USE CASE EXAMPLE

USE OF UML IN OBJECT-ORIENTED DESIGN In UML, a use-case model is depicted in a use-case diagram that contains the use cases and actors for a system. Begin working with the UML by modeling all scenarios in the system or business with Use Case diagrams. Describe the system in terms of actors, which are external agents that request a service from the system, and Use Cases.

UML DIAGRAM

CLASSES A class is a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment. Object modeling, or class modeling is the key activity in object-oriented development.

HIERARCHY As we form the class hierarchy, we push the common state and behavior between lower level classes into the upper level classes. The other type of hierarchy is the "part of" hierarchy we find in our designs. This is hierarchy through aggregation.

HIERARCHY EXAMPLE

UML PACKAGE DIAGRAM

UML CLASS DESCRIPTION TEMPLATE

UML SEQUENCE DIAGRAM

UML COLLABORATION DIAGRAM

UML STATE DIAGRAM The state diagram in the Unified Modeling Language is essentially a Harel statechart with standardized notation, which can describe many systems, from computer programs to business processes.Unified Modeling LanguageHarel statechart

EXAMPLE UML STATE DIAGRAM

UML ACTIVITY DIAGRAM UML activity diagrams are typically used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule.

EXAMPLE UML ACTIVITY DIAGRAM

OBJECT-ORIENTED PROGRAM DESIGN Class: a named concept in the domain space, with an optional superclass, defined as a set of fields and methods. Field: a named property of some type, which may reference another object (see composition) Method: a named function or procedure, with or without parameters, that implements some behavior for a class. Inheritance: a class may inherit - use by default - the fields and methods of its superclass. Inheritance is transitive, so a class may inherit from another class which inherits from another class, and so on, up to a base class (typically Object, possibly implicit/absent). Subclasses may override some methods and/or fields to alter the default behavior. Composition: when a Field’s type is a class, the field will hold a reference to another object, thus creating an association relationship between them. Without getting into the nuances of the difference between simple association, aggregation, and composition, let’s intuitively define composition as when the class uses another object to provide some or all of its functionality. Encapsulation: by interacting with objects instead of directly with the implementation of methods and fields, we hide and protect the implementation of a class. If a consumer does not know anything about an object other than its public interface, then it cannot rely on any internal implementation details.

INHERITANCE Inheritance is fundamental to object-oriented programming. A programming language may have objects and messages, but without inheritance it is not object-oriented (merely “object-based”, but still polymorphic).

COMPOSITION Composition is also fundamental to every language. Even if the language does not support composition, humans still think in terms of parts and components. It would be impossible to break down complex problems into modular solutions without composition.

DATA MANAGEMENT DESIGN

STORE PERSISTENT OBJECTS A persistent object store is a computer storage system that records and retrieves complete objects, or provides the illusion of doing so. Simple examples store the serialized object in binary format. More complex examples include object databases or object-relational mapping systems, which combine a database system with support for easily storing objects. Many modern operating systems provide some sort of support for "persisting" objects in flat files, often based on XML or JSON.computer storageserializedobject databasesobject-relational mapping databaseoperating systemsXMLJSON The most important components of a persistent object store are: [1] [1] The identification of persistent objects The properties of objects and their interconnections The scale of the object store The provision of stability

DATA MANAGEMENT A database management system (DBMS) is a computer software application that interacts with the user, other applications, and the database itself to capture and analyze data. A general-purpose DBMS is designed to allow the definition, creation, querying, update, and administration of databases. Well-known DBMSs include MySQL, PostgreSQL, Microsoft SQL Server, Oracle, Sybase and IBM DB2. A database is not generally portable across different DBMSs, but different DBMS can interoperate by using standards such as SQL and ODBC or JDBC to allow a single application to work with more than one DBMS.computer softwareMySQLPostgreSQL Microsoft SQL ServerOracleSybaseIBM DB2portablestandards SQLODBCJDBC

REQUIRED STEPS IN TASK MANAGEMENT DESIGN Initiation phase Definition phase Design phase Development phase Implementation phase Follow-up phase

OBJECT-ORIENTED MEASUREMENTS Software engineering metrics are units of measurement that are used to characterize: software engineering products, e.g., designs, source code, and test cases, software engineering processes, e.g., the activities of analysis, designing, and coding, and software engineering people, e.g., the efficiency of an individual tester, or the productivity of an individual designer.

WEIGHTED METHOD PER CLASS The weighted method class metric is the sum of the complexities of all class methods. It is an indicator of how much effort is required to develop and maintain a particular class.

DEPTH OF INHERITANCE Depth of inheritance, also called depth of inheritance tree (DIT), is defined as “the maximum length from the node to the root of the tree”

RESPONSE FOR A CLASS The Response for Class (RFC) metric is the total number of methods that can potentially be executed in response to a message received by an object of a class. This number is the sum of the methods of the class, and all distinct methods are invoked directly within the class methods. Additionally, inherited methods are counted, but overridden methods are not, because only one method of a particular signature will always be available to an object of a given class.

COUPLING BETWEEN OBJECTS This software metric represents the number of other types a class or interface is coupled to. The coupling between objects metric is calculated for classes and interfaces. It counts the unique number of reference types that occur through method calls, method parameters, return types, thrown exceptions and accessed fields.

CHIDAMBER-KEMERER METRIC The metrics suite for object-oriented design put forward by Chidamber and Kemerer [8] is partly evaluated by applying principles of measurement theory. Using the object coupling measure (CBO) as an example, it is shown that failing to establish a sound empirical relation system can lead to deficiencies of software metrics. Similarly, for the object-oriented cohesion measure (LCOM) it is pointed out that the issue of empirical testing the representation condition must not be ignored, even if other validation principles are carefully obeyed. As a by-product, an alternative formulation for LCOM is proposed.

MEASURING FROM A SEQUENCE DIAGRAM Sequence diagram is a technique for the measurement of Cohesion and Coupling of Sequence Diagram using the Program Slicing. The sequence diagram contains the dynamic information of the Object Oriented system. In this work Sequence Dependency Graph (SDG) is generated from the states and scenarios of Sequence diagram. The SDG is then dynamically sliced taking various aspects into consideration. These slices can then be used to measure Cohesion and Coupling. The novelty of this approach is the direct measurement of Cohesion and Coupling of an object oriented system from Sequence diagram.