Chapter 7: Design and Implementation (3705)

Chapter 7: Design and Implementation (3705)

1. 7.1 Object-oriented design using the UML

   • Object-oriented design processes involve designing object classes and the relationships between these classes
   • System context and interactions
     • System context models and interaction models present complementary views of the relationships between a system and its environment:
       • 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
       • cardinality information on the link shows that there is a single control system but several weather stations, one satellite, and one general weather information system.
   • Architectural design
     • You identify the major components that make up the system and their interactions
     • You may then design the system organization using an architectural pattern such as a layered or client–server model.
     • Once the interactions between the software system and the system’s environment have been defined, you use this information as a basis for designing the system architecture
     • This “listener model” is a commonly used architectural style for distributed systems.
     • broadcasting messages on a common infrastructure, shown as Communication link in Figure 7.4.
     • The Transmitter and Receiver objects are concerned with managing communications, and the WeatherData object encapsulates the information that is collected from the instruments and transmitted to the weather information system.
   • Object class identification
     • Use a grammatical analysis of a natural language description of the system to be constructed
     • Use tangible entities (things) in the application domain
     • “implementation objects” that are used to provide general services such as searching and validity checking
     • At this stage in the design process, you should focus on the objects themselves, without thinking about how these objects might be implemented.
     • look for common features and then design the inheritance hierarchy for the system
   • Design models
     • Design or system models, as I discussed in Chapter 5, show the objects or object classes in a system
     • show the associations and relationships between these entities
     • An important step in the design process, therefore, is to decide on the design models that you need and the level of detail required in these models.
     • When you use the UML to develop a design, you should develop two kinds of design model:
       • Structural models, which describe the static structure of the system using object classes and their relationships
       • Dynamic models, which describe the dynamic structure of the system and show the expected runtime interactions between the system objects
     • I think three UML model types are particularly useful for adding detail to use case and architectural models:
       • Subsystem models, which show logical groupings of objects into coherent subsystems.
       • Sequence models, which show the sequence of object interactions. (Dynamic)
       • State machine models, which show how objects change their state in response to events. (Dynamic)
   • Interface specification
     • An important part of any design process is the specification of the interfaces between the components in the design

2. 7.2 Design patterns

   • The Gang of Four defined the four essential elements of design patterns in their book on patterns:
   • 1. A name that is a meaningful reference to the pattern. 2. A description of the problem area that explains when the pattern may be applied. 3. A solution description of the parts of the design solution, their relationships and their responsibilities. This is not a concrete design description. It is a template for a design solution that can be instantiated in different ways. This is often expressed graphically and shows the relationships between the objects and object classes in the solution. 4. A statement of the consequences—the results and trade-offs—of applying the pattern. This can help designers understand whether or not a pattern can be used in a particular situation.
   • This pattern can be used in situations where different presentations of an object’s state are required. It separates the object that must be displayed from the different forms of presentation.
   • 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.
     • 1. Tell several objects that the state of some other object has changed (Observer pattern). 2. Tidy up the interfaces to a number of related objects that have often been developed incrementally (Façade pattern)3. Provide a standard way of accessing the elements in a collection, irrespective of how that collection is implemented (Iterator pattern). 4. Allow for the possibility of extending the functionality of an existing class at runtime (Decorator pattern).

