Domains and ModelsKaren Cortés V.

1

Karen Cortés V.

April 3rd, 2014

“Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be usually need your code; it'll be obvious”.

Fred Brooks.

2

Fred Brooks

• Ingeniero de Software y científico de la computación.

• Dirigió el desarrollo

3

• Dirigió el desarrollo del OS/360

• Autor del MythicalMan-Month

“Every business is a software business''.

Watts Humphrey, Winning with Software

4

5

FergusonFerguson, J., “, J., “CrouchingCrouching DragonDragon, , HiddenHidden Software: Software in Software: Software in DoDDoD

WeaponWeapon SystemsSystems”, Software, ”, Software, VolVol 18, 18, IssueIssue 4, 20014, 2001

• Originador del modelo de madurez de capacidades CMM, el proceso de software para equipos (TSP) y el proceso personal de software (PSP).de software (PSP).

• En IBM, Humphrey puso en práctica mejoras en los procesos y logró impactar la calidad de los productos y la productividad de los desarrolladores.

6

Agenda

• Domain

• Models

• Reuse

7

• Software Product Lines

• Product Line Architecture (PLA)

• AOPLA

What is a domain?

is a field of study that defines a set ofcommon requirements, terminology,and functionality

8

Approaches

• Domain-driven design

• Domain engineering

9

Premises

• Placing focus on the core domain and domain logic.

• Basing complex designs on a model of the domain. model of the domain.

• Collaboration between technical and domain experts

10

Model-1

Representation or simplified version of a concept, phenomenon, relationship, structure, system, or any aspect of the real world

11

Model-2

• One of the primary artifacts for capturing knowledge about a business problem and a technical solution.

• The model is the primary language for communication amongs technical people

• A means of communication between all system stakeholders and technical people

12

Model-3

• Assist in reasoning about the system's attributes

• Provide implementation guidelines for system developersfor system developers

• Help manage complexity by capturing details about aspects or views of a system while ignoring nonessential details

13

Software Reuse

• Software reuse is the process of creating software systems from existing software rather than building software systems from scratch1scratch1

14

1. Krueger, CH. W. ”Software reuse”, ACM Computing Surveys, Vol. 24, No. 2, pp. 131-183, 1992.

Why reuse?

Software development organizations are still failing to fulfill three impoprtant aspects:

– Quality

Time– Time

– Cost

15

Approaches that promote reuse

• Object Oriented Software Development

• Component-Based Software DevelopmentDevelopment

16

Software Product Lines

What is a Software Product Line?

A Software Product Line is a “set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market

17

needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.”2

2. P. Clements, and L. Northrop, Software Product Lines: Practices and Patterns, Addison-Wesley, USA, 2001

18

Some examples-1

19

Some examples-2

20

Problems addressed by SPL

• Disatisfaction with current project/product performance

• Need to reduce cost and schedule

• Complexity of managing and maintaining too

21

• Complexity of managing and maintaining too many products variants.

• Lack of staff

• Need to quickly respond to customer/marketplace demands.

SEI’s Framework for Product Line Practice

22

Three essential activities for Software Product Lines taken from

http://www.sei.cmu.edu/productlines/frame_report/PL.essential.act.htm

� SPL main characteristics:

• Two-tier organization

23

• Planned and proactive reuse of core assets

• Architecture-centricdevelopment

ESAPS & CAFÉ Product Family Engineering Process

24

The Product Family Engineering Process taken fromhttp://www.esi.es/en/Projects/Families/E1.4b-Method-Catalogue/Start_SFE_Catalogue.htm

El Vasa

En los años 1620s, Suecia y Polonia se encontraban en guerra y sus flotas se encontraban en lucha en el Mar Báltico. El rey de Suecia, Gustavo Adolfo, estaba determinado a poner fin a ella y encargó un nuevo y poderoso buque de guerra, el Vasa. Este buque tendría 70 m. de largo con capacidad para transportar hasta 300 soldados y contaría con 64 cañones en dos 300 soldados y contaría con 64 cañones en dos cubiertas Con la intención de agregar un poder sin igual a su flota el rey insistió en forzar la capacidad de armamento del Vasa al límite. La construcción fue encargada al experimentado y prestigiado Henry Hybertsson, de origen holandés. Sin embargo, el Vasa superaba su amplia experiencia. Los buques con dos cubiertas de cañones eran raros y ningún buque de guerra se había construido a la fecha del tamaño del Vasa ni con tal cantidad de armamento.

25

Como todos los arquitectos de su tiempo, Hybertsson hizo uso de su experiencia y balanceó todos los intereses que estaban en juego (tiempo de entrega, confiabilidad, seguridad, desempeño, funcionalidad y costo). Su experiencia le indicó que construyera el buque como un buque de una sola cubierta y de ahí extrapolar, lo cual estaba de acuerdo con el medio de extrapolar, lo cual estaba de acuerdo con el medio de la época. Hybertsson tuvo el buen tino de morir un año antes de terminar el buque.

26

Sin embargo el proyecto se concluyó de acuerdo a sus especificaciones. El 10 de agosto de 1628 el Vasa estaba listo. El Vasa desplegó sus velas, se adentró en las aguas del mar de Estocolmo y disparó sus cañones como saludo. Inmediatamente se volteó, el agua empezó a entrar por las escotillas de los cañones y se hundió. En total 150 hombres de su tripulación murieron hundió. En total 150 hombres de su tripulación murieron ahogados.

27

Software Product Line Architecture

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of

28

the externally visible properties of those elements, and the relationships among them.”3

3. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Second Edition, Addison-Wesley, USA, 2003.

Issues in PLA

• Definition of a reference architecture fromwhich specific architectures must be derived

• PL quality attributes as well as PLA-specificquality attributes

• Support for PL evolution

29

• Support for PL evolution

• Commonality and variation analysis

How to design a PLA? - 1

• SEI’s framework for PL practice

• In Software Engineering Practice Areas:

• Architecture definition

• Architecture evaluation

30

• Architecture evaluation

• Architecture recovery in Mining existing assets practice area

• Architecture definition practice area:

• Specific practices:

• Architecture definition and architecture-based development

How to design a PLA? - 2

31

architecture-based development

• Architecture styles and patterns

• Mechanisms for variability in a PLA

• Planning for architectural variation

AOPLA (Aspect-Oriented Product Line Architecture)

The definition of an architecture modelencompassing:

a) PL-specific quality attributes,

b) Products quality attributes

c) commonality and variabilitysupport, and

32

Product Line Quality Model

• Elements:

• Quality requirements: scenarios

• Metrics

• Architectural patterns• Architectural patterns

• Use of means

33

•PL-specific quality attributes•Variability•Derivability•Reusability•Rateability

34

•Rateability• Integrability•Correctness• Evolvability•Manageability•Maintainability

AOPLA

Business case definition

35

Domainengineering

Architecturemodeling

Questions? . . .

36

kcortes@uv.mx

www.uv.mx/personal/kcortes

www.uv.mx/its

@karencortesv

@CA_ingSoft