Object-Oriented Software Life Cycle
SOLID principles • Single Responsibility – Each object should be responsible for only one task or functionality in the application. • Open Close – Open for extensions and closed for modifications • Liskov’s Substitution – Polymorphic substitution of objects CS 446/546 2
SOLID principles (continued) • Interface Segregation – Clients should only use the objects through the object’s interface • Dependency Inversion – Objects should depend on their abstractions, not on their levels (high-level, low-level, …) – Abstraction should not depend on details; rather, details should depend on abstractions • SOLID principles introduced by Robert Martin in early 2000. CS 446/546 3
Stages in OO life cycle • Requirements engineering – requirements gathering, analysis and specification – inherently procedural because customers describe what the software system is supposed to do • OO Design – architectural design – detailed design – both require the transformation of functional requirements into OO design elements • Implementation or Coding or Programming using OO programming languages and tools CS 446/546 4
Stages in OO life cycle (continued) • Testing – unit testing; test methods within each object – integration testing; test collaborations between objects – system testing; test the entire system as a collection of objects – acceptance testing; test for standards and customer satisfaction CS 446/546 5
Maintenance • fixing bugs, enhancements, adapting to changing environment – all the three activities require that some objects to be changed; easy to trace those objects • add developed classes to library of classes, if appropriate – generalization • (possibly) create patterns and frameworks – reuse CS 446/546 6
Procedural and OO life cycles Procedural Object-Oriented Requirements Design Programming CS 446/546 7
3 -Tier Modeling of a data oriented system GUI Database Application CS 446/546 DB Interface 8
OO Definitions and Concepts
Object • What characterizes an “object”? – An object should possess attributes or behaviors, preferably both – An object can be primitive and wellunderstood • Example: – An object can be complex and needs to be defined further • Example: – Only those objects that are relevant to the goal of the problem should be modeled CS 446/546 10
Exercise Identify the objects in the following problems A small store attached to a gas station sells several items. The store uses a database to maintain inventory, sales and profits. A report is generated at the end of each day on sales and purchases. An intelligent traffic signal has four lights – RED, AMBER, GREEN and GREEN ARROW. The green arrow is turned on only when there is at least one vehicle on the turning lane. The signal is associated with a sensor to identify the vehicles in the turning lane. CS 446/546 11
Class and Objects A class represents a group of objects who share similar structure and behavior • Class • Objects – Receipt from Best. Buy, Receipt on Dec 12 – President’s speech, Keynote speech in a conference – Speech CS 446/546 12
Class Vs Object • Template • Created/defined by programmers • Can be abstract • One class represents a collection of objects • Actual structures with values (concrete) • Created by run-time system • Cannot be abstract • Each object belongs to exactly one class (traditional definition) CS 446/546 13
Class Vs Object (continued) • Class name serves as • Possesses an internal the identity, generated by the run-time system • Static; serves as a source of definitions; • Dynamic; created and possibly never be destroyed during destroyed execution; some objects may persist even after termination of execution CS 446/546 14
A bit of Theory • Classes are implementations of Abstract Data Types (ADTs) • An Abstract Data Type (ADT) is defined only by its behaviors without committed to any implementation – a Stack ADT • a behavior: Elements can be pushed in or popped out from one end of the stack. • The actual representation of the elements is not part of the definition of stack – a speech ADT • a behavior: must have a topic and contents • The actual representation of the topic or contents is not part of the definition of speech CS 446/546 15
A bit of Theory (continued) • Classes are implementations of ADTs • Why? – A class has a structure, along with its behavior – The integer data type is an ADT – The integer class in OO has a representation and hence a limitation (32 bits, 64 bits etc. ) – The stack is an ADT – The stack class has a structure; may use an array for implementation; has a limited size CS 446/546 16
Encapsulation • When an object is encapsulated, its internal details are hidden and its usage is exhibited through its external interface. • Example: – Explain how an item in a store is encapsulated. CS 446/546 17
Encapsulation – a question • How to identify components of an external interface? How to identify internal details of an object? – needs application domain information and access restrictions • what seems to be an external interface for one person may be an internal detail for another person – levels of access restrictions • public, private, protected – terms used by C++ and Java • not just these; may be more CS 446/546 18
Encapsulation Vs Information Hiding • Encapsulation is a concept • Information hiding (how to) is a concretization process of encapsulation (what) – information hiding implements encapsulation • OO analysis deals with encapsulation • OO design and implementation take care of information hiding CS 446/546 19
Communication between Objects • Objects communicate with each other or interact among themselves by message-passing • Single thread of control - client-server mode of communication – Client sends a message to server indicating a request and server sends a response back to client through another message – Requires that client and server know each other – Communication link established statically or dynamically CS 446/546 20
Communication (continued) • Multiple threads of control – Each object sends messages to one or more objects and continues to execute its own tasks – Information shared through messages – Each object should know the other objects with which it communicates – Communication link established statically or dynamically CS 446/546 21
Communication (continued) • Pre-defined / static communication links – Designer / programmer knows / decides well in advance the links between the objects – Explicit in the class definitions • inheritance, aggregation, association (will be discussed shortly) • Dynamic communication links – Decided at run-time • delegation CS 446/546 22
Static Relationships among Classes
Static Relationships • Decided during the analysis phase and/or the design phase, and carried over to the implementation phase • Establish static communication links • Three types – -Association – -Aggregation – -Generalization/specialization CS 446/546 24
Association • Denotes a relationship between the objects • Some relationship between the objects that is meaningful in the chosen application domain • Synonymous to “relation” in databases CS 446/546 25
Association – example 1 • In a course registration system, – A student object has an association with a course object • the student object depends on some information in the course object – The course object has another (different) association with the student object • the course object needs to know the identification of the student if he/she registered for that course – Both associations are unidirectional CS 446/546 26
Association – example 2 • In an automated ticket purchasing system, – A customer object has an association with a ticket object • Customer purchases ticket – An administrator object may have an association with the ticket object • Administrator changes the price of a ticket – Both associations are unidirectional CS 446/546 27
Association – Example 3 • In a university game system, – A game object has an association with a team object – A player object has an association with a team object – A game may have an association with a player object • The best player of the game • This is a ternary (3 -way) association CS 446/546 28
Association – Example 4 • In an office environment, – A person object may have an association with another person • One person works for another person OR • One person supervises another person • In a computer program, – A statement has an association with another statement • The body of an IF statement may include an assignment statement • These are unary (1 -way) associations CS 446/546 29
Association (continued) • Generally identified during the analysis phase – Not all associations are refined into the design phase and/or into the implementation phase • Some are useful in understanding the application domain and may lead to a better design • N-ary associations may give clues to identify concurrency issues CS 446/546 30
Association - exercises Identify the objects and associations between them in the following problems A small store attached to a gas station sells several items. The store uses a database to maintain inventory, sales and profits. A report is generated at the end of each day on sales and purchases. An intelligent traffic signal has four lights – RED, AMBER, GREEN and GREEN ARROW. The green arrow is turned on only when there is at least one vehicle on the turning lane. The signal is associated with a sensor to identify the vehicles in the turning lane. CS 446/546 31
Specialization • Specialization is also called “Generalization” relationship • Specialization describes how one class becomes a specialized version of another class – There must be some difference between the two classes but there must also be some commonality. – Do not use specialization relationship just for code reuse purposes CS 446/546 32
Specialization (continued) • Specialization relationship forms a hierarchy and is defined from a child to a parent • It is a transitive relation – If a grandchild is a specialization of a child and the child is a specialization of a parent, then the grandchild is a specialization of the parent • Example: – A Color Laser Printer is a specialization of a Laser Printer which in turn is a specialization of a Printer – Find out the differences and common features between the child and parent classes CS 446/546 33
Specialization (continued) • Another name for the specialization relationship is “generalization” which is a view from parent to child • The parent class is called “superclass”, “base class”, or “parent” • The child classes are called “subclasses”, “specialized classes”, “derived classes” or “children” CS 446/546 34
Specialization - Exercise • Give some classes and specialization relationships for the following problem: – A software system that maintains the catalog of materials in a university library – A software system used by a car dealer – An electronic voting system CS 446/546 35
Multiple specialization relationship • A subclass may be a specialized version of more than one superclass • It is called “multiple inheritance property” in OO programming languages • Designers must ensure that the properties inherited from the multiple superclasses do not conflict with each other – Most of the OO programming languages provide some mechanism to work around this problem CS 446/546 36
Aggregation • Also known as “composition” relationship, and “has-a/contains” relationship • Synonymous to “structure” in C and C++ – Basic idea is to group a set of entities/fields into one single bundle and use it as a single entity • Denotes composition of objects – An aggregate object encloses a component object – The aggregate object cannot exist without the component but the component may exist without the aggregate CS 446/546 37
Aggregation (continued) • Examples – A person object encloses an address object – A ticket object encloses date object – A seminar object encloses a contents object, a theme object and a duration object – A book object encloses …. – A car object encloses …. CS 446/546 38
Aggregation (continued) • Sometimes reflexive (recursive aggregation) – A procedure may contain another procedure (Pascal) – A class may contain another class (Java) – Requires careful design and implementation mechanisms • Aggregation is a special case of Association – Is it not interesting to know? • A person object contains an address object • So, the person object depends on the address object existence of a semantic dependency CS 446/546 39
Aggregation - exercises • Define the aggregation relationships, if any, in – The library catalog system discussed earlier – The software system used by the car dealer – The electronic voting system CS 446/546 40
Confusion between Specialization and Aggregation • Often, designers and programmers (particularly the latter) get confused between specialization and aggregation – Consequence: choose the wrong relationship – Will this decision affect the software product? • YES… in the long run. . may not be significant CS 446/546 41
Specialization Vs Aggregation • Relationship between classes • Objects of these classes are totally unrelated • Is not reflexive • Relationship between objects, even though their respective classes are used to define the relationship • Objects are related by composition • Sometimes reflexive (recursive aggregation) CS 446/546 42
Specialization Vs Aggregation An Example • Toyota Camry is a Car – by “is a” relationship, we can say Camry is a specialization of a car Specialization • The class car has an attribute called “model” which is instantiated with the value “Camry” Aggregation – car is an aggregate and “Camry” is the value of one of its component, namely model • Both are indeed correct – which one to choose…. depends on the context CS 446/546 43
Specialization Vs Aggregation – Another example • An ENT specialist is a specialization of a physician in a hospital – specialization relationship • A physician object includes a field called “specialty” that describes the specialization of a physician – aggregation relationship • The first one may be used in the hospital whereas the second one may be used in the City Office for book-keeping CS 446/546 44
Abstract Class • A class that cannot be instantiated – No direct objects for this class • At least one of its behavior definitions must be incomplete – Example: The class Printer has a behavior “print” which is deliberately left unspecified because it requires additional information depending on the type of printer • A subclass of an abstract class may itself be still abstract CS 446/546 45
Uses of abstract class • Intended to define general characteristics of an object in an abstract class with some behaviors deliberately left undefined make the class abstract • Another class (may be more than one) specializes the abstract class and complete the undefined behavior • Basic idea is to capture more general properties separately in an abstract class CS 446/546 46
Abstract Class - examples • One-level refinement – Printer is an abstract class which includes a behavior called “print” but does not define the behavior • Deliberately left undefined because we do not know the type of the printer – Postscript printer is a concrete class which specializes Printer and completes the behavior “print” CS 446/546 47
Abstract class – Examples (continued) • One-level refinement (continued – Inkjet printer is another concrete class which specializes Printer and completes the behavior “print” in a different way – Postscript printer 600 may be another concrete class which specializes Postscript printer, but both are concrete classes CS 446/546 48
Abstract class – examples (Continued) • Two-level refinement – Polygon is an abstract class which includes two incomplete behaviors “area” and “number of sides” – 4 -sided figure is an abstract class which specializes Polygon and completes the definition of the behavior “number of sides”, but the behavior “area” is still left incomplete and so this class is still abstract – Rectangle is a concrete class which specializes 4 sided figure and completes the definition of the behavior “area” – Square is another concrete class which specializes Rectangle but redefines the behavior “area” CS 446/546 49
Metaclass • Class whose instantiations are class definitions • High level concept; not used by end users • UML uses the concept of meta classes to define the semantics of other entities in UML notation – Refer to UML manual from OMG • Meta class concept is supported by Smalltalk, CLOS CS 446/546 50
Inheritance • A mechanism to implement (normally) a specialization relationship – Specialization is a concept, whereas inheritance is a mechanism – Analogous to encapsulation and information hiding • A distinguishing feature of object-oriented programming • Subclass inherits features (structure and behavior) of superclass – interface or internal or both? ? • Traditionally viewed as a code reuse mechanism in AI and non-OO applications CS 446/546 51
Inheritance- examples • HDTV inherits features of TV – Mechanism: adds more features • High Definition Signal receiver is included • Student president inherits Student – mechanism: adds more features • adds additional responsibilities • Square inherits Rectangle – mechanism : redefines perimeter and area • restricts the length and breadth to be the same CS 446/546 52
Three types of Inheritance • Inheritance by expansion – Subclass adds more features in addition to the features that are inherited from the superclass • Internship student inherits Student and adds employment details -- structural expansion • Student President inherits Student and adds administrative duties -- behavioral expansion CS 446/546 53
Three types of Inheritance (continued) • Inheritance by restriction – Subclass restricts some of the features that are inherited from the superclass – Subclass does not want its objects to use these restricted features • A “special non-degree” student is a specialization of student, but the former restricts the behavior “get. Program()” because the “special non-degree” student is not associated with any program • A “fixed-deposit” account is a specialization of account but the former restricts the behavior “withdraw” CS 446/546 54
Three types of Inheritance (continued) • Inheritance by redefinition – Subclass may redefine or more features that are inherited from the superclass • CS department inherits Department and may redefine the behavior “admission requirements” • Square inherits Polygon and redefines the behavior “area” – Structural redefinition is generally not permitted in OO programming languages since the redefinition may not be meaningful CS 446/546 55
Polymorphism • Generally implementation-oriented, but still can be considered at the design level • “Ability to exist in more than one form” - Oxford Dictionary • Advantage in OO design/programming – able to use one class/object/method in multiple contexts CS 446/546 56
Types of Polymorphism • Universal polymorphism – Parametric polymorphism • Provided by parametric classes • When parametric classes are instantiated, they exist in different forms – Examples • CS-Course[546], CS-Course[341] • Sony[TV] and Sony[DVD] CS 446/546 57
Polymorphism (continued) • Universal polymorphism (continued) – Inclusion polymorphism • Supported by inheritance • Subclass objects substituted for superclass objects • A subclass object when substituted for a superclass object behaves identically as a superclass object CS 446/546 58
Polymorphism (continued) • Inclusion polymorphism examples – A Flat panel TV can be substituted for a TV – A student seminar can be substituted for a seminar – A Student President object can be substituted for an object of Student – A CS faculty member object can be substituted for a University faculty member object CS 446/546 59
Polymorphism (continued) – Inclusion polymorphism (continued) • Valid only for inheritance by expansion • If inheritance by restriction or inheritance by redefinition is used, the subclass object WILL NOT BEHAVE identically as expected for the superclass object • One exception for the condition on inheritance is the use of abstract classes • Abstract classes cannot be instantiated; only subclass objects can support when abstract class needs to be instantiated; redefinition is mandatory in this context, but still exhibits inclusion polymorphism CS 446/546 60
Polymorphism (continued) • Ad hoc polymorphism – Exists at the level of behavior definitions • More than one definition for the same behavior • “sort” can be used to sort elements of different types • More than one constructors in Java and C++ – Mostly a feature of OO programming – Redefining an operator definition (also called operator overloading) CS 446/546 61
Скачать презентацию Object-Oriented Software Life Cycle SOLID principles
42eb88ddd054ae09c008aaaf9c9f6902.ppt