Requirement Analysis and system design (III.)

Writing here is also the end of the book, put in the middle and lower inside is the next concept, at the end of the chapter to write some I read this book to benefit from the part and related knowledge.

In class, you often hear the teacher say something about the software Requirements specification, the requirements specification, the requirement specification involves rigorous modeling of customer requirements defined during the requirements determination, and focuses on the desired services that the system will provide. System constraints are not generally considered in the specification phase, but system constraints can guide and validate the modeling effort. This guidance and validation takes the form of institutional priorities.

The software architecture defines the structure and organization form of the software components and subsystems which are interacting in the system. It is difficult to read a series of obscure words in a book, but it is possible to make a list of the appropriate use of extended inheritance, such as inheritance,UMLIt is very unique to implement inheritance in terms of generalization adjustment inheritance and proper use. The only appropriate use of inheritance is to define inheritance as an incremental type of class. Subclasses have more features than super-classes. Subclasses are one of the superclass classes. This is also commonly referred to as extended inheritance. In extended inheritance, the overloading of attributes should be used with caution, allowing only the use of attributes to be more specialized (such as restricting the worth of scope or making the implementation of the operation more efficient) without altering the meaning of the attribute. If overloading alters the meaning of an attribute, the subclass object cannot replace the superclass object. Extends the definition of subclasses with new attributes. However, some inherited attributes are forbidden in subclasses, so it is possible to use inheritance as a restriction mechanism, which is known as restriction inheritance. Blindly emphasize the implementation of inheritance, it may be in the use of software patterns caused by the complexity of the software increase, but we do not use inheritance, it is what use it! Some people have said that if we forbid the convenience of inheritance, we will be all right. Implementing inheritance is a risky thing for many standards. If it is not properly controlled and managed, inheritance can be overused and misused to create problems that should be addressed first. This is especially true for large systems (such as enterprise information systems) that have hundreds of classes, thousands of objects, dynamic object state changes, and an evolving class structure. There are base classes in the source program, there are calls, but often the base class will be very fragile, often improper use willBugfrequently, the problem is that, while allowing the implementation of a superclass (or more than one superclass, if multiple inheritance is used) to evolve, the subclass remains valid and available. This is a serious problem in any case, especially when we consider the ability to get superclass from external resources beyond the control of the system development team. With this in mind, your app inherits a few super-classes that make up the operating system and the database system. Package Visibility isJavathe default. If theJavadoes not specify a property or operationPrivate,protectedor Publickeyword (or no specified for the entire class Publickeyword), the visibility they get by default is package visibility. Package visibility means that all other classes contained in the package can access such a property or operation. However, for classes in all other packages, this property, operation, or class appears to be private. protected (and public) also has package accessibility, but not in turn. This means that other classes in the same package can access the protection attribute, but if the derived class and base class are in different packages, the derived class cannot access those attributes that have package visibility.

To design database access and transactions, the application needs to exchange data with the database, and the client program must use the database language (typicallySQL) to access and modify the database. Resource subsystem (andRreader,Rwriterand other classes) are responsible for communicating with the database. However, the model does not describe how to implement communication, and the model does not explain how to ensure the consistency of business transactions. SQLthe level of programming, in order to understand how the client program and the database server is how to communicate, we need to recognizeSQLcan be expressed in different forms, and can be at different levels of programming abstraction. First timeSQLUsed as a data definition languageDDL. DDLis the specification language that defines the database structure (database schema). Database Designer and database administratorDBAIt's the first floor .SQLthe primary user. Second FloorSQLUsed as a data manipulation languageDMLor query language. However, the term query language is a bit of a misnomer because the second layerSQLnot only can it be used to query data, but it can also be used to modify data. To ensure that the query returns the correct results, the programmer must be able to gradually browse through the records returned by the query and then, in turn, make a record decision if the records are processed. This one-time record-handling capability is called a temporal table, and the second-levelSQLall have this function.

Requirement Analysis and system design (III.)