Software Design and Implementation (Part 1)

Design and Implementation (Part 1)

• The "Design and Implementation" stage in software engineering combines creating and developing an executable software system. This stage combines two key activities.
• Software Design: A creative process to define software components and their interactions, based on customer requirements.
• Implementation: The process of translating the software design into actual code, bringing the design to life.
• Software design and implementation are closely intertwined, with design providing the blueprint and implementation turning it into a functioning program.

Build or Buy

• Choosing between building custom software or purchasing a pre-built solution (Commercial Off-The-Shelf - COTS) is a critical decision often influenced by factors like cost, time, and functionality.
• Building software involves designing and implementing the system from the ground up, tailored to the specific needs of the organization or project.
• Advantages of Building Software:
  • Customization: Tailoring features, functionality, and design to specific organizational needs.
  • Integration: Seamless integration with existing systems and processes.
  • Competitive Edge: Unique features or processes that differentiate the organization.
• Disadvantages of Building Software:
  • Cost: Typically higher due to development time, skilled personnel, and resource requirements.
  • Time: Development and testing can be lengthy.
  • Maintenance: Ongoing support and maintenance adds to long-term costs.
• Advantages of Buying Software:
  • Cost: Economies of scale and shorter development time, generally more affordable.
  • Time: Quicker deployment since the software is already developed and tested.
  • Support: Vendor typically provides ongoing support, updates, and maintenance.
• Disadvantages of Buying Software:
  • Customization Limits: May not fully meet specific needs or integrate seamlessly (customization typically limited to configuration).
  • Dependency: Reliance on vendor support, updates, and product availability.
  • Flexibility: Less flexibility in features and future changes compared to custom-built solutions.

Object-Oriented Design Process

• An object-oriented system is a software design and development approach that organizes and structures a program using objects.
• Objects: Fundamental units that combine data (attributes) and behavior (methods). Each object represents an instance of a class.
• Classes: Blueprints or templates that define the structure and behavior of objects. They specify object attributes and methods.
• Object-Oriented System: Consists of interacting objects with private states and operations.
• State Privacy: Objects protect their internal state from external access.
• Design Process: Focuses on creating classes and defining their relationships and interactions.
• Dynamic Creation: Objects are instantiated from classes during execution.
• Encapsulation: Objects combine data and operations.
• Impact of Changes: Modifying one object should not affect other objects.
• Real-World Mapping: Objects correspond to real-world entities, enhancing clarity and maintainability.

Process Stages

• Design processes commonly involve defining system context and modes of use, designing system architecture, identifying principal system objects, developing design models, and specifying object interfaces.

System Context and Interactions

• The initial stage in software design is understanding how the software interacts with its external environment, crucial for defining functionality and communication.
• System Boundaries: Determining what's part of the system, and what are external systems.
• System Context Models: Including structural models (showing other systems in the environment) and associations (relationships between entities).

Context and Interaction Models

• Interaction Models: Illustrate how a system interacts with its environment over time (often using use case models).
• Use Case Model: Describes interactions without excessive detail. Use ellipses for use cases, stick figures for external entities.

Weather Station Description

• A weather station is a software-controlled system that collects, processes, and transmits weather data.
• Instruments include thermometers, anemometer, wind vane, barometer, and rain gauge.
• Data is collected periodically, processed, and summarized.
• Summarized data is sent to a mapping computer upon request.

Weather Station Object Classes

• Object class identification is often based on tangible hardware and data within the weather station system.
• Ground Thermometer, Anemometer, Barometer: Hardware-related objects representing instruments.
• Weather Station: The main interface between the system and its environment.
• Weather Data: Encapsulates summarized data.

Weather Station Objects

• WeatherStation: An object that identifies a weather station, handles reporting, status, and related operations.
• WeatherData: Stores and summarizes weather data collected.
• Ground Thermometer, Anemometer, Barometer: Represents instruments that measure specific data. Each includes methods for retrieving data (get()) and testing (test()).

Design Models

• Design or system models illustrate objects/object classes and their relationships within a system, bridging system requirements and implementation.
• Agile Development: Abstract models and informal discussions may suffice.
• Plan-based Development: More detailed models are needed, especially when design and implementation are separated.
• Key UML Models: Include Structural models, depicting static structure, and Dynamic models, which show runtime interactions and state changes.

Examples of Design Models

• Subsystem Models: Grouping related objects into logical subsystems.
• Sequence Models: Illustrating the order of interactions between objects using UML sequence or collaboration diagrams (e.g., summarizing and transmitting weather data).
• State Machine Models: Describing how objects change states in response to events, typically using UML state diagrams (e.g., weather station operations like Shutdown, Running, Summarizing, and Collecting).

Sequence Models

• Sequence models illustrate the order of interactions between objects in a system.
• Objects: Arranged horizontally across the top of the diagram.
• Time: Represented vertically, diagram read top-to-bottom.
• Interactions: Depicted by labeled arrows, different style for different interaction types.
• Lifeline: Shows duration when an object is controlling.

Interface Specification

• Purpose: Specifies how components interact, enabling parallel development of objects/subsystems.
• Data Representation: Operations for data access should be clearly specified.
• Multiple Interfaces: An object can have multiple interfaces (e.g., reporting interface and remote control).

Weather Station Interfaces

• Reporting Interface: Contains methods for reporting weather status and weather reports.
• Remote Control Interface: Contains methods for controlling instruments, starting, stopping, status, data collection.

This quiz covers the initial stages of software engineering, focusing on the design and implementation of software systems. It explores the creative process of software design and the translation of that design into functional code. Additionally, the quiz examines the key decision-making process between building custom software versus buying pre-built solutions.