[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [epf-dev] DSM on OpenUP
|
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>
