Chapter 6 Considering Objects ISBN 0 -13 -146913

Contents 6. 1 6. 2 6. 3 6. 4 6. 5 6. 6 6. 7 6. 8 6. 9 6. 10 What is OO? The OO Development Process Use Cases Representing OO: An Example Using UML OO System Design OO Program Design OO Measurement Information System Example Real Time Example What this Chapter Means for You Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 2

Chapter 6 Objectives • The special nature of object-oriented development • Use cases • Using UML • Object-oriented system design • Object-oriented program design • Object-oriented measurement Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 3

6. 1 What is OO? • Object-orientation is an approach to software development that organizes both the problem and its solution as a collection of discrete objects – Data structure – Behavior Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 4

6. 1 What is OO? Sidebar 6. 1 Royal Service Station Requirements • • • • Royal Service station provides three types of services The system must track bills, the product, and services System to control inventory The system to track credit history, and payments overdue The system applies only to regular repeat customers The system must handle the data requirements for interfacing with other systems The system must record tax and related information The station must be able to review tax record upon demand The system will send periodic message to customers Customers can rent parking space in the station parking lot The system maintains a repository of account information The station manager must be able to review accounting information upon demand The system can report an analysis of prices and discounts The system can not be unavailable for more than 24 hours The system must protect customer information from unauthorized access The system will automatically notify the owners of dormant accounts Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 5

6. 1 What is OO? Object-Orientation Characteristics • Identity • Abstraction • Classification • Encapsulation • Inheritance • Polymorphism • Persistence Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 6

6. 1 What is OO? Objects and Classes • Reference or handle: name of object • Objects can have – attributes (such as color, size, location) – operations or behaviors (such as takeoff, land, repair) • Each object is an instance of a class • Class: group of objects that have attributes and behaviors in common • Method: a specific implementation of an operation for a certain class Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 7

6. 1 What is OO? Objects and Classes (continued) • Examples of objects grouped

6. 1 What is OO? Objects and Classes (continued) • We can represent a class using a box • Box represents – object’s name – attributes – behaviors Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 9

6. 1 What is OO? Classes Hierarchy • A class hierarchy is organized according to the sameness or differences among classes – Exhibits OO classes’ inheritance structure • A class is refined into subclasses • Subclasses may inherit the structure as well as the behavior and attributes of its superclass • Abstract class is used to simplify the hierarchy – No objects of the abstract class may be defined except as instances of a subclass Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 10

6. 1 What is OO? Classes Hierarchy (continued) • Example of forming a hierarchy

6. 2 The OO Development Process • One advantage of OO development is its consistency of language • Describing classes using OO representation requires three perspectives – Static views: descriptions of the object, attributes, behaviors, and relationships – Dynamic views: describe communication, control/timing, and the state and changes in state – Restrictions: describe constraints on the structure Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 12

6. 2 The OO Development Process Tendency of Change when Using OO Paradigm Characteristic of Software Product/Project Objects derived from application Long-lived information structures Passive object’s attributes Sequences of behavior Interface with outside world Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Probability for Change Low Medium High Page 6. 13

6. 2 The OO Development Process OO Requirements • Usually done in user’s language and discusses the concepts and scenarios likely in the application domain • The concepts include information services and responsibilities • Domain knowledge enables the developers – to understand the context in which the system will be used – to describe the requirements in a way that the user will understand Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 14

6. 2 The OO Development Process OO Design • Usually uses an OO requirements representation • System design identifies and represents objects and classes, plus details of each object’s attributes and behaviors • System design also identifies interactions and relationships • Program design inserts computational features in the models • Program design inserts class library details • Program design considers nonfunctional requirements to enhance design Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 15

6. 2 The OO Development Process OO Coding and Testing • Coding proceeds by translating the models to an OO programming language • It is necessary to refine the hierarchical structures and make adjustments as the requirements grow and mature • Testing involves some of the same activities that are performed when testing any kind of system Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 16

6. 2 The OO Development Process OO Coding and Testing (continued) • Graphical representation of how the abstraction level relates to various types of tests that are performed Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 17

6. 3 Use Cases • Describes particular functionality that a system is supposed to perform or exhibit by modeling the dialog that a user, external system, or other entity will have with the system to be developed • Diagrams have four elements – – actors cases extensions uses Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 18

6. 3 Use Cases Example of Use Cases • High-level view of Royal Service

6. 3 Use Cases Example of Use Cases (continued) • First extension part of the use case diagram of Royal Service Station requirements to include preventive maintenance Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 20

6. 3 Use Cases Example of Use Cases (continued) • Second extension of Royal Service Station diagram to include credit card system Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 21

