Miro support software#
Intended audience: Everybody, both technical and non-technical people, inside and outside of the software development team. Typically these other software systems sit outside the scope or boundary of your own software system, and you don’t have responsibility or ownership of them. users, actors, roles, or personas) and software systems (external dependencies) that are directly connected to the software system in scope. Primary elements: The software system in scope. It's the sort of diagram that you could show to non-technical people. The focus should be on people (actors, roles, personas, etc) and software systems rather than technologies, Draw a diagram showing your systemĪs a box in the centre, surrounded by its users and the other systems that it interacts with.ĭetail isn't important here as this is your zoomed out view showing a big picture of the system landscape. In the C4 model, components are not separately deployable units.Ī System Context diagram is a good starting point for diagramming and documenting a software system,Īllowing you to step back and see the big picture. one component vs many components per JAR file, DLL, shared library, etc) is a separate and orthogonal concern.Īn important point to note here is that all components inside a container typically execute in the same process space. Aspects such as how those components are packaged (e.g. If you're using a language like Java or C#, the simplest way to think of a component is that it's a collection of implementation classes behind an interface. The word "component" is a hugely overloaded term in the software development industry, but in this context a component is a grouping of related functionality encapsulated behind a well-defined interface.
Miro support code#
Miro support full#
Miro support android#
Not Docker! In the C4 model, a container represents an application or a data store. In many cases, a software system is "owned by" a single software development team. This includes the software system you are modelling, and the other software systems upon which your software system depends (or vice versa). 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. PersonĪ person represents one of the human users of your software system (e.g.
classes, interfaces, objects, functions, etc). Which in turn are implemented by one or more code elements (e.g. The C4 model considers the static structures of a software system in terms of containers, components and code.Īnd people use the software systems that we build.Ī software system is made up of one or more containers (web applications, mobile apps, desktop applications, databases, file systems, etc),Įach of which contains one or more components, In order to create these maps of your code, we 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.
0 kommentar(er)
