CS2103/CS2103T Exam Notes!

Main Success Scenario, describes the straightforward interaction for a given case.

Figuring out requirements:!

User Story
Brief description of what the system can do for the users written in the customers language.

! ! ! !

Extensions suggests alternative flow of events which are not expected by the MSS. Inclusion of another use case: underline text and refer to the use case number. E.g. 1. Staff creates survey (UC44) Include precondition to specify the state that the system is supposed to be in before the use case. Include guarantees to specify the state that the system promises at the end of operation. Possible extensions to consider: a) Internet connection goes down b) Session timeout c) Invalid data entered d) Data is being edited simultaneously

E.g. Students can download files uploaded by lecturers. A tutor can generate attendance sheets for printing.

Use Case
Describes the interaction between the user and the system for a specific functionality.

! ! !

E.g.! System: Online Banking System (OBS) ! Use case: UC23 - Transfer Money ! Actor: User" MSS:! 1. User chooses to transfer money." 2. OBS requests for details of the transfer." 3. User enters the requested details." 4. OBS requests for conrmation." 5. User conrms transfer." 6. OBS transfers money and displays the new account balance.! Use case ends. !

Use Case Diagram

Provides an overview of a set of use cases.

! ! ! ! !

Extensions:! 3a. OBS detects an error in the entered data. ! 3a1. OBS requests for the correct data. ! 3a2. User enters new data.! Steps 3a1-3a2 are repeated until the data entered are correct. Use case resumes from step 4.! 3b. User requests to effect the transfer in a future date. ! 3b1. OBS requests for conrmation." 3b2. User conrms future transfer." Use case ends.! *a. At any time, User chooses to cancel the transfer ! *a1. OBS requests to conrm the cancellation ! *a2. User conrms the cancellation" Use case ends.! *b. At any time, 120 seconds lapse without any input from the User ! *b1. OBS cancels the transfer! *b2. OBS informs the User of the cancellation ! Use case ends.MSS:!

<<extend>> is used to capture extensions to use cases. Try not to set System as an actor.

! !

Architecture!
Components and API
Interface refers to the list of public operations supported by a component. Interface of a component is called API. We can model interactions between multiple components using Sequence Diagram. Thereafter, we can discover which methods should be included in the API.

E.g. Mark/clear operations in Minesweeper

Page 1 # of 6 #

Cohesion: Measure of how strongly related and focused are the various responsibilities of a component.

Object Oriented Design!

Class Diagram
Describe the structure of an OO solution. Notation to show a class:

! To indicate optional interaction, we can sue the opt frame (similar to the loop frame) which includes the conditional. Same thing can be done for parallel frame (denoted by par, frame is partitioned into 2 halves). We can add an activation bar to indicate the constructor being called. We can also put a cross at the end of the lifeline to indicate object deletion. E.g.

! Visibility: +public -private #protected ~package Association: Use labels to show the role played by the class, the association of the class or the multiplicity of the class. Note that we can use attributes to indicate association too. Association classes: Used to store additional information about an association. In Java, there is no special way to implement association classes. E.g.

! Can use the following notation to indicate concurrent operation. ! Multiplicities: n..m denotes n to m objects inclusive, m means must be linked to m objects, * means no restriction. UML Notes and Constraints: Use notes to denote comments. Can also be used to indicate constraint and constraint should be written in curly braces. Navigability: Draw an arrow from one class to another, indicate that the class is aware of the content of the other class. Can be bidirectional. Dependency link should be in dotted line. Association link already implies dependency so no need to draw a link. Enumeration: Indicate a fixed set of values

Coupling and Cohesion

Coupling: Degree to which components are dependent on each other.

! Page 2 # of 6 #

Composition: Used to show an association that represents a whole-part relationship. When whole is destroyed, parts are also destroyed. Draw a solid diamond at the whole class at the end of the link.

Note that object names are underlined, and written in the format name:class. Can have labels on object diagrams, should use together with class diagram.

Inheritance: Used to show is a relationship.

Integration!
Integration Strategies
Big bang: All together

! Polymorphism: Treat different types of objects as a single general type yet get different kinds of behaviour from those objects.

Top-down: High level to low level, discover high level problems early but needs a lot of stubs Bottom-up: Reverse of top-down Sandwich: Combination of both bottom-up and top-down

! ! ! ! ! ! !

Substitutability: When an object from a class is expected, we can substitute an object of its subclass. Operation overriding: Specialisation of subclasses, subclasses may add members which are not in the superclass, or redefine methods in the superclass. Dynamic binding: Call the method of the object first before calling the method in superclass at runtime. Abstract classes: Classes without full implementation, cannot be instantiated E.g.
public abstract class Staff {! String name;! int salary;! public abstract void adjustMySalary(int byPercent); }!

Error Handling!
Assertions
Assertions are used to confirm your assumptions about the program state. Program will crash if exceptions are enabled, so it is more useful for developer. E.g.
int count = storage.getCount();! assert count >= 0;! count++;

Exceptions
Exceptions are used to deal with unusual but not unexpected situations. Expects unusual behaviour from the client or other situations (slow network, etc). E.g.
void processInput(String input[]){! try{! System.out.println(input[count]);! } catch (ArrayIndexOutOfBoundsException e) {! System.out.println(Out of bounds!);! }! }

Interface: Behaviour specification. Use the keyword <<interface>> to denote interface in class diagram. Use dotted lines to denote implementation. Dependency Injection: Replacing dependencies using stubs for testing. Can use inheritance to achieve polymorphism.

Object Diagram
Shows an object structure at a given point in time. E.g.

