Welcome to the Software Architect archives. The posts are listed in chronological order. Click the post title to read more.
Overview of Design Patterns
– Sponsored Ads —
The concept of patterns was first introduced by Christopher Alexander in his work The Timeless Way of Building (1977). His patterns were originally aimed to capture knowledge and experience for designing and constructing buildings. Alexander noticed that all good architecture designs share a set of successful solutions. He [...]
Here we will look at what a design pattern means, the difference between design pattern and idiom
What Is a Pattern?
A pattern describes a problem that frequently occurs in software design and implementation, Based on experience, describes the solution to that problem that is robust and reusable. In short, Design Patterns are introduced to document [...]
The following UML diagrams provide multiple viewpoints of the system under development.
Use Case Diagrams
Use case defines the scenarios in which the system is used. The inputs and possible outcomes of the system
Analyst uses use case diagram to represent possible usages of the application
We can also see the relationships among the use cases and understand the [...]
When creating your architecture you should explicitly use principles axioms and analogies to guide the creation. This gives the architecture a number of benefits that are not present if you simply create by implicitly leveraging your experience opinions and tastes.
Documenting your architecture will be easier. You can start by describing the principles that were followed. [...]
One of the problems of the fresh programmers today is that they get to hear a lot of contradictions, from equally credible people, on various topics in programming. One such controversial topic is use of GoF Design Patterns, especially the ones talked about in the book by GoF. This puts these programmers in a dilemma [...]
As an architect, it’s tempting to create elaborate designs and abstractions that elegantly address the problem at hand. It is even more tempting to sprinkle new technologies into the project. At the end of the day, someone has to implement your design, and the architectural acrobatics that you have the developers perform impact the project.
When [...]
As you work in requirements meetings to design software pretend that your customer is not your customer. It turns out that this is a very easy thing to do because it is true.
Your customer is not your customer. Your customer’s customer is your customer. If your customer’s customer wins your customer wins. Which means you [...]