New User Special Price Expires in

Let's log you in.

Sign in with Facebook


Don't have a StudySoup account? Create one here!


Create a StudySoup account

Be part of our community, it's free to join!

Sign up with Facebook


Create your account
By creating an account you agree to StudySoup's terms and conditions and privacy policy

Already have a StudySoup account? Login here

CS2103 Software Engineering Final Exam Study Guide

by: Jerry Tan

CS2103 Software Engineering Final Exam Study Guide CS2103

Marketplace > National University of Singapore > Quantitative Methods > CS2103 > CS2103 Software Engineering Final Exam Study Guide
Jerry Tan
GPA 4.3

Preview These Notes for FREE

Get a free preview of these Notes, just enter your email below.

Unlock Preview
Unlock Preview

Preview these materials now for free

Why put in your email? Get access to more of this material and other relevant free materials for your school

View Preview

About this Document

NUS, CS2103 final exam study guide, consolidated from lectures and module notes/textbook - Notes on SE - An Incremental Approach. All 11 lectures condensed into a 46 page document. Note that this i...
Software Engineering
Damith C. Rajapakse
Study Guide
50 ?




Popular in Software Engineering

Popular in Quantitative Methods

This 46 page Study Guide was uploaded by Jerry Tan on Sunday November 22, 2015. The Study Guide belongs to CS2103 at National University of Singapore taught by Damith C. Rajapakse in Summer 2015. Since its upload, it has received 135 views. For similar materials see Software Engineering in Quantitative Methods at National University of Singapore.

Popular in Quantitative Methods


Reviews for CS2103 Software Engineering Final Exam Study Guide


Report this Material


What is Karma?


Karma is the currency of StudySoup.

You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!