Logging
Useful for logging system information to learn more about what is wrong. e.g.!
import java.util.logging.*;! public class Foo {! private static Logger log = Logger.getLogger(Foo);! public void bar() {!

Page 3 # of 6 #

log.log(Level.INFO, test);! if(1 / 0 == 1) log.log(Level.WARNING, WAT!);! }! }!

Command
Context: A system has to execute many commands Solution:

Defensive Programming
Prevent things from going wrong using the following approaches: 1-to-1 association: Either throw an error when the object is null, or create a new association when the object is constructed Referential integrity: Happens when one object refers to another object but the other object is referring to a different object. Need to break any existing references first when we set new references. !

Model-View-Controller
Problem: Reduce the coupling in supporting storage, display and modification. Solution: Separate into 3 components: 1. Model: Stores and maintain data, update view if necessary. 2. View: Displays data, interacts with user, pulls data from model if necessary. 3. Controller: Detects UI events, updates the model if necessary.

Patterns!
Abstraction-Occurrence
Context: Group of similar entities that appear to be the occurrence of the same thing but are different. Solution: Create separate abstraction and occurrence classes. Abstraction stores common information while occurrence stores unique information. E.g. Library book duplication problem. Can use a class to abstract book title and another class to store unique serial numbers.

Observer
Problem: An object wants to get notified when another object is changed without coupling. Solution:

Singleton
Context: Want to limit the number of instantiated objects to 1 Solution: Use private constructor

! <<Observable>> maintains a list of <<observer>> objects. When there is a change to the observable object, it will call the notifyObservers method that will call the update method of each observer.

Principles
Separation of concerns: A program should be separated into different modules that tackles different concerns such as a feature or a functionality. Open-close principle: A module should be open for extension but closed for modification. Example is to use interface so that the program can be extended by adding a new class of the interface.

Facade
Context: To allow access to components without exposing internal details Solution: Create a facade class that accesses the internal components using its API.

Page 4 # of 6 #

Law of Demeter: An object should have limited knowledge of another object. It should also only interact with objects which are close to it. More concretely, an object should only invoke methods from the object itself, objects passes as the parameters of its methods, object instantiated by its methods and objects from its direct association. Liskov substitution principle: Subclasses should be substitutable Single responsibility principle: Every class should have a single responsibility. Brooks law: Adding people to a late project will make it later. The later you find a bug, the more costly it is to fix. Good, cheap, fast. Select any two.

Test Case Design

Equivalence partitioning: Divide inputs into groups which are likely to be processed the same way by the Software Under Test (SUT). Boundary value analysis: Test the values around the boundaries of the equivalence partition Combining multiple inputs: We can use the at least once heuristics where we design test cases such that every value of the input is considered at least once. Invalid input are tested in different cases. Links between the inputs can also further increase the number of test cases. We can also use the all pairs heuristics that test pairs of parameters. Use case testing: Test based on use case.

! Quality Assurance! !
Unit Testing

Software Development Life Cycle!

Basic SDLC Process Models
Sequential model: Linear process. Not recommended because the project is rarely well understood at the beginning phases.

Validation: Checking that the right system is built. Verification: Checking that the system is built correctly.

Unit testing is the testing of individual units. We can use JUnit as an automated test driver. E.g.
public class JUnitPayrollAtd {! @Test! public void testTotalSalary() {! Payroll p = new Payroll();! p.setSalaryManager(new SalaryManagerStub()); ! // test case 1! p.setEmployees(new String[] { "E001", "E002" });! assertEquals(p.totalSalary(), 6400);! // test case 2! p.setEmployees(new String[] { "E001" });! assertEquals(p.totalSalary(), 2300);! // more tests! System.out.println("All tests passed");! }! }!

! Iterative model: Have several iterations that potentially go through all development stages. It can take a breadth first approach that evolves all components together, or a depth first approach that fleshes out component by component.

Test Coverage
Function/method coverage: Number of functions executed Statement coverage: Number of lines executed Decision/branch coverage: In terms of decision points Condition coverage: In terms of boolean subexpressions Path coverage: In terms of possible paths !

!
Page 5 # of 6 #

Popular Models
Unified process: Four phases: Inception (understand the problem), Elaboration (refine and plan high level design), Construction and Transition (ready the system for actual use) Extreme programming: Deliver the software you need as you need it. Emphasises teamwork, aims to improve software in 5 different ways: communication, simplicity, feedback, respect and courage. Pair programming, CRC cards, project velocity and standup meeting are related to XP. Scrum: Project is divided into sprints. Product owner inform the team about the product backlog for the sprint. Sprint must end on time and no one is allowed to change the backlog.

Models!
Activity Diagram
Used to model a workflow. Use a rake symbol to denote that an action is described in another subsidiary diagram elsewhere. E.g. For snakes and ladders,

!
Platform, Frameworks and Libraries!
Frameworks
A general skeleton for a category of software systems. Allows us to customise and adapt to get the functionalities that we want. Examples: Web application frameworks (Ruby on Rails, Drupal), Automated Testing Framework (JUnit, GUnit), IDE Framework (Eclipse). In the case of framework, you write the code to be called by the framework. In comparison, you write codes that call functions from a library.

Platforms
! Provides a runtime environment for applications. E.g. Windows, iOS, JavaEE

OO Domain Models
Used to model objects in the problem domain. Does not contain solution specific classes. E.g. For snakes and ladders,

! References! !

Rajapakse, D. (2013) Notes on Software Engineering: An Incremental Approach.

Page 6 # of 6 #