Software Engineering

1. Object Oriented Analysis Software Engineering • 1. Requirements and specifications • goal • techniques • testing and metrics • case studies • 2. OOA : main activities and UML • 3. OOA : Use-case modeling • 4. OOA : Class modeling • 5. OOA : Interaction modeling • 6. OOA : Testing and Metrics

2. Requirements engineering 1. Requirement engineering User Feedback User requirements User validation specification elicitation Domain knowledge Domain knowledge Problem Domain

3. Structure communication between client and developer Requirement Elicitation Goal 1. Requirement engineering = find out what the client needs + limitations  what the client wants • Basic techniques • interviews • scenarios • rapid prototypes

4. Requirement Elicitation techniques 1. Requirement engineering interview • structured -> fixed set of close-ended questions are posed • unstructured-> use of open-ended questions • questionnaire given to group of employees-> no interaction between interviewer and interviewee possible • use of camera’s to find out problems at client side

5. Requirement Elicitation techniques 1. Requirement engineering scenarios = a set of “if … then”-clauses • Representations • list actions associated with scenario • give a sequence of expected screen shots in response to action

6. put together a working product, implementing a • subset of the expected functionality • include functionality visible to the usere.g. input screens, reports, ... • omit complexity not eliciting needse.g. input checks, file updates, consistency checks, layout, ... modify prototype until client and developer agree that all client needs are incorporated Requirement Elicitation techniques 1. Requirement engineering Rapid prototype  build-and-fix for the prototype !

7. Combine with interview for optimal results ! Requirement Elicitation techniques 1. Requirement engineering Rapid prototype •  replacement for specification • too informal • no written documentation ! •  version 1 of the product • build-and-fix problems !!! • not built to host complete functionality • not built for (good) performance

8. Elicitation techniquesTaxonomy 1. Requirement engineering Dominant information source Users Domain Ethnography Form analysis Natural language Reqs of existing system Domain analysis Interview Delphi technique Task analysis Scenario analysis Current situation Business Process Redesign (BPR) Brainstorming session Prototyping Future safe

9. Requirement specification 1. Requirement engineering • Introduction • Purpose • Scope • Definitions, acronyms and abbreviations • References • Overview • Overall Description • Product Perspective • Product Functions • User characteristics • Constraints • Assumptions and dependencies • Requirement subsets • Specific Requirements

10. Requirement specification 1. Requirement engineering 3. Specific Requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1.2 Hardware interfaces 3.1.3 Software interfaces 3.1.4 Communication interfaces 3.2 Functional requirements 3.2.1 User class 1 3.2.1.1 Functional Requirement 1.1 3.2.1.2 Functional Requirement 1.2 … 3.2.2 User class 2 … 3.3 Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements

11. Testing & Metrics 1. Requirement engineering Testing • role of SQA : • “test” that relevant client personnel is involved • are requirements consistent ? • extract tests out of requirements (“validation tests”) Metrics • number of new/changed requirements per unit of time • number of new/changed requirements AFTER completion of requirement phase • rapid prototyping : keep track of user interaction

12. Describe a set of scenario’s ? ? Case I Home alarm system 1. Requirement engineering Problem description • We want to make a system to give warnings (alarm goes • off) in case of emergency. Emergencies can be : • fire • flooding • illegal entry • ... Problem

13. Describe a set of scenario’s ? ? Case II The (in)famous elevator problem 1. Requirement engineering Problem description ? • Software to control an elevator is requested. The elevator • is to serve N floors, and has two types of control buttons : • buttons in the elevator : to select destination floor • buttons in the hall : to request an “elevator service” Problem

14. Describe a set of scenario’s ? ? Case III Courses, Students and Professors 1. Requirement engineering Problem description ? A software tool to manage courses, students and lecturers is to be built. A student can (de)register to any course, and each course is given by a specific lecturer. The specific lecturer for a course is entered by an administrator. Any lecturer must be able to get - an overview of the courses he’s supposed to organize and - a list of students attending a specific course he/she is responsible for. Problem

