SOFTWARE ENGINEERING

OBJECT-ORIENTED DESIGN

Saulius Ragaišis

saulius.ragaisis@mif.vu.lt

Information source

Slides are prepared on the basis of

• Bernd Oestereich, Developing Software with UML: Object-Oriented Analysis and Design in Practice (2nd edition). Addison-Wesley Professional, 2002. ISBN 020175603X

DEFINING THE APPLICATION ARCHITECTURE

Synopsis

• Identify the individual elements (layers, components, class types, etc.) of the underlying application architecture, plus the relationships between them, and portray them in a model/diagram.

• Describe the responsibilities, tasks, and special features of each element in the application architecture.

• Describe the principal communication mechanisms with the aid of interaction diagrams, and document the use of design patterns.

Application architecture

• What must be designed?

• Clean application architecture also helps to achieve:

– a sensible division of labor and a clear overview;

– long-term flexibility in system development;

– a higher degree of re-usability.

• Dialogs, dialog controller

• Dialog agent

• Use case controller

Application architecture (2)

• Workflow or process controller

• Domain components

– Responsibility for consistency of domain-specific content

• Frameworks

• Don’t call the framework…

– “Don’t call the framework, the framework will call you” (that is, reversal of control). This is also known as the “Hollywood principle” (“Don’t call us, we’ll call you”).

Example

Checklist

• Is there a model of the application architecture? • Have the responsibilities and tasks of all the

architecture elements been described? • Have the interaction principles and interface

properties of the architecture elements been explained?

• Has the use of design and architecture patterns been documented?

• Is there a prototype to demonstrate the usefulness of the application architecture?

• Is the application architecture appropriate for the problem in hand?

IDENTIFYING DOMAIN COMPONENTS

Domain components

• Synopsis: Develop an initial component model, based on the analysis class model and the specified application architecture.

• The assumed application architecture is a component-based architecture and provides for a division of the application logic into components.

• Define a workflow component for each business process.

• Define a use case controller component for each use case.

Domain components (2)

• Represent each external system by a component.

• Combine related classes in the analysis model to form domain components.

• Draw a component model and use dependency relationships to note the dependencies that are known at this stage between the components.

Example. Division of the analysis classes between components

Example. First domain component model

Checklist

• Can all identified business processes be allocated to corresponding workflow components?

• Can all identified system use cases be allocated to corresponding use case controller components?

• Are all identified external systems represented (encapsulated) by a component?

• Can each class in the analysis model be allocated to a domain component?

• Have the dependencies between the domain components been defined, insofar as they can be determined from the class model?

DEVELOPING COMPONENT-SPECIFIC CLASS MODELS

Class models

• Based on the analysis class model (problem description), develop a specific design class model (solution concept) for each component.

• Use domain-specific keys to represent all the associations to the objects of other components.

• Define the responsibilities of all component-specific classes, i.e. transform the problem description (analysis) into a solution concept (design) and if necessary restructure the component-specific class model.

Example. Initial class models

Example. Responsibilities and important properties

Example. Class design for Rental component

Checklist

• Have the responsibilities of all classes been checked and detailed?

• Has the analysis model (problem description) been converted into an appropriate design model (solution concept)?

• Have all the associations to objects of other components been represented by domain-specific keys?

• Can all the attributes and operations of a class be assigned to the defined responsibilities?

(FURTHER) DEVELOPING STATE MODELS

State models

• If and in what detail states are modeled during the design firstly depends on whether the behavior of an object is considered as sufficiently significant to be modeled.

• Objects that have only two to three different states which barely influence the behavioral possibilities of that object can usually be designed to a satisfactory degree without modeling.

State models (2)

• Identify the possible domain-specific states for each object.

• State-dependent messages

• State-dependent operation

• Decide how the identified states should be modeled and implemented (e.g. state machine, constraints, state attributes, “state” design pattern, etc.).

Example. State model for Rental class

Checklist

• Have all the technically permissible states of the object been documented?

• Have the domain-specific implications of the identified states been thought through and taken into account?

• Have the possible subsequent states and transitions been examined for each individual state?

• Have all the operations of the class in question been identified as state-dependent or state-independent (e.g. with an appropriate tagged value)?

IDENTIFYING AND, IF NECESSARY, RESTRUCTURING COMPONENT

DEPENDENCIES

Component dependencies

• Examine and document the structural connections and dependencies between the components.

– Identified components

• Examine and document the dynamic connections and dependencies between the components.

– Object flow diagram

– Interaction diagrams

– Restructuring

Example

Checklist

• Has each activity in the available object flow diagrams been assigned to a single domain component?

