I'm currently working from Cameo Systems Modeler 19.0, using IBDs and BDDs.
The system I'm currently modeling involves a component (:Parent) composed of two sub components (:first, :second), and I've established as much within my main BDD. Each :Parent is made up of 1 unique :first, and 1 unique :second. A 1 to 1 composition relationship has been set up from :Parent to :first, and :Parent to :second.
There are multiple instances of this main component being used within the context of the system - on the ibd for the system, I'm able to instantiate as many :Parent classes as I need (i.e. Parent 1 : Parent, Parent 2 : Parent, Parent 3 : Parent, etc.)
My issue is that when I display the parts that each parent instance is made up of (to show that each :Parent is composed of a unique :first and :second instance), each nested class is displaying as the same instance. Changes to the :first and :second children on Parent 1 : Parent applies the same change to all instances of :Parent.
I want to instantiate these nested blocks as being unique to their parent - so far the only way I've made it work even a little bit is to simply define redundant blocks and display them as needed, but I feel like there has to be something I'm missing that would allow me to instantiate separate children references for each instance of the parent.
When you display the parts tree of your system it looks like this (I added names to the Parent's parts):
- «System» System1
- «part» part1:Parent
- «part» itsFirst:first
- «part» itsSecond:second
- «part» part2:Parent
- «part» itsFirst:first
- «part» itsSecond:second
An instance of this System will contain two instances of first and two instances of second. Both instances of the same type will look identical, but are nevertheless distiguishable instances. To illustrate this fact, you could create an object diagram showing an example of the seven unique InstanceSpecifications consistent with your ibd.
The fact, that they must be individual instances is given by the composition relationship. Its semantics is exclusivity. Any instance can only be part of one composite. Please note that I said "can". An instance of first could also rest on a shelf somewhere, and be part of no composite at all. Therefore the relationship is 0..1 to 1. An instance of first could also be part of some other composite, just not at the same time - hence exclusivity.
Now you say you want to change some properties of first and second to have different values, depending on whether they are nested parts of part1 or part2. For example they could have a physical location within the system. Of course it will be different for each instance. For this purpose SysML introduced context specific initial values. Cameo Systems modeler supports them nicely. You will find an entry in the context menue of the part in the ibd of the system (you have to show the nested parts of part1 and part2). Just select "tools/define context-specific initial value".
The way this works, is that the tool then creates InstanceSpecifications with slots for the values and sets them as default value for the respective system parts. So don't be surprised, when you find completely new elements next to your system block.
Related
So, let's say I have basic Document with title, author,link_to_file properties and belongsToMany(Document) and hasMany(Document) recursive parent-child relations.
Now I want to extend my Document into, let's say, 3 (or more) types: Letter,Report and Contract, which can have their own unique properties (e.g. Letter has sender and recepient, Contract can have a some fields like valid_until and such) in the addition to inherited ones.
And I want them all to still have title property (inherited from Document) and be able to have child-parent relations with eachother (Contract can be parent of Letter, which can be parent of another Contract, which can be parent of Report... etc.) without hardcoding it.
How do I implement this in laravel?
I mean the extending thing. I'm aware of the fact that I can implement Letter,Report and Contract as separate entities without having an ancestor class/entity.
UPD: If I were doing it from scratch (no frameworks involved), I would've probably ended with following tables (bad design, just for demonstrational purposes):
documents= id:int, extension_type: enum(Letter,Contract,Report), extension_id: int,link:text,author:text,title:text
document_to_document = document_id:int,child_document_id:int
letters = extension_id:int,sender,recepient
contracts = extension_id:int, valid_until,additional_field_5
reports = extension_id:int, additional_field_6
Lets say we have a class "Car" than has different pieces of data ( maker, model, color, fabrication date, registration date, etc). The class has no method to get data, but it knows to as for it from another object (sent via constructor, let's cal it for short DS).- and the same for when needing to update changes.
A method getColor() would be implemented like this
if(! this->loaded('color')){
this->askDS('color') // this will do the necesarry work to generate a request to DS
}
return this->information('color');
Nothing too fancy so far. No comes the part i want to find out if it has a name, or if there are libraries / frameworks that do this already.
DS has a list of methods registered dinamically based on the class that needs data. For car we have:
input: car serial number, output: method to use to read the numbers to extract raw values
input: car raw color value, output: color code
input: car color code, manufacturer, year, mode, output:human-readable color (for example navy blue)
Now, DS or any method does not have an ordered list of using command to start from serial number and return the color blue, but if can construct a chain of methods that from one set of data, it can run them in order and get the desired data.
For our example above, DS runs 1,2,3 in that order and injects the data resulted from all methods into the class object that needed it.
Now if the car needs registration info, we have method (4) that gets that from the police database with an api request.
So, given:
- a type of model (class/object)
- a list of methods that take a fixed list of input(object properties) and give out a fixed list of output (object properties)
- a class DS that can glue the methods and run the needed ones for a model to get from property A (serial) to properby B (human readable colour) without the model or DS having a preconfigured way to get this data but finding it as needed.
does this have a name or is it already implemented somewhere ?
I've implemented a very basic prototype and it works very nice and i think this implementation method has useful features:
if you have a set of methods that do sql queries and then your app switches to using an api, you only need to change the methods and don't have to touch any other part of the application
when looking for a chain of methods that resolve the 'need' the object has, you can find a method chain, run it, if it fails keep looking for another list of methods based on the currently available data - so if you have multiple sources for a piece of data, it can try multiple versions
starting from the above paragraph i could start with an app that only has sql queries for data retrieval - when i find out a part of the app overloads the sql server i could add a method to retrieve data from cache with a lower cost than the one from database (or multiple layered caches, each with different costs)
i could probably add business logi in the mix the same ways as cache, and based on the user location / options present different data
this requires less coding overall, and decouples the data source from the object, making each piece easier to mock/test
what is needed to make this fast is a caching solution for the discovered method chains, since matching hundreds of thousands of methods per model type would be time-consuming but I don't think this is very hard to do - just store all found chains in memory as you find them and some metadata to be able to resume a search from any point in time - when you update the methods, just clear the cache, take a performance hit for the first requests
Thank you for your time
What you describe sounds like a somewhat roundabout way of doing Dependency Injection. Quote:
"Passing the service to the client, rather than allowing a client to
build or find the service, is the fundamental requirement of the
pattern."
Depending on what language you're using, there should be several Dependency Injection frameworks/libraries available.
I'm wanting to dynamically create and query tables using Datamapper.
While Datamapper allows you to work with legacy tables and schemas, and in this way set the table name used this is only during initialisation, not within the application.
Is there an easy way to tell Datamapper to migrate/upgrade a Model with an assigned table name in application, and to then tell it to query this table?
This should not be a problem.
All Ruby classes can be created, and re-defined at run-time. Even initialization is at run-time. Initialization just happens to be executed first, before other code is executed.
That is why monkey-patches work so easily. It's just additional code at initialization that just re-defines classes to add extra methods, variables etc.
There is no Ruby code that is "special" in the sense that it only runs at compile time. Ruby is an interpreted language.
To dynamically create a class, see Dynamically creating class in Ruby.
Assuming you don't need to dynamically create classes from an array of strings, you can define additional methods with define_method, or call Datamapper methods at runtime to add attributes.
To define new methods in a class:
Post.send :define_method, :new_method_name do
end
To define a new property using the Datamapper property:
class Post
include DataMapper::Resource
property :title, String # the static way
end
Post.send :property, :title, String # add property the dynamic way (at run-time)
Do note that any tables or properties you define at run-time will not be available if you restart your server, unless the code that dynamically generates these are re-executed.
To update your tables at runtime, you simply do the same thing as normal, that is, call:
DataMapper.auto_upgrade!
To upgrade only a single table, you can also do:
Post.auto_upgrade!
2nd warning: If you have multiple processes, the dynamic code will need to be run in each process, or the additional table Models and Properties will not be available.
This is a problem if you have multiple worker processes, as might happen in production (eg. Nginx with multiple Unicorn workers, or multiple Mongrel workers behind a Ha_proxy).
If you have a single process server, then that is not a problem. However, if you have multiple worker processes, you must run the dynamic code to generate these extra classes and properties in EACH process to make it available.
This is actually the same for initialization, because each process goes through initialization (or if forked, inherit any initialization).
The easiest way without changing anything under the hood is to use separate databases instead of tables (assuming that any relationships will also be stored in the separate database) and open a connection to an additional repository in the block.
DataMapper.setup(:external, "adapter://username:password#hostname/dbname")
DataMapper.repository(:external) do...end
I am creating a Mongoid based application which will have a Class (called Question) whose Objects are stored in two different ways for different purposes. One group of those objects need to be stored in an N:N relationship with Class Page and another group of the same objects need to be stored as embedded (1:N) entries in a different Class (FilledPage).
I need to be able to copy a Question Object which has been referenced in a Page into a FilledPage and for the purposes of speed, I need that to be an embedded relationship.
I have tried creating a Superclass with the information and then two child classes, but I can't convert from one child class to the other without considerable work (and this same design needs to be used in a few other areas with much greater complexity).
Is there any way to support both embedding and references in the same class, or some other solution which will do similar.
Nothing block to have same class to be embedded or standalone. with reference. The limitation is about linking a master document to embedded document. It's not possible easily with mongodb, because your need get the master document and extract the embedded one.
I am creating a document based project using Core Data and have run into what may simply be a conceptual issue for me, as while I am not new to Cocoa, this is my first attempt to utilize Core Data. What I am trying to accomplish should be relatively simple: with each new document launched, I would like a new instance of one of my model objects created that serves as a "root" object.
What I have done is add an NSObjectController to my xib, set its mode to Entity Name (with the correct entity name provided), checked off "Prepares Content", and bound its managed object context to File's Owner with managedObjectContext as the model key path. To test this, I bound the title of my main window to the object controller, with controller key as selection and model key path as one of the keys in my entity.
I know I can create my root object programmatically, but am trying to adopt the mediator pattern as is recommended by Apple. I have seen the instructions in the department-employee tutorial under the "adopting the mediator pattern" section and the steps detailed are exactly what I believe I have done.
Any thoughts?
Edit:
Perhaps I did not state the problem correctly. The models are created in Core Data and the relationships are setup as I need them to be (with a "root", children and leaves, using to-one parent relationships, to-many children relationships and an isLeaf boolean attribute). My issue is ensuring that this root object is instantiated as a singleton every time a new document is launched. There should be exactly a 1:1 relationship between the root object and the current document, that root object must always exist and be available without any user interaction to create it, and child nodes that are created and attached to the root are the data objects that are used and manipulated by the application.
I have implemented the above functionality programatically, but in keeping with Core Data principles, would like to adopt the mediator pattern completely and not manage any creation of data objects within my application logic.
If you want a "root" managed object like you would find in linked-list or tree, then you have to set that up in data model itself.
By default, a Core Data data model has no particular hierarchy among objects. Objects may be related but no object is logically "above" or "below" another one. You can reach in object in any relationship by starting with any other object and walking the relationship/s back to the desired object.
A hierarchy of managed objects needs a tree like structure like this:
Tree{
nodeName:string
parent<-->>Tree.children
children<<-->Tree.parent
}
... so that the "root" object is the sole Tree instances that has parent==nil.
Having said all this, I would point out that the Apple docs you refer to say that it is best NOT to use this type of built in hierarchy for most cases. It's just a simplification used for purposes of demonstration (and I think it is a bad one.)
The data model is intended to model/simulate the real-world objects, conditions or events that the app deals with. As such, the logical relationships between the entities/objects in the model/graph should reflect the real-world relationships. In this case, unless the real-world things you are modeling exist in a hierarchy with a real-world "root" object, condition or event, then your model shouldn't have one either.