210 likes | 224 Views
This report discusses the progress of highly promising software engineering projects, highlighting challenges such as time constraints and unexpected events. It also explores the importance of thinking for the long-term and addresses topics like system security, data privacy, requirements, design, and implementation.
E N D
CS 501: Software EngineeringFall 1999 Lecture 18 (a) Project Reports (b) Object-Oriented Design III
Administration Recitation session: Rational Rose
Project Progress All projects are highly promising, some are exceptional. Major concern is the time to completion. Real life experiences: Client representative leaves suddenly Team member drops course First approach not adequate (performance of animation) Start-up delays: learning, studying technical options, access to software and facilities, scheduling meetings
Thinking for the Long Term Believe that your software will be in use 5 years from now. What happens at end of semester? Packaging and hand-over Client's technical preferences (C++, Java) Some system decisions based on short-term considerations Which formats, protocols, etc. do you think will last? (IIOP, RMI, SNMP, ...)
Network Security Server Vulnerable information Application Internet Database Web server SendMail Insecure components
Network Security: Use of Firewall Server 2 Server 1 Web server Application Firewall Internet Relay Relay SendMail Database
Privacy Does you system collect personal data? Does the user know that you are collecting personal data? Who is supposed to have access to that data? Example: Dartmouth Medical School Who actually has access to that data? Example: Personnel data files ..... the first subpoena ....
Requirements, Design and Implementation Remember the definitions. Example: Consistency between two players of a board game The requirement is ..... The design is ..... What is a requirements specification?
Final Presentation: First Thoughts Last week of classes -- 3 or 4 day period Presentation in front of: Client(s) Bill Arms All CS 510 Class is invited Guests Time: 45 minutes Format -- you select from: Slides Online demonstrations Hand outs
Final Deliverables Documentation and programs Delivered to: Client and graders Due: Last day of classes Project will be graded on: Client satisfaction Usability Maintainability
Actor and Use Case An actor is a user of a system in a particular role. An actor can be human or an external system. A use case is a a task that an actor needs to perform with the help of the system. BookBorrower Borrow book
Use Cases and Actors A scenario is an instance of ause case Actor is role, not an individual (e.g., librarian can have many roles) Actor must be a "beneficiary" of the use case (e.g., not librarian who processes book when borrowed) In UML, the system boundary is the set of use cases.
Use Cases for Borrowing Books Borrow copy of book BookBorrower Return copy of book Reserve book Extend loan
Extend loan Relationships Between Use Cases: <<uses>> <<uses>> Check for reservation BookBorrower Borrow copy of book <<uses>>
Relationships Between Use Cases: <<extends>> <<extends>> Refuse loan Borrow copy of book BookBorrower
Use Cases in the Development Cycle Use cases are a tool in requirements analysis Intuitive -- easy to discuss with clients Use cases are often hard to translate into class models Scenarios are useful to validate design
Actions on Objects returnCopy(c) call return send create destroy okToBorrow() local status notifyReturn(b) asynchronous signal <<create>> stereotypes <<destroy>>
Copy Links LibraryMember +borrowCopy() +returnCopy() 1 on loan 0..* association class message borrowCopy(c) c:Copy libMem:LibraryMember link object
Sequence Diagram: Change in Cornell Program :MEngStudent Cornellian 1 : getName() 1.1 : name 2: new PhDStudent(name) :PhDStudent 3: <<destroy>> sequence numbers added to messages
Sequence Diagram: Borrow copy of a Book libMem: LibraryMember theBook:Book BookBorrower theCopy:Copy borrow(theCopy) okToBorrow borrow borrow
State Diagram returned() returned() not borrowable borrowable borrowed()[last copy] borrowed()[not last copy] State diagram for class Book