Date Created: 11/22/15
      CS2103  –  Software  Engineering   Final  Exam  Study  Guide   1 By:  Jerry  Tan  Si  Kai                                                                                                                         1  Credits  :  Notes  on  Software  Engineering:  An  Incremental  Approach  [Aug  2015   edition]  by  Bimlesh  Wadhwa,  Damith  C.  Rajapakse,  Henry  Chia,  Soo  Yuen  Jien   Lecture  1:  Introduction  to  Software  Engineering   What is software engineering? Short answer - engineering of software Detour into Software Engineering 1.The first step to become a professional software engineer 2.The product is you, not the software 3.Build software better, not bigger 4.Learn to learn, not just content Why do students say that software engineering projects are not useful to industry? Because school projects are usually started from scratch and worked on for a semester while industry projects are not from scratch usually and it is the sum of contribution from many other software engineers, over many years of work. Why use an IDE? Integrated Development Environment (IDE) are used to help you debug and code more efficiently. Define breakpoints Pause program execution Examine program state and variables in debugging mode Step by step program execution For this course, everyone should use either Eclipse or Microsoft Visual Studio. When everyone is using the same platform, the collective knowledge of the community can be used to help everyone. Why use a text editor? Lightweight Powerful features like fuzzy search Disadvantage - lack of features like step by step program execution, breakpoints etc. Experienced programmers do not expect program to run without errors on first try. They will run the program, run into errors, and then debug. Regression - term to use when you fix a bug which unintentionally introduced other bugs To prevent them, do testing. Testing Can be Scripted or Exploratory Can be Manual or Automatic Software Under Test (SUT) - the unit of software subjected to the test For each test case, have a test input, check the actual output against the expected output, if there is a mismatch, locate the bug, and modify the code to fix the bug. But once you modify the code, you may have introduced a regression, hence, retest all the other test cases again. How to automate testing Enumerate all the test cases and put into a text file. In the terminal, run the program, take the input file and output to a new text file. In windows, use a FC command (file compare) to compare the output file against the expected file to check for errors. Works very well for programs where all the test cases can be known beforehand and finite, but not well for randomly initialized state, or when not all the test cases can be known beforehand.         Lecture  2  -­‐  Good  code,  Bad  code:  Toward  Production  Quality   Code     What  are  the  qualities  of  production  level  code?   1) Performance  –  run-­‐time  efficiency   2) Security   3) Readability  and  understandability   4) Functionality   5) Ease  of  maintenance   6) Documentation     Code  quality  is  measured  by  WTF/min?     Practices  for  better  quality  code   1) Follow  a  standard     a. Indentation   b. Function  naming   c. Syntax   d. “All  code  in  any  code-­‐base  should  look  like  a  single  person  typed  it,   no  matter  how  many  people  contributed.”   2) Name  well   a. Related  things  should  be  named  similarly.  Unrelated  should  not.   b. Use  nouns  for  classes/variables  and  verbs  for  methods   c. Name  should  be  an  accurate  and  complete  description  of  its  entity   d. Preferable  not  to  have  lengthy  names   e. Correct  spelling  in  names  (and  even  in  comments)   f. If  you  must  abbreviate  or  use  acronyms,  do  it  consistently.  Explain   their  full  meaning  at  an  obvious  location   g. Avoid  misleading  names  –  multiple  meanings,  similar  sounding,   hard  to  read   h. Minimize  using  numbers  or  case  to  distinguish  names     i. Distinguish  between  single  valued  and  multivalued  variables   3) Be  obvious   a. Use  explicit  type  conversion  instead  of  implicit   b. Use  parentheses/braces  to  show  grouping   c. Use  enumerations  when  a  certain  variable  can  only  take  on  a  small   finite  number  of  values   d. Use  appropriate  naming  or  comments  when  functions  or  statements   should  follow  a  particular  order   4) Comment   a. Some  comments  are  wrong   b. Some  comments  will  eventually  be  wrong   c. Self-­‐explanatory  code  works  better  than  having  comments,  so  what   really  is  the  value  of  comments?   d. Good  comments  explain   i. What  the  function  is  supposed  to  do   ii. Why  do  we  call  certain  methods,  purpose  for  doing   something   iii. How  it  is  implemented   e. Avoid  magic  numbers  –  define  a  constant  for  frequently  used   numbers   5) Exploit  abstraction  (SLAP)   6) No  misuse  of  syntax   a. Use  ‘default’  option  of  a  case  statement  for  an  intended  default   action  and  not  just  to  execute  the  last  option.  Same  goes  for  if-­‐else   constructs.  Use  language  constructs  in  the  way  they  are  meant  to  be   used.  Do  not  take  shortcuts.   b. Avoid  dataflow  anomalies  –  using  uninitialized  variable  or  initialize   variables  without  ever  using  that  value   7) Optimize,  if  you  must   8) Avoid  error-­‐prone  practices   9) Minimize  global  variables   10)  Throw  out  garbage   11)  Minimize  duplication   12)  Make  comments  unnecessary   13)  Be  simple   14)  Code  for  humans   a. Avoid  arrowhead  style  code   b. Avoid  long  methods  –  not  more  than  50  lines  of  code  per  function   c. No  more  than  3  levels  of  nesting.   d. Default  path  of  execution  should  be  clear   e. Make  use  of  guard  clauses  to  remove  trivial  or  error  cases  early   i. E.g.  method  foo(int  a)  {   If  (a  ==  null)  return  0   //  non-­‐trivial  code  here   }   15)  Tell  a  good  story   16)  Do  not  release  temporary  code   17)  Sign  your  work  –  write  good  code  so  you  are  proud  enough  to  take   ownership  of  your  work     Single  Level  of  Abstraction  Per  Function  (SLAP)   What   1) In  order  to  make  sure  our  functions  are  doing  “one  thing”,  we  need  to   make  sure  that  the  statements  within  the  function  are  at  the  same  level   of  abstraction.   2) E.g.  public  static  void  main  (String  args[])  {   String  command  =  getCommand(scanner);   String  []  result  =  parseCommand();   String  msg  =  executeCommand(result[0],  result[1]);   printExecutionResult(msg);   }   3) Do  not  mix  high,  intermediate  and  low  level  abstractions  within   the  same  function.      Why  SLAP   1) There  is  a  limit  to  how  much  the  brain  can  process,  it  is  easier  to   understand  smaller  functions  than  bigger  functions   2) Breakdown  big  problems  into  smaller,  manageable  bite-­‐sized  chunks   Why  not  SLAP   1) More  functions  slow  down  the  code?   a. “Prematurely  optimizing  code  is  the  root  of  evil  in  programming”   b. Obscures  the  code   c. The  code  where  you  optimize  may  not  even  be  the  one  that  gets   executed   d. Negligible  improvements  in  performance     Messy  things,  get  messier  fast!  So  we  have  to  clean  up  code!     Refactor  –  cleaning  up  code  by  modifying  it  incrementally  without  modifying   behaviour.         But  refactoring,  may  introduce  regression.  So  perform  a  regression  test  after   refactoring.     Common  techniques   • Consolidate  conditional  expression   • Decompose  conditional   • Inline  method   • Remove  double  negatives   • Replace  magic  number  with  symbolic  constant   • Replace  nested  conditional  with  guard  clauses   • Replace  parameter  with  explicit  methods   • Reverse  conditional   • Split  loop   • Split  temporary  variable     Refer  to  www.refactoring  .com  for  detailed  explanations!     Tutorial  Review  –  CityConnectForRefactoring     Name  variables  consistently   Line  51  –  rename  WELCOME_MESSAGE  to  MESSAGE_WELCOME  to  be  consistent   with  the  rest  of  the  naming  conventions     100   public  static  void  main(String[]  args)  {   101     showToUser(WELCOME_MESSAGE);   102     while  (true)  {   103       System.out.print("Enter  command:");   104       String  command  =  scanner.nextLine();   105       String  userCommand  =  command;   106       String  feedback  =  executeCommand(userCommand);   107       showToUser(feedback);   108     }   109   }     Separate  intent  from  mechanism   Line  103  can  be  refactored  using  a  call  to  showToUser(“Enter  Command:”);     SLAP   Line  104-­‐106  can  be  refactored  into  another  function.  Reason  :  the  3  lines  are  very   low  level  abstraction  code  which  is  not  on  the  same  abstraction  level  as  lines  106   and  107.     In  CS2103,  we  are  training  to  be  Master  Craftsman,  not  code  monkey  or  code   gorilla.     Code  monkey  may  get  good  well  paying  jobs  at  startups.  Their  focus  is  on  writing   code  that  works  and  then  move  on.  However,  when  the  company  gets  big,  they   want  to  move  to  production,  they  will  hire  someone  else  to  do  the  work  for  them.   Thus,  the  code  monkey  will  probably  keep  moving  around  jobs.     Q:  How  much  refactoring  is  enough  refactoring?   A:  When  the  costs  outweigh  the  benefits,  which  depends  on  the  context.     Revision  Control  System     We  are  using  Git  for  CS2103.     Repository  –  folder  containing  all  the  files  and  folder  that  the  RCS  will  track.     Local  –  your  computer     Remote  –  server,  does  not  exist  on  your  computer     GIT  =  Fire  insurance     Unlike  actual  fire  insurance,  we  will  definitely  use  GIT  at  many  points  in  our   project.     What  is  the  defining  feature  of  an  RCS   a) Show  versions  graphically   b) Can  take  snapshots  of  files  and  store  them  in  a  low  cost  manner   c) Can  go  back  to  previous  versions   d) Can  compare  different  versions     Ans:  B,  all  the  rest  are  valid,  but  in  essence,  GIT  is  about  taking  snapshots  of  your   files  and  directories  at  points  in  time         Lecture  3  Part  1  -­‐  Establishing  requirements  –  don’t  assume,   ask!     Brown  field  project  –  a  development  project  which  aims  to  replace  or  update  an   established  software  system     Green-­‐field  project  –  a  totally  new  system  with  no  precedent     2  types  of  requirements:   Functional  Requirements  –  specify  what  the  system  do   Non-­‐functional  requirements  –  specify  the  constraints  under  which  system  is   developed  and  operated,  e.g.   • Data  requirements  –  size,  volatility,  persistency   • Environment  requirements,  technical  environment  in  which  system  would   operate  or  need  to  be  compatible  with   • Accessibility,  capacity,  compliance  with  regulations,  documentation,   disaster  recovery,  efficiency,  extensibility,  fault  tolerance,  interoperability,   maintainability,  privacy,  portability,  quality,  reliability,  response  time,   robustness,  scalability,  security,  stability,  testability,  and  more…     Non-­‐functional  requirements  are  easier  to  miss,  and  extra  effort  should  be  spent   digging  them  out  as  early  as  possible  because  they  are  critical  to  the  success  of  the   software.  An  application  that  has  all  the  right  functionalities  may  not  succeed   because  it  is  too  slow  or  does  not  work  on  certain  operating  system  platforms.     Even  the  most  reasonable  asusmptions  might  be  wrong.     How  to  establish  requirements?     Ask  user:  Survey,  Interviews,  Focus  groups   Invent  yourself:  product  study,  observe  users,  brainstorming,  prototyping  (early   UI  prototyping)     Prototyping  –  A  prototype  is  a  mock  up,  scaled  down  version,  or  a  partial  system   constructed   (a) To  get  users’  feedback   (b) To  validate  a  technical  concept  (proof-­‐of-­‐concept)   (c) To  give  a  preview  of  what  is  to  come,  or  to  compare  multiple  alternatives   on  a  small  scale  before  committing  fully  to  one  alternative   (d)For  early  field-­‐testing  under  controlled  conditions     Early  prototyping  is  a  good  technique  to  uncover  requirements,  especially  how   users  interact  with  the  system.     Sometimes,  the  user  may  not  know  what  they  want.  Consumers  can  only  tell  you   about  the  present,  they  cannot  envision  the  future.     Steve  Jobs  and  Henry  Ford  share  this  view.     SPECIFYING  requirements  (tools  to  specify  requirements,  can  be  used  to   establish  requirements)   1) Feature  lists  –  e..g  Basic  play  –  single  player,  Difficulty  –  medium,  high   2) Textual  descriptions  (  unstructured  text)     3) User  stories  –  As  a  <user  type/role>  I  can  <function>  so  that  <benefit>   a. Can  be  written  at  various  levels.  High  level  –  epics  or  themes  can  be   broken  down  into  multiple  lower  level  user  stories   b. Biggest  difference  between  user  stories  and  traditional   requirements  is  in  the  level  of  detail,  user  stories  –  low  detail   c. Things  that  need  to  be  true  for  user  story  to  be  accepted  as  done  –   conditions,  can  be  specified     4) Use  cases  –  describes  an  interaction  between  the  user  and  the  system  for  a   specific  functionality  of  the  system.     a. Use  case  model  is  a  way  of  capturing  the  functional  requirements  of   a  system.   b. Use  cases  are  a  part  of  the  UML  modeling  notation.   c. A  use  case  can  involve  multiple  actors   d. An  actor  can  be  involved  in  many  use  cases   e. A  single  person/system  can  play  many  roles   f. Many  persons/systems  can  play  a  single  role   g. Formal  definition–  a  description  of  a  set  of  sequences  of  actions,   including  variants,  that  a  system  performs  to  yield  an  observable   result  of  value  to  an  actor.     h. The  flow  of  events  is  a  sequence  of  steps  that  describes  the   interaction  between  the  system  and  the  Actors  for  a  use  case.  Each   step  is  given  as  a  simple  statement.   i. Every  step  should  clearly  show  who  does  what,  gives  the  intention   but  not  the  mechanics.  UI  details  should  be  omitted.   5) Functional  prototypes   6) Glossary   a. Definition  of  important  terms  because  some  terms  may  mean   different  things  to  different  people   7) Supplementary  requirements   a. Business/domain  rules  –  e.g.  size  of  minefield  cannot  be  smaller   than  five   b. Constraints  –  the  system  should  be  backward  compatible   c. Technical  requirements  –  32  bit  and  64  bit  environments   d. Performance  requirements  –  system  should  respond  within  2  secs   e. Quality  requirements  –  e.g.  system  should  be  usable  by  a  novice  who   has  never  carried  out  an  online  purchase   f. Process  requirements  –  adhere  to  a  schedule   g. Notes  about  project  scope  –  the  product  is  not  required  to  handle   the  printing  of  reports.     Example  of  use  case  specification:     System:  Online  Banking  System  (OBS)   Use  case:  UC23  –  Transfer  money   Actor:  Customer   Preconditions:  User  is  logged  in  (specify  the  state  we  expect  the  system  to  be  in)   Guarantees  –  specify  what  the  use  case  promises  to  give  us  at  the  end   Main  success  scenario:    (A  series  of  user  interaction  with  the  software  to  get  to  the   end  success  scenario,  assumes  all  inputs  are  correct  and  ignores  problems  such  as   timeout,  network  outage  etc.)     1) User  chooses  to  transfer  money   2) OBS  requests  for  details  of  the  transfer   3) User  performs  enter  transaction  details  (another  use  case)   a. OBS  detects  an  error  for  the  entered  data   b. OBS  requests  for  new  data   4) OBS  requests  for  confirmation     5) User  confirms  transfer   6) OBS  transfers  the  money  and  displays  status   7) Use  case  ends     Highlighted  in  RED  is  an  extension  –  another  use  case.  Add-­‐ons  to  the  MSS.   Exceptional  flow  of  events,  or  alternative  flow  of  events.    Extensions  should   be  given  below  the  MSS.  An  *  is  used  to  denote  extension  that  can  happen  at   any  time.       A  use  case  can  include  another  use  case.  Underlined  text  is  commonly  used   to  show  an  inclusion  of  a  use  case.  Inclusions  are  useful     • When  you  don’t  want  to  clutter  a  use  case  with  too  many  low  levels   • When  a  set  of  steps  is  repeated  in  multiple  use  cases.  (like  refactoring   code)     Use  case  diagrams  can  help  to  give  an  overview  of  a  set  of  use  cases  (like  a   graphical  table  of  contents  for  use  cases)    Refer  to  Notes  on  SE  –  an   incremental  approach  in  IVLE  for  diagram)     Writing  better  requirements    -­‐  characteristics  of  well-­‐defined  requirements     • Unambiguous   • Testable  (verifiable)   • Clear  (concise,  terse,  simple,  precise)   • Correct   • Understandable   • Feasible   • Independent   • Atomic   • Necessary   • Implementation-­‐free  (abstract)     The  set  of  requirements  as  a  whole  should  be   • Consistent   • Non-­‐redundant   • Complete   Q.  When  specifying  a  drawing  software  for  a  novel  gesture  based  device,  which  of   these  is  the  most  useful?     a) UI  prototypes   b) User  stories   c) Use  cases   d) Textual  descriptions   Ans:  A,  most  useful  when  you  want  to  convey  a  gesture  based  product         Lecture  3  Part  2  –  From  the  Magician’s  Hat:  Designing  the   Product     Product  design  –  the  design  of  a  software  solution  that  meets  the   requirements  identified  above.     Why  is  it  important  –  Even  though  programmers  are  only  required  to  just   implement  a  given  specification,  the  products  they  built  are  used  by  others.  It   is  important  to  spend  effort  in  designing  the  product  to  solve  the  users’   problem  in  the  most  optimal  way,  not  just  in  a  way  that  is  ‘cool’,  ‘interesting’  or   convenient  to  the  designer.     Guidelines   • Have  a  vision   • Put  vision  before  features   • Focus  features   • Focus  users   • Get  early  feedback   • Gently  exceed  expectations   • Design  the  UI  for  the  user   • Usability  is  king   o Presentable   o Minimize  work  for  users   o Minimize  change  of  user  errors   o Minimize  irreversible  actions   o Provide  way  to  recover  from  mistakes  and  errors   o Minimize  frequent  switching  between  mouse  and  keyboard   o Within  the  UI,  use  terms  that  users  can  understand   o Make  common  tasks  easy,  rare  tasks  possible   o Make  the  UI  consistent  –  have  1  person  to  design  the  whole  UI   o Should  not  leave  the  user  wondering  about  the  current  system   status   o Minimize  things  that  user  have  to  remember   o User  should  not  have  to  read  manual  to  use  the  product   o Put  yourself  in  the  user’s  shoes.   • Be  different,  if  you  must   • Name  it  well   o Convey  what  your  product  is,  and  its  strengths   o Make  sense  to  your  target  market,  not  just  you   o Check  if  there  is  already  another  product  by  that  name.   o Check  if  it  fits  well  into  a  web  domain  name  and  that  the  name  is   still  available   o Be  careful  of  using  team  member  initials  to  form  a  product  name   o Be  wary  of  difficult  to  spell,  hard  to  pronounce  names,  inside   jokes  or  alterations  of  existing  names,  they  don’t  mean  anything   to  the  users   o Be  aware  that  names  starting  with  ‘Z’  will  end  up  at  the  bottom   of  any  alphabetical  listing.       10  Observations  about  Product  Design   1) Anything  that  goes  into  the  software  must  add  value  to  the  user   2) Minimize  work  for  users   3) Match  user  intent   4) Less  is  more   5) Make  users  productive  within  minutes  of  first  contact   6) Don’t  force  to  RTFM  (read  the  f**king  manual)   7) Don’t  make  users  feel  stupid   8) Be  everything  to  somebody   9) Visualize  usage   10)Care   a. Software  can  be  bug-­‐free,  quality,  etc.  but  all  of  that  does  not  matter   when  the  user  does  not  like  the  product.       Lecture  4  Part  1  –  View  from  the  Top:  Architecture     Architecture  –  High  –  level  structure  +  technical  descisions   • Addresses  the  big  picture   • Shows  overall  organization  of  the  system,  high-­‐level  design   • Set  of  interacting  components  that  fit  together  to  achieve  the  required   functionality   • Should  be  simple  and  technically  viable   • Well-­‐understood  and  agreed-­‐upon  by  everyone  in  the  team   • Forms  the  basis  for  implementation     Technical  decisions  are  important  decisions  like  programming  language,   framework  to  use,  database  to  use  if  any?     What  will  be  covered  in  this  lecture?   How  to  break?   How  to  define/communicate  between  components?   1) Application  programming  interfaces  (APIs)  –  methods  required  within   each  component  to  help  achieve  all  the  user  stories   2) Define  APIs  systematically  to  match  features  starting  from  the  UI  and   moving  on  to  each  components  until  all  the  required  APIs  are  figured   out   When  to  move  on?   1) Depends  on  which  camp  you  are  in?  Agile  or  full-­‐design   2) Agile  approach  believes  you  should  move  fast  and  code  fast,  and  come   back  to  the  architecture  design  afterwards,  for  as  many  times  you  want.   3) Full-­‐design  –  think  out  everything  first  before  moving  on  to  code     What  next?   1) Move  on  and  develop  each  component  in  parallel   2) For  each  component,  you  may  need  to  break  it  down  into  smaller   components,  so  repeat  the  whole  process  again,  until  you  get  to   something  small  enough  that  you  can  start  coding.  This  is  the   recommended  approach  for  CS2103.  (Top  down  approach)     3) Bottom  up  approach  –  think  of  what  you  have  and  put  them  together  in   a  bottom  up  fashion.  Usually  used  for  small  product  or  when  developing   a  variant  of  an  existing  product  where  you  have  most  of  the  reusable   components  already.  Most  of  the  time,  we  have  been  using  bottom  up   approach.     Who  gets  to  decide?  The  software  architect,  who  provides  the  technical  vision  of   the  system  and  makes  high-­‐level  technical  decisions  on  the  project.  Needs  at  least   10-­‐15  years  of  experience,  not  easy.  Much  higher  paid  than  software  engineers.     Architecture  is  described  by  architecture  diagrams   • Free-­‐form  diagrams,  no  universally  adopted  standard  notation   • Indiscriminate  use  of  double-­‐headed  arrows  to  show  interactions  between   components  should  be  avoided   • Single  arrow  with  dotted  lines  should  be  used  to  denote  dependency   among  components   • Use  arrows  of  different  styles  to  indicate  different  meaning     Types  of  software  architecture  styles   1) N-­‐tier   a. Higher  layers  make  use  of  services  provided  by  lower  layers.  Lower   layers  are  independent  of  higher  layers.  Eg.  OSI  model  in  computer   network  communcations,  operating  systems.   2) Client-­‐server   a. For  distributed  applications.  Presence  of  at  least  one  component   playing  the  role  of  a  server,  with  at  least  one  client  component   accessing  the  services  of  the  server.   3) Transaction  processing   a. Workload  of  a  system  is  broken  down  into  numerous  transactions   which  are  then  given  to  a  “dispatcher”  that  controls  the  execution  of   each  transaction.   4) Service-­‐oriented  (SOA)   a. Relatively  recent  for  distributed  applications.  Combined   functionalities  packaged  as  programmatically  accessible  services.  It   is  designed  so  that  service  users  can  use  the  services  even  though   their  systems  may  be  implemented  using  different  programming   languages.  A  common  way  to  implement  SOA  is  through  XML  web   services  where  web  is  medium  for  services  to  interact  and  XML  is   used  as  communication  language.   5) Event-­‐driven  architectural  style   a. Event  is  a  notable  occurrence  that  happens  inside  or  outside  the   software.  Events  are  detected  and  communicated  to  affected   components,  which  then  react  appropriately,  often  used  in  GUIs.                6)  Others  –  pipes-­‐and-­‐filters,  broker,  peer-­‐to-­‐peer,  message-­‐oriented  etc.     APIs  –  architecture  diagrams  do  not  describe  how  components  communicate  with   each  other.  The  application  programming  interface  (API)  is  a  list  of  public   operations  supported  by  a  component  and  what  each  operation  does.  They  are   required  so  that  each  component  can  work  with  each  other  to  achieve  the   functionality  of  the  system.    It  should  be  well  designed  and  well  documented.       UML  Sequence  diagrams  –  diagram  that  captures  interactions  between   components  for  a  given  scenario.  Can  be  used  to  discover  APIs  for   components.     1. Activation  bar  –  a  bar  to  show  when  the  component  is  actively   processing  a  user  request   2. Entities  –  actors  or  components  involved  in  the  interaction   3. Lifeline  :  shows  that  the  instance  is  still  alive   4. Loops  are  drawn  by  drawing  a  big  box  around  the  actions,  a  box   on  the  top  left  hand  corner  labeled  “loop”  and  the  condition  in   next  to  the  label  –  e.g.  until  won  or  lost   5. Notation  <componentName>  :  <componentClass>  means  the   name  of  the  instance  before  the  colon,  and  the  class  name  of  the   component  after  the  colon.   6. Draw  arrows  from  one  component  to  the  next,  dotted  for  return   arrows,  solid  for  calling  methods.  The  method  to  call  or  the   specific  action  to  be  performed  is  labeled  on  top  of  the  arrow.   7. Time  goes  in  chronological  order  from  top  to  bottom   8. “sd”  stands  for  sequence  diagram.  UML  notation  for  labeling  a   sequence  diagram.   9. A  box  with  label  “ref”  in  the  top  left  hand  corner  is  a  way  to  use  a   ref  frame  to  allow  a  segment  of  the  interaction  to  be  omitted  and   detailed  in  another  diagram.     10. Activation  bars  and  return  arrows  may  be  omitted  if  they  do  not   result  in  ambiguities  or  loss  of  information.             Lecture  4  Part  2  –  Unit  Testing     Costs  of  fixing  software  bugs  increases  exponentially  in  later  stages  of   development.  Why?   1) At  deployment  stage,  there  might  be  need  to  recall,  higher  costs   2) There  are  penalties  to  pay  after  the  deadline     It  is  way  easier  to  catch  the  bugs  when  it  is  in  a  small  component  than  to  catch   them  when  there  are  integrated  into  a  big  system.     Why  unit  testing?  For  each  component,  you  do  not  have  a  UI  yet  to  test,  so  unless   you  want  to  wait  for  the  UI  to  be  ready,  you  have  to  use  unit  test.     How  to  do  unit  testing?     Replace  the  UI  with  Test  Driver  –  it  is  going  to  use  your  System  under  Test  (SUT).   Replace  the  storage/data  with  a  stub  (dummy  data),  which  is  so  simple  that  it   cannot  have  bugs  in  it.     Testing  frameworks  –  provides  methods  to  conveniently  test  methods.     e.g.  assertEquals(“desc  of  test  case”,  output,  expected  output);     assertEquals()  takes  the  output  from  your  SUT  and  checks  it  against  the  expected   output,  prints  something  when  failed.       IDE  have  built-­‐in  features  to  automatically  generate  unit-­‐testing  skeletons.     After  unit  testing,  have  to  do  integrated  testing  when  multiple  components  are  put   together  because  each  component  was  tested  based  on  your  idea  of  what  the   component  is  supposed  to  do.       When  to  do  testing?     Kent  Beck  –  Test-­‐Driven  Development  (TDD)  :  Write  the  test  cases  before  you  start   coding.  Why?       Rules   1) Do  not  start  to  write  code  until  you  have  a  failing  test   2) Do  not  write  more  test  cases  than  is  necessary  to  fail     3) Do  not  write  more  code  than  is  enough  to  pass  all  test  cases     For  your  project,  System  testing,  integrated  testing  and  automated  Unit  testing  are   required.  TDD  is  encouraged.       Lecture  5  –  Object  Oriented  Programming  (I)  e -­‐learning     Class  diagrams  –  UML  class  diagrams  describe  structure  (but  not  behaviour)  of   an  OO  program.    Attributes  represent  the  data  of  the  class  (top  half  of  the   diagram),  methods  represent  the  operation  (behaviour),  bottom  half  of  the   diagram.  Both  compartments  may  be  omitted  if  they  are  not  important  for  the  task   at  hand.     Visibility    notation   • +  for  public   • -­‐  for  private   • #  protected   • ~  package     Associations  –  objects  interact  with  one  another.  These  are  represented  as   connections  or  associations,  denoted  as  a  line  between  2  classes  in  UML  class   diagram.  A  link  may  be  permanent  or  semi-­‐permanent.  Associations  are  not  used   for  temporary  links  between  classes.  Role  labels  can  be  optionally  used  to  indicate   the  role  played  by  the  classes  in  the  association.     Association  labels  are  used  to  describe  the  association.  E.g.  Class  Admin  uses  >   Class  Student.  The  arrowhead  indicates  the  direction  of  relationship.     Multiplicity  –  number  of  objects  of  a  class  that  participate  in  the  association.     • 0…1  :  optional.  Can  be  linked  to  0  or  1  objects   • 1  :  must  be  linked  to  1  at  all  time   • *  :  0  or  more   • n…m  :  can  be  linked  to  between  n,  m  inclusive   • Place  this  notation  beside  Class  A,  means  how  many  objects  of  A  is   associated  with  ONE  of  B.     UML  notes  and  constraints  –  UML  notes  are  used  to  enhance  a  UML  diagram   with  additional  information.  They  can  be  connected  to  a  particular  element  in  the   diagram  or  standalone.  It  can  be  used  to  specify  a  constraint,  within  curly   brackets.     Navigability  –  denoted  by  arrowhead  in  the  association  link.  Indicates  whether  a   class  involved  in  an  association  is  “aware”  of  the  other  class.  In  code,  it  implies   how  objects  are  referenced.  Example  :  A  -­‐>  B.  A  is  aware  of  B.  There  is  a  reference   to  B  in  the  code  of  A.  But  not  the  other  way  round.  Arrows  can  be  unidirectional  or   bidirectional.       Associations  as  attributes  –  an  attribute  can  be  sometimes  used  to  represent  an   association.    Association  of  multiplicities  of  2  or  more  can  be  represented  using  a   Collection  object  attribute  –  e.g.  ArrayList<Class>  or  HashMap<Class>  or  Array     Enumerations  –  an  <<enumeration>>  is  used  to  indicate  that  an  attribute  can   only  take  on  a  fixed  set  of  values.     Object  diagrams  –  Sometimes  it  is  useful  to  show  objects  instead  of  classes.   Object  diagrams  show  an  object  structure  a  point  in  time  while  class  diagram   represents  the  general  situation.     • Notation  –  instance  name:  class  name   • Association  links,  most  attributes,  methods  and  some  object  names  are   omitted     Conclusion   OO  design  paradigm  can  be  used  to  work  out  the  classes  required  and  the  internal   APIs  of  each  class,  after    APIs  of  main  components  are  discovered.  This  process   (discovering  class  structure  and  behaviour)  is  one  of  the  most  difficult  areas  of   Object-­‐oriented  development.       Lecture  6  –  Advanced  OO  Concepts     Important  concepts  in  Object  oriented  programming   1) Encapsulation   a. Related  data,  variables  and  function  should  be  grouped  together   b. Classify  data  according  to  visibility  –  public  and  private.  Only  APIs   which  can  be  used  by  other  classes  should  be  public,  the  private   variables  and  method  should  not  be  visible.   2) Abstraction   a. Reveal  functionalities  that  the  public  should  know,  but  hide   implementation  details.   3) Inheritance   a. Objects  with  similar  behavior  can  inherit  from  a  parent  class  and   then  modified.     4) Polymorphism   a. Ability  to  process  objects  differently  depending  on  their  class  or   datatype  -­‐  redefine  methods  for  derived  classes     Class  diagram  describes  the  object-­‐oriented  properties  and  attributes  of  class,  for   our  project  should  be   1) Top-­‐down   2) Hierarchical     Association  classes   Student  -­‐>  (borrows)  book  v.s.  Student  <-­‐  (borrowed  by)  book..  The  arrow  is  an   association  label.  Association  classes  are  objects  associated  with  the  association   labels.  E.g.  The  Loan  object  should  be  associated  with  the  act  of  student  borrowing   a  book,  hence,  an  association  class,  with  a  data  called  returnDate  is  required.  They   are  denoted  as  a  connection  to  an  association  link  using  a  dashed  line.       Composition  –  represented  by  solid  diamond  right  next  to  the  whole.    Whole-­‐part   relationship.  When  the  ‘whole’  is  destroyed,  ‘parts’  are  destroyed  as  well.  Implies   that  there  cannot  be  cyclical  links.     Aggregation  –  represented  by  hollow  diamond.  Container-­‐containee  relationship.   Martin  Fowler  advocate  not  using  the  aggregation  symbol  because  it  adds  more   confusion  than  clarity.     Class  level  data  –  static  variables.  v.s.  Instance  variables.  Example,  a  student  class   has  the  static  variable  –  totalStudents,  while  studentName  would  be  an  instance   variable.  Get  it  by  calling  Student.getTotalStudents()     Dependency  Injection  –During  developer  testing,  replacing  the  collaboration   objects  with  test-­‐friendly  objects  such  as  stubs  or  mock  objects.  Example:  replace   the  Storage  object  by  a  StorageStub  (  an  imitation  of  the  actual  Storage).  Can   exploit  inheritance  and  polymorphism  by  writing  a  new  StorageStub  class,  which   extends  Storage  and  override  methods  that  will  be  called  in  the  parent  class,  which   responds  with  hardcoded  values  for  testing  purposes.     Polymorphism  –  ability  to  treat  different  types  as  same  type  and  yet  get  different   behaviour.  OR  ability  to  be  treated  as  different  types  and  still  maintain  own   behaviour.  Implemented  by  inheritance,  generics,  method  overloading  and   overriding  in  Java.     Inheritance  –  represented  by  a  “is  a  “  relationship  in  class  diagrams.  Can  be  used   to  implement  polymorphism.  Can  have  infinitely  many  levels  of  nested   inheritance.  Denoted  by  a  hollow  arrow  (  subtype  A  -­‐>  type  B).  Code  reuse  is  a   benefit  of  inheritance.     Substitutability  –  Every  instance  of  a  subclass  is  an  instance  of  the  superclass,  but   not  vice  versa.  Whenever  an  object  of  superclass  is  expected,  an  object  of  any  of  its   subclasses  can  substitute  it.  To  preserve  substitutability,  sub  classes  should  not   impose  conditions  that  are  more  restrictive  than  the  super  class.  Java  does  not   impose  substitutability,  it  is  up  to  the  programmer.     Method  overloading  –  when  there  are  multiple  operations  with  the  same  name   but  different  type  signatures.  An  operation  can  be  overloaded  within  same  class,   or  in  sub/super  classes.  It  is  resolved  at  compile  time.     Method  Overriding  –  when  a  subclass  redefines  an  operation  using  same  method   name  and  same  type  signature  that  is  already  present  in  the  parent  class,  it  is   called  method  overriding.  It  is  resolved  at  runtime,  when  the  type  of  the  object  can   be  determined.     Dynamic  binding  –  Overridden  operations  are  resolved  at  runtime.  During  run-­‐ time,  bind  the  actual  method  call  to  matching  method  declaration  along  the  class   hierarchy,  starting  from  the  very  bottom.     Abstract  classes/operations  -­‐  When  you  have  at  least  1  abstract  method  in  your   class,  i.e.  no  implementation  detail,  no  method  body  {},  the  class  becomes  abstract   and  no  object  instances  can  be  created  from  it.  In  Java,  denote  by  adding  abstract   keyword  –  abstract  public  class  A  {}.  A  subclass  should  implement  all  abstract   methods  of  all  its  super  classes,  otherwise,  declare  itself  as  abstract.  In  UML,  italics   (className)  or  the  ‘{abstract}’  label  is  used  to  indicate  abstract  classes.     Multiple  Inheritance  –  Multiple  inheritance  from  many  parent  classes  is  allowed   for  C++  but  not  for  Java.  The  Java  interface  construct  can  be  used  to  achieve  a   similar  effect.     Interface  –  it  is  a  behavior  specification.  In  code,  every  method  is  abstract  –  the   interface  is  a  class  that  has  no  implementations.  In  Java,  a  class  can  be  explicitly   declared  as  an  interface  –  (public  interface  MyInterface  {}).  In  C++,  a  fully  abstract   class  can  be  used.  In  UML,  use  the  keyword  <<interface>>  next  to  the  class  name.  A   class  implements  the  interface  if  all  methods  specified  in  the  interface  and   implemented  in  the  class.  In  UML,  use  a  dashed  line  with  the  hollow  triangle   similar  to  the  one  used  for  inheritance.  Java  allows  multiple  inheritance  among   interfaces,  also  allows  a  class  to  implement  multiple  interfaces.  If  a  class  C   implements  interface  I,  C  can  be  treated  as  a  subtype  of  I  –  C  is  substitutable   wherever  I  is  expected.         Lecture  6  Part  2  -­‐  How  to  avoid  the  Big  Bang  –  integrating   software  components  together     ‘Late  and  1  time’  vs  ‘Early  and  frequent’?     Late  and  1  time   • Developers  wait  till  all  components  are  completed  and  integrate  all  finished   components  just  before  the  release.   • This  is  not  recommended  because  integration  often  causes  many   component  incompatibilities  to  surface,  leading  to  delivery  delays.     Early  and  frequent   • Integrate  early  and  evolve  in  parallel  in  small  steps,  re-­‐integrating   frequently.     • One  developer  can  write  a  working  skeleton,  then  each  developer  can  add   one  feature  at  a  time,  after  each  feature  is  done,  simply  integrate  the  new   code  into  the  main  system.     Avoid  Late  and  one  time  integration,  use  Continuous  Integration  (CI)     There  is  also  a  need  to  decide  the  order  in  which  to  integrate  components     Big-­‐Bang  Integration   • All  components  are  integrated  at  the  same  time.   • Not  recommended  because  it  will  uncover  too  many  problems  at  the  same   time  which  could  make  debugging  and  bug-­‐fixing  too  complex.     Incremental  integration   • Top-­‐down  integration  –  higher  level  components  are  integrated  first.   Advantage  is  that  higher  level  problems  can  be  discovered  first.   Disadvantage  is  this  requires  dummy  components  in  the  lower  levels   because  high  level  parts  depend  on  the  lower  ones.   • Bottom-­‐up  integration,  advantages  and  disadvantages  are  reversed.   • Sandwich  integration  –  mix  of  top  down  and  bottom  up.  The  idea  is  to  do   both  and  meet  in  the  middle     Integrate   1) Incrementally   2) Early   3) Frequently   4) NOT  Big  Bang       Use  Revision  Control  Systems  (RCS)  as  a  CI  tool.       Concepts   • Clone  –  creates  a  copy  of  a  repo.  A  local  repo  can  be  created  by  cloning  a   remote  repo   • Push  –  uploads  the  revision  history  to  a  remote  repo.   • Pull  –  downloads  the  revision  history  from  another  repo.   • Branch  –  evolving  multiple  versions  of  the  software  in  parallel   • Merging  A  into  B–  bringing  commits  from  a  different  revision  history   (branch  A)  into  branch  B.  Typically  used  when  Branch  A  is  stable  and  ready   to  be  merged  into  a  larger,  stable  branch  like  testing,  staging  or  master.     Models  of  RCS   • Centralized  RCS  –  a  central  remote  repo  is  shared  by  the  team.  Team   members  download  ‘pull’  and  upload  ‘push’  changes  between  their  local   repo  to  the  remote  repo.  Older  tools  like  CVS  and  SVN  support  only  th


Buy Material

Are you sure you want to buy this material for

50 Karma

Buy Material

BOOM! Enjoy Your Free Notes!

We've added these Notes to your profile, click here to view them now.


You're already Subscribed!

Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'

Why people love StudySoup

Jim McGreen Ohio University

"Knowing I can count on the Elite Notetaker in my class allows me to focus on what the professor is saying instead of just scribbling notes the whole time and falling behind."

Allison Fischer University of Alabama

"I signed up to be an Elite Notetaker with 2 of my sorority sisters this semester. We just posted our notes weekly and were each making over $600 per month. I LOVE StudySoup!"

Bentley McCaw University of Florida

"I was shooting for a perfect 4.0 GPA this semester. Having StudySoup as a study aid was critical to helping me achieve my goal...and I nailed it!"

Parker Thompson 500 Startups

"It's a great way for students to improve their educational experience and it seemed like a product that everybody wants, so all the people participating are winning."

Become an Elite Notetaker and start selling your notes online!

Refund Policy


All subscriptions to StudySoup are paid in full at the time of subscribing. To change your credit card information or to cancel your subscription, go to "Edit Settings". All credit card information will be available there. If you should decide to cancel your subscription, it will continue to be valid until the next payment period, as all payments for the current period were made in advance. For special circumstances, please email


StudySoup has more than 1 million course-specific study resources to help students study smarter. If you’re having trouble finding what you’re looking for, our customer support team can help you find what you need! Feel free to contact them here:

Recurring Subscriptions: If you have canceled your recurring subscription on the day of renewal and have not downloaded any documents, you may request a refund by submitting an email to

Satisfaction Guarantee: If you’re not satisfied with your subscription, you can contact us for further help. Contact must be made within 3 business days of your subscription purchase and your refund request will be subject for review.

Please Note: Refunds can never be provided more than 30 days after the initial purchase date regardless of your activity on the site.