SlideShare uma empresa Scribd logo

Cnpm bkdn

•Transferir como PPT, PDF•
•
A
Ankit yadav
EducaçãoTecnologiaNegócios
1 de 600
Software Engineering Lecture 1 Introduction to Software Engineering
Code of Conduct  Software Engineering is a collaborative activity. You are encouraged to work together, but ...  Some tasks may require individual work.  Always give credit to your sources and collaborators. Good professional practice: To make use of the expertise of others and to build on previous work, with proper attribution. Unethical and academic plagiarism: To use the efforts of others without attribution.
Projects  Project teams, about 3 to 5 peoples.  Select your own project, any branch of software engineering  Real project for real client who intends to use the software in production.  Feasibility study and plan: during semester  Presentations: • requirements • design • final
Project Selection  Some suggested projects  Recitation section to suggest projects Contact potential clients:  Gain idea of their expectations  Estimate scope and complexity of the project  Discuss business decisions Assemble project team  Advertise on the web site
Previous Experience Your background       Biggest program that you have written? Biggest program that you have worked on? Biggest project team that you have been part of? Longest project that you have worked on? Most people who have used your work? Longest that your project has been in production? My background
Course Themes 1. Leadership of large software projects  Software as a product Clients and their needs Quality  Requirements and specification Usability Evolution  Project management Personnel management Economic, legal, and social factors
Course Themes 2. Large and very large systems  Software design Software architecture Object-oriented design  Dependable systems Reliability Verification  Legacy systems
Characteristics of Software Products General characteristics Usability Maintainability Dependability Efficiency Good software products require good programming, but ... Programming quality is the means to the end, not the end itself.
Software as a Product Software is expensive!! Every software project has a trade-off between: Functionality Resources (cost) Timeliness Example: Accounting Management System
Client (a.k.a Customer)  The client provides resources and expects some product in return.  Client satisfaction is the primary measurement of success. Question: Who is the client for Microsoft Excel?
Variety of Software Products Examples? -Operation System -Database Management System -Embedded System -Games -Application Software -…
Categories of Product Categories of client and software product:  Generic (e.g., Microsoft Excel)  Bespoke (customized) (e.g., IRS internal system) Many systems are customized versions of generic packages (e.g., Cornell's payroll system)
Variety of Software Products Software products are very varied --> Client requirements are very different --> There is no standard process for software engineering --> There is no best language, operating system, platform, database system, development environment, etc. A skilled software developer knows about a wide variety of approaches, methods, tools. The craft of software engineering is to select appropriate methods for each project and apply them effectively.
Professional Responsibility Organizations put trust in software developers:  Competence: Software that does not work effectively can destroy an organization.  Confidentiality: Software developers and systems administrators may have access to highly confidential information (e.g., trade secrets, personal data).  Legal environment: Software exists in a complex legal environment (e.g., intellectual property, obscenity).  Acceptable use and misuse: Computer abuse can paralyze an organization (e.g., the Internet worm).
Software Engineering Lecture 2 The Software Process
Books  Frederick P. Brooks, Jr. The Mythical Man Month. Addison-Wesley, 1972.  Ian Sommerville, Software Engineering, 6th edition. Addison-Wesley, 2000.  Grady Booch, James Rumbach, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999.
Software Process Fundamental Assumption: Good processes lead to good software Good processes reduce risk
Risk Management What can go wrong in a software project? How can the risk be reduced?
The Software Process (Simplified) Feasibility and Planning Requirements Design Implementation Operation and Maintenance
The Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
Requirements Analysis and Definition The system's services, constraints and goals are established by consultation with system users. They are then defined in a manner that is understandable by both users and development staff. This phase can be divided into:     Feasibility study (often carried out separately) Requirements analysis Requirements definition Requirements specification
System and Software Design System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture Software design: Represent the software system functions in a form that can be transformed into one or more executable programs  Unified Modeling Language (UML)
Programming and Unit Testing The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified.) Individual components are tested against specifications.
Integration and System Testing The individual program units are:  integrated and tested as a complete system  tested against the requirements as specified  delivered to the client
Operation and Maintenance  Operation: The system is put into practical use.  Maintenance: Errors and problems are identified and fixed.  Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment.  Phase out: The system is withdrawn from service.
Discussion of the Waterfall Model Advantages:     Process visibility Dependence on individuals Quality control Cost control Disadvantages: Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised.
Feedback in the Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
Iterative Refinement (Evolutionary Development) Concept: Initial implementation for user comment, followed by refinement until system is complete.  Vaporware: user interface mock-up  Throw-away software components  Dummy modules  Rapid prototyping  Successive refinement
Iterative Refinement Evaluation Requirements Implementation (prototype) Design
Iterative Refinement Concurrent Activities Requirements Outline Description Design Implementation Initial Version Intermediate Versions Final Version
Iterative Refinement & Software Process Concurrent Activities Outline Description Requirements Design Implementation Final Version
Iterative Refinement When is iterative refinement appropriate?
Iterative Refinement + Waterfall Model: Graphics for Basic Outline Description: Add vector graphics to Dartmouth Basic. Phase 1: Extend current language with a preprocessor and run-time support package. (1976/77) Phase 2: Write new compiler and run-time system incorporating graphics elements. (1978/80)
Iterative Refinement + Waterfall Model: Graphics for Basic Design Issues:  Pictorial subprograms: coordinate systems, window/viewport  User specification of perspective Design Strategy: (Iterative Refinement)  Write a series of prototypes with various proposed semantics  Evaluate with a set of programming tasks
Iterative Refinement + Waterfall Model: Graphics for Basic Phase 1: Implementation (Waterfall)  When the final specification was agreed, the entire preprocessor and run-time support were recoded.  The system was almost entirely bug-free. Phase 2: New compiler (Waterfall) Phase 1 was used as the requirements definition for the final version.
Observations about Software Processes Completed projects should look like the Waterfall Model but ... the development process is always partly evolutionary. Risk is lowered by:  Prototyping key components  Dividing into phases  Following a visible software process  Making use of reusable components
Software Engineering Lecture 3 (a) Feasibility Study (b) Requirements Definition
Feasibility Study Before beginning a project, a short, low-cost study to identify • Client • Scope • Potential benefits • Resources needed: staff, time, equipment, etc. • Potential obstacles Where are the risks? How can they be minimized?
Feasibility Study A feasibility study leads to a decision: go ahead do not go ahead think again In production projects, the feasibility study often leads to a budget request. In research, a feasibility study is often in the form of a proposal.
CS 501: Client In CS 501, you have two clients: • The client for the project • The professor for the course Can you satisfy them both?
Scope What are the boundaries of the project? CS 501 Examples: • Static web pages with open access on the Web [Web Profiler] • Used by the general public [Digital Collections] • Varying data formats [Legal Information] • Thousands of sensors [Data mining] • Support for Windows, Mac, Unix [SALSA]
Potential Benefits Why are you doing this project? Examples • Create a marketable product • Improve the efficiency of an organization • Control a system that is too complex to control manually • New or improved service • Safety or security • Get a good grade on CS 501
Resources Examples: CS 501 Staff: 5 to 7 students, with some help. How many hours per week? What skills do people have? Time: Must be completed by end of semester, including operational system, documentation, presentation Equipment and software: What special needs are there? Client: Will the client be sufficiently available and helpful?
Obstacles CS 501 projects Start-up time. Creating a team, scheduling meetings, acquiring software, learning new systems, ... Business considerations. Licenses, trade-secrets, ... Too ambitious. Nothing to show at the end of the semester. Changing circumstances. Client leaves the university, ... What else?
How to Minimize Risk? CS 501 Projects • Several target levels of functionality: required, desirable, optional • Visible software process: intermediate deliverables • Good communication within team and with Teaching Assistant Good processes lead to good software Good processes reduce risk
Feasibility Report A written document • For a general audience: client, financial management, technical management, etc. • Short enough that everybody reads it • Long enough that no important topics are skipped In CS 501, I am looking for a well written, well presented document.
Requirements Definition and Analysis Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
Example: Library of Congress (A Partial Failure) Outline Description The Library of Congress requires a repository system to store and make accessible very large amounts of highly varied material over long periods of time.
Chronology 1993-94 CNRI carries out research on architectures for digital libraries 1995-97 CNRI implements prototype repository for Library of Congress 1998 CNRI and Library of Congress carry out requirements definition
The Repository Repository Users Identification System Search System
Storage and Representation of Complex Objects Data Several representations: thumbnail image reference image archival image Metadata Each representation may have its own metadata
Repository: Research Achievements 1. CORBA implementation of repository access protocol. 2. Integration of persistent naming through handle system. 3. Use of structural metadata to describe complex objects, elementary typology. 4. Access management framework and implementation. 5. Applet-based middleware for user interfaces. 6. Information visualization program to view the structure of large collections.
Good Discoveries During Prototype • Structuring complex information in digital libraries • Data driven digital library interfaces • Comparison of object-oriented, relational, and file based storage systems • Naming and identification of library objects • Boundaries of required repository system
Bad Discoveries During Prototype • Resistance to change within Library of Congress • Technical weakness of Library of Congress • Gaps in CNRI architecture
Mistakes • Confusion of objectives (research and implementation) • Failure to involve all stakeholders • Over-ambitious (no proper feasibility study)
The Requirements Process Feasibility Study Feasibility Report Requirements Analysis Requirements Definition System Models Requirements Specification Definition of Requirements Requirements Document Specification of Requirements
Requirements Definition High-level abstract description of requirements: • Specifies external system behavior • Comprehensible by customer, management and users Should reflect accurately what the customer wants: • Services that the system will provide • Constraints under which it will operate
Library of Congress Requirements Study Team (all experienced): Librarian, Software Engineer (CNRI), Computing Project Leader (Library of Congress), + 2 others Advisors: Mailing list of about 20 knowledgeable stakeholders. Timetable: Preliminary report (2 months). Final report (1 month).
Functional Requirements Example: Library of Congress repository • Support for complex digital objects • Access management • Identification • Information hiding • Open protocols and formats • Integration with other systems (scope)
DRAFT OVERVIEW OF ITS SUPPORT FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY NDLP collections already released Coolidge collection (for repository test) NDLP collections in conversion Future NDLP collections Other applications and materials NDLP Workflow Tracking Support Current Storage Structure (in Unix files, by aggregate) Object Administration System ILS Repository Index Generation (including pre-processing) American Memory User Interface (retrieval, navigation, & display) AM user interface plus access management for objects/collections Other User Interfaces (e.g. RLG, OCLC, DLF partners) ILS OPAC Interface Supporting infrastructure Handle assignment & registration Handle-server NOW Handle resolution FUTURE
Non-functional Requirements Environment: • Estimates of sizes, numbers of users, etc. • Reliability and performance measures and targets Preferred: Example: Library of Congress repository • Hardware and software systems (e.g., IBM/Unix) • Database systems (e.g., Oracle) • Programming languages (e.g., C and C++)
Evolution of Requirements • If the requirements definition is wrong, the system will be a failure. • With complex systems, understanding of requirements always continues to improve. Therefore... • The requirements definition must evolve. • Its documentation must be kept current (but clearly identify versions).
Software Engineering Lecture 4 Management I: Project Management
The Aim of Project Management To complete a project: • On time • On budget • With required functionality • To the satisfaction of the client • Without exhausting the team
The Project Manager • • • • Create and maintain the schedule Should track progress against schedule Keep some slack in the schedule Be continually making adjustments: Start activities before previous activity complete Sub-contract activities Renegotiate deliverables • Keep senior management informed
Project Planning Methods The Critical Path Method, Gantt charts, Activity bar charts, etc. are roughly equivalent. These methods are best when: • Model is updated regularly (e.g., monthly) • The structure of the project is well understood • The time estimates are reliable • Activities do not share resources [Critical Path Method is excellent for large construction projects.]
Example: An Open University Course Deliverables: 16 8 8 4 1 4 Written texts (bound in pairs) Television programs Radio programs Computer programs Home experimental kit (scientific calculator) Assignments and sample solutions
Flexibility Schedule: Dates for broadcasting TV and radio programs are fixed. Printing and mailings can be accelerated if overtime is used. Functionality: The course team can decide what goes into the components of the course. Resources: The size of the course team can be increased slightly.
Scheduling: Critical Path Method An activity A dummy activity An event A milestone
Critical Path Method other activities START Revise Unit 3 Edit Unit 3 Print Unit 3 Mail Unit 3 END
Critical Path Method other activities Revise Unit 3 Edit Unit 3 START other activities Revise Unit 4 Edit Unit 4 Typeset Unit 3 Print Units 3/4 Typeset Unit 4 Mail Units 3/4
Critical Path Method Script TV 2 START Edit Unit 3 Make TV 2 Edit Unit 4 Prototype Computer 1 Document Computer 1 Mail Delivery Program Computer 1
Time Estimates for Activities (Weeks) 4 1 6 3 2 3 1 12 12 1 3 2 4 4 1 3 2 8
Earliest Start Dates 1 1 12 26 4 3 6 15 2 17 3 12 0 12 12 3 2 17 3 19 1 22 1 23 2 4 4 4 1 17 8 25
Latest Start Dates 11 1 12 4 3 6 15 1 2 17 3 12 0 12 14 4 13 3 26 2 17 4 3 20 23 1 24 2 17 1 8 25
Critical Path 1/11 12/12 26/26 15/15 17/17 22/23 0/0 12/14 4/13 17/17 19/20 17/17 23/24 25/25
Slack 1/11 10 12/12 0 0/0 26/26 10 3 15/15 0 0 0 1 22/23 0 2 12/14 2 17/17 9 17/17 4/13 19/20 1 0 9 23/24 25/25 1 1 5 17/17 0
Key Personnel In computing, not all people are equal: • The best are at least 5 times more productive • Some tasks are too difficult for everybody Adding more people adds communications complexity • Some activities need a single mind • Sometimes, the elapsed time for an activity can not be shortened. What happens to the project if a key person is sick or quits?
Key Personnel: Schedule for Editor Earliest Start Date Activity Weeks 15-16 Weeks 17-18 Weeks 19-20 Weeks 21-22 Edit Unit 3 Edit Unit 4 Edit Unit 5 Edit Unit 6 Week 15 Week 17 Week 19 Week 21 Review draft of Unit 7 Review draft of Unit 8 Check proofs of Unit 3 Check proofs of Unit 4 Weeks 18-19 Week 22 Vacation Out sick
Start-up Time On a big project, the start-up time is typically three to six months: • Personnel have to complete previous projects (fatigue) or recruited. • Hardware and software has to be acquired and installed. • Staff have to learn new domain areas and software (slow while learning) • Clients may not be ready.
Experience with Critical Path Method Administrative computing department at Dartmouth used the Critical Path Method for implementation phase of major projects. Experience: Elapsed time to complete projects was consistently 25% to 40% longer than predicted by model. Analysis: • Some tasks not anticipated (incomplete understanding) • Some tasks had to be redone (change of requirements, technical changes) • Key personnel on many activities (schedule conflicts) • System ZZZ (non-billable hours)
CS 501: Software Engineering Lecture 5 (a) Documentation (b) Requirements Analysis
Assignments September 13 October 4 October 16 November 8 Nov 29 - Dec 1 Exam week Feasibility and plan Requirements Midterm exam Design Project presentations Final examination Details are subject to change. Group Group/individual Individual Group/individual Group Individual
Assignment 1 Wednesday, September 13: Project plan due -- report. Title of project Client/customer Team members Outline description Current status (e.g., previous work) Plan (e.g., major stages, assignment to tasks, technical environment, schedule, etc.) Any other relevant information
Documentation • Reasons for documentation: visibility (e.g., project plan, interim report) user support (e.g., user manual) team communication (e.g., interface specifications) maintenance and evolution (e.g., requirements) • Characteristics of documentation: accurate and kept current appropriate for audience maintained online (usually) simple but professional in style and appearance Documentation is expensive --> Quality not volume
Form of Documentation External • Printed • Web site Internal • Program documentation • Program context (e.g., copyright notices)
Requirements Definition and Analysis Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
The Requirements Process Feasibility Study Feasibility Report Requirements Analysis Requirements Definition System Models Requirements Specification Definition of Requirements Requirements Document Specification of Requirements
Requirements Analysis 1. Understand the requirements in depth: • Domain understanding Examples: science research, application… • Stakeholders Example: companies, ministries, Danang City…
Viewpoint Analysis Example: University Admissions System • Applicants • University administration Admissions office Financial aid office Special offices (e.g., athletics, development) • Computing staff Operations Software development and maintenance • Academic departments
Interviews with Clients Clients may have only a vague concept of requirements. • Prepare before you meet with them • Keep full notes • If you don't understand, delve further • Small group meetings are often most effective Clients often confuse the current system with the underlying requirement.
Requirements Analysis 2. Organize the requirements: • Classification into coherent clusters (e.g., legal requirements) • Recognize and resolve conflicts (e.g., functionality v. cost v. timeliness) Example: Dartmouth general ledger system
Requirements Analysis 3. Model the requirements: • Informal Prose • Systematic Procedural models Data-centric models Object models • Formal models
Procedural Models: Flowchart Operation Decision Manual operation Report
Flowchart: University Admissions Form received New? T Database record Notify student F Update database Complete? T F Notify student Evaluate
Procedural Models: Pseudo-code Example: Check project project plan check_plan (report) if report (date_time) > due_date_time then error (too_late) if report (client) = none then error (no_client) if report (team) < min_team or > max_team then error (bad_team) if error() = none then comments = read_report (report) return (comments (text), comments (grade)) else return error()
Data-Flow Models External entities Processing steps Data stores or sources Data flows
Example: University Admissions Rejection Application Completed form Receive application Evaluate application Applicant Offer
Example: University Admissions Assemble Application Stage Acknowledgment Application form Receive Applicant Completed application Acknowledgment AND Initiate evaluation Evaluation request AND Supporting information Pending database Applicant database
Example: University Admissions Process Completed Application Stage Rejection Evaluation request Evaluation Acceptance Special request Applicant database Financial aid Offer
Requirements Analysis v. System Design Dilemma. • Requirements analysis should make minimal assumptions about the system design. • But the requirements definition must be consistent with computing technology and the resources available. In practice, analysis and design are interwoven. However, do not to allow the analysis tools to prejudge the system design.
CS 501: Software Engineering Lecture 6 (a) Requirements Analysis (continued) (b) Requirements Specification
The Requirements Process Feasibility Study Feasibility Report Requirements Analysis Requirements Definition System Models Requirements Specification Definition of Requirements Requirements Document Specification of Requirements
Requirements Analysis Methods for data modeling and design • Data flow diagrams • Entity-relation diagrams • Data dictionaries • Object models Many of these methods blur the distinction between analysis and design.
Entity-Relation Model A Design Methodology for Relational Databases • A database of entities and relations • Tools for displaying and manipulating entityrelation diagrams • Tools for manipulating the database (e.g., as input to database design) Warning: There is much confusion about definitions and notation
Entity-Relation Diagram An entity A relation between entities An entity or relation attribute An inheritance relation
Example: CS 501 Project Major Client 1 Student Project 1 CS501 Student 5 to 7 Member of 0:n Person 0:n 0:n Tech contact
MARC Format for Monographs (Books) 001 245 260 650 650 700 89-16879 r93 Campus strategies for libraries and electronic information {Bedford, Mass.} : Digital Press, c1990. Academic libraries--United States--Automation. Libraries and electronic publishing--United States. Arms, Caroline R. (Caroline Ruth)
Entity-Relation Diagram for MARC Book 0:n 1 0:n Describes 0:n Catalog record Short title 1:n Author of Editor of Is about Control numb 0:n Creator 0:n 0:n Subject heading
Data Dictionaries A data dictionary is a list of names used by the system • Brief definition (e.g., what is "date") • What is it (e.g., number, relation) • Where is it used (e.g., source, used by, etc.) • May be combined with a glossary As the system is implemented, the data dictionary in the requirements is input to the system data dictionary, which is a formal part of the system specification.
A Note on Object Models This course teaches object models as a tool for design. Some people recommend object models for requirements analysis, but it is difficult to use them without constraining the system design.
Non-Functional Requirements Product requirements performance, reliability, portability, etc... Organizational requirements delivery, training, standards, etc... External requirements legal, interoperability, etc...
Examples of Non-Functional Requirements Privacy (Mercury digital library) Functional requirement: Usage data for management of system Non-functional requirement: Usage data must not identify individuals Minimizing records (NeXT) Functional requirement: Retain all required records Non-functional requirement: Discard all other records
Unspoken Requirements Example: Resistance to change at XXX
Requirements Specification What is the purpose of the Requirements Specification?
Requirements Specification: Purpose 1. It describes the requirements to the stakeholders • Expressed in the terms that the stakeholders understand • Comprehensible from many viewpoints • Reviewed by stakeholders so that they understand implications • Must be clear about assumptions (things left out)
Requirements Specification: Purpose 2. It describes the requirements to the implementers • As precise and specific as possible • Expressed in terms that they understand • Comprehensible to new team members
Requirements Specification: Purpose 3. It records the requirements for the future • An essential part of system evolution 4. If may be a contractual document • See you in court!
Requirements Specification: Approaches • Natural language • Structured natural language • Design description language • Requirements specification language • Graphical notation • Formal specification See Sommerville, Chapter 7.
CS 501: Software Engineering Lecture 7 Management II Business and Legal Aspects of Software Engineering
Legal Environment Software is developed in a complex legal and economic framework. Changes in laws follow changes in technical world. Jurisdictions: • • • • • • Vietnamese laws International treaties Federal and state statues Precedents Supreme Court Cost of establishing precedent
Legal Topics • International • Intellectual property (copyright, patent, contract) • Tort (e.g., liability of Internet service provider) • Privacy • Free speech and its limitations (government secrets, obscenity, blasphemy, hate) Legal Information Institute: http://www.law.cornell.edu/
Copyright A copyright gives the owner the exclusive right to: • reproduce • distribute • perform • display • license Gradually extended to cover text, music, photographs, designs, software, ...
Copyright Copyright at creation • • • • • Works for hire Contracts and licenses First sale Fair use Infringement (contamination) International differences • Moral rights • Copyright registration
Software Patents • Should be: non-obvious, novel, useful • 17 years from award (20 years from application) • Poor quality of examining can lead to broad patents for routine computing concepts • International differences Copyright applies to the expression of ideas, patents to the ideas themselves.
Contracts and Licences Contracts allow intellectual property to be sold or licensed • • • • • • • Promise in exchange for adequate consideration Written document with signature Permanent or temporary, whole or part Exclusive or non-exclusive Termination, problems and difficulties Terms and conditions as agreed Enforceable by courts
Derivative Works When software is derived from other software: • New code is owned by new developer • Conditions that apply to old code apply to derived work If you write S, which is derived from A, B, C and D, you can not distribute or licenses S unless you have right to distribute each of A, B, C and D. To create a software product, you must have documented rights to use every component.
Privacy Invasions of privacy: • • • • intrusion appropriation of name or likeness unreasonable publicity false light Be very careful about collecting personal data without the knowledge of the individual
Software Business Questions • You are employed for company X writing software. When you leave, who owns your work? What use can you make of the work? • You work free-lance for company X. When you finish, who owns your work? What use can you make of the work? • Read the contract!
Your Next Job ... • Employment contract may restrict your next job (not working for competitors, etc.) • Trade-secret information (non-disclosure agreement) Ask when you are interviewed!
Trade Secrets and Non-Disclosure Agreements Trade Secret "... information, including a formula, pattern, compilation, program, device, method, technique, or process that derives independent economic value from not being generally known and not being readily ascertainable and is subject to reasonable efforts to maintain secrecy." Uniform Trade Secrets Act Non-Disclosure Agreement Legal agreement not to disclose trade secrets.
Some Business Models • Software developed in-house • Package licensed to customer, binary only (Microsoft model) • Package licensed to customer, source code for customer's modifications • Bespoke software for customer (may be owned by supplier or customer) • Software bundled with hardware product (PalmPilot)
Free-Lance Software Development You and a few friends create a company to develop software. How much should you charge per hour? You plan to work 40 hours a week for 50 weeks of the year and want to earn $50,000. Hourly rate = $50,000 / (40 x 50) = $25 But ...
Free-Lance Software Development Salary Taxes and benefits Rent, equipment, etc. Fees, services, etc. Travel and misc. TOTAL EXPENSE Hours worked less administration less marketing BILLABLE HOURS $50,000 $15,000 $10,000 $15,000 $10,000 $100,000 2,000 400 350 1,250 Hourly rate = $100,000 /1,250 = $80
Fixed and Variable Cost: Packaged Software Example: • The initial development cost of a software product is $10 million. • The cost of packaging and distribution of each copy is $5. • Technical support costs average $15 per copy. • The package sells for $200 per copy. Fixed cost = $10 million Variable cost = $20
Fixed and Variable Costs: Profit or Loss $15M $10M $5M 2,500 5,000 7,500 Unit sales
Community Development • Shareware • Open source (e.g., Linux, Apache, Perl, etc.) -> Shared development -> Market penetration Example: TCP/IP for Vax/VMS Software may be open source, but packaging and services can be profitable businesses
Open Source • Free redistribution • Source code • Derived works • Integrity of the author's source code • No discrimination against persons or groups
Open Source • No discrimination against fields of endeavor • Distribution of license • License must not be specific to a product • License must not contaminate other software http://www.opensource.org/osd.html
Practical Advice Be aware of the law, but do not pretend to be a lawyer. Use a professional for: • Contracts and licenses • Troubles (complaints, injunctions, subpoenas, etc.) • Personnel issues • When in doubt, ask help!
Source Code Management Or Configuration Management: How I learned to Stop Worrying and Hate My Co-workers Less
Source Code Management  Also known as Configuration Management  Source Code Managers are tools that: – Archive your development files – Serve as a single point of entry/exit when adding or updating development files
Why You Want A Source Control System  Supports concurrent development  Manage diverging source code bases  Records file/release versions  Easy access to all previous revisions  Can record why a revision was made  Optimal disk space usage  You’ll end up doing something equivalent anyway so it may as well be automated
Source Code Management Tools Are Not  A substitute for project management  A replacement for developer communication
How They Work  Central database of source code, documentation, build tools  Each file stored only once - all other versions are diffs of that one copy  To Make a Change – Check out the latest version of a file – Make the changes – Update the database
What should be in the database  Source Code  Documentation  Build Tools – Often need old versions of the tools to build old versions of the software – Ensures software is rebuilt exactly as the customer received it  Test Suites  Anything else you might want later
Version Control  Companies ship several products from the same source base (i.e. Win NT and Windows 2000 versions of MS Office)  When tracking down bugs you want to examine the code as it was when the product shipped
Code Sharing  Multiple people can work on the same source base without colliding – (1) Locks individual files so only one person at a time can modify it *OR* – (2) Allows multiple people to modify a source file and the system will automatically merge the changes (usually)
Locking  Only one person can work on a file at once  Works fairly well if developers work on different areas of the project and don’t conflict often  Problem 1: People forget to unlock files when they are done  Problem 2: People work around locking by editing a private copy and checking in when the file is finally unlocked - easy to goof and lose changes
Merging  Several people can work on a file at once  Before committing changes, each user merges their copy with the latest copy in the database – This is normally done automatically by the system and usually works, but you should not blindly accept the result of the merge
Labeling  Label all the files in the source base that make up a product at each milestone  Just before and just after a major change (e.g.. changing several interfaces)  When a new version ships
Version Trees  Each file in the database has a version tree  Can branch off the version tree to allow separate development paths  Typically a main path (trunk) for the next major version and branches off of shipped versions for maintenance
Branching  When a new version ships, typically create a branch in the version tree for maintenance  Double update: fix a defect in the latest version and then merge the changes (often by hand) into the maintenance version  Also create personal versions so you can make a change against a stable source base and then merge in the latest version later
Examples  RCS – Solaris: man rcsintro  CVS – Solaris: man cvs – www.cyclic.com/cvs/info.html  Visual SourceSafe – msdn.microsoft.com/SSAFE  ClearCase – www.rational.com
RCS  File management only  Transaction model – check out and lock – edit – check in and unlock  Little support for binaries
CVS  Built on top of RCS – Therefore little support for binaries  Database can be remote  No locking: merge before commit  Fast  Integrates with emacs
SourceSafe  Microsoft’s entry into the field  Project-based  Checkout-edit-checkin model  Built-in web site creation tools  Integrates with MSDEV
Clearcase  Clearcase is configuration management on steroids  You create a view of the database with a config spec, which describes how to select files from the database.  When you set a view, Clearcase creates a virtual filesystem containing only those versions of the files selected by the config spec
Clearcase Features  Distributed System – Several groups at different locations can work on the same database  Can install triggers – Example: e-mail the author of a file when some one makes a change to it  Uses merging model like CVS, but can also lock files
More Clearcase Features  Integrates with MSDEV  Build Management – Knows to rebuild out-of-date files even if your makefile doesn’t  Slow and a bit buggy
Helpful Rules for Version Control Bliss  Archived Files Should Always Compile  Code Review Files Before Check-in  Compile and run latest archived files *as a set* before Check-in  No Cheating (even “simple bug fixes” need to undergo this process)
Software Engineering Lecture 10 Formal Specification
Formal Specification Why? • Precise standard to define and validate software Why not? • May be time consuming • Methods not suitable for all applications
Formal Specification Ben Potter, Jane Sinclair, David Till, An Introduction to Formal Specification and Z (Prentice Hall) 1991 Jonathan Jacky The Way of Z (Cambridge University Press) 1997
Mathematical Specification Example of specification B1, B2, ... Bk is a sequence of m x m matrices η1, η2, ... ηk is a sequence of m x m elementary matrices B1-1 = η1 B2-1 = η2η1 Bk-1 = ηk ... η2η1 The numerical accuracy must be such that, for all k, BkBk-1 - I < ∆
Specification of Programming Languages <unsigned number> ::= <unsigned integer> | <unsigned real> <unsigned integer> ::= <digit> {<digit>} <unsigned real> ::= <unsigned integer> . <digit> {<digit>} | <unsigned integer> . <digit> {<digit>} E <scale factor> | <unsigned integer> E <scale factor> <scale factor> ::= <unsigned integer> | <sign> <unsigned integer> <sign> ::= + | Pascal number syntax
Formal Specification Using Diagrams unsigned integer digit unsigned number unsigned integer + . digit unsigned integer E -
Two Rules • Formal specification does not guarantee correctness • Formal specification does not prescribe the implementation
Example: Z Specification Language Informal: The function intrt(a) returns the largest integer whose square is less than or equal to a. Formal (Z): intrt: N N a : N• intrt(a) * intrt(a) < a < (intrt(a) + 1) * (intrt(a) + 1)
Example: Algorithm 1 + 3 + 5 + ... (2n - 1) = n2
Example: Program int intrt (int a) /* Calculate integer square root */ { int i, term, sum; term = 1; sum = 1; for (i = 0; sum <= a; i++) { term = term + 2; sum = sum + term; } return i; }
Finite State Machine A broadly used method of formal specification: • Event driven systems (e.g., games) • User interfaces • Protocol specification etc., etc., ...
Finite State Machine Example: Therapy control console [informal description]
State Transition Diagram Select field Enter Patients Enter Fields Start (ok) Setup Beam on Ready Stop (interlock) Select patient
State Transition Table Select Select Enter Patient Field Patients Fields Patients Setup Patients Fields Ready Patients Fields Beam on ok Start Stop interlock Fields Setup Ready Beam on Setup Ready Setup
Z Specification STATE ::= patients | fields | setup | ready | beam_on EVENT ::= select_patient | select_field | enter | start | stop | ok | interlock FSM == (STATE X EVENT) STATE no_change, transitions, control : FSM Continued on next slide
Z Specification (continued) control = no_change transitions no_change = { s : STATE; e : EVENT • (s, e) transitions = { (patients, enter) (fields, select_patient) s} fields, patients, (fields, enter) setup, (setup, select_patient) patients, (setup, select_field) (setup, ok) ready, fields, (ready, select_patient) patients, (ready, select_field) fields, (ready, start) beam_on, (ready, interlock) setup, (beam_on, stop) ready, (beam_on, interlock) setup }
Schemas Schema: • The basic unit of formal specification. • Describes admissible states and operations of a system.
LibSys: An Example of Z Library system: • Stock of books • Registered users. • Each copy of a book has a unique identifier. • Some books on loan; other books on shelves available for loan. • Maximum number of books that any user may have on loan.
LibSys: Operations • Issue a copy of a book to a reader. • Reader return a book. • Add a copy to the stock. • Remove a copy from the stock. • Inquire which books are on loan to a reader. • Inquire which readers has a particular copy of a book. • Register a new reader. • Cancel a reader's registration.
LibSys Level of Detail: Assume given sets: Copy, Book, Reader Global constant: maxloans
Schemas Describing Operations Naming conventions for objects: Before: plain variables, e.g., r After: with appended dash, e.g., r' Input: with appended ?, e.g., r? Output: with appended !, e.g., r!
Operation: Issue a Book • Inputs: copy c?, reader r? • Copy must be shelved initially: c? ∈ shelved • Reader must be registered: r? ∈ readers • Reader must have less than maximum number of books on loan: #(issued  {r?}) < maxloans • Copy must be recorded as issued to the reader: issued' = issued ⊕ {c? r?} • The stock and the set of registered readers are unchanged: stock' = stock; readers' = readers
Domain and Range X ran m y dom m x m:X Y Y dom m = { x ∈ X : ∃ y ∈ Y ∧ x y} ran m = { y ∈ Y : ∃ x ∈ X ∧ x y}
Operation: Issue a Book Issue stock, stock' : Copy issued, issued' : Copy Book Reader shelved, shelved': F Copy readers, readers' : F Reader c?: Copy; r? :Reader [See next slide]
Operation: Issue a Book (continued) Issue [See previous slide] shelved ∪ dom issued = dom stock shelved' ∪ dom issued' = dom stock' shelved ∩ dom issued = Ø; shelved' ∩ dom issued' = Ø ran issued ⊆ readers; ran issued' ⊆ readers' ∀r : readers • #(issued  {r}) < maxloans ∀r : readers' • #(issued'  {r}) < maxloans c? ∈ shelved; r? ∈ readers; #(issued  {r?}) < maxloans issued' = issued ⊕ {c? r?} stock' = stock; readers' = readers
LibSys: Schema for Abstract States Library stock : Copy Book issued : Copy Reader shelved : F Copy readers: F Reader shelved ∪ dom issued = dom stock shelved ∩ dom issued = Ø ran issued ⊆ readers ∀r : readers • #(issued  {r}) < maxloans
Schema Inclusion LibDB stock : Copy Book readers: F Reader LibLoans issued : Copy Reader shelved : F Copy ∀r : Reader • #(issued  {r}) < maxloans shelved ∩ dom issued = Ø
Schema Inclusion (continued) Library LibDB LibLoans dom stock = shelved ∪ dom issued ran issued ⊆ readers
Schema Decoration Issue Library Library' c? : Copy; r? : Reader c? ∈ shelved; r? ∈ readers #(issued  {r?}) < maxloans issued' = issued ⊕ {c? r?} stock' = stock; readers' = readers
Schema Decoration Issue ∆Library c? : Copy; r? : Reader c? ∈ shelved; r? ∈ readers #(issued  {r?}) < maxloans issued' = issued ⊕ {c? r?} stock' = stock; readers' = readers
The Schema Calculus Schema inclusion Schema decoration Schema disjunction: ^ AddCopy = AddKnownTitle ∨ AddNewTitle Schema conjunction: ^ AddCopy = EnterNewCopy ∧ AddCopyAdmin Schema negation Schema composition
Software Engineering Lecture 11 Object-Oriented Design I
What is in a Requirements Document? Example (Web Butler and Web Site Profiler) • Run web data collection in real time or batch mode How are jobs started? • Job parameters How are the parameters set up (interactive, edit file, ...)? What are the parameters (specify)? Can job parameters be stored and used again? If so, how? • Job monitoring What feedback is given while job is running? Can the user pause or break a job? If so, are the results retained?
What is in a Requirements Document? Remember • The requirements document specifies the functionality that you plan to deliver to the client • It must be comprehensive and detailed. Everything must be written out -- no hand waving! The requirements document is likely to be several times as long as Assignment 1.
Assignment 2 -- Individual Parts One approach: With your document, include a list of who contributed what part to the Requirements study, e.g., Person A Requirements analysis for database design (member of team of 3), wrote Section 3.1 of document, worked with client to identify software needs. Person B Prepared visual aids for presentation, edited entire document, specified the security needs and wrote Section 4.2.
The Waterfall Model Requirements Definition System and Software design Implementation and Unit Testing Integration and System Testing Operation and Maintenance
Useful Texts Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999. Grady Booch, Object-Oriented Analysis and Design with Applications, second edition. Benjamin/Cummings 1994. Rob Pooley, Perdita Stevens, Using UML Software Engineering with Objects and Components. Addison-Wesley 1999.
The Importance of Modeling • A model is a simplification of reality. • We build models so that we can better understand the system we are developing. • We build models of complex system because we cannot comprehend such a system in its entirety. Models can be informal or formal. The more complex the project the more valuable a formal model becomes. BRJ
Principles of Modeling • The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. • Every model can be expressed at different levels of precision. • The best models are connected to reality. • No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models. BRJ
The Unified Modeling Language UML is a standard language for modeling software systems. • Serves as a bridge between the requirements specification and the implementation. • Provides a means to specify and document the design of a software system. • Is process and programming language independent. • Is particularly suited to object-oriented program development.
Notation: Classes Window origin size open() close() move() display() name attributes operations A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.
Notation: Interface ISpelling An interface is a collection of operations that specify a service of a class or component, i.e., the externally visible behavior of that element.
Notation: Collaboration & Use Case Chain of responsibility A collaboration defines an interaction, i.e., a society of roles and other elements that work together to provide some cooperative behavior. Place order A use case is a description of a set of sequence of actions that a system performs that yields an observable result.
Notation: Active Class EventManager eventlist suspend() flush() An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity.
Notation: Component & Node orderform.java A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Server A node is a physical element that exists at run time and represents a computational resource.
Notation: Behavioral Things: Messages & States display An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. Waiting A state machine is a behavior that specifies the sequence of states an object or an interaction goes through during its lifetime in response to events.
Notation: Grouping and Annotation Business rules A package is a general-purpose mechanism for organizing elements into groups. return copy of self A note is a symbol for rendering constraints and comments attached to an element or a collection of elements.
Notation: Relationships A dependency is a semantic relationship between two things in which a change to one may effect the semantics of the other. 0..1 employer * employee An association is a structural relationship that describes a set of links, a link being a connection among objects.
Notation: Relationships (continued) child parent A generalization is a specialization/generalization relationship is which objects of the specialized element (child) are substitutable for objects of the generalized element (parent). A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.
Diagrams in UML A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships). • Class diagram shows a set of classes, interfaces, and collaborations with their relationships. • Object diagram shows a set of objects and their relationships. • Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.
Diagrams in UML (continued) • Interaction diagram shows an interaction, consisting of a set of objects and the relationships, including the messages that may be dispatched among them. => A sequence diagram emphasizes the time ordering. => A collaboration diagram emphasizes the structural organization of the objects that send and receive messages.
Diagrams in UML (continued) • Statechart diagram shows a state machine consisting of states, transitions, events, and activities. • Activity diagram is a statechart diagram that shows the flow from activity to activity within a system. • Component diagram shows the organization and dependencies among a set of components. • Deployment diagram shows the configuration of processing nodes and the components that live on them.
The HelloWorld Example class name HelloWorld operations paint()
Abstraction for HelloWorld class name HelloWorld operations paint() annotation g.drawString ("HelloWorld", 0, 10)"
The "Hello, World" Example import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) { g.drawString ("Hello, World!", 10, 10); } } Example from: BJR
Class Diagram Applet generalization Note that the Applet and Graphics classes are shown elided. HelloWorld paint() dependency Graphics
Class Inheritance Diagram Object Panel interface Component ImageObserver Applet Container HelloWorld
Packaging Classes java HelloWorld applet Graphics awt lang package
Notation for Classes and Objects Classes AnyClass attribute1 attribute2 operation1() operation2() or AnyClass Objects anObject:AnyClass or :AnyClass or anObject The names of objects are underlined.
Software Engineering Lecture 12 Object-Oriented Design II
Requirements: 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, ...)
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?
Modeling Classes Given a real-life system, how do you decide what classes to use? • What terms do the users and implementers use to describe the system? They are candidates for classes. • Is each candidate class crisply defined? • For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes? • What attributes and operations does each class need to carry out its responsibilities?
Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others 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. The system must keep track of when books and journals are borrowed and returned and enforce the rules.
Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others 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. The system must keep track of when books and journals are borrowed and returned and enforce the rules.
Candidate Classes Library Book Journal Copy ShortTermLoan LibraryMember Week MemberOfLibrary Item Time MemberOfStaff System Rule the name of the system event measure repeat book or journal abstract term general term general term
Relations between Classes Book Journal Copy LibraryMember Item MemberOfStaff Is Item needed? is an is an is a copy of a Item Item Book is a LibraryMember
Operations LibraryMember borrows Copy LibraryMember returns Copy MemberOfStaff borrows Journal MemberOfStaff returns Journal Item not needed yet.
Class Diagram MemberOfStaff LibraryMember 1 1 on loan on loan 0..12 Journal 0..* Copy is a copy of 1..* 1 Book
Rough Sketch: Wholesale System A wholesale merchant supplies retail stores from stocks of goods in a warehouse. What classes would you use to model this business?
Rough Sketch: Wholesale System RetailStore Order Merchant Product Warehouse Invoice Shipment
Rough Sketch: Wholesale System RetailStore name address contactInfo financialInfo Merchant Warehouse Order Product Reversals Invoice Shipment damaged() return() wrongItem() Responsibilities -track status of shipped products responsibility (text field)
Expanding a Class: Modeling Financial Information RetailStore association 1 * Transaction Which class is responsible for the financial records for a store? Payment Invoice
Modeling Invoice Shipment ??? RetailStore invoiceRecord goodsShipped Invoice invoiceNumber adornments +goodsShipped() + public -sendInvoice() - private PartsList
Lessons Learned Design is empirical. There is no single correct design. During the design process: • Eliding: Elements are hidden to simplify the diagram • Incomplete: Elements may be missing. • Inconsistency: The model may not be consistent The diagram is not the whole design. Diagrams must be backed up with specifications.
Levels of Abstraction The complexity of a model depends on its level of abstraction: • High-levels of abstraction show the overall system. • Low-levels of abstraction are needed for implementation. Two approaches: • Model entire system at same level of abstraction, but present diagrams with different levels of detail. • Model parts of system at different levels of abstraction.
Component Diagram hello.hml executable component HelloWorld.class hello.jpg hello.java
Actor and Use Case Diagram BookBorrower Borrow book • 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.
Use Cases and Actors • A scenario is an instance of a use 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 Extend loan Return copy of book Reserve book
Relationships Between Use Cases: <<uses>> Extend loan BookBorrower Borrow copy of book <<uses>> <<uses>> Check for reservation
Relationships Between Use Cases: <<extends>> BookBorrower <<extends>> Borrow copy of book Refuse loan
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
Software Engineering Lecture 13 Object-Oriented Design III
Comments on Presentations Presentation • Standard of graphics has been high • Some text too small (diagrams, screen dumps) Content • Level of detail • Requirements v. design The client defines the requirements Well done, but time is short. What is your critical path?
Modeling Dynamic Aspects of Systems Interaction diagrams: set of objects and their relationships including messages that may be dispatched among them • Sequence diagrams: time ordering of messages • Collaboration diagrams: structural organization of objects that send and receive messages Activity diagram: flow chart showing flow of control from activity to activity Statechart diagram: models a state machine
Bouncing Ball Diagrams Example: http://www.cs.cornell.edu/ domain name TCP connection HTTP get Client Servers
Actions on Objects call returnCopy(c) okToBorrow() return send create destroy local status notifyReturn(b) asynchronous signal <<create>> <<destroy>> stereotypes
Links LibraryMember 1 on loan 0..* Copy association +borrowCopy() +returnCopy() class libMem:LibraryMember object message borrowCopy(c) link c:Copy
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 BookBorrower theBook:Book theCopy:Copy borrow(theCopy) okToBorrow borrow borrow
Class Inheritance Diagram Object Panel interface Component ImageObserver Applet Container HelloWorld
Sequence Diagram:Painting Mechanism :Thread run :Toolkit run :ComponentPeer callbackLoop handleExpose paint target:HelloWorld
Activity Diagram: Process Modeling Release work order branch [materials not ready] [materials ready] Assign tasks Reschedule guard expression
Activity Diagram: Parallel Activities start state Decompress fork Stream video join stop state Stream audio
State Diagram returned() not borrowable returned() borrowable borrowed()[last copy] guard expression borrowed()[not last copy] State diagram for class Book
Implementation Modeling Subsystem A grouping of elements that specifies what a part of a system should do. Component (UML definition) "A distributable piece of implementation of a system, including software code (source, binary, or executable) but also including business documents, etc., in a human system." A component can be thought of as an implementation of a subsystem.
Component Diagram hello.hml executable component HelloWorld.class hello.jpg hello.java
Components and Classes agent.dll AgentAction PatternSearch Policy
Components and Classes agent.dll Realizes AgentAction PatternSearch Policy extended component
Components and Classes Classes represent logical abstractions. Components represent physical things. Components may live on nodes. Classes have attributes and operations directly. Components have operations that are reachable only through interfaces.
Interfaces render.java simulation.exe IRender dependency realization interface
Application Programming Interface (API) API is an interface that is realized by one or more components. simulation.exe IRender IModels ILighting
Components and Replaceability Components allow system to be assembled from binary replaceable elements. • A component is physical -- bits not concepts • A component can be replaced by any other component(s) that conforms to the interfaces. • A component is part of a system. • A component provides the realization of a set of interfaces.
Software Engineering Lecture 14 System Architecture I Data Intensive Systems
System Architecture The overall design of a system: • • • • • • Computers and networks (e.g., monolithic, distributed) Interfaces and protocols (e.g., http, CORBA) Databases (e.g., relational, distributed) Security (e.g., smart card authentication, SSL) Operations (e.g., backup, archiving, audit trails) Software environments (e.g., languages, source control tools)
Data Intensive Systems Examples • Electricity utility customer billing • Telephone company call recording and billing • Car rental reservations (e.g., Hertz) • Stock market brokerage (e.g., Charles Schwab) • Web sales (e.g., Amazon.com)
Example 1: Electricity Utility Billing First attempt: Transaction Data input Master file Each transaction handled as it arrives. Bill
Criticisms of First Attempt Where is this first attempt weak? The requirements have not been specified!!!
Transaction Types • • • • • • • • Create account / close account Meter reading Payment received Other credits / debits Check cleared / check bounced Account query Correction of error etc., etc., etc.,
Typical Requirements • All payments to be credited on day received • Customers must be able to query account by telephone • Cutting off service for non-payment requires management authorization • Data input staff should process n transactions per day per person • Error rate must be below 0.01% • System available 99.9% of business hours
Batch Processing: Validation errors Edit & validation Incoming transactions Data input read only Master file Validated transactions
Batch Processing: Master File Update Validated transactions in batches errors Reports Sort by account Master file update Bills Instructions
Benefits of Batch Updating • All transactions for an account are processed together • Backup and recovery have fixed checkpoints • Better management control of operations • Efficient use of staff and hardware
Online Inquiry Customer service read only Transactions Data input Master file Bills
Example 2: A Small-town Stockbroker • Transactions Received by mail or over telephone For immediate or later action • Complex customer inquiries • Highly competitive market
A Database Architecture Database(s): • Customer and account database • Financial products (e.g., account types, pension plans, savings schemes) • External databases (e.g., stock markets, mutual funds, insurance companies)
Database Architecture Products & services database Customer & account database External services
Real-time Transaction Real-time transactions Products & services database Customer & account database External services
Real-time Transactions & Batch Processing Real-time transactions Products & services database Data input Batch processing Customer & account database External services
Architectural considerations • Real-time service during scheduled hours + batch processing overnight • Combine information from several databases • Database consistency after any type of failure two-phase commit reload from checkpoint + log detailed audit trail • How will transaction errors be avoided? • How will transaction errors be corrected?
Example: Merger of Two Banks Each bank has a database with its customer accounts. The databases are used by staff at many branches and for back-office processing. The requirement is to integrate the two banks so that they appear to the customers to be a single organization and to provide integrated service from all branches.
Merger of Two Banks: Options A ??? ??? B
Merger of Two Banks: Architectural Options I. Convert everything to System A. convert databases retrain staff enhance System A (software and hardware) discard System B II. Build an interface between the databases in System A and System B. III. Extend client software so that it can interact with either System A or System B database.
Distributed Computing: General Problem An application that is running on one computer wishes to use data or services provided by another: • Network connection private, public, or virtual private network location of firewalls • Protocols point-to-point, multicast, broadcast message passing, RPC, distributed objects stateful or stateless • Quality of service
Network Choices Public Internet: Ubiquitous -- worldwide Low cost Private network: Security Predictable performance Choice of protocols (e.g., IBM's SNA)
Quality of Network Services Performance Maximum throughput Variations in throughput Real-time media (e.g., audio) Business Suppliers Trouble shooting and maintenance Upgrades
Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
Software Engineering Lecture 15 System Architecture II Distributed and Real Time Systems
Comments on Requirements Report Audience • • Client and design team Will be updated over time Content • • • Level of detail -- will be used to validate the implementation Requirements, not design Precise, but not legalistic
Sequence Diagram: Notation libMem: LibraryMember BookBorrower theBook:Book theCopy:Copy borrow(theCopy) okToBorrow borrow borrow dotted line shows object lifetime rectangle shows focus of control
Sequence Diagram: Branching libMem: LibraryMember theCopy:Copy BookBorrower 1:borrow(theCopy) [not ok]3:noborrow branch theBook:Book 2:okToBorrow [ok]3:borrow 4:borrow
Example: Distributed Database two copies of the same data
Distributed Data and Replication Distributed Data Data is held on several computer systems. A transaction may need to assemble data from several sources. Replication Several copies of the data are held in different locations. Mirror: Complete data set is replicated Cache: Dynamic set of data is replicated (e.g., most recently used) With replicated data, the biggest problem is consistency.
Example: Broadcast Search User User interface server Databases
Example: UseNet
Stateless Protocol v. Stateful Stateless protocol Example: http Open connection Send message Return reply Close connection State in http must be sent with every message (e.g., as parameter string or in a cookie)
Stateless Protocol v. Stateful Stateful (session) protocol Example: Z39.50 Open connection Begin session Interactive session End session Close connection Server remembers the results of previous transactions (e.g., authentication, partial results) until session is closed.
Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
The Domain Name System First attempt to resolve www.cs.cornell.edu .edu server 1 2 3 cornell.edu server cs.cornell.edu server
Discussion of the First Attempt Problems?
The Domain Name System Better method local DNS server 1 almaden.ibm.com cornell.edu Local ece.cmu.edu cache ibm.com acm.org .edu .edu server 2 cornell.edu server 3 cs.cornell.edu server
Real Time System A real time system is a software system whose correct functioning depends upon the results produced and the time at which they are produced. • A soft real time system is degraded if the results are not produced within required time constraints • A hard real time system fails if the results are not produced within required time constraints
Example: Web Server http message daemon TCP port 80 spawned processes The daemon listens at port 80. When a message arrives it: spawns a processes to handle the message returns to listening at port 80
Embedded Systems Software and hardware are combined to provide an integrated unit, usually dedicated to a specific task: • Digital telephone • Automobile engine control • GPS • Scientific instruments The software may be embedded in the device in a manner that can not be altered after manufacture.
Example: Autonomous Land Vehicle GPS Steer Sonar Model Laser Control signals Throttle Controls Sensors Signal processing
Other Applications Response critical • Network router • Telephone switch • Seat bag controller Shared systems • Multi-user data processing • Time sharing
Techniques • Special purpose hardware • Multi-threading and multi-tasking • Parallel processing => digital signal processing • Interrupts => levels and priorities
Multi-Threading Several similar threads operating concurrently: • Re-entrant code -- separation of pure code from data for each thread • Testing -- single thread and multi thread May be real time (e.g., telephone switch) or nontime critical
Real Time Executive Schedules and dispatches tasks in a real time system • Real time clock • Interrupt handler • Scheduler • Resource manager • Dispatcher Must be extremely reliable
Timing Timing mechanisms • Synchronous (clocked) -- periodic stimuli • Asynchronous -- wait for next signal Example: Communications protocols may be synchronous or asynchronous
Hardware v. Software Design of embedded systems requires close understanding of hardware characteristics • Special purpose hardware requires special tools and expertise. • Some functions may be implemented in either hardware of software (e.g., floating point unit) • Design requires separation of functions Distinction between hardware and software may be blurred.
Example: Dartmouth Time Shared System master processor Communications processor Communications processor I/O Mulitplexor Central processor Central processor Central processor
Software Considerations Resource considerations may dictate software design and implementation: • Low level language (e.g., C) where programmer has close link to machine • Inter-process communication may be too slow (e.g., C fork). • May implement special buffering, etc., to control timings
Example: CD Controller 4 Input block 7 3 2 5 6 Circular buffer 1 Output block
Continuous Operation Many systems must operate continuously • Software update while operating • Hardware monitoring and repair • Alternative power supplies, networks, etc. • Remote operation These functions must be designed into the fundamental architecture.
Routers and Other Network Computing • Interoperation with third party devices • Support for several versions of protocols • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads • Time outs, dropped packets, etc. • Evolution of network systems
Software Engineering Lecture 15 System Architecture II Distributed and Real Time Systems
Administration Assignment 2: Requirements • • • Grades -- presentation, report, individual Comments at presentation Comments from teaching assistant Assignment 3: Design
Comments on Requirements Report Audience • • Client and design team Will be updated over time Content • • • Level of detail -- will be used to validate the implementation Requirements, not design Precise, but not legalistic
Sequence Diagram: Notation libMem: LibraryMember BookBorrower theBook:Book theCopy:Copy borrow(theCopy) okToBorrow borrow borrow dotted line shows object lifetime rectangle shows focus of control
Sequence Diagram: Branching libMem: LibraryMember theCopy:Copy BookBorrower 1:borrow(theCopy) [not ok]3:noborrow branch theBook:Book 2:okToBorrow [ok]3:borrow 4:borrow
Example: Distributed Database two copies of the same data
Distributed Data and Replication Distributed Data Data is held on several computer systems. A transaction may need to assemble data from several sources. Replication Several copies of the data are held in different locations. Mirror: Complete data set is replicated Cache: Dynamic set of data is replicated (e.g., most recently used) With replicated data, the biggest problem is consistency.
Example: Broadcast Search User User interface server Databases
Example: UseNet
Stateless Protocol v. Stateful Stateless protocol Example: http Open connection Send message Return reply Close connection State in http must be sent with every message (e.g., as parameter string or in a cookie)
Stateless Protocol v. Stateful Stateful (session) protocol Example: Z39.50 Open connection Begin session Interactive session End session Close connection Server remembers the results of previous transactions (e.g., authentication, partial results) until session is closed.
Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
The Domain Name System First attempt to resolve www.cs.cornell.edu .edu server 1 2 3 cornell.edu server cs.cornell.edu server
Discussion of the First Attempt Problems?
The Domain Name System Better method local DNS server 1 almaden.ibm.com cornell.edu Local ece.cmu.edu cache ibm.com acm.org .edu .edu server 2 cornell.edu server 3 cs.cornell.edu server
Real Time System A real time system is a software system whose correct functioning depends upon the results produced and the time at which they are produced. • A soft real time system is degraded if the results are not produced within required time constraints • A hard real time system fails if the results are not produced within required time constraints
Example: Web Server http message daemon TCP port 80 spawned processes The daemon listens at port 80. When a message arrives it: spawns a processes to handle the message returns to listening at port 80
Embedded Systems Software and hardware are combined to provide an integrated unit, usually dedicated to a specific task: • Digital telephone • Automobile engine control • GPS • Scientific instruments The software may be embedded in the device in a manner that can not be altered after manufacture.
Example: Autonomous Land Vehicle GPS Steer Sonar Model Laser Control signals Throttle Controls Sensors Signal processing
Other Applications Response critical • Network router • Telephone switch • Seat bag controller Shared systems • Multi-user data processing • Time sharing
Techniques • Special purpose hardware • Multi-threading and multi-tasking • Parallel processing => digital signal processing • Interrupts => levels and priorities
Multi-Threading Several similar threads operating concurrently: • Re-entrant code -- separation of pure code from data for each thread • Testing -- single thread and multi thread May be real time (e.g., telephone switch) or nontime critical
Real Time Executive Schedules and dispatches tasks in a real time system • Real time clock • Interrupt handler • Scheduler • Resource manager • Dispatcher Must be extremely reliable
Timing Timing mechanisms • Synchronous (clocked) -- periodic stimuli • Asynchronous -- wait for next signal Example: Communications protocols may be synchronous or asynchronous
Hardware v. Software Design of embedded systems requires close understanding of hardware characteristics • Special purpose hardware requires special tools and expertise. • Some functions may be implemented in either hardware of software (e.g., floating point unit) • Design requires separation of functions Distinction between hardware and software may be blurred.
Example: Dartmouth Time Shared System master processor Communications processor Communications processor I/O Mulitplexor Central processor Central processor Central processor
Software Considerations Resource considerations may dictate software design and implementation: • Low level language (e.g., C) where programmer has close link to machine • Inter-process communication may be too slow (e.g., C fork). • May implement special buffering, etc., to control timings
Example: CD Controller 4 Input block 7 3 2 5 6 Circular buffer 1 Output block
Continuous Operation Many systems must operate continuously • Software update while operating • Hardware monitoring and repair • Alternative power supplies, networks, etc. • Remote operation These functions must be designed into the fundamental architecture.
Routers and Other Network Computing • Interoperation with third party devices • Support for several versions of protocols • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads • Time outs, dropped packets, etc. • Evolution of network systems
Software Engineering Lecture 16 System Architecture III Distributed Objects
Real-Time: Software Considerations Resource considerations may dictate software design and implementation: • Low level language (e.g., C) where programmer has close link to machine • Inter-process communication may be too slow (e.g., C fork). • May implement special buffering, etc., to control timings
Buffering Example: CD Controller 4 Input block 7 3 2 5 6 Circular buffer 1 Output block
Continuous Operation Many systems must operate continuously • Software update while operating • Hardware monitoring and repair • Alternative power supplies, networks, etc. • Remote operation These functions must be designed into the fundamental architecture.
Example: Routers and Other Network Computing • Interoperation with third party devices • Support for several versions of protocols • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads • Time outs, dropped packets, etc. • Evolution of network systems
Example: Transaction Monitor messages Transaction monitor processes A transaction monitor: monitors transactions, routes them across services, balances the load, restarts transactions after failure.
Software Reuse: Application Packages • Package supports a standard application (e.g., payroll, user interface to Internet information, mathematical algorithms) • Functionality can be enhanced by: => configuration parameters (e.g., table driven) => extensibility at defined interfaces => custom written source code extensions
Reuse: Object Object Oriented Languages Example: Java is a relatively straightforward language with a very rich set of class hierarchies. • Java programs derive much of their functionality from standard classes • Learning and understanding the classes is difficult. => Java experts can write complex systems quickly => Inexperienced Java programmers write inelegant and buggy programs
Reuse: Objects - Basic Definitions • An object is a piece of code that owns attributes and provides services through methods. • The methods operate on instance data owned by the object. • A class is a collection of like objects.
Reuse: Objects - Characteristics • Encapsulation. An object has a public interface that defines how other objects or applications can interact with it. methods public instance data • Inheritance. Subclasses can be derived from parent classes. They inherit or override the parents' methods and instance data. • Polymorphism. The effect of a method can vary depending on the class that implements it (e.g., display_object)
Reuse: Objects - Object Binding Binding is the linking of the software interface between two objects. • Static binding: The interface is determined at compile or build time. Straightforward Allows type checking • Dynamic binding or late binding: The link is established at run time. Flexible and extensible Complex
Reuse: Objects - Distributed Objects Objects on separate computers interact through method calls and instance data. Major systems: • CORBA (Common Object Request Broker Architecture) • Microsoft family: OLE, COM, DCOM, Active X ...
Desirable Properties of Distributed Objects • Different languages and operating environments • Reusable code: components • Architecture can be extensible • Future changes can be localized • Standard tools used for client/server interactions
Example: Fedora IDL A research project to explore extensibility: -- very simple Interface Definition Language -- powerful tools for extensions -- interoperability, Cornell and CNRI http://www.cs.cornell.edu/cdlrg/fedora.html
Object Request Broker (ORB) C C++ Cobol Objects IDL IDL IDL Interface IDL Java Client Other IDL Server Object Request Broker
Interface Definition Language module <identifier> { <type declarations>; <constant declarations>; <exception declarations>; Naming context interface <identifier> [:<inheritance>] { See next slide } interface <identifier> [:<inheritance>] { ..... } { Define a class Define a class
Interface Definition Language (continued) interface <identifier> [:<inheritance>] { <type declarations>; <constant declarations>; <exception declarations>; Define a class [<op_type] <identifier>(<parameters>) Define a method [raises exception] [context]; .... [<op_type] <identifier>(<parameters>) Define a method [raises exception] [context]; .... }
ORB: Programmer's View Client Invoke a on object X Server Invoke a on object Y Object X Object Y a a Object Request Broker
Object Request Broker (ORB) An ORB lets objects make requests to and receive response from other objects located locally or remotely. • Static and dynamic method invocations • High-level language bindings • Self-describing system • Local/remote transparency • Inter-ORB protocols Internet Inter-ORB Protocol (IIOP)
ORB: System View Interface repository Client Dynamic Client IDL ORB invocation stubs interface Object Implementation implementation repository Static Dynamic Object skeletons invocation adapter Object Request Broker
CORBA Services • • • • • • • • • • • • • Naming service Event service Concurrency control service Transaction service Relationship service Externalization service Query service Life cycle service Persistence service Licensing service Properties service Security service Time service
Distributed Objects and the System Life-Cycle All large systems change with time. • Dynamic binding of objects combined with polymorphism permits the addition of extra object types, incremental changes, etc. to be localized. Development environments change with time. • Language bindings and IIOP permit changes. Production environments changes with time. • Code can be reused in different environments.
Software Engineering Lecture 17 Design for Usability I
Q2: Finite State Machine The cruise control system on an automobile is controlled by a master switch and three buttons. Initially, it is turned on by the master switch. The master switch can be turned off at any time. When first turned on, the system enters stand-by mode. When the system is in stand-by mode, the driver of the automobile can press Button A to engage the cruise control at the current speed of the automobile. When the cruise control is engaged, if the driver presses the brake or presses Button B the system will be disengaged and return to stand-by mode. After returning to standby mode, the driver can press Button C to engage the cruise control at the speed that it was set at previously. (After the system is first turned on, Button C has no effect.) When the cruise control is engaged, the driver can press Button A to increase speed by one mile per hour or Button C to decrease speed by one mile per hour.
State Transition Diagram A C MS-On Off Standby A A Engaged C B-Brake MS-Off Standby1
State Transition Table MS on MS off A Standby Off Engaged Engaged Off Engaged Standby1 Engaged Standby1 Off Engaged Off B Brake C Standby Engaged
Question 4 When software is written, who owns the copyright? How can somebody else be permitted to use the software? How can copyright be transferred to somebody else?
Question 4 When software is written, who owns the copyright? The person who writes the software Except work for hire -- the employer How can somebody else be permitted to use the software? By permission from the copyright owner (usually a license) How can copyright be transferred to somebody else? Copyright is property that can be sold or given away (usually a contract)
Question 4 You are employed for company X writing software. When you leave, who owns your work? What use can you make of the work?
Question 4 You are employed for company X writing software. When you leave, who owns your work? The company (work for hire) What use can you make of the work? None without permission of the copyright owner
Question 4 You work free-lance for company X. When you finish, who owns your work? What use can you make of the work?
Question 4 You work free-lance for company X. When you finish, who owns your work? It depends on the circumstances Have a written contract What use can you make of the work? If you hold the copyright -- unrestricted Otherwise -- none without agreement
Distributed Objects and the System LifeCycle All large systems change with time. • Dynamic binding of objects combined with polymorphism permits the addition of extra object types, incremental changes, etc. to be localized. Development environments change with time. • Language bindings and IIOP permit changes. Production environments changes with time. • Code can be reused in different environments.
Design for Usability Usability of a computer system is a combination of factors: • User interface design • Functionality • Performance • Help systems and documentation • Freedom from errors Anything else?
Iterative Design Evaluation Requirements Implementation (prototype) Design
Methods for Evaluation of Usability • Observing users (user protocols) • Focus groups • Measurements effectiveness in carrying out tasks speed • Expert review • Client's opinions • Competitive analysis
Levels of Usability interface design conceptual model functional design data and metadata computer systems and networks
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn
Cnpm bkdn

Recomendados

Software Engineering concept
Software Engineering concept Software Engineering concept
Software Engineering concept Atamjitsingh92
 
Software engineering principles in system software design
Software engineering principles in system software designSoftware engineering principles in system software design
Software engineering principles in system software designTech_MX
 
Software Engineering - Basics
Software Engineering - BasicsSoftware Engineering - Basics
Software Engineering - BasicsPurvik Rana
 
[2015/2016] Software systems engineering PRINCIPLES
[2015/2016] Software systems engineering PRINCIPLES[2015/2016] Software systems engineering PRINCIPLES
[2015/2016] Software systems engineering PRINCIPLESIvano Malavolta
 
Software engineering note
Software engineering noteSoftware engineering note
Software engineering noteNeelamani Samal
 
Software Engineering Process Models
Software Engineering Process Models Software Engineering Process Models
Software Engineering Process Models Satya P. Joshi
 
Software design methodologies
Software design methodologiesSoftware design methodologies
Software design methodologiesDr. C.V. Suresh Babu
 
Software Engineering - Lecture 02
Software Engineering - Lecture 02Software Engineering - Lecture 02
Software Engineering - Lecture 02Asifuzzaman Hridoy
 

Recomendados

Software Engineering concept
Software Engineering concept Software Engineering concept
Software Engineering concept Atamjitsingh92
 
Software engineering principles in system software design
Software engineering principles in system software designSoftware engineering principles in system software design
Software engineering principles in system software designTech_MX
 
Software Engineering - Basics
Software Engineering - BasicsSoftware Engineering - Basics
Software Engineering - BasicsPurvik Rana
 
[2015/2016] Software systems engineering PRINCIPLES
[2015/2016] Software systems engineering PRINCIPLES[2015/2016] Software systems engineering PRINCIPLES
[2015/2016] Software systems engineering PRINCIPLESIvano Malavolta
 
Software engineering note
Software engineering noteSoftware engineering note
Software engineering noteNeelamani Samal
 
Software Engineering Process Models
Software Engineering Process Models Software Engineering Process Models
Software Engineering Process Models Satya P. Joshi
 
Software design methodologies
Software design methodologiesSoftware design methodologies
Software design methodologiesDr. C.V. Suresh Babu
 
Software Engineering - Lecture 02
Software Engineering - Lecture 02Software Engineering - Lecture 02
Software Engineering - Lecture 02Asifuzzaman Hridoy
 
Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software EngineeringMajane Padua
 
Ch03-Software Engineering Model
Ch03-Software Engineering ModelCh03-Software Engineering Model
Ch03-Software Engineering ModelBala Ganesh
 
SOFTWARE ENGINEERING
SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
SOFTWARE ENGINEERINGMahalakshmi Seenaswamy
 
Selection of methodology - System Analysis and Design
Selection of methodology - System Analysis and Design Selection of methodology - System Analysis and Design
Selection of methodology - System Analysis and Design Sutharshan Sharma
 
Software systems engineering PRINCIPLES
Software systems engineering PRINCIPLESSoftware systems engineering PRINCIPLES
Software systems engineering PRINCIPLESIvano Malavolta
 
SDLC
SDLCSDLC
SDLCPooja Chaddha
 
Notes of Software engineering and Project Management
Notes of Software engineering and Project ManagementNotes of Software engineering and Project Management
Notes of Software engineering and Project ManagementNANDINI SHARMA
 
Cs504 handouts 1_45
Cs504 handouts 1_45Cs504 handouts 1_45
Cs504 handouts 1_45Ahsan Younis
 
Pressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-modelsPressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-modelszeal123123
 
Chapter 01 software engineering pressman
Chapter 01 software engineering pressmanChapter 01 software engineering pressman
Chapter 01 software engineering pressmanRohitGoyal183
 
Slides chapter 3
Slides chapter 3Slides chapter 3
Slides chapter 3Priyanka Shetty
 
Software Engineering - Lecture 01
Software Engineering - Lecture 01Software Engineering - Lecture 01
Software Engineering - Lecture 01Asifuzzaman Hridoy
 
testing
testingtesting
testingnazeer pasha
 
Introduction,Software Process Models, Project Management
Introduction,Software Process Models, Project ManagementIntroduction,Software Process Models, Project Management
Introduction,Software Process Models, Project Managementswatisinghal
 
System Development Life Cycle
System Development Life CycleSystem Development Life Cycle
System Development Life Cyclesourav verma
 
Software process
Software processSoftware process
Software processAmisha Patel
 
Software development lifecycle
Software development lifecycleSoftware development lifecycle
Software development lifecycleRebecca Jones
 
Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Fadhil Ismail
 
PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)
PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)
PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)IrtazaAfzal3
 
