程序员的资源宝库

网站首页 > gitee 正文

代码中的软件工程-menu项目工程化编程实战

sanyeah 2024-03-29 17:24:29 gitee 11 ℃ 0 评论

代码中的软件工程-menu项目工程化编程实战

前言

本博客主要根据孟宁老师课上所讲述的有关软件工程的相关知识,以VS Code + GCC工具集为主要环境编译调试课程项目menu的仔细阅读分析源代码,结合代码分析其中的软件工程方法、规范或软件工程思想。

参考资料如下:

VS Code + GCC工具集环境配置:https://mp.weixin.qq.com/s/sU9Wh12JZqQyJfEBBafFAQ

代码案例:https://github.com/mengning/menu

其他参考资料:https://gitee.com/mengning997/se/blob/master/README.md#代码中的软件工程

一. 编译调试环境配置

1. 安装C/C++插件:

打开 VSCode 点击最左侧的管理扩展插件图标(Ctrl+Shift+X),如下图在扩展插件市场里搜索 C++,找到 Microsoft C/C++扩展插件“C/C++ for Visual Studio Code”,点击 Install 安装即可。

2. 安装C/C++编译器和调试器:

VSCode 的 C/C++插件并不包含 C/C++编译器和调试器,不同的 C/C++编译器和调试器的用法有所不同,由于 GCC 在不同平台上都可以使用,而且用法基本一致,我们这里选用 Mingw-w64(包含 GCC 和 GDB)用于 Windows 环境。具体下载过程以及环境变量的配置参考前言中的相关链接。

3. 配置VS Code构建任务

一般在命令行下使用"code ."命令可以打开及当前文件夹,同时将当前文件夹作为工作区(workspace)。同时 VS Code 会在当前工作区创建.vscode 文件夹并在其中创建三个 JSON 配置文件:

tasks.json (build instructions)

launch.json (debugger settings)

c_cpp_properties.json (compiler path and IntelliSense settings)

1. tasks.json

tasks.json配置文件是用来告诉 VS Code 如何编译程序,我们这里可以通过修改 tasks.json 配置构建任务,实际上就调用 gcc 编译器将源代码变异成可执行程序。具体参数配置如下:

//主要注意如果是编写C++,编译器需改成g++;如果不想要额外警告,把-Wall那一条删去。
//更多详情请查阅https://code.visualstudio.com/docs/editor/tasks
{
    "version": "2.0.0",
    "tasks": [{
        "label": "Compile", // 任务名称,与launch.json的preLaunchTask相对应
        "command": "gcc",   // 要使用的编译器,C++用g++
        "args": [
            "${file}",
            "-o",    // 指定输出文件名,不加该参数则默认输出a.exe,Linux下默认a.out
            "${fileDirname}/${fileBasenameNoExtension}.exe",
            "-g",    // 生成和调试有关的信息
            "-m64", // 不知为何有时会生成16位应用而无法运行,加上此条可强制生成64位的
            "-Wall", // 开启额外警告
            "-static-libgcc",     // 静态链接libgcc,一般都会加上
            "-fexec-charset=GBK", // 生成的程序使用GBK编码,不加这条会导致Win下输出中文乱码;繁体系统改成BIG5
            // "-std=c11", // 要用的语言标准,根据自己的需要修改。c++可用c++14
        ], // 编译的命令,其实相当于VSC帮你在终端中输了这些东西
        "type": "process", // process是把预定义变量和转义解析后直接全部传给command;shell相当于先打开shell再输入命令,所以args还会经过shell再解析一遍
        "group": {
            "kind": "build",
            "isDefault": true // 不为true时ctrl shift B就要手动选择了
        },
        "presentation": {
            "echo": true,
            "reveal": "always", // 执行任务时是否跳转到终端面板,可以为always,silent,never。具体参见VSC的文档
            "focus": false,     // 设为true后可以使执行task时焦点聚集在终端,但对编译C/C++来说,设为true没有意义
            "panel": "shared"   // 不同的文件的编译信息共享一个终端面板
        },
        "problemMatcher":"$gcc" // 捕捉编译时终端里的报错信息到问题面板中,修改代码后需要重新编译才会再次触发
        // 本来有Lint,再开problemMatcher就有双重报错,但MinGW的Lint效果实在太差了;用Clang可以注释掉
    }]
}

2. launch.json

