Contenido

Introduction.......................................................................................................................................3
Aspects to Product Lines................................................................................................................3
Art studio (theoretical framework)....................................................................................................5
Domain-specific modeling (DSM).......................................................................................................6
Elements of the Domain Model.....................................................................................................8
Domain Model Construction Process.............................................................................................8
Tool support for DSM.......................................................................................................................12
Interoperability.........................................................................................................................13
Conclusions......................................................................................................................................15
REFERENCES.....................................................................................................................................17

1
Introduction

Aspects to Product Lines

Understanding the relevant domains is the first step to defining the commonality
and variability that can be expected to occur among the products identified in the product
line's scope. Domain understanding for a product line emphasizes the commonality and
variations present among the products, whereas domain analysis for a single system focuses
instead on the technical concepts inherent in a single system or how that system might
evolve once fielded. [9]

Domain information for a product line will help you determine: [9]

 Which capabilities tend to be common across systems in the domain and what
variations are present. This information will inform the process of scoping, in which
the commonality and variations for your product line will be established.

 Which subsets of capabilities might be packaged together as assets for the product
line? This information begins to inform the architecture creation effort for the
product line, by suggesting potential subsystems that have occurred in other systems
in the domain.

 what constraints apply to systems in the domain

 Which assets typically constitute members of the domain? This suggests a list of
assets that an organization could begin to search for in its own legacy inventory or
on the open market.

 Whether to continue with the product line development effort

In this paper I talk about:

Domain analysis, or product line analysis, is the process of analyzing related software
systems in a domain to find their common and variable parts. It is a model of wider

2
business context for the system. The term was coined in the early 1980s by James
Neighbors.[1] [2]

Domain analysis is the first phase of domain engineering. It is a key method for
realizing systematic software reuse. [3]

Domain analysis produces domain models using methodologies such as domain specific
languages, feature tables, facet tables, facet templates, and generic architectures, which
describe all of the systems in a domain. Several methodologies for domain analysis have
been proposed. [4]

We can model a domain analysis using DSM

For this we use a method called domain specific modeling which will help us
understand a type of modeling for software product lines

In this paper we will study and understand the artifacts that use this method for
modeling software product lines.

This report provides a practical introduction to product line requirements modeling.

3
Art studio (theoretical framework)

In this investigation we will be guided in the modeling domain, based on definitions

of various authors.

The investigation is viable and that the references consulted are important sources
such as sei, ibm, etc.

DSM differs from earlier code generation attempts in the CASE tools of the 1980s
or UML tools of the 1990s. In both of these, the code generators and modeling languages
were built by tool vendors. While it is possible for a tool vendor to create a DSM language
and generators, it is more normal for DSM to occur within one organization. [16]

[5][1][2][4], “
Northrop and Clements, Neighbors J.M., Frakes W.B. and Kyo Kang a
software product line is a set of software intensive systems that share a managed set of
characteristics, and that satisfies the needs of a particular market segment or mission, being
developed using a set of common core assets in a preestablished fashion.”

Dennis de Champeaux, Douglas Lea, and Penelope Faure [3] “Domain analysis is the
first phase of domain engineering. It is a key method for realizing systematic software
reuse”

Domain analysis is the process of identifying, collecting, organizing, and

representing the relevant information in a domain, based upon the study of existing systems
and their development histories, knowledge captured from domain experts, underlying
theory, and emerging technology within a domain[11].

Domain-Specific Modeling (DSM) can raise the level of abstraction beyond coding
by specifying programs directly using domain concepts. The final products can then be
generated from these high-level specifications. This automation is possible because the

4
modeling language and generator only need to fit the requirements of one domain, often in
only one company. [14],[15]

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 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

Domain-specific modeling often also includes the idea of code generation

automating the creation of executable source code directly from the DSM models.

Being free from the manual creation and maintenance of source code means DSM
can significantly improve developer productivity. The reliability of automatic generation
compared to manual coding will also reduce the number of defects in the resulting
programs thus improving quality.

Having the modeling language and generator built by the organization that will use
them allows a tight fit with their exact domain and needs. It also reduces the time needed
for developers to learn the modeling language, since it can use familiar terms and concepts.

Finally, since only one organization's requirements need be taken into account, it is
easier for the modeling language to evolve in response to changes in the domain.

DSM languages can usually cover a range of abstraction levels for a particular domain.

Tolvanen identifies over 20 industrial cases in which this approach has been
successfully applied to target languages such as C, C++, Java 2 Platform, Enterprise
Edition (J2EE), and Extensible Markup Language (XML).

