Thoughts on Coupling in Software Design

Coupling is a software metric that describes how closely connected two routines or modules are. It is a measure of quality. The concept was introduced by Larry Constantine in the 1960s and was formulated in a 1974 article for the IBM Systems Journal, Structured Design, and in the 1979 book by the same name.

Having modules A and B, the more knowledge about B is required in order to understand A, the more closely connected is A to B. The fact that one module needs to be inspected in order to understand the operation of another is an indication of a degree of interconnection, even if the degree of interconnection is not known.

Coupling is a measure of the strength of that interconnection. Coupling is affected by the type of connections between modules, interface complexity, information flow between module connections, and binding time of module connections. Coupling is usually contrasted with cohesion, e.g., low coupling translates into high cohesion and vice-versa.

Levels of Coupling

Coupling can be low / loose / weak or high / tight / strong.

Tight coupling translates into ripple effects when making changes, as well as code that is difficult to understand. It tends to propagate errors across modules, when one module behaves incorrectly. It tends to complicate debugging and fixing defects.

In loosely coupled systems, on the other hand, individual modules can be studied and altered without the need of taking into account a lot of information from other modules. Errors can be pointed out much more easily. Debugging takes less time, while fixing defects is usually simpler. The chances of error propagation across modules tend to be reduced.

The levels of coupling below are ordered from high to low:

Content Coupling: Content coupling, or pathological coupling, occurs when one module modifies or relies on the internal workings of another module. Changing the inner working will lead to the need of changing the dependent module. An example would be a search method that adds an object which is not found to the internal structure of the data structure used to hold information.

Common Coupling: Global coupling, or common coupling, occurs when two or more functions share global data. Any changes to them have a ripple effect. An example of global coupling would be global information status regarding an operation, with the multiple modules reading and writing to that location.

Control Coupling: Control coupling occurs when one module controls the flow of another by passing control information, e.g., a control flag, a comparison function passed to a sort algorithm.

Stamp Coupling: Stamp coupling, or data structure coupling, occurs when modules share a composite data structure and use only a part of it, possibly different parts. One example is of a print module that accepts an Entity, and retrieves its information to construct a message.

Data Coupling: Data coupling occurs when methods share data, regularly through parameters. Data coupling is better than stamp coupling, because the module takes exactly what it needs, without the need of it knowing the structure of a particular data structure.

Message Coupling: Message coupling is the lowest form of coupling, realized with decentralization and message passing. Examples include Dependency Injection and Observables.

Coupling Metrics Class Level

Class level coupling results from implementation dependencies in a system. In general, the more assumptions are made by one class about another, the tighter the coupling.

The strength of coupling is given by the stability of a class, i.e., the amount of changes in dependant classes that need be made if a class changes, and the scope of access, i.e., the scope in which a class is accessed, with the higher scope introducing tighter coupling. At class level, the degree of coupling is measured as the ratio of number of messages passed to the number of messages received, i.e.,

DC = MRC / MPC

where MRC is the received message coupling (the number of messages received by a class from other classes), and MPC is the passed message coupling (the number of messages sent by a class to other classes).

Class level is a particular case of the Module level metric.

Module Level

A more general metric, this metric tracks other modules, global data, and outside environment. The formula computes a module indicator mc, where

mc = k / M

With k a proportionality constant and M a value calculated by the following formula:

M = di + (a * ci) + d0 + (b * c0) + gd + c * gc) + w + r

In the formula above:

a, b, and c are defined empirically

w – the number of modules called (fan out) – and r – the number of modules calling the module under consideration (fan-in) are environmental coupling parameters

gd and gc, describing the number of global variables used as data and as control, are global coupling parameters

di, do, ci, and co, describing the number of data and control input and output parameters, are data and control flow parameters

One important note to be made is that as the value of mc increases, the overall coupling decreases. In order to have the coupling move upward as the degree of coupling increases, a revised coupling metric, C, might be defined as:

C = 1 - mc

Decoupling