• Has the dynamic interconnection of the components been determined by examining the changes in control flow and the accesses to foreign objects?

• Have the components been restructured, if necessary, to minimize the degree of interconnection?

DESIGNING COMPONENT INTERFACES

Component interfaces

• Synopsis: Based on the use cases, define the necessary interfaces for each identified component.

• The process flow defined in the object flow diagram is definitively implemented by the use case controller component. The use case controller component can therefore formulate the requirements on the interfaces between the neighboring components.

• Use case controller interface – used by the dialog agent

• Domain component interfaces – required by the use case controller

Example. Use case controller interface

Example. Domain component interface

Checklist

• Are all the objects or object states contained in the object flow diagram located without exception in the described interfaces?

• Do the described interfaces contain all the operations required for the process controller (use case controller), insofar as they are known?

DEVELOPING COLLABORATION MODELS

Collaboration models

• For each use case develop a sequence or collaboration diagram that represents the standard course of events (successful case).

• Recognize the strengths and weaknesses of the selected design in these situations.

• For each use case develop 1–3 collaboration diagrams that represent the most important process variants or exceptions.

• Identify properties that are still missing from the classes in question, i.e. if necessary create new classes, associations, attributes, and operations.

Collaboration models (2)

• Collaboration and sequence diagrams illustrate and detail selected situations, i.e. situations that are limited in terms of time and class.

• Developing collaboration diagrams is an exploratory activity and once knowledge has been derived from them, they have served their purpose and are generally no longer required.

Example. Collaboration model for Reserve vehicle by phone use case

Checklist

• Has a collaboration diagram representing the standard course of events been developed for each use case?

• Has a collaboration diagram been developed for the 1–3 most important process variants of a use case?

• Are all the classes, relationships, attributes, and operations used in the collaboration diagrams available, i.e. defined in the class model?

DEVELOPING PROCESS-ORIENTED COMPONENT TESTS

Component tests

• This step could also be called “Defining and Restructuring Operations”.

• The development of automated tests is a design activity.

• Developing the tests generally produces new insights into the situations to be implemented.

• The design must be conceived in such a way that it is subsequently possible to carry out automated tests on it.

Component tests (2)

• During the analysis stage the first test cases could be identified on the basis of the use cases.

• At least one test case was required for each outgoing transition of an activity, so that all the paths and variants could be run through at least once in the test.

• This should involve testing the interfaces that were defined in the previous steps for the individual components.

Component tests (3)

• The tests should, if possible, be automated, i.e. they should just start up, require no user input, check their own results, and be repeated as often as you like.

• When all the tests can be completed successfully, you are, in principle, ready. After every change to the code all the tests must be run again.

Checklist

• Has an automated test been programmed for each identified test case?

• Are all the automated tests compilable and executable (even if with negative results)?

DEVELOPING CLASS TESTS

Class Tests

• Determine which operations in the component interface are to be handled by which class.

• Define the preconditions and postconditions of the operations as well as the necessary invariants of the classes.

• Develop automated tests for all operations.

Class Tests (2)

Helpful questions for identification of operations include:

• What kind of service is expected from the object (e.g., setting of a standard address)?

• Which state transitions might apply to the object?

• When does the life cycle of an object begin, and when does it end?

• For which relations with other objects are add or remove operations required (e.g., adding a contract)?

• Which information must the object be able to give?

• Which data contents are modifiable? Data changes are carried out via operations which might also take over formal and content checking of the data change.

Class Tests (3) The specification of an operation contains:

• Signature: describes name, arguments, and return type of the operation.

• Precondition: describes the object state that must be given before execution of the operation.

• Postcondition: describes the object state given after execution of the

• operation.

• Invariant: describes the object state that must be present during execution of the operation as well as in general. This includes, among other things, type tests and special value tests for the operation parameters.

• Semantics: describes task and significance of the operation by way of a comment.

Checklist • Has a test method been developed for each operation?

• Have the semantics of each operation been described?

• Have the invariants, preconditions, and postconditions been described for each operation?

• Are all the operations coherent, i.e. do they only perform a single task?

• Have possible side effects as a result of global variables been ruled out by instead passing the corresponding information as parameters?

• Do overwritten operations behave in a compatible manner to the operations in the superclass?

• Do the operations contain any switch/case statements or a series of consecutive if statements (indicators of procedural)?

• Have the extreme values (minimum, maximum, null, nonsense) of all the parameters been taken into account in order to achieve a robust behavior in all situations?

• Have general and enterprise-specific standards been taken into account?

DEFINING ATTRIBUTES

Defining attributes

• Determine the required attributes and assign them uniquely to the existing classes.

• For each potential attribute, ask yourself whether it should perhaps be a class in its own right.