Ch03 prescriptive process models
Ch03 prescriptive process modelsCh03 prescriptive process models
Ch03 prescriptive process modelsDr. C.V. Suresh Babu
 
Software Architecture Office Presentation by Walter Ariel Risi, 2006
Software Architecture Office Presentation by Walter Ariel Risi, 2006Software Architecture Office Presentation by Walter Ariel Risi, 2006
Software Architecture Office Presentation by Walter Ariel Risi, 2006Walter Ariel Risi
 
Ch1 it1 - v4.0 - 87.8%
Ch1 it1 - v4.0 - 87.8%Ch1 it1 - v4.0 - 87.8%
Ch1 it1 - v4.0 - 87.8%chikoecko
 

Mais conteúdo relacionado

Mais procurados

Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software EngineeringMajane Padua
 
Ch03-Software Engineering Model
Ch03-Software Engineering ModelCh03-Software Engineering Model
Ch03-Software Engineering ModelBala Ganesh
 
Selection of methodology - System Analysis and Design
Selection of methodology - System Analysis and Design Selection of methodology - System Analysis and Design
Selection of methodology - System Analysis and Design Sutharshan Sharma
 
Software systems engineering PRINCIPLES
Software systems engineering PRINCIPLESSoftware systems engineering PRINCIPLES
Software systems engineering PRINCIPLESIvano Malavolta
 
