1. Lecture 6 Requirement analysis Functional Modeling Object Modeling Dynamical Modeling Non-functional requirements Slides adopted from the book and lecture material for the “Object oriented software engineering” by Bruegge & Dutroit

2. SW Development Process Requirement analysis Describes what the system is supposed to do. System Analysis Identifies the structure of the system. Design Describes how the system is realized. Implementation Implements the system and performs unit testing Testing Verifies system

3. Requirement Analysis: Overview Three types of modeling Functional modeling Object modeling Dynamic modeling Functional Modeling: What are the transformations? Create scenarios and use case diagrams Talk to client, observe, get historical records, do thought experiments

4. Requirement Analysis: Overview Object Modeling: What is the structure of the system? Create class diagrams Identify objects. What are the associations between them? What is their multiplicity? What are the attributes of the objects? What operations are defined on the objects? Dynamic Modeling: What is its control structure? Create sequence diagrams Identify senders and receivers Show sequence of events exchanged between objects. Identify event dependencies and event concurrency. Create state diagrams Only for the dynamically interesting objects.

5. How to do Analysis Analyze the problem statement Identify functional requirements Identify non-functional requirements Identify constraints (pseudo requirements) Build the functional model: Develop use cases to illustrate functionality requirements Build the dynamic model: Develop sequence diagrams to illustrate the interaction between objects Develop state diagrams for objects with interesting behavior Build the object model: Develop class diagrams showing the structure of the system

6. Power is turned on Car moves forward and car headlight shines Power is turned off Car stops and headlight goes out. Power is turned on Headlight shines Power is turned off Headlight goes out. Power is turned on Car runs backward with its headlight shining. Power is turned on Car moves forward and car headlight shines Power is turned off Car stops and headlight goes out. Power is turned on Headlight shines Power is turned off Headlight goes out. Power is turned on Car runs backward with its headlight shining. Problem Statement: Direction Control for a Toy Car Power is turned off Car stops and headlight goes out. Power is turned on Headlight shines Power is turned off Headlight goes out. Power is turned on Car runs forward with its headlight shining. Power is turned off Car stops and headlight goes out. Power is turned on Headlight shines Power is turned off Headlight goes out. Power is turned on Car runs forward with its headlight shining.

7. Find the Functional Model: Do Use Case Modeling Use case 1: System Initialization Entry condition: Power is off, car is not moving Flow of events: Driver turns power on Exit condition: Car moves forward, headlight is on Use case 2: Turn headlight off Entry condition: Car moves forward with headlights on Flow of events: Driver turns power off, car stops and headlight goes out. Driver turns power on, headlight shines and car does not move. Driver turns power off, headlight goes out Exit condition: Car does not move, headlight is out

8. Use Cases continued Use case 3: Move car backward Entry condition: Car is stationary, headlights off Flow of events: Driver turns power on Exit condition: Car moves backward, headlight on Use case 4: Stop backward moving car Entry condition: Car moves backward, headlights on Flow of events: Driver turns power off, car stops, headlight goes out. Power is turned on, headlight shines and car does not move. Power is turned off, headlight goes out. Exit condition: Car does not move, headlight is out.

9. Use cases continued Use case 5: Move car forward Entry condition: Car does not move, headlight is out Flow of events Driver turns power on Exit condition: Car runs forward with its headlight shining.

10. Use Case Pruning Do we need use case 5? Use case 1: System Initialization Entry condition: Power is off, car is not moving Flow of events: Driver turns power on Exit condition: Car moves forward, headlight is on Use case 5: Move car forward Entry condition: Car does not move, headlight is out Flow of events Driver turns power on Exit condition: Car runs forward with its headlight shining.

11. Find the Dynamic Model: Create sequence diagram Name: Drive Car Sequence of events: Billy turns power on Headlight goes on Wheels starts moving forward Wheels keeps moving forward Billy turns power off Headlight goes off Wheels stops moving...

12. Sequence Diagram for Drive Car Scenario Power(on) :HeadlightBilly:Driver :Wheel Power(off) Power(on) Power(off) Power(on)

13. Toy Car: Dynamic Model State-Chart Diagram Wheel Forward Backward Stationary power on power off power off power on Headlight power on power off Off On

14. Toy Car: Object Model Wheel Motion:( Forward Backward, Stationary) Start_Moving() Stop_Moving() Headlight Status: (On, Off) Switch_On() Switch_Off() Power Status: (On, Off) TurnOn() TurnOff() Car

15. For which system is a particular model most relevant? Object model: The system has non-trivial data structures. Dynamic model: The model has many different types of events: Input, output, exceptions, errors, etc. Functional model: The model performs complicated transformations such as difficult computations consisting of many steps.

16. For which system is a particular model most relevant? Examples: Compiler: Functional model most important. Dynamic model is trivial because there is only one type input and only a few outputs. Database systems: Object model most important. Functional model is trivial, because their purpose is usually only to store, organize and retrieve data. Spreadsheet program: Functional model most important. Object model is trivial, because the spreadsheet values are trivial and cannot be structured further. The only interesting object is the cell.

