<< Requirements Analysis and System design >> reading notes three

Finally, "demand analysis and System design" finished reading, feel a lot, although understanding is not thorough, but still learned a lot of knowledge. In the software requirements specification, it is necessary to use graphs and other formal models to illustrate the requirements, and to describe a system in a complete manner, it is important to adopt multiple models. UML provides a number of integrated modeling techniques to assist system analysts to accomplish this task. The process of specification is iterative and incremental. For successful modeling, it is necessary to use the case tool. Requirements specification generates three models: state model, behavior model, state change model. The requirements specification involves rigorous modeling of customer requirements defined by the requirements definition period, with a focus on the desired services that the system will provide. System constraints are generally not considered further in the specification phase, but system constraints can guide and validate modeling tools. This guidance and validation takes the form of architectural priorities. Software architecture defines the structure and organization of the software components and subsystems that interact in the system. The software architecture captures and preserves the design intent of the designer with regard to the system structure and behavior, so it provides a protective measure against the design to prevent failure as a system phase design. Before the detailed system specification work begins, it is critical that the Software development team select the architectural patterns and principles to be followed by all developers. If the system does not have a clear view of the architecture, then the analysis phase is the delivery of specifications for an unsupported system. The most important goal of all software modeling is to minimize component dependencies. In order to do this, developers cannot freely communicate with objects that can cause confusion in an incomprehensible component communication network. As the model grows and each object joins, such system complexity increases exponentially, which is intolerable and must be stopped before it can cause damage. In the early life cycle, we must adopt a clear architecture model with layered components and subsystems, and strictly control the communication of objects.

In iterative and incremental software development, the model is continuously refined using technical details, and once the technical details are considered for software/hardware, the analysis model becomes a design model. The system design includes two main problems: the system architecture design and the detailed design of the program in the system. Architecture design is to describe the system from the aspects of the system, including the solution strategy of determining the client component and the server component of the system. Architecture defines the hierarchical organization of classes and packages, assigning processes to compute facilities, reuse, and component management. The architecture design solves the problem of multi-layer physical architecture and multi-layer logical architecture. Architecture design has two aspects: physical and logical. The physical architecture design focuses on the choice of deployment scenarios and the distribution of the system's workloads on multiprocessor. The physical architecture addresses client and server issues, as well as any middleware issues that are required to glue clients and servers. It assigns the processing artifacts to the computer nodes. Most enterprise information systems adopt a layered architecture, which defines the computational hierarchy relative to the peer architecture. Software developers know that the difficulty of creating small systems is not comparable to the difficulties of large solutions. Small systems are easy to understand, implement and deploy. Large enterprise systems consist of a large number of objects of the corresponding random event, which can cause confusion in the interrelated operations. Without a clear architecture design and rigorous process, large software projects are doomed to fail.

The behavior of the system is that it is presented to the external user, which is described by use cases, and the use case model can be generated at different levels of abstraction. They can consider the system as a whole, explaining the main functional units of the application in development. In the analysis period, use cases capture system requirements by focusing on what the system does or what it should do. In the design phase, use case views can be used to illustrate the behavior that the system will implement. The behavior that is developed by use cases requires the execution of a use case through computation and interaction between objects. Calculations can be modeled with activity diagrams, and the interaction of objects can be illustrated by sequence diagrams or communication diagrams. The behavior specification provides an operational view of the system, and the primary task is to define the use cases in the application domain and to determine which classes are involved in the execution of these use cases, indicating the delivery of information between class actions and object operations. Although object interaction also causes changes in the state of the object, in the behavior specification, we define only the operation view of the frozen state of the system, and the change in the state of the object is clearly described in the state change specification.

<< Requirements Analysis and System design >> reading notes three