Topic 9Summer ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Topic 9 Partially based on lecture notes written by Sommerville, Frost, & Easterbrook. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited

Topic 9Summer Today’s Lecture l A brief introduction to Classes & Objects

Topic 9Summer Noun extraction for design Complements design by information hiding

Topic 9Summer Remember this? Invoice Processing System – Object Model This system can: Issue invoices to customers Receive payments Issue receipts for payments Issue reminders for unpaid invoices The dashed line means that one object uses the attributes or services of another object

Topic 9Summer Choosing classes & objects l At the conceptual level: an object is a set of responsibilities, including responsibility for itself (encapsulates functions and data) l At the specification level: an object is a set of methods (its interface), which can be invoked by itself or other objects l At the implementation level: an object is code (methods) and data (attributes) Object Oriented approach attempts to manage complexity in real-world problems

Topic 9Summer Objects l Have Public and Private sides l OOD –views the world as a system of cooperating collaboration agents.

Topic 9Summer Some Terminology l Encapsulation – bundling operations and data that are conceptually linked (like putting them in a capsule) l Information Hiding – Making the capsule opaque l Method – an action l Attribute – a variable/constant l Object – primitive programming element l Class – a generic specification for an arbitrary number of similar objects – (abstract, template)

Topic 9Summer An OOD Process l Find the classes in your system l Determine operations for each class l Determine how objects will need to collaborate with each other

Topic 9Summer Hints for Choosing Classes l How do I find classes, attributes and so on? Look at the requirements »classes often correspond to nouns »attributes often correspond to abstract nouns »operations often correspond to verbs

Topic 9Summer Determining Classes l Model physical objects (employees, invoices, printers, etc..) l If more than 1 word is used for the same concept choose the one that is most meaningful. l Be wary of adjectives – does it describe new behavior? l Model known interfaces l Model the values of attributes – but don’t model attributes e.g. Line and length – class or attribute

Topic 9Summer A class should... l represent a coherent concept Principle: Low Coupling, High Cohesion l have a small, well-defined set of responsibilities l be named with a singular noun that says what each each instance of the class is l have no more than operations

Topic 9Summer An Example FastData Inc. wants a subsystem to process office supply orders via the Web. The user will supply via a form their name, password, account number, and a list of supplies along with an indication of the quantities desired. The subsystem will validate the input, enter the order into a database, and generate a receipt with the order number, expected ship date, and the total cost of the order. If the validation step fails, the subsystem will generate an error message describing the cause of the failure

Topic 9Summer You may need to rewrite Make it concise. l “FastData, Inc. employees may order office supplies via the Internal Web and receive a receipt confirming the order. The order must include the user name, user password, account number, and the list of supplies. A receipt must be generated containing an order number, ship date, and total cost. If the order is valid, it must be entered into an order database. If the order is invalid, an error message must be generated.”

Topic 9Summer Formalize the Strategy l Identify the nouns of the description, which serve as the basis for identifying the subsystem’s classes. l Look for out-of-domain nouns (and throw them out!) l Look for abstract nouns (use these for attributes) l The remaining nouns are good candidates for classes!

Topic 9Summer Find the nouns l “FastData, Inc. employees may order office supplies via the Internal Web and receive a receipt confirming the order. The order must include the user name, user password, account number, and the list of supplies. A receipt must be generated containing an order number, ship date, and total cost. If the order is valid, it must be entered into an order database. If the order is invalid, an error message must be generated.”

Topic 9Summer Nouns –Employees –Office Supplies  Item –Internal Web –Receipt –Order –User name –User password – Account number – Order number – Ship date – Total cost – Order database – Error message – List of supplies

Topic 9Summer Nouns l Out-of-Domain Internal Web l Abstract user name user password account number order number ship date total cost list of supplies l Good Candidates employee item (was office supplies) receipt order order database error message l Notes We have decided not to worry about the Web in this design. Instead we focus on the inputs and outputs and defer the Web details until later.

Topic 9Summer Basic Classes Employee Name Password Account # Order Number Employee Item Error Message Item Order Ship Date Total cost Receipt Order Order Database l This gives us a starting place to refine and revise

Topic 9Summer Assigning Responsibilities l Responsibilities include 2 key items The knowledge an object maintains The actions an object can perform l An object is a client when it requests services from another object. l An object is a server when it fulfills a request from another object. l Where to look – Requirements Classes

Topic 9Summer Identifying Responsibilities l Look for the verbs Which ones clearly represent actions that some object must perform Note where information is mentioned »Information an object must maintain and manipulate l Look at they system as a whole (walkthrough) l Look at the classes