Introducing coupling increases the instability of a system. Decoupling is the systematic coupling reduction between modules with the explicit intent of making them more independent, i.e., minimizing the value of C, as defined in the previous section.

Content coupling can be eliminated by following encapsulation.

Common coupling can be resolved by introducing abstractions. Design patterns could prove useful towards achieving a good architecture.

External coupling can be resolved by eliminating the knowledge of formats from the domain, and operating on concepts.

Control coupling can be eliminated by using strategies or states.

Stamp coupling can be eliminated by passing actual data.

Data coupling can be eliminated by employing message passing.

One very important principle to guide by in reducing coupling is the Law of Demeter, presented below.

Law of Demeter

Also referred to as the principle of least knowledge, the Law of Demeter is a specific case of loose coupling. The principle states that a unit should only have knowledge of and talk to closely-related units, assuming as little as possible about the structures and properties of anything it interacts with, including its own subcomponents. For example, an object A could call functionality on object B, but should not reach through B to access an object C for its functionality. Instead, object B should facilitate access through its own interface, propagating the request to its subcomponents. Alternatively, A could have a direct reference to C.

A more formal definition states that a method M on an object O can invoke the methods of the following objects:

O

M's parameters

Any objects created / instantiated within M

O's direct subcomponents

A global variable, accessible by O, in the scope of M

In particular, an object should not call a method on a returned object, i.e., there should be at most one dot in code, e.g., a.Method(), and not a.B.Method().

Conclusions

Coupling is unavoidable; otherwise each module would be its own program. However, achieving low coupling should be one of the primary objectives in system design, such that individual modules can be studied and altered without the need of taking into account a lot of information from other modules, errors can be pointed out much more easily, and debugging takes less time, while fixing defects is usually simpler.

Loose coupling leads to high cohesion, and together they lead to maintainable systems.

References
Source: Thoughts on Coupling in Software Design

JM2 Webdesigners Expands and Creates a Corporate Office in Valparaiso, Indiana

VALPARAISO, Ind., Aug. 2, 2016 /PRNewswire/ -- Today, JM2 Webdesigners CEO John Marx unveiled "Project Coffee Pot." This project has been in the works since March 2016 when demand to serve customers was starting to require more space. The overall goal of the company was to only stay in the Zoseco Co-working space for two years. JM2 Webdesigners felt that if they stayed any longer they would be hindering other individuals that wanted to move into the business world on their own.

Logo - http://photos.prnewswire.com/prnh/20160802/395132LOGO

"We are taking some bold steps to grow and help small businesses focus on their businesses while JM2 Webdesigners helps these businesses with their digital marketing needs," Marx said. This move will give room for growth for individualized on premise seminars, a dedicated photography room, and grow the Find Business Directory at http://FindBiz.Directory/ to name just a few. The Find Business Directory is a free business listing service for any business large or small.

JM2 Webdesigners will move into a 2,000+ square feet at 403 East Lincolnway, Valparaiso, IN  46383. This move comes after careful study and review of the company's future operating needs in light of its growth prospects.

JM2 Webdesigners is a leading provider of web design, graphic design, and custom software development for all industries that need to improve their business processes. JM2 Webdesigners products and solutions enable businesses to efficiently manage their online digital marketing needs. If you would like more information about this topic, please contact John Marx at 855-456-2669 or email at john@jm2.biz.

Related Files

press-corporate-office-20160729.pdf

This content was issued through the press release distribution service at Newswire.com. For more info visit: http://www.newswire.com

To view the original version on PR Newswire, visit:http://www.prnewswire.com/news-releases/jm2-webdesigners-expands-and-creates-a-corporate-office-in-valparaiso-indiana-300308064.html

SOURCE JM2 Webdesigners

Related Links

http://www.jm2.biz

Source: JM2 Webdesigners Expands and Creates a Corporate Office in Valparaiso, Indiana

Thoughts on Coupling in Software Design

