System Architecture Documentation
Timetracko
Abstractions
In order to create maps of timetracko 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. The C4
model considers the static structures of a software system in terms of containers, components and
code. And people use the software systems that we build.
Timetracko system is made up of multi containers (web applications, mobile apps, desktop
applications, databases, file systems, etc), each of which contains one or more components, which
in turn are implemented by one or more code elements (e.g. classes, interfaces, objects, functions,
etc).
Person
A person represents one of the human users of timetracko system (e.g. Employee, Workspace
Manager, Project Manager, Team Owner etc).
Software System
A software system is the highest level of abstraction and describes something that delivers value to
its users, whether they are human or not. This includes the software system you are modelling, and
the other software systems upon which your software system depends (or vice versa)
Container (applications and data stores)
Not Docker! In the C4 model, a 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. In real terms, a
container is something like:
 Server application: In Timetracko server applications are used to provide api for client web
and desktop applications.
 Client-side web application: A JavaScript application running in a web browser using
Javascript, React etc.
 Client-side desktop application: A desktop application written using Python to collect
Employee events.
 Server-side console application: A standalone application, a batch process, example DB
migrations Scripts.
 Serverless function: A single serverless function (e.g. Amazon Lambda, Azure Function,
etc).
 Database: A schema or database in a relational database management system, document
store, Timescale database, PostgreSql
 Blob or content store: A blob store (e.g. Amazon S3, Microsoft Azure Blob Storage, etc) or
content delivery network (e.g. Akamai, Amazon CloudFront, etc).
 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.
 etc
A container is essentially a context or boundary inside which some code is executed or some data is
stored. And each container is a separately deployable/runnable thing or runtime environment,
typically (but not always) running in its own process space. Because of this, communication
between containers typically takes the form of an inter-process communication.
Component
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. The simplest way to think of a component is that it's a collection of implementation
classes behind an interface. Aspects such as how those components are packaged (e.g. one
component vs many components per whl file, site-packages, etc) is a separate and orthogonal
concern.
An important point to note here is that all components inside a container typically execute in the
same process space. In the C4 model, components are not separately deployable units.
Core Diagrams
System Landscape diagram
A system landscape diagram is really just a system context diagram without a specific focus on a
particular software system. it's often useful to understand how all of software systems fit together
within the bounds of an enterprise. This diagram can show the organizational boundary,
internal/external users and internal/external systems.
Scope: An enterprise.
Primary elements: People and software systems related to the enterprise in scope.
Intended audience: Technical and non-technical people, inside and outside of the software
development team.
Image 1 : System landscape diagram for Timetracko System.
Desktop Agent :
Desktop agent is a client application which runs on client PC and captures different events from
employee like mouse events, keyboard events, active application, screenshot and information is
send to Lokarkhe.
Lokarkhe:
Lokarkhe is a server side application which receives Employee events from Desktop Agent and
queues events for processing which is handled by Gauthali.
Gauthali:
Gauthali processes events of employee and stores files using file system, stores data to database
parsing and cleaning so that the data can be used by Jhaukari system for reporting.
Jhaukari:
Jhaukari handles requests from web application. Request can be reports, authentication,
dashboard data, User management, Employee management.
Alert System:
Alert system is responsible for generating alerts if any of defined alert workflow is matched.
Email System:
Sends emails to end user.
Event System:
All events are added in event system such that other system can subscribe particular event for
event handling.