Configuration Models and Configuration Designs

CONFIGURATION MODELS AND CONFIGURATION DESIGNS Configuration Models • Design models show the articles and thing classes and connections between these substances. • There are two types of design models: o Structural models portray the static design of the framework as far as article classes and connections. o Dynamic models describe the dynamic interactions between objects. Examples of Configuration Models • Subsystem models that show legitimate groupings of articles into lucid subsystems. • Collaboration models that show the grouping of object interactions. • State machine models that show how individual objects meaningfully change their state due to events. • Other models include use-case models, collection models, speculation models, etc. Subsystem Models • Shows how the plan is coordinated into intelligently related gatherings of articles. • In UML, these are shown utilizing bundles - a reflection develop. This is a logical model. The actual organization of objects in the system may differ. Sequence Models • Arrangement models show the succession of item cooperations that happen: o Objects are arranged horizontally across the top. o Time is represented vertically, so models are read top to bottom. o Interactions are represented by named arrows, with various arrow styles indicating different types of interactions. o A thin rectangle on an object’s lifeline represents when the object is the controlling object in the system. 1 State Diagrams • State outlines are utilized to show how articles answer different assistance demands and the state advances set off by these solicitations. • State graphs are valuable significant level models of a framework or an item's runtime conduct. • You ordinarily needn't bother with a state graph for each item in the framework. Many items in a framework are generally basic, and a state model adds pointless detail to the design. • State outlines are utilized to show how items answer different help demands and the state changes set off by these solicitations. • State charts are valuable significant level models of a framework or an item's runtime conduct. • You normally needn't bother with a state graph for each item in the framework. Many items in a framework are somewhat straightforward, and a state model adds superfluous detail to the plan. Interface Specification • Object interfaces must be specified so that objects and other components can be designed in parallel. • Designers should avoid specifying the interface representation but should hide this within the object itself. • Objects may have multiple interfaces, which are views of the methods provided. • UML uses class diagrams for interface specification, but Java can also be used. Configuration Designs • A design pattern is a way of reusing knowledge about a problem and its solution. • An example is a depiction of the issue and the substance of its answer. • Reused in various settings, it ought to be adequately general. • Configuration designs ordinarily use object-situated characteristics like legacy and polymorphism. 2 Designs • Examples and Example Lingos are ways of portraying best practices, great plans, and caught bits of knowledge so that others can reuse this experience. Design Elements • Name: A significant pattern identifier. • Problem Description: • Solution Description: o • Not a concrete design but a template for a design solution that can be implemented in various ways. Consequences: o The results and trade-offs of applying the pattern. The Observer Pattern • Name: Observer • Description: Separates the display of object state from the actual object. • Problem Description: Used when multiple views of state are required. • Solution Description: See the UML description slide. • Consequences: o Improvements to display performance are unfeasible. Design Issues • To use patterns in your design, you need to recognize that any design problem you are facing may have a related pattern that can be applied. o Let some objects know that the state of another object has changed (Observer pattern). o Clean up the interfaces to various related objects that have often been created incrementally (Facade pattern). o Provide a standard way to access elements in a collection, regardless of how that collection is implemented (Iterator pattern). o Allow for the possibility of extending the functionality of an existing class at runtime (Decorator pattern). 3