Coupling is a software metric that describes how closely connected two routines or modules are. It is a measure of quality. The concept was introduced by Larry Constantine in the 1960s and was formulated in a 1974 article for the IBM Systems Journal, Structured Design, and in the 1979 book by the same name.

Having modules A and B, the more knowledge about B is required in order to understand A, the more closely connected is A to B. The fact that one module needs to be inspected in order to understand the operation of another is an indication of a degree of interconnection, even if the degree of interconnection is not known.

Coupling is a measure of the strength of that interconnection. Coupling is affected by the type of connections between modules, interface complexity, information flow between module connections, and binding time of module connections. Coupling is usually contrasted with cohesion, e.g., low coupling translates into high cohesion and vice-versa.

Levels of Coupling

Coupling can be low / loose / weak or high / tight / strong.

Tight coupling translates into ripple effects when making changes, as well as code that is difficult to understand. It tends to propagate errors across modules, when one module behaves incorrectly. It tends to complicate debugging and fixing defects.

In loosely coupled systems, on the other hand, individual modules can be studied and altered without the need of taking into account a lot of information from other modules. Errors can be pointed out much more easily. Debugging takes less time, while fixing defects is usually simpler. The chances of error propagation across modules tend to be reduced.

The levels of coupling below are ordered from high to low:

Content Coupling: Content coupling, or pathological coupling, occurs when one module modifies or relies on the internal workings of another module. Changing the inner working will lead to the need of changing the dependent module. An example would be a search method that adds an object which is not found to the internal structure of the data structure used to hold information.

Common Coupling: Global coupling, or common coupling, occurs when two or more functions share global data. Any changes to them have a ripple effect. An example of global coupling would be global information status regarding an operation, with the multiple modules reading and writing to that location.

Control Coupling: Control coupling occurs when one module controls the flow of another by passing control information, e.g., a control flag, a comparison function passed to a sort algorithm.

Stamp Coupling: Stamp coupling, or data structure coupling, occurs when modules share a composite data structure and use only a part of it, possibly different parts. One example is of a print module that accepts an Entity, and retrieves its information to construct a message.

Data Coupling: Data coupling occurs when methods share data, regularly through parameters. Data coupling is better than stamp coupling, because the module takes exactly what it needs, without the need of it knowing the structure of a particular data structure.

Message Coupling: Message coupling is the lowest form of coupling, realized with decentralization and message passing. Examples include Dependency Injection and Observables.

Coupling Metrics Class Level

Class level coupling results from implementation dependencies in a system. In general, the more assumptions are made by one class about another, the tighter the coupling.

The strength of coupling is given by the stability of a class, i.e., the amount of changes in dependant classes that need be made if a class changes, and the scope of access, i.e., the scope in which a class is accessed, with the higher scope introducing tighter coupling. At class level, the degree of coupling is measured as the ratio of number of messages passed to the number of messages received, i.e.,

DC = MRC / MPC

where MRC is the received message coupling (the number of messages received by a class from other classes), and MPC is the passed message coupling (the number of messages sent by a class to other classes).

Class level is a particular case of the Module level metric.

Module Level

A more general metric, this metric tracks other modules, global data, and outside environment. The formula computes a module indicator mc, where

mc = k / M

With k a proportionality constant and M a value calculated by the following formula:

M = di + (a * ci) + d0 + (b * c0) + gd + c * gc) + w + r

In the formula above:

a, b, and c are defined empirically

w – the number of modules called (fan out) – and r – the number of modules calling the module under consideration (fan-in) are environmental coupling parameters

gd and gc, describing the number of global variables used as data and as control, are global coupling parameters

di, do, ci, and co, describing the number of data and control input and output parameters, are data and control flow parameters

One important note to be made is that as the value of mc increases, the overall coupling decreases. In order to have the coupling move upward as the degree of coupling increases, a revised coupling metric, C, might be defined as:

C = 1 - mc

Decoupling

Introducing coupling increases the instability of a system. Decoupling is the systematic coupling reduction between modules with the explicit intent of making them more independent, i.e., minimizing the value of C, as defined in the previous section.

