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.

CREATIONAL DESIGN PATTERNS IN DETAILED DESIGN AND DESIGN LOGIC PATTERNS

Software Design Patterns

Abstract Factory

Definition

The abstract factory pattern is a creational design software pattern that provides a means to encapsulate a group of individual factories or units sharing common characteristics but without specifying actual classes. A factory is location of real class in the code where objects are constructed.

Problem

Abstract factory class declares only interface for creating products whereas it is the task of concrete product class to actually create products. This might cause concrete factory to override existing factory methods.

Benefit

The pattern may be used to insulate object creation from their current usage and further create families of related objects without depending on actual classes. The benefit from this is that it allows creation of new derived types without requiring any changes to code that use base class.

Factory Method

Definition

Factory method is a popular creational design pattern in object-oriented programming and it helps to put into practice the concept of factories. The design pattern may be specifically used to deal with problem of object creation without specifying exact number of object classes that would be created. This method is used when object creation and reuse becomes impossible without duplication of code (Otero, pp.188-189).

Problem

  • Refactoring of existing classes of using factories breaks changes existing clients.
  • This pattern relies on private constructor that limits extension of class and
  • Inherited constructors are required to be invoked by sub-classes which cannot be done if constructor is private

Benefit

  • The essence of this pattern is to define interface an object by letting the interface decide which class needs to be instantiated
  • They are common in frameworks and toolkits where objects are created using library codes which may further be sub-classed

Builder

Definition

It is a popular object creation software design pattern that aims to find solution to telescopic constructor anti pattern. This phenomenon of anti-pattern occurs when increase of constructor object parameter leads to list of exponential constructors. Thus, instead of using frequent constructors the builder pattern uses another builder object that takes initialization parameter sequentially returns resultant output object at once.

Problem

  • It is difficult to differentiate between builder class and abstract factory class patterns as they are practically very similar
  • It requires common interface for products belonging to common classes

Benefit

  • It is useful when system requires allowing different representations for objects that are being created
  • It is also applicable when object creation algorithm is complex and independent from its constituent parts

Prototype

Definition

It is a creational design pattern in the field of software development that is popularly used when object type is determined from prototype instance cloned for producing new objects. Abstract classes are required to implement this pattern that uses pure virtual clone method (Otero, pp.201-203).

Problem

  • Using a lot of prototypes that are dynamically created and destroys requires creation of registry called prototype manager
  • Initialization and implementation of clone operations may be complex in certain situations

Benefit

  • It is beneficial when sub-classes of object creator can be avoided in client application
  • It is useful when inherent cost of creating new object is expensive to implement a given application

Singleton

Definition

In software engineering, this design pattern restricts classes to be instantiated to objects. The pattern is very useful when one object needs to coordinate actions across system. The pattern generalizes systems that operates more efficiently with single object and restricts instantiation up to limited number of objects.

Problems

  • Multi-threading use must be carefully synchronized for robust application implementation
  • Serialization interface have to be implemented using read resolve method to avoid having multiple objects

Benefits

  • Protected constructor may be used to permit subclasses
  • Provides a global access point to objects

Domain Logic Pattern

Transaction Script

Definition

It organizes business logic by particular routines handling single request from presentation layer and is the most common way of writing applications for beginners. Language semantics can be used to identify and express tasks and common routines may be broken into sub-routines. Transcripts are generally organized as global functions or classes.

Problems

  • Procedural programming code
  • It is best suited for simple business logic scenarios where business logic is straight forward

Benefits

  • A single file may contain multiple transcripts at once
  • It is simple procedural model and very easy to understand

Domain Model

Definition

They help to organize domain logic into well defined entities containing both data and behavior. Conceptually each entity class represents single entity in data layer and this model creates hierarchy of inter-related objects that can interact by triggering behavior.

Problems

  • Requires focusing on behaviors of entities instead of regular routines
  • It does not work effectively with relational databases

Benefits

  • Enables full power OOP concept
  • Handles domain complexities more efficiently compared to transaction scripts

Table Module

Definition

It is a database centric approach where all business logic is organized in the region of database tables. It is very useful when application uses tabular data frequently such as SQL call and hence useful for flexible database architectures.

Problems

  • It may include queries as factory methods using Table Data Gateway class
  • Table module may be instance or static method

Benefits

  • A single class can be used to encapsulate all domain logic for all view or table
  • Implementation is relatively simple since data translation is not required

Service Layer

Definition

This pattern is applied with service oriented design approach that aims to organize services within service inventory of logical layer sets. The services are categorized in a particular layer on the basis of functionality.

Problems

  • It should not be used when business logic of service layer has single client
  • Adding an interface or service layer is time consuming

