Part 2: Experience Customization Tailored to Your Site

In this section, let’s explore Next Design’s customizability and scalability—which enable it to handle a wide range of tasks—and experience firsthand the concept behind Next Design: “a design tool that fits the field.”
While this section uses embedded software development as an example, you can customize the sample—which follows a standard V-model process—to suit your own development needs, making it applicable to tasks beyond embedded software development.

The estimated time required is about 30 minutes.

Step

Let's explore the customization and extensibility of Next Design in this order.

  1. Let's take a look at the profile and the target process.
  2. Let's narrow down the target processes.
  3. Let's add the necessary design data.
  4. Let's experience the expandability offered by extensions.

1. Let's take a look at the profile and the target process.

Review the big picture of the target process

Videos for Steps 1–4: Get an overview of the target process
Open in a new window
Class Diagram for the Target Process
Open in a new window
Video for Step 5: Checking Candidate Processes When Adding a Model
Open in a new window

Details of the Implementation

At Next Design, we define the types and structures of information handled in the design process as “profiles.” The embedded software development base package comes pre-configured with profiles that align with the V-model process commonly used in embedded software development.

Here, open [[Class Diagram]Target Process] from the Profile Navigator to view an overview of the processes defined in the package.

procedure

  1. Open the sample project [Embedded Software Development] in Next Design.
  2. Switch the Navigator to the Profile Navigator.
  3. In the Profile Navigator, double-click the following class diagram to open it.

    [Class Diagram] Target Process

  4. Verify that the requirements analysis and design phases, as well as the testing phase, are defined in the class diagram in accordance with the V-model.

    The following steps are defined for the requirements analysis and design phase.

    • System Requirements Analysis
    • Software Requirements Analysis
    • Software Architecture Design
    • Software Component Design

    The following steps are defined for the testing process.

    • Software Component Testing
    • Software Integration Testing
    • Software Testing
  5. Return to the Model Navigator and, when adding a model to the project root, verify that each process you identified in the class diagram appears as an option.

Goal

You can see that the embedded software development base package comes with predefined profiles based on the standard V-model, allowing you to create a software development model simply by implementing the package.

2. Let's narrow down the target processes.

Limit it to only the processes that are used

Open in a new window
As a result of narrowing down the target processes to four
Open in a new window

Details of the Implementation

In actual development, the scope of Next Design application varies depending on the project. By customizing the profile of the Embedded Software Development Base Package, you can limit the options available when adding models to only those processes used in your project.

Here, we will assume a minimal V-model process that includes the upstream phases and limit the applicable phases to the following four.

  • Software Requirements Analysis
  • Software Architecture Design
  • Software Integration Testing
  • Software Testing

procedure

  1. Switch to the Profile Navigator and open the following class diagram.

    [Class Diagram] Target Process

  2. In the class diagram, select one process at a time from the following processes—which are not included in the scope of this project—to remove.
    • System Requirements Analysis
    • Software Component Design
    • Software Component Testing
  3. Right-click the selected process and select [Remove from Model] from the context menu.
  4. When the dialog box appears, click [Delete All].
  5. Repeat steps 2 through 4 to remove the three processes that are not included in the scope.
  6. Verify that only the following four processes remain in the [[Class Diagram] Target Processes].
    • Software Requirements Analysis
    • Software Architecture Design
    • Software Integration Testing
    • Software Testing
  7. Return to the Model Navigator and verify that the options for adding a model at the project root are limited to the four steps you kept.

Goal

By using the standard package profile as a basis and retaining only the steps necessary for your project’s scope, you’ll see that you can tailor it to fit your own development process.

These procedures are also described in the manual for the Embedded Software Development Base Package.

See: Package Manual > Customization Guide > C1: Using the Software with Limited Scope and Processes

3. Let's add the necessary design data.

Ensure that the design rationale can be documented

Video for Steps 1–4: Adding a Design Rationale Field
Open in a new window
With the "Design Rationale" field added
Open in a new window
Video for Steps 5–7: Adding a Design Rationale View
Open in a new window
With the Design Rationale view added
Open in a new window

Details of the Implementation

Based on the design information defined in the standard package, you can add the information needed for your own development.

Here, as a typical example of adding design data, we will add a rich-text [Design Rationale] field—which allows you to document the rationale behind the design, such as interface design, for each software component—along with a form view for editing it.

