Computer ScienceSoftware Engineering Slide 1 Groups Paul Simmerlink Andrew Rodgers Daniel Coming Ogechi Ugwulebo William Nelson Jigna J. Bhatt Casey J. Powell Jonathan Ward Michael Vidal Howard C. Wu Stephen Herbert Don Miller James Frye David Brewer Olja Mihic Casey Mees Maggie Lu Reid Webber Taisuke Nagayama Stan Sexton Matasaka Sako Brett Harrison Shana Rheault RichardD.VanHorn Rodel Mangoba Steve Luong Jason Dodd Beifang Yi Dorothy P. Cheung James King Will Woolsey James Cohen, Judy Rowley, Rajashekhar Yakkali, Kazuhito Mori, Jeff Payne

Computer ScienceSoftware Engineering Slide 2 Teamwork l Know each other Strengths and Weaknesses Schedules Preferences l Compete With other groups With each other l Leadership Emergent Social/Technical

Computer ScienceSoftware Engineering Slide 3 Requirements/Initial Design l Brainstorm, disseminate your understanding l Reach a consensus or ask for clarification l Split tasks AFTER reaching consensus l The members with the best understanding (<= 3) should architect the system (major classes – relationship among them). l Group reviews and suggests modifications l Ask for volunteers l Keep track of progress – Design for visibility

Computer ScienceSoftware Engineering Slide 4 The Process of Requirements Analysis l Create verified requirements specification l Create list of primary classes l Create informal scenarios l Create use cases l Create scenarios l Create class diagrams l Create use case diagrams

Computer ScienceSoftware Engineering Slide 5 Determining Primary Classes l Select nouns from the requirements specification and inspect each noun for the following properties Retained information Needed services Multiple attributes Common attributes Common operations Essential requirements

Computer ScienceSoftware Engineering Slide 6 LMS Case Study:Primary Classes l Patron l Student, faculty, library staff l Resource l Book, music CD, video, software l Reference resource, reserved resource, requested resource, online research resource l Inter-library loan request l Overdue charge l Overdue form letters

Computer ScienceSoftware Engineering Slide 7 Identifying Use Cases l A use case is a description of a scenario (or closely related set of scenarios) in which the system interacts with users of the system l The behavior of the system is expressed without specifying how the behavior is implemented l Use cases are initially described narratively, and then modeled graphically by class diagrams and interaction diagrams (to be discussed later) l Informal scenarios are a good starting point for use cases

Computer ScienceSoftware Engineering Slide 8 Characteristics of Use Cases l Use cases are more abstract than informal scenarios l A single use case may encompass multiple scenarios l Use cases avoid redundancy l Use cases are more formally structured than scenarios l Use cases seek to capture complete breadth of system behavior

Computer ScienceSoftware Engineering Slide 9 Use Case Layout l Precondition What conditions must be true at the beginning of the use case? l Main flow of events Describe the essential behavior associated with the use case l Post condition What occurs as a result of the use case executing l Exceptional flow of events ( zero to many) Enumerate possible erroneous flow of events

Computer ScienceSoftware Engineering Slide 10 LMS Case Study: Use Cases l Validate patron l Check out resource l Check in resource l Request resource l Reserve resource l Manage Resource l Manage Patron l Generate from letter

Computer ScienceSoftware Engineering Slide 11 LMS Case Study: Check out Resource Use Case l Precondition Library staff and patron validated to LMS Library DB initialized l Main flow of events Enter resource Determine due date l Exceptional flow of events Patron ID not valid Patron has over due resources or too many checked Resource number not valid

Computer ScienceSoftware Engineering Slide 12 More LMS Case Study: Check out Resource Use Case l Postcondition Patron DB entry updated to reflect new resource Resource DB entry updated to reflect changed status: checked out Due date assigned to the resource DB entry