Top Banner
Object-Oriented Software Engineering Practical Software Development using UML and Java SEG2105 FINAL REVIEW December 2015
16

SEG2105 FINAL REVIEW December 2015

Jan 17, 2018

Download

Documents

Lisa Campbell

Chapter 8: Modelling Interactions and Behaviour PLAN Chapter 10 concepts Chapter 11 concepts UML design Chapter 8: Modelling Interactions and Behaviour © Lethbridge/Laganière 2012
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: SEG2105 FINAL REVIEW December 2015

Object-Oriented Software EngineeringPractical Software Development using UML and Java

SEG2105FINAL REVIEW

December 2015

Page 2: SEG2105 FINAL REVIEW December 2015

PLAN

• Chapter 10 concepts• Chapter 11 concepts• UML design

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 2

Page 3: SEG2105 FINAL REVIEW December 2015

Chapter 10 - Testing

• Error• Fault (Bug)• Failure

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 3

Page 4: SEG2105 FINAL REVIEW December 2015

Black box vs White box testing

• Black Box testing: Equivalence classesEX.Input: month, day, year representing a date– 1 <= month <= 12– 1 <= day <= 31– 1812 <= year <= 2012

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 4

Page 5: SEG2105 FINAL REVIEW December 2015

Black box vs White box testing

• White Box testing: Control flow graphEx.

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 5

Page 6: SEG2105 FINAL REVIEW December 2015

Defects in Timing

Deadlock Livelock

Deadlock

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 6

Page 7: SEG2105 FINAL REVIEW December 2015

Defects in Timing

Critical Race

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 7

Page 8: SEG2105 FINAL REVIEW December 2015

Strategies for testing large systems

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 8

Page 9: SEG2105 FINAL REVIEW December 2015

Chapter 11 – Process models

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 9

Page 10: SEG2105 FINAL REVIEW December 2015

Software Development MethodologiesRUP vs Agile (scrum, XP)

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 10

Page 11: SEG2105 FINAL REVIEW December 2015

Software Engineering Teams

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 11

Page 12: SEG2105 FINAL REVIEW December 2015

Project Scheduling and Tracking - PERT

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 12

Page 13: SEG2105 FINAL REVIEW December 2015

Project Scheduling and Tracking - GANTT

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 13

Page 14: SEG2105 FINAL REVIEW December 2015

Class Design – Manufacturing Plant Controller (Page 479 in the textbook)

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 14

Page 15: SEG2105 FINAL REVIEW December 2015

UML Design – Class and State DiagramsExam Management Corporation (EMC) runs exams internationally for organizations that provide certifications (e.g. ‘certified FIFA referee). EMC runs testing centres around the world, an organization that wants to provide a certification arranges with EMC to develop and administer exams to candidates. Each certification has one exam. Each exam has a ‘bank’ of questions. A candidate who writes an exam will be presented on their test-centre computer screen with a subset of these questions; that way a candidate can’t memorize the questions and tell another candidate what they are. There might be 500 questions in the bank for an exam, and each candidate might only have to answer 100 of these.  Organizations have to create new questions every year to replace old ones in each bank. Old questions are marked as ‘removed’. Questions might also be put ‘on-hold’ so they are not selected for a period of time. Some questions might be used in more than one certification (they are in more than one question bank). Some exams have categories of questions. For example, candidate in a software engineering exam might have to answer at least 10 questions on design, 10 on requirements and 10 on project management. When a random exam is created for a candidate the, system ensures that at least these minimum numbers of questions are chosen from each category. Exam questions can be one of the following two types:•Multiple choice questions have what is called the ‘stem’ (the part before the list of answers) and between 2 and 8 answers. One of the answers is the ‘key’ (the correct answer) worth 4 points, and the others are called ‘distractors’, worth 0 points. •Fill-in-the-blank questions also have a stem, however they also have a list of potential answers, each of which is worth between 1 and 4 points. When marking these questions, the system determines whether the candidate’s answer matches an item on the list. If there is no match, then a human marker is prompted to give a grade. The student’s answer and mark is then stored as a new potential answer so that next time the same answer can be marked automatically. When a student has completed his or her exam, he or she clicks on the “exam complete” button. For each question, the system gets the student’s answer and the corresponding item in the bank. It then processes the answer according to whether it is a multiple choice or fill-in-the blank question, and adds the correct number of points to the final grade. Once the system has processed all the questions, it stores the final grade in the database and sends the result to the student. The system also keeps track of the number of candidates who give each answer, so that a statistical analysis can be performed to ensure the question is not misleading.

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 15

Page 16: SEG2105 FINAL REVIEW December 2015

State Machine

A record company wants to create a software system to manage its CD release process. A new CD release process is started when a decision to launch is made by the record company and results in an “empty” CD being created. A CD producer can then add a track to the empty CD. If the track fits, the CD becomes then “non-empty”. The producer can continue to add tracks to a non-empty CD, as long as they fit. She can also delete tracks. If she deletes a track and there are none left, the CD becomes empty again. When the producer has finished editing, she will declare the CD to be “ready for pressing”, after which no more track changes can be made. Once a CD is “ready for pressing” the record company may request a certain number of copies to be pressed. This request results in the required number of CD being pressed. The CD is then “ready for release”. It stays in this state until the record company decides to release it. Anytime before any copies of a CD are pressed, the record company may decide to cancel the CD. All work done on the CD is then cancelled and a new decision to launch needs to be made to start over the CD release process. Once a CD is “released“, it can either be “in stock“ (i.e., copies are available for sale) or “out of stock“ (i.e., no copies are available). The record company may request other pressings of a CD “in stock” or “out of stock” to put it back in stock. The record company may also decide to delete an “out of stock” CD. In that case, no more pressing is done, however, the CD is still considered “released”.

© Lethbridge/Laganière 2012 Chapter 8: Modelling Interactions and Behaviour 16