procedure

  1. Switch to the Profile Navigator and select the following class from the tree.

    Embedded Software Development > Software Architecture Design > Software Components

  2. Click [View] > [Pane] > [Inspector] in Ribbon to display the Inspector on the right side of the screen, where you can configure detailed settings.
  3. From the Ribbon, select [Profile] > [View] > [Related Class Diagrams] to open the following class diagram.

    [Class Diagram] Software Architecture Design

  4. Add the following fields to the [SoftwareComponent] class.

    Make sure the [Software Component] class is selected in the class diagram, then click the [+] icon in the list of [Fields] displayed in the Inspector on the right side of the screen and enter the following information.

    Display Name: Design Rationale
    Field Name: Design Rationale
    Data Type: Rich Text
    Add controls corresponding to all forms: Off

    When you click the [OK] button, a [Design Rationale] field will be added to the [Software Component] class.

  5. Next, add a view to display and edit the newly added [Design Rationale] field.

    First, return to the Model Navigator and open one of the [Software Component] models you want to work with. In this example, open the following model:

    Embedded Software Development / Software Architecture Design / ADAS ECU Component Integration / Application Layer / Vehicle Speed Deviation Calculation

  6. Click [Profile] > [View Definitions] > [New View] > [Document] on the ribbon, and enter the following information on the screen.

    Display Name: Design Rationale
    View Name: Design Rationale

    When you click the [OK] button, [Design Rationale] will be added to the view options, and you will be able to switch to it.

  7. Place the [Design Rationale] field you just added in the newly added [Design Rationale] view.

    Right-click the title of the view, click [Profile] > [Add Existing Field] from the context menu, and then select the [Design Rationale] field from the [Field] list.

    When you click the [OK] button, a [Design Basis] field is added to the [Design Basis] view.

  8. [Design Rationale] Since views are added to all [Software Component] models, it becomes possible to document the design rationale for any model.

Goal

By adding fields and views to existing classes, you can understand how to manage the design information necessary for your development as part of the model.

These procedures are also described in the manual for the Embedded Software Development Base Package.

See: Package Manual > Customization Guide > C2: Adding Domain-Specific Design Information > Adding Fields to Store Design Information

View the metamodel for the entire set of design data

Class diagram representing the metamodel of the entire design data set
Open in a new window

Details of the Implementation

The overall structure of the design data handled by Next Design is called a “metamodel.” You can view the structure of this metamodel in the form of a class diagram and customize it to suit your development needs.

Here, we'll take a look at part of the metamodel defined in the sample.

procedure

  1. From the Next Design startup screen, reopen the sample project [Embedded Software Development].
  2. Switch the Navigator to the Profile Navigator.
  3. Double-click the following class diagram in the Profile Navigator to open it and review the overall structure of the design data.
    Class Diagram Description.
    [Class Diagram] Overall Structure Class diagram illustrating the main structure and relationships of design data for each V-model phase
    [Class Diagram] Trace-Related Diagram Class diagram illustrating the relationships between traceability information across processes
    Software Architecture Design > [Class Diagram] Software Architecture Design A class diagram illustrating the structure and relationships of design data used in the software architecture design process

Goal

You can understand that the structure of the design data handled by Next Design is defined as a metamodel, and that you can verify this structure using the class diagrams included in the profile.

4. Let's experience the expandability offered by extensions.

Automatically extract the scope of impact

Open in a new window

Details of the Implementation

The embedded software development base package includes extensions that use models to automate routine tasks.

Here, you will perform [Extracting Areas Affected by Interfaces], which identifies dependencies based on interfaces and components in static structure diagrams. You will experience how the centralized management of design information as a model enables the automatic identification of the scope of impact when changes are made.

procedure

  1. In the Model Navigator, select a model under [Software Architecture Design Group] or [Software Component].

    For example, select the following model.

    Embedded Software Development / Software Architecture Design / ADAS ECU Component Integration

  2. Switch the main editor's view to [Static Structure Diagram].
  3. On the static structure diagram, select one interface or component for which you want to check the scope of impact.
  4. In Ribbon, click [Design Support] > [Impact Analysis] > [Extract IF Impact Locations].
  5. Verify that the extension can identify the interfaces associated with an interface and determine the scope of its impact.

Goal

By managing design information as models, you can see how extensions automate the process of tracing relationships between models, allowing you to efficiently verify the scope of impact when changes are made.

Let's take a look at the extension's source code

Source code for the C# extension
Open in a new window
Source code for the Python extension
Open in a new window

Details of the Implementation

The source code for the extensions included in the Embedded Software Development Base Package is available for both the C# and Python versions. You can use the source code as an implementation example or use it as a basis to extend the software to suit your specific business needs.

In this section, we'll examine the publicly available source code and the automation features included in the package to understand how Next Design can be extended through programming.

procedure

  1. We will review the extension source code for the embedded software development base package published on GitHub.com.

    You can view the source code corresponding to the [Extract IF Affected Areas] extension feature you just ran at the following link.

    C# source code: searchImpactedComponentsAndInterfaces.cs

    Python source code: search_impacted_components_and_interfaces.py

  2. In addition to automatic impact analysis, the embedded software development base package includes extensions that automate the following routine tasks:
    • Batch Creation of Software Requirements Models
    • Batch Creation of Test Result Models
    • Sequential Reassignment of IDs
    • Automatic Extraction of the Scope of Impact
    • Automatic Tabulation of Test Results

    You can also view this source code at the following link.

    https://github.com/denso-create/NextDesign-Samples/tree/main/extensions/EmbeddedSoftwareDevBase

Goal

You’ll see that it offers the flexibility not only to use the extension features included in the standard package but also to customize the software to suit your specific business needs by referencing the publicly available C# or Python source code, thereby enabling the automation of routine tasks such as the following.

Examples of automating routine tasks using extensions:

  • Check for Compliance with Design Rules
  • Test Data Generation
  • Integration with external tools, etc.

Let's summarize the key points of Next Design!

Summarizing the Key Points