配置文件 launch.json 用于告诉 VS Code 如何调用调试器调试程序,我们这里 GDB debugger 为例。配置调试环境可以通过左侧的“启动和调试”图标或者快捷键 Ctrl+Shift+D 进入 Debug 二级菜单,然后创建一个 launch.json 配置文件(create a launch.json file),选择 C++(GDB/LLDB)。具体参数配置如下:

// 使用 IntelliSense 了解相关属性。 
// 悬停以查看现有属性的描述。
// 欲了解更多信息,请访问: https://code.visualstudio.com/docs/cpp/launch-json-reference
{
    "version": "0.2.0",
    "configurations": [{
        "name": "(gdb) Launch", // 配置名称,将会在启动配置的下拉菜单中显示
        "type": "cppdbg", // 配置类型,cppdbg对应cpptools提供的调试功能;可以认为此处只能是cppdbg
        "request": "launch", // 请求配置类型,可以为launch(启动)或attach(附加)
        "program": "${fileDirname}/${fileBasenameNoExtension}.exe", // 将要进行调试的程序的路径
        "args": [], // 程序调试时传递给程序的命令行参数,一般设为空即可
        "stopAtEntry": false, // 设为true时程序将暂停在程序入口处,相当于在main上打断点
        "cwd": "${fileDirname}", // 调试程序时的工作目录,${workspaceFolder}此为工作区文件夹;改成${fileDirname}可变为文件所在目录
        "environment": [], // 环境变量
        "externalConsole": true, // 使用单独的cmd窗口,与其它IDE一致;为false时使用内置终端
        "internalConsoleOptions": "neverOpen", // 如果不设为neverOpen,调试时会跳到“调试控制台”选项卡,你应该不需要对gdb手动输命令吧?
        "MIMode": "gdb", // 指定连接的调试器,可以为gdb或lldb。但我没试过lldb
        "miDebuggerPath": "gdb.exe", // 调试器路径,Windows下后缀不能省略,Linux下则不要
        "setupCommands": [
            { // 模板自带,好像可以更好地显示STL容器的内容,具体作用自行Google
                "description": "Enable pretty-printing for gdb",
                "text": "-enable-pretty-printing",
                "ignoreFailures": false
            }
        ],
        "preLaunchTask": "Compile" // 调试会话开始前执行的任务,一般为编译程序。与tasks.json的label相对应
    }]
}

3. c_cpp_properties.json