Topic 9Summer Assigning Responsibilities l Try to evenly distribute system intelligence l State responsibilities as generally as possible l Keep behavior with related information l Keep information about 1 thing in 1 place l Share responsibilities among related objects

Topic 9Summer What Operations go with which Class? Employee Name Password Account # Order Number Employee Item SendReceipt() SendErrorMsg() AddItem() Error Message Item Order Ship Date Total cost Receipt Order Order Database

Topic 9Summer Final Notes l Refine, Revise l Define relationships

Topic 9Summer Design Recap

Topic 9Summer Important concepts l Architectural styles l Information hiding l Noun extraction l Uses diagram l Comprises diagram

Topic 9Summer How do we decide if a design is the best possible design? l Ability to predict comes with experience l Qualities to look for: Verifiability, Maintainability, Repairability, Evolvability, Reusability, Portability, Understandability, Interoperability l Principles to maintain: Rigor & formality, Separation of concerns, Modularity, Abstraction, Anticipation of change, Generality

Topic 9Summer What is a Good Class? l …and what should not be a class? l A class should be named with a noun Example: “class Book” l A class should not represent a task or operation Don’t do this: “class FindABook” Don’t have classes described as “performing” something l A class should contain several related operations These correspond to the class’ responsibilities l A class should contain at least one attribute l A class should represent a single abstraction

Topic 9Summer Is fan-in, fan-out relevant? l Yes, but it’s not as important as other indications of a good design l High cohesion and low coupling are the most important l For smaller systems, the uses diagram is the next most important l For larger systems, the comprises diagram is also important

Topic 9Summer How does high level architecture affect module interaction? l Architectural styles restrict the way in which components can be connected Prescribe patterns of interaction Promote fundamental principles »Rigor, Separation of concerns, Modularity, Abstraction, Anticipation of change, Generality, Incrementality »Low coupling, High cohesion

Topic 9Summer Do we have to code up the modules? l Yes, but later.

Topic 9Summer Why do we define levels in the uses diagram? l The process of doing so helps identify cycles (which are usually bad) l The levels are used in making an integration test plan

Topic 9Summer How many levels should we have in a uses diagram? l It depends. l Small systems may only have 2 or 3 l Larger systems may have many more, or they may remain fairly “shallow”

Topic 9Summer Acceptance testing? l Acceptance testing is performed after implementation and integration testing is complete, before the product is given to the client l Acceptance test plans are made during the requirements phase l The acceptance test plan includes a high-level description of what is being tested, and specific test inputs, along with expected outputs.

Topic 9Summer Integration testing? l Integration testing is performed after implementation and module testing, before acceptance testing l The integration test plan is made during design l The integration test plan includes a plan of the order of integration and specific test cases.

Topic 9Summer Integration Testing

Topic 9Summer V-Model of Development and Testing Develop Acceptance Tests Acceptance Test ReviewRequirements Review Develop RequirementsExecute System TestsDevelop Integration Tests Integration Tests ReviewDesign Review DesignExecute Integration TestsDevelop Unit Tests Unit Tests ReviewCode Review CodeExecute Unit Tests

Topic 9Summer Integration Test Plans l Goal (Why?) Ensure modules make compatible assumptions about each other. Exercise interfaces between modules, as opposed to functionality within modules l Hard part: Identifying interactions that reveal agreement or disagreement on assumptions l Approach (How?) Combine more and more modules Use USES hierarchy »Work up from lowest numbers  Use test harnesses to test each group of modules »Work down from highest numbers  Use stubs as mockups to test each group of modules l Test execution can be done during implementation effort

Topic 9Summer Integration Test Example Provided Interface Main component Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface

Topic 9Summer Integration Testing Tools l Extra code you write for integration testing. Needed because not all modules are ready at the same time. l Harnesses or drivers Call or invoke modules and pass parameters to them l Stubs Are called by modules, do minimal processing, return reasonable values

Topic 9Summer Test Harnesses (bottom-up integration) Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Subcomponent Required Interface Provided Interface Test Harness Required Interface Provided Interface Test Harness Required Interface

Topic 9Summer Stubs (top-down integration) Provided Interface Main component Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface

Topic 9Summer Stubs Provided Interface Main component Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface Provided Interface Subcomponent Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface

Topic 9Summer Stubs Provided Interface Main component Required Interface Provided Interface Subcomponent Required Interface Provided Interface Stub Required Interface Provided Interface Subcomponent Required Interface Provided Interface Stub Required Interface Provided Interface Stub Required Interface

Topic 9Summer Integration Testing Strategies l Integrate and test increasingly larger subsets of modules l Top-down integration testing Can be done before units are fully coded Requires stubs l Bottom-up integration testing Requires test harnesses or drivers Can thoroughly test lower modules but postpones detection of major integration problems l Hybrid of both most common in practice