Design Patterns and OCL
Design Patterns
Structural Patterns
– Adapters, Bridges, Facades, and Proxies are variations on a single theme:
- Reduce coupling between two or more classes
- Introduce an abstract class to enable future extensions
– Encapsulate complex structures
Behavioral Patterns
– Here we are concerned with algorithms and the assignment of responsibilities between objects: Who does what?
– Behavioral patterns allow us to characterize complex control flows that are difficult to follow at runtime.
Creational Patterns
– Here our goal is to provide a simple abstraction for a complex instantiation process.
– We want to make the system independent from the way its objects are created, composed, and represented.
3 Types of Design Patterns (GoF patterns)
Structural Patterns
- Composite, Adapter, Bridge, Façade, Proxy
Focus: Composing objects to form larger structures
Realize new functionality from old functionality,
Provide flexibility and extensibility
Behavioral Patterns
- Command, Observer, Strategy, Template
Focus: Algorithms and assignment of responsibilities to objects
Avoid tight coupling to a particular solution
Creational Patterns
- Abstract Factory, Builder
Focus: Creation of complex objects
Hide how complex objects are created and put together
Facade Bridge Adapter
–A façade should be offered by all subsystems in a software system which provide a set of services
The façade delegates requests to the appropriate components within the subsystem. The façade usually does not have to be changed, when the components are changed
–The adapter pattern should be used to interface to existing components and legacy systems
Example: A smart card software system should use an adapter for a smart card reader from a specific manufacturer
–The bridge pattern should be used to interface to a set of objects with a large probability of change
When the full set of objects is not completely known at analysis or design time (-> Mock Object Pattern)
When there is a chance that a subsystem or component must be replaced later after the system has been deployed and client programs use it in the field.
Adapter vs Bridge
Similarities:
Both hide the details of the underlying implementation
Difference:
The adapter pattern is geared towards making unrelated components work together
Applied to systems that are already designed (reengineering, interface engineering projects)
“Inheritance followed by delegation”
A bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently
Green field engineering of an “extensible system”
New “beasts” can be added to the “zoo” (“application and solution domain zoo”, even if these are not known at analysis or system design time
“Delegation followed by inheritance”.
Rishiko OCL
Context Tournament::acceptPlayer(p)
post:
self.getNumPlayers() =self@pre.getNumPlayers() + 1
Context
inv []:
The OCL-Type Collection
is the generic superclass of a collection of objects of Type T
How to get collections?
- A collection can be generated by explicitly enumerating the elements from the UML model
- A collection can be generated by navigating along one or more 1-N associations in the UML model
– Navigation along a single 1:n association yields a Set
– Navigation along a couple of 1:n associations yields a Bag (Multiset)
– Navigation along a single 1:n association labeled with the constraint {ordered} yields a Sequence
3 basic navigation types
- Local attribute navigation
- Directly related class navigation
- Indirectly related class navigation
Shiko njehere sintaksen e OCL invariants
- Universal quantification
- Existential quantification
Summary
Constraints are predicates (often boolean expressions) on UML model elements
Contracts are constraints on a class that enable class users, implementors, and extenders to share the same assumption about the class (“Design by contract”)
OCL is the example of a formal language that allows us to express constraints on UML models
The names of the model elements in the UML model are used in the formulation of the OCL predicates
The context definition of an OCL expression specifies the model entity for which the OCL expression is defined.
Complicated constraints involving more than one class, attribute, or operation can be formulated by using 3 basic navigation types:
- Local attribute navigation
- Directly related class navigation
- Indirectly related class navigation
Rationale
Argument
–Arguments represent the debate developers went through to arrive to resolve the issue.
Arguments can support or oppose any other part of the rationale.
Arguments constitute the most part of rationale.
Issue
–Issues are concrete problems which usually do not have a unique, correct solution.
Issues are phrased as questions.
Proposal
–Proposals are possible alternatives to issues.
One proposal can be shared across multiple issues.
Criterion
–A criteria represent a goodness measure.
Criteria are often design goals or nonfunctional requirements.
Resolution
–Resolutions represent decisions.
A resolution summarizes the chosen alternative and the argument supporting it.
A resolved issue is said to be closed.
A resolved issue can be re-opened if necessary, in which case the resolution is demoted.
Rationale is the reasoning that leads to the system.
Rationale includes:
the issues that were addressed,
the alternatives that were considered,
the decisions that were made to resolve the issues,
the criteria that were used to guide decisions, and
the debate developers went through to reach a decision.
————
Improve design support
Avoid duplicate evaluation of poor alternatives
Make consistent and explicit trade-offs
Improve documentation support
Makes it easier for non developers (e.g., managers, lawyers, technical writers) to review the design
Improve maintenance support
Provide maintainers with design context
Improve learning
New staff can learn the design by replaying the decisions that produced it
—————–
**Rationale in project management
-Consensus building (WinWin)
-Consistency with goals (NFR Framework)
-Rapid knowledge construction (Compendium)