ilovepdf_merged.pdf - CSE 687 OOD Week 1 Introduction Edmund Yu PhD Associate Teaching Professor [email protected] 21 2020 1

ilovepdf_merged.pdf - CSE 687 OOD Week 1 Introduction...

This preview shows page 1 out of 754 pages.

You've reached the end of your free preview.

Want to read all 754 pages?

Unformatted text preview: CSE 687 OOD Week 1: Introduction Edmund Yu, PhD Associate Teaching Professor [email protected] January 14, 16, 21, 2020 1 2 ` 3 ` 4 Assignment #1 (10 points) ❖Propose a “killer app” idea for your team. ❖Due: January 31 ❖High-level descriptions are acceptable. Technical details are not required at this stage. Minimum: 1 (full) page. ❖Must give reasons why you think what you are proposing is a killer app. ❖Don’t forget to elect a team lead, and list all the team members. ❖Will be graded mainly by 3 categories: creativity, clarity, and project scope. ❖Submit via Blackboard 5 Assignment #1 (10 points) ❖Project Scope – My subjective view: ❖I assume each team member should be able to write 250 lines of Java code per week (50 lines per hour X 5 hours per week) for about 8 weeks. ❖Therefore, for a team of 5, I will use 10,000 lines of Java code to assess whether their project scope is too small. ❖But as I said, this is subjective, and has to be adjusted for different languages, and the extent of code reuse. So, please just use your best judgment to assess whether your project scope is too small for your team size. 6 What Is Software? ❖ Computer programs and associated documentation ❖ Software products may be: ❖ Generic products: software developed for a general market ❖PC software such as graphics programs, project management tools; CAD software; software for specific markets such as appointments systems for dentists, etc ❖ Customized products: software developed for a particular customer ❖Embedded control systems, air traffic control software, traffic monitoring systems, etc ❖ Software is hard (Donald Knuth): ❖ Can become extremely complex, difficult to understand and expensive to change ❖ It's hard enough to find an error in your code when you're looking for it; it's even harder when you've assumed your code is error-free. (Steve McConnell, Code Complete) 7 What are the Attributes of Good Software? ❖Good software: ❖Should deliver the required functionality and performance to the user ❖Should be maintainable, dependable, efficient and usable ❖Definitions on next slide 8 Attributes of Good Software Product characteristic Description Maintainability Software should be written in such a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is inevitable in a changing business environment. Dependability Software dependability includes a range of characteristics including reliability, security and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to access or damage the system. Efficiency Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilization, etc. Acceptability Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable 9 and compatible with other systems that they use. What Is Software Engineering? ❖ Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. ❖ Engineering discipline ❖Using appropriate theories and methods to solve problems bearing in mind organizational and financial constraints ❖ All aspects of software production ❖Not just technical process of development. Also project management and the development of tools, methods etc. to support software production ❖ The systematic approach used in software engineering is called a software process 15 Importance of Software Engineering ❖Individuals and society rely on advanced software systems more and more. ❖We need to be able to produce reliable and trustworthy systems economically and quickly. ❖It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. ❖For most types of system, the majority of costs are the costs of changing the software after it has gone into use. 16 Importance of Software Engineering ❖In this video, Professor Ian Sommerville, the author of our textbook, explains the economic and social importance of software engineering and how it is central to all economic and social developments in the 21st century. ❖ 17 Software Application Types 18 What Are the Best SE Techniques/Methods? ❖While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of system. ❖For example: ❖Games should always be developed using a series of prototypes (→ the incremental development model) ❖Safety critical control systems require a complete and analyzable specification to be developed first (→ the waterfall model) ❖Therefore, you can’t say that one method is better than another. 19 Application Types ❖Stand-alone applications ❖These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network. ❖Interactive transaction-based applications ❖Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web applications such as e-commerce applications. 20 Application Types ❖Embedded control systems ❖These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system. ❖Batch processing systems ❖These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. 21 Application Types ❖Entertainment systems ❖These are systems that are primarily for personal use and which are intended to entertain the user. ❖Systems for simulation and modelling ❖These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects. 22 Application Types ❖Data collection systems ❖These are systems that collect data from their environment using a set of sensors and send that data to other systems for processing. ❖Systems of systems ❖These are systems that are composed of a number of other software systems 23 What Differences Has the Web Made to SE? ❖ The Web is now a platform for running application. ❖ Organizations are increasingly developing web-based systems rather than local systems. ❖ Web services allow application functionality to be accessed over the web. ❖ Cloud computing is an approach to the provision of computer services where applications run remotely on the ‘cloud’. Users do not buy software/hardware. They pay according to use. ❖Infrastructure as a service (IaaS): AWS/Amazon Elastic Compute Cloud (EC2) ❖Platform as a service (PaaS): AWS, Google Cloud Platform/App Engine, MS Azure, Rest APIs ❖Software as a service (SaaS): Google Apps, Salesforce.com 24 Web Software Engineering ❖Software reuse ❖Software reuse is the dominant approach for constructing web-based systems. ❖When building these systems, you think about how you can assemble them from pre-existing software components and systems. ❖Incremental and agile development ❖Web-based systems should be developed and delivered incrementally. ❖It is now generally recognized that it is impractical to specify all the requirements for such systems in advance. 25 Web Software Engineering ❖Service-oriented systems ❖Software may be implemented using serviceoriented software engineering, where the software components are stand-alone web services. ❖Rich interfaces ❖Interface development technologies such as AJAX and HTML5 have emerged that support the creation of rich interfaces within a web browser. 26 Software Processes 27 Software Processes ❖ Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. ❖ Engineering discipline ❖Using appropriate theories and methods to solve problems bearing in mind organizational and financial constraints ❖ All aspects of software production ❖Not just technical process of development. Also project management and the development of tools, methods etc. to support software production ❖ The systematic approach used in software engineering is called a software process 28 Plan-Driven and Agile Processes ❖There are two main categories of software processes: ❖Plan-driven processes: ❖Processes where all of the process activities are planned in advance and progress is measured against this plan ❖Agile processes: ❖Processes where planning is incremental and it is easier to change the process to reflect changing customer requirements ❖In practice, most practical processes include elements of both plan-driven and agile approaches 29 Software Process Models ❖ A software process model is a simplified representation of a software process. ❖ Three commonly used models are: ❖The waterfall model ❖Plan-driven model ❖Separate and distinct phases of specification and development ❖Incremental development ❖Specification, development and validation are interleaved ❖May be plan-driven or agile ❖Reuse-oriented software engineering (Integration and Configuration) ❖The system is assembled from existing components ❖May be plan-driven or agile 30 The Waterfall Model Figure 2.1 The waterfall model 31 The 7-Stage Waterfall Model System Requirements Software Requirements Analysis Design Coding Testing Operations 32 Waterfall Model Problems ❖Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements ❖This model is only appropriate when ❖The requirements are well-understood ❖Changes will be fairly limited during the design process ❖Few business systems have stable requirements. ❖Therefore, the waterfall model is mostly used for large systems engineering projects where a system is developed at several sites ❖In those circumstances, the plan-driven nature of the waterfall model helps coordinate the work. 33 Incremental Development Figure 2.2 Incremental development 34 Software Process Models ❖A software process model is a simplified representation of a software process. ❖Three commonly used models ❖The waterfall model ❖Plan-driven model ❖Separate and distinct phases of specification and development ❖Incremental development ❖Specification, development and validation are interleaved ❖May be plan-driven or agile ❖Reuse-oriented software engineering ❖The system is assembled from existing components ❖May be plan-driven or agile 35 Incremental Development Benefits ❖The cost of accommodating changing customer requirements is reduced. ❖The amount of analysis and documentation that has to be redone is much less than is required with the waterfall model. ❖It is easier to get customer feedback on the development work that has been done. ❖Customers can comment on demonstrations of the software and see how much has been implemented. ❖More rapid delivery and deployment of useful software to the customer is possible. ❖Customers are able to use and gain value from the software earlier than is possible with a waterfall process. 36 Incremental Development Problems ❖The process is not visible. ❖Managers need regular deliverables to measure progress. ❖If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system. ❖System structure tends to degrade as new increments are added. ❖Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure. ❖Incorporating further software changes becomes increasingly difficult and costly 37 Reuse-based Software Engineering ❖Based on software reuse where systems are integrated from existing components or application systems (sometimes called COTS, i.e. CommercialOff-The-Shelf, systems). ❖Reused elements may be configured to adapt their functionality to a user’s requirements ❖Reuse is now the standard approach for building many types of systems ❖Software reuse will be covered in more depth later. 38 Reuse-Oriented Software Engineering Figure 2.3 Reuse-oriented software engineering 39 Software Process Models ❖A software process model is a simplified representation of a software process. ❖Three commonly used models ❖The waterfall model ❖Plan-driven model ❖Separate and distinct phases of specification and development ❖Incremental development ❖Specification, development and validation are interleaved ❖May be plan-driven or agile ❖Reuse-oriented software engineering ❖The system is assembled from existing components ❖May be plan-driven or agile 40 The Reuse Landscape Figure 15.3 The reuse landscape 41 The Reuse Landscape Approach Description Application frameworks Collections of abstract and concrete classes are adapted and extended to create application systems. Application system integration Two or more application systems are integrated to provide extended functionality Architectural patterns Standard software architectures that support common types of application systems are used as the basis of applications. Aspect-oriented software Shared components are woven into an application at development different places when the program is compiled. Component-based software engineering Systems are developed by integrating components (collections of objects) that conform to component-model standards. 42 The Reuse Landscape Approach Description Configurable application systems Domain-specific systems are designed so that they can be configured to the needs of specific system customers. Design patterns Generic abstractions that occur across applications are represented as design patterns showing abstract and concrete objects and interactions. ERP systems Large-scale systems that encapsulate generic business functionality and rules are configured for an organization. Legacy system wrapping Legacy systems are ‘wrapped’ by defining a set of interfaces and providing access to these legacy systems through these interfaces. Model-driven engineering Software is represented as domain models and implementation independent models and code is generated from these models. 43 The Reuse Landscape Approach Description Program generators A generator system embeds knowledge of a type of application and is used to generate systems in that domain from a user-supplied system model. Program libraries Class and function libraries that implement commonly used abstractions are available for reuse. Service-oriented systems Systems are developed by linking shared services, which may be externally provided. Software product lines An application type is generalized around a common architecture so that it can be adapted for different customers. System of systems Two or more distributed systems are integrated to create a new system 44 Benefits of Software Reuse Benefit Explanation Increased dependability ❖ Reused software, which has been tried and tested in working systems, should be more dependable than new software. ❖ Its design and implementation faults should have been found and fixed. Reduced process risk ❖ The cost of existing software is already known, whereas the costs of development are always a matter of judgment. ❖ This is an important factor for project management because it reduces the margin of error in project cost estimation. ❖ This is particularly true when relatively large software components such as subsystems are reused. Effective use of specialists ❖ Instead of doing the same work over and over again, application specialists can develop reusable software that encapsulates their knowledge. 45 Benefits of Software Reuse Benefit Explanation Standards compliance ❖ Some standards, such as user interface standards, can be implemented as a set of reusable components. ❖ E.g., if menus in a user interface are implemented using reusable components, all applications present the same menu to users. ❖ The use of standard user interfaces improves dependability because users make fewer mistakes when presented with a familiar interface. Lower development cost ❖ Development costs are proportional to the size of the software being developed. Reusing software means fewer lines of code to write. Accelerated development ❖ Reusing software can speed up system production because both development and validation time may be reduced. ❖ Bringing a system to market as early as possible is often more important than overall costs. 46 Problems with Reuse Problem Explanation Increased maintenance costs ❖ If the source code of a reused software system or component is not available then maintenance costs may be higher because the reused elements of the system may become increasingly incompatible with system changes. Lack of tool support ❖ Some software tools do not support development with reuse, and hence it may be difficult or impossible to integrate these tools with a component library system. ❖ This is more likely to be the case for tools that support embedded systems engineering than for object-oriented development tools. Not-invented-here syndrome ❖ Some software engineers prefer to rewrite components because they believe they can improve on them. ❖ This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people’s software. 47 Problems with Reuse Problem Explanation Creating, maintaining, and using a component library ❖ Populating a reusable component library and ensuring the software developers can use this library can be expensive. ❖ Development processes have to be adapted to ensure that the library is used. Finding, understanding, and adapting reusable components ❖ Software components have to be discovered in a library, understood and, sometimes, adapted to work in a new environment. ❖ Engineers must be reasonably confident of finding a component in the library before they include a component search as part of their normal development process. 48 Software Process Models ❖A software process model is a simplified representation of a software process. ❖Three commonly used models ❖The waterfall model ❖Plan-driven model ❖Separate and distinct phases of specification and development ❖Incremental development ❖Specification, development and validation are interleaved ❖May be plan-driven or agile ❖Reuse-oriented software engineering ❖The system is assembled from existing components ❖May be plan-driven or agile 49 Exercise Suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems. Explain your answer according to the type of system being developed: 1. A system to control anti-lock braking in a car 2. A virtual reality system to support software maintenance 3. A university accounting system that replaces an existing system 4. An interactive travel planning system that helps users plan journeys with the lowest environmental impact 50 Answer 1. 2. 3. 4. Anti-lock braking system - This is a safety-critical system so it requires a lot of up-front analysis before implementation. It certainly needs a plandriven approach to development with the requirements carefully analyzed. A waterfall model is therefore the most appropriate approach to use, perhaps with formal transformations between the different development stages. Virtual reality system - This is a system where the requirements will change and there will be an extensive user interface components. Incremental development with, perhaps, some UI prototyping is the most appropriate model. University accounting system - This is a system whose requirements are fairly well-known and which is used in many existing systems. Therefore, a reuse-based appro...
View Full Document

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture