CSE241/CMM341 Foundations of Software Engineering Topic 7 PDF
Document Details
Uploaded by ClearPoltergeist9006
Universiti Sains Malaysia
null
Tags
Summary
This document is an outline for a software engineering course, covering the topic of architectural and implementation. It details the use cases, and concepts within software engineering. The document describes learning outcomes, case study & diagram; Implementation issues and Open-source development.
Full Transcript
We l e a d CSE241/CMM341 Foundations of Software Engineering TOPIC 7: Architectural and Implementation II CSE241 Course Content We l e a d Foundations 1. Introduction to Software Engineering of Software 2. Software Processes...
We l e a d CSE241/CMM341 Foundations of Software Engineering TOPIC 7: Architectural and Implementation II CSE241 Course Content We l e a d Foundations 1. Introduction to Software Engineering of Software 2. Software Processes 3. Agile Software Development Engineering 4. Requirements Engineering 5. System Modeling 6. Architectural Design & Implementation I 7. Architectural Design & Implementation II 8. Software Testing 9. Software Evolution 10. Project Management 11. Project planning 12. Quality Management 13. Configuration Management Topic 7: Architectural Design & Implementation II Contents IMPLEMENTATION ISSUES OPEN SOURCE DEVELOPMENT Learning outcomes By the end of this topic, you should be able to: Understand the key issues to be considered when implementing software. Understand the possibility of reusing existing software and the emerging of open source solutions to software development. Chapter 7 Design and Implementation Software design and implementation is the stage in the software engineering process at which an executable software system is developed. Software design and implementation Design and activities are invariably inter-leaved. implementation Software design is a creative activity in which you identify software components and their relationships, based on a customer’s requirements. Implementation is the process of realizing the design as a program. An object-oriented design process Structured object-oriented design processes involve developing a number of different system models. They require a lot of effort for development and maintenance of these models and, for small systems, this may not be cost-effective. However, for large systems developed by different groups design models are an important communication mechanism. 30/10/2014 Chapter 7 Design and Implementation Process stages There are a variety of different object-oriented design processes that depend on the organization using the process. Common activities in these processes include: Define the context and modes of use of the system Design the system architecture Identify the principal system objects Develop design models Specify object interfaces Define the context and modes of use of the system A system context model is a structural model that demonstrates the other systems in the environment of the system being developed. Context and interaction An interaction model is a dynamic models model that shows how the system interacts with its environment as it is used. Chapter 7 Design and Implementation 8 System context for the Weather station use cases weather station Chapter 7 Design and Implementation 9 Define the context and modes of use of the system Use case description—Report weather System Weather station Use case Report weather Actors Weather information system, Weather station Description The weather station sends a summary of the weather data that has been Use case collected from the instruments in the collection period to the weather list information system. The data sent are the maximum, minimum, and average ground and air temperatures; the maximum, minimum, and average air pressures; the maximum, minimum, and average wind speeds; the total rainfall; and the wind direction as sampled at five-minute intervals. Stimulus The weather information system establishes a satellite communication link with the weather station and requests transmission of the data. Response The summarized data is sent to the weather information system. Comments Weather stations are usually asked to report once per hour but this frequency may differ from one station to another and may be modified in the future. Chapter 7 Design and Implementation 10 Architectural design Design the system architecture You identify the major Once interactions components that make between the system and up the system and their its environment have interactions, and then been understood, you may organize the use this information for components using an designing the system architectural pattern architecture. such as a layered or client-server model. Chapter 7 Design and Implementation Design the system architecture High-level architecture of the weather station The weather station is composed of independent subsystems that communicate by broadcasting messages on a common infrastructure. The architecture of data collection system Chapter 7 Design and Implementation Identify the principal system objects Approaches to Object class identification Object identification is an iterative process. You are unlikely to get it right first time. Use a grammatical approach based on a natural language description of the system. Base the identification on tangible things in the application domain. Use a behavioural approach and identify objects based on what participates in what behaviour. Use a scenario-based analysis. The objects, attributes and methods in each scenario are identified. 30/10/2014 Chapter 7 Design and Implementation 13 Identify the principal system objects Weather station object classes Ground thermometer, Anemometer, Barometer Application domain objects that are ‘hardware’ objects related to the instruments in the system. Weather station The basic interface of the weather station to its environment. It therefore reflects the interactions identified in the use-case model. Weather data Encapsulates the summarized data from the instruments. Chapter 7 Design and Implementation 14 Develop design models Design models Subsystem models that show logical groupings of objects into coherent subsystems. Design models show objects and object Sequence models that show the sequence of classes + relationships object interactions. between these entities. State machine models that show how individual Two kinds of design objects change their state in response to events. model: Structural models Other models include use-case models, Dynamic models aggregation models, generalisation models, etc. Chapter 7 Design and Implementation 15 Develop design models Sequence diagram describing data collection Weather station state diagram Chapter 7 Design and Implementation 16 Specify object interfaces Interface specification Object interfaces have to be specified so that the objects and other components can be designed in parallel. Objects may have several interfaces which are viewpoints on the methods provided. The UML uses class diagrams for interface specification but Java may also be used. 30/10/2014 Chapter 7 Design and Implementation 17 Specify object interfaces Interface specification Object interfaces have to be specified so that the objects and other components can be designed in parallel. Designers should avoid designing the interface representation but should hide this in the object itself. Objects may have several interfaces which are viewpoints on the methods provided. The UML uses class diagrams for interface specification but Java may also be used. High-fidelity prototyping High-fidelity (hi-fi) prototypes appear and Low-fidelity prototyping function as similar as Low and high Low-fidelity (lo-fi) possible to the actual product that will ship. fidelity prototyping is a quick and easy way to translate high- Teams usually create high- prototyping level design concepts into tangible and testable fidelity prototypes when they have a solid artifacts. understanding of what they are going to build and they The first and most important need to either test it with role of lo-fi prototypes is to real users or get final-design check and test functionality approval from stakeholders. rather than the visual appearance of the product. Example of Software: Marvel Figma Origami Studio Sketch Proto.io Example Low-fidelity (lo-fi) Identify Use Cases Identify Object Classes Topic 7: Architectural Design & Implementation II IMPLEMENTATION ISSUES OPEN SOURCE DEVELOPMENT Implementation issues ▪ The focus here is not on programming, but on implementation issues Reuse Most modern software is constructed by reusing existing components or systems Should use as much as possible of existing code. Configuration management During the development process, keep track of different versions of each software component in a configuration management system. Host-target development develop it on one computer (the host system) and execute it on a separate computer (the target system). 1. Reuse From the 1960s to the 1990s, most new software was developed from scratch, by writing all code in a high-level programming language. The only significant reuse or software was the reuse of functions and objects in programming language libraries. Costs and schedule pressure mean that this approach became increasingly unviable, especially for commercial and Internet-based systems. An approach to development based around the reuse of existing software emerged and is now generally used for business and scientific software. Reuse levels The abstraction level At this level, you don’t reuse software directly but use knowledge of successful abstractions in the design of your software. The object level At this level, you directly reuse objects from a library rather than writing the code yourself. The component level Components are collections of objects and object classes that you reuse in application systems. The system level At this level, you reuse entire application systems. Software reuse Reuse costs The costs of the time spent in looking for software to reuse and assessing whether or not it meets your needs. Where applicable, the costs of buying the reusable software. For large off-the-shelf systems, these costs can be very high. The costs of adapting and configuring the reusable software components or systems to reflect the requirements of the system that you are developing. The costs of integrating reusable software elements with each other (if you are using software from different sources) and with the new code that you have developed. 2. Configuration management Configuration management is the name given to the general process of managing a changing software system. The aim of configuration management is to support the system integration process so that all developers can access the project code and documents in a controlled way, find out what changes have been made, and compile and link components to create a system. Configuration management activities 1 2 3 Version management, where System integration, where Problem tracking, where support is provided to keep track support is provided to help support is provided to allow of the different versions of developers define what versions users to report bugs and software components. Version of components are used to create other problems, and to allow management systems include each version of a system. This facilities to coordinate description is then used to build a all developers to see who is development by several system automatically by working on these problems programmers. compiling and linking the required and when they are fixed. components. Most software is developed on one computer (the host), but runs on a separate machine (the target). A platform is more than just hardware. Host-target More generally, we can talk about a development It includes the installed operating development platform and an execution platform. system plus other supporting software such as a database management system or, for development platforms, an interactive development Development platform environment. usually has different installed software than execution platform; these platforms may have different architectures. Development platform tools An integrated compiler and syntax-directed editing system that allows you to create, edit and compile code. A language debugging system. Graphical editing tools, such as tools to edit UML models. Testing tools, such as Junit that can automatically run a set of tests on a new version of a program. Project support tools that help you organize the code for different development projects. Software development tools are often grouped to create an integrated development environment (IDE). Integrated An IDE is a set of software tools that supports different development aspects of software development, within some common framework and user interface. environments (IDEs) IDEs are created to support development in a specific programming language such as Java. The language IDE may be developed specially, or may be an instantiation of a general-purpose IDE, with specific language-support tools. Component/system deployment factors If a component is designed for a specific High availability systems may require If there is a high level of communications hardware architecture, or relies on some components to be deployed on more than one traffic between components, it usually makes other software system, it must obviously be platform. This means that, in the event of sense to deploy them on the same platform or deployed on a platform that provides the platform failure, an alternative on platforms that are physically close to one required hardware and software support. implementation of the component is available. other. This reduces the delay between the time a message is sent by one component and received by another. Topic 7: Architectural Design & Implementation II Contents IMPLEMENTATION ISSUES OPEN SOURCE DEVELOPMENT The source code of a software system is published and volunteers are invited to participate in the development process The source code should not be proprietary but rather should always be Open source available for users to examine and modify development as they wish. Example : LINUX, Java, the Apache web server and the mySQL database management system. Open source issues Should the product that is being developed make use of open source components? Should an open source approach be used for the software’s development? A fundamental principle of open-source development is that source code should be freely available, this does not mean that anyone can do as they wish with that code. Legally, the developer of the code (either a company or Open an individual) still owns the code. They can place restrictions on how it is used by including legally source binding conditions in an open source software license. Some open source developers believe that if an open licensing source component is used to develop a new system, then that system should also be open source. Others are willing to allow their code to be used without this restriction. The developed systems may be proprietary and sold as closed source systems. License models The GNU General Public The GNU Lesser General The Berkley Standard License (GPL) Public License (LGPL) Distribution (BSD) License. if you use open source you can write you are not obliged to software that is licensed components that link to re-publish any changes under the GPL license, open source code or modifications made then you must make without having to to open source code. that software open publish the source of You can include the code source. these components. in proprietary systems that are sold. Key points ▪ When developing software, you should always consider the possibility of reusing existing software, either as components, services or complete systems. ▪ Configuration management is the process of managing changes to an evolving software system. It is essential when a team of people are cooperating to develop software. ▪ Most software development is host-target development. You use an IDE on a host machine to develop the software, which is transferred to a target machine for execution. ▪ Open source development involves making the source code of a system publicly available. This means that many people can propose changes and improvements to the software. 45