Object Oriented Design (OOD): The Concept

Transcription

1 Object Oriented Design (OOD): The Concept Objec,ves To explain how a so8ware design may be represented as a set of interac;ng objects that manage their own state and opera;ons 1

2 Topics covered Object Oriented Development (OOD) Characteris,cs of OOD Basic Principles of OOD Object Oriented Concepts Advantages of OOD Implementa,on Issues 3 RECAP ON SDLC PHASES VS. ARTEFACTS PRODUCED 2

3 Recap on SDLC Phases & Artefacts Business Domain Analysis Domain Model (Class Diagram) Requirement Analysis 1) Functional & Non-Functional requirement 2) Use Case diagram 1) System Sequence Diagram 2) Activity Diagram SRS Design 1) Class Diagram (refined) 2) Detail Sequence Diagram 3) State Diagram SDD Implementation 1) Application Source Code 2) User Manual Documentation Testing & Deployment 1) Test Cases 2) Prototype Maintenance & Evolution 1) Change Request Form (zoom into Design) Requirement Requirement Specifica,ons (Func,onal & Non Func,onal) Analysis Requirement Models (Use cases diagram, class diagram, ac,vity diagram, sequence diagram) Design Architectural design model (Package diagram) Detailed design models ( Class diagram (refined), sequence diagram (refined), state diagram) 3

4 4 Architectural Design Classifica,on Architectural Design System Organisa.on (Style/ Pa4ern) Repository Model Client Server Model Layered (Tiers) Model Pipe & Filter Model View Controller Control Style Model Centralised Call Return Manager Event Driven Broadcast Interrupt Driven Modular Composi.on Object Oriented Func,on Oriented Architectural Design Classifica,on Architectural Design System Organisa.on (Style/ Pa4ern) Repository Model Client Server Model Layered (Tiers) Model Pipe & Filter Model View Controller Control Style Model Centralised Call Return Manager Event Driven Broadcast Interrupt Driven Modular Composi.on Object Oriented Func,on Oriented

5 OBJECT ORIENTED DEVELOPMENT Object oriented Approach There have been basically 3 approaches in informa,on system development area: process oriented, data oriented and object oriented approaches The focus of first two was either on process or data, while the object oriented approach combines data and processes into single en,,es called objects. Objects usually correspond to the real things such as customers, suppliers, contracts, offices, vehicles The goal of object oriented approach is to make system elements more reusable 10 5

6 Object oriented development Key idea in object oriented development: The real world can be accurately described as a collec,on of objects that interact. Process to transform the analysis model (from OOA) into OO Design Model. From WHAT (specifica,on) into HOW (implementa,on). Assump,ons: Describing large, complex systems as interac,ng objects make them easier to understand. The behaviors of real world objects tend to be stable over,me. Changes tend to be localized to a few objects. 11 OOA (What?) OOD (How?) Analysis (OOA using UML) SPECIFICATIONS Design (OOD using UML) IMPLEMENTATION 6

7 Characteris,cs of OOD OOD process involves designing object classes and rela,onship between these classes. Objects are abstrac,ons of real world or system en,,es and manage themselves. Objects are independent and encapsulate state and representa,on informa,on. Changing implementa,on (code) of one object should NOT affect other system objects. System func,onality is expressed in terms of object services. Shared data areas are eliminated. Objects communicate by message passing. OO PRINCIPLES 7

8 Abstrac;on Polymorphism OOD Basic Principles Encapsula;on Modularity Principle#1. Abstrac,on Abstrac,on focuses on the essen,al characteris,cs of some object, rela,ve to the perspec,ve of the viewer. 8

9 Basic Principles of OOD: Abstrac,on Abstrac,on allows us to manage complexity by concentra,ng on the essen,al characteris,cs that makes an en,ty different from others. OO uses abstrac,on to depict classes and objects in a system. Principle#2. Encapsula,on Encapsula,on hides the details of the implementa,on of an object. 9

10 Basic Principles of OOD: Encapsula,on Encapsula,on separates the implementa,on of objects behavior from its public interface It is called informa,on hiding, it allows object s behavior to be used without knowing its implementa,on Offers two kinds of security: Protects object s internal state from being changed from outside users. Changes can be done to the behavior implementa,on without affec,ng other objects An analogy: When you drive a car, you don t have to know the details of how many cylinders the engine has or how the gasoline and air are mixed and ignited. Instead you only have to know how to use the controls. Principle#3. Modularity 10

11 Basic Principles of OOD: Modularity Modularity can be defined as the process of breaking up of a complex system into small, self contained pieces that can be managed easily. Packages and subsystems support the defini,on of the modularity. Classes are independent modules Principle#4. Polymorphism 11

12 Basic Principles of OOD: Polymorphism Polymorphism the same word or phrase can mean different things in different contexts Analogy: in English, bank can mean side of a river or a place to put money (one word, bank, but different meaning in different context) In OOD, Polymorphism is the ability to hide many implementa,ons behind the same interface. Example: OO CONCEPTS 12

13 Object Oriented Concepts Object Class Anribute Opera,on Interface Package Subsystem Rela,onships Object An object is a separately iden,fiable en,ty that has a set of opera,ons and a state that records the effects of the opera,ons. Objects are characterized by: state, opera,ons, iden,ty. 13

