Design and Implementation Lecture Notes PDF

Design and Implementation Part (1) Lecture (3) Dania Mohamed Ahmed Design and implementation  The "Design and Implementation" stage in software engineering involves creating and developing an executable software system. This stage combines two key activit...

Design and Implementation Part (1) Lecture (3) Dania Mohamed Ahmed Design and implementation  The "Design and Implementation" stage in software engineering involves creating and developing an executable software system. This stage combines two key activities: 1. Software Design: This is a creative process where you define the software components and their interactions based on the requirements provided by the customer. 2. Implementation: involves translating the design into actual code, thereby bringing the software design to life.  In essence, software design and implementation are closely intertwined activities where design specifies the blueprint and implementation turns that blueprint into a functioning program. Build or buy  Build or buy software is a critical one, often influenced by factors like cost, time, and functionality. This decision pertains to whether you should develop a custom software solution from scratch or purchase an existing commercial off-the-shelf (COTS) product and adapt it to meet your needs.  Building software means developing a custom solution tailored specifically to the needs and requirements of the organization or project. This typically involves designing and implementing the system from the ground up.  Advantages of building software: 1. Customization: Allows precise tailoring of features, functionality, and design to meet specific organizational needs. 2. Integration: Can be smoothly integrated with existing systems and processes. 3. Competitive Edge: Offers a competitive advantage through unique features or processes that differentiate the organization.  Build or buy  Disadvantages of building software: 1. Cost: Typically higher due to development time, skilled personnel, and resource requirements. 2. Time: Development and testing can be lengthy. 3. Maintenance: Requires ongoing support and maintenance, adding to long-term costs.  Buying software involves purchasing a pre-built software package or system from a vendor. These Commercial Off-The-Shelf (COTS) systems are designed to meet the needs of a broad range of users and can be adapted to fit specific requirements.  Advantages of buying: 1. Cost: Generally more affordable due to economies of scale and shorter development time. 2. Time: Quicker deployment as the software is already developed and tested. 3. Support: Vendor typically provides ongoing support, updates, and maintenance. Build or buy  Disadvantages of buying : 1. Customization Limits: This may not fully meet specific needs or integrate seamlessly; customization is usually limited to the configuration. 2. Dependency: Relies on the vendor for updates, support, and product availability. 3. Flexibility: Offers less flexibility in features and future changes compared to custom- built solutions. An 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 what attributes and methods the objects will have. ► Object-Oriented System: Consists of interacting objects with private states and operations. ► State Privacy: Object states are hidden and not directly accessible from outside. ► Design Process: Focuses on creating classes and defining their relationships and interactions. ► Dynamic Creation: Objects are instantiated from class definitions during execution. ► Encapsulation: Objects combine data and operations, allowing them to be modified independently. ► Impact of Changes: Modifying an object’s implementation or adding new services should not affect other objects. ► Real-World Mapping: Objects often correspond to real-world entities, enhancing design clarity and maintainability. 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: 1. Define the context and modes of use of the system; 2. Design the system architecture; 3. Identify the principal system objects; 4. Develop design models; 5. Specify object interfaces.  Process illustrated here using a design for a wilderness weather station. System context and interactions  In the software design process, the initial stage focuses on understanding how the software interacts with its external environment. This understanding is crucial for defining system functionality and structuring communication with the environment.  System Boundaries: Determining the system's boundaries helps identify which features are part of the system and which belong to other systems. For instance, deciding the functionality of the weather station versus its control system.  System Context Models:  Structural Model: Shows the other systems in the environment of the system being developed. For example, a weather station's context model includes a weather information system, a satellite system, and a control system.  Associations: Represent relationships between entities, such as one control system managing multiple weather stations.  Context and interaction models ► Interaction Models:  Dynamic Model: Illustrates how the system interacts with its environment over time. A use case model can be used for this purpose, showing interactions such as the weather station reporting data to the weather information system and receiving commands from the control system. ► Use Case Model:  Abstract Representation: Describes interactions without excessive detail, using ellipses for use cases and stick figures for external entities (both systems and users).  Example: For a weather station, use cases might include reporting weather data and hardware status, with interactions involving both external systems and control commands.  Documentation:  Structured Descriptions: Use structured natural language to describe interactions, including information exchanged and how interactions are initiated.  Stimuli and Responses: In embedded systems, document how the system responds to internal or external stimuli. System context for the weather station Weather station use cases 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.  Architectural design  Once interactions between a software system and its environment are defined, this information guides the system architecture design. Key steps in this process include:  System Architecture Design: 1. Integration of Knowledge: Combine interaction information with architectural design principles and domain-specific knowledge. 2. Component Identification: Determine the major components of the system and their interactions. 3. Architectural Patterns: Choose an architectural pattern, such as layered or client- server models, to structure the system.  High-Level Architectural Design:  Example: For the weather station, the architecture involves independent subsystems communicating via a common communication link.  Listener Model: This model allows subsystems to broadcast and receive messages without needing to address them to specific subsystems, facilitating flexible configurations.  Architectural design  Subsystem Design:  Data Collection Subsystem: Includes components like Transmitter, Receiver, and WeatherData objects.  Producer–Consumer Pattern: WeatherData encapsulates collected information and communicates it to the weather information system, following the producer-consumer pattern where data is produced by sensors and consumed by the reporting system. ► This architecture simplifies subsystem interactions and enhances flexibility by decoupling message senders from specific receivers. High-level architecture of the weather station Architecture of data collection system Object class identification  Identifying object classes is too 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.  At this stage in the design process, you should have a clear understanding of the essential objects needed for your system. As you refine your design, you'll need to identify and define these objects and their operations based on use case descriptions and other knowledge sources.  Approaches to identification  Three approaches to identifying object classes in object-oriented design are: 1. Grammatical Analysis: Extract objects and attributes from nouns and operations from verbs in a natural language description. 2. Tangible Entities: Use real-world entities like roles, events, interactions, and locations. 3. Scenario-Based Analysis: Analyze scenarios to identify required objects, attributes, and operations.  In practice, refining an initial design involves using a mix of methods. Start with objects identified from informal descriptions, then enhance them using domain knowledge and scenario analysis Weather station description ► A weather station is a software-controlled system that collects, processes, and transmits weather data. ► Instruments include air and ground thermometers, an anemometer, a wind vane, a barometer, and a rain gauge. ► Data is collected periodically. ► Upon receiving a transmission command, the station processes and summarizes the data. ► The summarized data is then sent to a mapping computer upon request. 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: Hardware-related objects representing specific weather instruments in the system.  Weather Station: The main interface between the system and its environment, reflecting the interactions defined in the use-case model.  Weather Data: Encapsulates the summarized data collected from the instruments. Weather station objects Design models  Design or system models illustrate the objects or object classes within a system and their relationships. They bridge system requirements with implementation, balancing abstraction with sufficient detail for programmers.  The level of detail in these models varies with the design process: 1. Agile Development: Abstract models and informal discussions may suffice. 2. Plan-Based Development: More detailed models are needed for precise communication, especially when design and implementation are separated.  Key UML design models include: Structural Models: Depict the static structure with object classes, relationships like inheritance, and composition. Dynamic Models: Show runtime interactions and state changes among system objects, including sequences of service requests and interactions. Examples of design models  Three UML model types are particularly useful for detailing use-case and architectural models: 1. Subsystem Models:  Purpose: Show logical groupings of objects into coherent subsystems.  Representation: Uses class diagrams with packages enclosing related objects.  Type: Structural models. 2. Sequence Models:  Purpose: Illustrate the sequence of interactions between objects.  Representation: Utilizes UML sequence or collaboration diagrams.  Type: Dynamic models.  Example: Sequence diagrams for interactions, such as summarizing and transmitting weather data. Examples of design models 3. State Machine Models:  Purpose: Depict how objects change states in response to events.  Representation: Shown using UML state diagrams.  Type: Dynamic models.  Example: State diagrams for weather station operations, including states 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, with the model read from top to bottom.  Interactions: Depicted by labeled arrows, with different arrow styles indicating different types of interactions.  Lifeline: A thin rectangle on an object’s lifeline shows the duration when the object is the controlling entity in the system. Sequence diagram describing data 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. Weather station state diagram Interface specification  Purpose: Specifies how components interact, allowing parallel development of objects and subsystems.  Data Representation: This should not be detailed in interface design; focus on operations for data access and updates. This allows for changes in data representation without affecting dependent objects, enhancing maintainability.  Multiple Interfaces: An object can have multiple interfaces, providing different viewpoints on its methods. Similarly, a group of objects may be accessed through a single interface.  Example: In the weather station system, interfaces can include a reporting interface for generating reports and a remote control interface for specific operations, each mapping to different methods in the WeatherStation object. Weather station interfaces