Lecture01-OrgIntroUseCases.pdf

TOMK18/TOUK18 – 6/7.5 credits Autumn 2024 Object-Oriented Software Development / … with design patterns Lecture01 Intro Tuesday August 27, 2024 Johannes Schmidt School of Engineering  Programming is fun, but developing quality software is hard. (from App...

TOMK18/TOUK18 – 6/7.5 credits Autumn 2024 Object-Oriented Software Development / … with design patterns Lecture01 Intro Tuesday August 27, 2024 Johannes Schmidt School of Engineering  Programming is fun, but developing quality software is hard. (from Applying UML and patterns) Agenda Course information, organisation Introduction to (object-oriented) Software Development Use Cases Course staff Johannes Schmidt, [email protected] Examiner, course leader, lecturer, lab assistant Andreas Lönn Lab assistant Linus Sönnerhed Lab assistant Mohamed Maizia Lab assistant ILOs Knowledge and understanding Display knowledge of different methods for system development and their pros and cons Display knowledge of system design, requirements specifications and validation Display understanding of the most common aspects of the Unified Modelling Language (UML) Display understanding of established design patterns for object-oriented analysis, object-oriented programming and system architecture ILOs Skills and abilities Display skill to, via analysis of a requirements specification, create UML- diagrams describing an IT-system that meets the requirements Display skill to implement UML-diagrams into object-oriented program code Display ability to apply object-oriented programming with design patterns for software development Judgement and approach [TOUK18 only] Display ability to, given a problem, suggest and motivate appropriate design patterns Literature Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition), Craig Larman, Prentice Hall, ISBN: 978-0131489066 Head First, Object-Oriented Analysis&Design, Brett D. McLaughlin, Gary Pollice & David West, O’Reilly, ISBN: 978-0596008673 Both available at JU library in electronic and paper form Course information Canvas activities TOUK18 T4227 Object-oriented Software Development with Design Patterns https://ju.instructure.com/courses/12327 TOMK18 T4231 Object-oriented Software Development https://ju.instructure.com/courses/12358 Course information Teaching elements Lectures Lab sessions Examination elements Examination element Credits TOMK18 Credits TOUK18 grades Written exam 4 4 5/4/3/Fail Lab assignments 2 3.5 Pass/Fail Course information Written exam Digital (Inspera) exam in week 42: October 17th, 14.00-17.00 Course information Lab assignments Rules Lab 01: Use Cases To pass a lab: week 35-36 1) oral presentation 2) submission via Canvas Lab 02: A&D, UML (Assignments) week 36-37 3) wait for feedback Lab 03: Basics of java You may discuss the labs and week 37-39 possible solutions with your peers, Lab 04: Design in java but: week 38-40 Individual work and submissions! (plagiarism check) Lab 05: design patterns week 40-42 Instructions are (will be) available on [TOUK18 only] Canvas (Modules/Labs) General deadline: end of week 42 Each lab has a (soft) deadline. If you miss it, submission is closed until week 42  Texts are generated from other texts (can create plagiarism) Quality varies References often made up Do not trust answers, always double check. Can be used as inspiration, but not more. For code: can be used to understand, learn and generate code. But: never use it without understanding the generated code a 100%. Usually, generated code needs to be reworked anyway to fit your needs. Course information In Canvas please sign up for one of the following lab groups TOUK18: G1: timeslot mostly Wednesday 8.15-12.00 lab assistant primarily Linus G2: timeslot mostly Wednesday 13.15-17.00 lab assistant primarily Andreas G3: timeslot mostly Thursday 13.15-17.00 lab assistant primarily Mohamed TOMK18: G1: timeslot mostly Tuesday 13.15-17.00 lab assistant primarily Linus G2: timeslot mostly Wednesday 13.15-17.00 lab assistant primarily Andreas Course information A course evaluation takes place at the end of the course. Of course you can give us feedback during the course, too. Course information Last year’s course evaluation: course well-received. No significant changes planned. Count TGIN7H23 – TOMK18 Datateknik, inbyggda system TGMM7H23 – TOUK18 Datateknik, mjukvaruutveckling och mobila plattformar  Programming is fun, but developing quality software is hard. Who says that? Software Development "only 35 percent of software projects started in 2006 could be categorized as successful – defined in the broadest sense as being completed on time, on budget and meeting user requirements" (Standish Group, 2006) "half of all large IT projects – defined as those with initial price tags exceeding $15 millions – massively blow their budgets. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. Software projects run the highest risk of cost and schedule overruns" (McKinsey&Company, 2012) "More than half of IT projects still failing" (CIO Magazine, 2016) Requirements Among IT projects that fail, how many do so as a result of poor requirements management? Select one: 15% 58% 71% 95% Requirements Among IT projects that fail, how many do so as a result of poor requirements management? Select one: 15% 58% 71% 95% Requirements Conclusion IT-Project failure is common. A major reason is lack of involvement of the customer. (Applying UML and patterns) And: Requirements change (or evolve) while a system is developed! Capture requirements is a challenge Miscommunication? A question of interpretation! Example: create a means to transport an individual from home to place of work Developing Software – basic idea Does not work well. Why? Developing Software – refined Works much better.  Software Development Life Cycle (SDLC) requirements -> plan -> implement -> test/integrate -> operate Main focus of this course Analysis and Design Analysis: Do the right thing Design: Do the thing right In the Object-Oriented context: Analysis: find/identify the objects Design: define software objects and how they collaborate/work together to fulfill the requirements Why Object-Oriented (OO)? It is one of the major programming paradigms and can produce quality software (btw, what is quality software?) What else is there, if not OO? imperative: procedural, object-oriented declarative: functional, logical data-driven … Software Development Life Cycle (SDLC) requirements -> plan -> implement -> test/integrate -> operate Why capture requirements at all? If they change anyway… if the customer anyway doesn’t know them… if that is such an impossible task anyway…? The relative cost to fix an error Phase in which found Cost Requirements 1 Design 3-6 Coding 10 Dev. Testing 15-40 Acceptance Testing 30-70 Operation 40-1000 A similar figure holds for changes! Requirements – two types Functional requirements Non-functional requirements Describes an interaction Describes a restriction or between the system and its constraint that limits our choices Environment, e.g. for constructing a solution, e.g. System communicates with Paychecks distributed no more than external system X 4 hours after initial date is read What conditions must be met for System limits access to senior a message to be sent managers Sometimes requirements are also divided into product req. vs project req. That is a different (or additional) division! Requirements – two types Hotel reservations: identify functional and non-functional requirements Functional requirements Non-functional requirements – Reservations and cancellations – Max. time to do reservation < 2 min. – Meals and extra services – Downtime < 1% – Billings – Run on Windows & Mac – Easy to change DBMS Requirements capuring In earlier times (1960’s, 1970’s, …), lists of requirements were often created. These lists were usually long and exhaustive. Today this is less common. Instead, text stories are written which describe "cases of usage" Use Cases Text stories of some actor using a system to meet goals. Example (simple): A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items. Purpose of use cases: discovering and recording requirements. Focus lies on functional requirements. Use Cases – more formally Actor: something with behaviour: person (in a certain role) or computer system, organisation, … Scenario: specific sequence of actions and interactions between actors and the system Use case: collection of related (success AND failure) scenarios Use Cases – example Use case Handle Returns Main success scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item … Alternate scenarios: If the customer paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash. If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code (perhaps it is corrupted). If the system detects failure to communicate with the external accounting system … Use Cases – Different Kinds of Actors Actor: something with behaviour SuD = System under Design Why identify? Primary actor: has user goals Find user goals (which drive fulfilled throught the SuD. the use cases!) E.g. the cashier Supporting actor: provids a service Clarify external interfaces and (e.g. information) to the SuD. protocols E.g. automated payment authorisation service Offstage actor: has an interest in the Ensure that ALL necessary SuD’s behaviour, but is not primary interests are identified (and or supporting. satisfied) E.g. government tax agency Use Cases – different formats When? Brief Early requirements analysis One paragraph summary, main success scenario Casual Early requirements analysis Various scenarios, one paragraph each Fully dressed Once many use cases are identified All steps and variations in detail + and written in brief/casual format supporting sections (preconditions, Only the architecturally significant success guarantees) and high-value use cases  Use Cases – fully dressed Various format templates exist. E.g. one from Alistair Cockburn: Use Case Section Comment Use Case Name Start with a verb/action Scope The system under design Level Either ”user-goal” or ”subfunction” Primary Actor Calls on the system to deliver its services Stakeholders and Interests Who cares about this use case, and what do they want? Preconditions What must be true on start, and is worth telling the reader? Success Guarantee What must be true on successful completion, and is worth telling the reader? Main Success Scenario A typical, unconditional happy path scenario of success Extentions Alternate scenarios of success or failure Special Requirements Related non-functional requirements Technology and Data Variations List Varying I/O methods and data formats Frequency of Occurrence Influences investigation, testing, and timing of implementation Miscellaneous Such as ”open issues” Use Cases – Extension notation Letters are used for extensions. Main success scenario: 1. Ask user to input URL 2. Input URL valid and exists: … 3. … Extensions: 2a URL invalid format 2b URL valid format, but not existent 3a … Use Cases – branching Use cases sometimes branch to perform another use case 3a. Invalid item ID (not found in system): 1. System signals error and rejects entry. 2. cashier responds to the error: 2a. … 2b. … 2c. Cashier performs Find Product Help to obtain true item ID and price Identify it by underlining it. Use Cases – two column format The two column format emphesizes the interaction between the actors (left column) and the system (right column). Main Success Scenario: Actor Action (or Intention) System Responsibility 1. Customer arrive at POS checkout with goods and/or services to purchase 2. Cashier starts a new sale 3. Cashier enters item identifier 4. Records each sale line item and presents description and running total. 5. Presents total with taxes calculated. Cashier repeats steps 3-4 until indicates done 6. Cashier tells customer the total and asks for payment. … Use Case Diagrams Use cases are about writing text. However, certain drawings (diagrams) can be used as a supplement to the text stories. E.g. a Use Case Context Diagram illustrates the external actors and how they use the system. How to write good Use Cases Essential style: keep the UI out, focus on actor intent Concrete style: include the UI Use essential style, concrete only when in late requirements phase Focus rather on WHAT the user puts in and gets out of the system, rather than on HOW it is done Write terse (e.g. avoid articles whenever possible) Write Blackbox use cases: do not describe the internal working of the system, focus on the system’s responsibilities Generally: focus on WHAT is to do, not HOW Take an actor and actor-goal perspective Who writes the Use Cases? Usually people from the development team. However, user involvement is highly desireable (either reading+feedback or even co-writing) Why Use Cases? Why are Use Cases so widely used and popular for over 30 years? Hard to say. One strength is clearly this: With Use Cases one can scale up and down in both detail and degree of formality. Not everybody uses Use Cases of course. Recommended readings Applying UML and patterns Chapter 1 Chapter 6 Now you got all you need… … to start with lab 1 Have fun!