Basic principles of constructing an object model. Building an object model of an existing business process
Construction object model tasks using the UML modeling language.
WORK IS DONE IN StarUML
Lead time:
2 – 3 lessons
To defend your work, you must provide a project created in the Rational Rose package, including three types of diagrams: use cases, classes (interface, data) and sequences for each function.
EXAMPLE TASK:
It is necessary to ensure that the following information is stored in the database:
- student information
o Full name,
o address,
o record number,
o group);
- information about specialties
o name of specialty,
o cipher;
- information about groups
o speciality,
o year of admission,
o group number.
Ensure the issuance of a “Group List” document containing the following fields:
· Full name,
· record number.
Work order
The construction of the object model is carried out in the Rational Rose package. To do this, let's create an empty project. You should start your work with a use case diagram. It is built in the Main area of the Use Case View section, as shown in Fig. 9.
Before starting to build a diagram, it is necessary to define the roles of system users (actors) and their functions (use cases). In our case, two actors work with the system: “Employee of the educational department” and “Employee of the dean’s office.” The functions of an employee of the educational department include maintaining a list of specialties (under maintaining a list we will understand adding records, adjusting them and deleting them). The functions of the dean's office employee include maintaining a list of students and maintaining a list of groups.
The constructed diagram is shown in Fig. 10.
Next, in the Logical View section, you should create two class diagrams. To do this, you can create two packages. The first diagram should contain the interface classes of the application being designed (see Figure 11). In this figure, in the “List of Groups” and “List of Students” classes, the operations of adding, changing and deleting are omitted to avoid cluttering the figure. The group list (lower class) is the output document (it is preceded by the “Group Selection” class, since it is necessary to obtain a list of students in a certain group). The second diagram is database entities (see Fig. 12).
The constructed class diagram displays all forms of the future application and their relationships.
You should enter key fields and establish a connection (from the arrow context menu - Multiplicity).
The next stage of building an object model is creating sequence diagrams. Sequence diagrams are created for each use case in the use case diagram. To add a sequence diagram to a use case, you need to select it in the tree and call it context menu(NewàSequence Diagram) as shown in Fig. 13.
An example of a sequence diagram for the “Maintaining a list of specialties” precedent is shown in Fig. 14.
It should be noted that when constructing this type of diagram for the output document “Group List”, in our case, you should first select the group on the “Group Selection” form (this, in turn, should receive data from the “Group” entity), and then display the output form document, to which data comes from the “Student” entity.
With an object-oriented approach, the analysis of system requirements comes down to the development of models of this system. A model of a system (or any other object or phenomenon) is a formal description of a system that identifies the main objects that make up the system and the relationships between these objects. Model building is a widespread way of studying complex objects and phenomena. The model omits numerous details that make it difficult to understand. Modeling is widespread in both science and technology.
Models help:
Check the performance of the system being developed at the early stages of its development;
Communicate with the system customer, clarifying his requirements for the system;
Make (if necessary) changes to the system design (both at the beginning of its design and at other phases of its life cycle).
Currently, there are several technologies for object-oriented development of application software systems, which are based on the construction and interpretation of models of these systems on a computer. This project uses one of them - OMT (Object Modeling Techniques). In addition, an object model diagram was constructed in UML.
The object model describes the structure of the objects that make up the system, their attributes, operations, and relationships with other objects. The object model should reflect those concepts and objects of the real world that are important for the system being developed. The object model reflects, first of all, the pragmatics of the system being developed, which is expressed in the use of application domain terminology associated with the use of the system being developed.
Defining Object Model Classes
Analysis of external requirements for the designed system makes it possible to determine objects and classes of objects associated with the applied problem that this system must solve. All classes must be meaningful in the application domain in question; classes associated with computer implementation, such as list, stack, etc. should not be administered at this stage.
Let's start by identifying possible classes from the written statement applied problem. When identifying possible classes, you should try to identify as many classes as possible, writing down the name of each class that comes to mind. In particular, each noun appearing in the preliminary statement of the problem can have a corresponding class. Therefore, when identifying possible classes, each such noun is usually associated with a possible class.
As a result, we get the following list of possible class names:
Another proxy;
Document;
Remote Web server;
Configuration;
Information about the document;
Information about the remote Web server;
Request header;
Response header.
Object Model
Object-oriented technology is based on the so-called object model. The main principles of its construction are: abstraction, encapsulation, modularity, hierarchy, typing, parallelism and persistence. Each of these principles in itself is not new, but in the object model they are applied together for the first time.
Object-oriented analysis and design are fundamentally different from traditional structural design approaches: here you need to think differently about the decomposition process, and the architecture of the resulting software product largely goes beyond the concepts traditional for structured programming. The differences are due to the fact that structured design is based on structured programming, while object-oriented design is based on object-oriented programming methodology.
Structural design methods help simplify the development process of complex systems by using algorithms as ready-made building blocks. Likewise, object-oriented design techniques are designed to help developers apply powerful means of expression object and object-oriented programming, using classes and objects as blocks.
. (object-oriented analysis, OOA) is aimed at creating models of reality based on an object-oriented worldview.
Object-oriented analysisis a methodology in which system requirements are perceived in terms of classes and objects identified in subject area.
. ( object-oriented design, OOD )
Programming primarily involves the correct and effective use of the mechanisms of specific programming languages. Design, on the other hand, focuses on the correct and efficient structuring of complex systems. Let's define object-oriented design as follows:
Object-Oriented Designis a design methodology that combines the process of object decomposition and methods of representing logical and physical, as well as static and dynamic models of the designed system.
IN this definition contains two important parts: object-oriented design
1) is based on object-oriented decomposition;
2) uses a variety of techniques for representing models that reflect the logical (classes and objects) and physical (modules and processes) structure of the system, as well as its static and dynamic aspects.
It is object-oriented decomposition that distinguishes object-oriented design from structural design; in the first case, the logical structure of the system is reflected by abstractions in the form of classes and objects, in the second - by algorithms.
. (object-oriented programming, OOP)
Object-oriented programmingis a programming methodology based on representing a program as a collection of objects, each of which is an instance of a specific class, and the classes form an inheritance hierarchy.
This definition can be divided into three parts:
1) OOP uses as basic elements objects, not algorithms;
2) each object is copy any specific class;
3) classes are organized hierarchically.
A program will be object-oriented only if all three specified requirements are met. In particular, programming that is not based on hierarchical relationships does not belong to OOP, but is called programming based abstract types data.
There are five main types of programming styles, which are listed below along with the types of abstractions inherent in them:
It is impossible to recognize any one programming style as the best in all areas. practical application. For example, a rule-oriented style is more suitable for designing knowledge bases, while a procedure-oriented style is more suitable for computing tasks. Based on accumulated experience, the object-oriented style is the most suitable for the widest range of applications; indeed, this paradigm often serves as the architectural foundation upon which other paradigms are built.
Each programming style has its own conceptual basis. Each style requires its own state of mind and way of perceiving the problem being solved. For the object-oriented style, the conceptual basis is object model. It has four main elements:
- abstraction;
- encapsulation;
- modularity;
- hierarchy.
These elements are main in the sense that without any of them the model will not be object-oriented. In addition to the main ones, there are three additional elements:
- typing;
- parallelism;
- preservation.
By calling them optional, we mean that they are useful in the object model, but not required.
Abstraction identifies the essential characteristics of some object that distinguish it from all other types of objects and, thus, clearly defines its conceptual boundaries from the point of view of the observer.
The abstraction is based on the concepts of client and server.
Client Any object that uses the resources of another object (called server).
We will characterize the behavior of an object by the services it provides to other objects and the operations it performs on other objects. This approach focuses attention on the external manifestations of the object and leads to the idea contract model programming, when the external manifestation of an object is considered from the point of view of its contract with other objects, in accordance with this its internal structure(often in interaction with other objects). The contract records all obligations that the server object has to the client object. In other words, this contract defines responsibility object, that is, the behavior for which it is responsible.
Each operation covered by this contract is uniquely defined by its formal parameters and return type. The complete set of operations that a client can perform on another object, together with in the right order, in which these operations are called is called protocol. The protocol reflects everything possible ways, by which an object can act or be affected. It thus completely determines the external behavior of the abstraction from a static and dynamic point of view.
Encapsulation is the process of separating from each other the elements of an object that determine its structure and behavior. Encapsulation serves to isolate the contractual obligations of an abstraction from their implementation.
Abstraction and encapsulation are complementary: abstraction focuses on the observable behavior of an object, while encapsulation deals with the internal structure. Most often, encapsulation is performed by hiding information, that is, masking all internal parts that do not influence external behavior. Typically, both the internal structure of an object and the implementation of its methods are hidden. In practical terms, this means that there are two parts to a class: an interface and an implementation. Interface reflects the external behavior of an object, describing the abstraction of the behavior of all objects of this class. Internal implementation describes the representation of this abstraction and the mechanisms for achieving the desired behavior of the object. The principle of separating the interface and implementation corresponds to the essence of things: everything related to interaction is collected in the interface part of this object with any other objects; the implementation hides from other objects all details that are not related to the process of interaction between objects.
Modularity - this is a property of a system that has been decomposed into internally coherent, but weakly interconnected modules.
In the process of dividing a system into modules, two rules can be useful. First, because modules serve as elementary and indivisible program blocks that can be reused throughout the system, the distribution of classes and objects among modules must take this into account. Secondly, many compilers create a separate code segment for each module. Therefore, there may be restrictions on module size. The dynamics of subroutine calls and the layout of declarations within modules can greatly affect link locality and page management virtual memory. When procedures are poorly modularized, mutual calls between segments become more frequent, which leads to loss of cache efficiency and frequent page changes.
It is quite difficult to bring together such contradictory requirements, but the main thing is to understand that the isolation of classes and objects in a project and the organization of a modular structure is independent actions. The process of isolating classes and objects is part of the logical design process of a system, and dividing into modules is a stage of physical design. Of course, sometimes it is impossible to complete the logical design of a system without completing the physical design, and vice versa. These two processes are performed iteratively.
Hierarchy - this is the ordering of abstractions, their arrangement by levels.
The main types of hierarchical structures in relation to complex systems are the class structure (the "is-a" hierarchy) and the object structure (the "part of" hierarchy).
An important element object-oriented systems and the main type of "is-a" hierarchy is the concept of inheritance mentioned above. Inheritance means a relationship between classes (parent/child relationship) in which one class borrows a structural or functional part of one or more other classes (respectively, single And multiple inheritance). In other words, inheritance creates a hierarchy of abstractions in which subclasses inherit the structure of one or more superclasses. Often a subclass builds on or rewrites components of a higher class.
While the "is a" hierarchy defines the generalization/specialization relationship, the "part of" relationship introduces the aggregation hierarchy. In the "part of" hierarchy, a class is at a higher level of abstraction than any used to implement it.
Typing is a way to protect against the use of objects of one class instead of another, or at least to control such use.
Parallelism - this is a property that distinguishes active objects from passive ones.
Storability - the ability of an object to exist in time, surviving the process that gave birth to it, and (or) in space, moving from its original address space.
Now we have everything necessary concepts to describe the process of building an object model. This process includes the following steps:
· definition of objects and classes;
· preparation of a data dictionary;
· determination of dependencies between objects;
· determination of object attributes and connections;
· organization and simplification of classes when using inheritance;
· further research and improvement of the model.
2.2.1. Definition of classes. Analysis of external requirements for the designed PS allows one to determine objects and classes of objects associated with the applied problem that this system must solve. All classes must be meaningful in the application domain in question; classes associated with computer implementation, such as list, stack, etc. should not be administered at this stage.
You need to start by identifying possible classes from the written statement of the applied problem ( terms of reference and other documentation provided by the customer). It should be borne in mind that this is a very difficult and responsible stage of development, since the future fate of the project largely depends on it.
When identifying possible classes, you should try to identify as many classes as possible, writing down the name of each class that comes to mind. In particular, each noun appearing in the preliminary statement of the problem can have a corresponding class. Therefore, when identifying possible classes, each such noun is usually associated with a possible class.
· redundant classes: if two or more classes express the same information, only one of them should be retained;
· irrelevant(not directly related to the problem) classes: For each possible class name, it is evaluated how necessary it is in future system(this is often very difficult to assess); irrelevant classes are excluded;
· ill-defined(from the problem point of view) classes(see clause 2.3.1);
· attributes: some nouns correspond more to attributes rather than classes; such nouns, as a rule, describe the properties of objects (for example, name, age, weight, address, etc.);
· operations: some nouns correspond more to operation names than to classes (for example, telephone_call is unlikely to denote any class);
· roles: Some nouns define the names of roles in the object model (for example, owner, driver, boss, employee; all of these names are associated with roles in various object dependencies of the person class);
· implementation structures: Names more related to programming and computer hardware should not be on at this stage compare classes, since they do not reflect the features of the designed substation; examples of such names: subroutine, process, algorithm, interrupt, etc.
After eliminating the names of all unnecessary (superfluous) possible classes, a preliminary list of classes that make up the designed system will be obtained.
2.2.2. Preparing the data dictionary. Individual words have too many interpretations. Therefore, it is necessary to prepare at the very beginning of design data dictionary, containing clear and unambiguous definitions of all objects (classes), attributes, operations, roles and other entities considered in the project. Without such a dictionary, discussing the project with fellow developers and system customers is meaningless, since everyone can interpret the terms discussed in their own way. For an example of a dictionary, see paragraph 2.3.2.
2.2.3. Definition of dependencies. On next stage When building an object model, dependencies between classes are determined. First of all, attributes that are explicit links to other classes are excluded from classes; such attributes are replaced by dependencies. The point of this replacement is that dependencies represent an abstraction at the same level as classes, and therefore do not have a direct impact on future implementation (a reference to a class is just one way to implement dependencies).
In the same way that the names of possible classes were obtained from the nouns found in the preliminary statement of the application problem, the names of possible dependencies can be obtained from verbs or verb phrases appearing in the specified document. This is how they usually describe: physical position (follows_behind, is_part, is_contained), directed action (leads_to_movement), communication (talks_to), belonging (has, is_part), etc. An example of identifying explicit and implicit verb phrases from a preliminary formulation of a specific applied problem is discussed in section 2.3.3.
You should then remove unnecessary or incorrect dependencies using the following criteria:
· dependencies between excluded classes must be excluded or reformulated in terms of the remaining classes (see clause 2.3.3);
· irrelevant dependencies and implementation dependencies must be excluded (see clause 2.3.3);
· actions: the dependency should describe the structural properties of the application domain, and not unimportant events (see clause 2.3.3);
· training dependencies: most of the dependencies between three or a large number classes can be decomposed into several binary dependencies, using qualifiers if necessary (see section 2.3.3); in some (rare) cases such decomposition cannot be carried out; for example, the trenary dependence “The professor is teaching a course in room 628” cannot be decomposed into binary ones without loss of information;
· derived dependencies: it is necessary to exclude dependencies that can be expressed through other dependencies, since they are redundant (see section 2.3.3); when excluding redundant (derived) dependencies, you need to be especially careful, since not all duplicating dependencies between classes are redundant; in some cases, other dependencies allow us to establish only the existence of another derived dependence, but do not allow us to establish the multiplicity of this dependence; for example, in the case shown in Fig. 2.36, the company has many employees and owns many computers; each employee is provided with personal use several computers, in addition, there are public computers; the dependency multiplicity provided_for_use cannot be inferred from the dependencies serves and owns; Although derived dependencies do not add new information, they are often convenient; in these cases they can be indicated on the diagram by marking them with a slash.
Rice. 2.36. Non-redundant dependencies
Having removed redundant dependencies, you need to clarify the semantics of the remaining dependencies as follows:
· misnamed dependencies: they should be renamed so that their meaning becomes clear (see clause 2.3.3);
· role names: you need to add role names where necessary; the role name describes the role played by the corresponding class in a given dependency from the point of view of another class participating in that dependency; if the role name is clear from the class name, it can be omitted (see section 2.3.3);
· qualifiers: By adding qualifiers where necessary, we introduce elements of context, which allows us to achieve unambiguous identification of objects; qualifiers also make it possible to simplify some dependencies by reducing their multiplicity;
· multiplicity: it is necessary to add designations for the multiplicity of dependencies; It should be remembered that the multiplicity of dependencies may change in the process of further analysis of system requirements;
· unaccounted dependencies must be identified and added to the model.
2.2.4. Attribute clarification. At the next stage, the attribute system is clarified: class attributes are adjusted, and new attributes are introduced, if necessary. Attributes express the properties of objects of the class in question, or determine their current state.
Attributes usually correspond to nouns; for example, car_color (object property), cursor_position (object state). Attributes, as a rule, have little effect on the structure of the object model.
You should not try to define as many attributes as possible: large number attributes complicates the model and makes it difficult to understand the problem. It is necessary to enter only those attributes that are relevant to the designed application system, omitting random, unimportant and derived attributes.
Along with the attributes of objects, it is also necessary to enter attributes of dependencies between classes (relationships between objects).
When specifying attributes, they are guided by the following criteria:
· Replacing attributes with objects. If the presence of some entity is more important than its value, then it is an object; if the value is more important, then it is an attribute: for example, a boss is an object (it doesn’t matter who the boss is, the main thing is that someone is), salary is an attribute ( its significance is very significant); city is always an object, although in some cases it may seem that it is an attribute (for example, city as part of a company's address); in cases where you want city to be an attribute, you should define a dependency (say, located) between the classes firm and city.
· Qualifiers. If the value of an attribute depends on a specific context, it should be made a qualifier (see section 2.3.4).
· Names. Names are usually better matched by qualifiers than by object attributes; in all cases when a name allows one to select from objects of a certain set, it should be made a qualifier (see section 2.3.4).
· Identifiers. Object identifiers are associated with their implementation. In the early stages of design they should not be considered as attributes.
· Link Attributes. If some property characterizes not the object itself, but its connection with another object (objects), then this is a connection attribute, not an object attribute.
· Internal values. Attributes that define only the internal state of an object, invisible outside the object, should be excluded from consideration.
· Unimportant details. It is recommended to omit attributes that do not affect the execution of most operations.
2.2.5. Organizing a class system using inheritance. Next, you need to try to find superclasses for the introduced classes. This is useful because it clarifies the structure of the model and makes subsequent implementation easier. The example is discussed in paragraph 2.3.5.
2.2.6. Further research and improvement of the model. Only in very rare cases does the constructed object model immediately turn out to be correct. The model must be researched and debugged. Some errors can be found when examining a model without a computer, others - when interpreting it together with dynamic and functional models on a computer (these models are built after the object model has already been built).
Here we will look at techniques for computer-free search and correction of errors in the object model. They are based on external signs that can be used to find errors in the model; these signs can be combined into the following groups.
Signs of a missing object (class):
· asymmetry of connections and generalizations (inheritance); to fix the error you need to add the missing classes;
· mismatch between attributes and operations of a class; to correct the error, it is necessary to split the class into several other classes so that the attributes and operations of the new classes correspond to each other;
· an operation has been detected that does not have a satisfactory target class; To fix the error, you need to add the missing target class;
· several dependencies with the same names and purposes were found; To fix the error, you need to generalize and add the missing superclass.
Signs of an unnecessary (superfluous) class:
· lack of attributes, operations and dependencies of a certain class; To correct the error, you need to consider whether such a class should be excluded.
Signs of missing dependencies:
· there are no access paths to operations; To fix the error, you need to add new dependencies that provide the ability to service the corresponding requests.
Signs of unnecessary (superfluous) dependencies:
· redundant information in dependencies; to correct the error, it is necessary to exclude dependencies that do not add new information, or mark them as derived dependencies;
· there are not enough operations crossing the dependency; To correct the error, you need to consider whether such a dependency should be excluded.
Signs of improper dependency placement:
· role names are too broad or too narrow for their classes; To fix the error, you need to move the dependency up or down the class hierarchy.
Signs of incorrect attribute placement:
· there is no need to access an object by the values of one of its attributes; To fix the error, you need to consider whether you need to introduce a qualified dependency.
For examples of practical application of the described features, see paragraph 2.3.6.
Example object model
Let's consider the process of building an object model for a banking service system in the process of analyzing requirements and preliminary design of this system. To build an object model of the system under consideration, we need to complete all the steps listed in paragraph 2.2.
2.3.1. Definition of objects and classes. In clause 1.3, the task is formulated and a diagram of the banking service network is shown (Fig. 1.3). By analyzing this statement of the problem, it is possible to identify possible classes by matching them with the nouns mentioned in its preliminary formulation; you will get the following list of possible class names (in alphabetical order):
We examine this list, excluding class names from it in accordance with the recommendations of paragraph 2.2.1:
· redundant classes: It is clear that client and user mean the same concept; for the banking system it is more natural to leave the client class;
· irrelevant classes: such a class is the price class (it is not directly related to the work banking network);
· ill-defined classes: such classes are record_keeping_service and security check (these services are part of the posting), system (in our case it is not clear what this is), banking_network (the entire PS will serve the banking network);
· attributes: transaction data, account data, money (meaning real money given to the client by a cashier or ATM, or accepted by the cashier), receipt (issued to the client along with the money) is more natural to have as attributes;
· implementation structures express names such as software_software and access; they should also be excluded from the list of possible class names.
After eliminating all unnecessary names of possible classes, we obtain the following list of classes that make up the designed banking system (these classes are presented in Fig. 2.5):
2.3.2. Preparing the data dictionary. Here is a part of the data dictionary containing definitions of the classes used in the project.
ATM (ATM) is a terminal that allows the client to make his own transactions using his card for identification. ATM (ATM) interacts with the customer to receive necessary information for posting, sends posting information to the central_computer so that it checks it and subsequently uses it when performing posting and issues money and a receipt to the client. It is assumed that the ATM (automated teller machine) does not need to operate independently of the network.
A bank is a financial institution that holds accounts for its customers and issues cards authorizing access to accounts through an ATM (automated teller machine) network.
Card - plastic card, delivered by a bank to its client, which authorizes access to accounts through the ATM (automated teller machine) network. Each card contains a bank code and card number, encoded in accordance with national standards for bank cards. The bank_code uniquely identifies the bank within the consortium. The card_number determines the accounts to which the card has access. The card does not necessarily provide access to all customer accounts. Each card can only be owned by one customer, but multiple copies may exist, so consideration should be given to the possibility of using the same card from different ATMs (automated teller machines) at the same time.
A cashier is a bank employee who has the right to make transactions from cash terminals, as well as accept and issue money and checks to customers. Transactions, money and checks that each cashier works with must be recorded and correctly accounted for.
Cash_terminal - the terminal from which the cashier makes transactions for clients. When the cashier accepts and issues money and checks, the POS terminal prints receipts. The POS terminal interacts with the bank_computer to verify and post transactions.
Client is the holder of one or more bank accounts. The client may consist of one or more individuals or organizations. The same person holding an account in another bank is treated as a different client.
Bank_computer is a computer owned by the bank that interacts with the ATM (ATM) network and the bank's own cash_terminals. The bank may have its own internal computer network to process invoices, but here we are only considering the bank_computer that communicates with the ATM network.
A consortium is an association of banks that ensures the operation of the ATM (ATM) network. The network transmits bank transactions to the consortium.
Posting is a single integrated request to perform a certain sequence of operations on the accounts of one client. It has been assumed that ATMs (automated teller machines) only dispense money, but they should not exclude the possibility of printing checks or accepting money and checks. We would also like to ensure the flexibility of the system, which in the future will provide the ability to simultaneously process accounts from different clients, although this is not required yet. The various operations must be properly balanced.
Account - a single bank account over which postings are made. Accounts may be various types; a client can have several accounts.
Central_computer - a computer owned by a consortium that distributes transactions and their results between ATMs (ATMs) and bank_computers. The central_computer checks bank codes but does not post.
2.3.3. Definition of dependencies. Following the recommendations of paragraph 2.2.3, we distinguish explicit and implicit verb phrases from the preliminary statement of the problem and consider them as names of possible dependencies. From the formulation of the problem of the banking network (see section 1.3), the following expressions can be extracted:
Verb phrases (explicit and implicit):
Banking network includes cashiers and ATMs
Consortium distributes results of transactions via ATM
Bank owns bank computer
Bank computer supports accounts
Bank owns cash terminals
Cash terminal interacts with bank computer
Cashier enters posting to the invoice
ATM's interact with the central computer during wiring
Central computer interacts with bank computer
ATM accepts card
ATM communicates with user
ATM issues cash
ATM prints receipts
System regulates shared access
Bank provides software
Consortium consists of banks
Consortium owns central computer
System provides logging
System provides safety
Clients have cards
Card provides access to the account
At the bank serve cashiers
Then we exclude unnecessary or incorrect dependencies using the criteria formulated in paragraph 2.2.3:
· dependencies between excluded classes: the following dependencies are excluded: Banking network includes cashiers and ATMs (banking_network class excluded), ATM prints receipts (receipt class excluded), ATM issues cash (class money excluded), System provides logging transactions (record_keeping_service class excluded), System provides security of account management (class security_service excluded), Banks provide software (class software_software excluded);
· irrelevant dependencies and implementation related dependencies: dependency "System" regulates shared access" is excluded as implementation related;
· actions are described by dependencies such as "ATM accepts card" and "ATM communicates with the user"; we exclude these dependencies;
· training dependencies: addiction "Cashier" enters posting on the account" is decomposed into two binary dependencies "Cashier enters wiring" and "Wiring refers to account". Dependency "ATM"s interact with the central computer during wiring" is expanded into "ATM"s interact with central computer" and "Wiring starts with ATM";
· derived dependencies: dependency "Consortium" distributes ATM's are a consequence of the Consortium dependencies owns central computer" and "ATM"s interact with a central computer."
By removing redundant dependencies, we get the following list of dependencies:
Bank owns bank computer
Bank computer supports accounts
Bank owns cash terminals
Cash terminal interacts with bank computer
Cashier enters wiring
Wiring refers to account
ATM's interact with central computer
Wiring begins with ATM
Central computer interacts with bank computer
Consortium consists of banks
Consortium owns central computer
Clients have cards
Card provides access to the account
At the bank serve cashiers
Let us clarify the semantics of the remaining dependencies as follows:
· let's rename incorrectly named dependencies so that their meaning becomes clearer; so dependency Computer_bank supports it is more convenient to replace the accounts with the Bank dependency holds accounts.
· role names may not be used, since they are clear from the names of the classes involved in the dependency, such as for the ATM dependency interact with a central computer;
· unaccounted dependencies: Wiring begins from cash_terminal, Clients have Accounts, Posting registered card should be added to the model.
After specifying the dependencies, you can create original version object diagram. For the problem under consideration, it will have the form shown in Fig. 2.37.
Rice. 2.37. First version of the object diagram for the banking network
2.3.4. Attribute clarification. Applying the criteria formulated in clause 2.2.4, we obtain:
The card contains the bank_code and card_code; they can be considered attributes of objects of the card class, but it is more convenient to use them as qualifiers, since the bank_code ensures the choice of bank, reducing the multiplicity of the consortium - bank relationship; For similar use card_code you need to add a dependency Bank issues cards, the qualifier of which will be card_code.
After making the above changes, the diagram will take the form shown in Fig. 2.38.
2.3.5. Organizing a class system using inheritance. In the example under consideration, it is natural to define superclasses for objects that define various terminals: cash_terminal and ATM (ATM), and for objects that define transactions: cashier_transaction and remote_transaction (from an ATM).
Having made the appropriate changes, we obtain the object diagram shown in Fig. 2.39.
Rice. 2.38. Object diagram for a banking network after specifying attributes and adding qualifiers
Rice. 2.39. Object diagram for banking taking into account inheritance
2.3.6. Further improvement of the model. The card acts in two entities: as a registration unit in the bank (passbook), which provides the client with access to his accounts, and as a data structure with which ATM works. Therefore, it is convenient to split the card class into two classes: registration_card and card; the first of these classes provides the client with access to his bank accounts, and the second defines the data structure with which ATM works.
It is convenient to imagine the posting class as an aggregation of change classes, since posting is an agreed upon sequence of making changes to accounts and other banking documents; When working with bank documents, three types of changes are considered: withdrawal, placement and request.
It is natural to combine the bank class with the computer_bank class, and the consortium class with the central_computer class.
Rice. 2.40. Final view of the object diagram for the banking network
After making the above changes, the object diagram will take the form shown in Fig. 2.40. This completes the construction of the object model of the preliminary design stage. Further refinements of the object model will be carried out at the next phases of the system lifecycle.
Isolation of subsystems
2.4.1. The concept of a subsystem. So, the PS is a set of interdependent objects. Each object is characterized by a set of attributes, the values of which determine the state of the object, and a set of operations that can be applied to this object. When developing a software system, it is convenient to assume that all attributes of objects are closed (that is, they are not accessible outside the object, and in order to find out the value of an attribute of another object in an object, or change it, it is necessary to use one of the public operations of this object, if, of course, such an operation is defined). Object operations can be either public or private.
Thus, each object has a strictly defined interface, i.e. a set of public operations that can be applied to this object. All objects of the same class have the same interface. The interface of a class (and, consequently, of each object of this class) is specified by a list of signatures of its open (public) operations (and methods that implement them); signatures of closed operations are not included in the interface of objects of the corresponding class.
The system object model specifies the set of interdependent objects that make up the system, and therefore defines the set of interfaces available within the system. All data processing capabilities within the system (i.e., in each object that is part of the system) are determined by this set of interfaces, which defines internal environment(or Wednesday) systems.
Along with the internal environment of the system, it is possible to determine its external environment. It is determined by the functions (operations) implemented as part of the system software(i.e. operating system, programming system, various editors, DBMS, etc.), as well as in other application systems and libraries used in conjunction with the system. Objects and operations that make up the external environment of the system can also be accessed within the system. To keep this in mind, we could add another object to the object model whose interface would represent the environmental capabilities used in the system (such an interface usually represents only a part of the external environment's capabilities). But this would not be entirely accurate, since the external environment is realized not by one, but by several objects. On the other hand, inside the system there is no reason to consider the structure of its external environment. The way out of this contradiction is to introduce another entity into consideration - a subsystem.
Subsystem is a set of objects and subsystems that provide some functionality and interact with each other in accordance with their interfaces. Subsystem interface represents subset combining the interfaces of all objects and subsystems that make up this subsystem. A subsystem may include one or more interdependent objects and/or subsystems.
The set of interfaces of objects (and subsystems), which together constitute a certain subsystem, constitutes internal environment this subsystem. Each subsystem must include an environment subsystem representing external environment this subsystem. The environment subsystem for the banking service system, considered as an end-to-end example, is shown in Fig. 2.41. The interface of the environment subsystem determines in which software environment the designed system will operate and what capabilities of this environment will be used during its operation (this is important when there is a need to modify or replace individual components of the environment).
Note that the environment subsystem represents only the interface of the banking service system with its external environment. The external environment of the banking service system consists of several subsystems and libraries, and an object model can also be developed for it, which can also contain the system being developed (in this object model it will be one of the subsystems).
The object model of the banking service system and its system (external) environment can also be depicted in the form of an object diagram (however, this object diagram will not include objects, but only subsystems; each subsystem is depicted on the diagram as a rectangle with double vertical sides). The dependencies between the subsystems depicted in this object diagram (Fig. 2.42) reflect the interaction of the designed banking system and the corresponding subsystems during the operation of the system. This determines the requirements of the designed system for its system environment.
Rice. 2.41. Object diagram of the banking network, which indicates the interface with the system environment
Rice. 2.42. Object diagram of a banking network and its system environment
The introduction of the concept of a subsystem and the ability to include subsystems in the object model along with objects (classes) defines the hierarchical structure of the object model and allows the use of the OMT methodology when designing fairly complex software systems containing a large number of different objects and classes.
2.4.2. Interfaces and environments. The objects and subsystems that make up a higher-level subsystem will be called components the last one. As already noted, for each component that is part of the subsystem object model, its interface, i.e. a set of open (public) operations that can be applied to this component (object or subsystem).
Object Interface is defined by the interface of the corresponding class and is specified by a list of signatures of its public operations (methods). Subsystem interface is defined through the interfaces of its constituent objects and subsystems as follows: an operation can be included in the interface of a subsystem if this subsystem contains an object (subsystem) whose interface contains this operation. Interfaces are described in an interface description language IDL (Interface Definition Language).
All data processing capabilities within the subsystem (i.e., in each component included in its composition) are determined by a set of interfaces of its components, which determines internal environment of the subsystem.
If for some subsystem it turns out that none of its components contains an operation that it is desirable to include in its interface, an object that implements such an operation can be added to its composition. Such an object is called interface object. Interface objects allow you to coordinate the external interface of a subsystem with its external environment, i.e. with interfaces of other objects and subsystems, which, together with the subsystem in question, constitute a higher-level subsystem.
Let us explain the introduced concepts using the example of a banking service system. In its composition, one can distinguish the bank subsystem (in fact, the system will have several copies of the bank subsystem - one for each bank included in the consortium). In this case, the object model of the system will take the form shown in Fig. 2.43.
Rice. 2.43. Object diagram of the banking network after highlighting the bank subsystem
At the same time, the external interfaces of the bank and environment subsystems, together with the interfaces of the ATM and consortium objects, form the internal environment of the banking service system. Its external environment is shown in Fig. 2.42; it consists of external interfaces various software systems used in the banking system (the figure shows only a part of these systems), and its own external interface.
The conceptual basis of the object-oriented approach is the object model. The main principles of its construction are:
· abstraction;
· encapsulation;
· modularity;
· hierarchy.
Abstraction is the selection of the most important, essential characteristics of some object, which distinguish it from all other types of objects and, thus, clearly define its conceptual boundaries from the point of view of further consideration and analysis, and ignoring less important or insignificant details.
Abstraction allows you to manage the complexity of the system by focusing on the essential properties of the object. Abstraction focuses attention on external features object and allows you to separate the most essential features of its behavior from the details of their implementation. Selecting the right set of abstractions for a given problem domain is the main challenge of object-oriented design. Abstraction depends on the domain and point of view - what is important in one context may not be important in another. Objects and classes are the basic abstractions of a domain.
Encapsulation is the physical localization of properties and behavior within a single abstraction (considered a "black box"), hiding their implementation behind a public interface.
Encapsulation is the process of separating from each other individual elements object that determines its structure and behavior. Encapsulation serves to isolate an object's interface, which reflects its external behavior, from the object's internal implementation. The object approach assumes that its own resources, which can only be manipulated by the operations of the object itself, are hidden from the external environment. Abstraction and encapsulation are complementary: abstraction focuses attention on the external features of an object, while encapsulation (or otherwise restricting access) prevents user objects from discerning the internal structure of the object.
Encapsulation is similar to the concept of information hiding. This is the ability to hide numerous details of an object from the outside world. The external world of an object is everything that is outside of it, including the rest of the system. Information hiding provides the same benefit as encapsulation: flexibility.
Modularity is a property of a system associated with the possibility of its decomposition into a number of internally strongly coupled, but weakly interconnected subsystems (modules).
Modularity reduces system complexity by allowing independent development of individual modules. Encapsulation and modularity create barriers between abstractions.
Hierarchy is a ranked or ordered system of abstractions, their arrangement by levels.
The main types of hierarchical structures in relation to complex systems are the class structure (hierarchy by nomenclature) and the structure of objects (hierarchy by composition). Examples of class hierarchies are simple and multiple inheritance (one class uses a structural or functional part, respectively, of one or more other classes), and object hierarchies are aggregation.
Classes can be organized in a hierarchical structure that appearance resembles a classification scheme in conceptual logic. The hierarchy of concepts is constructed as follows. The most general concept or category is taken to be the concept that has the largest volume and, accordingly, the smallest content. This is the most high level abstractions for a given hierarchy. Then given general concept is specified, that is, its volume decreases and its content increases. A less general concept appears, which in the hierarchy diagram will be located one level below the original one. This process of concretizing concepts can be continued until, at the lowest level, a concept is obtained, the further concretization of which in a given context is either impossible or impractical.