6. 3 Use Cases Example of Use Cases (continued) • Third extension of Royal Service Station diagram to include inventory and accounting Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 22

6. 3 Use Cases Identifying Participants • What users or groups use the system to perform a task? • What users or groups are needed so that the system can perform its functions? • What external systems use the system to perform a task? • What external systems, users, or groups send information to the system? • What external systems, users, or groups receive information from the system? Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 23

6. 4 Representing OO: An Example Using UML in the OO Process • Workflow diagrams • Object model • Sequence diagrams • Collaboration diagrams • Package diagrams • Component diagrams • Deployment diagrams Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 24

6. 4 Representing OO: An Example Using UML in the OO Process (continued) • How UML can be used in requirements specification, design, and coding Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 25

6. 5 OO System Design First Cut at Object Classes • Structures • External systems • Devices • Roles • Operating procedures • Places • Organizations • Things that are manipulated by the system to be built Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 26

6. 5 OO System Design Guidelines for Building Classes • What needs to be “processed” in some way? • What items have multiple attributes? • When do you have more than one object in a class? • What is based on the requirements themselves, not derived from your understanding of the requirements? • What attributes and operations are always applicable to a class or object? Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 27

6. 5 OO System Design First Grouping of Attributes and Classes: Step 1 Attributes personal check tax price cash credit card discount Classes customer maintenance services parking fuel bill purchase Pfleeger and Atlee, Software Engineering: Theory and Practice Page 6. 28 station manager © 2006 Pearson/Prentice Hall

6. 5 OO System Design First Grouping of Attributes and Classes: Step 2 Attributes Classes personal check customer tax maintenance price services cash parking credit card fuel discount bill birthdate purchase Pfleeger and Atlee, Software Engineering: Theory and Practice Page 6. 29 name periodic message © 2006 Pearson/Prentice Hall

6. 5 OO System Design First Grouping of Attributes and Classes: Step 3 Attributes Classes personal check tax price cash credit card discount birthdate name address customer maintenance services parking fuel bill purchase periodic message station manager warning letter parts accounts inventory credit card system part-ordering system fuel-ordering system Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 30

6. 5 OO System Design Guidelines for Identifying Behaviors • Imperative verbs • Passive verbs • Actions • Things or reminded events • Roles • Operating procedures • Services provided by an organization Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 31

6. 5 OO System Design UML Diagram • A UML box used to illustrate

6. 5 OO System Design UML Diagram to Describe Relationship • Inheritance relationship (is-a relationship): lower box inherits the attributes and behaviors of the upper box Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 33

6. 5 OO System Design UML Diagram to Describe Relationship (continued) • Each order is associated with salesperson (associated) • The order item is part of the order (aggregation) Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 34

6. 5 OO System Design UML Diagram to Describe Relationship (continued) • Graphical representation of several other ways of denoting relationships between classes Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 35

6. 5 OO System Design UML Notation for Notes and Qualifiers • The picture shows how class association can be enhanced with notes and qualifiers Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 36

6. 5 OO System Design First Cut at Royal Service Station Design Pfleeger and

6. 5 OO System Design Second Cut at Royal Service Station Design Pfleeger and

6. 5 OO System Design Third and Final Cut at Royal Service Station Design

6. 5 OO System Design A Class Description Template • Describes class in more detail • Tells us – the position of the class (in terms of inheritance) in the overall hierarchy – the export controls – the cardinality – association with other classes • Specifies the operations in the class and the public interface to the class Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 40

6. 5 OO System Design Example of a Class Description Template Class name: refuel Category: service External documents: Export control: Public Cardinality: n Hierarchy: Superclasses: services Associations: fuel in association <name> Operation name: price Public member of: refuel Documentation: // Calculates fuel final price Preconditions: gallons > 0 Object diagram: (unspecified) Semantics: final_price = gallons * price Object diagram: (unspecified) Concurrency: sequential Public interface: Operations: price Private interface: Attributes: gallons price Implementation: Attributes: gallons price State machine: no Concurrency: sequential Persistence: transient Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 41

6. 5 OO System Design Package Diagram • View the system as a small collection of packages, which can be expanded to a larger set of classes • Show the dependencies among classes as they belong to different packages • Two items are dependent if changes to the definition of one may cause changes to the other Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 42

6. 5 OO System Design Package Diagram for the Royal Service Station • There are four major packages • The service package consists of five key classes Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 43

6. 5 OO System Design Interaction Diagram • Describe how operations and behaviors are handled by the objects in the design • Two kinds of interaction diagrams – Sequence diagram: shows the sequence in which activities or behaviors occur – Collaboration diagram: shows how the objects are connected statically Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 44

