Computer science and programming
Jueves 09 noviembre, 09:44 am
Fuente:
Object-Oriented Software Engineering
-
- Analysis p 173
- Overview of Analysis
- Analysis Concepts pp 176
- Analysis Activities pp 179
Analysis
Analysis results in a model of the system that aims to be correct, complete, consistent, and unambiguous. Developers formalize the requirements specification produced during requirements elicitation and examine in more detail boundary conditions and exceptional cases. Developers validate, correct and clarify the requirements specification if any errors or ambiguities are found. The client and the user are usually involved in this activity when the requirements specification must be changed and when additional information must be gathered. In object-oriented analysis, developers build a model describing the application domain.
Formalization helps identify areas of ambiguity as well as inconsistencies and omissions in a requirements specification. Once developers identify problems with the specification, the address them by eliciting more information from the users and the client. Requirements elicitation and analysis are iterative and incremental activities that occur concurrently.
An Overview of Analysis
Analysis focuses on producing a model of the system, called the analysis model, which is correct, complete, consistent, and verifiable. Analysis is different from requirements elicitation in that developers focus on structuring and formalizing the requirements elicited from users (Figure 5-2).
This formalization leads to new insights and the discovery of errors in the requirements. As the analysis model may not be understandable to the users and the client, developers need to update the requirements specification to reflect insights gained during analysis, then review the changes with the client and the users. In the end, the requirements, however large, should be understandable by the client and the users.
The analysis model is composed of three individual models: the functional model, represented by use cases and scenarios, the analysis object model, represented by class and object diagrams, and the dynamic model, represented by state machine and sequence diagrams (Figure 5-3).
In the previous chapter, we described how to elicit requirements from the users and describe them as use cases and scenarios. In this chapter, we describe how to refine the functional model and derive the object and the dynamic model. This leads to a more precise and complete specification as details are added to the analysis model.
Analysis Object Model
The analysis model represents the system under development from the user’s point of view. The analysis object model is a part of the analysis model and focuses on the individual concepts that are manipulated by the system, their properties and their relationships. The analysis object model, depicted with UML class diagrams, includes classes, attributes, and operations. The analysis object model is a visual dictionary of the main concepts visible to the user.
Dynamic Model
The dynamic model focuses on the behavior of the system. The dynamic model is depicted with sequence diagrams and with state machines. Sequence diagrams represent the interactions among a set of objects during a single use case. State machines represent the behavior of a single object (or a group of very tightly coupled objects). The dynamic model serves to assign responsibilities to individual classes and, in the process, to identify new classes, associations, and attributes to be added to the analysis object model.
Entity, Boundary, and Control Objects
The analysis object model consists of entity, boundary, and control objects [Jacobson et al., 1999]. Entity objects represent the persistent information tracked by the system. Boundary objects represent the interactions between the actors and the system. Control objects are in charge of realizing use cases. In the 2Bwatch example, Year, Month, and Day are entity objects; Button and LCDDisplay are boundary objects; ChangeDateControl is a control object that represents the activity of changing the date by pressing combinations of buttons.Modeling the system with entity, boundary, and control objects provides developers with simple heuristics to distinguish different, but related concepts.
To distinguish between different types of objects, UML provides the stereotype mechanism to enable the developer to attach such meta-information to modeling elements.
For example, in Figure 5-5, we attach the «control» stereotype to the ChangeDateControl object. In addition to stereotypes, we may also use naming conventions for clarity and recommend distinguishing the three different types of objects on a syntactical basis: control objects may have the suffix Control appended to their name; boundary objects may be named to clearly denote an interface feature (e.g., by including the suffix Form, Button, Display, or Boundary); entity objects usually do not have any suffix appended to their name.
Generalization and Specialization
Modeling with UML, inheritance enables us to organize concepts into hierarchies. At the top of the hierarchy is a general concept, and at the bottom of the hierarchy are the most specialized concepts.
Generalization is the modeling activity that identifies abstract concepts from lower-level ones.
Specialization is the activity that identifies more specific concepts from a high-level one.
In some instances, modelers call inheritance relationships generalization-specialization relationships. In this book, we use the term “inheritance” to denote the relationship and the terms “generalization” and “specialization” to denote the activities that find inheritance relationships.
Analysis Activities: From Use Cases to Objects
In this section, we describe the activities that transform the use cases and scenarios produced during requirements elicitation into an analysis model. Analysis activities include:
- Identifying Entity Objects
- Identifying Boundary Objects
- Identifying Control Objects
- Mapping Use Cases to Objects with Sequence Diagrams
- Modeling Interactions among Objects with CRC Cards
- Identifying Associations
- Identifying Aggregates
- Identifying Attributes
- Modeling State-Dependent Behavior of Individual Objects
- Modeling Inheritance Relationships
- Reviewing the Analysis Model
Identifying Entity Objects
Participating objects form the basis of the analysis model. Natural language analysis is an intuitive set of heuristics for identifying objects, attributes, and associations from a requirements specification. Abbott’s heuristics maps parts of speech (e.g., nouns, having verbs, being verbs, adjectives) to model components (e.g., objects, operations, inheritance relationships, classes). Table 5-1 provides examples of such mappings by examining the ReportEmergency use case:
The following heuristics can be used in conjunction with Abbott’s heuristics:
As it was mentioned before, Entity Objects represent the persistent information tracked by the system. For entity objects we recommend always to start with the names used by end users and application domain specialists. Describing objects, even briefly, allows developers to clarify the concepts they use and avoid misunderstandings (e.g., using one object for two different but related concepts).
For example, after a first examination of the ReportEmergency use case (Figure 5-7), we use application domain knowledge and interviews with the users to identify the objects Dispatcher, EmergencyReport, FieldOfficer, and Incident. Note that the EmergencyReport object is not mentioned explicitly by name in the ReportEmergency use case. Step 4 of the use case refers to the emergency report as the “information submitted by the FieldOfficer.” After review with the client, we discover that this information is usually referred to as the “emergency report” and decide to name the corresponding object EmergencyReport.
The definition of entity objects leads to the initial analysis model described in Table 5-2.
Identifying Boundary Objects
Boundary objects represent the system interface with the actors. In each use case, each actor interacts with at least one boundary object. The boundary object collects the information from the actor and translates it into a form that can be used by both entity and control objects.
We find the boundary objects of Table 5-3 by examining the ReportEmergency use case.
We have made progress toward describing the system. We now have included the interface between the actor and the system. We are, however, still missing some significant pieces of the description, such as the order in which the interactions between the actors and the system occur. In the next section, we describe the identification of control objects.
Identifying Control Objects
Control objects are responsible for coordinating boundary and entity objects. Control objects usually do not have a concrete counterpart in the real world. Often a close relationship exists between a use case and a control object; a control object is usually created at the beginning of a use case and ceases to exist at its end. It is responsible for collecting information from the boundary objects and dispatching it to entity objects. For example, control objects describe the behavior associated with the sequencing of forms, undo and history queues, and dispatching information in a distributed system.
We model the control flow of the ReportEmergency use case with a control object for each actor: ReportEmergencyControl for the FieldOfficer and ManageEmergency-Control for the Dispatcher, respectively (Table 5-4).
The decision to model the control flow of the ReportEmergency use case with two control objects stems from the knowledge that the FieldOfficerStation and the DispatcherStation are actually two subsystems communicating over an asynchronous link.
Literature Review by: Larry Francis Obando – Technical Specialist
Escuela de Ingeniería Eléctrica de la Universidad Central de Venezuela, Caracas.
Escuela de Ingeniería Electrónica de la Universidad Simón Bolívar, Valle de Sartenejas.
Escuela de Turismo de la Universidad Simón Bolívar, Núcleo Litoral.
Contact: Caracas, Valladolid, Quito, Guayaquil, Jaén, Villafranca de Ordizia
WhatsApp: +34633129287
00593984950376
email: dademuchconnection@gmail.com
2 comentarios sobre “UML Analysis – Basics”