15. Goal of OOA 2. OOA-activities • specify the externals of the product precisely (= specification technique) • architectural design (class and object identification) How to do it ? (1) formalize basic requirements (user-developer) (2) identification of classes (3) identification of class hierarchy (4) find connections between objects (5) modeling of object behavior

16. Several diagrams to model different aspects of the software under construction Use-case diagrams (CRC-modeling) Class diagrams Interaction diagrams State diagrams UML ? 2. OOA-activities Visual modeling of software (1) formalize basic requirements (2) identification of classes (3) identification of class hierarchy (4) find connections between objects (5) modeling of object behavior

17. Concept 3. Use-case diagram Goal Present requirements as seen from the user in a diagram, unambiguously = user model view • define functional requirements of the system • describe clear and unambiguously interaction between user and system • provide basis for validation testing Use-case diagram = Actor + use-cases

18. Actors 3. Use-case diagram = a role any external “user” plays interacting with the system • Single physical person can play many roles • User can be a physical person or other (external) software/hardware system THE SYSTEM

19. Case IIICourses, Students and Professors 3. Use-case diagram Problem ? ? Find the actors ! CourseAdministration

20. Case IIICourses, Students and Professors 3. Use-case diagram Solution ? CourseAdministration

21. Scenarios helpful to find use-cases Identify external events and deduce use-cases Use-case 3. Use-case diagram • = externally required functionality (usually required by a -set of- actors) • typically describes a goal/objective of an actor How to find use-cases ? Scenario is implementation of use-case System responds to external events

22. Use-case diagram 3. Use-case diagram Actor 2 requires functionality of use-case 4

23. Case IIICourses, Students and Professors 3. Use-case diagram Problem ? ? Find use-cases !

24. Case IIICourses, Students and Professors 3. Use-case diagram Solution ?

25. <<extends>> 3. Use-case diagram use-case A has more functionality than use-case B (i.e. use-case A = use-case B + modifications) Used to express variation on normal behavior

26. <<uses>> 3. Use-case diagram Use-cases A and B need functionality of use-case C Used to avoid repetition of same functionality UML 2.0 : <<include>> replaces <<uses>>

27. Use-caseand scenarios 3. Use-case diagram + Use-case diagram Scenario’s Use case 1 Use case 2 Use case 3

28. Use-caseand scenarios 3. Use-case diagram Use case title Main Success Scenario 1. Step 1 2. Step 2 … Extensions <MSS-step> [condition for alternative] .1 : Step 1 .2 : Step 2 . : … .X : return to MSS step … <MSS-step> [ …] … Pre-conditions Post-conditions Triggers Use case 1

29. Techniques • noun extraction • CRC-cards • UML class diagram Concept 4. Class modeling Goal • find essential classes and attributes • find structure and hierarchy of classes = static “data oriented” view

30. Class identification 4. Class modeling Major class categories • External entities producing/consuming information • Things part of the problem domain • Occurrences/events during system operation • Roles played by people interacting with the system • Organizational units relevant to the application • Places • Structures aggregating objects or defining relations between objects

31. class-candidates Class identification 4. Class modeling Noun extraction • Make a small text describing the problem, together with major requirements (10-20 lines). • Isolate all nouns from this text. • Remove : • nouns relating to non-physical, abstract entities • nouns relating to physical entities outside the problem domain • Only first indication !

32. Class identification 4. Class modeling CRC-cards = Class-Responsibility-collaboration card For each class fill in form Class name : Class type : Class characteristic : responsibilities : collaborations : Describe the functionality of the class List other classes needed to achieve this functionality

33. Class identification 4. Class modeling CRC-cards Show collaborations in diagram Find new classes/collaborations/responsibilities by “role play” (based on scenario’s)

34. Case IIICourses, Students and Professors 4. Class modeling Problem ? • Include password based authentication. • All users identified by a unique number. • Update use-case diagram ! • Identify classes by : • writing small text (10-20 lines) • noun extraction

