Pipe and filter architecture, which is a type of data flow architecture. Data flow architecture considers a system as simply a series of transformation on sets of data. Data is transformed from one form to another using different types of operations. A pipe and filter architecture has independent entities called filters which perform transformations on data input they receive, and pipes, which serve as connectors for the stream of data being transformed. 

The changes to the data are done sequentially from filter to filter. Each filter performs its local transformation on the data input it receives from the previous pipe and then it sends the output onto the next pipe.

Continue reading “Pipes and Filters” →

• State. The information that a system remembers defines its state. For example, a queue system can be in a number of different “states”: an empty state, a queued state, or a full state.
• Transition. A transition is used to describe the change of a system from one state to another. A single system state can have multiple transitions; majority of systems today will have multiple transitions branching from one system state. This makes behaviors non-deterministic, since we cannot predict what the next state of the system will be.
• Behavior. The behavior of a system describes what the system will do when exposed to a condition, which can vary from timed system events to user input.

State transition systems can be thought of as directed graphs. Each node of the graph represents the set of states, and each edge of the graph represents the set of transition. We can determine how a system reaches a specific state by simply traversing the graph.

State transition systems can help us understand how parallel processing, multithreading, or distributed computing can affect the overall state of our system. Do we need to wait for another process to finish its work before continuing? At which junction of our system will we be bottlenecked?

In addition, state transition systems can help us identify deadlocks. A deadlock occurs when a process is waiting indefinitely for another to release a shared resource or complete its work. A state transition system can help you easily identify deadlocks since they occur if there is a condition that prevents a transition out of particular state.

Another name of the n-Tier is Multitier. Tiers often refer to components that are on different physical machines. The number of tiers varies quite a bit, 3- and 4-tier architectures are quite common, but any number is possible. So this architecture is called n-Tier or a Multitier.

The relationship between 2-Tiers in an n-Tier architecture is often a client/server relationship. The server side provides services. This could be storing information in a database, performing computation tasks, any sort of service. The client-side requests these services through messages. The communication between the two sides is called Request-Response. A tier can act as both a server and a client, simultaneously fulfilling the requests of its clients and making requests of its servers.

2-Tier Architecture (Client Tier and Data Tier):

Continue reading “Client Server n-Tier” →

A simple example of the layered system (3 layers) where each higher layer can get one or other properties, methods from the near layer. The students and the principal only have to interact with one layer, the teachers, while the teachers have to interact with both of their adjacent layers, the principal and the students

Continue reading “Layered Systems” →

Data-Centric Software Architecture helps to increase the maintainability, reusability, and scalability of a system. There are 2 types of components:

1. Central Data – the component used to store and serve data across all components that connect to it.
2. Data Accessors – the components that connect to the central data component. The data accessors make queries and transactions against the information stored in the database.

The data accessors are separated from one another and communicate only to the central data component. The central data facilitates data sharing by saving the desired information from the current state of the system and serving data as requested.

Continue reading “Repository-based Systems: Databases” →

In a UML activity diagram, you represent the control flow from one activity to another in software system (like a levels in video game). You can consider activities as actions that further the flow of execution in a system. They are actions, that when completed, cause another action to execute. For example these actions can alter objects or create new objects. These changes/actions drive the application forward.

The purpose of the activity diagram is to capture the dynamic behaviour of the system. The activity diagram allows you to map out the branching into alternative flows.

When creating the diagram, firstly have to identify the activities.

Activity diagram have 2 major parts, the start and end nodes:

The intermediate activities are shaped as a pill. They describe all of the activities that change the game state before the game ends.

Continue reading “UML Activity Diagram” →

Software release involves:

• Separate libraries
• An executable.
• An installer.
• Configuration files.
• Other different pieces.

To make software ready to run, need an idea of how to fully deploy all the different files to a needed environment. To visualize it, can use the UML deployment diagram. The deployment environment (deployment target) can be very specific. The details on the deployment diagram will change accordingly.

The physical result of the development process is artifact. For example artifacts for video game can include an executable, installer, audio libraries, multimedia assets.

There are 2 types of deployment diagrams:

Continue reading “UML Deployment Diagram” →

A package – groups together elements of a software that are related. This elements can be related based on Data, Classes, User Tasks.

A package also defines a namespace for the elements it contains, helps to organize the named elements of a software into a separate score. An element can be uniquely identified in the system by a fully qualified name, based on the own name and the name of the package that element is in (namespace).

Package diagram show packages and the dependencies between them. The packageable elements might be: Data, Classes, Other packages. Package diagrams are helpful for when you want a high-level look at your system, how different packages depend on each other.

A package has a simple depiction, which looks like a tabbed folder.

Continue reading “UML Package Diagram” →