17. Why Scenarios and Use Cases? Comprehensible by the user Use cases model a system from the users’ point of view (functional requirements) Define every possible event flow through the system Description of interaction between objects Use cases can form basis for whole development process User manual System design and object design Implementation Test specification Client acceptance test

18. Identifying Use Cases Engage in a dialog, use an evolutionary, incremental approach You help the client to formulate the requirements The client helps you to understand the requirements The requirements evolve while the use cases are being developed

19. How to Specify a Use Case Name of Use Case Actors Description of actors involved in use case Precondition Use a phrase such as “This use case starts when…” Flow of Events Free form, informal natural language Exceptions Describe what happens if things go wrong Special Requirements List nonfunctional requirements and constraints

20. From Use Cases to Requirement Analysis Model Both focus on the requirements from the user point of view. Use cases use natural language (derived from problem statement) Written scenarios Requirements analysis model uses formal or semi-formal notation (UML) System sequence diagrams Domain model

21. Identify Conceptual Classes Candidate classes are possible class names that are being considered as candidates for inclusion in the system. Techniques: noun phrase identification from use case model or documentation Brainstorming CRC cards Design patterns

22. Noun Phrase Identification Read and understand the use case scenarios. Look for noun phrases, mark the nouns Divide into three categories Definite object Possible object Nonsense object Discuss “possible objects” and assign them to either of the two other categories

23. Example Computer system for library: Books and Journals: The library contains books and journals. There can be multiple copies a particular book. Books can be borrowed by a library user for a period of six weeks. Loans: The system needs to keep track of which books are on loan and when they are due. Possible candidates for conceptual classes: library, system, book, journal, copy, user, period, week, loan Nonsense objects: week, system Possible objects: library, period Definite objects: book, journal, copy, loan, user

24. Definition: Object Modeling Main goal: Find the important abstractions Steps during object modeling 1. Class identification Based on the fundamental assumption that we can find abstractions 2. Find the attributes 3. Find the methods 4. Find the associations between classes Order of steps Goal: get the desired abstractions Order of steps secondary, only a heuristic Iteration is important

25. Class Identification Identify the boundaries of the system Identify the important entities in the system Class identification is crucial to object- oriented modeling Basic assumption: 1. We can find the classes for a new software system (Forward Engineering) 2. We can identify the classes in an existing system (Reverse Engineering)

26. Class Identification Objects are not just found by taking a picture of a scene or domain The application domain has to be analyzed. Depending on the purpose of the system different objects might be found How can we identify the purpose of a system? Scenarios and use cases Another important problem: Define system boundary. What object is inside, what object is outside?

27. Pieces of an Object Model Classes Associations (Relations) Part of- Hierarchy (Aggregation) Kind of-Hierarchy (Generalization) Attributes Detection of attributes Is something an attribute or a class (e.g. money) Methods Detection of methods Generic methods: General world knowledge, design patterns Domain Methods: Dynamic model, Functional model

28. Object vs Class Object (instance): Exactly one thing The lecture on Wednesday 19/9 from 8-10 on Analysis A class describes a group of objects with similar properties Sale, Customer, Item, Lecture… Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations"): Class diagram: Template for describing many instances of data. Useful for taxonomies, patters, schemata... Instance diagram: A particular set of objects relating to each other. Useful for discussing scenarios, test cases and examples

29. Class and Instance Diagrams Inspector joe: Inspector mary: Inspector anonymous: Inspector Class Diagram Instance Diagram

30. Attributes and Values name:string age: integer Inspector name = “Joe” age = 24 joe:Inspector name = “Mary” age = 18 mary: Inspector

31. Links and Associations Links and associations establish relationships among objects and classes. Link: A connection between two object instances. A link is like a tuple. A link is an instance of an association Association: Basically a bidirectional mapping. One-to-one, many-to-one, one-to-many, An association describes a set of links like a class describes a set of objects.

32. 1-to-1 and 1-to-N Associations has-capital 1-1 association 1-N association City name Order Item price productID * Country name date contains

33. Object Instance Diagram Example for 1-to-N :Item Price:9,90 ItemID : 105 :Order :Item Price:105,00 ItemID : 98 :Item Price:5,50 ItemID : 23

34. Many-to-Many Associations places ** CustomerOrder

35. Aggregation Models "part of" hierarchy Useful for modeling the breakdown of a product into its component parts UML notation: Like an association but with a small diamond indicating the assembly end of the relationship.

36. weight Automobile serial number year manufacturer model color drive purchase Aggregation Engine horsepower volume on off 3,4,5 Wheel diameter number of bolts 2,4 Door open close Battery amps volts charge discharge * Brakelight on off

37. Inheritance Models "kind of" hierarchy Powerful notation for sharing similarities among classes while preserving their differences UML Notation: An arrow with a triangle Cell MuscleCellBloodCellNerveCell StriateSmoothRedWhitePyramidalCortical

