Software design
Today, the process of creating complex software applications is impossible to imagine without division into life cycle stages. By the life cycle of a program, we mean the totality of the steps:
Let us dwell on the design process. In the course of the design, an architect or an experienced programmer creates project documentation, including text descriptions, diagrams, models of the future program. The UML language will help us in this difficult task.
UML is a graphical language for visualization, description of parameters, construction and documentation of various systems (programs in particular). Charts are created using special CASE tools, such as Rational Rose (http://www-01.ibm.com/software/rational/) and Enterprise Architect (http://www.sparxsystems.com.au/). Based on the UML technology, a single information model is built. The above CASE tools are capable of generating code in various object-oriented languages, and also have a very useful reverse engineering function. (Reversible engineering allows you to create a graphical model from existing program code and comments to it.)
Consider chart types for model visualization (this is a must have, although there are much more types):
The designed system is represented as a set of entities or actors interacting with the system with the help of the so-called precedents. In this case, an entity (actor) or actor is any entity that interacts with the system from the outside. In other words, each use case defines a certain set of actions performed by the system during a dialogue with an actor. At the same time, nothing is said about how the interaction of actors with the system will be realized.
')
The class diagram serves to represent the static structure of the system model in the terminology of the classes of object-oriented programming. The class diagram can reflect, in particular, various interrelations between individual entities of the domain, such as objects and subsystems, and also describes their internal structure (fields, methods ...) and types of relations (inheritance, implementation of interfaces ...). This diagram does not indicate information on the temporal aspects of the functioning of the system. From this point of view, the class diagram is a further development of the conceptual model of the designed system. At this stage, knowledge of the OOP approach and design patterns is fundamental.
The main purpose of this diagram is to describe the possible sequences of states and transitions that collectively characterize the behavior of the model element during its life cycle. A state diagram represents the dynamic behavior of entities, based on the specification of their response to the perception of certain specific events.
For modeling the interaction of objects in the UML language, the corresponding interaction diagrams are used. The interaction of objects can be viewed in time, and then a sequence diagram is used to represent the temporal characteristics of the transmission and reception of messages between objects. Interacting objects exchange some information among themselves. In this case, the information takes the form of complete messages. In other words, although the message has informational content, it acquires an additional property to exert a directional influence on its recipient.
On the cooperation diagram, rectangles depict objects participating in an interaction, containing the name of the object, its class and, possibly, attribute values. As in the class diagram, the associations between objects are indicated in the form of various connecting lines. In this case, you can explicitly specify the names of the associations and the roles played by the objects in the given association.
In contrast to the sequence diagram, only relations between objects that play certain roles in the interaction are depicted in the cooperation diagram.
The component diagram, unlike the previously considered diagrams, describes the features of the physical representation of the system. The component diagram allows you to define the architecture of the system being developed by establishing dependencies between software components, in the role of which source, binary and executable code can act. In many development environments, a module or component corresponds to a file. The dashed arrows connecting the modules show the relationship of interdependence, similar to those that occur when compiling the source code of programs. The main graphic elements of the component diagram are components, interfaces and dependencies between them.
The deployment diagram is intended for visualization of program elements and components that exist only at the stage of its execution (runtime). In this case, only the components of the program are represented, which are executable files or dynamic libraries. Those components that are not used at runtime are not shown in the deployment diagram.
The deployment diagram contains graphic representations of the processors, devices, processes, and the connections between them. Unlike the logical presentation diagrams, the deployment diagram is uniform for the system as a whole, since it must fully reflect the features of its implementation. This diagram, in fact, completes the OOAA process for a specific software system, and its development is usually the last step in the model specification.
This concludes the overview of diagrams in particular and design in general. It is worth noting that the design process has long become a software development standard, but often we have to deal with a beautifully written program that, due to the lack of normal documentation, becomes cluttered with unnecessary side functionality, crutches, becomes cumbersome and loses its former quality. = (
I am convinced that the programmer is first and foremost a coder - he should NOT communicate with the customer, should NOT think about the system architecture, should not invent an interface to the program, he should only code - implement algorithms, functionality, appearance, usability, but no more ... From the abstract diagrams (describing the subject area) to the diagrams representing the structure of the data, the classes and the processes of their interaction, the designer must, in detail, step by step, describe everything. That is, the complexity of the work and the salary of the designer must be much higher than the programmer == coder. Sorry for sedition ....
- Analysis of the subject area and the creation of TZ (interaction with the customer)
- Designing the program structure
- Coding (a set of software code according to project documentation)
- Testing and debugging
- Implementation of the program
- Program maintenance
- Recycling
Let us dwell on the design process. In the course of the design, an architect or an experienced programmer creates project documentation, including text descriptions, diagrams, models of the future program. The UML language will help us in this difficult task.
UML is a graphical language for visualization, description of parameters, construction and documentation of various systems (programs in particular). Charts are created using special CASE tools, such as Rational Rose (http://www-01.ibm.com/software/rational/) and Enterprise Architect (http://www.sparxsystems.com.au/). Based on the UML technology, a single information model is built. The above CASE tools are capable of generating code in various object-oriented languages, and also have a very useful reverse engineering function. (Reversible engineering allows you to create a graphical model from existing program code and comments to it.)
Consider chart types for model visualization (this is a must have, although there are much more types):
- Use case diagram (use case diagram)
- Class diagram
- Statechart diagram
- Sequence diagram
- Collaboration diagram (collaboration diagram)
- Component diagram
- Deployment diagram
Use case diagram (use case diagram)
The designed system is represented as a set of entities or actors interacting with the system with the help of the so-called precedents. In this case, an entity (actor) or actor is any entity that interacts with the system from the outside. In other words, each use case defines a certain set of actions performed by the system during a dialogue with an actor. At the same time, nothing is said about how the interaction of actors with the system will be realized.
')
Class diagram
The class diagram serves to represent the static structure of the system model in the terminology of the classes of object-oriented programming. The class diagram can reflect, in particular, various interrelations between individual entities of the domain, such as objects and subsystems, and also describes their internal structure (fields, methods ...) and types of relations (inheritance, implementation of interfaces ...). This diagram does not indicate information on the temporal aspects of the functioning of the system. From this point of view, the class diagram is a further development of the conceptual model of the designed system. At this stage, knowledge of the OOP approach and design patterns is fundamental.
Statechart diagram
The main purpose of this diagram is to describe the possible sequences of states and transitions that collectively characterize the behavior of the model element during its life cycle. A state diagram represents the dynamic behavior of entities, based on the specification of their response to the perception of certain specific events.
Sequence diagram
For modeling the interaction of objects in the UML language, the corresponding interaction diagrams are used. The interaction of objects can be viewed in time, and then a sequence diagram is used to represent the temporal characteristics of the transmission and reception of messages between objects. Interacting objects exchange some information among themselves. In this case, the information takes the form of complete messages. In other words, although the message has informational content, it acquires an additional property to exert a directional influence on its recipient.
Collaboration diagram (collaboration diagram)
On the cooperation diagram, rectangles depict objects participating in an interaction, containing the name of the object, its class and, possibly, attribute values. As in the class diagram, the associations between objects are indicated in the form of various connecting lines. In this case, you can explicitly specify the names of the associations and the roles played by the objects in the given association.
In contrast to the sequence diagram, only relations between objects that play certain roles in the interaction are depicted in the cooperation diagram.
Component diagram
The component diagram, unlike the previously considered diagrams, describes the features of the physical representation of the system. The component diagram allows you to define the architecture of the system being developed by establishing dependencies between software components, in the role of which source, binary and executable code can act. In many development environments, a module or component corresponds to a file. The dashed arrows connecting the modules show the relationship of interdependence, similar to those that occur when compiling the source code of programs. The main graphic elements of the component diagram are components, interfaces and dependencies between them.
Deployment diagram
The deployment diagram is intended for visualization of program elements and components that exist only at the stage of its execution (runtime). In this case, only the components of the program are represented, which are executable files or dynamic libraries. Those components that are not used at runtime are not shown in the deployment diagram.
The deployment diagram contains graphic representations of the processors, devices, processes, and the connections between them. Unlike the logical presentation diagrams, the deployment diagram is uniform for the system as a whole, since it must fully reflect the features of its implementation. This diagram, in fact, completes the OOAA process for a specific software system, and its development is usually the last step in the model specification.
This concludes the overview of diagrams in particular and design in general. It is worth noting that the design process has long become a software development standard, but often we have to deal with a beautifully written program that, due to the lack of normal documentation, becomes cluttered with unnecessary side functionality, crutches, becomes cumbersome and loses its former quality. = (
I am convinced that the programmer is first and foremost a coder - he should NOT communicate with the customer, should NOT think about the system architecture, should not invent an interface to the program, he should only code - implement algorithms, functionality, appearance, usability, but no more ... From the abstract diagrams (describing the subject area) to the diagrams representing the structure of the data, the classes and the processes of their interaction, the designer must, in detail, step by step, describe everything. That is, the complexity of the work and the salary of the designer must be much higher than the programmer == coder. Sorry for sedition ....
Source: https://habr.com/ru/post/74330/
All Articles