Content coupling can be eliminated by following encapsulation.

Common coupling can be resolved by introducing abstractions. Design patterns could prove useful towards achieving a good architecture.

External coupling can be resolved by eliminating the knowledge of formats from the domain, and operating on concepts.

Control coupling can be eliminated by using strategies or states.

Stamp coupling can be eliminated by passing actual data.

Data coupling can be eliminated by employing message passing.

One very important principle to guide by in reducing coupling is the Law of Demeter, presented below.

Law of Demeter

Also referred to as the principle of least knowledge, the Law of Demeter is a specific case of loose coupling. The principle states that a unit should only have knowledge of and talk to closely-related units, assuming as little as possible about the structures and properties of anything it interacts with, including its own subcomponents. For example, an object A could call functionality on object B, but should not reach through B to access an object C for its functionality. Instead, object B should facilitate access through its own interface, propagating the request to its subcomponents. Alternatively, A could have a direct reference to C.

A more formal definition states that a method M on an object O can invoke the methods of the following objects:

O

M's parameters

Any objects created / instantiated within M

O's direct subcomponents

A global variable, accessible by O, in the scope of M

In particular, an object should not call a method on a returned object, i.e., there should be at most one dot in code, e.g., a.Method(), and not a.B.Method().

Conclusions

Coupling is unavoidable; otherwise each module would be its own program. However, achieving low coupling should be one of the primary objectives in system design, such that individual modules can be studied and altered without the need of taking into account a lot of information from other modules, errors can be pointed out much more easily, and debugging takes less time, while fixing defects is usually simpler.

Loose coupling leads to high cohesion, and together they lead to maintainable systems.

References
Source: Thoughts on Coupling in Software Design

Design Composites in the Cloud

CompoSIDE Ltd., a developer of engineering simulation and data management solutions based in the U.K., has released v2.8.2 of its web-based CompoSIDE composite design and analysis software. A subscription-based service, CompoSIDE v2.8.2, says the company, significantly improves the development cycles for composites parts and products.

CompoSIDE Ltd. has released version 2.8.2 of its CompoSIDE integrated suite of web-based design, analysis and data management tools for composites design and as well as applications using metal and other materials such as wood and plastics. Image courtesy of CompoSIDE Ltd.

Core CompoSIDE functionality modules provide toolsets for composites materials management, laminate calculation, beam section design and 3D FEA (finite element analysis) modeling with integrated reporting and BOM (bill of materials) generation. A management module, PROJECTSpace integrates the interlinked 2D/3D design and engineering tools, the materials database and other modules. Add-ons include YACHTScant, which integrates functionality specifically for vessel creation, and an FE (finite element) export module.

CompoSIDE's Materials Database (CMDB) acts as a central repository for all materials and provides tools for managing materials data, physical and mechanical properties, ply generation and micro-mechanics. It supports material types such as adhesives, cores, fibers, matrix and plies as well as non-composite materials such as metals, woods, plywood and plastics. A CompoSIDE subscription comes with a basic set of materials that you can expand with your own project specific data.

CompoSIDE provides centralized, cloud-based data management, enabling users to store composites project data such as design, materials, standards, BOMs (bill of materials), drawings and reports in a single secured location. Image courtesy of CompoSIDE Ltd.

The CompoSIDE CMDB features company-wide and project-specific libraries to help evaluate and develop new materials and plies. At the project level, users can develop new materials data, estimate new performances and fine-tune existing data. CompoSIDE v2.8.2 introduces the "Materials Data Manager" role with dedicated rights within the organization to approve and publish new materials across the company-wide library of materials.

CompoSIDE's BOM generation tool automatically produces bill of materials including weight and cost estimates, says the company. Users can also generate BOMs manually and make modifications and additions. CompoSIDE links design modules and BOMs dynamically, enabling users to update and review the effects of design decisions on BOMs and costs.

