Software Architecture
Fleeting- External reference: https://c4model.com/
see C4 model for visualising software architecture.
In short, it should be the
- tourist map (several stakeholders, simple views to help collaboration)
- of the epistemic truth (epistemic modesty, bayesian thinking, we acknowledge that we don’t know yet if it will reach the goal)
- shared by the experts of the project (needs an educated system 1)
- about the decisions (made by the team, for the team)
- that they wish they would have made at the start of the project (its evolutionary, it is not a big upfront design)
The software architecture appears to be hard to define and eventually becomes the stuff that says what should be important1, 2.
It appears to have been define in IEEE 1471-20003.
Here are properties I have found so far in descriptions of software architecture.
- abstract description of the structure and the relationship of entities in a system4, 5, 6, 7, 8, 9, 10, 3, 11, 12, 13,
- along with a set of fundamental structural choices14, 8, 9, 3, 11, 12, 15,
- contains non functional requirements15,
- focuses on the what, not the how16,
- a descriptions of the things of the system that are hard to change8, 9,
- focused on being a single point of communication between several stakeholders see the image above 17, 18, 19,
- becomes an ubiquitous language
- contains some high level intentions of the product to create2,
- important stuff, whatever that is8,
- some conventions about the code9,
- a document explaining how the product to be built will answer the goals (for stakeholders)20, 12, 15,
- a document made by the team and for the team21, 22, 23
- a structured document24
- should be part of the habitus of the software developer25
It is also used in a more specific usage to say only how we organise the code26, 27. I think this is due to the fact people tend to confuse architectural pattern with software architecture. It is to be noted that even the wikipedia page of architectural pattern indicates that it is not the same as architecture28.
It may be composed of several views29, depending on which stakeholder your are aiming at30, 31, 32, 33. Because they are several kinds of stakeholder, the documentation parts must be thought carefully to only bring the meaningful information34, 33, 35.
It is advised to start a project with an simple architecture documentation and curate it along the path of the project36, so that people can always rely on it and be confident the product does not diverges too much from the vision37, 33.
This can only be done if routines are setup to challenge the architecture along with the evolution of the product37. Also, a too detailed documentation wont be updated and will quickly become useless38, 35. People feel a cognitive resistance updating a complicated technical documentation and don’t see the point39, 40 and even rationalize this by not maintaining any documentation41, which is a logical fallacy42. This documentation should be a team effort, therefore the team must agree on it utility and want to curate it43, 44, 40. There appears to be no silver bullet answer to what and how much documentation to write45. For that reason, it relies on the collective gut feeling, therefore and needs decision hygiene and educated system 1 (a.k.a. experienced people).
It is advised to keep it simple and avoid complex stuff like UML. It is realized that team generally create architecture documentation using messy ad hoc techniques, avoiding the rigid modeling of UML, but still trying to document comprehensively anyway46
This has lead Simon Brown to create a simple model for creating diagrams in simple way while being able to address the usual stakeholders. It focus less on notation complexity and more on abstraction47, so that the different point of view are seen as abstraction zoom in and out.
He also suggest to avoid creating much up front design48. He emphasizes that there should still be some architecture work, and people have had the fallacy of believing that agile methods came with no upfront design at all, quoting that big design up front is dumb, but doing no design up front is even dumber.
whole toolbox for software architecture documentation:
- Structure it with arc42
- Describe and visualize it with the C4 model
- Treat your documentation and diagrams like code with AsciiDoc, AsciiDoctor, docToolChain and Structurizr
- …and integrate it into your development workflow.
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
I feel that creating an architecture is like defining what done means and what doing looks like.
software architecture diagram
see C4 model for visualising software architecture.
It seems to be as difficult to grasp as the notion of software architecture itself.
The main properties I can see are,
- holistic view of the software system49, 50, 51, 52, 53,
- should be easy to read so that it is used in collaborations54, 55, 56, 57,
- a mean to discuss with stakeholders and other devs58, 59, 57,
- don’t follow complex semantic60, 61, 53 (they are diagrams after all),
- provides vision and guidance to the dev 57, 53,
There are plenty of different templates of architecture diagrams62, like
Here is a checklist to find out whether the diagram is correctly done.
Using the group keyword I suppose
name “container” was chosen as a generic way to describe something in which components live
unfortunate that containerisation has become popular, because many software developers now associate the term “container” with Docker.
though, there is sometimes a nice parity between a container in the C4 model and an infrastructure (e.g. Docker) container.
Feel free to modify the terminology that you use to describe software architecture at different levels of abstraction. Just make sure that everybody explicitly understands it.
C4 model for visualising software architecture
-
External reference: https://c4model.com/#CoreDiagrams software architecture, by Simon Brown
A description of a software architecture that supposedly better fits the way developers use to write such document47. Due to its simplicity, it is more likely to be kept up-to-date. Yet, it contains powerful enough abstractions to allow conveying what is important for a software architecture: answering what the goal is and how the system is supposed to reach it at several horizons and levels of details so that in suits all sorts of stakeholders.
It is meant to be kept pragmatic and, following the idea of lean, should not contain more than the minimum needed66.
It contains:
The 4C stands for75
- Context,
- Container,
- Component,
- Code (optional)
Level 1: System Context diagram
This level is meant to show the big picture76, with your system surrounded by whatever makes sense to you to better understand it77.
Don’t focus on technical stuff here78. Tell the who and what, not the how.
level 2: container
high-level shape of the software architecture and how responsibilities are distributed across it. It also shows the major technology choices and how the containers communicate with one another. It’s a simple, high-level technology focussed diagram that is useful for software developers and support/operations staff alike.
level 3: component
Component diagram shows how a container is made up of a number of “components”, what each of those components are, their responsibilities and the technology/implementation details
level 4: code
should consider showing only those attributes and methods that allow you to tell the story that you want to tell
wip
System Landscape diagram
high-level map of the software systems at the enterprise level, with a C4 drill-down for each software system of interest. From a practical perspective, a system landscape diagram is really just a system context diagram without a specific focus on a particular software system
Dynamic diagram
similar to a UML sequence diagram although it allows a free-form arrangement of diagram elements with numbered interactions to indicate ordering
Deployment diagram
show the mapping between containers and deployment nodes. A deployment node is something like physical infrastructure (e.g. a physical server or device), virtualised infrastructure (e.g. IaaS, PaaS, a virtual machine), containerised infrastructure (e.g. a Docker container), an execution environment (e.g. a database server, Java EE web/application server, Microsoft IIS), etc. Deployment nodes can be nested.
C4 model doesn’t prescribe any particular notation
simple notation that works well on whiteboards, paper, sticky notes, index cards and a variety of diagraming tools
C4 model was created by Simon Brown
If you’re using UML (or SysML, ArchiMate, etc) and it’s working for you, stick with it. Unfortunately, UML usage seems to be in decline, and many teams have reverted to using ad hoc boxes and lines diagrams once again. Given that many of those teams don’t want to use UML (for various reasons), the C4 model helps introduce some structure and discipline into the way software architecture is communicated. For many teams, the C4 model is sufficient. And for others, perhaps it’s a stepping stone to UML
Feel free to modify the terminology that you use to describe software architecture at different levels of abstraction. Just make sure that everybody explicitly understands it.
don’t be afraid to split that single complex diagram into a larger number of simpler diagrams, each with a specific focus around a business area, functional area, functional grouping, bounded context, use case, user interaction, feature set, etc. The key is to ensure that each of the separate diagrams tells a different part of the same overall story, at the same level of abstraction
Although existing notations such as UML, ArchiMate and SysML already exist, many software development teams don’t seem to use them. Often this is because teams don’t know these notations well enough, perceive them to be too complicated, think they are not compatible with agile approaches or don’t have the required tooling
common misconception is that a team’s design process should follow the levels in the C4 model hierarchy, perhaps with different people on the team being responsible for different levels of diagrams. For example, a business analyst creates the system context diagram, the architect creates the container diagram, while the developers look after the remaining levels of detail.
Although you can certainly use the C4 model in this way, this is not the intended or recommended usage pattern. The C4 model is just a way to describe a software system, from different levels of abstraction, and it implies nothing about the process of delivering software.
Should the lines represent dependencies or data flow? This is your choice
Should you include message buses, API gateways, service meshes, etc?
omit the intermediary, and instead use notation (e.g. a textual description, colour coding, line style, etc) to signify that the interaction between service A and B happens via an intermediary. This approach tends to result in diagrams that tell a clearer story.
C4 model can be used to describe a variety of software architectures (monolithic or distributed), built in a variety of programming languages, deployed on a variety of platforms (on-premises or cloud).
As an industry, we’ve tended to prefer diagramming over modelling, primarily because the barrier to entry is relatively low, and it’s seen as a much simpler task
domain language of diagramming tools is really just boxes and lines
C4 model can be used irrespective of whether you are diagramming or modelling, but there are some interesting opportunities when you progress from diagramming to modelling.
Often, the diagrams themselves aren’t the end-goal, with teams using the diagrams to answer other questions that they have,
software architect
Notes linking here
- agile methods
- architectural pattern
- complicated relation between freedom/liberty and comfort
- diagram
- evolutionary architecture
- Handbook of Software Architecture
- important decisions, as measured by the cost of change
- Simon Brown
- Simon Brown - Software Architecture for Developers
- software architect evolution in growing team
- structurizr
- what software architecture should look like
Permalink
-
↩︎Humm pretty complex…that’s why some people finally conclude that: “Software Architecture is about the important stuff, whatever that is.”
— https://medium.com/@devsenamishra/software-architecture-afba8093a840
-
↩︎ ↩︎There is no sharp distinction between software architecture versus design and requirements engineering (see Related fields below). They are all part of a “chain of intentionality” from high-level intentions to low-level details.
-
↩︎ ↩︎ ↩︎As fully defined by IEEE 1471-2000, software architecture is “the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” This definition reveals what software architecture truly includes
— https://www.designveloper.com/blog/what-is-software-architecture/
-
↩︎Architecture is nothing but an abstract description of entities in a system. It defines the relations between them and involves a series of decision-making processes.The architecture is a vision and a structure.
-
↩︎Software Architecture defines fundamental organization of a system and more simply defines a structured solution. It defines how components of a software system are assembled, their relationship and communication between them. It serves as a blueprint for software application and development basis for developer team.
— https://www.geeksforgeeks.org/fundamentals-of-software-architecture/
-
↩︎Robert C. Martin’s book “Clean Architecture,” where he writes: “the architecture of a software system is the shape given to that system by those who build it. The form of that shape is in the division of that System into components, the arrangement of those components, and the ways in which those components communicate with each other.”
— https://medium.com/@devsenamishra/software-architecture-afba8093a840
-
↩︎Software architecture is the abstract structure of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations
-
↩︎ ↩︎ ↩︎ ↩︎Opinions vary as to the scope of software architectures:
- Macroscopic system structure: this refers to architecture as a higher-level abstraction of a software system that consists of a collection of computational components together with connectors that describe the interaction between these components.
- The important stuff—whatever that is: this refers to the fact that software architects should concern themselves with those decisions that have high impact on the system and its stakeholders.
- That which is fundamental to understanding a system in its environment
- Things that people perceive as hard to change: since designing the architecture takes place at the beginning of a software system’s lifecycle, the architect should focus on decisions that “have to” be right the first time. Following this line of thought, architectural design issues may become non-architectural once their irreversibility can be overcome.
- A set of architectural design decisions: software architecture should not be considered merely a set of models or structures, but should include the decisions that lead to these particular structures, and the rationale behind them. This insight has led to substantial research into software architecture knowledge management.
-
↩︎ ↩︎ ↩︎ ↩︎team member has a lot of questions:
- Where can I find an overview of the system’s building blocks?
- Why are you using Angular and not React? Why are you using Hibernate and not jOOQ?
- Where and how is the system deployed?
- Are there any conventions I need to be aware of?
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎Software architecture is the fundamental underlying structure of a software system. Just like physical architecture defines and limits how a specific building can be efficiently used, software architecture defines what software is or can be.
— https://builtin.com/software-engineering-perspectives/software-architecture
-
↩︎ ↩︎Software architecture is the defining and structuring of a solution that meets technical and operational requirements. Software architecture optimizes attributes involving a series of decisions, such as security, performance and manageability. These decisions ultimately impact application quality, maintenance, performance and overall success
— https://www.techopedia.com/definition/24596/software-architecture
-
↩︎ ↩︎ ↩︎Some key functions of software architecture include:
- It helps stakeholders to visualise, understand, and analyse a system’s qualities.
- It focuses on the structure (rather than implementation).
- It can be used to anticipate expensive choices in a project before they’re made.
- It is used as the basis for making core decisions to ensure high-quality work.
— https://www.future-processing.com/blog/what-is-software-architecture-in-software-engineering/
-
↩︎So in short, Software architecture is more about the design of the entire system, while software design emphasizes on module / component / class level.
— https://stackoverflow.com/questions/704855/software-design-vs-software-architecture
-
↩︎Software architecture is about making fundamental structural choices that are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of the software.
-
↩︎ ↩︎ ↩︎Software architecture is concerned with context, which can be split into three main areas:
The functional requirements:
– What should a particular system do?
Non-functional requirements (the ‘ilities’):
– Functionality – Reliability – Usability – Efficiency – Maintainability – Scalability
Restrictions
– Legal requirements – Standards – Cost – Time-to-market – Talent hiring
— https://www.future-processing.com/blog/what-is-software-architecture-in-software-engineering/
-
↩︎architect is concerned with the ‘big picture’ questions about what the project is, how it will look, what its function is and so on, whereas, the designer/ engineer is concerned with how to make the architect’s ideas work.
— https://www.future-processing.com/blog/what-is-software-architecture-in-software-engineering/
-
↩︎first goal of software architecture documentation:
Software architecture documentation creates a common understanding of the solution behind the system for various stakeholders
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎Software architecture documentation allows your stakeholders to judge whether the system is achieving the goal, since they often can’t dive into the code.
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎large part of software architecture work is communication. In particular, communication with stakeholders is key to effective and focused discussion outcomes
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎good architecture documentation, they can answer the following questions:
- Does the chosen architecture fit the solution?
- Is the architecture appropriate?
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎most important that the software architecture documentation supports your team effort
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎important to actively know (and pass on to new team members) the goals, constraints, and non-functional requirements within the team.
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎go to ask each of your colleagues what they really need out of the technical documentation and what types of diagrams it should include. Collect their input, then brainstorm and agree together on what is really necessary for the team.
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎Don’t includes Tutorials or Q&A sections
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎your documentation process benefits from the same practices you use to develop successful software.
Some of these practices are:
Storing content in a version control system Separation of content, configuration, and presentation Use of automation for compilation, validation, verification and publishing (CI/CD) Reuse shared materials (DRY) …and use your IDE to write content ;-)
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
See how in https://youtu.be/ihtIcGkTFBU it is described that MVC is an architecture. This makes sense beca ↩︎
-
In https://youtu.be/v=-IZlOPciSl0, Dave Farley talks about the actor architecture. ↩︎
-
↩︎Even though an architectural pattern conveys an image of a system, it is not an architecture. An architectural pattern is a concept that solves and delineates some essential cohesive elements of a software architecture
-
#+BEGIN_QUOTE quite a number of ways that architectures can be structured and patterned, with some more popular than others.
[…]
- LAYERED PATTERN ARCHITECTURE
[…]
- EVENT-DRIVEN ARCHITECTURE
-
↩︎create different views of your system’s architecture by developing a common understanding of your system’s software architecture
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎many different stakeholders interested in different aspects of our system: Software Architects, Software Engineers, Ops, Support, Testing, POs, Project Managers, SMEs, Business Sponsors and so on.
— https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/
-
↩︎Most of the time we create either too much, too little or irrelevant documentation because we fail to identify the proper beneficiaries and their real needs
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎ ↩︎ ↩︎main beneficiary should be the team (developers, test engineers, business analysts, devops, etc.) who have direct involvement in the project. In my experience, outside of the team, there are very few stakeholders who really care about documentation. In the best case, they might be interested in one or two high-level diagrams (e.g. context diagram, application or software component diagram) which roughly describe the structure of the system and give a high-level understanding of it.
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎most stakeholders are not interested in detailed diagrams, but rather in one or two high-level diagrams which reflect the modularity and boundaries of the system. Beyond these, for a deeper understanding, the code should be the source of truth, which in most of the cases only developers are interested in.
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎ ↩︎please stop creating diagrams for things that are self-explanatory in the code, too detailed, or when there is no real audience
— https://www.infoq.com/articles/why-architectural-diagrams/
-
#+BEGIN_QUOTE
-
↩︎ ↩︎good practises must be put in place from the outset. Some essential practises include:
Keeping comprehensive documentation of all aspects of the architectural design and their interrelationships with other aspects of the project, as well as the goals or functions they should achieve.
Implementing a system of regularly evaluating the architecture to determine whether it’s achieving its purpose. If not, then actions can be taken to rectify the problem before it becomes a critical issue down the road.
Continuously analysing the system to ensure that it is conforming to the intended architecture type.
Putting systems in place at every stage of the architecture process to maintain quality assurance of the system’s tasks, goals, and outputs.
— https://www.future-processing.com/blog/what-is-software-architecture-in-software-engineering/
-
↩︎biggest mistakes is to create detailed architectural diagrams for parts of the system with high volatility. It is a burden to manually maintain them unless they are automatically generated
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎most of the developers I interacted with are not in favor of creating and maintaining technical documentation; they consider it tedious, time-consuming, and less valuable than other work, or even unnecessary when source code is enough
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎ ↩︎keep in mind the team should be the main beneficiary of architectural diagrams. If they do not manifest any interest, then you should probably stop creating them; it might be waste of time. We should not create architectural diagrams just “for the sake of having them,” to follow some comprehensive methodologies, or to justify our role as Architects
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎common, big misunderstanding was people thinking they did not need any documentation, because working software is more important than creating comprehensive documentation
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎not all documentation provides value. But that isn’t the same as “all documentation provides no value.”
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎If developers understand the real value of the documentation and have as interest in its remaining valuable, they will be encouraged to contribute and properly maintain it. In the end, everybody becomes happy. However, if they do not understand the necessity or they do not care, you can almost forget about it, since documentation becomes very difficult to maintain by a just single person (the architect) when this must be a shared responsibility among the team members
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎My advice is to decide together with the team and to create just enough technical documentation, whatever that means for your team.
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎very difficult to get the right answer to the question: what is the appropriate amount of technical documentation (i.e. architectural diagrams)? In the end, it relates to each project and to the architect experience, and could be summarized as “IT DEPENDS.” The right amount of documentation to provide value depends on what your team has decided they need.
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎Ask somebody in the building industry to visually communicate the architecture of a building and you’ll be presented with site plans, floor plans, elevation views, cross-section views and detail drawings. In contrast, ask a software developer to communicate the software architecture of a software system using diagrams and you’ll likely get a confused mess of boxes and lines … inconsistent notation (colour coding, shapes, line styles, etc), ambiguous naming, unlabelled relationships, generic terminology, missing technology choices, mixed abstractions, etc.
-
↩︎ ↩︎C4 model is an “abstraction-first” approach to diagramming software architecture, based upon abstractions that reflect how software architects and developers think about and build software
-
↩︎Enough up front design to create a good starting point and direction
-
↩︎Software architecture is all about having a holistic view and seeing the bigger picture to understand how the software system works as a whole
— https://www.infoq.com/articles/brown-are-you-a-software-architect/
-
↩︎architecture diagram is a diagram that depicts a system that people use to abstract the software system’s overall outline and build constraints, relations, and boundaries between components
-
↩︎system architecture diagram will focus on the structure of the system to be created, along with the technologies used, external services, user requirements and components such as databases and servers.
-
↩︎An architecture diagram is a visual representation of all the elements that make up part, or all, of a system.
-
↩︎ ↩︎ ↩︎Architectural diagrams should help everybody to see the big picture and to understand the surroundings. In my opinion, this should be the fundamental reason behind creating and maintaining the architectural diagrams
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎An architecture diagram:
a) Help in making the comprehension process easy
[…]
b) The diagrams help improve collaboration and communication
-
↩︎When the team — stakeholders included — are all working from the same diagram, it’s easier to keep track of jobs and progress
-
↩︎Software architecture diagrams are a helpful tool for visualizing highly complex processes in a way that’s easy to understand
-
↩︎ ↩︎ ↩︎main purpose of architectural diagrams should be to facilitate collaboration, to increase communication, and to provide vision and guidance
— https://www.infoq.com/articles/why-architectural-diagrams/
-
↩︎Architecture (or architectural – both are used) diagrams are primarily about making it easier to communicate and collaborate with all stakeholders in a project. An architecture diagram will show the concepts involved in the architecture, including key principles, elements, and components. They are high-level diagrams that aim to represent the big picture and make it clearly understandable.
-
↩︎Above all, it helps the engineers, designers, stakeholders — and anyone else involved in the project — understand a system or app’s layout
-
↩︎Show system interactions: If you can use a shape or an arrow to say it, do it. Use lines to indicate process flows and interactions
-
Add notes to explain key parts of your diagram — but keep it short, and only use words when a part of the diagram can’t be understood without them.
↩︎Make your diagram accessible: Share it widely
-
↩︎Here are some of the more commonly used software architecture diagrams you’re likely to encounter.
Application architecture diagram
[…]
Integration architecture diagram
[…]
Deployment architecture diagram
[…]
DevOps architecture diagram
[…]
Website architecture diagram
[…]
AWS architecture diagram
[…]
-
↩︎A system architecture diagram (SAD) is a diagram that shows the relationship between software modules
-
also called software architecture diagram79, but I think this makes the conversation harder ↩︎
-
↩︎Enterprise architecture diagram help manage the business and organizational model of a project
-
↩︎don’t need to use all 4 levels of diagram; only those that add value - the System Context and Container diagrams are sufficient for many software development teams
-
↩︎first need a common set of abstractions to create a ubiquitous language that we can use to describe the static structure of a software system
-
↩︎person represents one of the human users of your software system (e.g. actors, roles, personas, etc).
-
↩︎software system is the highest level of abstraction and describes something that delivers value to its users, whether they are human or not.
-
↩︎container represents an application or a data store. A container is something that needs to be running in order for the overall software system to work
-
↩︎container is essentially a context or boundary inside which some code is executed or some data is stored
-
↩︎communication between containers typically takes the form of an inter-process communication
-
↩︎File system: A full local file system or a portion of a larger networked file system (e.g. SAN, NAS, etc). Shell script: A single shell script written in Bash, etc.
-
↩︎In the C4 model, components are not separately deployable units.
-
↩︎hierarchy of abstractions is then done by creating a collection of Context, Container, Component and (optionally) Code (e.g. UML class) diagrams
-
↩︎step back and see the big picture
-
↩︎your system as a box in the centre, surrounded by its users and the other systems that it interacts with.
-
↩︎focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, protocols and other low-level details. It’s the sort of diagram that you could show to non-technical people
-
↩︎software architecture diagram. The software to be designed is divided into layers that represent different functionalities, such as the business layer, service layer, and data layer.
