RUP & MDD

Rational Unified Process⌘

• The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation
• RUP is a process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.

Project life-cycle⌘

Four project life-cycle phases⌘

• Inception phase
  • establishing business case (business context, success factors like expected revenue, market recognition, etc., and financial forecast
  • a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated
• Elaboration phase
  • mitigating the key risk items identified by analysis, creating basic architecture of the project
• Construction phase
  • building the software system
• Transition phase
  • transiting the system from development into production, making it available to and understood by the end user

Model Driven Development⌘

References⌘

• IBM Software Group, The Value of Modeling
• Joshua M. Epstein, Why Model?
• Business Modeling: A Practical Guide to Realizing Business Value David Bridgeland and Ron Zahavi - MK/OMG Press, 2008.
• Rebecca Wirfs-Brock, Why Domain Modeling, blog posting, Feb 2013
• Mike Burner, Modeling for Software Development and Operations, https://msdn.microsoft.com/en-us/library/ms954611.aspx

The Value of Modeling⌘

by Gary Cernosek, Eric Naiburg IBM Software Group

When do I model?⌘

Modeling complex applications has several general benefits:

• To better understand the business or engineering situation at hand (“as-is” model) and to create a better system (“to-be” model)
• To build and design a system architecture
• To create visualizations of code and other forms of implementation

When don't I model?⌘

Simple things do not necessarily need a model preceding its construction

• The problem domain is well known.
• The solution is relatively easy to construct.
• Very few people need to collaborate to build or use the solution (often only one).
• The solution requires minimal ongoing maintenance.
• The scope of future needs is unlikely to grow substantially.

Why model software?⌘

By modeling software, developers can:

• Create and communicate software designs before committing additional resources
• Trace the design back to the requirements, helping to ensure that they are building the right system
• Practice iterative development, in which models and other higher levels of abstraction facilitate quick and frequent changes

Unambiguous models produced by domain experts will greatly reduce information loss in the requirements gathering process. Industry-specific models will reduce the risk of inconsistent or improper implementations, improving interoperability across diverse platforms.

How do I model?⌘

• Adopting a standard notation such as UML is an important step in taking a model-driven approach to software development.
• UML is more than just a graphical notational standard—it is a modeling language.
• UML defines syntax (both graphical and textual, in this case) and semantics (the underlying meanings of the symbols and text).

Abstraction⌘

source: IBM Software Group, The Value of Modeling, Figure 1. A spectrum of times, places and ways to model.

• Abstraction selectively exposes certain information while suppressing details deemed unnecessary or unwanted
• Abstraction is the essence of modeling and any visualization of code is indeed an abstraction.

MDA. The next step.⌘

• Model-Driven Architecture (MDA) can be considered the next logical step in the evolution of modeling and model-driven development technologies.
• MDA, based on UML and other related standards, focuses on defining models at varying levels of abstraction and on the transformations defined between these different levels.

Domain Model⌘

by Rebecca Wirfs-Brock, Why Domain Modeling, blog posting, Feb 2013

• Domain Model is a conceptual model of the domain that incorporates both behavior and data (source: wikipedia)
• Domain Modeling allows to make explicit the connections between the business problem and your code.
• It helps to embed domain knowledge in your working solution, and gives a deep shared understanding of the problem domain along with your code.

Creating a Good Model⌘

by David Bridgeland and Ron Zahavi, Business Modeling: A Practical Guide to Realizing Business Value

• Not every model should be built.
• Sometimes the costs of creating and using a model are greater than the benefits that are gained from its use (model value destruction).
• Creating/using a model always takes time:
  • time interacting with the subject matter experts,
  • time spent constructing the model with modeling tools, and making the model simpler
  • time spent finding and fixing problems with the model,
  • and time spent verifying a model with subject matter experts.
  • time spent analyzing the model for business implications,
  • time spent explaining the model to others,
  • time spent maintaining the model when things change, and so on.

The decision about whether to create a model is ultimately an economic decision: Are we going to deliver more value using this model than we will spend creating/using/maintaining it?

Model Value Analysis⌘

• For small models, that can be built in an hour or four, we typically make a quick informal analysis (Do we expect to realize enough benefits to offset the time and trouble of creating the model?)
• Simple and useful model has value.
• More formal analysis - model value analysis - a summary of the expected costs and the expected benefits, and a comparison of the two.

• Spend 1% of the total anticipated modeling time on the model value analysis, to decide whether the other 99% makes economic sense.

4+1 UML Perspectives⌘