Principles of Detail Design

Design is the process of creativity that allows for solutions to implementing all of the customer’s requirements; and thus is the resulting plan. This paper will explore the principles of design and with a focus on the development of the requirements (the details on what the consumers want the system to do) and the corresponding translation into a design (a depiction of a system that will fulfil the clients’ requirements).

Detailed design as explained by IEEE is is the act of making improvements on already designed software so as to make it suit the intended purpose (34). In the process of detailed design, designers thoroughly explore each element in order to define the core structure and behavioural capabilities of the software that would result in the construction of efficient and natural software.  Clements et al differentiate architectural design from detailed design in a uniquely interesting way. He alluded that architecture could be defined as a form of design yet the reverse was not possible. The interpretation is that design is not within the realms of architecture since the end of any masterpiece can be manipulative.  There is a close relation between detailed design, architecture and construction. From this, designers aiming for success in detailed design are obligated to have or obtain full understanding of the requirements and architecture of the system. Proficiency in particular design strategies such as object-oriented, programming languages, and methods and processes for software quality control becomes a requirement. Detailed design acts as a bridge between design and code in the same way that architecture provides a link between requirements and design.

When it comes to implementation, it can be debated that most problem solving activities occur in the detailed design phase. This can be demonstrated in the case where a formal process is followed, and the requirements are met by the detailed design and architecture. In numerous real-world applications, intricate problem solving is deferred by the architectural design activity to the detailed design, predominantly through abstraction. In some instances, specifying requirements is also submitted to detailed design. In view of these reasons, detailed design has to assume the role of gatekeeper to ensure that the specification and design of the system are sufficiently completed even before construction begins. This can be particularly hard for large-scale systems built from scratch devoid of experience with the development of systems that are alike. Tasks such as understanding the requirements and architecture, documenting software design, evaluating detailed designs, monitoring and controlling implementation, and creating detailed designs, become major factors in implementing detailed design activity.

 

In contrast to software architecture, where the comprehensive set of conditions are assessed and well understood, detailed design activity calls for designers to focus on the requirements assigned to their explicit components. After understanding the architecture and requirements for allocated components, is when the detailed design of software modules can begin. The components of detailed design include both behavioral and structural designs. This is demonstrated by the focus on interface design (which includes internal interface design and external interface design), graphical user interface design-which could be an extension of the designs started during architecture, and internal component design (both structural and behavioral), and data design.

The Open-Closed principle (OCP) is a crucial principle for creating recyclable and adjustable systems that advance gracefully with time. The key idea behind the OCP is that working code should remain untouched and any new additions should come as extensions of the original work. This does not mean that designs modification cannot occur; it means they should be done by incorporating new code in the system without requiring the old code to be changed. Barbara Liskov originally proposed the LSP and it functions as a basis for constructing designs that permit clients written against derived classes to act as they would if they were written using the equivalent base classes (Otero). The LSP necessitates signatures between derived and base classes be upheld, and reasoning be supported by subtype specifications based on the super type requirement. The interface segregation principle (ISP) requires clients should not be obligated to be contingent on methods that they do not use. This follows that there should be only one reason for change in well-designed classes.

Conclusion

There should be a clear understanding of want the client requirements are in terms of software specifications even before the design process begins. This will serve to ensure that what is produced is actually what the client wants, and therefore allowing for efforts to be channeled towards creation instead of persistent corrections and modifications.

Work Cited

  • Otero, Carlos E. Software engineering design. CRC Press, 2012.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>