6. 5 OO System Design Sequence Diagram for the Royal Service Station • Showing the use case of the refuel class Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 45

6. 5 OO System Design Collaboration Diagram for the Royal Service Station • Shows the parking use case Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 46

6. 5 OO System Design State Diagram • To document a dynamic model of the system • Shows – the possible states an object can take – the events that trigger the transition from one state to the next – the actions that result from each state change • Needed only for classes where the objects exhibit dynamic behavior, with many attribute values and messages Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 47

6. 5 OO System Design State Diagram Example • Black dot: start node • Smaller black dot inside a white dot: end node • Rectangle: a state • Arrow: transition Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 48

6. 5 OO System Design State Diagram for the Royal Service Station System • State diagrams for the fuel and parts classes Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 49

6. 5 OO System Design State Diagram for the Royal Service Station System • State diagram for the inventory class, orders parts or fuel: a different condition triggers each state Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 50

6. 5 OO System Design Activity Diagram • To model the flow of procedures or activities in a class • A decision node is used to represent a choice of which activity to invoke Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 51

6. 5 OO System Design Activity Diagram for the Royal Service Station • An activity diagram for the inventory class • It may have two decisions – to verify that there is enough fuel – to verify that a part is in stock Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 52

6. 6 OO Program Design • Begins with the objects and classes from the system design • During program design – Make more detailed decisions about the data structures – Specify the features of each object’s interface – Need to know the operation signature • name each operation • the objects it takes as parameters • The values returned by the operation • An object’s interface: the collection of all its operation’s signature Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 53

6. 6 OO Program Design Considerations • Nonfunctional requirements • Reused components • Reusable components • User interface requirements • Data structure and management details Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 54

6. 6 OO Program Design Construction Paradigms • White-box reuse: one class inherits properties from another class – Gives us a static view of the system at compile time – Modification is easier and more straightforward – The inheritance can not easily be changed at runtime • Black-box reuse: built up from component classes – Enforces the encapsulation built into the system design – Allows easy replacement of one component with other – Not always clear which objects reference to other objects Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 55

6. 6 OO Program Design Aids • A toolkit: a set of related, reusable classes • A pattern: a template of abstract architectural elements – Context: explains the situations in which pattern would be appropriate – Forces: elements of the context • A framework: a reuse part of a domainspecific design Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 56

6. 6 OO Program Design Sidebar 6. 2 Approaches to Creating Patterns • Abstract factory • Builder • Factory method • Prototype • Singleton Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 57

6. 6 OO Program Design User Interface Design • Defining the humans who will interact with the system • Developing scenarios for each way that the system can perform a task • Designing hierarchy of user commands • Refining sequence of user interactions with the system • Designing relevant classes in the hierarchy to implement the user interface design decision • Integrating the user interface classes in the overall system class hierarchy Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 58

6. 6 OO Program Design User Interface Design (continued) • The first step in user interface design is to lay out the interaction on paper • The left-hand side of the picture shows the paper bill, the right -hand side shows a screen of automated billing process Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 59

6. 6 OO Program Design User Interface Design Example • Possible design for new billing screen of the Royal Service Station system Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 60

6. 6 OO Program Design Data Management Design • Four steps – Identify the data, data structure, and relationships among them – Design services to manage the data structures and relationships – Find tools, such as database management systems, to implement some of the data management tasks – Design classes and class hierarchies to oversee the data management functions • An OO solution can use conventional files or relational databases, but it interfaces most easily with OO databases Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 61

6. 6 OO Program Design Data Management Design: Using a Relational Database • Database to track vehicle maintenance and parts Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 62

6. 6 OO Program Design Task Management Design • A task: a process in the system – Event-driven task: initiated when a particular event occurs – Time-driven task: invoked at a particular time • Four steps – – Identify the task to be performed Determine priorities for the tasks Create a task to coordinate all other tasks Design objects for each task, and define the relationships among them Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 63

6. 6 OO Program Design Task Management Design: A Task Definition Example Task name: order parts Description: Purpose is to order new parts automatically when there are not enough parts already in stock Priority: High. It must be activated when the inventory warns the parts in stock are low Included services: Verify inventory Managed by/Manager: Service Station System Communicates by: modem with the order_parts system Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 64

6. 6 OO Program Design Sidebar 6. 3 Gamma et. al’s Pattern for Task Management • • • Chain of responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 65

6. 6 OO Program Design Task Management Design: The Observer Pattern • Useful when an abstraction has at least two aspects, and some are dependent on the others – One-to-many dependency • Involves four major constructs – – Subject Observer Concrete subject Concrete observer Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 66