5
 The domains of these industries include telecom services, insurance, medical
device configuration, handheld devices, machine control, and business processes.

Domains in this context have been defined as:

 An application area
 A business area
 A software business area
 A software intensive application area
 An application area for which similar software systems have been built

It includes scoping and domain modeling. Scoping consists of defining which

products are parts of the SPL and which are not. Domain modeling is the process through
which commonalities and variabilities are identified, captured and organized in a domain
model with the purpose of characterizing the domain.

Variability is the key aspect of SPL that must be considered when analyzing models
and as it was previously mentioned, embedded SPL may have diverse variability issues:

 Some functionality may vary from one product of the line to another. Not all
products of the product line have the same functionalities.

 Two products with the same functionality may require different quality attributes, as
well as the priority or degree of them. Impacts may also arise among different
quality attributes and/or other variability issues.

 Variability can be addressed at execution environment. Often, some of the hardware

devices and other performance-affecting factors can vary from one product to
another
The real difficulty was in finding appropriate concepts for modeling the behavioral parts
and logic based on domain rules. This was achieved when the underlying platform provided
services the models could be mapped to. This is often called analyzing the variability space

6
Elements of the Domain Model
The Domain model structure is based on features, goals, scenarios and lexicon.

In the context of a product line, a goal is an objective of the business, the

organization or the system that some stakeholder hopes to achieve with that product line.

A scenario is a possible behavior limited to a set of interactions with the purpose of

achieving some goals with the product line. Thus, a scenario is generally composed of a
sequence of one or more actions corresponding to user or system interactions with products
of a product line.

Features are characteristics and abstractions of product functionalities, parameters

and data storages in a SPL visible for stakeholders, and thus they can be viewed as effects
achieved by some product behavior (External or internal). A feature is an attribute of a
system that directly affects end-users

The lexicon defines the domain vocabulary

Domain Model Construction Process

7
 The business goal establishes the purpose for developing products as a family. This
goal is unique for the whole SPL, but there may be several particular goals.

We distinguish two types of scenarios: development scenarios that are those

followed whenever a product of the SPL is built, and use scenarios that are those followed
by particular products once they are executed.

Features are those data storage, parameters or functionalities identified for the
potential products in the SPL; they may be common, optional or alternative.

The lexicon involves terms necessary for understanding the domain and they can be
any relevant thing into the domain.

Activity diagram for building the domain model. The domain expert and the domain
analyst should interact in order to identify and specify goals, features, scenarios, actions,
and terms of the lexicon as well as their relationships considering information from the
stakeholders (included domain expert and analyst), available components developed in the
domain, external information and systems.

8
 Identifying information

Depelopment Artifacts

Domain Model Construction

Analysis of Domain Model

Delivering Domain Model

9
DSM can support UML Diagrams:

Interaction diagrams are a subset of behavior diagrams, which emphasizes the

control flow and data between system elements modeling:

1.-Sequence diagram
2.-Communication diagram, a simplified version of the Collaboration Diagram
2.-Timing diagram
3.-Global interaction diagram or interaction diagram view

The DSL (Domain Specific Language) is the underlying model for a domain to
perform DSM, and it is generally captured in the form of a meta-model or final model
domain.

One or a few expert developers create the modeling language and generators, and
the rest of the developers use them.

If a domain could not be defined or an existing architecture was not available,

languages tended to use modeling only for the general static structures.

A Domain Model or Meta-Model is an artifact of the analysis discipline, the

construction task domain model, presented as one or more class diagrams and contains no
concepts of a software system but of the physical reality, can include to Entity Relationship
Diagrams.

10
 Example for Domain Model

The outputs of these processes will be input to a process of analysis, which is

identifying what is constant throughout the domain system. The main results are a domain
model.

Tool support for DSM

Many General-Purpose Modeling languages already have tool support available in

the form of CASE tools. DSM languages tend to have too small a market size to support the
construction of a bespoke CASE tool from scratch. Instead, most tool support for DSM
languages is built based on existing DSM frameworks or through DSM environments.

For this case we need to model a large domain as the CASE tools provides us with a
limited solution so this is based on a tool that has the same base and Eclipse specific
particularities called ActifSource.

11
 The main basis of its construction is eclipse.

Actifsource is a domain specific modeling workbench. Actifsource supports the

creation of multiple domain models which can be linked together. It comes with a UML-
like graphical editor to create domain specific languages and a general graphical editor to
edit structures in the created languages.

Interoperability

Actifsource can use models from other modeling tools by importing and exporting
the ecore format which is defined by the Eclipse Modeling Framework.

Design of a Meta-Model Specific Domain

