Executable UML - PowerPoint PPT Presentation

Loading...

PPT – Executable UML PowerPoint presentation | free to download - id: 6fa67a-MTk4Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Executable UML

Description:

Guest Lecture for QMW Sofware Engineering course. Presented on 28th November 2000. – PowerPoint PPT presentation

Number of Views:15
Avg rating:3.0/5.0
Slides: 38
Provided by: PaulK115
Learn more at: http://www.computing.surrey.ac.uk
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Executable UML


1
Executable UML
  • Two Real-World Projects
  • Paul Krause

2
Lecture 10 - Two Real-World Projects
3
A Talk in Four Parts
  • Prologue
  • Requirements Modeling for Families of Complex
    Systems
  • The Koala Component Model for Consumer
    Electronics Software
  • Epilogue

4
Part I
  • The Prologue
  • Why is Philips interested in Software?
  • The need for Quality
  • What is Quality?

5
Philips Electronics makes Software?
  • Philishave - 35k of software
  • Mid end TV gt 4M of software
  • Development teams gt 100
  • Distributed development
  • e.g. TV development sites at Brugge, Eindhoven,
    Southampton, Vienna, Bangalore, Singapore,
    Briarcliffe, Knoxville

6
The Need for Software Quality
  • Embedded software follows Moores Law
  • doubling in size every two years
  • Diversity of products and their software is also
    increasing rapidly
  • Development time must decrease significantly
  • Reliability
  • Flexibility
  • Extendibility
  • Reusability.

7
What is Quality (or what is it not)!
  • Quality means conformance to requirements
  • BUT!
  • Requirements contain gt15 of all errors
  • Requirements typically grow at gt2 per month
  • Do you conform to requirements errors?
  • Do you conform to new requirements?
  • Whose requirements are you trying to satisfy?
  • Source Capers Jones, 2000

8
Conclusion
  • To achieve quality products we need to look at
    all aspects of our development processes
  • In this lecture we will look at ways of
  • improving requirements management
  • reducing time to market
  • increasing responsiveness to changes in the
    market place.

9
Part II
  • Requirements Modeling for Families of Complex
    Systems
  • Based on presentation by Pierre America, Philips
    Research, and Jan van Wijgerden, Philips Medical
    Systems
  • Presented at the 3rd Int. Workshop on Software
    Architecture for Product Families, March 2000,
    Las Palmas de Gran Canaria, Spain.

10
Contents
  • Introduction
  • Context
  • Documents
  • Family issues
  • Towards a design
  • Experience
  • Conclusion

11
Introduction Product families
  • Deal explicitly with commonalities and
    differences
  • Advantages in
  • Marketing
  • Development
  • Manufacturing
  • Maintenance

12
Introduction Goals
  • Requirements specifications for product families
    should
  • specify what can be expected from the products
  • be agreed on by all stakeholders
  • be sufficiently precise to avoid
    misunderstandings
  • deal explicitly with commonalities and
    differences
  • form a solid basis for further development
  • without unnecessarily limiting the designers
    freedom

13
Context Medical imaging
14
Context Medical imaging X-Ray
15
Context Market and product characteristics
  • Mature market? complex systems
  • Potential hazards (radiation, electricity,
    mechanics, ) ? high demands on products and
    process
  • Relatively few systems, many configurations?
    systems cannot all be tested thoroughly

16
Context Project characteristics
  • Vast range of expertise needed
  • Many (gt100) developers, some new to the domain
  • Carried out jointly by several departments
  • Time to market important
  • Long project duration (several years)
  • Long lifetime of architecture (gt10 years)

17
Documents
  • Commercial Requirements Specification (CRS)
  • positioning of system family in market
  • Systems Requirements Specification (SRS)
  • features mentioned in lists and tables
  • Functional Requirements Specification (FRS)
  • detailed descriptions of use cases (in English)
  • Requirements Object Model
  • concepts and their relationships (in UML)