6. 6 OO Program Design The Observer Pattern (continued) • Graphical representation of relationship among observer pattern constructs Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 67

6. 6 OO Program Design The Observer Pattern (continued) • Sequence diagram to show the four constructs interact Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 68

6. 7 OO Measurement OO Size Measure • Pfleeger (1991): used objects and methods as a basic size measure • Lorenz and Kidd’s nine aspects of size – – – – – Number of scenario script (NSS) Number of key classes Number of support classes The average number of support classes per key classes Number of subsystems Class size Number of operations overridden by a subclass (NOO) Number of operations added by a subclass Specialization index • SI = (NOO X level) / (total class methods) Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 69

6. 7 OO Measurement Lorenz and Kidd Metrics Collection in Different Phases of Development Metric Requirements Description Number of scenario script X Program Design Coding Testing X Number of key classes System Design X Number of support classes X Average number of support classes per key class X Number of subsystem X X Class size X X X Number of operations overridden by a subclass X X X Number of operations added by a subclass X X X Specialization index X X X Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall X X Page 6. 70

6. 7 OO Measurement OO Size Measure of the Royal Service Station • Using Lorenz and Kidd’s metrics, the number of scenario scripts is equal to six Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 71

6. 7 OO Measurement Class Hierarchy for the Royal Service Station, plus Lorenz and

6. 7 OO Measurement OO Design Measures • Chidamber and Kemerer have also devised a suite of metrics for object-oriented development n – Weighted methods per class = S ci i=1 – – – Depth of inheritance Number of children Coupling between objects Response for a class Lack of cohesion of methods Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 73

6. 7 OO Measurement Chidamber and Kemerer Metrics Collection in Different Phases of Development System Design Program Design Weighted methods per class X X X Depth of inheritance X X X Number of children X X X Coupling between objects X X Response for a class X X Lack of cohesion of methods X X Metric Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Coding Testing X Page 6. 74

6. 7 OO Measurement Chidamber-Kemerer Metrics Applied to the Royal Service Station’s System Design

6. 7 OO Measurement Calculating the Lack of Cohesion • Given class C with n methods, M 1 through Mn • Suppose {Ijj} is the set of instance variables used by the method M • We can define P to be collection of pairs (Ir , Is) where Ir and Is, share no common members – P = {(Ir , Is) | Ir ∩ Is = Ø} • Q is the collection of pairs (Ir , Is) where Ir and Is, share at least one common member – Q = {(Ir , Is) | Ir ∩ Is ≠ Ø} • Lack of cohesion in methods for C to be – |P|-|Q| if |P| > |Q| – Zero if otherwise Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 76

6. 7 OO Measurement Chidamber-Kemerer Metrics applied to the Royal Service Station’s Program Design Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 77

6. 7 OO Measurement Other Metrics • Li and Henry (1993): metrics to predict the size of changes in classes during maintenance – Message-passing coupling – Data abstraction coupling • Travassos (1999) – The average operation size – The average number of parameters per operation Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 78

6. 7 OO Measurement Travassos Metrics Applied to the Royal Service Station’s Sequence Diagram

6. 7 OO Measurement Where to Do OO Measurement Class Metric Use cases diagram Number of scenario scripts X Number of key classes X Number of support classes X Average number of support classes per key X class Number of subsystems Class size X Number of operation overridden by a subclass X Number of operation added by a subclass X Specialization index X Weighted methods in class X Depth of inheritance X Number of children X Coupling between objects X Response for a class Lack of cohesion in methods Average operation size Average number of parameters per operation Operation complexity Percent public and protected Public access to data members Number of root classes X Fan-in/fan-out X Interaction Class State diagram description diagram Package diagram X X X Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall X X X Page 6. 80

6. 8 Information System Example Data Flow Diagram as Basis for Use Cases for

6. 8 Information System Example Class Diagram for the Advertising Campaign • First cut at two classes to deal with ratings prediction Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 82

6. 9 Real-Time Example • Had Ariane-5 been implemented using an object-oriented approach, the reuse would have been either in terms of composition or inheritance • In composition approach: the SRI is viewed as a black box and called from the main system • In inheritance approach: the SRI structure and behavior are open to view, inheriting as much structure and behavior from parent classes as possible Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 83

6. 10 What This Chapter Means for You • Use cases are embellished to generate a system design, painting a high-level portrait of how the system will solve problem at hand • Program design implements nonfunctional requirements • UML is becoming a de facto standard way of describing OO system • There are several metrics that are commonly used to measure size and characteristic of OO artifacts Pfleeger and Atlee, Software Engineering: Theory and Practice © 2006 Pearson/Prentice Hall Page 6. 84