Software Design and Implementation Quiz

Software Design and Implementation

• Software design and implementation is the stage of software engineering where an executable software system is created.
• Design and implementation activities are often intertwined.
• Software design is a creative process. It involves identifying software components and their relationships, based on customer requirements.
• Implementation is the process of converting the design into a working program.

Build or Buy

• In many fields, ready-made systems (COTS) can be adapted to meet user needs.
• Using existing software can be faster and cheaper than developing from scratch (e.g., using pre-built medical records systems).
• When using COTS, the design process focuses on how to use the system's configuration features to achieve the desired functionality.

Object-Oriented Design Process

• Object-oriented design processes involve creating multiple system models.
• This approach requires significant effort for development and maintenance, sometimes making it cost-ineffective for smaller projects.
• For large projects with multiple teams, design models are vital for effective communication.

Process Stages

• Various object-oriented design processes exist, dependent on the organization implementing them.
• Common activities in these processes include: defining system context and usage, designing system architecture, identifying key system objects, creating design models, specifying object interfaces.
• An example illustrated is a design for a wilderness weather station.

System Context and Interactions

• Understanding the relationships between the software being designed and its external environment is critical for determining system functionality and structure.
• Defining system boundaries helps in determining the features implemented in the system and those in related systems.

Context and Interaction Models

• A system context model depicts the other systems within the environment of the system being developed (structural).
• An interaction model depicts how the system interacts with its environment during use (dynamic).

Architectural Design

• After understanding interactions with the system's environment, the system architecture can be designed.
• Major system components and their interactions are identified and organized using architectural patterns (e.g., layered or client-server).
• The weather station example consists of independent subsystems communicating over a shared infrastructure.

Object Class Identification

• Identifying object classes is a crucial but often difficult part of object-oriented design.
• No single "magic formula" exists; it relies on the experience and domain knowledge of the designers.
• This process is iterative (it takes several attempts).

Approaches to Identification

• Methods for identifying object classes include: grammatical approaches (based on natural language descriptions), domain-based approaches (focused on tangible things in the application), behavioral approaches (identifying objects based on their actions), and scenario-based approaches (identifying objects based on use cases).

Weather Station Object Classes

• Object identification in the weather station system can be based on hardware (e.g., thermometer, anemometer) and data elements (e.g., weather data).
• Application-domain objects include weather station hardware.
• The weather station's interface reflects interactions detailed in use-case models.
• Weather data encapsulates summarized data from instruments.

Design Models

• Design models illustrate objects, object classes, and relationships between them.
• Two main types of design models exist: structural models (depicting static system structure) and dynamic models (depicting dynamic interactions between objects).

Examples of Design Models

• Subsystem models represent logical groupings of objects into subsystems.
• Sequence models depict the sequence of object interactions.
• State machine models illustrate how objects change state responding to events.
• Other models exist, including use case models, aggregation models, and generalizations.

Subsystem Models

• Subsystem models illustrate how a design is structured into logically related object groups.
• UML packages represent these groupings, providing a logical model.
• Actual object organization within the system may differ.

Sequence Models

• Sequence models graphically display object interactions.
• Objects are arranged horizontally, and time flows vertically.
• Interactions occur along connected arrows.
• A thin rectangle in an object lifeline represents actions of that object.

State Diagrams

• State diagrams show how objects respond to service requests (state transitions).
• State diagrams are high-level models of system run-time behavior, not necessarily detailing all objects (many can be simple).

Interface Specification

• Object and component interfaces must be specified for parallel design.
• Interface representations should be hidden within the object itself.
• Objects may have multiple interfaces that view different aspects of their methods.

Implementation Issues

• Implementation involves more than just programming (e.g., reuse, configuration management, host-target development); these are often not included in programming texts.
• Reuse involves reusing existing components or systems in new software. Configuration Management is necessary to track changes to the software over time. Host-target development ensures software can run on different environments (eg. development vs actual server).

Reuse

• Reuse was a less significant aspect of software development from the 1960s to the 1990s. Reusing functions and programming languages libraries was a limited form of reuse. Costs and time pressure made broader software reuse less viable.
• Reuse strategies/reuse levels include: abstraction level, object level, component level, and system level.

Reuse Costs

• Reusing software includes the costs associated with search, evaluation, and adaptation.
• Adapting existing software to meet specific needs can be expensive.
• Integrating software components from different sources adds further cost, particularly for large-scale projects.

Configuration Management

• Configuration management involves tracking changes to a software system over time.
• The goal is to allow developers to access related, and changing code in a controlled manner.
• Developers need to understand the changes. A configuration management system is needed to compile and link components correctly.

Configuration Management Activities

• Version management: tracking and maintaining different versions of software components.
• System integration: specifying the components and versions used to create each system version.
• Problem tracking: managing bug reports and other issues by assigning and tracking the relevant developers and details.

Development Platform Tools

• Integrated development environments (IDEs) combine tools to support different aspects of software development.
• IDEs provide a common framework and user interface for programming tools (e.g., compilers, debugging tools, and UML model creation).
• Testing tools are useful for running predefined sets of automated tests on a program's new versions.

Open Source Development

• Open source development is based on published software source code, enabling volunteer contributions to the development process.
• The Free Software Foundation (www.fsf.org), highlights principles of open source code.
• Open source models often attract a larger volunteer community, frequently enabling faster development.

Open Source Systems

• Linux is a widely used server and desktop operating system.
• Java, the Apache web server and the mySQL database management system are also notable open-source examples.

Open Source Issues

• Organizations evaluating a product for development should consider whether or not to utilize open-source components or processes.
• Evaluating the cost-benefit of using open source software.

Open Source Business

• Business models of some organizations increasingly rely on support services for open-source software rather than selling the software itself.
• Using open-source communities may allow developing software more quickly and less expensively.