Software Design: Maintenance and Metrics

Maintenance and Metrics

^ü    During use case realization, we identify mainly four "types" of classes, boundary classes, data store classes and control classes.

^ü    The entity classes represent the information that the system uses. Examples of entity classes are: Customer, Product, and Supplier. Entity classes are essential to the system as the expected functionality of the system includes maintaining information about them or retrieving information from them.

^ü    The boundary classes represent the interaction between the system and its actors. A GUI form is an example of a boundary class.

^ü    Data store classes encapsulate the design decisions about data storage and retrieval strategies. This provides us flexibility to move a n application from database platform to another.

^ü    The control classes represent the control logic of the system. They implement the flow of events as given in a use case.

Entity Classes

^ü    Entity classes are the abstractions of the keys concepts of the system being modelled. If the steps of the Architectural Analysis have been carried out, many of the entity classes may have already been identified during those steps.

^ü    The Core functionality and logic of the system are encapsulated in the various entity classes. For example, if interest is to be calculated and paid to savings account holders, a savings Account entity class may be responsible for computing and returning the interest.

^ü    You can normally look for the following types of things as potential entity classes:

1.     Roles played by people or organizations about which information is required to be maintained by the system. For Example, Student in a Library Management System, Vendor in a Purchase Ordering System.

2.     Other physical, tangible things. For example, Book in a Library Management System.

3.     Events that requires remembrance. For example, Reservation and Issue in a Library Management System.

^ü    The logical data structures (attributes and relationships) of the entity classes would be designed to hold and manipulate the data according to the system's requirements. Values of the attributes and their relationships of the entity class objects are often given by actors. The entity classes are responsible for storing and managing information in the system.

^ü    Entity class objects are usually persistent, having attributes and relationships that need to be retained for a long time, sometimes even before the life of system. An entity class is usually not specific to one use cause realization. Objects of most entity classes would required in multiple use cases. Sometimes, an entity object may not be specific to the system itself.

Boundary Classes

^ü    Boundary classes represent the interaction between the system and its actors. They insulate the system from changes in the surroundings of the system, such as user interfaces, and interfaces to other systems.

^ü    There may be various types of boundary classes in a system:

1.     User Interfaces classes: Classes for encapsulating the human user interface of the system, such as GUI forms.

2.     System Interface Classes: Classes that encapsulate the interaction of the system with other systems.

3.     Device Interface Classes: Classes that provide the interface to devices that detect external events.

^ü    An important objective of identifying boundary classes is to ensure that the entity classes and the control classes are not affected by any changes to the boundary classes.

^ü    Actors interact with the system only through the boundary classes.

User Interface Classes

A user interface class represents the interaction between a use case and its initiating actor. This class has the responsibility of coordinating the interaction with the actor. A boundary class may have various subsidiary classes to which some of its responsibilities are delegated. For example, in a GUI application, there may be multiple forms within a use case.

^ü    During use case analysis, you should use the boundary classes as just place-holders for the GUI forms. Detailed GUI design is an activity of Class Design. During Analysis, the emphasis should be only on isolating all environment-dependent behaviour as boundary classes. These classes will get refined or replaced in the later stages.

System Interface Classes

^ü    A system interface class is responsible for interfacing with an external system. The interface offered by the external system would have been identified by the developers of that system. Thus, the behaviour of a system interface class should be derived directly from the interface specifications of the external system.

^ü    System interface classes achieve the purpose of isolating the internal details of the external systems, which may change over a period of time. Our system should not get affected by such changes in the internal details of the external systems.

Device Interface Classes

^ü    Device interface classes are responsible for interacting with the external devices that the system may depend upon for receiving inputs or handling outputs. Examples of such external devices would be: bar code reader, system clock, printer, etc.

^ü    A device may already have a well-defined interface, which could be used by you later during design. Therefore, a note of such interface should be made in the model documentation.

Data Store Classes

^ü    Data Store classes encapsulate our design decisions about the database structures which are used to store entity class objects, and to retrieve them later. For each entity class that required persistence, we create a corresponding data store class. A data store class typically receives an object of an entity class, and make it persistence (for example, by inserting a row in a table). At a later point of time, we may ask the data store class to return the entity class object.

^ü    Encapsulating the database design designs in data store classes, makes the entity classes independent of the database structure, and thus provides us greater flexibility to move an application from one database platform to another.

Controller Classes

^ü    Controller classes provide co-ordinating behaviour in the system. A typical example would be a controller class implementing the logic and flow of events of a use case.

^ü    Controller Classes isolates the entity classes and boundary classes from each other, making the system independent of the changes to the system boundary. They also isolate the use case specific behaviour from the entity class objects, thus making them re-usable across use cases and even across systems.

^ü    Simple use cases may be performed without using controller classes, with direct flow of data between boundary objects and entity objects. However, more complex use cases usually require and benefit from such controller classes. The characteristics of controller classes are:

1.     They define the order of events and transactions within a use case. In other words, they encapsulate the use case-specific behaviour of the system.

2.     They are relatively independent of the changes to the internal structure or behaviour of the entity classes.

3.     They are nearly independent of changes to the boundary classes.

4.     They may use or set several entity classes, thus coordinating the behaviour of these entity classes. However, this coordination can be invisible to the participating entity classes.

^ü    Though most of the times a control class correspond to a single use case, some times a single controller class may be use to control several use cases. Some tines there may even be multiple controller classes with in a single use case. As mentioned earlier, there may be use cases that do not require controller classes.

Association:

^ü    Association defines the relationship between two or more classes in the System. These generally relates to the one object having instance or reference of another object inside it. This article discusses on how we can implement Association in UML.

^ü    Associations in UML can be implemented using following ways:

1.Multiplicity

