Designing is an important part of any IT systems development process. The shape and operation of the created IT system depends on it. That’s why it’s worth to realize the fact that regardless of the adopted software development model (agile or cascade / waterfall), there is a need and even absolutely necessity to devote appropriate resources and time to ensure that the system design is properly developed and documented. Thanks to this, we will be sure that our system – its software will have a solid architecture that will not collapse like a house of cards under the pressure of problems and errors.

What is basics of software design?

The purpose of the analysis and software design process is:

• transforming the requirements into the software design of the future system,
• developing a robust system architecture,
• adapting the project to the implementation environment with particular emphasis on operational efficiency.

It is also worth noting that the quality of the developed and collected requirements that we set for the IT system has a very large impact on the results of the project and, consequently, on the shape of the system being built. Therefore, giving the appropriate structure to the requirements helps in the software design of systems.

Read also: How To Prepare a Good Specification Of Requirements For IT Projects

What is basics of software design?

To talk and think about software architecture, you must first define an architectural representation, a way to describe important aspects of architecture. This description is typically found in a Software Architecture Document.

Architectural views

Software architecture is often represented as multiple architectural views. Each architectural view addresses a specific set of problems specific to stakeholders in the software development process: end users, designers, managers, system engineers, programmers, etc.

The views capture the most important software design decisions about the structure, showing how the software architecture is decomposed into components and how the components are interconnected. Of course, these software design choices must be related to requirements, functional and non-functional constraints, and other constraints. But these choices, in turn, place further constraints on requirements and future software design decisions at a lower level.

A typical set of architectural views

One of the elements of IT systems architecture that can be represented is the view sets known as the “4 + 1 view model”.

The model consists of the following views:

• use case view – contains use cases and scenarios that include architecturally important behaviors, classes, or technical risks,
• logical view – contains the most important design classes and their organization into packages and subsystems and the organization of these packages and subsystems into layers. It also includes some use case implementations,
• implementation view – provides an overview of the implementation model and its organization in terms of modules into packages and system layers. Also bind packages and classes (from Logical View) to packages and modules of Implementation View,
• process view – includes a description of tasks (process and threads), their interactions and configurations, and assigning objects and design classes to tasks. Use this view only if your system has a significant degree of concurrency,
• deployment view – describes the various physical nodes for the most common platform configurations and assigns tasks (from the process view) to physical nodes.

Architectural views are documented in the software architecture document. Additional views are placed in the software design documentation as needed to show other aspects of the architecture: UI view, safety view, data view, and so on. For simple systems, some views included in the 4+1 view model can be omitted.

The main elements of architecture

While the above views may represent the entire software design, the systems architecture only deals with some specific aspects:

• model structure – organizational patterns, such as layers,
• basic elements – critical use cases, main classes, common mechanisms,
• several key scenarios representing the main control flows throughout the system,
• services to capture modularity, optional features, product line aspects.

In fact, architectural views are abstractions or simplifications of the entire project, in which important features are more clearly visible, leaving details aside. These features are important when:

• system evolution – transition to the next development cycle,
• reuse of architecture or parts of it in the context of product line development,
• evaluation of additional features such as performance, availability, portability and security,
• assigning development work to teams or subcontractors,
• decisions to include ready-made components,
• embedding into a larger system.

Architectural patterns

When building the system architecture, the so-called architectural patterns. These are ready-made elements that solve recurring architectural problems. An architectural framework, or middleware, is a set of components upon which a specific type of architecture can be built. Many of the major architectural problems should be resolved through the use of appropriate architectural patterns.

Architectural plans

The graphical representation of an architectural view is called an architectural plan. For the different views described above, the plans consist of the following Unified Modeling Language diagrams:

• logical view – class diagram, state diagram and object diagram,
• process view – class diagram and object diagram (including tasks – processes and threads),
• implementation view – component diagram,
• deployment view – deployment diagram,
• use case view – use case diagram showing use cases, actors, and regular design classes; sequence diagram showing design objects and their cooperation.

The process of analysis and software design

In the initial phase, analysis and software design focuses on determining if the system is feasible as predicted and evaluating potential technological solutions (Perform Architectural Synthesis). If the development seems to be associated with little risk (because, for example, the domain is well understood, the system is not new, etc.), this detail of the workflow can be omitted.

