Design - Who needs an architect?

Fowler, Martin

doi:10.1109/ms.2003.1231144

Cited by 99 publications

(54 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…We began this chapter by referring to a software architecture definition as proposed in (Fowler 2003) and (Klusener et al 2005): Architectures are those things that people perceive as hard to change. This definition illuminates the importance of quality attributes because they shape the early design decisions, which in many cases are expensive (hard) to change in subsequent development phases.…”

Section: Discussionmentioning

confidence: 99%

See 1 more Smart Citation

Software Quality Attribute Analysis by Architecture Reconstruction (SQUA3RE)

Störmer

2007

11th European Conference on Software Maintenance and Reengineering (CSMR'07)

View full text Add to dashboard Cite

Section: Discussionmentioning

confidence: 99%

“…In an IEEE Software column, Martin Fowler wonders why people would feel the need to get some things right early in the project (Fowler 2003). This is Fowler's answer including a definition of software architecture (that was independently also proposed in (Klusener et al 2005))…”

Section: Rationale For Software Architecturesmentioning

confidence: 99%

Software Quality Attribute Analysis by Architecture Reconstruction (SQUA3RE)

Störmer

2007

11th European Conference on Software Maintenance and Reengineering (CSMR'07)

View full text Add to dashboard Cite

“…Pushing complexity out of a class may increase overall systemic complexity-which is less visible: BI'd rather have a more complex class than one that removes some of the real complexity^. This raises the fundamental question of what constitutes a 'good' decomposition for a particular problem: BWe do not know what should be the aspects that need separating, and we do not know when it is worth separating them and when it is not^ (Fowler 2003).…”

Section: Design Practices-complexitymentioning

confidence: 99%

Recognising object-oriented software design quality: a practitioner-based questionnaire survey

Stevenson

Wood

2017

Software Qual J

View full text Add to dashboard Cite

Design quality is vital if software is to be maintainable. What practices do developers actually use to achieve design quality in their day-to-day work and which of these do they find most useful? To discover the extent to which practitioners concern themselves with object-oriented design quality and the approaches used when determining quality in practice, a questionnaire survey of 102 software practitioners, approximately half from the UK and the remainder from elsewhere around the world was used. Individual and peer experience are major contributors to design quality. Classic design guidelines, well-known lower level practices, tools and metrics all can also contribute positively to design quality. There is a potential relationship between testing practices and design quality. Inexperience, time pressures, novel problems, novel technology, and imprecise or changing requirements may have a negative impact on quality. Respondents with most experience are more confident in their design decisions, place more value on reviews by team leads and are more likely to rate design quality as very important. For practitioners, these results identify the techniques and tools that other practitioners find effective. For researchers, the results highlight a need for more work investigating the role of experience in the design process and the contribution experience makes to quality. There is also the potential for more in-depth studies of how practitioners are actually using design guidance, including Clean Code. Lastly, the potential relationship between testing practices and design quality merits further investigation.

show abstract

“…. ] contain complexity by reducing irreversibility" [26]. Turning a Java program into an ArchJava program is an irreversible transformation.…”

Section: Hints For Language and Tool Designersmentioning

confidence: 99%

A case study in re-engineering to enforce architectural control flow and data sharing

Abi-Antoun

Aldrich

Coelho

2007

Journal of Systems and Software

View full text Add to dashboard Cite

Without rigorous software development and maintenance, software tends to lose its original architectural structure and become difficult to understand and modify. ArchJava, a recently proposed programming language which embeds a componentand-connector architectural specification within Java implementation code, offers the promise of preventing the loss of architectural structure. AliasJava, which can be used in conjunction with ArchJava, is an annotation system that extends Java to express how data is confined within, passed among, or shared between components and objects in a software system.We describe a case study in which we incrementally re-engineer an existing Java implementation to obtain an implementation which enforces the architectural control flow and data sharing. Building on results from similar case studies, we chose an application consisting of over 16,000 source lines of Java code and over 90 classes. We describe our process, the detailed steps involved (some of which can be automated), as well as some lessons learned and perceived limitations with the languages, techniques and tools we used.

show abstract

Design - Who needs an architect?

Cited by 99 publications

References 0 publications

Software Quality Attribute Analysis by Architecture Reconstruction (SQUA3RE)

Software Quality Attribute Analysis by Architecture Reconstruction (SQUA3RE)

Recognising object-oriented software design quality: a practitioner-based questionnaire survey

A case study in re-engineering to enforce architectural control flow and data sharing

Contact Info

Product

Resources

About