Introduction. Introduction. Software Engineering. Software Engineering. Software Process. Department of Computer Science 1

Transcription

1 COMP209 Object Oriented Programming System Design Mark Hall Introduction So far we ve looked at techniques that aid in designing quality classes To implement a software system successfully requires planning, design and testing For larger projects, the amount of time spent on planning and design is often much greater than actual coding If you spend most of your time keying in code and fixing bugs, you can cut down on total time spent by concentrating more on the planning and design phase Introduction The techniques we are going to look at are the domain of the fields of Software Engineering and Systems Analysis and Design We ll take a look at some simple techniques and processes COMP314 delves deeper Software Engineering Software engineers model parts of the real world in software Models can be abstract and complex, so are recorded and made visible in documents. This is more useful to other developers than hard to understand code Modelling and documentation is as important in the SE process as programming Many different approaches, one common idea: Decomposition of a complicated problem into less complicated parts Software Engineering Primary objective: produce quality software products Quality SE product is On time Within budget Functional User friendly Bug free Flexible Adaptable Software Process A software project usually starts because a customer has a problem and will pay money to have it solved US Dept. Defense was an early proponent of a formal process for software development A formal process identifies and describes different phases of development + guidelines on how to carry out the phases Department of Computer Science 1

2 The Software Lifecycle Many software engineers divide the process into five phases (referred to as the Software Lifecycle): Analysis decide what the project is supposed to accomplish Output: a requirements document Design develop a plan for how to implement the system Output: description of classes and methods, with diagrams showing relationships among classes Implementation write and compile program code Output: completed program (all classes and methods implemented) Testing run tests to verify that program runs correctly Output: report describing tests and their results Deployment release program and install for use The Waterfall Model In the early 1970s, software engineers had a very simple visual model of these phases Analysis Design Implementation Testing One phase runs to completion, its output spills over to the next phase, and the next phase begins Deployment The Waterfall Model When rigidly applied, the waterfall model did not work Difficult to come up with perfect requirements specification Common to discover requirements problems during the design phase Design problems often come to light during implementation Many bugs found during testing often fatal problems that could only be fixed by starting again! Unhappy customers :-( Spiral Model Developed in the late 1980 s to address shortcomings in the standard waterfall process Iterative in nature Spiral Phases (perhaps like the waterfall) are performed in each iteration to develop software that is not necessarily the final product Construction of prototypes in early iterations When intermediate system is done, the project is evaluated to see if further development should be done Spiral Model Driven by risk Risk of failure is high for large complex systems Eg. it may not be known whether the system can be produced with the resources that can be brought to bear In first turn of spiral developers try to resolve this question After each turn of the spiral new risks come to light, and a next turn is planned to resolve them In later turns, the software prototypes begin to look more an more like finished products Along the way, the original requirements might have been modified so that the final system contains only a portion of what was originally intended ie, that portion for which the risks were overcome Even complex development processes with many iterations have not always met with success In 1999 Kent Beck introduced, a development methodology that strives for simplicity Cuts out most of the formal trappings of traditional development methodologies Focuses on a set of practices Department of Computer Science 2

3 12 Commandments of : 1. Realistic planning Meet with coders, managers, and the customer each week to schedule tasks for the next phase. Update the plan regularly 2. Small releases Put a simple system into production quickly, then release new versions on a short cycle 3. Metaphor Create an analogy that expresses how the parts of the new system work 4. Simplicity Design everything to be as simple as possible instead of preparing for future complexity 12 Commandments continued 5. Testing Write test programs that assure every portion of the code runs flawlessly before attempting a new task 6. Refactoring Restructure the system continuously to improve the code and eliminate duplication 7. Pair programming Write all code with two programmers at one machine 8. Collective ownership Permit anyone on the team to change code anywhere in the system at any time 12 Commandments continued: 9. Continuous integration Whenever a task is completed, build the entire system and test it hour week Don t cover up unrealistic schedules with bursts of heroic effort 11. On-site customer Include a real, live user on the team, available full-time to answer questions 12. Coding standards Use agreed-upon styles and nomenclature to promote easy understanding of what the code does Many of the extreme programming practices are common sense For this course you will not need a full-fledged methodology to solve your assignments We will take a look at a few modeling techniques that can help in the analysis and design phase Analysis In the analysis phase of software development, the task is to discover the requirements for the software What is the software supposed to do for its users? Behaviour of the software under various conditions One tool that can help discover and organize requirements are What is a Use Case? Use cases document the behaviour of the system from the user s point of view Express requirements at a high level The first step in software analysis is to develop a sufficient set of use cases Will also be useful later on for system testing E.g. for a word processor: Build an index Insert a picture Ensure consistent formatting Department of Computer Science 3

4 A use case is a sequence of actions that an actor performs with the help of the system to accomplish a particular task An actor represents A role a user can play with regard to a system An entity such as another system or a database (outside of the system being modelled) Result of use case modelling all required system functionality is described in the use cases Use cases provide a structured approach to requirements analysis Identify the actors For each actor find out What they need from the system: that is, what use cases there are which have value for them Detail the use case: describe the steps the user would go through with the system to accomplish the usage scenario Use cases also provide a good basis for writing the user manual for the software Example: The University Library System Problem statement : You have been contracted to develop a software system for a university library. The library currently uses a 1960 s program, written in an obsolete language, for some simple bookkeeping tasks, and a card index, for user browsing. You are asked to build an interactive system which handles both of these aspects on line. Vague, but typical of an initial request University Library requirements facts after some investigation Books and journals The library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. New books and journals arrive regularly and are sometimes disposed of. The current year s journals are sent away to be bound into volumes at the end of each year. There may in future be be a requirement for users to be able to extend the loan of a book if it is not reserved. Borrowing The system must keep track of when books and journals are borrowed and returned, enforcing the rules described above. Browsing The system will allow users to search for a book by topic, author, etc., to check whether a copy of a book is available for loan, and if not, to reserve the book. Anybody can browse in the library Users: Librarian Library member Non-library member Actors (roles): Librarian BookBorrower JournalBorrower Browser Actors in the Library System in the Library System BookBorrower Reserve book, Borrow copy of book, Return copy of book, Extend loan JournalBorrower Borrow journal, Return journal Browser Browse Librarian Update catalogue Department of Computer Science 4

5 Library System Use Case Diagram Library System Reserve book Borrow journal JournalBorrower BookBorrower Borrow copy of book Return copy of book Return journal Browse Browser Extend loan Update catalogue Librarian Documenting Detail of each use case should be documented Use third-person, active voice English Use terms from the problem domain (i.e. Those that the user would understand) Say what the system does, not how or implementation detail The basic course of action is the main start-to-finish path the user will follow under normal circumstances An alternative course of action can represent an infrequently used path, an exception, or error Borrow copy of book use case Actor: BookBorrower Trigger: A potential BookBorrower presents a book to the Librarian Preconditon(s): The Librarian has successfully identified himself or herself to the library system by entering a valid library staff identification number and password. Basic course: A BookBorrower presents a book. The system checks that the potential borrower is a member of the library and that he/she does not already have the maximum permitted number of books on loan. The system records that this library member has this copy of the book on loan. Alternative course(s): 1) If potential borrower is not a member of the library the system refuses the loan. 2) If the library member has the maximum permitted number of books (12 for staff members, otherwise 6) the system refuses the loan Postcondition(s): If the loan is successful then the system records the loan against the library member s record. Otherwise, nothing in the system has changed when this use case ends. Documenting Granularity? How big or small should a use case be? Guideline: a use case should accomplish something of value for the actor involved E.g. ATM system: is enter pin number using keypad a use case? No, it doesn t achieve something of value for the actor Probably one step in a withdraw funds use case here the value for the user is the funds received from the ATM Helps with three difficult aspects of development Identifying and capturing requirements Planning iterations of development Testing systems Department of Computer Science 5