• Divide the attributes into standard attributes, enumerations, and primitive types.

• Determine the required constraints for the attributes.

Helpful questions

• What does the object have to know (generally, short-time)?

• Which information must the object be able to give?

• Which are the attributes used to describe the properties of the object?

• Where does the information come from? What happens to the information in the course of time?

Attributes

• Attribute or class? – It has to be considered whether some attributes had not

better be viewed as independent objects.

• Defining enumerations – Consolidate

– Find the common features

– Stereotype «enumeration»

• Restructuring – Having a closer look at the attributes to consolidate the

present model also means once again finding common features between the classes, generalizing differences, recognizing dependent and independent properties, and if necessary further generalizing the classes.

Example

Customer Group in analysis model

Customer Group modeled as an enumeration

Checklist

• Have you examined which attribute candidates are a «primitive»?

• Have you examined which attribute candidates are an «enumeration»?

• Have you examined which attribute candidates represent a domain class («entity»)?

• Have the name, type, initial value and constraints been defined for each attribute?

• Have general and enterprise-specific standards been taken into account?

• Can each attribute be assigned to a responsibility of the class?

SPECIFYING DIALOGS

Specifying Dialogs

• Examine the different contexts or use cases in which a dialog or dialog element is used.

• Design the dialogs in such a way that they can be used in a uniform manner in as many contexts or use cases as possible.

• Specify all dialog elements according to a standard pattern.

Dialogs

• Dialog contexts

• Dialogs, Activities, Subsystems, Components

• Dialog specification

– It would appear to be best initially only to specify the dialog requirements.

– This may happen at two levels:

• individual fields and dialog elements

• dialog elements can be combined into groups (e.g., street, place, and ZIP into an address group)

– Constraints

Checklist

• Do you know the different contexts in which each individual dialog will be used?

• Has each individual dialog element been fully specified according to a standard pattern?

DISCUSSION OF DESIGN

Discussion of Design

• Synopsis: look at various design alternatives and critically discuss their strengths, weaknesses, and implications.

• The following terms are under discussion: – business partner, customer , customer file,

contact partner, supplier, supplier file, enterprise, private person, bank account, telecommunication connections (in short: phone number), address, employee.

• To begin with, all the listed terms are interpreted as possible classes.

Discussion of Design (2)

• Identifying relationships

– After having identified the classes, we are now going to analyze their relationships (associations, aggregations, and inheritance).

• Business partners and their roles

– Problematic solutions - modeling with: “OR” inheritance, “OR” compositions, combinatorial inheritance hierarchy

– Redundancy?

– Constraints

Discussion of Design (3)

• A critical check of inheritance: – Employee and supplier can be customers – Specialization vs. role assignment – Business partner roles – Actor-role pattern

• Bank account, phone number and address – Types of address: Street address, Post box address,

Corporate address, Foreign country address. – The various types of address modeled as a

specialization hierarchy – Dynamic classification – The various types of address encapsulated in the

component and equipped with a uniform façade

Business Partner modeling with OR inheritance

Business Partner modeling with OR inheritance (2)

Business Partner modeling with combinatorial inheritance hierarchy

Business Partner modeling with OR compositions

Business Partner modeling constraints on composition relationships

Business Partner modeling with roles

Partner roles model

Checklist

• Does a subclass support all the attributes and operations of its superclass, i.e. has a suppression of properties been avoided?

• Does each class have a large degree of internal coherence, i.e. have related responsibilities been concentrated in one class?

• Does each class have only a small number of external dependencies, i.e. contracts/ interfaces to other classes?

• Has indirect navigation been avoided, i.e. does a class have only limited knowledge of its neighboring classes?

• Have client-server relationships been designed between the classes (cooperation principle)?

Checklist (2)

• Are the superclasses of an abstract class themselves abstract classes?

• Does a subclass not define any constraints on the properties of the superclass?

• Have you examined the relationships between the classes to determine whether there are any domain-level dependencies or hierarchies between the classes?

• Have you examined inheritance relationships and attempted to replace them by delegation, etc.?

• Have you identified those structures (classes and relationships) which may become unstable in future, and can they be clearly and unambiguously distinguished from those which are assumed to be stable?

Checklist (3)

• Can the class structure survive without a combinatorial explosion of relationships, even in the event of future extensions?

• Have separate operations been provided instead of operation modes?

• Does the code for each operation generally cover less than a page? Otherwise you might as well go back to Cobol, PL/1, etc.

• Have you defined uniform and appropriate names, types, and parameter sequences?

• Have domain classes (e.g. Vehicle class) been separated from expression classes (e.g. VehicleType class)?

QUESTIONS?