I have been working on the DSM plugin last few days, I would like to ask You what do you think about it. I have published my sample configuration of process in here (main changes in Develop Solution Increment activity):
http://lagoon.freebsd.lublin.pl/~dagoon/OUPDSM/ There are still things to be done (like guidelines - I'll try to finish them later) Best regards: Miroslaw Lewandowski <[email protected]> 2009/3/3 Mirosław Lewandowski <[email protected]>: > Dear Ricardo Balduino, > first of all, thank you for your reply, after few days of reading > about DSM and OpenUP I have decided to choose authoring new practice. > I'll try to sketch how I see the method for my thesis: > > short concept description: > Domain-specific modeling (DSM) is a software engineering methodology > for designing and developing systems, such as computer software. It > involves systematic use of a graphical domain-specific language (DSL) > to represent the various facets of a system. DSM languages tend to > support higher-level abstractions than General-purpose modeling > languages, so they require less effort and fewer low-level details to > specify a given system. (Wikipedia) > > I was wondering, how does the concept fit with OpenUP from the point > of view of Object Oriented Analysis and Design. In OOA&D we focus on > creating use-cases, which are used to model SD, and SSD using for > instance GRASP patterns. This is a powerfull tool for recognising new > classes for specific scenario. . > > Because we assume that in DSM we create meta-model, which gives us > opportunity to create whole variety of models, and generate different > applications later, we are not focused on use-cases, and don't use SSD > at all (instead we build generator) design domain is useless in our > case. I would like to ask of your opinion about it. > > Nevertheless I think it could be another concept to use in EPL, even > if we don't use all the design, we still gain from the analysis, which > can be base to produce meta-model. Use-cases can be used later during > modeling. During architecture agreement we could decide if we use > existing framework, or we produce a new one for a domain, and so on. > So there are few aspects which also ease and structure generating > software with DSM. > > Because due to the schedule of my thesis I have to give back my method > configuration in few days I tried to introduce the practice: > > Practice preposition: > tasks: > implement framework -> product: domain framework (probably there is > internal framework already, it will be identified during Identify and > Refine Requirements) > implement dsl -> product: domain-specific-language > implement generator -> product: generator (dsl mapped on code) > design -> product: implementation > DSM workshops (during elaboration to show the first prototypes and > that it really works) > > guidelines for all tasks, and roadmap > > > Process preposition: > > If we would like to implement DSM as a practice, and then create new > configuration of process on base of OpenUP, we would have to > consequently in all phases, change activity Develop Solution > Increment. > > Acticity changes: > Develop Solution Increment > > 1) implement framework, (input: architecture notepad) > 2) implement domain-specific-language (input: work-slot technical > specification (mainly glossary), framework) > 3) implement generator (input: domain-specific-language) > 4) design -> product: implementation > 5) integrate and create build (no changes) > > Work products changes: > there is no need of DeveloperTest > there is no need of Design > > > I'll look forward for any opinions on that topic from you Colleagues > > Best regards, > > Mirek > > > > > On 2/25/09, Ricardo Balduino <[email protected]> wrote: >> >> Miroslaw, >> >> Thanks for reaching out to this group. I personally think that any extension >> that community members can provide on top of the methods captured in EPF are >> a great value-add for the rest of the community and always welcome. >> I'm not sure I follow though what you mean by creating a new phase of >> meta-modeling. Maybe you want to provide a few more details on what exactly >> you will be adding on top of OpenUP - a short document, or short explanation >> sent to this list. >> >> I'd offer a generic thought on this in case you are pursuing this effort: >> try to base your work on the existing EPF practices. OpenUP is one example >> of process that can be assembled by combining practices available in our >> library. You could try to create an independent practice for DSM that adds >> to other practices as needed, or that stands on its own (in case it makes >> sense to adopt DSM in isolation). >> >> Either way, you may want to consider the Method Authoring Method available >> for anyone in this community as a way to start thinking how to architect >> this new practice. Check out this link: >> http://epf.eclipse.org/wikis/mam/index.htm >> Look for the key scenarios, such as Authoring a New Practice, etc. >> >> I hope this helps. >> Thanks again for your initiative. >> >> Ricardo Balduino. >> >> >> >> >> From: Mirosław Lewandowski <[email protected]> >> To: [email protected] >> Date: 02/21/2009 10:26 PM >> Subject: [epf-dev] DSM on OpenUP >> ________________________________ >> >> >> >> Hi, >> This is my first post on this newsletter, My name is Miroslaw Lewandowski, >> and i'm student at Military University of Technology in Warsaw. Currently >> I'm writing my thesis in domain of extending software development >> methodology. I'm thinking of extending OpenUP with the concept of Domain >> Specific Modeling. Tentatively I think I will have to make few major changes >> (maybe even new phase of meta-modeling?) I would like to ask what are Yours >> thoughts about it. >> >> >> Yours sincerely: >> Miroslaw Lewandowski >> <[email protected]>_______________________________________________ >> epf-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/epf-dev >> >> >> >> _______________________________________________ >> epf-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/epf-dev >> >> > > > -- > Yours sincerely: > Miroslaw Lewandowski <[email protected]> > _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
