Lecture 6

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 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. Problem Statement: Direction Control for a Toy Car

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 :Wheel :Headlight Billy:Driver Power(on) Power(on) Power(off) Power(off) Power(on) Power(on)

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

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

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 Class Diagram anonymous: Inspector joe: Inspector mary: Inspector Instance Diagram

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

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. Country City name name Order 1-to-1 and 1-to-N Associations has-capital 1-1 association Item contains * price productID date 1-N association

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

34. Customer Order Many-to-Many Associations places * *

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

37. Red White Smooth Cortical Striate Inheritance • Models "kind of" hierarchy • Powerful notation for sharing similarities among classes while preserving their differences • UML Notation: An arrow with a triangle Cell BloodCell MuscleCell NerveCell Pyramidal

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?