The early development phase focuses on creating the initial system architecture to provide a starting point for major analytical work. If the architecture already exists (because it was produced in previous iterations or previous projects), it focuses on refining the Architecture, analyzing behavior, and creating an initial set of elements to ensure proper system behavior (Analyze Behavior).

After identifying the initial elements, they are further refined. Design components form a set of components that provide the appropriate behavior to meet system requirements. In parallel with these activities, persistence issues are addressed in Database Design. The result is an initial set of components that are further developed during the implementation phase.

Architecture prototype

Prototypes are used in a targeted manner to reduce risk. Prototypes can reduce uncertainty about:

• profitability of the product under development,
• stability or performance of key technology,
• involvement or financing of the project,
• understanding the requirements,
• the appearance and operation of the product and its usability.

A prototype can help build product support by showing users, customers and managers something specific and doable.

However, the nature and purpose of the prototype must remain clear throughout its lifetime. As a rule, it cannot be assumed that if a prototype works, it should become the end product. For example, an exploratory, behavioral prototype designed to test the user interface very quickly rarely turns into a strong, resilient product.

You can look at prototypes in two ways: what they research; and how they evolve or what the outcome is.

In the context of the first view – what they investigate – there are two main types of prototypes:

• a behavioral prototype that focuses on studying a specific system behavior,
• a structural prototype that studies certain architectural or technological problems.

In the context of the second view – their result – there are also two types of prototypes:

• a research prototype that is not directly used to build an actual system,
• an evolutionary prototype that gradually evolves to become a true system.

Architectural analysis

Architectural analysis focuses on defining potential architecture and limiting architectural techniques to be used in the system. It is about accumulating experiences from similar systems or problem areas so that effort is not wasted on “rediscovering architecture”. In systems where a well-defined architecture already exists, this step is skipped. Architectural analysis is particularly beneficial when developing new and innovative systems.

System behavior analysis

The goal of this stage is to transform the behavioral descriptions provided by the use cases defined in the requirements gathering stage into a set of elements on which to base the system design.

Designing system components

Use case design

This stage of the systems analysis and software design process focuses on the following aspects of the system:

• use case implementation design in terms of interactions,
• draft requirements for the operation of design classes,
• implementation of requirements for the operation of subsystems and / or their interfaces.

System behavior can be described and documented using a number of techniques – collaboration or interaction. This activity describes the use of interactions, particularly sequence diagrams, to describe system behavior. Sequence diagrams are most useful when the behavior of a system or subsystem can primarily be described with synchronous messaging. Asynchronous messaging, especially in event driven systems, is often easier to describe in terms of state and collaboration machines, which allows for a compact way of defining possible interactions between objects.

Class design

This stage of the software design focuses on:

• the designed system elements (classes) ensured the behavior required by the implementation of use cases,
• determine sufficient information to unambiguously implement the classes in the later stages of building the system,
• handling non-functional class-related requirements,
• taking into account the software design mechanisms used by the class.

Classes are the basic building block of systems and reflect the real work of the system. The rest of the software design – subsystems, packages, and collaboration, simply describes how classes are grouped or interacted together.

Subsystem project

The purpose of this stage is the following project activities:

• definition of the behaviors specified in the subsystem interfaces with regard to cooperation in the classes between them,
• documentation of the internal structure of the subsystem,
• defining the implementation between the subsystem interfaces and the classes it contains,
• determining dependence on other subsystems.

Database design

At this stage of the project, he focuses on the following software design works:

• identification of “persistent” classes (data) in the project,
• designing appropriate database structures for data storage,
• defining mechanisms and strategies for storing and retrieving data so that system performance criteria are met.

The result of the above activities is the creation of a data model. The data model is used to describe the logical and possibly physical structure of persistent information managed by the system. The data model is especially needed when the persistent data structure cannot be automatically derived from the persistent class structure in the software design model. It is used to define the mapping between persistent design classes and persistent data structures, and to define the persistent data structures themselves. This is most often needed when your design model is an object model and the persistent storage mechanism is based on a relational database.

Design is important for software development

The value of a IT software design cannot be overestimated. As you can see, the good software design phase is a very important and important stage and at the same time a difficult and complicated process. Therefore, the work and experience of project teams should be appreciated. Good documentation of this stage of the IT system construction implementation allows for efficient information exchange between the members of the project team and the end customer. A good software design guarantees the efficient operation of the implemented systems. This, in turn, translates into the satisfaction of our customers.