{
    "configurations": [
        {
            "name": "Win32",//配置标识符
            "includePath": [//一些库路径,如果需要递归包含,末尾加/**
                "${workspaceFolder}/**"
            ],
            "defines": [//预处理列表
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "compilerPath": "D:\\SOFTWARE\\mingw64\\bin\\gcc.exe",//编译器完整路径
            "cStandard": "gnu17",//c语言标准版本
            "cppStandard": "gnu++14",//c++标准版本
            "intelliSenseMode": "gcc-x64"//设置IntellSense模式
        }
    ],
    "version": 4//配置文件版本
}

4. 试运行环境是否配置成功:

#include <stdio.h>
int main()
{
    printf("hello world!\n");
}

二. menu项目分析

在对menu项目分析之前先尝试该项目是否能正常运行,运行结果如下图:

测试正常,接下来结合孟老师所给的代码迭代开发的过程对整个项目进行分析。

名称 包含文件 内容描述
lab1 hello.c/menu.c hello.c 文件用于测试环境是否搭建完成,menu.c 文件是该项目的基础框架(伪代码)。
lab2 menu.c 对menu.c进行完善,成为可执行代码。还添加了文件头部注释。
lab3.1 menu.c 添加了一个命令链表,通过遍历链表来实现功能,包括help/version/quit三项功能。
lab3.2 menu.c 将对链表的操作封装到FindCmd函数当中,以及help中的描述内容封装到函数ShowAllCmd当中。
lab3.3 linklist.c/linklist.h/menu.c 将功能部分的代码实现分离到linklist模块当中,linklist.h包含对函数的声明,linklist.c则为函数的实现。
lab4 linktable.h/linketable.c/menu.c/test.c/testlinktable.c 引入了动态创建命令链表包括增删改等功能,利用了信号量实现链表的同步与互斥,还进行了单元测试。
lab5.1 linktable.h/linktable.c/menu.c/testlinktable.c 引入回调函数SearchCondition,回调函数的调用函数SearchLinkTableNode。
lab5.2 linktable.h/linktable.c/menu.c/Makefile 改造了SearchLinkTableNode,降低了耦合度,添加了makefile来告诉编译器如何去编译和连接程序。
lab7.1 linktable.h/linktable.c/menu.c/Makefile/menu.h/test.c 新增了menu部分的功能分离出来成为一个独立模块,main函数在test中实现,此时只需要调用简单的函数接口。
lab7.2 lab7.1+readme.txt 增加了 readme.txt 文件,记录了项目的相关说明。

三. 结合软件工程思想对menu项目的一些总结思考

1. 模块化设计

从lab3.3开始逐渐将各功能模块化,在lab3.3中将原本写在menu.c的FindCmd和ShowAllCmd以及DataNode结构体分离到了linklist模块中,一次次迭代模块化,最后将整个menu分解为了linktable和menu模块,每一个软件模块都将只有一个单一的功能目标,并相对独立于其他软件模块。而在主程序中只需要根据所需功能调用相应的函数即可。

linktable内只需要实现对命令链表的创建、增加,删除,查找操作的接口,在统一好接口规范之后只需专注与功能的实现,不用理会模块外的其他事情。

menu则实现对命令的获取,数据的显示等,无需关心具体的实现。

这很好符合模块化程序设计的思想,也很好的体现了模块化的目标“高内聚、低耦合”。

耦合度是指软件模块之间的依赖程度,一般可以分为紧密耦合(Tightly Coupled)、松散耦合(Loosely Coupled)和无耦合(Uncoupled)。一般在软件设计中我们追求松散耦合。

内聚度是指一个软件模块内部各种元素之间互相依赖的紧密程度。理想的内聚是功能内聚,也就是一个软件模块只做一件事,只完成一个主要功能点或者一个软件特性(Feather)。

模块化程序设计的基本思想是自顶向下、逐步分解、分而治之,即将一个较大的程序按照功能分割成一些小模块,各模块相对独立、功能单一、结构清晰、接口简单。有效控制了程序设计的复杂性、提高了代码的重用性、易于维护和功能扩充、有利于团队开发。

2.可重用接口

尽管已经做了初步的模块化设计,但是分离出来的数据结构和它的操作还有很多菜单业务上的痕迹,我们要求这一个软件模块只做一件事,也就是功能内聚,那就要让它做好链表数据结构和对链表的操作,不应该涉及菜单业务功能上的东西;同样我们希望这一个软件模块与其他软件模块之间松散耦合,就需要定义简洁、清晰、明确的接口。

接口就是互相联系的双方共同遵守的一种协议规范,在我们软件系统内部一般的接口方式是通过定义一组API函数来约定软件模块之间的沟通方式。换句话说,接口具体定义了软件模块对系统的其他部分提供了怎样的服务,以及系统的其他部分如何访问所提供的服务。

接口规格是软件系统的开发者正确使用一个软件模块需要知道的所有信息,那么这个软件模块的接口规格定义就必须清晰明确地说明正确使用本软件模块的信息。一般来说,接口规格包含五个基本要素:

接口的目的;
接口使用前所需要满足的条件,一般称为前置条件或假定条件;
使用接口的双方遵守的协议规范;
接口使用之后的效果,一般称为后置条件;
接口所隐含的质量属性。

menu中可重用接口设计

可重用是为了提供软件开发的效率,很多已经实现的功能就没必要再浪费时间去重写了,不要重复的造轮子,但要求这个接口要尽量减少耦合,在被调用的时候,调用者无需知道内部的具体实现,只需要具体的用法即可。

以该项目中 linktable.c 的 SearchLinkTableNode 函数为例。SearchLinkTableNode函数的Condition参数是一个函数指针,利用回调函数参数为其他模块提供了一个更加通用的接口,而且这个函数没有用到任何业务逻辑层的数据,只是负责遍历链表,具体判断是否找到指定条件的节点交由Condition回调函数来负责。另一个想要调用该接口的模块,可以根据自己的需求去编写Condition函数,大大提高了接口的通用性。还有一个参数是args,避免访问全局变量cmd,将该变量独立出来。

我们还通过将linktable.h中不是在接口调用时必须内容转移到linktable.c中,这样可以有效地隐藏软件模块内部的实现细节,为外部调用接口的开发者提供更加简洁的接口信息,同时也减少外部调用接口的开发者有意或无意的破坏软件模块的内部数据。通过接口进行信息隐藏已经成为面向对象编程语言的标准做法,使用public和private来声明属性和方法对于外部调用接口的开发者是否可见。

tDataNode *p = (tDataNode*)SearchLinkTableNode(head,SearchConditon,(void*)argv[0]);
/*
 * Search a LinkTableNode from LinkTable
 * int Conditon(tLinkTableNode * pNode);
 */
tLinkTableNode * SearchLinkTableNode(tLinkTable *pLinkTable, int Conditon(tLinkTableNode * pNode, void * args), void * args)
{
    if(pLinkTable == NULL || Conditon == NULL)
    {
        return NULL;
    }
    tLinkTableNode * pNode = pLinkTable->pHead;
    while(pNode != NULL)
    {    
        if(Conditon(pNode,args) == SUCCESS)
        {
            return pNode;				    
        }
        pNode = pNode->pNext;
    }
    return NULL;
}

int SearchConditon(tLinkTableNode * pLinkTableNode,void * arg)
{
    char * cmd = (char*)arg;
    tDataNode * pNode = (tDataNode *)pLinkTableNode;
    if(strcmp(pNode->cmd, cmd) == 0)
    {
        return  SUCCESS;  
    }
    return FAILURE;	       
}

3.可重入函数与线程安全

可重入(reentrant)函数:当一个执行流因为异常或者被内核切换而中断正在执行的函数而转为另外一个执行流时,当后者的执行流对同一个函数的操作并不影响前一个执行流恢复后执行函数产生的结果。

不可重入(non-reentrant)函数:当程序运行到某一个函数的时候,可能因为硬件中断或者异常而使得在用户正在执行的代码暂时终端转而进入你内核,这个时候如有一个信号需要被处理,而处理的这个信号的时候又会重新调用刚才中断的函数,如果函数内部有一个全局变量需要被操作,那么,当信号处理完成之后重新返回用户态恢复中断函数的上下文再次继续执行的时候,对同一个全局变量的操作结果可能就会发生改变而并不如我们预期的那样,这样的函数被称为不可重入函数。例如在进行链表的插入时,插入函数访问一个全局链表,有可能因为重入而造成错乱。

可重入函数满足的条件:

(1)不为连续的调用持有静态数据;
(2)不返回指向静态数据的指针;
(3)所有数据都由函数的调用者提供;
(4)使用局部变量,或者通过制作全局数据的局部变量拷贝来保护全局数据;
(5)使用静态数据或全局变量时做周密的并行时序分析,通过临界区互斥避免临界区冲突;
(6)绝不调用任何不可重入函数。

线程安全:如果你的代码所在的进程中有多个线程在同时运行,而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的,而且其他的变量的值也和预期的是一样的,就是线程安全的。线程安全本质上其实是内存的安全!

常见的线程安全的情况:

(1)每个线程对全局变量或者静态变量只有读取的权限,而没有写入的权限,一般来说这些线程是安全的;
(2)类或者接口对于线程来说都是原子操作;
(3)多个线程之间的切换不会导致该接口的执行结果存在二义性;

可重入函数与线程安全的关系:

不可重入函数线程不安全,线程安全不一定是可重入函数,而可重入函数一定是线程安全的。

menu项目中线程安全的应用

在多线程应用程序中,当多个线程共享相同的内存时,如同时访问一个变量时,需要确保每个线程看到一致的数据视图,即保证所有线程对数据的修改是一致的。该项目中是通过互斥锁来实现线程安全的,主要应用于linktable中的DeleteLinkTable、AddLinkTableNode和DelLinkTableNode中。

struct LinkTable
{
    tLinkTableNode *pHead;
    tLinkTableNode *pTail;
    int			SumOfNode;
    pthread_mutex_t mutex;//信号量
};
//信号量的初始化与销毁
pthread_mutex_init(&(pLinkTable->mutex), NULL);
//...dosomething
pthread_mutex_destroy(&(pLinkTable->mutex));

//上锁与解锁
pthread_mutex_lock(&(pLinkTable->mutex));
//...此处为对链表的操作,如增加节点与删除节点
pthread_mutex_unlock(&(pLinkTable->mutex));

四. 总结

通过此次作业,结合孟宁老师给予的资料更加深刻理解了模块化设计、可重用接口、线程安全等相关知识,由于没接触过回调函数,对这块知识有了极大的收获。

本文暂时没有评论,来添加一个吧(●'◡'●)

欢迎 发表评论:

最近发表
标签列表