Notes of Software engineering and Project Management
Notes of Software engineering and Project ManagementNotes of Software engineering and Project Management
Notes of Software engineering and Project ManagementNANDINI SHARMA
 
Cs504 handouts 1_45
Cs504 handouts 1_45Cs504 handouts 1_45
Cs504 handouts 1_45Ahsan Younis
 
Pressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-modelsPressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-modelszeal123123
 
Chapter 01 software engineering pressman
Chapter 01 software engineering pressmanChapter 01 software engineering pressman
Chapter 01 software engineering pressmanRohitGoyal183
 
Software Engineering - Lecture 01
Software Engineering - Lecture 01Software Engineering - Lecture 01
Software Engineering - Lecture 01Asifuzzaman Hridoy
 
Introduction,Software Process Models, Project Management
Introduction,Software Process Models, Project ManagementIntroduction,Software Process Models, Project Management
Introduction,Software Process Models, Project Managementswatisinghal
 
System Development Life Cycle
System Development Life CycleSystem Development Life Cycle
System Development Life Cyclesourav verma
 
Software development lifecycle
Software development lifecycleSoftware development lifecycle
Software development lifecycleRebecca Jones
 
Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Fadhil Ismail
 
PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)
PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)
PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)IrtazaAfzal3
 

Mais procurados (20)

Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software Engineering
 
