Software Design Concepts: Analysis, Models, and Architecture
1). Concept Analysis
The analysis concept is basically to understand the business rules and software requirements in order to provide an optimal solution to the problem, with clear aims and objectives. It also defines the scope of the project and the functional and non-functional requirements. It consists of several stages:
- Recognize the problem: which recognizes the basic elements of the problem as perceived by end users.
- Evaluation and synthesis, which assesses the information content, defines and develops all the functions of software, meaning the software behavior in the context of events that affect the system.
- Modeling: System models are created in order to better understand the objectives and behavior.
- Specification: In this stage, there is a formal specification of the software.
- Review: Where a final checkup is done throughout the process.
2). Model Concept and Methodology
The model serves to explain and present a solution to a problem; no dynamics is static. However, the methodology is a set of procedures, techniques, and tools that help achieve the objective solution; therefore, it is dynamic. In general terms, the methodology is used with the models.
3). Architectural Concept
Design is the highest level of the structure of a system, which is defined in terms of components and the interaction between them. It shows the correspondence between system requirements and elements constructed and shows the overall system properties such as scalability, performance, consistency, and compatibility.
3.1). Concept of Architectural Style
The description of the types of components and a control pattern of execution and/or data transfer.
An architectural style defines a family of systems in terms of patterns of structural organization. A style defines:
- Vocabulary (components and connectors)
- Restrictions on how to combine
- Semantic models that determine how to set global properties from the properties of the parts.
Some architectural styles are: pipe and filters, objects, layered, and client-server, etc.
3.2). Component Concept
Corresponds to a piece of software responsible for encapsulating a set of functions that operate on a data model part of the solution. In some cases, it corresponds to the part that functions AutoMon and integrates with other components.
4). Request or Requirement Concept
Requirements are the descriptions made by the user of their desires or needs they have in front of a product. These requirements give rise to conditions which must be met to achieve the requirements. Overall output:
- Requirements: We show what the system should do, how to solve a problem or achieve an objective.
- Requirement: How to make the software prerequisites necessary to resolve the problem.
5). Concept of Use Case
A use case is a technique that is used to specify the functionality and behavior of a system through its interaction with users and/or other systems.
The use case diagram consists of actors, relationships, and scenarios.
6). Concept of Non-Functional Requirement
Specify what is expected of the system in terms of non-functional specific qualities such as its speed, user-friendliness, robustness, reliability, adaptability, and portability. These are requirements that cannot be classified as “programmable”, but they will be inserted into the software features that are intended to build.
7). Concept Diagram of Components
Component diagrams represent parts of the software comprising the system; they may be simple files, packages, dynamically loaded libraries, etc.
It consists of:
- Components, that is a physical unit implementation with well-defined interfaces designed to be used as a replaceable part.
- Interface: which is a list of operations that a piece of software or hardware features and can perform.
7.1). Comparison of Component Diagram and Class Diagram
A component diagram has a higher level of abstraction than a class diagram – usually a component is implemented by one or more classes (or objects) at runtime.