3. 7.3 Implementation issues

   • create an executable version of the software.
   • some aspects of implementation that are particularly important to software engineering
     • Reuse
       • Most modern software is constructed by reusing existing components or systems.
       • The abstraction level
         • At this level, you don’t reuse software directly but rather use knowledge of successful abstractions in the design of your software.
       • The object 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 operate together to provide related functions and services.
       • The system level
         • you reuse entire application systems
       • reused software has been tested in other applications, it should be more reliable than new software. However, there are costs associated with reuse:
         • 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
         • The costs of adapting and configuring the reusable software components
         • The costs of integrating reusable software elements with each other
     • Configuration management
       • If you don’t keep track of these versions in a configuration management system, you are liable to include the wrong versions of these components in your system.
       • change happens all the time, so change management is absolutely essential.
       • Configuration management is the name given to the general process of managing a changing software system.
       • As shown in Figure 7.14, there are four fundamental configuration management activities:
         • Version management
           • to keep track of the different versions of software components
           • stop one developer from overwriting code that has been submitted to the system by someone else
         • System integration
           • what versions of components are used to create each version of a system
         • Problem tracking
           • report bugs and other problems,
         • Release management,
           • new versions of a software system are released to customer
     • Host-target development
       • you develop it on one computer (the host system) and execute it on a separate computer (the target system)
       • A software development platform should provide a range of tools to support software engineering processes.
         • 1. An integrated compiler and syntax-directed editing system that allows you to create, edit, and compile code. 2. A language debugging system. 3. Graphical editing tools, such as tools to edit UML models. 4. Testing tools, such as JUnit, that can automatically run a set of tests on a new version of a program. 5. Tools to support refactoring and program visualization. 6. Configuration management tools to manage source code versions and to integrate and build systems.
       • As part of the development process, you need to make decisions about how the developed software will be deployed on the target platform
         • straightforward for embedded systems, where the target is usually a single computer
         • distributed systems, you need to decide on the specific platforms where the components will be deployed
           • Issues that you have to consider
             • The hardware and software requirements of a component
             • The availability requirements of the system
             • Component communications

4. 7.4 Open-source development

   • source code of a software system is published and volunteers are invited to participate in the development process
   • in practice, successful open-source systems still rely on a core group of developers who control changes to the software.
   • Linux operating system is the most widely used server system, as is the open-source Apache web server.
   • other key benefit of using open-source products is that widely used open-source systems are very reliable.
   • two open-source issues that have to be considered:
     • Should the product that is being developed make use of open-source components?
     • Should an open-source approach be used for its own software development?
     • software product for sale, then time to market and reduced costs are critical
     • developing software to a specific set of organizational requirements, then using open-source components may not be an option.
     • developing software in a domain in which there are high-quality open-source systems available, you can save time and money by using these systems
   • Open Source views
     • adopting an open-source approach will reveal confidential business knowledge to their competitors and so are reluctant to adopt this development model
     • Businesses supporting open source are mostly selling support for that product.
     • involving the open-source community will allow software to be developed more cheaply and more quickly and will create a community of users for the software.
     • Most successful open-source products have been platform products rather than application systems.
     • Customers with a concerns about its availability in future, making the software open source means that they can take their own copy and so be reassured that they will not lose access to it.
   • Open-source licensing
     • Legally, the developer of the code (either a company or an individual) owns the code. They can place restrictions on how it is used by including legally binding conditions in an open-source software license
     • Most open-source licenses (Chapman 2010) are variants of one of three general models:
       • The GNU General Public License (GPL)
         • This is a so-called reciprocal license that simplistically 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)
         • 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. However, if you change the licensed component, then you must publish this as open source.
       • The Berkley Standard Distribution (BSD) License.
         • This is a nonreciprocal 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. If you use open-source components, you must acknowledge the original creator of the code. The MIT license is a variant of the BSD license with similar conditions.
     • If you are building software that runs on an open-source platform but that does not reuse open-source components, then licenses are not a problem
     • companies managing projects that use open source should:
       • 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
     • open-source approach is one of several business models for software.
       • In this model, companies release the source of their software and sell add-on services and advice in association with this.
       • sell cloud-based software services

5. Introduction

   • Software design and implementation is the stage in the software engineering process at which an executable software system is developed
   • One of the most important implementation decisions that has to be made at an early stage of a software project is whether to build or to buy the application software.
   • To show how system modeling and architectural design (covered in Chapters 5 and 6) are put into practice in developing an object-oriented software design.
   • To introduce important implementation issues that are not usually covered in programming books. These include software reuse, configuration management and open-source development.

Images and files in the map