Benefits

  • Defines common application operation sets for different clients and further coordinates each response
  • Helps to reduce conceptual overheads
  • Helps to manage service inventory belonging to same layer

 


Works Cited

  • Fowler, Martin. Patterns of Enterprise Application Architecture. United States: Pearson Education Inc, 2012. Print.
  • Otero, Carlos. Software Engineering Design: Theory and Practice. United States: CRC Press, 2012. Print.

Architectural Design Patterns

 

Layered Pattern

Context

  • Grouping of associated functionality in an application into separate layers that are placed vertically on top of one another.

Problem

  • Components in a layer can only interact with those in an identical layer or with those from the layers directly below it.

Solution

  • Layering the application adequately to sustain a stout separation of concerns that, consequently, promotes maintainability and flexibility (Taylor, Medvidović and Dashofy 31).

 

 

Broker Pattern

Context

  • A system which is made up of several remote objects which network asynchronously or synchronously.
  • A heterogeneous environment.

Problem

  • Scalability is lessened.
  • Inbuilt networking complications, for example, partial failures.
  • There is need of having significant changeability, maintainability, and flexibility when creating applications.

Solution

  • Split system communication functionality from the foremost application functionality by offering a broker that separates communication-associated issues (Taylor, Medvidović and Dashofy 37).

Model-View-Controller Pattern

Context

  • Retrieving data from a data store and exhibit if for the user.

Problem

  • How to modularize the user interface functionality of an application so as to modify the individual part in an easy way.

Solution

  • Separating the modeling of the actions, presentation, and domain based on user input into three distinct classes of model, view, and controller (Taylor, Medvidović and Dashofy 44).

 

Pipe-And-Filter Pattern

Context

  • Made up of programs that should process a stream of information.

Problem

  • If two steps are not bordering, then they will not share information.
  • Various sources of input data should exist.

Solution

  • Enable the concurrent execution of filters.
  • Split the task into a series of processing stages.
  • Connect the input to the sequence to a source of data (Taylor, Medvidović and Dashofy 58).

 

Client-Server Pattern

Context

  • Distributed systems which involve a distinct server and client system and a connecting network.

Problem

  • The computers should have a conventional language and abide by the rules for both server and client to know what to expect during communication.

Solution

  • Clients initiating communication sessions with servers which wait for arriving requests (Taylor, Medvidović and Dashofy 67).

Peer-To-Peer Pattern

Context

  • Where special nodes in the network function as both consumers and suppliers of resources.

Problem

  • Its applications may have vulnerabilities. 

Solution

  • Sharing between several interconnected peers who directly contribute a part of their resources to various network participants without a centralized synchronization by servers (Taylor, Medvidović and Dashofy 72).

Service-Oriented Architecture Pattern

Context

  • Services are joined by other software applications that offer the full functionality of a large software application.

Problem

  • How to use a procedure in a different application.
  • How to transfer data between services.

Solution

  • Employ an event message for asynchronous, reliable event notification among applications.
  • Utilize a command message to efficiently invoke a process in a different application (Taylor, Medvidović and Dashofy 81).

 

Publish-Subscribe Pattern

Context

  • Integration architecture made up of different applications.

Problem

  • Determining how an application in an integration architecture can solely send applications that are interested in getting the messages without the characters of the receivers.

Solution

  • Broaden the communication infrastructure by developing topics.
  • Allow listening applications to support specified messages (Taylor, Medvidović and Dashofy 86).

 

Shared-Data Pattern

Context

  • Where the system is perceived as a constant, shared data store that is modified and accessed by several elements.

Problem

  • In sequential architecture the only way to share information between the components is to pass the data along with the invocation, which may be insufficient for significant data sets.

Solution

  • Utilize shared repository to provide adequate means for accessing information (Taylor, Medvidović and Dashofy 89).

 

Map-Reduce Pattern

Context

  • In processing significant data sets with a distributed, parallel algorithm on a cluster.

Problem

  • Its interface is extremely low-level.
  • Low-level record management.

Solution

  • Processing information near or on the storage to lessen data transmission (Taylor, Medvidović and Dashofy 94).

Multi-Tier Pattern

Context

  • Where application processing, presentation, and data management duties are logically split.

Problem

  • It is a moderately conceptual style because numerous aspects are not particularized in detail.

Solution

  • Segregating an application into tiers.
  • Use N-tier application to develop reusable and flexible applications (Taylor, Medvidović and Dashofy 89).

 

Work Cited

Taylor, R. N., Medvidović, N., and Dashofy, E. M. Software Architecture: Foundations, Theory   and Practice. New York: Wiley, 2009. Print.