1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.

1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e Supplementary Slides for Software Engineering: A Practitioner's Approach, 5/e copyright © 1996, 2001 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 20 Object-Oriented Concepts and Principles

3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The OO Process Model

4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 The OO Mindset problem domain objects

5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Key Concepts classes and class hierarchiesclasses and class hierarchies –instances –inheritance –abstraction and hiding objectsobjects –attributes –methods –encapsulation –polymorphism messagesmessages

6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Classes object-oriented thinking begins with the definition of a class often defined as:object-oriented thinking begins with the definition of a class often defined as: – template – generalized description – pattern – “blueprint”... describing a collection of similar items a metaclass (also called a superclass) is a collection of classesa metaclass (also called a superclass) is a collection of classes once a class of items is defined, a specific instance of the class can be definedonce a class of items is defined, a specific instance of the class can be defined

7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Building a Class

8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 What is a Class? external entities things occurrences roles organizational units places structures class name attributes: operations:

9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Encapsulation/Hiding The object encapsulates both data and the logical procedures required to manipulate the data Achieves “information hiding” method # 1 data method # 2 method # 4 method # 5 method # 6

10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class Hierarchy chair table desk"chable" instances of chair furniture (superclass) subclasses of the furniture superclass

11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Methods (a.k.a. Operations, Services) An executable procedure that is encapsulated in a class and is designed to operate on one or more data attributes that are defined as part of the class. A method is invoked via message passing.

12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Messages

14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 21 Object-Oriented Analysis

15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Domain Analysis DOMAIN ANALYSIS SOURCES OF DOMAIN KNOWLEDGE DOMAIN ANALYSIS MODEL techncial literature existing applications customer surveys expert advice current/future requirements class taxononmies reuse standards functional models domain languages

16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOA- A Generic View define use cases extract candidate classes establish basic class relationships define a class hierarchy identify attributes for each class specify methods that service the attributes indicate how classes/objects are related build a behavioral model iterate on the first five steps

17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Use Cases  a scenario that describes a “thread of usage” for a system  actors represent roles people or devices play as the system functions  users can play a number of different roles for a given scenario

18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Developing a Use Case  What are the main tasks or functions that are performed by the actor?  What system information will the the actor acquire, produce or change?  Will the actor have to inform the system about changes in the external environment?  What information does the actor desire from the system?  Does the actor wish to be informed about unexpected changes?

19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Selecting Classes—Criteria needed services multiple attributes common attributes common operations essential requirements retained information

20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Unified Modeling Language (UML) User model view. This view represents the system (product) from the user’s (called “actors” in UML) perspective. Structural model view. Data and functionality is viewed from inside the system. That is, static structure (classes, objects, and relationships) is modeled. Behavioral model view. This part of the analysis model represents the dynamic or behavioral aspects of the system. Implementation model view. The structural and behavioral aspects of the system are represented as they are to be built. Environment model view. The structural and behavioral aspects of the environment in which the system is to be implemented are represented.

21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 UML: Use-Case Diagram

22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 CRC Modeling

23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Guidelines for Allocating Responsibilities to Classes 1. System intelligence should be evenly distributed. 2. Each responsibility should be stated as generally as possible. 3. Information and the behavior that is related to it should reside within the same class. 4. Information about one thing should be localized with a single class, not distributed across multiple classes. 5. Responsibilities should be shared among related classes, when appropriate.

24 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Reviewing the CRC Model 1. All participants in the review (of the CRC model) are given a subset of the CRC model index cards. 2. All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. 3. The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes the token to the person holding the corresponding class index card. 4. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. 5. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards.

25 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 UML: Class Diagrams Generalization- specialization Composite aggregates

26 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 UML: Package Reference

27 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Relationships between Objects

28 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Object-Behavior Model 1. Evaluate all use-cases to fully understand the sequence of interaction within the system. 2. Identify events that drive the interaction sequence and understand how these events relate to specific objects. 3. Create an event trace [RUM91] for each use-case. 4. Build a state transition diagram for the system 5. Review the object-behavior model to verify accuracy and consistency