CompoSIDE provides users an integrated reporting engine that include such features as revision/version control, customizable templates and URL sharing. Image courtesy of CompoSIDE Ltd.

The integrated reporting engine provides such features as reporting wizards, customizable templates, URL sharing, quality features like issue and revision/version control as well as the ability to generate project documentation automatically. Automated project documentation output includes design data, deliverables required for manufacturing, materials data sheets, BOMs and project reports. An advanced editing tool lets users edit or add commentary and insert additional content before distributing project deliverables.

CompoSIDE v2.8.2 also introduces a Desktop Client for 2D/3D modeling and FEA that, says the company, provides improved performance and response time for large and complex models. The Desktop Client combines local computational resources for model editing with the performance of HPC (high-performance computing) for running solvers and analysis tasks. Analysis jobs are submitted to the CompoSIDE HPC infrastructure automatically, which relieves the local workstation of the compute-intensive tasks.

Since CompoSIDE integrates data in a centralized, web-accessible location, design, engineering and manufacturing teams can draw on the same source of data and collaborate as well as work on a project simultaneously. Image courtesy of CompoSIDE Ltd.

Miscellaneous features a graphical user interface, a user-defined Wiki module and systems tools for configuring project settings, including safety factors, failure settings, user roles, user permissions, managing subscriptions and monitoring resources.

"CompoSIDE v2.8.2 significantly enhances product development cycles for composites products and parts" said Lorenzo Bossi, sales and marketing manager at CompoSIDE Ltd., in the v2.8.2 release announcement. "The latest release improves materials data management and delivers efficient design workflows for both pure players and new entrants to composites applications."

CompoSIDE is licensed on a quarterly or annual subscription basis with an unlimited number of users. Subscriptions start at $6,250. In addition to the FE export and YACHTScant add-on modules, the company also offers a CMDB materials database add on module containing more than 1,200 materials and over 900 plies. All materials provide full physical and mechanical properties data.

For complete details on CompoSIDE 2.8.2, visit the CompoSIDE website.

Watch a video on the features of CompoSIDE.

Learn more about the CompoSIDE Materials Database.

Learn more about CompoSIDE's laminate design and management module.

Sign up for a 30-day trial of CompoSIDE.

See why DE's editors selected CompoSIDE v2.8.2 as their Pick of the Week.

Sources: Press materials received from the company and additional information gleaned from the company's website.

Source: Design Composites in the Cloud

The Productivity Benefits of Scrum in Modern Web Development

Before the Industrial Revolution, most goods were produced by hand by a single person. Master craftsmen labored over their work, producing a finished product they could be accountable for and proud of.

Mass-production led to the assembly line, in which each person was assigned a step, and their job was to do that step over and over again with the result of many finished products, the reason a car can be built in a single automobile factory assembly line every 20 minutes.

Although it produces a very high output, this causes a much lower sense of accomplishment for the employee – when a worker does one task over and over, they view the result as less worthy than the craftsmen who completed every step involved and thus were responsible for the entire, single object.

There is a product development framework that combines the benefits of these two work processes: a high-quality product, produced efficiently, by a team who takes accountability and pride in their work. This process is called Scrum. Our web software development team has been using Scrum for close to two years, and we're thrilled with the results. Scrum allows us to constantly improve and communicate as a cohesive team. This has allowed us to build more advanced sites and web applications in a shorter period of time.

Scrum: the Beginnings

Scrum as we use it today began at a company called Advanced Development Methods by Ken Schwaber and Jeff Sutherland in the early 90s. Used by companies like IBM and Google, Scrum has increased total productivity by nearly 1,200 percent. Despite its technical background however, Scrum has manifested itself into a variety of workflows from journalism to education to building schools in Africa – Scrum accelerates human effort, no matter what the effort is.

Our web development team is an office of ten, so Scrum for JTech cannot be pure, which is fine because a big part of Scrum is its ability to adapt to the way your team needs it. We had to try and adapt the philosophies illustrated in Sutherland's Book to discover for ourselves what would and wouldn't work for us. However, when we adopted the process, it immediately felt natural. This is because Scrum's integration of goal-setting, team accountability and celebration matches the rhythm of human instinct – our need to strive toward an obtainable goal instead of working one long monotonous assembly line.