35. Case IIICourses, Students and Professors 4. Class modeling Solution Original Use-case diagram ?

36. Case IIICourses, Students and Professors 4. Class modeling Solution Updated Use-case diagram ?

37. Case IIICourses, Students and Professors 4. Class modeling Solution ? Descriptive text (10-20 lines) A system to administrate courses is to be constructed. A user requesting/supplying information from/to the system must identify himself using a password, which is checked. If found OK, the user gets access to the system and sees a menu.Each user has a unique identification number. The administrator of the system is responsible for defining the course-instructor relationship, and has essentially access to all information in the system (read and write). Students can register or deregister for any course. A professor can get a list of students for a specific course he teaches, and can also get a list of courses he teaches.

38. Case IIICourses, Students and Professors 4. Class modeling Solution ? Extract nouns A system to administrate courses is to be constructed. A user requesting/supplying information from/to the system must identify himself using a password, which is checked. If found OK, the user gets access to the system and sees a menu. Each user has a unique identification number. The administrator of the system is responsible for defining the course-instructorrelationship, and has essentially access to all information in the system (read and write). Students can register or deregister for any course. A professorcan get a listof students for a specific course he teaches, and can also get a list of courses he teaches.

39. CourseAdministration IDNumber SAME Case IIICourses, Students and Professors 4. Class modeling Solution Candidate classes ? System Course User Information Password Access Administrator Instructor Relationship Student Professor List Number Menu Abstract Abstract Abstract Existing class (Vector or [ ])

40. Case IIICourses, Students and Professors 4. Class modeling Solution ? Candidate classes CourseAdministration Course User Password Administrator Student Professor IDNumber Menu

41. Fundamental question What items are needed to uniquely and completely define an object of the class ? Attributes 4. Class modeling For each class find its (essential) attributes Sources ? • problem description used for class extraction • CRC-card functionality description

42. Case IIICourses, Students and Professors 4. Class modeling Problem ? Make a CRC-card for the Course candidate class and find attributes.

43. Case IIICourses, Students and Professors 4. Class modeling Solution ? Course Class name : responsibilities : collaborations : Store/change/give course title Administrator Store/change/give instructor Administrator, Professor Store/change/give subscribed Students Administrator, Professor, Student

44. Case IIICourses, Students and Professors 4. Class modeling Solution ? Student Class name : responsibilities : collaborations : Manage password Password Store/change/give first name& family name Store/give unique ID number IDNumber (De)register to course Course Give list of courses to attend Course

45. Case IIICourses, Students and Professors 4. Class modeling Solution ? Professor Class name : responsibilities : collaborations : Manage password Password Store/change/give first name& family name Store/give unique ID number IDNumber Give list of own courses to give Course Give student list for own course Course, Student

46. Case IIICourses, Students and Professors 4. Class modeling Problem ? Draw class diagram. Add navigability, composition, aggregation. Golden Rule of software engineering applies : Don’t use all possible features ! KEEP IT SIMPLE

47. Concept 5. Interaction Diagrams Goal • to find out how objects interact as a function of time • to combine scenario’s (dynamic) and class structure (static) Two types of diagrams • sequence diagram • collaboration diagram UML notation for objects Object named c from class B Any object from class B

48. Possible JAVA-implementation ... b.f(); c.g(); … Sequence Diagram 5. Interaction Diagrams • show message passing between objects • drawn as a function of time • creation of new objects indicated • can contain messages to actors class C { ... public void g() { D d = new D(); d.h(); } ... } class D { public D() { h(); } public void h() {…} } Object lifeline Return optional

49. Sequence Diagram 5. Interaction Diagrams Adding control information Possible JAVA-implementation condition if (OK==true) b.f( ); iteration B[ ] b = new B[size]; for(int i=0;i<size;i++) b[i].f( );

50. Case IIICourses, Students and Professors 5. Interaction Diagrams Problem ? Make a scenario for password authentication Transform into a sequence diagram. List consequences to CRC-card for Password class.