38. Aggregation vs Inheritance Both associations describe trees (hierarchies) Aggregation tree describes “a-part-of “relationships (also called and-relationship) Inheritance tree describes "kind-of" relationships (also called or-relationship) Aggregation relates instances (involves two or more different objects) Inheritance relates classes (a way to structure the description of a single object)

39. Other Associations Uses: An object uses another object : Player moves Token Contains: Sometimes called “spatial aggregation”... contains... Example: an order contains items Parent/child relationship:... is father of...... is mother of... Seniority:... is older than...... is more experienced than...

40. Requirement Analysis Challenging activity Requires collaboration of people with different backgrounds User with application domain knowledge Developer with implementation domain knowledge Bridging the gap between user and developer: Scenarios: Example of the use of the system in terms of a series of interactions with between the user and the system Use cases: Abstraction that describes a class of scenarios

41. System Model Scenarios - As-is scenarios, visionary scenarios Use case model - Actors and use cases Object model - Data dictionary - Class diagrams (classes, associations, attributes and behaviors) Dynamic model - State diagrams for classes with significant dynamic behavior - Sequence diagrams for collaborating objects (protocol)

42. System Identification Development of a system is not just done by taking a snapshot of a scene (domain) Definition of the system boundary What is inside, what is outside? How can we identify the purpose of a system? Requirement Process: Requirements Elicitation: Definition of the system in terms understood by the customer (use cases) Analysis: Technical specification of the system in terms understood by the developer (sequence diagrams, class diagrams)

43. Why different kinds of models? Use case model (user oriented view of the domain) Domain model (analysis model, analyst oriented view of the domain) Design model (view of software concepts in the domain) Each type of model describes the same system but from a different perspective and at a different level of abstraction. They provide different kinds of information (e.g. dynamic, static view of the system, or functionality oriented vs. solution oriented)

44. Types of Requirements Functional requirements: Describe the interactions between the system and its environment independent from implementation The system must record sales. Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. The response time must be less than 5 second The display should be readable from 1 meter. Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate The implementation language must be JAVA.

45. Nonfunctional Requirements Usability Reliability Performance Supportability Implementation Interface Operations

46. Nonfunctional Requirements Usability: User interface and human factors What type of user will be using the system? Will more than one type of user be using the system? What sort of training will be required for each type of user? Is it particularly important that the system be easy to learn? Is it particularly important that users be protected from making errors? What sort of input/output devices for the human interface are available, and what are their characteristics?

47. Nonfunctional Requirements Usability : Documentation What kind of documentation is required? What audience is to be addressed by each document? Implemenation: Hardware considerations What hardware is the proposed system to be used on? What are the characteristics of the target hardware, including memory size and auxiliary storage space?

48. Nonfunctional Requirements Performance characteristics Are there any speed, throughput, or response time constraints on the system? Are there size or capacity constraints on the data to be processed by the system? Reliability: Error handling and extreme conditions How should the system respond to input errors? How should the system respond to extreme conditions?

49. Nonfunctional Requirements Interface Is input coming from systems outside the proposed system? Is output going to systems outside the proposed system? Are there restrictions on the format or medium that must be used for input or output? Supportability : System Modifications What parts of the system are likely candidates for later modification?

50. Nonfunctional Requirements Reliability : Quality issues What are the requirements for reliability? Must the system trap faults? Is there a maximum acceptable time for restarting the system after a failure? What is the acceptable system downtime per 24-hour period? Is it important that the system be portable (able to move to different hardware or operating system environments)? What sorts of modifications are expected?

51. Nonfunctional Requirements Physical Environment Where will the target equipment operate? Will the target equipment be in one or several locations? Will the environmental conditions in any way be out of the ordinary (for example, unusual temperatures, vibrations, magnetic fields,...)?

52. Nonfunctional Requirements Reliability : Security Issues Must access to any data or the system itself be controlled? Is physical security an issue? Operation : Resources and Management Issues How often will the system be backed up? Who will be responsible for the back up? Who is responsible for system installation? Who will be responsible for system maintenance?

53. Pseudo Requirements Pseudo requirement: Any client restriction on the solution domain Examples: The target platform must be a SUN/SPARC The implementation language must be JAVA The documentation standard X must be used A data-glove must be used ActiveX must be used The system must interface to a barcode reader

54. Prioritizing requirements High priority (“Core requirements”) Must be addressed during analysis, design, and implementation. A high-priority feature must be demonstrated successfully during client acceptance. Medium priority (“Optional requirements”) Must be addressed during analysis and design. Usually implemented and demonstrated in the second iteration of the system development. Low priority (“Fancy requirements”) Must be addressed during analysis (“very visionary scenarios”). Illustrates how the system is going to be used in the future if not yet available technology enablers are

55. Requirements Validation Requirements validation criteria: Correctness: The requirements represent the client’s view. Completeness: All possible scenarios through the system are described, including exceptional behavior by the user or the system Consistency: There are functional or nonfunctional requirements that contradict each other

56. Requirements Validation Clarity: There are no ambiguities in the requirements. Realism: Requirements can be implemented and delivered Traceability: Each system function can be traced to a corresponding set of functional requirements