29 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 UML: State Transition

30 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 UML: Event Trace

32 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 22 Object-Oriented Design

33 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Object-Oriented Design

34 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOA and OOD

35 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOA and OOD

36 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design Issues  decomposability—the facility with which a design method helps the designer to decompose a large problem into subproblems that are easier to solve;  composability—the degree to which a design method ensures that program components (modules), once designed and built, can be reused to create other systems;  understandability—the ease with which a program component can be understood without reference to other information or other modules;  continuity—the ability to make small changes in a program and have these changes manifest themselves with corresponding changes in just one or a very few modules;  protection—a architectural characteristic that will reduce the propagation of side affects if an error does occur in a given module.

37 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Generic Components for OOD  Problem domain component—the subsystems that are responsible for implementing customer requirements directly;  Human interaction component —the subsystems that implement the user interface (this included reusable GUI subsystems);  Task Management Component—the subsystems that are responsible for controlling and coordinating concurrent tasks that may be packaged within a subsystem or among different subsystems;  Data management component—the subsystem that is responsible for the storage and retrieval of objects.

38 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Process Flow for OOD

39 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 System Design Process Partition the analysis model into subsystems. Partition the analysis model into subsystems. Identify concurrency that is dictated by the problem. Identify concurrency that is dictated by the problem. Allocate subsystems to processors and tasks. Allocate subsystems to processors and tasks. Develop a design for the user interface. Develop a design for the user interface. Choose a basic strategy for implementing data management. Choose a basic strategy for implementing data management. Identify global resources and the control mechanisms required to access them. Identify global resources and the control mechanisms required to access them. Design an appropriate control mechanism for the system, including task management. Design an appropriate control mechanism for the system, including task management. Consider how boundary conditions should be handled. Consider how boundary conditions should be handled. Review and consider trade-offs. Review and consider trade-offs.

40 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 System Design

41 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Subsystem Example

42 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Subsystem Design Criteria The subsystem should have a well-defined interface through which all communication with the rest of the system occurs. With the exception of a small number of “communication classes,” the classes within a subsystem should collaborate only with other classes within the subsystem. The number of subsystems should be kept small. A subsystem can be partitioned internally to help reduce complexity.

43 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Subsystem Collaboration Table

44 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Object Design  A protocol description establishes the interface of an object by defining each message that the object can receive and the related operation that the object performs  An implementation description shows implementation details for each operation implied by a message that is passed to an object.  information about the object's private part  internal details about the data structures that describe the object’s attributes  procedural details that describe operations

45 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design Patterns... you’ll find recurring patterns of classes and communicating objects in many object-oriented systems. These patterns solve specific design problems and make object-oriented design more flexible, elegant, and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them. Gamma and his colleagues [GAM95]

46 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Design Pattern Attributes  The design pattern name is an abstraction that conveys significant meaning about it applicability and intent.  The problem description indicates the environment and conditions that must exist to make the design pattern applicable.  The pattern characteristics indicate the attributes of the design that may be adjusted to enable the pattern to accommodate into a variety of problems.  The consequences associated with the use of a design pattern provide an indication of the ramifications of design decisions.

48 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 23 Object-Oriented Testing

49 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Object-Oriented Testing  begins by evaluating the correctness and consistency of the OOA and OOD models  testing strategy changes  the concept of the ‘unit’ broadens due to encapsulation  integration focuses on classes and their execution across a ‘thread’ or in the context of a usage scenario  validation uses conventional black box methods  test case design draws on conventional methods, but also encompasses special features

50 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Broadening the View of “Testing” It can be argued that the review of OO analysis and design models is especially useful because the same semantic constructs (e.g., classes, attributes, operations, messages) appear at the analysis, design, and code level. Therefore, a problem in the definition of class attributes that is uncovered during analysis will circumvent side effects that might occur if the problem were not discovered until design or code (or even the next iteration of analysis).

