The document discusses the design and implementation process in software engineering. It covers topics like using the Unified Modeling Language (UML) for object-oriented design, design patterns, and implementation issues. It then discusses the design process, including identifying system contexts and interactions, architectural design, identifying object classes, and creating design models like subsystem, sequence, and state diagrams. The example of designing a weather station system is used to illustrate these design concepts and activities.
System modeling involves creating abstract models of a system from different perspectives, such as context, interactions, structure, and behavior. These models help analysts understand system functionality and communicate with customers. Context models show a system's external environment and relationships. Interaction models, such as use case and sequence diagrams, depict how users and systems interact. Structural models, like class diagrams, represent a system's internal organization. Behavioral models, including activity and state diagrams, illustrate a system's dynamic response to events or data. Model-driven engineering aims to generate implementation from system models.
The document discusses requirements engineering for software systems. It covers topics like functional and non-functional requirements, the software requirements document, requirements specification processes, and requirements elicitation, analysis, and management. Requirements engineering is the process of establishing customer needs for a system and constraints for its development and operation. Requirements can range from abstract to highly detailed and serve different purposes depending on their intended use.
This document provides an overview of topics covered in Chapter 7 on software design and implementation, including object-oriented design using UML, design patterns, implementation issues, and open source development. It discusses the design and implementation process, build vs buy approaches, object-oriented design processes involving system models, and key activities like defining system context, identifying objects and interfaces. Specific examples are provided for designing a wilderness weather station system.
The document discusses various types of software testing:
- Development testing includes unit, component, and system testing to discover defects.
- Release testing is done by a separate team to validate the software meets requirements before release.
- User testing involves potential users testing the system in their own environment.
The goals of testing are validation, to ensure requirements are met, and defect testing to discover faults. Automated unit testing and test-driven development help improve test coverage and regression testing.
Architectural design involves identifying major system components and their communications. Architectural views provide different perspectives of the system, such as conceptual, logical, process, and development views. Common architectural patterns include model-view-controller, layered, client-server, and pipe-and-filter architectures. Application architectures define common structures for transaction processing, information, and language processing systems.
This document discusses software processes and models. It covers the following key points:
1. Software processes involve activities like specification, design, implementation, validation and evolution to develop software systems. Common process models include waterfall, incremental development and reuse-oriented development.
2. Processes need to cope with inevitable changes. This can involve prototyping to avoid rework or using incremental development and delivery to more easily accommodate changes.
3. The Rational Unified Process is a modern process model with phases for inception, elaboration, construction and transition. It advocates iterative development and managing requirements and quality.
Ian Sommerville, Software Engineering, 9th EditionCh 8Mohammed Romi
The document discusses different types of software testing including unit testing, component testing, and system testing. Unit testing involves testing individual program components in isolation through techniques like partition testing and guideline-based testing. Component testing focuses on testing interactions between components through their interfaces. System testing integrates components to test their interactions and check for emergent behaviors that are not explicitly defined. The document also covers test-driven development, which involves writing tests before code in incremental cycles.
This document provides an introduction to software engineering topics including:
1. What software engineering is, its importance, and the software development lifecycle activities it encompasses.
2. The many different types of software systems that exist and how software engineering approaches vary depending on the application.
3. Key fundamentals of software engineering that apply universally, including managing development processes, dependability, and reusing existing software components.
System modeling involves creating abstract models of a system from different perspectives, such as context, interactions, structure, and behavior. These models help analysts understand system functionality and communicate with customers. Context models show a system's external environment and relationships. Interaction models, such as use case and sequence diagrams, depict how users and systems interact. Structural models, like class diagrams, represent a system's internal organization. Behavioral models, including activity and state diagrams, illustrate a system's dynamic response to events or data. Model-driven engineering aims to generate implementation from system models.
The document discusses requirements engineering for software systems. It covers topics like functional and non-functional requirements, the software requirements document, requirements specification processes, and requirements elicitation, analysis, and management. Requirements engineering is the process of establishing customer needs for a system and constraints for its development and operation. Requirements can range from abstract to highly detailed and serve different purposes depending on their intended use.
This document provides an overview of topics covered in Chapter 7 on software design and implementation, including object-oriented design using UML, design patterns, implementation issues, and open source development. It discusses the design and implementation process, build vs buy approaches, object-oriented design processes involving system models, and key activities like defining system context, identifying objects and interfaces. Specific examples are provided for designing a wilderness weather station system.
The document discusses various types of software testing:
- Development testing includes unit, component, and system testing to discover defects.
- Release testing is done by a separate team to validate the software meets requirements before release.
- User testing involves potential users testing the system in their own environment.
The goals of testing are validation, to ensure requirements are met, and defect testing to discover faults. Automated unit testing and test-driven development help improve test coverage and regression testing.
Architectural design involves identifying major system components and their communications. Architectural views provide different perspectives of the system, such as conceptual, logical, process, and development views. Common architectural patterns include model-view-controller, layered, client-server, and pipe-and-filter architectures. Application architectures define common structures for transaction processing, information, and language processing systems.
This document discusses software processes and models. It covers the following key points:
1. Software processes involve activities like specification, design, implementation, validation and evolution to develop software systems. Common process models include waterfall, incremental development and reuse-oriented development.
2. Processes need to cope with inevitable changes. This can involve prototyping to avoid rework or using incremental development and delivery to more easily accommodate changes.
3. The Rational Unified Process is a modern process model with phases for inception, elaboration, construction and transition. It advocates iterative development and managing requirements and quality.
Ian Sommerville, Software Engineering, 9th EditionCh 8Mohammed Romi
The document discusses different types of software testing including unit testing, component testing, and system testing. Unit testing involves testing individual program components in isolation through techniques like partition testing and guideline-based testing. Component testing focuses on testing interactions between components through their interfaces. System testing integrates components to test their interactions and check for emergent behaviors that are not explicitly defined. The document also covers test-driven development, which involves writing tests before code in incremental cycles.
This document provides an introduction to software engineering topics including:
1. What software engineering is, its importance, and the software development lifecycle activities it encompasses.
2. The many different types of software systems that exist and how software engineering approaches vary depending on the application.
3. Key fundamentals of software engineering that apply universally, including managing development processes, dependability, and reusing existing software components.
This document discusses agile software development methods. It covers topics like agile principles, extreme programming practices including test-driven development and pair programming. It also discusses scaling agile methods to larger projects using scrum, with sprints and daily stand-up meetings. Some challenges of applying agile to large, long-term projects with distributed teams are also outlined.
Ian Sommerville, Software Engineering, 9th Edition Ch 4Mohammed Romi
The document discusses requirements engineering and summarizes key topics covered in Chapter 4, including:
- The importance of specifying both functional and non-functional requirements. Non-functional requirements place constraints on system functions and development process.
- The software requirements specification document defines what the system must do and includes both user and system requirements. It should not describe how the system will be implemented.
- Requirements engineering involves eliciting, analyzing, validating and managing requirements throughout the development lifecycle. Precise, complete and consistent requirements are important for development.
This document discusses sociotechnical systems and systems engineering. It defines sociotechnical systems as systems that include both technical systems (e.g. hardware and software) as well as operational processes and people. Sociotechnical systems have emergent properties that depend on the interactions between system components. They are also non-deterministic since human behavior introduces unpredictability. Developing sociotechnical systems requires an interdisciplinary approach involving areas like software engineering, organizational design, and human factors.
This document provides an overview of key topics from Chapter 11 on security and dependability, including:
- The principal dependability properties of availability, reliability, safety, and security.
- Dependability covers attributes like maintainability, repairability, survivability, and error tolerance.
- Dependability is important because system failures can have widespread effects and undependable systems may be rejected.
- Dependability is achieved through techniques like fault avoidance, detection and removal, and building in fault tolerance.
This document discusses socio-technical systems and their engineering. It defines socio-technical systems as systems that include both technical and human/organizational elements. Key points include: emergent properties depend on relationships between system components; reliability depends on interactions between hardware, software, and human factors; systems engineering involves specifying, designing, and maintaining complex systems; organizational context and processes affect system design and use; legacy systems are critical but costly to maintain.
This document discusses quality management in software development. It covers topics like software quality, standards, reviews/inspections, quality management in agile development, and software measurement. Regarding quality management, the key points are that it provides an independent check on the development process, ensures deliverables meet goals/standards, and the quality team should be independent from developers. Quality plans set quality goals and define assessment processes and standards to apply. Quality management is important for large, complex systems and focuses on establishing a quality culture for smaller systems.
Software evolution involves making ongoing changes to software systems to address new requirements, fix errors, and improve performance. There are several approaches to managing software evolution, including maintenance, reengineering, refactoring, and legacy system management. Key considerations for legacy systems include assessing their business value and quality to determine whether they should be replaced, transformed, or maintained.
The chapter discusses software evolution, including that software change is inevitable due to new requirements, business changes, and errors. It describes how organizations must manage change to existing software systems, which represent huge investments. The majority of large software budgets are spent evolving, rather than developing new, systems. The chapter outlines the software evolution process and different approaches to evolving systems, including addressing urgent changes. It also discusses challenges with legacy systems and their management.
Ian Sommerville, Software Engineering, 9th Edition Ch2Mohammed Romi
This document summarizes key aspects of software processes and models. It discusses the basic activities involved in software development like specification, design, implementation, validation and evolution. It describes process models like waterfall, incremental development and reuse-oriented processes. The waterfall model involves sequential phases while incremental development interleaves activities. Validation includes testing stages from unit to system level. The document also covers designing for change and evolution.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Rapid and iterative development is emphasized to quickly adapt to changing requirements. Methods like Extreme Programming (XP) use practices like user stories, test-driven development, pair programming, and continuous refactoring to develop working software in short iterations.
The document discusses chapter 7 of a software engineering textbook which covers design and implementation. It begins by outlining the topics to be covered, including object-oriented design using UML, design patterns, and implementation issues. It then discusses the software design and implementation process, considerations around building versus buying systems, and approaches to object-oriented design using UML.
This document provides an overview of software reuse techniques discussed in Chapter 16, including:
1) Application frameworks which provide reusable skeleton designs through abstract and concrete classes;
2) Software product lines which allow generic applications to be adapted through configuration, component selection, and specialization for different requirements;
3) COTS (commercial off-the-shelf) product reuse where pre-existing software systems can be customized through deployment configuration without changing source code.
This chapter discusses system modeling and different types of models used, including:
- Context models which illustrate the operational context of a system.
- Interaction models which model interactions between a system and its environment.
- Structural models which display the organization of a system's components.
- Behavioral models which model a system's dynamic behavior in response to events or data.
- Model-driven engineering is discussed as an approach where models rather than code are the primary outputs.
Ian Sommerville, Software Engineering, 9th Edition Ch1Mohammed Romi
The document provides an introduction to software engineering concepts. It discusses what software engineering is, the importance of ethics in software development, and introduces three case studies that will be used as examples throughout the book. Specifically:
[1] It defines software engineering as an engineering discipline concerned with all aspects of software production. Professional and ethical practices are important.
[2] It discusses software engineering ethics and introduces the ACM/IEEE code of ethics for software engineers.
[3] It provides an overview of three case studies that will be referenced in later chapters: an insulin pump system, a patient management system, and a weather station system.
The document discusses different types of software testing:
- Development testing includes unit, component, and system testing to discover bugs during development. Unit testing involves testing individual program units in isolation.
- Release testing is done by a separate team to test a complete version before public release.
- User testing involves potential users testing the system in their own environment.
The goals of testing are to demonstrate that software meets requirements and to discover incorrect or undesirable behavior to find defects. Different testing types include validation testing to check correct functionality and defect testing to uncover bugs. Both inspections and testing are important and complementary methods in software verification.
This document discusses configuration management (CM) and version control. It covers topics like version management, system building, change management, and release management. CM is important for software development as it allows tracking of changing software systems and components. Version control systems are key to CM, identifying and storing different versions. They support independent development through a shared repository and private workspaces. Developers check components in and out to make changes separately without interfering with each other.
This document discusses key topics in systems engineering, including:
1) Systems engineering involves procuring, designing, implementing, and maintaining sociotechnical systems that include both technical and human elements.
2) Software systems are part of broader sociotechnical systems and software engineers must consider human, social, and organizational factors.
3) Sociotechnical systems have emergent properties that depend on the interactions between system components and cannot be understood by examining the components individually.
The document discusses architectural design, including:
- Architectural design determines how a software system is organized and structured. It identifies the main components and relationships.
- Architectural views show different perspectives of a system, such as logical, process, development, and physical views. Common patterns like model-view-controller and layered architectures are also covered.
- Architectural decisions impact system characteristics like performance, security, and maintainability. Common application architectures are also discussed.
This document discusses software reuse and application frameworks. It covers the benefits of software reuse like accelerated development and increased dependability. Application frameworks provide a reusable architecture for related applications and are implemented by adding components and instantiating abstract classes. Web application frameworks in particular use the model-view-controller pattern to support dynamic websites as a front-end for web applications.
This document discusses software processes and process models. It covers topics such as the waterfall model, incremental development, integration and configuration, process activities including specification, design, implementation, validation and evolution. It also discusses coping with change through techniques like prototyping and incremental delivery. The key aspects of software process models, activities, and improvement are summarized.
1. The document discusses different types of switched networks including circuit-switched, datagram, and virtual circuit networks. It describes the key characteristics of each type.
2. Circuit switching uses dedicated paths between nodes and has three phases: setup, data transfer, and teardown. Datagram networks treat each packet independently and route using destination addresses in packet headers. Virtual circuit networks combine aspects of circuit and datagram switching.
3. The structures of switches used in different networks are examined, including crossbar switches for circuit switching and various designs for packet switches like Banyan networks.
The document discusses problem-solving agents and uninformed search strategies. It introduces problem-solving agents as goal-based agents that try to find sequences of actions that lead to desirable goal states. It then discusses formulating problems by defining the initial state, actions, goal test, and cost function. Several examples of problems are provided, like the Romania tour problem. Uninformed search strategies like breadth-first search, uniform-cost search, and depth-first search are then introduced as strategies that use only the problem definition, not heuristics. Breadth-first search expands nodes in order of shallowest depth first, while depth-first search expands the deepest node in the frontier first.
This document discusses agile software development methods. It covers topics like agile principles, extreme programming practices including test-driven development and pair programming. It also discusses scaling agile methods to larger projects using scrum, with sprints and daily stand-up meetings. Some challenges of applying agile to large, long-term projects with distributed teams are also outlined.
Ian Sommerville, Software Engineering, 9th Edition Ch 4Mohammed Romi
The document discusses requirements engineering and summarizes key topics covered in Chapter 4, including:
- The importance of specifying both functional and non-functional requirements. Non-functional requirements place constraints on system functions and development process.
- The software requirements specification document defines what the system must do and includes both user and system requirements. It should not describe how the system will be implemented.
- Requirements engineering involves eliciting, analyzing, validating and managing requirements throughout the development lifecycle. Precise, complete and consistent requirements are important for development.
This document discusses sociotechnical systems and systems engineering. It defines sociotechnical systems as systems that include both technical systems (e.g. hardware and software) as well as operational processes and people. Sociotechnical systems have emergent properties that depend on the interactions between system components. They are also non-deterministic since human behavior introduces unpredictability. Developing sociotechnical systems requires an interdisciplinary approach involving areas like software engineering, organizational design, and human factors.
This document provides an overview of key topics from Chapter 11 on security and dependability, including:
- The principal dependability properties of availability, reliability, safety, and security.
- Dependability covers attributes like maintainability, repairability, survivability, and error tolerance.
- Dependability is important because system failures can have widespread effects and undependable systems may be rejected.
- Dependability is achieved through techniques like fault avoidance, detection and removal, and building in fault tolerance.
This document discusses socio-technical systems and their engineering. It defines socio-technical systems as systems that include both technical and human/organizational elements. Key points include: emergent properties depend on relationships between system components; reliability depends on interactions between hardware, software, and human factors; systems engineering involves specifying, designing, and maintaining complex systems; organizational context and processes affect system design and use; legacy systems are critical but costly to maintain.
This document discusses quality management in software development. It covers topics like software quality, standards, reviews/inspections, quality management in agile development, and software measurement. Regarding quality management, the key points are that it provides an independent check on the development process, ensures deliverables meet goals/standards, and the quality team should be independent from developers. Quality plans set quality goals and define assessment processes and standards to apply. Quality management is important for large, complex systems and focuses on establishing a quality culture for smaller systems.
Software evolution involves making ongoing changes to software systems to address new requirements, fix errors, and improve performance. There are several approaches to managing software evolution, including maintenance, reengineering, refactoring, and legacy system management. Key considerations for legacy systems include assessing their business value and quality to determine whether they should be replaced, transformed, or maintained.
The chapter discusses software evolution, including that software change is inevitable due to new requirements, business changes, and errors. It describes how organizations must manage change to existing software systems, which represent huge investments. The majority of large software budgets are spent evolving, rather than developing new, systems. The chapter outlines the software evolution process and different approaches to evolving systems, including addressing urgent changes. It also discusses challenges with legacy systems and their management.
Ian Sommerville, Software Engineering, 9th Edition Ch2Mohammed Romi
This document summarizes key aspects of software processes and models. It discusses the basic activities involved in software development like specification, design, implementation, validation and evolution. It describes process models like waterfall, incremental development and reuse-oriented processes. The waterfall model involves sequential phases while incremental development interleaves activities. Validation includes testing stages from unit to system level. The document also covers designing for change and evolution.
The document discusses agile software development methods. It covers topics like agile methods, techniques, and project management. Rapid and iterative development is emphasized to quickly adapt to changing requirements. Methods like Extreme Programming (XP) use practices like user stories, test-driven development, pair programming, and continuous refactoring to develop working software in short iterations.
The document discusses chapter 7 of a software engineering textbook which covers design and implementation. It begins by outlining the topics to be covered, including object-oriented design using UML, design patterns, and implementation issues. It then discusses the software design and implementation process, considerations around building versus buying systems, and approaches to object-oriented design using UML.
This document provides an overview of software reuse techniques discussed in Chapter 16, including:
1) Application frameworks which provide reusable skeleton designs through abstract and concrete classes;
2) Software product lines which allow generic applications to be adapted through configuration, component selection, and specialization for different requirements;
3) COTS (commercial off-the-shelf) product reuse where pre-existing software systems can be customized through deployment configuration without changing source code.
This chapter discusses system modeling and different types of models used, including:
- Context models which illustrate the operational context of a system.
- Interaction models which model interactions between a system and its environment.
- Structural models which display the organization of a system's components.
- Behavioral models which model a system's dynamic behavior in response to events or data.
- Model-driven engineering is discussed as an approach where models rather than code are the primary outputs.
Ian Sommerville, Software Engineering, 9th Edition Ch1Mohammed Romi
The document provides an introduction to software engineering concepts. It discusses what software engineering is, the importance of ethics in software development, and introduces three case studies that will be used as examples throughout the book. Specifically:
[1] It defines software engineering as an engineering discipline concerned with all aspects of software production. Professional and ethical practices are important.
[2] It discusses software engineering ethics and introduces the ACM/IEEE code of ethics for software engineers.
[3] It provides an overview of three case studies that will be referenced in later chapters: an insulin pump system, a patient management system, and a weather station system.
The document discusses different types of software testing:
- Development testing includes unit, component, and system testing to discover bugs during development. Unit testing involves testing individual program units in isolation.
- Release testing is done by a separate team to test a complete version before public release.
- User testing involves potential users testing the system in their own environment.
The goals of testing are to demonstrate that software meets requirements and to discover incorrect or undesirable behavior to find defects. Different testing types include validation testing to check correct functionality and defect testing to uncover bugs. Both inspections and testing are important and complementary methods in software verification.
This document discusses configuration management (CM) and version control. It covers topics like version management, system building, change management, and release management. CM is important for software development as it allows tracking of changing software systems and components. Version control systems are key to CM, identifying and storing different versions. They support independent development through a shared repository and private workspaces. Developers check components in and out to make changes separately without interfering with each other.
This document discusses key topics in systems engineering, including:
1) Systems engineering involves procuring, designing, implementing, and maintaining sociotechnical systems that include both technical and human elements.
2) Software systems are part of broader sociotechnical systems and software engineers must consider human, social, and organizational factors.
3) Sociotechnical systems have emergent properties that depend on the interactions between system components and cannot be understood by examining the components individually.
The document discusses architectural design, including:
- Architectural design determines how a software system is organized and structured. It identifies the main components and relationships.
- Architectural views show different perspectives of a system, such as logical, process, development, and physical views. Common patterns like model-view-controller and layered architectures are also covered.
- Architectural decisions impact system characteristics like performance, security, and maintainability. Common application architectures are also discussed.
This document discusses software reuse and application frameworks. It covers the benefits of software reuse like accelerated development and increased dependability. Application frameworks provide a reusable architecture for related applications and are implemented by adding components and instantiating abstract classes. Web application frameworks in particular use the model-view-controller pattern to support dynamic websites as a front-end for web applications.
This document discusses software processes and process models. It covers topics such as the waterfall model, incremental development, integration and configuration, process activities including specification, design, implementation, validation and evolution. It also discusses coping with change through techniques like prototyping and incremental delivery. The key aspects of software process models, activities, and improvement are summarized.
1. The document discusses different types of switched networks including circuit-switched, datagram, and virtual circuit networks. It describes the key characteristics of each type.
2. Circuit switching uses dedicated paths between nodes and has three phases: setup, data transfer, and teardown. Datagram networks treat each packet independently and route using destination addresses in packet headers. Virtual circuit networks combine aspects of circuit and datagram switching.
3. The structures of switches used in different networks are examined, including crossbar switches for circuit switching and various designs for packet switches like Banyan networks.
The document discusses problem-solving agents and uninformed search strategies. It introduces problem-solving agents as goal-based agents that try to find sequences of actions that lead to desirable goal states. It then discusses formulating problems by defining the initial state, actions, goal test, and cost function. Several examples of problems are provided, like the Romania tour problem. Uninformed search strategies like breadth-first search, uniform-cost search, and depth-first search are then introduced as strategies that use only the problem definition, not heuristics. Breadth-first search expands nodes in order of shallowest depth first, while depth-first search expands the deepest node in the frontier first.
This document summarizes key aspects of software engineering processes and models. It discusses the fundamental activities of software specification, development, validation, and evolution. It describes plan-driven and incremental process models like the waterfall model and incremental development. It also covers topics like software prototyping, reuse-oriented processes, and coping with changing requirements through change avoidance and change tolerance strategies.
This document discusses the history and foundations of artificial intelligence. It covers early developments in the 1940s-1950s that led to the birth of AI as a field at the 1956 Dartmouth conference. It describes successes and challenges in the 1960s-1970s, the rise of knowledge-based systems and expert systems in the 1970s, and AI becoming an industry in the 1980s. The return of neural networks in the 1980s-1990s is also summarized. The document outlines different approaches to defining and pursuing AI, including systems that think like humans, think rationally, act like humans, and act rationally. It lists philosophy, mathematics, neuroscience, and other disciplines as foundations of AI.
The document discusses requirements engineering and summarizes key topics covered in Chapter 4, including:
- Functional and non-functional requirements and how they differ
- The structure and purpose of a software requirements specification document
- Methods for specifying requirements such as using natural language, structured specifications, and tables
- Challenges in writing requirements clearly and avoiding ambiguity or mixing of requirement types
This document discusses different types of intelligent agents and their environments. It defines rational agents as those that do the right thing given their percepts and goals. The document outlines different types of agent architectures, including simple reflex agents, model-based reflex agents, goal-based agents, and utility-based agents. It also discusses properties of task environments and examples of different environments. Learning agents are introduced as agents that can improve their performance over time through experience.
The document discusses architectural design in software engineering. It covers topics like architectural design decisions, views, patterns, and application architectures. Architectural design involves identifying major system components and their communications in order to represent the link between specification and design processes. Common architectural patterns discussed include model-view-controller, layered architectures, repositories, client-server, pipes and filters. The document also provides examples of architectures for different types of applications like transaction processing systems and information systems.
This document discusses the design and implementation chapter of a lecture. It covers topics like using UML for object-oriented design, design patterns, and implementation issues. It then discusses the weather station case study used to illustrate the design process, including defining system context, use cases, architectural design, identifying object classes, design models, and interface specification.
This document discusses design and implementation topics covered in Chapter 7, including object-oriented design using UML, design patterns, implementation issues, and open source development. It provides an example of designing a weather station system using various UML diagrams to illustrate the object-oriented design process. Key activities covered are identifying objects, developing design models, and specifying object interfaces. Implementation issues discussed include reuse, configuration management, and host-target development.
This document discusses topics related to software design and implementation, including object-oriented design using UML, design patterns, and implementation issues. It provides details on the design and implementation process for a weather station system, including identifying system objects and classes, developing design models like sequence and state diagrams, and specifying interfaces. Design patterns are also introduced as a way to reuse solutions to common problems.
This chapter discusses software design and implementation. It covers object-oriented design using UML, design patterns, implementation issues, and open source development. The key stages of design and implementation are discussed, including defining requirements, designing architecture, identifying objects, developing design models, and specifying interfaces. Common design models like use case diagrams, sequence diagrams, and state diagrams are presented. Design patterns like Observer are explained. Implementation issues around reuse, configuration management, and host-target development are also covered.
The document provides an overview of the topics covered in a systems analysis and design course, including software used, information system components, analyzing the business case, managing projects, requirements modeling, data modeling, object modeling, development strategies, output and interface design, data design, and system architecture. Key concepts discussed include SWOT analysis, business cases, feasibility studies, project management techniques, UML, data flow diagrams, use cases, object-oriented analysis, cost-benefit analysis methods, user interface design, data structure, normalization, and entity relationship diagrams.
This document discusses design and implementation in software engineering. It covers object-oriented design using the Unified Modeling Language (UML), implementation issues such as reuse and configuration management, and open source development. Specifically, it provides examples and diagrams for the design of a weather station system, including use cases, classes, interfaces, and state diagrams. It emphasizes that design is an iterative process involving modeling the system context, architecture, objects, and their interactions.
The document summarizes key aspects of architectural design for software systems. It defines software architecture as the structure of system components and relationships between them. Architecture is important for analyzing design effectiveness, considering alternatives, and managing risks. Key architectural styles described include data-centered, data flow, call and return, object-oriented, and layered. The document also discusses defining architectural context diagrams, archetypes, and components to design system architecture.
Three types of systems that are used as case studies are embedded systems to control medical devices, information systems like medical records systems, and sensor-based data collection systems like wilderness weather stations. Software engineering techniques include prototypes, reuse-oriented processes, and testing processes. Architectural design is a critical link between overall system design and requirements and involves determining how a system should be organized at a high level.
Object-oriented design involves representing a software system as interacting objects that manage their own state and operations. The key activities in object-oriented design are object identification, developing design models like class diagrams and sequence diagrams, and specifying object interfaces. Design evolution is simplified since changes made to objects do not unpredictably affect other objects due to encapsulation.
This document summarizes four architectural patterns for context-aware systems: WCAM, Event-Control-Action, Action, and architectural pattern for context-based navigation. It discusses examples, problems addressed, solutions, structures, and benefits of each pattern. The patterns are examined to determine which can best overcome complexity and be more extensible for context-aware systems.
Software Engineering Important Short Question for ExamsMuhammadTalha436
The document discusses various topics related to software engineering including:
1. The software development life cycle (SDLC) and its phases like requirements, design, implementation, testing, etc.
2. The waterfall model and its phases from modeling to maintenance.
3. The purpose of feasibility studies, data flow diagrams, and entity relationship diagrams.
4. Different types of testing done during the testing phase like unit, integration, system, black box and white box testing.
The document provides an overview of a 7-step process for building an information system. The 7 steps are: 1) Identify and list stakeholders, 2) Identify and list actors, 3) Identify and list use cases, 4) Identify and list scenarios, 5) Identify and list steps, 6) Identify and list classes/objects, and 7) Manage work products. It describes each step in the process, including defining stakeholders, actors, use cases, scenarios, and mapping analysis to design. The process emphasizes discovery, iteration, and developing a shared understanding between stakeholders.
The document discusses various topics related to software engineering including:
1) How early days of software development have affected modern practices.
2) Definitions of software engineering from different sources.
3) The stages of software design including problem analysis, solution identification, and abstraction description.
4) Object-oriented design principles like information hiding, independent objects, and service-based communication.
The document discusses object-oriented design and its role in software development. It describes how design builds upon analysis to provide implementation details. Key aspects of object-oriented design include defining a multilayered architecture, specifying subsystems and components, describing classes and objects, and defining communication mechanisms. The input to design comes from artifacts created in analysis like use cases and class models. The output of design serves as a blueprint to guide construction.
The document discusses software architecture, including:
1. Definitions of software architecture and how it is influenced.
2. Common sections of a software architecture document such as introduction, views, goals and quality.
3. Architectural patterns and views including model-view-controller, layered patterns, and the "4+1" views of logical, process, deployment, and implementation.
4. How architecture addresses concerns like complexity, communication, and early decisions.
This document discusses architectural design and provides examples of architectural views, patterns, and decisions. It covers topics such as the 4+1 view model, layered architecture pattern, model-view-controller pattern, and how architectural decisions impact system characteristics such as performance, security, and maintainability. Key points are that architectural design represents a link between specification and design, and that views, patterns, and decisions are important aspects of documenting and designing software architectures.
CS8592 Object Oriented Analysis & Design - UNIT V pkaviya
This document discusses object-oriented methodologies for software development. It describes the Rumbaugh, Booch, and Jacobson methodologies which were influential in the development of the Unified Modeling Language. The Rumbaugh Object Modeling Technique focuses on object models, dynamic models, and functional models. The Booch methodology emphasizes class diagrams, state diagrams, and other modeling tools. Jacobson's methodologies like Objectory emphasize use case modeling and traceability between phases.
The document provides an overview of architectural design topics including:
- Architectural design decisions involve choices around application architecture, distribution, styles, and documentation.
- Architectural views provide different perspectives of a system's modules, runtime processes, and distribution.
- Architectural patterns like MVC and layered architectures capture proven design solutions.
- Application architectures provide templates for transaction processing, language processing, and information systems.
This document provides an overview of Internet Protocol version 4 (IPv4) and version 6 (IPv6). It discusses the need for a network layer in an internetwork, IPv4 addressing and packet format, fragmentation, and IPv6 advantages over IPv4 such as a larger address space and better header format. Key aspects of IPv4 include the header length field, total length field, identification field for fragmentation, flags, fragmentation offset, checksum, and protocol field. IPv6 improvements include a fixed header length, larger addresses, priority and flow label fields, and extension headers.
The document provides an overview of software testing. It discusses different types of testing like development testing, test-driven development, release testing, and user testing. It describes unit testing, component testing, system testing, and the goals of validation and defect testing. It also covers topics like the testing process, automated testing, equivalence partitioning, regression testing, and test-driven development.
The document discusses IPv4 addressing and logical addressing in computer networks. It covers the following key points:
- IPv4 addresses are 32-bit addresses that uniquely identify devices connected to the internet. The total address space is 232 or approximately 4.3 billion addresses.
- Addresses can be written in binary or dotted-decimal notation. IPv4 addresses are divided into classes based on the first bits of the address.
- Classful addressing wasted a large portion of addresses. It was replaced by classless addressing which allocates address blocks of variable sizes.
- In classless addressing, a block of addresses is defined as the network address, subnet mask, and number of hosts. The first and last
This document provides an overview of multiple access protocols for shared wireless media. It discusses random access protocols like ALOHA, slotted ALOHA, CSMA, CSMA/CD, and CSMA/CA. ALOHA protocols allow stations to transmit whenever they have data, which can cause collisions. Slotted ALOHA and CSMA protocols reduce collisions by coordinating transmissions. The document also covers controlled access protocols like reservation, polling, and token passing that establish transmission rights to avoid collisions. It includes frame formats, throughput calculations, and flow diagrams to illustrate how each protocol manages access to the shared channel.
The document discusses different techniques for weighting terms in the vector space model for information retrieval, including:
- Sublinear tf scaling using the logarithm of term frequency
- Tf-idf weighting
- Maximum tf normalization to mitigate higher weights for longer documents
It also discusses evaluating information retrieval systems using test collections with queries, relevant documents, and metrics like precision and recall. Standard test collections include Cranfield, TREC, and CLEF.
The document summarizes the vector space model for scoring and ranking documents in response to a query in an information retrieval system. It explains that in this model, documents and queries are represented as vectors in a common vector space. The similarity between a document and query vector is measured by calculating the cosine similarity of the two vectors, which scores and ranks documents based on the terms they share with the query. It also describes how the vector space model allows retrieving the top K documents by relevance rather than using a Boolean retrieval model.
The document discusses processing Boolean queries in an information retrieval system using an inverted index. It describes the steps to process a simple conjunctive query by locating terms in the dictionary, retrieving their postings lists, and intersecting the lists. More complex queries involving OR and NOT operators are also processed in a similar way. The document also discusses optimizing query processing by considering the order of accessing postings lists.
This document discusses building an inverted index to efficiently support information retrieval on large document collections. It describes tokenizing documents, building a dictionary of normalized terms, and creating postings lists that map each term to the documents it appears in. Inverted indexes allow skipping linear scanning and support flexible queries by indexing term locations. The document also covers calculating precision and recall to measure system effectiveness.
This document provides an overview of an information retrieval course. The course will cover topics related to information retrieval models, techniques, and systems. Students will complete exams, assignments, and a major project to build a search engine using both text-based and semantic retrieval techniques. The document defines key concepts in information retrieval and discusses different types of information retrieval systems and techniques.
The document discusses the structure of OpenGL programs, including initializing shaders and setting up vertex arrays and buffer objects. Most OpenGL programs have a main function that specifies callbacks, opens a window, and enters an event loop. Initialization functions set up viewing parameters, shaders, and vertex attributes in buffer objects. A display callback renders the vertex data by drawing arrays. The document also covers topics like coordinate systems, the OpenGL camera model, and orthographic viewing.
The document discusses graphics programming and OpenGL. It introduces OpenGL, describing it as a hardware-independent interface consisting of over 700 commands. It outlines the OpenGL API, including primitive functions, attribute functions, and viewing functions. It also covers OpenGL primitives like points, lines, and polygons, as well as attributes like color. It explains orthographic and two-dimensional viewing in OpenGL.
Ian Sommerville, Software Engineering, 9th Edition Ch 23Mohammed Romi
The document discusses project planning for software development. It covers topics like software pricing, plan-driven development, project scheduling, and estimation techniques. Project planning involves breaking down work, anticipating problems, and preparing tentative solutions. A project plan is created at the start of a project to communicate the work breakdown and help assess progress. Planning is done at various stages including proposals, project startup, and periodically throughout the project. Factors like requirements, costs, and risks are considered in planning.
CapTechTalks Webinar Slides June 2024 Donovan Wright.pptxCapitolTechU
Slides from a Capitol Technology University webinar held June 20, 2024. The webinar featured Dr. Donovan Wright, presenting on the Department of Defense Digital Transformation.
Cross-Cultural Leadership and CommunicationMattVassar1
Business is done in many different ways across the world. How you connect with colleagues and communicate feedback constructively differs tremendously depending on where a person comes from. Drawing on the culture map from the cultural anthropologist, Erin Meyer, this class discusses how best to manage effectively across the invisible lines of culture.
How to Create User Notification in Odoo 17Celine George
This slide will represent how to create user notification in Odoo 17. Odoo allows us to create and send custom notifications on some events or actions. We have different types of notification such as sticky notification, rainbow man effect, alert and raise exception warning or validation.
How to Download & Install Module From the Odoo App Store in Odoo 17Celine George
Custom modules offer the flexibility to extend Odoo's capabilities, address unique requirements, and optimize workflows to align seamlessly with your organization's processes. By leveraging custom modules, businesses can unlock greater efficiency, productivity, and innovation, empowering them to stay competitive in today's dynamic market landscape. In this tutorial, we'll guide you step by step on how to easily download and install modules from the Odoo App Store.
Get Success with the Latest UiPath UIPATH-ADPV1 Exam Dumps (V11.02) 2024yarusun
Are you worried about your preparation for the UiPath Power Platform Functional Consultant Certification Exam? You can come to DumpsBase to download the latest UiPath UIPATH-ADPV1 exam dumps (V11.02) to evaluate your preparation for the UIPATH-ADPV1 exam with the PDF format and testing engine software. The latest UiPath UIPATH-ADPV1 exam questions and answers go over every subject on the exam so you can easily understand them. You won't need to worry about passing the UIPATH-ADPV1 exam if you master all of these UiPath UIPATH-ADPV1 dumps (V11.02) of DumpsBase. #UIPATH-ADPV1 Dumps #UIPATH-ADPV1 #UIPATH-ADPV1 Exam Dumps
Artificial Intelligence (AI) has revolutionized the creation of images and videos, enabling the generation of highly realistic and imaginative visual content. Utilizing advanced techniques like Generative Adversarial Networks (GANs) and neural style transfer, AI can transform simple sketches into detailed artwork or blend various styles into unique visual masterpieces. GANs, in particular, function by pitting two neural networks against each other, resulting in the production of remarkably lifelike images. AI's ability to analyze and learn from vast datasets allows it to create visuals that not only mimic human creativity but also push the boundaries of artistic expression, making it a powerful tool in digital media and entertainment industries.
1. Chapter 7 – Design and Implementation
Lecture 1
1Chapter 7 Design and implementation
2. Topics covered
Object-oriented design using the UML
Design patterns
Implementation issues (not covered)
Open source development (not covered)
2Chapter 7 Design and implementation
3. 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 activities are
invariably inter-leaved.
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.
3Chapter 7 Design and implementation
4. Build or buy
In a wide range of domains, it is now possible to buy
Commercial off-the-shelf systems (COTS) that can be
adapted and tailored to the users’ requirements.
For example, if you want to implement a medical records system,
you can buy a package that is already used in hospitals. It can
be cheaper and faster to use this approach rather than
developing a system in a conventional programming language.
When you develop an application in this way, the design
process becomes concerned with how to use the
configuration features of that system to deliver the
system requirements.
4Chapter 7 Design and implementation
5. 7.1 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.
5Chapter 7 Design and implementation
6. 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.
Process illustrated here using a design for a wilderness
weather station.
6Chapter 7 Design and implementation
7. 7.1.1 System context and interactions
Understanding the relationships between the software
that is being designed and its external environment is
essential for deciding how to provide the required system
functionality and how to structure the system to
communicate with its environment.
Understanding of the context also lets you establish the
boundaries of the system. Setting the system boundaries
helps you decide what features are implemented in the
system being designed and what features are in other
associated systems.
7Chapter 7 Design and implementation
8. Context and interaction models
A system context model is a structural model that
demonstrates the other systems in the environment of
the system being developed.
An interaction model is a dynamic model that shows how
the system interacts with its environment as it is used.
8Chapter 7 Design and implementation
9. System context for the weather station
9Chapter 7 Design and implementation
11. 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
collected from the instruments in the collection period to the weather
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.
11Chapter 7 Design and implementation
12. 7.1.2 Architectural design
Once interactions between the system and its
environment have been understood, you use this
information for designing the system architecture.
You identify the major components that make up the
system and their interactions, and then may organize the
components using an architectural pattern such as a
layered or client-server model.
The weather station is composed of independent
subsystems that communicate by broadcasting
messages on a but common infrastructure. Common
architecture not discussed in ch6.
12Chapter 7 Design and implementation
13. High-level architecture of the weather station
13Chapter 7 Design and implementation
the sender of a message does not need to address the
message to a particular
subsystem.
Broadcasting architecture:
The sender of a message does not need to address the message to a particular subsystem.
15. 7.1.3 Object class identification
Identifying object classes is often a difficult part of object
oriented design.
There is no 'magic formula' for object identification. It
relies on the skill, experience
and domain knowledge of system designers.
Object identification is an iterative process. You are
unlikely to get it right first time.
15Chapter 7 Design and implementation
16. Approaches to identification
various proposals:
Use a grammatical approach based on a natural language
description of the system (used in Hood OOD method) Hierarchic
Object-Oriented Design. Objects and attributes are nouns;
operations or services are verbs
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.
In practice, you have to use several knowledge sources to discover
object classes.
16Chapter 7 Design and implementation
17. Weather station description (Example)
A weather station is a package of software controlled instruments
which collects data, performs some data processing and transmits
this data for further processing. The instruments include air and
ground thermometers, an anemometer, a wind vane, a barometer
and a rain gauge. Data is collected periodically.
When a command is issued to transmit the weather data, the
weather station processes and summarises the collected data.
The summarised data is transmitted to the mapping computer
when a request is received.
17Chapter 7 Design and implementation
18. Weather station object classes
Object class identification in the weather station system
may be based on the tangible hardware and data in the
system:
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.
18Chapter 7 Design and implementation
19. Weather station object classes
not all the objects
19Chapter 7 Design and implementation
20. At this stage in the design process, you should focus on
the objects themselves, without thinking about how
these might be implemented.
Once you have identified the objects, you then refine the
object design.
You look for common features and then
design the inheritance hierarchy for the system.
You may also add new attributes and operations to
the superclass, such as an attribute that maintains the
frequency of data collection.
Chapter 7 Design and implementation 20
21. 7.1.4 Design models
Design models show the objects and object classes and
relationships between these entities.
Static models describe the static structure of the
system in terms of object classes and relationships.
Dynamic models describe the dynamic interactions
between objects.
21Chapter 7 Design and implementation
22. Examples of design models
Subsystem models that show logical groupings of
objects into coherent subsystems.
Sequence models that show the sequence of object
interactions.
State machine models that show how individual objects
change their state in response to events.
Other models include use-case models, aggregation
models, generalisation models, etc.
22Chapter 7 Design and implementation
23. Subsystem models
Shows how the design is organised into logically related
groups of objects.
In the UML, these are shown using packages - an
encapsulation construct. This is a logical model. The
actual organisation of objects in the system may be
different.
23Chapter 7 Design and implementation
24. Sequence models
Sequence models show the sequence of object
interactions that take place
Objects are arranged horizontally across the top;
Time is represented vertically so models are read top
to bottom;
Interactions are represented by labelled arrows,
Different styles of arrow represent different types of
interaction;
A thin rectangle in an object lifeline represents the
time when the object is the controlling object in the
system.
24Chapter 7 Design and implementation
26. State diagrams
State diagrams are used to show how objects respond to
different service requests and the state transitions
triggered by these requests.
State diagrams are useful high-level models of a system
or an object’s run-time behavior.
You don’t usually need a state diagram for all of the
objects in the system. Many of the objects in a system
are relatively simple and a state model adds
unnecessary detail to the design.
26Chapter 7 Design and implementation
28. 7.1.5 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.
28Chapter 7 Design and implementation
30. Key points
Software design and implementation are inter-leaved activities. The
level of detail in the design depends on the type of system and
whether you are using a plan-driven or agile approach.
The process of object-oriented design includes activities to design
the system architecture, identify objects in the system, describe the
design using different object models and document the component
interfaces.
A range of different models may be produced during an object-
oriented design process. These include static models (class models,
generalization models, association models) and dynamic models
(sequence models, state machine models).
Component interfaces must be defined precisely so that other
objects can use them. A UML interface stereotype may be used to
define interfaces.
30Chapter 7 Design and implementation
31. Chapter 7 – Design and Implementation
Stop
Lecture 2
31Chapter 7 Design and implementation
32. Design patterns
A design pattern is a way of reusing abstract knowledge
about a problem and its solution.
A pattern is a description of the problem and the essence
of its solution.
It should be sufficiently abstract to be reused in different
settings.
Pattern descriptions usually make use of object-oriented
characteristics such as inheritance and polymorphism.
32Chapter 7 Design and implementation
33. Pattern elements
Name
A meaningful pattern identifier.
Problem description.
Solution description.
Not a concrete design but a template for a design solution that
can be instantiated in different ways.
Consequences
The results and trade-offs of applying the pattern.
33Chapter 7 Design and implementation
34. The Observer pattern
Name
Observer.
Description
Separates the display of object state from the object itself.
Problem description
Used when multiple displays of state are needed.
Solution description
See slide with UML description.
Consequences
Optimisations to enhance display performance are impractical.
34Chapter 7 Design and implementation
35. The Observer pattern (1)
Pattern
name
Observer
Description Separates the display of the state of an object from the object itself and
allows alternative displays to be provided. When the object state
changes, all displays are automatically notified and updated to reflect the
change.
Problem
description
In many situations, you have to provide multiple displays of state
information, such as a graphical display and a tabular display. Not all of
these may be known when the information is specified. All alternative
presentations should support interaction and, when the state is changed,
all displays must be updated.
This pattern may be used in all situations where more than one
display format for state information is required and where it is not
necessary for the object that maintains the state information to know
about the specific display formats used.
35Chapter 7 Design and implementation
36. The Observer pattern (2)
Pattern name Observer
Solution
description
This involves two abstract objects, Subject and Observer, and two concrete
objects, ConcreteSubject and ConcreteObject, which inherit the attributes of the
related abstract objects. The abstract objects include general operations that are
applicable in all situations. The state to be displayed is maintained in
ConcreteSubject, which inherits operations from Subject allowing it to add and
remove Observers (each observer corresponds to a display) and to issue a
notification when the state has changed.
The ConcreteObserver maintains a copy of the state of ConcreteSubject and
implements the Update() interface of Observer that allows these copies to be kept
in step. The ConcreteObserver automatically displays the state and reflects
changes whenever the state is updated.
Consequences The subject only knows the abstract Observer and does not know details of the
concrete class. Therefore there is minimal coupling between these objects.
Because of this lack of knowledge, optimizations that enhance display
performance are impractical. Changes to the subject may cause a set of linked
updates to observers to be generated, some of which may not be necessary.
36Chapter 7 Design and implementation
38. A UML model of the Observer pattern
38Chapter 7 Design and implementation
39. Design problems
To use patterns in your design, you need to recognize
that any design problem you are facing may have an
associated pattern that can be applied.
Tell several objects that the state of some other object has
changed (Observer pattern).
Tidy up the interfaces to a number of related objects that have
often been developed incrementally (Façade pattern).
Provide a standard way of accessing the elements in a
collection, irrespective of how that collection is implemented
(Iterator pattern).
Allow for the possibility of extending the functionality of an
existing class at run-time (Decorator pattern).
39Chapter 7 Design and implementation
40. Implementation issues
Focus here is not on programming, although this is
obviously important, but on other implementation issues
that are often not covered in programming texts:
Reuse Most modern software is constructed by reusing existing
components or systems. When you are developing software, you
should make as much use as possible of existing code.
Configuration management During the development process,
you have to keep track of the many different versions of each
software component in a configuration management system.
Host-target development Production software does not usually
execute on the same computer as the software development
environment. Rather, you develop it on one computer (the host
system) and execute it on a separate computer (the target
system).
40Chapter 7 Design and implementation
41. 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.
41Chapter 7 Design and implementation
42. 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.
42Chapter 7 Design and implementation
43. 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.
43Chapter 7 Design and implementation
44. 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.
See also Chapter 25.
44Chapter 7 Design and implementation
45. Configuration management activities
Version management, where support is provided to keep track
of the different versions of software components. Version
management systems include facilities to coordinate
development by several programmers.
System integration, where support is provided to help
developers define what versions of components are used to
create each version of a system. This description is then used
to build a system automatically by compiling and linking the
required components.
Problem tracking, where support is provided to allow users to
report bugs and other problems, and to allow all developers to
see who is working on these problems and when they are
fixed.
45Chapter 7 Design and implementation
46. Host-target development
Most software is developed on one computer (the host),
but runs on a separate machine (the target).
More generally, we can talk about a development
platform and an execution platform.
A platform is more than just hardware.
It includes the installed operating system plus other supporting
software such as a database management system or, for
development platforms, an interactive development environment.
Development platform usually has different installed
software than execution platform; these platforms may
have different architectures.
46Chapter 7 Design and implementation
47. 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.
47Chapter 7 Design and implementation
48. Integrated development environments (IDEs)
Software development tools are often grouped to create
an integrated development environment (IDE).
An IDE is a set of software tools that supports different
aspects of software development, within some common
framework and user interface.
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.
48Chapter 7 Design and implementation
49. Component/system deployment factors
If a component is designed for a specific hardware architecture, or
relies on some other software system, it must obviously be deployed
on a platform that provides the required hardware and software
support.
High availability systems may require components to be deployed
on more than one platform. This means that, in the event of platform
failure, an alternative implementation of the component is available.
If there is a high level of communications traffic between
components, it usually makes sense to deploy them on the same
platform or on platforms that are physically close to one other. This
reduces the delay between the time a message is sent by one
component and received by another.
49Chapter 7 Design and implementation
50. Open source development
Open source development is an approach to software
development in which the source code of a software
system is published and volunteers are invited to
participate in the development process
Its roots are in the Free Software Foundation
(www.fsf.org), which advocates that source code should
not be proprietary but rather should always be available
for users to examine and modify as they wish.
Open source software extended this idea by using the
Internet to recruit a much larger population of volunteer
developers. Many of them are also users of the code.
50Chapter 7 Design and implementation
51. Open source systems
The best-known open source product is, of course, the
Linux operating system which is widely used as a server
system and, increasingly, as a desktop environment.
Other important open source products are Java, the
Apache web server and the mySQL database
management system.
51Chapter 7 Design and implementation
52. 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?
52Chapter 7 Design and implementation
53. Open source business
More and more product companies are using an open
source approach to development.
Their business model is not reliant on selling a software
product but on selling support for that product.
They believe that involving the open source community
will allow software to be developed more cheaply, more
quickly and will create a community of users for the
software.
53Chapter 7 Design and implementation
54. Open source licensing
Afundamental 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 an
individual) still owns the code. They can place restrictions on
how it is used by including legally binding conditions in an open
source software license.
Some open source developers believe that if an open 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.
54Chapter 7 Design and implementation
55. License models
The GNU General Public License (GPL). This is a so-called
‘reciprocal’ license that means that if you use open source
software that is licensed under the GPL license, then you
must make that software open source.
The GNU Lesser General Public License (LGPL) is a variant
of the GPL license where you can write components that link
to open source code without having to publish the source of
these components.
The Berkley Standard Distribution (BSD) License. This is a
non-reciprocal license, which means you are not obliged to re-
publish any changes or modifications made to open source
code. You can include the code in proprietary systems that
are sold.
55Chapter 7 Design and implementation
56. License management
Establish a system for maintaining information about
open-source components that are downloaded and
used.
Be aware of the different types of licenses and
understand how a component is licensed before it is
used.
Be aware of evolution pathways for components.
Educate people about open source.
Have auditing systems in place.
Participate in the open source community.
56Chapter 7 Design and implementation
57. 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.
57Chapter 7 Design and implementation