Ch03-Software Engineering Model
Ch03-Software Engineering ModelCh03-Software Engineering Model
Ch03-Software Engineering Model
 
SOFTWARE ENGINEERING
SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
SOFTWARE ENGINEERING
 
Selection of methodology - System Analysis and Design
Selection of methodology - System Analysis and Design Selection of methodology - System Analysis and Design
Selection of methodology - System Analysis and Design
 
Software systems engineering PRINCIPLES
Software systems engineering PRINCIPLESSoftware systems engineering PRINCIPLES
Software systems engineering PRINCIPLES
 
SDLC
SDLCSDLC
SDLC
 
Notes of Software engineering and Project Management
Notes of Software engineering and Project ManagementNotes of Software engineering and Project Management
Notes of Software engineering and Project Management
 
Cs504 handouts 1_45
Cs504 handouts 1_45Cs504 handouts 1_45
Cs504 handouts 1_45
 
Pressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-modelsPressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-models
 
Chapter 01 software engineering pressman
Chapter 01 software engineering pressmanChapter 01 software engineering pressman
Chapter 01 software engineering pressman
 
Slides chapter 3
Slides chapter 3Slides chapter 3
Slides chapter 3
 
Software Engineering - Lecture 01
Software Engineering - Lecture 01Software Engineering - Lecture 01
Software Engineering - Lecture 01
 
testing
testingtesting
testing
 
Introduction,Software Process Models, Project Management
Introduction,Software Process Models, Project ManagementIntroduction,Software Process Models, Project Management
Introduction,Software Process Models, Project Management
 
System Development Life Cycle
System Development Life CycleSystem Development Life Cycle
System Development Life Cycle
 
Software process
Software processSoftware process
Software process
 
Software development lifecycle
Software development lifecycleSoftware development lifecycle
Software development lifecycle
 
Software System Engineering - Chapter 1
Software System Engineering - Chapter 1Software System Engineering - Chapter 1
Software System Engineering - Chapter 1
 
PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)
PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)
PRESCRIPTIVE PROCESS MODEL(SOFTWARE ENGINEERING)
 
Ch03 prescriptive process models
Ch03 prescriptive process modelsCh03 prescriptive process models
Ch03 prescriptive process models
 

Destaque

Software Architecture Office Presentation by Walter Ariel Risi, 2006
Software Architecture Office Presentation by Walter Ariel Risi, 2006Software Architecture Office Presentation by Walter Ariel Risi, 2006
Software Architecture Office Presentation by Walter Ariel Risi, 2006Walter Ariel Risi
 
Ch1 it1 - v4.0 - 87.8%
Ch1 it1 - v4.0 - 87.8%Ch1 it1 - v4.0 - 87.8%
Ch1 it1 - v4.0 - 87.8%chikoecko
 
1/3 SEO: Keyword Research - Inede (Máster en Marketing Digital)
1/3 SEO: Keyword Research - Inede (Máster en Marketing Digital)1/3 SEO: Keyword Research - Inede (Máster en Marketing Digital)
1/3 SEO: Keyword Research - Inede (Máster en Marketing Digital)rodcul
 
Tutorial e bibliounad
Tutorial e bibliounadTutorial e bibliounad
Tutorial e bibliounadMimelucho
 
Actiw Intralogistics White Paper - Procter & Gamble
Actiw Intralogistics White Paper - Procter & GambleActiw Intralogistics White Paper - Procter & Gamble
Actiw Intralogistics White Paper - Procter & GambleActiw Intralogistics
 
MongoDB at Mailbox
MongoDB at MailboxMongoDB at Mailbox
MongoDB at MailboxMongoDB
 
Presentación de Oxatis y del mercado del e-commerce
Presentación de Oxatis y del mercado del e-commercePresentación de Oxatis y del mercado del e-commerce
Presentación de Oxatis y del mercado del e-commerceMarketing-Oxatis-ES
 
Presentazione Cfrm Ingegna Finanza 2009
Presentazione Cfrm Ingegna Finanza 2009Presentazione Cfrm Ingegna Finanza 2009
Presentazione Cfrm Ingegna Finanza 2009Daniele Cescutti
 
Hands on usuarios moviles 3g wifi seguros
Hands on usuarios moviles 3g wifi segurosHands on usuarios moviles 3g wifi seguros
Hands on usuarios moviles 3g wifi segurosPaloSanto Solutions
 
Microsoft Azure solutions - Whitepaper
Microsoft Azure solutions - WhitepaperMicrosoft Azure solutions - Whitepaper
Microsoft Azure solutions - WhitepaperBinu Bhasuran
 
Visible banking workshop program social media and finance-madrid- reyes bolumar
Visible banking workshop program social media and finance-madrid- reyes bolumarVisible banking workshop program social media and finance-madrid- reyes bolumar
Visible banking workshop program social media and finance-madrid- reyes bolumarreyesbolumar
 
Guía de Emprendimiento y Tecnologías
Guía de Emprendimiento y Tecnologías Guía de Emprendimiento y Tecnologías
Guía de Emprendimiento y Tecnologías Marco Peres
 

Destaque (20)

Software Architecture Office Presentation by Walter Ariel Risi, 2006
Software Architecture Office Presentation by Walter Ariel Risi, 2006Software Architecture Office Presentation by Walter Ariel Risi, 2006
Software Architecture Office Presentation by Walter Ariel Risi, 2006
 
Ch1 it1 - v4.0 - 87.8%
Ch1 it1 - v4.0 - 87.8%Ch1 it1 - v4.0 - 87.8%
Ch1 it1 - v4.0 - 87.8%
 
1/3 SEO: Keyword Research - Inede (Máster en Marketing Digital)
1/3 SEO: Keyword Research - Inede (Máster en Marketing Digital)1/3 SEO: Keyword Research - Inede (Máster en Marketing Digital)
1/3 SEO: Keyword Research - Inede (Máster en Marketing Digital)
 
Listofcountries
ListofcountriesListofcountries
Listofcountries
 
Tutorial e bibliounad
Tutorial e bibliounadTutorial e bibliounad
Tutorial e bibliounad
 
CV Sabrina S
CV Sabrina SCV Sabrina S
CV Sabrina S
 
Trabajo ade valeo final
Trabajo ade valeo finalTrabajo ade valeo final
Trabajo ade valeo final
 
ACO COURSE 6
ACO COURSE 6ACO COURSE 6
ACO COURSE 6
 
Actiw Intralogistics White Paper - Procter & Gamble
Actiw Intralogistics White Paper - Procter & GambleActiw Intralogistics White Paper - Procter & Gamble
Actiw Intralogistics White Paper - Procter & Gamble
 
MongoDB at Mailbox
MongoDB at MailboxMongoDB at Mailbox
MongoDB at Mailbox
 
Plan de capacitaciòn pnl
Plan de capacitaciòn pnlPlan de capacitaciòn pnl
Plan de capacitaciòn pnl
 
Taxones
TaxonesTaxones
Taxones
 
Online Tourismus –
Online Tourismus – Online Tourismus –
Online Tourismus –
 
Presentación de Oxatis y del mercado del e-commerce
Presentación de Oxatis y del mercado del e-commercePresentación de Oxatis y del mercado del e-commerce
Presentación de Oxatis y del mercado del e-commerce
 
