Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epf-dev] DSM on OpenUP

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 <mirek.lewandowski@xxxxxxxxx>



2009/3/3 Mirosław Lewandowski <mirek.lewandowski@xxxxxxxxx>:
> 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 <balduino@xxxxxxxxxx> 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 <mirek.lewandowski@xxxxxxxxx>
>>  To: epf-dev@xxxxxxxxxxx
>>  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
>> <mirek.lewandowski@xxxxxxxxx>_______________________________________________
>>  epf-dev mailing list
>>  epf-dev@xxxxxxxxxxx
>>  https://dev.eclipse.org/mailman/listinfo/epf-dev
>>
>>
>>
>> _______________________________________________
>>  epf-dev mailing list
>>  epf-dev@xxxxxxxxxxx
>>  https://dev.eclipse.org/mailman/listinfo/epf-dev
>>
>>
>
>
> --
> Yours sincerely:
> Miroslaw Lewandowski <mirek.lewandowski@xxxxxxxxx>
>


Back to the top