Lecture
The Unified Modeling Language (UML) is a standard tool for creating “drawings” of information systems (IS). Using UML, you can visualize, specify, design, and document the elements of these systems.
UML is suitable for modeling any systems: from enterprise-wide information systems to distributed Web applications and even embedded real-time systems. It is a very expressive language, allowing to consider the system from all points of view related to its development and subsequent deployment. Despite the abundance of expressive possibilities, this language is easy to understand and use. It is most convenient to begin the study of UML with its conceptual model, which includes three main elements: basic building blocks, rules defining how these blocks can be combined with each other, and some general language mechanisms.
UML is one of the components of the process of developing an IP. Although UML does not depend on the simulated reality, it is best to apply it when the modeling process is based on consideration of use cases, is iterative and step-by-step, and the system itself has a clearly defined architecture.
UML is a language for visualizing, specifying, constructing and documenting elements of software systems. The language consists of a dictionary and rules that allow you to combine the words in it and get meaningful constructions. In the modeling language, the vocabulary and rules are focused on the conceptual and physical representation of the system. A modeling language like UML is a standard tool for composing “drawings” of an IC.
When creating an IS of any complexity, modeling of the future system is carried out, but in many cases this is done informally, without developing any document. However, this approach is fraught with trouble. First, the exchange of views on the conceptual model is possible only when all participants in the discussion speak the same language. Secondly, it is impossible to get an idea about certain aspects of information systems without a model that goes beyond the boundaries of a text-based programming language. Thirdly, if the author of the code has never embodied the models he conceived, this information will be permanently lost if he changes jobs. At best, it can only be partially recreated based on the implementation.
Using UML allows you to solve the third problem: an explicit model facilitates communication.
Some features of the system are best modeled as text, others graphically. In fact, in all interesting systems there are structures that cannot be represented using only a programming language. UML is a graphical language that allows solving the second of the indicated problems.
UML is not just a set of graphics. Behind each of them is a well-defined semantics. This means that a model written by one developer can be unambiguously interpreted by another - or even an instrumental program. This is how the first of the above problems is solved.
In this context, specification means the construction of accurate, unambiguous and complete models. UML allows you to specify all the essential decisions relating to the analysis, design and implementation that must be made in the process of developing and deploying an information system.
UML is a visual design language, and models created with it can be directly translated into various programming languages of the IC.
When developing an IP, such elements are also created as:
Depending on the adopted development methodology, the performance of some works is performed more formally than others. The elements mentioned are not just supplied components of the project; they are necessary for management, for evaluation of results, and also as a means of communication between team members during system development and after its deployment.
UML solves the problem of documenting the system architecture and all its details, offers a language for formulating system requirements and test definitions, and finally provides the means to simulate work during the project planning and version management stages.
Where UML is used
UML language is intended primarily for the development of information systems. Its use is especially effective in the following areas:
The scope of UML is not limited to software modeling. Its expressiveness makes it possible to simulate, say, document flow in legal systems, the structure and functioning of the patient care system in hospitals, and to design hardware.
UML conceptual model
To understand UML, it is necessary to master its conceptual model, which includes three components: the basic building blocks of the language, the rules for their combination, and some mechanisms common to the whole language. Having mastered these elements, you will be able to read the models in UML and create them yourself - of course, the beginning is not very complicated. As you gain experience in working with a language, you will learn to use its more advanced capabilities.
UML building blocks
UML vocabulary includes three types of building blocks:
Entities are abstractions that are the main elements of the model. Relationships bind different entities; diagrams group entities of interest.
There are four types of entities in UML:
Entities are the basic object-oriented blocks of a language. With their help, you can create correct models. There are seven types of entities:
These seven basic elements — classes, interfaces, collaborations, use cases, active classes, components, and nodes — are the basic structural entities that can be incorporated into the UML model. There are also variations of these entities: actors, signals, utilities (types of classes), processes and threads (types of active classes), applications, documents, files, libraries, pages and tables (types of components).
Behavioral things are the dynamic components of the UML model. These are verbs of the language: they describe the behavior of the model in time and space. There are only two main types of behavioral entities:
These two elements of interaction and automata are the main behavioral entities included in the UML model. Semantically, they are often associated with various structural elements, primarily classes, cooperatives, and objects.
Grouping entities are organizing parts of the UML model. These are the blocks into which the model can be expanded . There is only one primary grouping entity, namely a package.
Packages are the basic grouping entities with which you can organize a UML model. There are also variations of packages, such as frames (Frameworks), models and subsystems.
Annotation entities are explanatory parts of the UML model. These are comments for additional descriptions, explanations or comments on any element of the model. There is only one basic type of annotation elements - a note (Note). A note is simply a symbol to represent comments or constraints attached to an element or group of elements. Graphically, a note is depicted as a rectangle with a curved edge containing a text or graphic comment.
UML defines four types of relationships:
These relationships are the main binding building blocks in UML and are used to create correct models.
The four elements described are the main types of relationships that can be included in UML models. There are also variations of them, such as Refinement, Trace, Include, and Expand (for dependencies).
A diagram in UML is a graphical representation of a set of elements, most often depicted as a connected graph with vertices (entities) and edges (relations). Diagrams are drawn to visualize the system from different points of view. The diagram is in a sense one of the projections of the system. As a rule, with the exception of the most trivial cases, the diagrams give a minimized representation of the elements from which the system is composed. The same element may be present in all diagrams, or only in several (the most common option), or not in one (very rarely). In theory, diagrams can contain any combination of entities and relationships. In practice, however, a relatively small number of type combinations are used, corresponding to the five most commonly used types that make up the information system architecture. Thus, in UML there are nine types of diagrams:
Here is a partial list of diagrams used in UML. Tools allow you to generate other diagrams, but the nine listed are found in practice most often.
UML rules
UML building blocks cannot be arbitrarily combined with each other. Like any other language, UML is characterized by a set of rules that determine how a well-formed model should look, that is, semantically self-consistent and in harmony with all the models that are associated with it.
The UML language has semantic rules that allow you to correctly and unambiguously determine:
The models created in the process of developing information systems evolve over time and can be ambiguously considered by different project participants at different times. For this reason, not only well-designed models are created, but also those that:
The appearance of not too well-designed models is inevitable in the development process, until all the details of the system have been clarified in full. The UML rules encourage - although they do not require - in the course of working on a model, to solve the most important issues of analysis, design and implementation, with the result that the model becomes well formed over time.
Common UML Language Mechanisms
Construction is simplified and carried out more efficiently if you adhere to some agreements. Following certain architectural patterns, you can decorate a building in Victorian or French style. The same principle applies to UML. Working with this language is greatly facilitated by the consistent use of the common mechanisms listed below:
Architecture
To visualize, specify, construct, and document information systems, it is necessary to consider them from different points of view. Everyone who is involved in the project — end users, analysts, developers, system integrators, testers, technical writers, and project managers — pursue their own interests, and everyone looks at the system being created differently at different points in her life. The system architecture is perhaps the most important element that is used to manage all sorts of points of view and thus contributes to the iterative and incremental development of the system throughout its life cycle.
Architecture is a set of essential decisions regarding:
The architecture of the software system covers not only all structural and behavioral aspects, but also its use, functionality, performance, flexibility, reusability, completeness, economic and technological limitations and trade-offs, as well as aesthetic issues.
The use case view covers use cases that describe the system behavior observed by end users, analysts, and testers. This type specifies not the true organization of the software system, but the driving forces on which the formation of the system architecture depends. In UML, static aspects of this type are transmitted by use case diagrams, and dynamic aspects by interaction, state, and action diagrams.
The design view covers the classes, interfaces, and collaborations that form the vocabulary of the problem and the solutions. This type of support primarily supports the functional requirements for the system, that is, those services that it must provide to end users. With the help of the UML language, static aspects of this type can be transmitted by class and object diagrams, and dynamic ones - by interaction, state and action diagrams.
The process view covers the threads and processes that form the parallelism and synchronization mechanisms in the system. This type mainly describes system performance, scalability and bandwidth. In UML, its static and dynamic aspects are visualized by the same diagrams as for the view from the design point of view, but special attention is paid to the active classes that represent the corresponding threads and processes.
The implementation view covers the components and files used to build and release the final software product. This view is intended primarily to manage the configuration of system versions made up of independent (to some extent) components and files, which can be combined in different ways. In UML, static aspects of this view are transmitted using component diagrams, and dynamic aspects using interaction diagrams, states, and actions.
The deployment view covers the nodes that form the hardware topology of the system on which it runs. First of all, it is associated with the distribution, supply and installation of the parts that make up the physical system. Its static aspects are described by deployment diagrams, and dynamic diagrams by interaction diagrams, states and actions.
Each of these types can be considered completely independent, so that persons related to the development of the system can focus on studying only those aspects of the architecture that directly concern them. But we must not forget that these species interact with each other. For example, view nodes from a deployment point of view contain the components described for the view from an implementation point of view, and those in turn represent the physical embodiment of classes, interfaces, cooperatives, and active classes from views from a design and process point of view. UML allows you to display each of the five listed species and their interactions.
Comments
To leave a comment
Analysis and reengineering of business processes
Terms: Analysis and reengineering of business processes