Presentazione Cfrm Ingegna Finanza 2009
Presentazione Cfrm Ingegna Finanza 2009Presentazione Cfrm Ingegna Finanza 2009
Presentazione Cfrm Ingegna Finanza 2009
 
Hands on usuarios moviles 3g wifi seguros
Hands on usuarios moviles 3g wifi segurosHands on usuarios moviles 3g wifi seguros
Hands on usuarios moviles 3g wifi seguros
 
Microsoft Azure solutions - Whitepaper
Microsoft Azure solutions - WhitepaperMicrosoft Azure solutions - Whitepaper
Microsoft Azure solutions - Whitepaper
 
Visible banking workshop program social media and finance-madrid- reyes bolumar
Visible banking workshop program social media and finance-madrid- reyes bolumarVisible banking workshop program social media and finance-madrid- reyes bolumar
Visible banking workshop program social media and finance-madrid- reyes bolumar
 
Tp computacion
Tp computacionTp computacion
Tp computacion
 
Guía de Emprendimiento y Tecnologías
Guía de Emprendimiento y Tecnologías Guía de Emprendimiento y Tecnologías
Guía de Emprendimiento y Tecnologías
 

Semelhante a Cnpm bkdn

Software Development Methodologies.pptx
Software Development Methodologies.pptxSoftware Development Methodologies.pptx
Software Development Methodologies.pptxMohamedElshaikh10
 
unit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDppt
unit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDpptunit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDppt
unit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDpptWrushabhShirsat3
 
Elementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptxElementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptxethiouniverse
 
Software Development Life Cycle (SDLC )
Software Development Life Cycle (SDLC )Software Development Life Cycle (SDLC )
Software Development Life Cycle (SDLC )eshtiyak
 
Software development PROCESS
Software development PROCESSSoftware development PROCESS
Software development PROCESSIvano Malavolta
 
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdfMODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdfJayanthi Kannan MK
 
Software Engineering Lec 1-introduction
Software Engineering Lec 1-introductionSoftware Engineering Lec 1-introduction
Software Engineering Lec 1-introductionTaymoor Nazmy
 

Semelhante a Cnpm bkdn (20)

Week1.pptx
Week1.pptxWeek1.pptx
Week1.pptx
 
Requirements engineering
Requirements engineeringRequirements engineering
Requirements engineering
 
Software Development Methodologies.pptx
Software Development Methodologies.pptxSoftware Development Methodologies.pptx
Software Development Methodologies.pptx
 
unit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDppt
unit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDpptunit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDppt
unit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDppt
 
Elementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptxElementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptx
 
Software Development Life Cycle (SDLC )
Software Development Life Cycle (SDLC )Software Development Life Cycle (SDLC )
Software Development Life Cycle (SDLC )
 
Unit 1 OOSE
Unit 1 OOSEUnit 1 OOSE
Unit 1 OOSE
 
Software Engineering and Introduction, Activities and ProcessModels
Software Engineering and Introduction, Activities and ProcessModels Software Engineering and Introduction, Activities and ProcessModels
Software Engineering and Introduction, Activities and ProcessModels
 
Waterfall model
Waterfall modelWaterfall model
Waterfall model
 
Incremental model
Incremental modelIncremental model
Incremental model
 
software engineering
software engineering software engineering
software engineering
 
Software development PROCESS
Software development PROCESSSoftware development PROCESS
Software development PROCESS
 
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdfMODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf
 
Soft lifecycle
Soft lifecycleSoft lifecycle
Soft lifecycle
 
ppt chapter 1.ppt
ppt chapter 1.pptppt chapter 1.ppt
ppt chapter 1.ppt
 
Software Engineering Lec 1-introduction
Software Engineering Lec 1-introductionSoftware Engineering Lec 1-introduction
Software Engineering Lec 1-introduction
 
SE UNIT-1 Revised.pdf
SE UNIT-1 Revised.pdfSE UNIT-1 Revised.pdf
SE UNIT-1 Revised.pdf
 
Week_02.pptx
Week_02.pptxWeek_02.pptx
Week_02.pptx
 
01lifecycles
01lifecycles01lifecycles
01lifecycles
 
SE-Lecture1.ppt
SE-Lecture1.pptSE-Lecture1.ppt
SE-Lecture1.ppt
 

Último

Introduction to Nonprofit Accounting: The Basics
Introduction to Nonprofit Accounting: The BasicsIntroduction to Nonprofit Accounting: The Basics
Introduction to Nonprofit Accounting: The BasicsTechSoup
 
UGC NET Paper 1 Mathematical Reasoning & Aptitude.pdf
UGC NET Paper 1 Mathematical Reasoning & Aptitude.pdfUGC NET Paper 1 Mathematical Reasoning & Aptitude.pdf
UGC NET Paper 1 Mathematical Reasoning & Aptitude.pdfNirmal Dwivedi
 
Making communications land - Are they received and understood as intended? we...
Making communications land - Are they received and understood as intended? we...Making communications land - Are they received and understood as intended? we...
Making communications land - Are they received and understood as intended? we...Association for Project Management
 
Spellings Wk 3 English CAPS CARES Please Practise
Spellings Wk 3 English CAPS CARES Please PractiseSpellings Wk 3 English CAPS CARES Please Practise
Spellings Wk 3 English CAPS CARES Please PractiseAnaAcapella
 
How to Give a Domain for a Field in Odoo 17
How to Give a Domain for a Field in Odoo 17How to Give a Domain for a Field in Odoo 17
How to Give a Domain for a Field in Odoo 17Celine George
 
Application orientated numerical on hev.ppt
Application orientated numerical on hev.pptApplication orientated numerical on hev.ppt
Application orientated numerical on hev.pptRamjanShidvankar
 
Sensory_Experience_and_Emotional_Resonance_in_Gabriel_Okaras_The_Piano_and_Th...
Sensory_Experience_and_Emotional_Resonance_in_Gabriel_Okaras_The_Piano_and_Th...Sensory_Experience_and_Emotional_Resonance_in_Gabriel_Okaras_The_Piano_and_Th...
Sensory_Experience_and_Emotional_Resonance_in_Gabriel_Okaras_The_Piano_and_Th...Pooja Bhuva
 
The basics of sentences session 3pptx.pptx
The basics of sentences session 3pptx.pptxThe basics of sentences session 3pptx.pptx
The basics of sentences session 3pptx.pptxheathfieldcps1
 
Key note speaker Neum_Admir Softic_ENG.pdf
Key note speaker Neum_Admir Softic_ENG.pdfKey note speaker Neum_Admir Softic_ENG.pdf
Key note speaker Neum_Admir Softic_ENG.pdfAdmir Softic
 
Accessible Digital Futures project (20/03/2024)
Accessible Digital Futures project (20/03/2024)Accessible Digital Futures project (20/03/2024)
Accessible Digital Futures project (20/03/2024)Jisc
 
Understanding Accommodations and Modifications
Understanding Accommodations and ModificationsUnderstanding Accommodations and Modifications
Understanding Accommodations and ModificationsMJDuyan
 
How to setup Pycharm environment for Odoo 17.pptx
How to setup Pycharm environment for Odoo 17.pptxHow to setup Pycharm environment for Odoo 17.pptx
How to setup Pycharm environment for Odoo 17.pptxCeline George
 
Holdier Curriculum Vitae (April 2024).pdf
Holdier Curriculum Vitae (April 2024).pdfHoldier Curriculum Vitae (April 2024).pdf
Holdier Curriculum Vitae (April 2024).pdfagholdier
 
Basic Civil Engineering first year Notes- Chapter 4 Building.pptx
Basic Civil Engineering first year Notes- Chapter 4 Building.pptxBasic Civil Engineering first year Notes- Chapter 4 Building.pptx
Basic Civil Engineering first year Notes- Chapter 4 Building.pptxDenish Jangid
 
Micro-Scholarship, What it is, How can it help me.pdf
Micro-Scholarship, What it is, How can it help me.pdfMicro-Scholarship, What it is, How can it help me.pdf
Micro-Scholarship, What it is, How can it help me.pdfPoh-Sun Goh
 
Fostering Friendships - Enhancing Social Bonds in the Classroom
Fostering Friendships - Enhancing Social Bonds in the ClassroomFostering Friendships - Enhancing Social Bonds in the Classroom
Fostering Friendships - Enhancing Social Bonds in the ClassroomPooky Knightsmith
 
ICT role in 21st century education and it's challenges.
ICT role in 21st century education and it's challenges.ICT role in 21st century education and it's challenges.
ICT role in 21st century education and it's challenges.MaryamAhmad92
 
REMIFENTANIL: An Ultra short acting opioid.pptx
REMIFENTANIL: An Ultra short acting opioid.pptxREMIFENTANIL: An Ultra short acting opioid.pptx
REMIFENTANIL: An Ultra short acting opioid.pptxDr. Ravikiran H M Gowda
 
Wellbeing inclusion and digital dystopias.pptx
Wellbeing inclusion and digital dystopias.pptxWellbeing inclusion and digital dystopias.pptx
Wellbeing inclusion and digital dystopias.pptxJisc
 

Último (20)

Introduction to Nonprofit Accounting: The Basics
Introduction to Nonprofit Accounting: The BasicsIntroduction to Nonprofit Accounting: The Basics
Introduction to Nonprofit Accounting: The Basics
 
UGC NET Paper 1 Mathematical Reasoning & Aptitude.pdf
UGC NET Paper 1 Mathematical Reasoning & Aptitude.pdfUGC NET Paper 1 Mathematical Reasoning & Aptitude.pdf
UGC NET Paper 1 Mathematical Reasoning & Aptitude.pdf
 
Making communications land - Are they received and understood as intended? we...
Making communications land - Are they received and understood as intended? we...Making communications land - Are they received and understood as intended? we...
Making communications land - Are they received and understood as intended? we...
 
Spellings Wk 3 English CAPS CARES Please Practise
Spellings Wk 3 English CAPS CARES Please PractiseSpellings Wk 3 English CAPS CARES Please Practise
Spellings Wk 3 English CAPS CARES Please Practise
 
How to Give a Domain for a Field in Odoo 17
How to Give a Domain for a Field in Odoo 17How to Give a Domain for a Field in Odoo 17
How to Give a Domain for a Field in Odoo 17
 
Application orientated numerical on hev.ppt
Application orientated numerical on hev.pptApplication orientated numerical on hev.ppt
Application orientated numerical on hev.ppt
 
Sensory_Experience_and_Emotional_Resonance_in_Gabriel_Okaras_The_Piano_and_Th...
Sensory_Experience_and_Emotional_Resonance_in_Gabriel_Okaras_The_Piano_and_Th...Sensory_Experience_and_Emotional_Resonance_in_Gabriel_Okaras_The_Piano_and_Th...
Sensory_Experience_and_Emotional_Resonance_in_Gabriel_Okaras_The_Piano_and_Th...
 
The basics of sentences session 3pptx.pptx
The basics of sentences session 3pptx.pptxThe basics of sentences session 3pptx.pptx
The basics of sentences session 3pptx.pptx
 
Key note speaker Neum_Admir Softic_ENG.pdf
Key note speaker Neum_Admir Softic_ENG.pdfKey note speaker Neum_Admir Softic_ENG.pdf
Key note speaker Neum_Admir Softic_ENG.pdf
 
Accessible Digital Futures project (20/03/2024)
Accessible Digital Futures project (20/03/2024)Accessible Digital Futures project (20/03/2024)
Accessible Digital Futures project (20/03/2024)
 
Understanding Accommodations and Modifications
Understanding Accommodations and ModificationsUnderstanding Accommodations and Modifications
Understanding Accommodations and Modifications
 
How to setup Pycharm environment for Odoo 17.pptx
How to setup Pycharm environment for Odoo 17.pptxHow to setup Pycharm environment for Odoo 17.pptx
How to setup Pycharm environment for Odoo 17.pptx
 
Holdier Curriculum Vitae (April 2024).pdf
Holdier Curriculum Vitae (April 2024).pdfHoldier Curriculum Vitae (April 2024).pdf
Holdier Curriculum Vitae (April 2024).pdf
 
Basic Civil Engineering first year Notes- Chapter 4 Building.pptx
Basic Civil Engineering first year Notes- Chapter 4 Building.pptxBasic Civil Engineering first year Notes- Chapter 4 Building.pptx
Basic Civil Engineering first year Notes- Chapter 4 Building.pptx
 
Micro-Scholarship, What it is, How can it help me.pdf
Micro-Scholarship, What it is, How can it help me.pdfMicro-Scholarship, What it is, How can it help me.pdf
Micro-Scholarship, What it is, How can it help me.pdf
 
Fostering Friendships - Enhancing Social Bonds in the Classroom
Fostering Friendships - Enhancing Social Bonds in the ClassroomFostering Friendships - Enhancing Social Bonds in the Classroom
Fostering Friendships - Enhancing Social Bonds in the Classroom
 
ICT role in 21st century education and it's challenges.
ICT role in 21st century education and it's challenges.ICT role in 21st century education and it's challenges.
ICT role in 21st century education and it's challenges.
 
REMIFENTANIL: An Ultra short acting opioid.pptx
REMIFENTANIL: An Ultra short acting opioid.pptxREMIFENTANIL: An Ultra short acting opioid.pptx
REMIFENTANIL: An Ultra short acting opioid.pptx
 
Mehran University Newsletter Vol-X, Issue-I, 2024
Mehran University Newsletter Vol-X, Issue-I, 2024Mehran University Newsletter Vol-X, Issue-I, 2024
Mehran University Newsletter Vol-X, Issue-I, 2024
 
Wellbeing inclusion and digital dystopias.pptx
Wellbeing inclusion and digital dystopias.pptxWellbeing inclusion and digital dystopias.pptx
Wellbeing inclusion and digital dystopias.pptx
 