Elements of Scrum

Sprints:Sprints are work cycles. We work in a three week Sprint for larger website projects in parallel with one-week Sprints for smaller, ongoing work orders.

Stories:Stories are the way projects are divvied up into small, consumable pieces. Each story is assigned to a team member and moves through a series of columns on a Scrum board: To Do, In Progress, Team Review, Owner Review and Done.

Stand Up:Stand up is one of five meetings that drive a Sprint. This particular meeting is less than 15 minutes long, occurs at 9:00AM every morning and is a time for each team member to discuss a) what they are working on and b) what roadblocks are preventing them from moving a story across the board.

Roles:Everyone on a Scrum team is a team member, except the Scrum Master, who runs the Scrum board, drives meetings and ensures the Sprints are completed on time, and the Product Owner. The Product Owner is the person that created the project and in the best position to understand what the client wants; everything must be approved by them before it is considered Done.

Backlog Meeting:The Sprint Backlog meeting is used to prioritize all stories and prepare them for the upcoming Sprint.

Planning Meeting:The Sprint Planning meeting involves the entire team – we choose which stories to take on during the three and one-week Sprints and to who to assign them, and vote on how long they may take. Voting is based on a Fibonacci sequence, with the numbers representing a relative gauge of work involved.

Review:Sprint Review is a time to review all of the work we've accomplished within the recently completed Sprint. Clients are invited to participate in this review as we demo the new website or web app, walking them through all of its features.

Retrospective:The Retrospective is when the team sits down and discusses what went right, what could have gone better and what goals can be set for the next Sprint.

Scrum at a Development Firm

Since we provide so many different services, Scrum has played a huge role in unifying the departments into one cohesive team. It has sped up our process, allowing us to take on more work, resolve project obstacles and to complete web development projects faster. Although we produce more, our projects are ever increasingly more refined. So, here are the ways in which we've taken the elements of Scrum that were designed for Silicon Valley-sized corporations and applied them to our business in Downtown Bozeman, Montana.

Productivity:Our Scrum software, called Jira, documents and helps keep a high level of productivity among a team. The Scrum board keeps track of all Stories, to whom they're assigned, helps us compare one sprint to another, and even maps our progress visually. It makes it easy to see how well we're doing at the moment and over time.

Team Accountability:Because we have so many departments under one roof – design, development, marketing and copywriting – the Stand Up meeting is a time for cross-departmental communication. No one is working in a metaphorical (or literal) cubicle because although stories are assigned to a single member, we are all equally responsible for completing all stories, ensuring team-wide inclusion. Because of this, designers are involved with marketing plans, developers read copy and writers give feedback on art, creating a holistically-managed assembly line.

Accomplishment:Team members need to see their efforts reflected in the objects they've created. Much as a chef would anticipate a restaurant review or a painter would relish their own art show, we as a team enjoy showing the website we've built to the client for the first time, and discussing its intricacies, which is why Sprint Reviews and Retrospectives are so effective.

Unlike the assembly line worker who feels no personal connection to the car they've produced since their only job was to affix the bumper, in Scrum, even if the homepage of a site was assigned to a single team member, we've all worked on it collectively.

Conclusion

Scrum allows us to produce high-quality work, faster. It encourages cohesiveness among our various departments and makes it easier for us to identify issues, fostering continuous improvement that sustains and drives our process. Most notably though, it allows us to design advanced websites for our customers built for excellent performance of which we can be proud.

In short, whether you're building schools in a third world country, teaching a classroom full of elementary students, or building websites, Scrum is highly effective because it matches many of the instincts that drive human nature; as Sutherland put it in his book, "Happiness is not complacent. It is a process, not a result."

You may also like to learn about Agile Development.

Source: The Productivity Benefits of Scrum in Modern Web Development