Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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
www.uv.mx/personal/kcortes
www.uv.mx/its
@karencortesv
@CA_ingSoft