51 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Testing the CRC Model 1. Revisit the CRC model and the object-relationship model. 2. Inspect the description of each CRC index card to determine if a delegated responsibility is part of the collaborator’s definition. 3. Invert the connection to ensure that each collaborator that is asked for service is receiving requests from a reasonable source. 4. Using the inverted connections examined in step 3, determine whether other classes might be required or whether responsibilities are properly grouped among the classes. 5. Determine whether widely requested responsibilities might be combined into a single responsibility. 6. Steps 1 to 5 are applied iteratively to each class and through each evolution of the OOA model.

52 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT Strategy  class testing is the equivalent of unit testing  operations within the class are tested  the state behavior of the class is examined  integration applied three different strategies  thread-based testing—integrates the set of classes required to respond to one input or event  use-based testing—integrates the set of classes required to respond to one use case  cluster testing—integrates the set of classes required to demonstrate one collaboration

53 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT—Test Case Design Berard [BER93] proposes the following approach: 1.Each test case should be uniquely identified and should be explicitly associated with the class to be tested, 2.The purpose of the test should be stated, 3.A list of testing steps should be developed for each test and should contain [BER94]: a.a list of specified states for the object that is to be tested b.a list of messages and operations that will be exercised as a consequence of the test c.a list of exceptions that may occur as the object is tested d.a list of external conditions (i.e., changes in the environment external to the software that must exist in order to properly conduct the test) e.supplementary information that will aid in understanding or implementing the test.

54 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT Methods: Random Testing  Random testing  identify operations applicable to a class  define constraints on their use  identify a miminum test sequence  an operation sequence that defines the minimum life history of the class (object)  generate a variety of random (but valid) test sequences  exercise other (more complex) class instance life histories

55 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT Methods: Partition Testing  Partition Testing  reduces the number of test cases required to test a class in much the same way as equivalence partitioning for conventional software  state-based partitioning  categorize and test operations based on their ability to change the state of a class  attribute-based partitioning  categorize and test operations based on the attributes that they use  category-based partitioning  categorize and test operations based on the generic function each performs

56 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OOT Methods: Inter-Class Testing  Inter-class testing  For each client class, use the list of class operators to generate a series of random test sequences. The operators will send messages to other server classes.  For each message that is generated, determine the collaborator class and the corresponding operator in the server object.  For each operator in the server object (that has been invoked by messages sent from the client object), determine the messages that it transmits.  For each of the messages, determine the next level of operators that are invoked and incorporate these into the test sequence

58 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Chapter 24 Technical Metrics for Object-Oriented Systems

59 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Distinguishing Characteristics  Localization—the way in which information is concentrated in a program  Encapsulation—the packaging of data and processing  Information hiding—the way in which information about operational details is hidden by a secure interface  Inheritance—the manner in which the responsibilities of one class are propagated to another  Abstraction—the mechanism that allows a design to focus on essential details Berard [BER95] argues that the following characteristics require that special OO metrics be developed:

60 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class-Oriented Metrics  weighted methods per class  depth of the inheritance tree  number of children  coupling between object classes  response for a class  lack of cohesion in methods Proposed by Chidamber and Kemerer:

61 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class-Oriented Metrics  class size  number of operations overridden by a subclass  number of operations added by a subclass  specialization index Proposed by Lorenz and Kidd [LOR94]:

62 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Class-Oriented Metrics  Method inheritance factor  Coupling factor  Polymorphism factor The MOOD Metrics Suite

63 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Operation-Oriented Metrics  average operation size  operation complexity  average number of parameters per operation Proposed by Lorenz and Kidd [LOR94]:

64 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 Testability Metrics  encapsulation related  lack of cohesion in methods  percent public and protected  public access to data members  inheritance related  number of root classes  fan in  number of children and depth of inheritance tree Proposed by Binder [BIN94]:

65 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001 OO Project Metrics  number of scenario scripts  number of key classes  number of subsystems Proposed by Lorenz and Kidd [LOR94]:

1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.

Similar presentations

Presentation on theme: "1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.

Similar presentations

Presentation on theme: "1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by."— Presentation transcript:

Similar presentations

About project

Feedback