 |
|
An architecture for designing reusable embedded systems software, Part 1By Dinu P. Madau, Visteon Corporation Embedded.com (05/01/08, 12:00:00 AM EDT) Want to make your application software more reusable? Don't change the hardware, operating system, or your tools. Instead change the architectural framework within which you do your design. The drive to reduce product development cycle times has led to the need for designing reusable code. It's apparent that reusing code across software projects decreases project development time. Nonetheless, software engineers often resist developing reusable code because they're burdened by time-to-delivery commitments. From design to documentation, reusable code requires that project managers assign additional resources up front. Project managers must decide whether to initially spend the extra effort in designing reusable software modules, which would benefit the long term, or to first quickly design the software to meet their clients' deadlines and later rework the modules to be reusable. In an effort to reduce the development time of designing reusable software, adopting an architectural template that can be applied from project to project would be beneficial. The template would define hardware-independent reusable modules and an interface layer that is hardware dependent--changing when the hardware in the system changes. By applying the architecture template consistently across several program platforms, the goal would be to decrease the development time from one project to another while improving the maintainability of the software product. Let's start off by viewing the overall system as an object that is partitioned into several smaller objects or layers. Some of these objects are written to be reusable while others, by design, are dependent on the hardware and have to change when the hardware changes. We can divide the system into four distinct layers as shown in Figure 1. The perceived system behavior, the outermost layer of the system, is where the users expect a certain behavior, typically defined in a functional requirements document. For example, when someone pushes the call button for an elevator, they expect that within some reasonable amount of time the elevator door will open allowing the person to enter and choose a desired floor.
|
| |||||||||||||||
