CS2103 Lecture 4
CS2103 Lecture 4 CS2103
Popular in Software Engineering
Popular in Quantitative Methods
verified elite notetaker
This 4 page Class Notes was uploaded by Jerry Tan on Saturday September 19, 2015. The Class Notes belongs to CS2103 at National University of Singapore taught by Damith C. Rajapakse in Summer 2015. Since its upload, it has received 99 views. For similar materials see Software Engineering in Quantitative Methods at National University of Singapore.
Reviews for CS2103 Lecture 4
Loved these! I'm a horrible notetaker so I'll be your #1 fan this semester
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 09/19/15
National University of Singapore NUS CS2103 Software Engineering AY2015 SEM 1 Lecture 4 Building the Product Friday 28th August 2015 By Jerry Tan Si Kai Lecture 4 View from the Top Architecture Architecture High level structure technical descisions 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 fulldesign 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 Fulldesign 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 C82103 Top down approach 3 Bottom up approach think of what you have and put them together in a bottom up fashion Most of the time we have been using bottom up approach Who gets to decide The architect Needs at least 1015 years of experience not easy Much higher paid than software engineers Types of software architecture styles 1 Ntier 2 Clientserver 3 Transaction processing 4 Serviceoriented 5 Pipes and filter Sequence diagrams diagrams that show interactions between components for a given scenario 1 Activation bar a bar to show when the UI is actively processing a user request 2 Loops are drawn by drawing a big box around the actions a box on the top left hand corner labeled quotloopquot and the condition in the middle of the box eg until won or lost 3 Draw arrows from one component to the next can be dotted or solid line The method to call or the specific action to be performed is labeled on top of the arrow 4 Time goes in the chronological order from top to bottom 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 U1 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 eg assertEquals desc of test casequot output expected output assertEqualsO takes the output from your SUT and checks it against the expected output prints something when failed IDE have builtin 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 TestDriven 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