2.Aggregation

3.Composition

Multiplicity in UML: Multiplicity indicates the no of instance of one class is linked to one instance of another class. The various multiplicity values are listed below:

Attributes

^ü   It is a logical data value of an object

^ü   In UML:

1.     Attributes are shown in the second compartment of the class box.

2.     The type of an attribute may optionally be shown.

In a domain model, attributes and data types should be simple. Complex concepts should be represented by an association to another conceptual class.

^ü   An attribute should be what the UML standard calls a data type: a set of values for which unique identity is not meaningful. Numbers, strings, Booleans, dates, times, phone numbers, and addresses are examples of data types. Values of these types are called value objects.

Relating Types

^ü   Conceptual classes in a domain model should be related by associations, not attributes.

^ü   In particular, an attribute should not be used as a kind of foreign key.

Quantities and Units

Quantities with associated units should be represented either as conceptual classes or as attributes of specialized types that imply units (e.g., Money or Weight).

Derived Attributes

^ü    A quantity that can be calculated from other values, such as role multiplicities, is a derived attribute, designated in UML by a leading slash symbol.

NextGen POS Domain Model Attributes

^ü   Strategies to Identify Conceptual Classes

^ü   Two techniques are presented in the following sections:

1.     Use a conceptual class category list.

2.     Identify noun phrases.

^ü   Another excellent technique for domain modeling is the use of analysis patterns, which are existing partial domain models created by experts

Finding Conceptual Classes with Noun Phrase Identification

^ü   Another useful technique (because of its simplicity) suggested in [Abbot83] is linguistic analysis: identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes or attributes.

^ü   Care must be applied with this method; a mechanical noun-to-class mapping isn't possible, and words in natural languages are ambiguous. Nevertheless, it is another source of inspiration. The fully dressed use cases are an excellent description to draw from for this analysis. For example, the current scenario of the Process Sale use case can be used.

Main Success Scenario (or Basic Flow):

1.     Customer arrives at a POS checkout with goods and/or services to purchase.

2.     Cashier starts a new sale.

3.     Cashier enters item identifier.

4.     System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 2-3 until indicates done.

5.     System presents total with taxes calculated.

6.     Cashier tells Customer the total, and asks for payment.

7.     Customer pays and System handles payment.

8.     System logs the completed sale and sends sale and payment information to the external Accounting (for accounting and commissions) and Inventory systems (to update inventory).

9.     System presents receipt.

10.         10.Customer leaves with receipt and goods (if any).

Extensions (or Alternative Flows): 7a. Paying by cash:

1.  Cashier enters the cash amount tendered.

2.     System presents the balance due, and releases the cash drawer.

3.     Cashier deposits cash tendered and returns balance in cash to Customer.

4.     System records the cash payment.

^ü   The domain model is a visualization of noteworthy domain concepts and vocabulary. Where are those terms found? In the use cases. Thus, they are a rich source to mine via noun phrase identification.

^ü   Some of these noun phrases are candidate conceptual classes, some may refer to conceptual classes that are ignored in this iteration (for example, "Accounting" and "commissions"), and some may be attributes of conceptual classes.

^ü   A weakness of this approach is the imprecision of natural language; different noun phrases may represent the same conceptual class or attribute, among other ambiguities. Nevertheless, it is recommended in combination with the Conceptual Class Category List technique.

^ü   Specification or Description Conceptual Classes

^ü   The following discussion may at first seem related to a rare, highly specialized issue. However, it turns out that the need for specification conceptual classes (as will be defined) is common in any domain models. Thus, it is emphasized.

^ü   Note that in earlier times a register was just one possible implementation of how to record sales. The term has acquired a generalized meaning over time.

^ü   Assume the following:

1.     An Item instance represents a physical item in a store; as such, it may even have a serial number.

2.     An Item has a description, price, and itemID, which are not recorded anywhere else.

3.     Everyone working in the store has amnesia.

4.     Every time a real physical item is sold, a corresponding software instance of Item is deleted

from "software land."

^ü   With these assumptions, what happens in the following scenario?

^ü   There is strong demand for the popular new vegetarian burger—ObjectBurger. The store sells out, implying that all Item instances of ObjectBurgers are deleted from computer memory.

^ü   Now, here is the heart of the problem: If someone asks, "How much do Object Burgers cost?", no one can answer, because the memory of their price was attached to inventoried instances, which were deleted as they were sold.

^ü   Notice also that the current model, if implemented in software as described, has duplicate data and is space-inefficient because the description, price, and itemID are duplicated for every Item instance of the same product.

The Need for Specification or Description Conceptual Classes

^ü   The preceding problem illustrates the need for a concept of objects that are specifications or descriptions of other things. To solve the Item problem, what is needed is a ProductSpecification (or ItemSpecification, ProductDescription, ...) conceptual class that records information about items. A ProductSpecification does not represent an Item, it represents a description of information about items. Note that even if all inventoried items are sold and their corresponding Item software instances are deleted, the ProductSpecifications still remain.

^ü   Description or specification objects are strongly related to the things they describe. In a domain model, it is common to state that an XSpecification Describes an X.

^ü   The need for specification conceptual classes is common in sales and product domains. It is also common in manufacturing, where a description of a manufactured thing is required that is distinct from the thing itself. Time and space have been taken in motivating specification conceptual classes because they are very common; it is not a rare modeling concept.

When Are Specification Conceptual Classes Required?

The following guideline suggests when to use specifications:

^ü   Add a specification or description conceptual class (for example, ProductSpecification) when:

1.     There needs to be a description about an item or service, independent of the current existence of any examples of those items or services.

2.     Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, due to the incorrect association of information with the deleted thing.

3.     It reduces redundant or duplicated information.