Академический Документы
Профессиональный Документы
Культура Документы
Tujuan Dapat menggunakan syntax dan semantic OOP Memahami konsep pengembangan perangkat lunak berorientasi obyek Dapat membuat aplikasi perangkat lunak berorientasi obyek
Materi
Konsep Dasar OOD Class dan Method Inheritance dan polimorphism Dasar UML Use Case Diagram Activity Diagram Sequence Diagram Class Diagram Deployment Diagram
Software Development
Methodology
A methodology is a systematic way of doing things. a repeatable process that we can follow from the earliest stages of software development (the germ of an idea or a new business opportunity) through to the maintenance of an installed system. a methodology should specify what were expected to produce as we follow the process include advice or techniques for resource management, planning, scheduling and other management tasks
Methodology
A methodology can help to impose discipline on the coding effort. Going through even the basic steps of a methodology increases our understanding of the problem, improving the quality of our solution. Writing lines of code is only one of the many activities in software development: performing some of the other activities helps us to spot conceptual and practical mistakes before we commit them to source code.
Methodology
At every stage, a methodology specifies what we should do next, so were not left scratching our heads, thinking Okay, what now? A methodology helps us to produce code that is more extensible (easier to change), more reusable (applicable to other problems) and easier to debug (because it has more documentation).
Good Methodology
Planning: Deciding what needs to be done. Scheduling: Mapping out when things will be done. Resourcing: Estimating and acquiring the human, software, hardware and other resources that are needed. Workflows: The subprocesses within the wider development effort (for example, designing the system architecture, modeling the problem domain and planning the development effort).
Good Methodology
Activities: Individual tasks within a workflow, such as testing a component, drawing a class diagram or detailing a use case, too small or indefinable to be a workflow in their own right. Roles: The parts played by personnel within the methodology (developer, tester or sales person). Artifacts: The products of the development effort: pieces of software, design documents, training plans and manuals. Education: Deciding how to train personnel, if necessary, to fulfill their required roles;deciding how end users (staff, customers, sales people) will learn how to use the new system.
Key Questions
Requirements phase:
What is our context? What are we trying to achieve? What entities are we dealing with? How can we be sure we have the right ones? How are we going to solve the problem? What hardware and software will we need in the finished system?
Analysis phase:
Key Questions
How are we going to implement the solution? What will the source code and supporting files look like? What rules govern the interfaces between the system components? Can we remove ambiguity and ensure correctness?
Specification phase:
Key Questions
Implementation phase:
How can we code the components to meet the specification? How do we write stylish code? Does the finished system satisfy the requirements? Can we break the system? What do the system administrators have to do? How can we educate the end users?
Testing phase:
Deployment phase:
Key Questions
Maintenance phase:
Can we find and fix the faults? Can we improve the system?
15
1. 2. 3. 4. 5. 6.
Specify the problem requirements Analyze the problem Design the algorithm Coding Testing and verification Maintenance
Also known as the Waterfall Method; one step is dependent on the previous step.
16
IV. Follow the detailed steps/directions Implement the algorithm! V. Test the swing Is it safe? Any sharp edges? What is the max weight? OK kids come play!!! Released for use VI. Check on it occasionally maintenance Add a chin-up bar Check for broken parts Upgrade the slide, etc.
17
Establish the level of abstraction: Understand the problem. What is NOT the problem? What is essential to solve the problem? Eliminate unnecessary unimportant information. Gather missing information.
State the Problem Specification We will simplify the specification to a formal one-line statement of the problem. Be clear and concise To calculate To produce To determine
18
http://mathcs.holycross.edu/~croyden/csci150spr03/notes/lec15_divideConquer.gif
21
Simple programs follow this generic pattern: Major Task Identification 1.0 Get the data 2.0 Perform the computation(s) (Processing) 3.0 Display the results
continued
Now refine; use indentation for subtasks: 1.0 Get the data 1.1 Prompt for the data 1.2 Get the data Subtasks ..
http://faculty.frostburg.edu/cosc/htracy/UML/IPO_flowchart.gif
22
23
DO NOT USE programming language syntax DO USE variable names as an abstraction of memory locations. Variable: a named data element in a program. The compiler will associate a relative memory location with the name. Variables have values that change over time. Walk through the algorithm to simulate execution. - Create a Trace Table to show how the values of data elements will change during execution. - Show the Expected Output
24
25
SOFTWARE DEVELOPMENT METHOD Where are we? 1. Specify the problem requirements 2. Analyze the problem 3. Design the algorithm
Major task / Subtask Identification & Algorithm Design
4. Coding
5. Testing and verification 6. Maintenance
26
Step 1: Choose the C++ data types based on the internal storage representation and the max and min values of the data Is it an Integer? Real? or Character? Step 2: Convert the algorithm to C++ code. Write out the C++ code by hand! Step 3: Compile the program Create your source file, compile, execute. Debug the code: locate and correct errors. Code (a little at a time), Compile, and Debug in increments.
27
http://www.first-to-fly.com/Adventure%20Images/1901%20Glider%20Replica/Testing%20pitch.jpg http://www.first-to-fly.com/Adventure%20Images/1901%20Glider%20Replica/Testing%20pitch.jpg
Validation:
Have I done the right thing? Does the solution meet the clients expectation? Have the requirements been met?
28
SOFTWARE DEVELOPMENT METHOD 6. Maintenance Fix Problems: Logic errors Make improvements, Upgrade or replace equipment (tech change), Most expen$ive part of Software, Legacy code: old code that has had many changes and revisions. Especially difficult to follow.
http://www.deerparkmanagement.com/images/maintenance.jpg
29
ALWAYS CONSIDER MAINTENANCE, MAINTENANCE especially in design and coding steps. The following contribute to low maintenance: Reusability of code, Good documentation, Structured programming, Kiss method.
30
SOFTWARE DEVELOPMENT METHOD 1. 2. 3. 4. 5. 6. Specify the problem requirements Analyze the problem Design the algorithm Coding Testing and verification Maintenance
31
would you prefer to open wide and swallow the beast whole or to eat a manageable portion, have a rest, eat another portion, have a rest, and so on?
New Methodologies
We need to accept that it is impossible to develop a piece of software in one pass However hard we try, the first time around our software will be incomplete or imperfect or both We need to perform the classical phases of software development several times, adding to and perfecting the system as we go.
Spiral Methodology
Iterative Methodology
Incremental Methodology
At the highest level, we know from the incremental methodology that we must plan a succession of increments. Within each increment, the spiral methodology suggests that we should have at least two attempts to produce each increment. Within each spiral, the waterfall methodology specifies the phases and the order in which they occur. Within each mini-waterfall, the iterative methodology allows us to repeat phases, or combinations of phases, as we see fit (for example, several cycles of requirements and analysis); the iterative methodology also allows us to fix a problem as soon as we discover it (for example, we might discover during subsystem design that the system design makes some piece of functionality impossible, so we fix the system design before we carry on).
OBJECT-ORIENTED METHODOLOGIES
the developers are given some choice about whether they use a particular type of diagram, for example
Development team must select a methodology and agree which artifacts are to be produced, before they do any detailed planning or scheduling.
Static modeling involves deciding what the logical or physical parts of the system should be and how they should be connected together. static modeling describes how we construct and initialize the system Dynamic modeling is about deciding how the static parts should collaborate.
dynamic modeling describes how the system should behave when its running
To be effective, any spiral, iterative and incremental methodology requires an end-toend development tool. The need to amend project artifacts iteratively is a strong justification for the use of a software tool. Such a tool should allow members of the project team to produce the artifacts and then to store them.
Traceability Change history Multiuser access control Reduced redundancy Consistency checking Networked operation Testing the artifacts that we produce, as we go along
Development Tools
Rational Corporation developed a tool called Rose, based on RUP and UML. Rose became probably the best-known object-oriented development tool. In 2003, Rational was bought by IBM and the tool has been reworked as a set of modular products (and is now called Rational Application Developer). Of course, there are many development tools available Rational products are only mentioned here because of the historical perspective.