14 Object (cont.) aqributes: the collec,on of informa,on held (i.e., stored) by the object. It can change over,me. It changes as the result of an opera,on performed on the object. The anribute is encapsulated within the object opera;ons: a procedure that takes the anributes of the object and zero or more arguments and changes the state and/or returns one or more values. iden;ty: a way to dis,nguish between two dis,nct objects (even if they have the same state and opera,ons). Class A class is a template for crea,ng objects. A class describes a collec,on of related objects (i.e., instances of the classes). Objects of the same class have common opera,ons and a common set of possible states. The concept of class is closely related to the concept of abstract data type that we discussed previously. A class is a descrip,on of a set of objects that share the same anributes, opera,ons, rela,onships (Booch, 1999). An object is an instance of a class 14

15 Class (cont.) Class (cont.) In UML, a class has 3 compartments Name Anributes Opera,ons Class nota,on in UML: 15

16 Class (Anributes) Anributes is a data type held by the objects in the class. Only the object itself should be able to change the value of its anributes. Different objects of the same class Class (Opera,ons) 16

17 Classes & Objects Classes & Objects A class is an abstract defini,on of an object. It defines the structure and the behavior of each object. A class is template for producing objects of a certain type. Objects are grouped into classes An object is a run,me instances of the corresponding class 17

18 Classes & Objects Terminology Recap object usually a person, place or thing (a noun) method an ac,on performed by an object (a verb) class a category of similar objects (such as automobiles) *Class does not hold any values of the object s anributes 18

19 Stereotype A stereotype is a new class of modeling element that is introduced at modeling,me. The stereotype is a tag, or symbol, used to mark the type of an object or other construct so that it can be dis,nguished and treated differently from other types of constructs Interfaces A special class that contains a collec,on of opera,ons that are used to specify a service of a class. Interfaces specify, but not implement behaviour. 19

20 Interfaces Interfaces (cont.) 20

21 Abstrac,on with Interface Component A component is a physical and replaceable part of a system that conforms to and provides the realiza,on of a set of interfaces (Booch, 1999) Component may be: Source code component (shell scripts, data files, *.cpp) Link,me component (*.dll files): <<library>> Run,me component (Java Beans, Ac,veC controls, COM objects, CORBA objects, *.exe files): <<applica,on>>, <<table>> A component enforces Encapsula,on 21

22 Component (cont.) Packages A package is a general purpose mechanism for organizing elements into groups (Booch,1999) It is a model element which can contain other model elements As a grouping mechanism, does not have any seman,cs defined It may not have a representa,on in implementa,on (osen it may represent a directory) A package owns its elements; an element can belong to only one package A package enforces Modularity 22

23 Packages (cont.) Subsystems A system that is part of a larger system, and which has a definite interface. A model element that has the seman,cs of a package and a class that provides behavior. It implements one or more interfaces which define the behavior of the subsystem A subsystem enforces Encapsula,on & Modularity 23

24 Rela,onship between Classes / Components A rela,onship is a connec,on among things UML uses these kinds of rela,onships: Associa,on Aggrega,on Composi,on Dependency Generaliza,on Realiza,on Associa,on Rela,onship Associa,on represents a general binary rela,onship that describes an ac,vity between two classes. The rela,onship allows one class to call methods in other class. When there is associa,on between classes, instances/objects of the class has associa,on. 24

25 Associa,on Rela,onship (cont.) Association between classes Instance association Associa,on Rela,onship Mul,plicity Specifies how many objects/instances of one class may relate to a single instance of an associated class. i.e. 25

26 Associa,on Rela,onship Role A role name is a name that uniquely iden,fies one end of an associa,on. Wrinen next to the class that plays the role. i.e. Student 1SCS take core Subject Aggrega,on Rela,onship A special form of associa,on. Represents an ownership rela,onships between two classes. Models the rela,onship like has a, part of, owns. Parts may belong to mul,ple wholes. 26

27 Aggrega,on Rela,onship (cont.) Composi,on Rela,onship Models a whole/part relationship with a strong ownership; when the whole dies, the part does so as well An object can be only part of one whole object The whole part is responsible for creation and destruction of its parts 27

28 Inheritance Rela,onship is a or a kind of rela,onship Classes with proper,es in common can be grouped so that their common proper,es are only defined once. Superclass : inherit its anributes & methods to the subclass(es). Subclass : inherit all its superclass anributes & methods + have its own unique anributes & methods. Inheritance Rela,onship (cont.) Sub- Class 28

29 Inheritance Rela,onship (cont.) How do we structure these classes? Inheritance Rela,onship (cont.) A subclass inherits from its superclass: attributes operations relationships. A subclass may add to its definition: Attributes Operations Relationships Redefine inherited operations 29

30 Modeling Example Model the following scenario: Paula is married to Paul They have children Realiza,on Rela,onship A realization is a semantic relationship between classifiers in which one classifier specifies a contract that another guaranties to carry out. It is used in the context of interfaces and collaborations An interface can be realized by many classes or components A class may realize many interfaces 30

31 Dependency Rela,onship A dependency is a rela,onship that specifies that a change in one thing may affect other things that use it but not necessarily the inverse. 61 Dependency Rela,onship (cont.) 31

32 Advantages of OOD Easier maintenance. Objects may be understood as stand alone en,,es. Objects are poten,ally reusable components. For some systems, there may be an obvious mapping from real world en,,es to system objects. Implementa,on Issues Reuse When you are developing sosware, you should make as much use as possible of exis,ng code. Sosware reuse is possible at different levels The abstrac;on level: Design panern or architectural panern The object level: directly reuse objects from library rather wri,ng code yourself. E.g., you need to process message in Java, you may use objects and methods from JavaMail library. The component level: collec,on of object and object classes You write some code: User interface connected to database The system level: you resue en,re applica,on systems. It ususally involves some configura,on of these systems Configura,on Management: Version management, system integra,on (compiling), problem tracking (bug report) Host target development: development computer (host), execute program on computer (target). Host & target computers may be different. 32