Cnpm bkdn

  • 2. Code of Conduct  Software Engineering is a collaborative activity. You are encouraged to work together, but ...  Some tasks may require individual work.  Always give credit to your sources and collaborators. Good professional practice: To make use of the expertise of others and to build on previous work, with proper attribution. Unethical and academic plagiarism: To use the efforts of others without attribution.
  • 3. Projects  Project teams, about 3 to 5 peoples.  Select your own project, any branch of software engineering  Real project for real client who intends to use the software in production.  Feasibility study and plan: during semester  Presentations: • requirements • design • final
  • 4. Project Selection  Some suggested projects  Recitation section to suggest projects Contact potential clients:  Gain idea of their expectations  Estimate scope and complexity of the project  Discuss business decisions Assemble project team  Advertise on the web site
  • 5. Previous Experience Your background       Biggest program that you have written? Biggest program that you have worked on? Biggest project team that you have been part of? Longest project that you have worked on? Most people who have used your work? Longest that your project has been in production? My background
  • 6. Course Themes 1. Leadership of large software projects  Software as a product Clients and their needs Quality  Requirements and specification Usability Evolution  Project management Personnel management Economic, legal, and social factors
  • 7. Course Themes 2. Large and very large systems  Software design Software architecture Object-oriented design  Dependable systems Reliability Verification  Legacy systems
  • 8. Characteristics of Software Products General characteristics Usability Maintainability Dependability Efficiency Good software products require good programming, but ... Programming quality is the means to the end, not the end itself.
  • 9. Software as a Product Software is expensive!! Every software project has a trade-off between: Functionality Resources (cost) Timeliness Example: Accounting Management System
  • 10. Client (a.k.a Customer)  The client provides resources and expects some product in return.  Client satisfaction is the primary measurement of success. Question: Who is the client for Microsoft Excel?
  • 11. Variety of Software Products Examples? -Operation System -Database Management System -Embedded System -Games -Application Software -…
  • 12. Categories of Product Categories of client and software product:  Generic (e.g., Microsoft Excel)  Bespoke (customized) (e.g., IRS internal system) Many systems are customized versions of generic packages (e.g., Cornell's payroll system)
  • 13. Variety of Software Products Software products are very varied --> Client requirements are very different --> There is no standard process for software engineering --> There is no best language, operating system, platform, database system, development environment, etc. A skilled software developer knows about a wide variety of approaches, methods, tools. The craft of software engineering is to select appropriate methods for each project and apply them effectively.
  • 14. Professional Responsibility Organizations put trust in software developers:  Competence: Software that does not work effectively can destroy an organization.  Confidentiality: Software developers and systems administrators may have access to highly confidential information (e.g., trade secrets, personal data).  Legal environment: Software exists in a complex legal environment (e.g., intellectual property, obscenity).  Acceptable use and misuse: Computer abuse can paralyze an organization (e.g., the Internet worm).
  • 16. Books  Frederick P. Brooks, Jr. The Mythical Man Month. Addison-Wesley, 1972.  Ian Sommerville, Software Engineering, 6th edition. Addison-Wesley, 2000.  Grady Booch, James Rumbach, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999.
  • 17. Software Process Fundamental Assumption: Good processes lead to good software Good processes reduce risk
  • 18. Risk Management What can go wrong in a software project? How can the risk be reduced?
  • 19. The Software Process (Simplified) Feasibility and Planning Requirements Design Implementation Operation and Maintenance
  • 20. The Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
  • 21. Requirements Analysis and Definition The system's services, constraints and goals are established by consultation with system users. They are then defined in a manner that is understandable by both users and development staff. This phase can be divided into:     Feasibility study (often carried out separately) Requirements analysis Requirements definition Requirements specification
  • 22. System and Software Design System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture Software design: Represent the software system functions in a form that can be transformed into one or more executable programs  Unified Modeling Language (UML)
  • 23. Programming and Unit Testing The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified.) Individual components are tested against specifications.
  • 24. Integration and System Testing The individual program units are:  integrated and tested as a complete system  tested against the requirements as specified  delivered to the client
  • 25. Operation and Maintenance  Operation: The system is put into practical use.  Maintenance: Errors and problems are identified and fixed.  Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment.  Phase out: The system is withdrawn from service.
  • 26. Discussion of the Waterfall Model Advantages:     Process visibility Dependence on individuals Quality control Cost control Disadvantages: Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised.
  • 27. Feedback in the Waterfall Model Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
  • 28. Iterative Refinement (Evolutionary Development) Concept: Initial implementation for user comment, followed by refinement until system is complete.  Vaporware: user interface mock-up  Throw-away software components  Dummy modules  Rapid prototyping  Successive refinement
  • 31. Iterative Refinement & Software Process Concurrent Activities Outline Description Requirements Design Implementation Final Version
  • 32. Iterative Refinement When is iterative refinement appropriate?
  • 33. Iterative Refinement + Waterfall Model: Graphics for Basic Outline Description: Add vector graphics to Dartmouth Basic. Phase 1: Extend current language with a preprocessor and run-time support package. (1976/77) Phase 2: Write new compiler and run-time system incorporating graphics elements. (1978/80)
  • 34. Iterative Refinement + Waterfall Model: Graphics for Basic Design Issues:  Pictorial subprograms: coordinate systems, window/viewport  User specification of perspective Design Strategy: (Iterative Refinement)  Write a series of prototypes with various proposed semantics  Evaluate with a set of programming tasks
  • 35. Iterative Refinement + Waterfall Model: Graphics for Basic Phase 1: Implementation (Waterfall)  When the final specification was agreed, the entire preprocessor and run-time support were recoded.  The system was almost entirely bug-free. Phase 2: New compiler (Waterfall) Phase 1 was used as the requirements definition for the final version.
  • 36. Observations about Software Processes Completed projects should look like the Waterfall Model but ... the development process is always partly evolutionary. Risk is lowered by:  Prototyping key components  Dividing into phases  Following a visible software process  Making use of reusable components
  • 37. Software Engineering Lecture 3 (a) Feasibility Study (b) Requirements Definition
  • 38. Feasibility Study Before beginning a project, a short, low-cost study to identify • Client • Scope • Potential benefits • Resources needed: staff, time, equipment, etc. • Potential obstacles Where are the risks? How can they be minimized?
  • 39. Feasibility Study A feasibility study leads to a decision: go ahead do not go ahead think again In production projects, the feasibility study often leads to a budget request. In research, a feasibility study is often in the form of a proposal.
  • 40. CS 501: Client In CS 501, you have two clients: • The client for the project • The professor for the course Can you satisfy them both?
  • 41. Scope What are the boundaries of the project? CS 501 Examples: • Static web pages with open access on the Web [Web Profiler] • Used by the general public [Digital Collections] • Varying data formats [Legal Information] • Thousands of sensors [Data mining] • Support for Windows, Mac, Unix [SALSA]
  • 42. Potential Benefits Why are you doing this project? Examples • Create a marketable product • Improve the efficiency of an organization • Control a system that is too complex to control manually • New or improved service • Safety or security • Get a good grade on CS 501
  • 43. Resources Examples: CS 501 Staff: 5 to 7 students, with some help. How many hours per week? What skills do people have? Time: Must be completed by end of semester, including operational system, documentation, presentation Equipment and software: What special needs are there? Client: Will the client be sufficiently available and helpful?
  • 44. Obstacles CS 501 projects Start-up time. Creating a team, scheduling meetings, acquiring software, learning new systems, ... Business considerations. Licenses, trade-secrets, ... Too ambitious. Nothing to show at the end of the semester. Changing circumstances. Client leaves the university, ... What else?
  • 45. How to Minimize Risk? CS 501 Projects • Several target levels of functionality: required, desirable, optional • Visible software process: intermediate deliverables • Good communication within team and with Teaching Assistant Good processes lead to good software Good processes reduce risk
  • 46. Feasibility Report A written document • For a general audience: client, financial management, technical management, etc. • Short enough that everybody reads it • Long enough that no important topics are skipped In CS 501, I am looking for a well written, well presented document.
  • 47. Requirements Definition and Analysis Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
  • 48. Example: Library of Congress (A Partial Failure) Outline Description The Library of Congress requires a repository system to store and make accessible very large amounts of highly varied material over long periods of time.
  • 49. Chronology 1993-94 CNRI carries out research on architectures for digital libraries 1995-97 CNRI implements prototype repository for Library of Congress 1998 CNRI and Library of Congress carry out requirements definition
  • 51. Storage and Representation of Complex Objects Data Several representations: thumbnail image reference image archival image Metadata Each representation may have its own metadata
  • 52. Repository: Research Achievements 1. CORBA implementation of repository access protocol. 2. Integration of persistent naming through handle system. 3. Use of structural metadata to describe complex objects, elementary typology. 4. Access management framework and implementation. 5. Applet-based middleware for user interfaces. 6. Information visualization program to view the structure of large collections.
  • 53. Good Discoveries During Prototype • Structuring complex information in digital libraries • Data driven digital library interfaces • Comparison of object-oriented, relational, and file based storage systems • Naming and identification of library objects • Boundaries of required repository system
  • 54. Bad Discoveries During Prototype • Resistance to change within Library of Congress • Technical weakness of Library of Congress • Gaps in CNRI architecture
  • 55. Mistakes • Confusion of objectives (research and implementation) • Failure to involve all stakeholders • Over-ambitious (no proper feasibility study)
  • 57. Requirements Definition High-level abstract description of requirements: • Specifies external system behavior • Comprehensible by customer, management and users Should reflect accurately what the customer wants: • Services that the system will provide • Constraints under which it will operate
  • 58. Library of Congress Requirements Study Team (all experienced): Librarian, Software Engineer (CNRI), Computing Project Leader (Library of Congress), + 2 others Advisors: Mailing list of about 20 knowledgeable stakeholders. Timetable: Preliminary report (2 months). Final report (1 month).
  • 59. Functional Requirements Example: Library of Congress repository • Support for complex digital objects • Access management • Identification • Information hiding • Open protocols and formats • Integration with other systems (scope)
  • 60. DRAFT OVERVIEW OF ITS SUPPORT FOR NDLP PRODUCTION AND DELIVERY OF AMERICAN MEMORY NDLP collections already released Coolidge collection (for repository test) NDLP collections in conversion Future NDLP collections Other applications and materials NDLP Workflow Tracking Support Current Storage Structure (in Unix files, by aggregate) Object Administration System ILS Repository Index Generation (including pre-processing) American Memory User Interface (retrieval, navigation, & display) AM user interface plus access management for objects/collections Other User Interfaces (e.g. RLG, OCLC, DLF partners) ILS OPAC Interface Supporting infrastructure Handle assignment & registration Handle-server NOW Handle resolution FUTURE
  • 61. Non-functional Requirements Environment: • Estimates of sizes, numbers of users, etc. • Reliability and performance measures and targets Preferred: Example: Library of Congress repository • Hardware and software systems (e.g., IBM/Unix) • Database systems (e.g., Oracle) • Programming languages (e.g., C and C++)
  • 62. Evolution of Requirements • If the requirements definition is wrong, the system will be a failure. • With complex systems, understanding of requirements always continues to improve. Therefore... • The requirements definition must evolve. • Its documentation must be kept current (but clearly identify versions).
  • 64. The Aim of Project Management To complete a project: • On time • On budget • With required functionality • To the satisfaction of the client • Without exhausting the team
  • 65. The Project Manager • • • • Create and maintain the schedule Should track progress against schedule Keep some slack in the schedule Be continually making adjustments: Start activities before previous activity complete Sub-contract activities Renegotiate deliverables • Keep senior management informed
  • 66. Project Planning Methods The Critical Path Method, Gantt charts, Activity bar charts, etc. are roughly equivalent. These methods are best when: • Model is updated regularly (e.g., monthly) • The structure of the project is well understood • The time estimates are reliable • Activities do not share resources [Critical Path Method is excellent for large construction projects.]
  • 67. Example: An Open University Course Deliverables: 16 8 8 4 1 4 Written texts (bound in pairs) Television programs Radio programs Computer programs Home experimental kit (scientific calculator) Assignments and sample solutions
  • 68. Flexibility Schedule: Dates for broadcasting TV and radio programs are fixed. Printing and mailings can be accelerated if overtime is used. Functionality: The course team can decide what goes into the components of the course. Resources: The size of the course team can be increased slightly.
  • 69. Scheduling: Critical Path Method An activity A dummy activity An event A milestone
  • 70. Critical Path Method other activities START Revise Unit 3 Edit Unit 3 Print Unit 3 Mail Unit 3 END
  • 71. Critical Path Method other activities Revise Unit 3 Edit Unit 3 START other activities Revise Unit 4 Edit Unit 4 Typeset Unit 3 Print Units 3/4 Typeset Unit 4 Mail Units 3/4
  • 72. Critical Path Method Script TV 2 START Edit Unit 3 Make TV 2 Edit Unit 4 Prototype Computer 1 Document Computer 1 Mail Delivery Program Computer 1
  • 73. Time Estimates for Activities (Weeks) 4 1 6 3 2 3 1 12 12 1 3 2 4 4 1 3 2 8
  • 77. Slack 1/11 10 12/12 0 0/0 26/26 10 3 15/15 0 0 0 1 22/23 0 2 12/14 2 17/17 9 17/17 4/13 19/20 1 0 9 23/24 25/25 1 1 5 17/17 0
  • 78. Key Personnel In computing, not all people are equal: • The best are at least 5 times more productive • Some tasks are too difficult for everybody Adding more people adds communications complexity • Some activities need a single mind • Sometimes, the elapsed time for an activity can not be shortened. What happens to the project if a key person is sick or quits?
  • 79. Key Personnel: Schedule for Editor Earliest Start Date Activity Weeks 15-16 Weeks 17-18 Weeks 19-20 Weeks 21-22 Edit Unit 3 Edit Unit 4 Edit Unit 5 Edit Unit 6 Week 15 Week 17 Week 19 Week 21 Review draft of Unit 7 Review draft of Unit 8 Check proofs of Unit 3 Check proofs of Unit 4 Weeks 18-19 Week 22 Vacation Out sick
  • 80. Start-up Time On a big project, the start-up time is typically three to six months: • Personnel have to complete previous projects (fatigue) or recruited. • Hardware and software has to be acquired and installed. • Staff have to learn new domain areas and software (slow while learning) • Clients may not be ready.
  • 81. Experience with Critical Path Method Administrative computing department at Dartmouth used the Critical Path Method for implementation phase of major projects. Experience: Elapsed time to complete projects was consistently 25% to 40% longer than predicted by model. Analysis: • Some tasks not anticipated (incomplete understanding) • Some tasks had to be redone (change of requirements, technical changes) • Key personnel on many activities (schedule conflicts) • System ZZZ (non-billable hours)
  • 82. CS 501: Software Engineering Lecture 5 (a) Documentation (b) Requirements Analysis
  • 83. Assignments September 13 October 4 October 16 November 8 Nov 29 - Dec 1 Exam week Feasibility and plan Requirements Midterm exam Design Project presentations Final examination Details are subject to change. Group Group/individual Individual Group/individual Group Individual
  • 84. Assignment 1 Wednesday, September 13: Project plan due -- report. Title of project Client/customer Team members Outline description Current status (e.g., previous work) Plan (e.g., major stages, assignment to tasks, technical environment, schedule, etc.) Any other relevant information
  • 85. Documentation • Reasons for documentation: visibility (e.g., project plan, interim report) user support (e.g., user manual) team communication (e.g., interface specifications) maintenance and evolution (e.g., requirements) • Characteristics of documentation: accurate and kept current appropriate for audience maintained online (usually) simple but professional in style and appearance Documentation is expensive --> Quality not volume
  • 86. Form of Documentation External • Printed • Web site Internal • Program documentation • Program context (e.g., copyright notices)
  • 87. Requirements Definition and Analysis Requirements Definition System and Software design Programming and Unit Testing Integration and System Testing Operation and Maintenance
  • 89. Requirements Analysis 1. Understand the requirements in depth: • Domain understanding Examples: science research, application… • Stakeholders Example: companies, ministries, Danang City…
  • 90. Viewpoint Analysis Example: University Admissions System • Applicants • University administration Admissions office Financial aid office Special offices (e.g., athletics, development) • Computing staff Operations Software development and maintenance • Academic departments
  • 91. Interviews with Clients Clients may have only a vague concept of requirements. • Prepare before you meet with them • Keep full notes • If you don't understand, delve further • Small group meetings are often most effective Clients often confuse the current system with the underlying requirement.
  • 92. Requirements Analysis 2. Organize the requirements: • Classification into coherent clusters (e.g., legal requirements) • Recognize and resolve conflicts (e.g., functionality v. cost v. timeliness) Example: Dartmouth general ledger system
  • 93. Requirements Analysis 3. Model the requirements: • Informal Prose • Systematic Procedural models Data-centric models Object models • Formal models
  • 96. Procedural Models: Pseudo-code Example: Check project project plan check_plan (report) if report (date_time) > due_date_time then error (too_late) if report (client) = none then error (no_client) if report (team) < min_team or > max_team then error (bad_team) if error() = none then comments = read_report (report) return (comments (text), comments (grade)) else return error()
  • 97. Data-Flow Models External entities Processing steps Data stores or sources Data flows
  • 98. Example: University Admissions Rejection Application Completed form Receive application Evaluate application Applicant Offer
  • 99. Example: University Admissions Assemble Application Stage Acknowledgment Application form Receive Applicant Completed application Acknowledgment AND Initiate evaluation Evaluation request AND Supporting information Pending database Applicant database
  • 100. Example: University Admissions Process Completed Application Stage Rejection Evaluation request Evaluation Acceptance Special request Applicant database Financial aid Offer
  • 101. Requirements Analysis v. System Design Dilemma. • Requirements analysis should make minimal assumptions about the system design. • But the requirements definition must be consistent with computing technology and the resources available. In practice, analysis and design are interwoven. However, do not to allow the analysis tools to prejudge the system design.
  • 102. CS 501: Software Engineering Lecture 6 (a) Requirements Analysis (continued) (b) Requirements Specification
  • 104. Requirements Analysis Methods for data modeling and design • Data flow diagrams • Entity-relation diagrams • Data dictionaries • Object models Many of these methods blur the distinction between analysis and design.
  • 105. Entity-Relation Model A Design Methodology for Relational Databases • A database of entities and relations • Tools for displaying and manipulating entityrelation diagrams • Tools for manipulating the database (e.g., as input to database design) Warning: There is much confusion about definitions and notation
  • 106. Entity-Relation Diagram An entity A relation between entities An entity or relation attribute An inheritance relation
  • 107. Example: CS 501 Project Major Client 1 Student Project 1 CS501 Student 5 to 7 Member of 0:n Person 0:n 0:n Tech contact
  • 108. MARC Format for Monographs (Books) 001 245 260 650 650 700 89-16879 r93 Campus strategies for libraries and electronic information {Bedford, Mass.} : Digital Press, c1990. Academic libraries--United States--Automation. Libraries and electronic publishing--United States. Arms, Caroline R. (Caroline Ruth)
  • 109. Entity-Relation Diagram for MARC Book 0:n 1 0:n Describes 0:n Catalog record Short title 1:n Author of Editor of Is about Control numb 0:n Creator 0:n 0:n Subject heading
  • 110. Data Dictionaries A data dictionary is a list of names used by the system • Brief definition (e.g., what is "date") • What is it (e.g., number, relation) • Where is it used (e.g., source, used by, etc.) • May be combined with a glossary As the system is implemented, the data dictionary in the requirements is input to the system data dictionary, which is a formal part of the system specification.
  • 111. A Note on Object Models This course teaches object models as a tool for design. Some people recommend object models for requirements analysis, but it is difficult to use them without constraining the system design.
  • 112. Non-Functional Requirements Product requirements performance, reliability, portability, etc... Organizational requirements delivery, training, standards, etc... External requirements legal, interoperability, etc...
  • 113. Examples of Non-Functional Requirements Privacy (Mercury digital library) Functional requirement: Usage data for management of system Non-functional requirement: Usage data must not identify individuals Minimizing records (NeXT) Functional requirement: Retain all required records Non-functional requirement: Discard all other records
  • 115. Requirements Specification What is the purpose of the Requirements Specification?
  • 116. Requirements Specification: Purpose 1. It describes the requirements to the stakeholders • Expressed in the terms that the stakeholders understand • Comprehensible from many viewpoints • Reviewed by stakeholders so that they understand implications • Must be clear about assumptions (things left out)
  • 117. Requirements Specification: Purpose 2. It describes the requirements to the implementers • As precise and specific as possible • Expressed in terms that they understand • Comprehensible to new team members
  • 118. Requirements Specification: Purpose 3. It records the requirements for the future • An essential part of system evolution 4. If may be a contractual document • See you in court!
  • 119. Requirements Specification: Approaches • Natural language • Structured natural language • Design description language • Requirements specification language • Graphical notation • Formal specification See Sommerville, Chapter 7.
  • 120. CS 501: Software Engineering Lecture 7 Management II Business and Legal Aspects of Software Engineering
  • 121. Legal Environment Software is developed in a complex legal and economic framework. Changes in laws follow changes in technical world. Jurisdictions: • • • • • • Vietnamese laws International treaties Federal and state statues Precedents Supreme Court Cost of establishing precedent
  • 122. Legal Topics • International • Intellectual property (copyright, patent, contract) • Tort (e.g., liability of Internet service provider) • Privacy • Free speech and its limitations (government secrets, obscenity, blasphemy, hate) Legal Information Institute: http://www.law.cornell.edu/
  • 123. Copyright A copyright gives the owner the exclusive right to: • reproduce • distribute • perform • display • license Gradually extended to cover text, music, photographs, designs, software, ...
  • 124. Copyright Copyright at creation • • • • • Works for hire Contracts and licenses First sale Fair use Infringement (contamination) International differences • Moral rights • Copyright registration
  • 125. Software Patents • Should be: non-obvious, novel, useful • 17 years from award (20 years from application) • Poor quality of examining can lead to broad patents for routine computing concepts • International differences Copyright applies to the expression of ideas, patents to the ideas themselves.
  • 126. Contracts and Licences Contracts allow intellectual property to be sold or licensed • • • • • • • Promise in exchange for adequate consideration Written document with signature Permanent or temporary, whole or part Exclusive or non-exclusive Termination, problems and difficulties Terms and conditions as agreed Enforceable by courts
  • 127. Derivative Works When software is derived from other software: • New code is owned by new developer • Conditions that apply to old code apply to derived work If you write S, which is derived from A, B, C and D, you can not distribute or licenses S unless you have right to distribute each of A, B, C and D. To create a software product, you must have documented rights to use every component.
  • 128. Privacy Invasions of privacy: • • • • intrusion appropriation of name or likeness unreasonable publicity false light Be very careful about collecting personal data without the knowledge of the individual
  • 129. Software Business Questions • You are employed for company X writing software. When you leave, who owns your work? What use can you make of the work? • You work free-lance for company X. When you finish, who owns your work? What use can you make of the work? • Read the contract!
  • 130. Your Next Job ... • Employment contract may restrict your next job (not working for competitors, etc.) • Trade-secret information (non-disclosure agreement) Ask when you are interviewed!
  • 131. Trade Secrets and Non-Disclosure Agreements Trade Secret "... information, including a formula, pattern, compilation, program, device, method, technique, or process that derives independent economic value from not being generally known and not being readily ascertainable and is subject to reasonable efforts to maintain secrecy." Uniform Trade Secrets Act Non-Disclosure Agreement Legal agreement not to disclose trade secrets.
  • 132. Some Business Models • Software developed in-house • Package licensed to customer, binary only (Microsoft model) • Package licensed to customer, source code for customer's modifications • Bespoke software for customer (may be owned by supplier or customer) • Software bundled with hardware product (PalmPilot)
  • 133. Free-Lance Software Development You and a few friends create a company to develop software. How much should you charge per hour? You plan to work 40 hours a week for 50 weeks of the year and want to earn $50,000. Hourly rate = $50,000 / (40 x 50) = $25 But ...
  • 134. Free-Lance Software Development Salary Taxes and benefits Rent, equipment, etc. Fees, services, etc. Travel and misc. TOTAL EXPENSE Hours worked less administration less marketing BILLABLE HOURS $50,000 $15,000 $10,000 $15,000 $10,000 $100,000 2,000 400 350 1,250 Hourly rate = $100,000 /1,250 = $80
  • 135. Fixed and Variable Cost: Packaged Software Example: • The initial development cost of a software product is $10 million. • The cost of packaging and distribution of each copy is $5. • Technical support costs average $15 per copy. • The package sells for $200 per copy. Fixed cost = $10 million Variable cost = $20
  • 136. Fixed and Variable Costs: Profit or Loss $15M $10M $5M 2,500 5,000 7,500 Unit sales
  • 137. Community Development • Shareware • Open source (e.g., Linux, Apache, Perl, etc.) -> Shared development -> Market penetration Example: TCP/IP for Vax/VMS Software may be open source, but packaging and services can be profitable businesses
  • 138. Open Source • Free redistribution • Source code • Derived works • Integrity of the author's source code • No discrimination against persons or groups
  • 139. Open Source • No discrimination against fields of endeavor • Distribution of license • License must not be specific to a product • License must not contaminate other software http://www.opensource.org/osd.html
  • 140. Practical Advice Be aware of the law, but do not pretend to be a lawyer. Use a professional for: • Contracts and licenses • Troubles (complaints, injunctions, subpoenas, etc.) • Personnel issues • When in doubt, ask help!
  • 141. Source Code Management Or Configuration Management: How I learned to Stop Worrying and Hate My Co-workers Less
  • 142. Source Code Management  Also known as Configuration Management  Source Code Managers are tools that: – Archive your development files – Serve as a single point of entry/exit when adding or updating development files
  • 143. Why You Want A Source Control System  Supports concurrent development  Manage diverging source code bases  Records file/release versions  Easy access to all previous revisions  Can record why a revision was made  Optimal disk space usage  You’ll end up doing something equivalent anyway so it may as well be automated
  • 144. Source Code Management Tools Are Not  A substitute for project management  A replacement for developer communication
  • 145. How They Work  Central database of source code, documentation, build tools  Each file stored only once - all other versions are diffs of that one copy  To Make a Change – Check out the latest version of a file – Make the changes – Update the database
  • 146. What should be in the database  Source Code  Documentation  Build Tools – Often need old versions of the tools to build old versions of the software – Ensures software is rebuilt exactly as the customer received it  Test Suites  Anything else you might want later
  • 147. Version Control  Companies ship several products from the same source base (i.e. Win NT and Windows 2000 versions of MS Office)  When tracking down bugs you want to examine the code as it was when the product shipped
  • 148. Code Sharing  Multiple people can work on the same source base without colliding – (1) Locks individual files so only one person at a time can modify it *OR* – (2) Allows multiple people to modify a source file and the system will automatically merge the changes (usually)
  • 149. Locking  Only one person can work on a file at once  Works fairly well if developers work on different areas of the project and don’t conflict often  Problem 1: People forget to unlock files when they are done  Problem 2: People work around locking by editing a private copy and checking in when the file is finally unlocked - easy to goof and lose changes
  • 150. Merging  Several people can work on a file at once  Before committing changes, each user merges their copy with the latest copy in the database – This is normally done automatically by the system and usually works, but you should not blindly accept the result of the merge
  • 151. Labeling  Label all the files in the source base that make up a product at each milestone  Just before and just after a major change (e.g.. changing several interfaces)  When a new version ships
  • 152. Version Trees  Each file in the database has a version tree  Can branch off the version tree to allow separate development paths  Typically a main path (trunk) for the next major version and branches off of shipped versions for maintenance
  • 153. Branching  When a new version ships, typically create a branch in the version tree for maintenance  Double update: fix a defect in the latest version and then merge the changes (often by hand) into the maintenance version  Also create personal versions so you can make a change against a stable source base and then merge in the latest version later
  • 154. Examples  RCS – Solaris: man rcsintro  CVS – Solaris: man cvs – www.cyclic.com/cvs/info.html  Visual SourceSafe – msdn.microsoft.com/SSAFE  ClearCase – www.rational.com
  • 155. RCS  File management only  Transaction model – check out and lock – edit – check in and unlock  Little support for binaries
  • 156. CVS  Built on top of RCS – Therefore little support for binaries  Database can be remote  No locking: merge before commit  Fast  Integrates with emacs
  • 157. SourceSafe  Microsoft’s entry into the field  Project-based  Checkout-edit-checkin model  Built-in web site creation tools  Integrates with MSDEV
  • 158. Clearcase  Clearcase is configuration management on steroids  You create a view of the database with a config spec, which describes how to select files from the database.  When you set a view, Clearcase creates a virtual filesystem containing only those versions of the files selected by the config spec
  • 159. Clearcase Features  Distributed System – Several groups at different locations can work on the same database  Can install triggers – Example: e-mail the author of a file when some one makes a change to it  Uses merging model like CVS, but can also lock files
  • 160. More Clearcase Features  Integrates with MSDEV  Build Management – Knows to rebuild out-of-date files even if your makefile doesn’t  Slow and a bit buggy
  • 161. Helpful Rules for Version Control Bliss  Archived Files Should Always Compile  Code Review Files Before Check-in  Compile and run latest archived files *as a set* before Check-in  No Cheating (even “simple bug fixes” need to undergo this process)
  • 163. Formal Specification Why? • Precise standard to define and validate software Why not? • May be time consuming • Methods not suitable for all applications
  • 164. Formal Specification Ben Potter, Jane Sinclair, David Till, An Introduction to Formal Specification and Z (Prentice Hall) 1991 Jonathan Jacky The Way of Z (Cambridge University Press) 1997
  • 165. Mathematical Specification Example of specification B1, B2, ... Bk is a sequence of m x m matrices η1, η2, ... ηk is a sequence of m x m elementary matrices B1-1 = η1 B2-1 = η2η1 Bk-1 = ηk ... η2η1 The numerical accuracy must be such that, for all k, BkBk-1 - I < ∆
  • 166. Specification of Programming Languages <unsigned number> ::= <unsigned integer> | <unsigned real> <unsigned integer> ::= <digit> {<digit>} <unsigned real> ::= <unsigned integer> . <digit> {<digit>} | <unsigned integer> . <digit> {<digit>} E <scale factor> | <unsigned integer> E <scale factor> <scale factor> ::= <unsigned integer> | <sign> <unsigned integer> <sign> ::= + | Pascal number syntax
  • 167. Formal Specification Using Diagrams unsigned integer digit unsigned number unsigned integer + . digit unsigned integer E -
  • 168. Two Rules • Formal specification does not guarantee correctness • Formal specification does not prescribe the implementation
  • 169. Example: Z Specification Language Informal: The function intrt(a) returns the largest integer whose square is less than or equal to a. Formal (Z): intrt: N N a : N• intrt(a) * intrt(a) < a < (intrt(a) + 1) * (intrt(a) + 1)
  • 170. Example: Algorithm 1 + 3 + 5 + ... (2n - 1) = n2
  • 171. Example: Program int intrt (int a) /* Calculate integer square root */ { int i, term, sum; term = 1; sum = 1; for (i = 0; sum <= a; i++) { term = term + 2; sum = sum + term; } return i; }
  • 172. Finite State Machine A broadly used method of formal specification: • Event driven systems (e.g., games) • User interfaces • Protocol specification etc., etc., ...
  • 173. Finite State Machine Example: Therapy control console [informal description]
  • 174. State Transition Diagram Select field Enter Patients Enter Fields Start (ok) Setup Beam on Ready Stop (interlock) Select patient
  • 175. State Transition Table Select Select Enter Patient Field Patients Fields Patients Setup Patients Fields Ready Patients Fields Beam on ok Start Stop interlock Fields Setup Ready Beam on Setup Ready Setup
  • 176. Z Specification STATE ::= patients | fields | setup | ready | beam_on EVENT ::= select_patient | select_field | enter | start | stop | ok | interlock FSM == (STATE X EVENT) STATE no_change, transitions, control : FSM Continued on next slide
  • 177. Z Specification (continued) control = no_change transitions no_change = { s : STATE; e : EVENT • (s, e) transitions = { (patients, enter) (fields, select_patient) s} fields, patients, (fields, enter) setup, (setup, select_patient) patients, (setup, select_field) (setup, ok) ready, fields, (ready, select_patient) patients, (ready, select_field) fields, (ready, start) beam_on, (ready, interlock) setup, (beam_on, stop) ready, (beam_on, interlock) setup }
  • 178. Schemas Schema: • The basic unit of formal specification. • Describes admissible states and operations of a system.
  • 179. LibSys: An Example of Z Library system: • Stock of books • Registered users. • Each copy of a book has a unique identifier. • Some books on loan; other books on shelves available for loan. • Maximum number of books that any user may have on loan.
  • 180. LibSys: Operations • Issue a copy of a book to a reader. • Reader return a book. • Add a copy to the stock. • Remove a copy from the stock. • Inquire which books are on loan to a reader. • Inquire which readers has a particular copy of a book. • Register a new reader. • Cancel a reader's registration.
  • 181. LibSys Level of Detail: Assume given sets: Copy, Book, Reader Global constant: maxloans
  • 182. Schemas Describing Operations Naming conventions for objects: Before: plain variables, e.g., r After: with appended dash, e.g., r' Input: with appended ?, e.g., r? Output: with appended !, e.g., r!
  • 183. Operation: Issue a Book • Inputs: copy c?, reader r? • Copy must be shelved initially: c? ∈ shelved • Reader must be registered: r? ∈ readers • Reader must have less than maximum number of books on loan: #(issued  {r?}) < maxloans • Copy must be recorded as issued to the reader: issued' = issued ⊕ {c? r?} • The stock and the set of registered readers are unchanged: stock' = stock; readers' = readers
  • 184. Domain and Range X ran m y dom m x m:X Y Y dom m = { x ∈ X : ∃ y ∈ Y ∧ x y} ran m = { y ∈ Y : ∃ x ∈ X ∧ x y}
  • 185. Operation: Issue a Book Issue stock, stock' : Copy issued, issued' : Copy Book Reader shelved, shelved': F Copy readers, readers' : F Reader c?: Copy; r? :Reader [See next slide]
  • 186. Operation: Issue a Book (continued) Issue [See previous slide] shelved ∪ dom issued = dom stock shelved' ∪ dom issued' = dom stock' shelved ∩ dom issued = Ø; shelved' ∩ dom issued' = Ø ran issued ⊆ readers; ran issued' ⊆ readers' ∀r : readers • #(issued  {r}) < maxloans ∀r : readers' • #(issued'  {r}) < maxloans c? ∈ shelved; r? ∈ readers; #(issued  {r?}) < maxloans issued' = issued ⊕ {c? r?} stock' = stock; readers' = readers
  • 187. LibSys: Schema for Abstract States Library stock : Copy Book issued : Copy Reader shelved : F Copy readers: F Reader shelved ∪ dom issued = dom stock shelved ∩ dom issued = Ø ran issued ⊆ readers ∀r : readers • #(issued  {r}) < maxloans
  • 188. Schema Inclusion LibDB stock : Copy Book readers: F Reader LibLoans issued : Copy Reader shelved : F Copy ∀r : Reader • #(issued  {r}) < maxloans shelved ∩ dom issued = Ø
  • 189. Schema Inclusion (continued) Library LibDB LibLoans dom stock = shelved ∪ dom issued ran issued ⊆ readers
  • 190. Schema Decoration Issue Library Library' c? : Copy; r? : Reader c? ∈ shelved; r? ∈ readers #(issued  {r?}) < maxloans issued' = issued ⊕ {c? r?} stock' = stock; readers' = readers
  • 191. Schema Decoration Issue ∆Library c? : Copy; r? : Reader c? ∈ shelved; r? ∈ readers #(issued  {r?}) < maxloans issued' = issued ⊕ {c? r?} stock' = stock; readers' = readers
  • 192. The Schema Calculus Schema inclusion Schema decoration Schema disjunction: ^ AddCopy = AddKnownTitle ∨ AddNewTitle Schema conjunction: ^ AddCopy = EnterNewCopy ∧ AddCopyAdmin Schema negation Schema composition
  • 194. What is in a Requirements Document? Example (Web Butler and Web Site Profiler) • Run web data collection in real time or batch mode How are jobs started? • Job parameters How are the parameters set up (interactive, edit file, ...)? What are the parameters (specify)? Can job parameters be stored and used again? If so, how? • Job monitoring What feedback is given while job is running? Can the user pause or break a job? If so, are the results retained?
  • 195. What is in a Requirements Document? Remember • The requirements document specifies the functionality that you plan to deliver to the client • It must be comprehensive and detailed. Everything must be written out -- no hand waving! The requirements document is likely to be several times as long as Assignment 1.
  • 196. Assignment 2 -- Individual Parts One approach: With your document, include a list of who contributed what part to the Requirements study, e.g., Person A Requirements analysis for database design (member of team of 3), wrote Section 3.1 of document, worked with client to identify software needs. Person B Prepared visual aids for presentation, edited entire document, specified the security needs and wrote Section 4.2.
  • 197. The Waterfall Model Requirements Definition System and Software design Implementation and Unit Testing Integration and System Testing Operation and Maintenance
  • 198. Useful Texts Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language. Addison-Wesley 1999. Grady Booch, Object-Oriented Analysis and Design with Applications, second edition. Benjamin/Cummings 1994. Rob Pooley, Perdita Stevens, Using UML Software Engineering with Objects and Components. Addison-Wesley 1999.
  • 199. The Importance of Modeling • A model is a simplification of reality. • We build models so that we can better understand the system we are developing. • We build models of complex system because we cannot comprehend such a system in its entirety. Models can be informal or formal. The more complex the project the more valuable a formal model becomes. BRJ
  • 200. Principles of Modeling • The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. • Every model can be expressed at different levels of precision. • The best models are connected to reality. • No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models. BRJ
  • 201. The Unified Modeling Language UML is a standard language for modeling software systems. • Serves as a bridge between the requirements specification and the implementation. • Provides a means to specify and document the design of a software system. • Is process and programming language independent. • Is particularly suited to object-oriented program development.
  • 202. Notation: Classes Window origin size open() close() move() display() name attributes operations A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.
  • 203. Notation: Interface ISpelling An interface is a collection of operations that specify a service of a class or component, i.e., the externally visible behavior of that element.
  • 204. Notation: Collaboration & Use Case Chain of responsibility A collaboration defines an interaction, i.e., a society of roles and other elements that work together to provide some cooperative behavior. Place order A use case is a description of a set of sequence of actions that a system performs that yields an observable result.
  • 205. Notation: Active Class EventManager eventlist suspend() flush() An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity.
  • 206. Notation: Component & Node orderform.java A component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Server A node is a physical element that exists at run time and represents a computational resource.
  • 207. Notation: Behavioral Things: Messages & States display An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. Waiting A state machine is a behavior that specifies the sequence of states an object or an interaction goes through during its lifetime in response to events.
  • 208. Notation: Grouping and Annotation Business rules A package is a general-purpose mechanism for organizing elements into groups. return copy of self A note is a symbol for rendering constraints and comments attached to an element or a collection of elements.
  • 209. Notation: Relationships A dependency is a semantic relationship between two things in which a change to one may effect the semantics of the other. 0..1 employer * employee An association is a structural relationship that describes a set of links, a link being a connection among objects.
  • 210. Notation: Relationships (continued) child parent A generalization is a specialization/generalization relationship is which objects of the specialized element (child) are substitutable for objects of the generalized element (parent). A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.
  • 211. Diagrams in UML A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships). • Class diagram shows a set of classes, interfaces, and collaborations with their relationships. • Object diagram shows a set of objects and their relationships. • Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.
  • 212. Diagrams in UML (continued) • Interaction diagram shows an interaction, consisting of a set of objects and the relationships, including the messages that may be dispatched among them. => A sequence diagram emphasizes the time ordering. => A collaboration diagram emphasizes the structural organization of the objects that send and receive messages.
  • 213. Diagrams in UML (continued) • Statechart diagram shows a state machine consisting of states, transitions, events, and activities. • Activity diagram is a statechart diagram that shows the flow from activity to activity within a system. • Component diagram shows the organization and dependencies among a set of components. • Deployment diagram shows the configuration of processing nodes and the components that live on them.
  • 215. Abstraction for HelloWorld class name HelloWorld operations paint() annotation g.drawString ("HelloWorld", 0, 10)"
  • 216. The "Hello, World" Example import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) { g.drawString ("Hello, World!", 10, 10); } } Example from: BJR
  • 217. Class Diagram Applet generalization Note that the Applet and Graphics classes are shown elided. HelloWorld paint() dependency Graphics
  • 220. Notation for Classes and Objects Classes AnyClass attribute1 attribute2 operation1() operation2() or AnyClass Objects anObject:AnyClass or :AnyClass or anObject The names of objects are underlined.
  • 222. Requirements: 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, ...)
  • 223. 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?
  • 224. Modeling Classes Given a real-life system, how do you decide what classes to use? • What terms do the users and implementers use to describe the system? They are candidates for classes. • Is each candidate class crisply defined? • For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes? • What attributes and operations does each class need to carry out its responsibilities?
  • 225. Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others 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. The system must keep track of when books and journals are borrowed and returned and enforce the rules.
  • 226. Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others 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. The system must keep track of when books and journals are borrowed and returned and enforce the rules.
  • 227. Candidate Classes Library Book Journal Copy ShortTermLoan LibraryMember Week MemberOfLibrary Item Time MemberOfStaff System Rule the name of the system event measure repeat book or journal abstract term general term general term
  • 228. Relations between Classes Book Journal Copy LibraryMember Item MemberOfStaff Is Item needed? is an is an is a copy of a Item Item Book is a LibraryMember
  • 230. Class Diagram MemberOfStaff LibraryMember 1 1 on loan on loan 0..12 Journal 0..* Copy is a copy of 1..* 1 Book
  • 231. Rough Sketch: Wholesale System A wholesale merchant supplies retail stores from stocks of goods in a warehouse. What classes would you use to model this business?
  • 232. Rough Sketch: Wholesale System RetailStore Order Merchant Product Warehouse Invoice Shipment
  • 233. Rough Sketch: Wholesale System RetailStore name address contactInfo financialInfo Merchant Warehouse Order Product Reversals Invoice Shipment damaged() return() wrongItem() Responsibilities -track status of shipped products responsibility (text field)
  • 234. Expanding a Class: Modeling Financial Information RetailStore association 1 * Transaction Which class is responsible for the financial records for a store? Payment Invoice
  • 236. Lessons Learned Design is empirical. There is no single correct design. During the design process: • Eliding: Elements are hidden to simplify the diagram • Incomplete: Elements may be missing. • Inconsistency: The model may not be consistent The diagram is not the whole design. Diagrams must be backed up with specifications.
  • 237. Levels of Abstraction The complexity of a model depends on its level of abstraction: • High-levels of abstraction show the overall system. • Low-levels of abstraction are needed for implementation. Two approaches: • Model entire system at same level of abstraction, but present diagrams with different levels of detail. • Model parts of system at different levels of abstraction.
  • 239. Actor and Use Case Diagram BookBorrower Borrow book • 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.
  • 240. Use Cases and Actors • A scenario is an instance of a use 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.
  • 241. Use Cases for Borrowing Books Borrow copy of book BookBorrower Extend loan Return copy of book Reserve book
  • 242. Relationships Between Use Cases: <<uses>> Extend loan BookBorrower Borrow copy of book <<uses>> <<uses>> Check for reservation
  • 243. Relationships Between Use Cases: <<extends>> BookBorrower <<extends>> Borrow copy of book Refuse loan
  • 244. 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
  • 246. Comments on Presentations Presentation • Standard of graphics has been high • Some text too small (diagrams, screen dumps) Content • Level of detail • Requirements v. design The client defines the requirements Well done, but time is short. What is your critical path?
  • 247. Modeling Dynamic Aspects of Systems Interaction diagrams: set of objects and their relationships including messages that may be dispatched among them • Sequence diagrams: time ordering of messages • Collaboration diagrams: structural organization of objects that send and receive messages Activity diagram: flow chart showing flow of control from activity to activity Statechart diagram: models a state machine
  • 248. Bouncing Ball Diagrams Example: http://www.cs.cornell.edu/ domain name TCP connection HTTP get Client Servers
  • 251. 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
  • 252. Sequence Diagram: Borrow copy of a Book libMem: LibraryMember BookBorrower theBook:Book theCopy:Copy borrow(theCopy) okToBorrow borrow borrow
  • 255. Activity Diagram: Process Modeling Release work order branch [materials not ready] [materials ready] Assign tasks Reschedule guard expression
  • 256. Activity Diagram: Parallel Activities start state Decompress fork Stream video join stop state Stream audio
  • 257. State Diagram returned() not borrowable returned() borrowable borrowed()[last copy] guard expression borrowed()[not last copy] State diagram for class Book
  • 258. Implementation Modeling Subsystem A grouping of elements that specifies what a part of a system should do. Component (UML definition) "A distributable piece of implementation of a system, including software code (source, binary, or executable) but also including business documents, etc., in a human system." A component can be thought of as an implementation of a subsystem.
  • 262. Components and Classes Classes represent logical abstractions. Components represent physical things. Components may live on nodes. Classes have attributes and operations directly. Components have operations that are reachable only through interfaces.
  • 264. Application Programming Interface (API) API is an interface that is realized by one or more components. simulation.exe IRender IModels ILighting
  • 265. Components and Replaceability Components allow system to be assembled from binary replaceable elements. • A component is physical -- bits not concepts • A component can be replaced by any other component(s) that conforms to the interfaces. • A component is part of a system. • A component provides the realization of a set of interfaces.
  • 266. Software Engineering Lecture 14 System Architecture I Data Intensive Systems
  • 267. System Architecture The overall design of a system: • • • • • • Computers and networks (e.g., monolithic, distributed) Interfaces and protocols (e.g., http, CORBA) Databases (e.g., relational, distributed) Security (e.g., smart card authentication, SSL) Operations (e.g., backup, archiving, audit trails) Software environments (e.g., languages, source control tools)
  • 268. Data Intensive Systems Examples • Electricity utility customer billing • Telephone company call recording and billing • Car rental reservations (e.g., Hertz) • Stock market brokerage (e.g., Charles Schwab) • Web sales (e.g., Amazon.com)
  • 269. Example 1: Electricity Utility Billing First attempt: Transaction Data input Master file Each transaction handled as it arrives. Bill
  • 270. Criticisms of First Attempt Where is this first attempt weak? The requirements have not been specified!!!
  • 271. Transaction Types • • • • • • • • Create account / close account Meter reading Payment received Other credits / debits Check cleared / check bounced Account query Correction of error etc., etc., etc.,
  • 272. Typical Requirements • All payments to be credited on day received • Customers must be able to query account by telephone • Cutting off service for non-payment requires management authorization • Data input staff should process n transactions per day per person • Error rate must be below 0.01% • System available 99.9% of business hours
  • 273. Batch Processing: Validation errors Edit & validation Incoming transactions Data input read only Master file Validated transactions
  • 274. Batch Processing: Master File Update Validated transactions in batches errors Reports Sort by account Master file update Bills Instructions
  • 275. Benefits of Batch Updating • All transactions for an account are processed together • Backup and recovery have fixed checkpoints • Better management control of operations • Efficient use of staff and hardware
  • 277. Example 2: A Small-town Stockbroker • Transactions Received by mail or over telephone For immediate or later action • Complex customer inquiries • Highly competitive market
  • 278. A Database Architecture Database(s): • Customer and account database • Financial products (e.g., account types, pension plans, savings schemes) • External databases (e.g., stock markets, mutual funds, insurance companies)
  • 279. Database Architecture Products & services database Customer & account database External services
  • 280. Real-time Transaction Real-time transactions Products & services database Customer & account database External services
  • 281. Real-time Transactions & Batch Processing Real-time transactions Products & services database Data input Batch processing Customer & account database External services
  • 282. Architectural considerations • Real-time service during scheduled hours + batch processing overnight • Combine information from several databases • Database consistency after any type of failure two-phase commit reload from checkpoint + log detailed audit trail • How will transaction errors be avoided? • How will transaction errors be corrected?
  • 283. Example: Merger of Two Banks Each bank has a database with its customer accounts. The databases are used by staff at many branches and for back-office processing. The requirement is to integrate the two banks so that they appear to the customers to be a single organization and to provide integrated service from all branches.
  • 284. Merger of Two Banks: Options A ??? ??? B
  • 285. Merger of Two Banks: Architectural Options I. Convert everything to System A. convert databases retrain staff enhance System A (software and hardware) discard System B II. Build an interface between the databases in System A and System B. III. Extend client software so that it can interact with either System A or System B database.
  • 286. Distributed Computing: General Problem An application that is running on one computer wishes to use data or services provided by another: • Network connection private, public, or virtual private network location of firewalls • Protocols point-to-point, multicast, broadcast message passing, RPC, distributed objects stateful or stateless • Quality of service
  • 287. Network Choices Public Internet: Ubiquitous -- worldwide Low cost Private network: Security Predictable performance Choice of protocols (e.g., IBM's SNA)
  • 288. Quality of Network Services Performance Maximum throughput Variations in throughput Real-time media (e.g., audio) Business Suppliers Trouble shooting and maintenance Upgrades
  • 289. Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
  • 290. Software Engineering Lecture 15 System Architecture II Distributed and Real Time Systems
  • 291. Comments on Requirements Report Audience • • Client and design team Will be updated over time Content • • • Level of detail -- will be used to validate the implementation Requirements, not design Precise, but not legalistic
  • 293. Sequence Diagram: Branching libMem: LibraryMember theCopy:Copy BookBorrower 1:borrow(theCopy) [not ok]3:noborrow branch theBook:Book 2:okToBorrow [ok]3:borrow 4:borrow
  • 294. Example: Distributed Database two copies of the same data
  • 295. Distributed Data and Replication Distributed Data Data is held on several computer systems. A transaction may need to assemble data from several sources. Replication Several copies of the data are held in different locations. Mirror: Complete data set is replicated Cache: Dynamic set of data is replicated (e.g., most recently used) With replicated data, the biggest problem is consistency.
  • 296. Example: Broadcast Search User User interface server Databases
  • 298. Stateless Protocol v. Stateful Stateless protocol Example: http Open connection Send message Return reply Close connection State in http must be sent with every message (e.g., as parameter string or in a cookie)
  • 299. Stateless Protocol v. Stateful Stateful (session) protocol Example: Z39.50 Open connection Begin session Interactive session End session Close connection Server remembers the results of previous transactions (e.g., authentication, partial results) until session is closed.
  • 300. Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
  • 301. The Domain Name System First attempt to resolve www.cs.cornell.edu .edu server 1 2 3 cornell.edu server cs.cornell.edu server
  • 302. Discussion of the First Attempt Problems?
  • 303. The Domain Name System Better method local DNS server 1 almaden.ibm.com cornell.edu Local ece.cmu.edu cache ibm.com acm.org .edu .edu server 2 cornell.edu server 3 cs.cornell.edu server
  • 304. Real Time System A real time system is a software system whose correct functioning depends upon the results produced and the time at which they are produced. • A soft real time system is degraded if the results are not produced within required time constraints • A hard real time system fails if the results are not produced within required time constraints
  • 305. Example: Web Server http message daemon TCP port 80 spawned processes The daemon listens at port 80. When a message arrives it: spawns a processes to handle the message returns to listening at port 80
  • 306. Embedded Systems Software and hardware are combined to provide an integrated unit, usually dedicated to a specific task: • Digital telephone • Automobile engine control • GPS • Scientific instruments The software may be embedded in the device in a manner that can not be altered after manufacture.
  • 307. Example: Autonomous Land Vehicle GPS Steer Sonar Model Laser Control signals Throttle Controls Sensors Signal processing
  • 308. Other Applications Response critical • Network router • Telephone switch • Seat bag controller Shared systems • Multi-user data processing • Time sharing
  • 309. Techniques • Special purpose hardware • Multi-threading and multi-tasking • Parallel processing => digital signal processing • Interrupts => levels and priorities
  • 310. Multi-Threading Several similar threads operating concurrently: • Re-entrant code -- separation of pure code from data for each thread • Testing -- single thread and multi thread May be real time (e.g., telephone switch) or nontime critical
  • 311. Real Time Executive Schedules and dispatches tasks in a real time system • Real time clock • Interrupt handler • Scheduler • Resource manager • Dispatcher Must be extremely reliable
  • 312. Timing Timing mechanisms • Synchronous (clocked) -- periodic stimuli • Asynchronous -- wait for next signal Example: Communications protocols may be synchronous or asynchronous
  • 313. Hardware v. Software Design of embedded systems requires close understanding of hardware characteristics • Special purpose hardware requires special tools and expertise. • Some functions may be implemented in either hardware of software (e.g., floating point unit) • Design requires separation of functions Distinction between hardware and software may be blurred.
  • 314. Example: Dartmouth Time Shared System master processor Communications processor Communications processor I/O Mulitplexor Central processor Central processor Central processor
  • 315. Software Considerations Resource considerations may dictate software design and implementation: • Low level language (e.g., C) where programmer has close link to machine • Inter-process communication may be too slow (e.g., C fork). • May implement special buffering, etc., to control timings
  • 317. Continuous Operation Many systems must operate continuously • Software update while operating • Hardware monitoring and repair • Alternative power supplies, networks, etc. • Remote operation These functions must be designed into the fundamental architecture.
  • 318. Routers and Other Network Computing • Interoperation with third party devices • Support for several versions of protocols • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads • Time outs, dropped packets, etc. • Evolution of network systems
  • 319. Software Engineering Lecture 15 System Architecture II Distributed and Real Time Systems
  • 320. Administration Assignment 2: Requirements • • • Grades -- presentation, report, individual Comments at presentation Comments from teaching assistant Assignment 3: Design
  • 321. Comments on Requirements Report Audience • • Client and design team Will be updated over time Content • • • Level of detail -- will be used to validate the implementation Requirements, not design Precise, but not legalistic
  • 323. Sequence Diagram: Branching libMem: LibraryMember theCopy:Copy BookBorrower 1:borrow(theCopy) [not ok]3:noborrow branch theBook:Book 2:okToBorrow [ok]3:borrow 4:borrow
  • 324. Example: Distributed Database two copies of the same data
  • 325. Distributed Data and Replication Distributed Data Data is held on several computer systems. A transaction may need to assemble data from several sources. Replication Several copies of the data are held in different locations. Mirror: Complete data set is replicated Cache: Dynamic set of data is replicated (e.g., most recently used) With replicated data, the biggest problem is consistency.
  • 326. Example: Broadcast Search User User interface server Databases
  • 328. Stateless Protocol v. Stateful Stateless protocol Example: http Open connection Send message Return reply Close connection State in http must be sent with every message (e.g., as parameter string or in a cookie)
  • 329. Stateless Protocol v. Stateful Stateful (session) protocol Example: Z39.50 Open connection Begin session Interactive session End session Close connection Server remembers the results of previous transactions (e.g., authentication, partial results) until session is closed.
  • 330. Firewall Public network Private network Firewall A firewall is a computer at the junction of two network segments that: • Inspects every packet that attempts to cross the boundary • Rejects any packet that does not satisfy certain criteria, e.g., an incoming request to open a TCP connection an unknown packet type
  • 331. The Domain Name System First attempt to resolve www.cs.cornell.edu .edu server 1 2 3 cornell.edu server cs.cornell.edu server
  • 332. Discussion of the First Attempt Problems?
  • 333. The Domain Name System Better method local DNS server 1 almaden.ibm.com cornell.edu Local ece.cmu.edu cache ibm.com acm.org .edu .edu server 2 cornell.edu server 3 cs.cornell.edu server
  • 334. Real Time System A real time system is a software system whose correct functioning depends upon the results produced and the time at which they are produced. • A soft real time system is degraded if the results are not produced within required time constraints • A hard real time system fails if the results are not produced within required time constraints
  • 335. Example: Web Server http message daemon TCP port 80 spawned processes The daemon listens at port 80. When a message arrives it: spawns a processes to handle the message returns to listening at port 80
  • 336. Embedded Systems Software and hardware are combined to provide an integrated unit, usually dedicated to a specific task: • Digital telephone • Automobile engine control • GPS • Scientific instruments The software may be embedded in the device in a manner that can not be altered after manufacture.
  • 337. Example: Autonomous Land Vehicle GPS Steer Sonar Model Laser Control signals Throttle Controls Sensors Signal processing
  • 338. Other Applications Response critical • Network router • Telephone switch • Seat bag controller Shared systems • Multi-user data processing • Time sharing
  • 339. Techniques • Special purpose hardware • Multi-threading and multi-tasking • Parallel processing => digital signal processing • Interrupts => levels and priorities
  • 340. Multi-Threading Several similar threads operating concurrently: • Re-entrant code -- separation of pure code from data for each thread • Testing -- single thread and multi thread May be real time (e.g., telephone switch) or nontime critical
  • 341. Real Time Executive Schedules and dispatches tasks in a real time system • Real time clock • Interrupt handler • Scheduler • Resource manager • Dispatcher Must be extremely reliable
  • 342. Timing Timing mechanisms • Synchronous (clocked) -- periodic stimuli • Asynchronous -- wait for next signal Example: Communications protocols may be synchronous or asynchronous
  • 343. Hardware v. Software Design of embedded systems requires close understanding of hardware characteristics • Special purpose hardware requires special tools and expertise. • Some functions may be implemented in either hardware of software (e.g., floating point unit) • Design requires separation of functions Distinction between hardware and software may be blurred.
  • 344. Example: Dartmouth Time Shared System master processor Communications processor Communications processor I/O Mulitplexor Central processor Central processor Central processor
  • 345. Software Considerations Resource considerations may dictate software design and implementation: • Low level language (e.g., C) where programmer has close link to machine • Inter-process communication may be too slow (e.g., C fork). • May implement special buffering, etc., to control timings
  • 347. Continuous Operation Many systems must operate continuously • Software update while operating • Hardware monitoring and repair • Alternative power supplies, networks, etc. • Remote operation These functions must be designed into the fundamental architecture.
  • 348. Routers and Other Network Computing • Interoperation with third party devices • Support for several versions of protocols • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads • Time outs, dropped packets, etc. • Evolution of network systems
  • 349. Software Engineering Lecture 16 System Architecture III Distributed Objects
  • 350. Real-Time: Software Considerations Resource considerations may dictate software design and implementation: • Low level language (e.g., C) where programmer has close link to machine • Inter-process communication may be too slow (e.g., C fork). • May implement special buffering, etc., to control timings
  • 351. Buffering Example: CD Controller 4 Input block 7 3 2 5 6 Circular buffer 1 Output block
  • 352. Continuous Operation Many systems must operate continuously • Software update while operating • Hardware monitoring and repair • Alternative power supplies, networks, etc. • Remote operation These functions must be designed into the fundamental architecture.
  • 353. Example: Routers and Other Network Computing • Interoperation with third party devices • Support for several versions of protocols • Restart after total failure • Defensive programming -- must survive => erroneous or malicious messages => extreme loads • Time outs, dropped packets, etc. • Evolution of network systems
  • 354. Example: Transaction Monitor messages Transaction monitor processes A transaction monitor: monitors transactions, routes them across services, balances the load, restarts transactions after failure.
  • 355. Software Reuse: Application Packages • Package supports a standard application (e.g., payroll, user interface to Internet information, mathematical algorithms) • Functionality can be enhanced by: => configuration parameters (e.g., table driven) => extensibility at defined interfaces => custom written source code extensions
  • 356. Reuse: Object Object Oriented Languages Example: Java is a relatively straightforward language with a very rich set of class hierarchies. • Java programs derive much of their functionality from standard classes • Learning and understanding the classes is difficult. => Java experts can write complex systems quickly => Inexperienced Java programmers write inelegant and buggy programs
  • 357. Reuse: Objects - Basic Definitions • An object is a piece of code that owns attributes and provides services through methods. • The methods operate on instance data owned by the object. • A class is a collection of like objects.
  • 358. Reuse: Objects - Characteristics • Encapsulation. An object has a public interface that defines how other objects or applications can interact with it. methods public instance data • Inheritance. Subclasses can be derived from parent classes. They inherit or override the parents' methods and instance data. • Polymorphism. The effect of a method can vary depending on the class that implements it (e.g., display_object)
  • 359. Reuse: Objects - Object Binding Binding is the linking of the software interface between two objects. • Static binding: The interface is determined at compile or build time. Straightforward Allows type checking • Dynamic binding or late binding: The link is established at run time. Flexible and extensible Complex
  • 360. Reuse: Objects - Distributed Objects Objects on separate computers interact through method calls and instance data. Major systems: • CORBA (Common Object Request Broker Architecture) • Microsoft family: OLE, COM, DCOM, Active X ...
  • 361. Desirable Properties of Distributed Objects • Different languages and operating environments • Reusable code: components • Architecture can be extensible • Future changes can be localized • Standard tools used for client/server interactions
  • 362. Example: Fedora IDL A research project to explore extensibility: -- very simple Interface Definition Language -- powerful tools for extensions -- interoperability, Cornell and CNRI http://www.cs.cornell.edu/cdlrg/fedora.html
  • 363. Object Request Broker (ORB) C C++ Cobol Objects IDL IDL IDL Interface IDL Java Client Other IDL Server Object Request Broker
  • 364. Interface Definition Language module <identifier> { <type declarations>; <constant declarations>; <exception declarations>; Naming context interface <identifier> [:<inheritance>] { See next slide } interface <identifier> [:<inheritance>] { ..... } { Define a class Define a class
  • 365. Interface Definition Language (continued) interface <identifier> [:<inheritance>] { <type declarations>; <constant declarations>; <exception declarations>; Define a class [<op_type] <identifier>(<parameters>) Define a method [raises exception] [context]; .... [<op_type] <identifier>(<parameters>) Define a method [raises exception] [context]; .... }
  • 366. ORB: Programmer's View Client Invoke a on object X Server Invoke a on object Y Object X Object Y a a Object Request Broker
  • 367. Object Request Broker (ORB) An ORB lets objects make requests to and receive response from other objects located locally or remotely. • Static and dynamic method invocations • High-level language bindings • Self-describing system • Local/remote transparency • Inter-ORB protocols Internet Inter-ORB Protocol (IIOP)
  • 368. ORB: System View Interface repository Client Dynamic Client IDL ORB invocation stubs interface Object Implementation implementation repository Static Dynamic Object skeletons invocation adapter Object Request Broker
  • 369. CORBA Services • • • • • • • • • • • • • Naming service Event service Concurrency control service Transaction service Relationship service Externalization service Query service Life cycle service Persistence service Licensing service Properties service Security service Time service
  • 370. Distributed Objects and the System Life-Cycle All large systems change with time. • Dynamic binding of objects combined with polymorphism permits the addition of extra object types, incremental changes, etc. to be localized. Development environments change with time. • Language bindings and IIOP permit changes. Production environments changes with time. • Code can be reused in different environments.
  • 372. Q2: Finite State Machine The cruise control system on an automobile is controlled by a master switch and three buttons. Initially, it is turned on by the master switch. The master switch can be turned off at any time. When first turned on, the system enters stand-by mode. When the system is in stand-by mode, the driver of the automobile can press Button A to engage the cruise control at the current speed of the automobile. When the cruise control is engaged, if the driver presses the brake or presses Button B the system will be disengaged and return to stand-by mode. After returning to standby mode, the driver can press Button C to engage the cruise control at the speed that it was set at previously. (After the system is first turned on, Button C has no effect.) When the cruise control is engaged, the driver can press Button A to increase speed by one mile per hour or Button C to decrease speed by one mile per hour.
  • 374. State Transition Table MS on MS off A Standby Off Engaged Engaged Off Engaged Standby1 Engaged Standby1 Off Engaged Off B Brake C Standby Engaged
  • 375. Question 4 When software is written, who owns the copyright? How can somebody else be permitted to use the software? How can copyright be transferred to somebody else?
  • 376. Question 4 When software is written, who owns the copyright? The person who writes the software Except work for hire -- the employer How can somebody else be permitted to use the software? By permission from the copyright owner (usually a license) How can copyright be transferred to somebody else? Copyright is property that can be sold or given away (usually a contract)
  • 377. Question 4 You are employed for company X writing software. When you leave, who owns your work? What use can you make of the work?
  • 378. Question 4 You are employed for company X writing software. When you leave, who owns your work? The company (work for hire) What use can you make of the work? None without permission of the copyright owner
  • 379. Question 4 You work free-lance for company X. When you finish, who owns your work? What use can you make of the work?
  • 380. Question 4 You work free-lance for company X. When you finish, who owns your work? It depends on the circumstances Have a written contract What use can you make of the work? If you hold the copyright -- unrestricted Otherwise -- none without agreement
  • 381. Distributed Objects and the System LifeCycle All large systems change with time. • Dynamic binding of objects combined with polymorphism permits the addition of extra object types, incremental changes, etc. to be localized. Development environments change with time. • Language bindings and IIOP permit changes. Production environments changes with time. • Code can be reused in different environments.
  • 382. Design for Usability Usability of a computer system is a combination of factors: • User interface design • Functionality • Performance • Help systems and documentation • Freedom from errors Anything else?
  • 384. Methods for Evaluation of Usability • Observing users (user protocols) • Focus groups • Measurements effectiveness in carrying out tasks speed • Expert review • Client's opinions • Competitive analysis
  • 385. Levels of Usability interface design conceptual model functional design data and metadata computer systems and networks