18
Documents Example model
19
Documents Example use case
  • Use case CloseCircleShutter
  • When the CloseShuttersEvent is received from the
    ClinicalUser, then the Diameter of the Object
    CircleShutter is decreased with a fixed Speed,
    until either the StopShuttersEvent or the
    OpenShuttersEvent is received.

20
Documents Structure of FRS
  • Divided into chapters according to areas of
    functionality
  • Different kinds of user (clinical user, field
    service. )
  • Different phases of workflow
  • Often coincides with areas of expertise of FRS
    authors.
  • Does not imply the same subdivision in design.
  • Examples

Administration Patient positioning AcquisitionFie
ld service
Reviewing Printing Archiving
21
Family issues Expressing variation Object model
  • Specialization
  • Multiplicity
  • Attributes

22
Family issues Expressing variation Use cases
  • Behaviour of use cases may depend on model,
    including the above variation mechanisms.
  • Different systems may support different sets of
    use cases
  • Result
  • Precise and detailed specifications for the
    domain
  • Concise specifications for individual systems

23
Experience
  • Tried out in one large development project and
    several small feasibility studies
  • Large FRS15 chapters 500 use cases
  • Large requirements model100 diagrams 1000
    relationships 700 classes 1500 attributes
  • Solid basis of shared knowledge
  • Effort well spent
  • Object model relatively immune to changes

24
Conclusion
  • We learned
  • Early construction of a requirements object model
    provides an explicit, shared map of concepts.
  • Developing use cases and object model hand in
    hand leads to precise use cases and a complete
    model.
  • Overlapping groups allow many participants and
    parallel work, while maintaining consistency.
  • Not the individual technique counts, but the way
    they fit together.

25
Part III
  • The Koala Component Model for Consumer
    Electronics Software
  • For more information, see article by Rob van
    Ommering, Frank van der Linden (Philips Research
    Laboratories, Eindhoven), Jeff Kramer and Jeff
    Magee (Imperial College)

26
Contents of Part III
  • Motivation - the need for components
  • The Koala model
  • Coping with evolution
  • Conclusions

27
The need for components
  • Consumer Electronics products are members of
    complex family structures
  • Exhibit diversity in
  • product features
  • user control style
  • supported broadcasting standards
  • hardware technology
  • Need to create new products by extending and
    rearranging elements of existing products

28
The need for components
  • Object-oriented frameworks enable multiple
    applications to be created from shared structure
    and code
  • but changing the structure significantly is
    difficult
  • Component-based approaches let engineers
    construct multiple configurations with variations
    in both structure and content
  • component - an encapsulated piece of software
    with an explicit interface to its environment
  • components - can be used in many different
    configurations

29
The need for requires interfaces
30
The Koala Model
  • Components
  • units of design development and reuse
  • Interfaces
  • a component communicates with its environment
    through interfaces
  • an interface is a small set of semantically
    related functions
  • A component provides functionality through its
    interfaces
  • To do so, it may also require functionality
    through its interfaces

31
Koalas graphical notation
32
Configurations and Compound Components
  • A configuration is a set of components connected
    together to form a product
  • all requires interfaces must be bound to
    precisely one provides interface
  • each provides interface can be bound to zero or
    more requires interfaces
  • It may be useful to compose Compound Components
    from basic components
  • But always, when binding interfaces there must be
    a unique definition of each function, but a
    function may be called by many other functions

33
Conclusion
  • Able to introduce component orientation in a
    domain that is resource-constrained
  • Graphical notation helpful in design discussions
  • More than 100 software developers within Philips
    are currently using Koala, on an increasing
    diversity of products

34
Part IV
  • Epilogue

35
We have seen
  • how the need to deliver quality products in a
    volatile and complex market place has driven
    developments in Software Engineering
  • how UML can be exploited to strengthen the
    requirements process for families of complex
    systems
  • a component model that enables new configurations
    to be rapidly developed for novel products

36
Global concerns
Mainstream TV Singapore
37
Conclusion
  • Software Engineering issues are vitally important
  • But this is not the whole story
  • co-ordination
  • collaboration
  • communication
  • people management
  • planning
  • strategy
  • technology

The End!
About PowerShow.com