12
 Design of a Meta-Model Specific Domain with extensions

Creating a domain model with ActifSource

Use Object-Property-Role-Relationship (OPRR) data model, definition of the DSM

language notation with a graphical symbol editor, and the definition of code generators
using a Domain-Specific Language.

Actifsource allows you to manage your feature structure and generate all structural
code artifacts and their interdependencies needed to build your complex software-system

The tool is based on obtaining the business Goals, as well as information from
stakeholders and information from existing systems and processes for the development of
artifacts.
It will be useful for many types of software engineers and administrators, as well as
domain analysts.

13
Conclusions

I presented a domain modeling, showing how its characteristics could be specified

using a model based on features, scenarios, goals and lexicon.

The Domain Model presented is the basis for building a SPL

Using the DSM based approach a decision support system with appropriate
visualization can be realized cost efficient.

Domain-specific modeling is most often used only in the design phase of software
development process

We are said to be a reliable method because of the variety of tools that support it as
CASE tools provides us with a great framework and good development.
This method is a very broad area of opportunity in the development of software engineering
in SPL mode, but in this case we use the tool because of its high coupling actifsource the
modeling domain
Product line analysis applies established modeling techniques to engineer the
requirements for a product line of software-intensive systems.

As we saw in this document, the main entrances to the development of domain

model are the business goals, information from the stakeholder, which we have available
components, as well as external information and existing systems.

We are able to develop the information provided various faces to go with such a
final domain model, in which we specify what we have and we can work around that.

The tool allows us to model Actifsource domain models since it has the ability to
process business Goals and information provided by stakeholders, as well as information
needs of existing systems, if they exist.

14
 This method is very useful, as it helps us a good development of the SPL, and
provides us a very broad framework, as well as a range of tools for its implementation.

Its disadvantage is that it requires experience to their modeling, and on occasion is

based on personal experiences, but none of the stakeholders.

15
REFERENCES

[1] Neighbors, J.M. Software Construction using Components. Technical Report 160,
Department of Information and Computer Sciences, University of California, Irvine.

Date December 20-2010

[2] Neighbors, J.M. "The Draco Approach to Constructing Software from Reusable
Components". IEEE Transactions of Software Engineering, SE-10(5)

Date December 20-2010

[3] Dennis de Champeaux, Douglas Lea, and Penelope Faure (1993). Domain Analysis,
chapter 13, Object-Oriented System Development. Addison Wesley. ISBN 0-201-56355-X.

Date December 20-2010

[4] Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future",
IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Date December 20-2010

[5] L. Northrop and P. Clements. A Framework for Software Product Line Practice,
version 5.0. http://www.sei.cmu.edu/productlines/frame_report/

Date December 20-2010

[6] R. Prieto-D´ıaz. Domain Analysis: An Introduction. SIGSOFT Software

Engineering Notes, 15(2):47–54

Date December 20-2010

[7] Espinoza, H.: An Integrated Model-Driven Framework for Specifying and

Analyzing Non-Functional Properties of Real-Time Systems, Thesis.
DRT/LIST/DTSI/SOL/07-265/HE

Date December 20-2010

[8] http://Steven Kelly and Juha-Pekka Tolvanen/domain specific modeling/full_book

Date December 13-2010

[9] http://www.sei.cmu.edu/productlines/frame_report/rel_domains.htm

Date December 10-2010

16
[10] K. Czarnecki and U. W. Eisenecker. Generative Programming. Methods, Tools, and
Applications. Addison Wesley

Date December 20-2010

[11] SEI. Domain Modeling. http://www.sei.cmu.edu/domainengineering/

domain model.html

Date December 20-2010

[12] A Systematic Process for Defining Meshing Tool Software Product Line Domain
Model. Pedro O. Rossel, Departamento de Ingeniería Informática, Universidad Católica de
la Santísima Concepción Alonso de Ribera 2850, Concepción, Chile [email protected]

Date December 20-2010

[13] http://en.wikipedia.org/wiki/Computer-aided_software_engineering

Date November 13-2010

[14] Pohjonen, R., Kelly, S., Domain-Specific Modeling, Dr. Dobb’s Journal

Date December 20-2010

[15] Tolvanen, J.-P., Kelly, S., Domain-Specific Modeling (in German:

domänenspezifische Modellierung) ObjektSpektrum, 4

Date December 20-2010

[16] Kelly, S. and Tolvanen, J.-P., (2008) Domain-Specific Modeling: Enabling Full
Code Generation, John Wiley & Sons, New Jersey. ISBN 978-0-470-03666-2

Date November 26-2010

17