steven h. dam, ph.d., esep president, spec innovations 571-485-7805 steven.dam@specinnovations

© 2012 Systems and Proposal Engineering Company. All Rights Reserved

1

Lifecycle Modeling – A Quick Overview of a New Methodology for Simple, Rapid Development, Operations, and Support

Steven H. Dam, Ph.D., ESEPPresident, SPEC [email protected]

May 15, 2012


Overview

What is Cloud Computing? Why a New Language? Lifecycle Modeling Language Overview Implementing LML

2


3

What is Cloud Computing?Hint: It’s not just a website


4

What is cloud computing?

• Definition from NIST: – Cloud computing is a model for enabling

convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models

From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012


5

Five Essential Characteristics• On-demand self-service. A consumer can unilaterally provision computing capabilities,

such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider.

• Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

• Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.

• Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.

• Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.

From presentation by Jim Sweeney, GTSI at the Technology Leadership Series 2012 Seminar, January 19, 2012


6

Hardware

App AppAppApp

Normal Server Deployment

1) Two applications running under normal conditions

2) One application’s demand increased3) Server crashed, both applications down


7

Hardware HardwareHardware

Hardware VirtualizationHardware Virtualization

App AppAppApp

Virtualized Server Deployment

1) Two applications running under normal conditions

2) One application’s demand increased4) Application’s demand increased5) Application’s demand decreased6) Hardware server crashes,virtualization continues

3) Added third server, extended virtual server


8

Hardware Hardware Hardware

Hardware Virtualization Layer

Box

0(C

ontr

olle

r)

App App App App

Net

Disk

Cloud Virtualized Servers


9

Advantages

• Reduce the total number of independent servers

• Individual applications are secured from one another (“Sandboxed”)

• Servers stored at secure locations• Only accessible on the secure network• Inexpensive• Scalable


10

Disadvantages• Scalability means “no-SQL” out of the box

– SQL Databases are designed for single servers or small clusters

– Caching data in memory becomes more important as it is inefficient (and expensive) for applications to read the database for common queries

– Requires understanding use cases ahead of time

• Software development cost is typically higher– Bleeding edge technology (changing everyday)– Requires significant new code – cannot just port

old code


11

Cloud Computing Bottom-Line• Enhances scalability• Enhances capability for large

collaborations on design and development throughout the lifecycle

• Upside: We can design more complex systems

• Downside: We will have to manage more complex systems development


12

Why a New Language?


13

State of Current “Languages”• In the past decade, the Unified Modeling

Language (UML) and now the profile Systems Modeling Language (SySML) have dominated the discussion

• Why?– Perception that software is “the problem”– Hence need for an “object” approach

• SysML was designed to relate systems thinking to software development, thus improving communication between systems engineers (SE) and software developers


14

Why Objects Are Not the Answer• Although SysML may improve the communication

of design between SEs and the software developers it does not communicate well to anyone else– No other discipline in the lifecycle uses object oriented

design and analysis extensively– Users in particular have little interest/acceptance of

this technique– Software developers who have adopted Agile

programming techniques want functional requirements (and resent SEs trying to write software)

– Many software languages are hybrid object and functional


15

So What Do We Do?

• Recognize that our primary job as SEs is to communicate between all stakeholders in the lifecycle

• Be prepared to translate between all the disciplines

• Reduce complexity in our language to facilitate communication


16

What We Did

• In preparing for the cloud computing world of SE we:– Researched the variety of languages (ontologies)

in common use (DM2, SysML, BPMN, IDEF, SREM, etc.)

– Researched the variety of representations (FFBDs, N2, Behavior Diagrams, Class Diagrams, Electrical Engineering Diagrams, etc.)

– Took the best of each of these languages and representations and distilled them down to the essential elements, relationships, attributes, and diagramsThe result: Lifecycle Modeling Language


LIFECYCLE MODELING LANGUAGE (LML) OVERVIEW

17

A language to simplify system design description for the cloud


18

The Lifecycle

Architecture Development

System Design

Hardware/Software Acquisition

Integration and Test

Operational T&E and Transition

Future Operations and Maintenance

Demolition and Disposal

Program Management

Current Operations and Maintenance

Desig

n &

Analysis

Inte

gra

tion

& V

eri

fica

tion


19

Requirements Analysis

Functional Analysis and Allocation

Synthesis

System Analysis and Control

Middle OutBest Use: Architecture Development (To-Be)

Systems Engineering During Design Phase

Bottom Up

Top DownBest Use: “Classical SE”

Best Use: Reverse Engineering (As-Is)

Adapted from EIA-632

Note: On the cloud the customer participate in the requirements development process and as such may want to focus on a scenario-based approach


20

Lifecycle Modeling Language (LML)

• LML combines the logical constructs with an ontology to capture information– SysML – mainly constructs – limited ontology– DoDAF Metamodel 2.0 (DM2) ontology only

• LML simplifies both the “constructs” and ontology to make them more complete, yet easier to use

• Goal: A language that works across the full lifecycle


21

LML Ontology* Overview

• Taxonomy**: – 12 primary element classes– Many types of each element class

• Action (types = Function, Activity, Task, etc.)

• Relationships: almost all classes related to each other and themselves with consistent words– Asset performs Action/Action performed by

Asset– Hierarchies: decomposed by/decomposes– Peer-to-Peer: related to/relates

*Ontology = Taxonomy + relationships among terms and concepts** Taxonomy = Collection of standardized, defined terms or concepts


22

LML Taxonomy Simplifies and Enhances the Semantic Schema Elements• Technical

– Action– Artifact– Asset

• Resource

– Characteristic– Input/Output– Link– Statement

• Requirement

• Programmatic/Technical– Cost– Decision– Location

• Physical, Orbital, Virtual

– Risk– Time


LML Sequencing

Action A Action BAction A

Action B

Action C

Condition 1

Condition 2

Action A

Action B

LOOP

Action A

Action C

Range

Range (e.g.) 1 to n (iterate)

Until r < z (loop)

PARALLEL

SEQUENTIAL

CASE

SYNC

CASE

Action C (Exit Criteria)L

OOP

23

No constructs – only special types of Actions – ones that enable the modeling of command and control/ information assurance to capture the critical decisions in your model

Coordinated by Asset C


24

OR

LML Action Diagram Captures Behavior

Request ServiceAction

Element in ParallelAction

Start End

Trigger

AND

Data 2

Synchronize Information?

Action

1.2

1.3

1.7

Data

Data 1

SerialElement

Action

1.1Element in

LoopAction

1.6Loop

7 times

Data

External Input

Data

External Output

Data

Data 3LOOP Exit Criteria

Action

1.5

Element in Decision

Action

1.4


25

LML Physical Block Diagram*

Sensor Systems Operator

P.5.2.1

Asset (Human)

I.1.3 Operator-Sensor Platform InterfaceSensor Platform

P.5.2.2

Asset (System)

connected with/connects

Sensor System Memory

R.5.2.2.1

Asset (Resource)

used by/uses• capacity (10 Mbits/sec)• Latency (100 millisec)

• maximum quantity (6 Gbytes)• minimum quantity (10 Kbytes)

*Note: Work in progress


LML Combined Physical Behavior Diagram* Enables Instances and Clones

26

Sensor Systems Operator

P.5.2.1

Asset (Human)

I.1.3 Operator-Sensor Platform Interface

connected with/connects

Sensor Platform A(2)

P.5.2.2

Asset (System)

Asset (Resource)


P.5.2.2

Asset (System)

Asset (Resource)


P.5.2.2

Asset (System)

Asset (Resource) Clon

es p

rovi

de m

ultip

le in

stan

ces

of

an A

sset

for u

se in

sim

ulati

on

A.3.1

Action (System Function)

A.3.2

Sense Targets

A.3.1

Action (System Function)

A.3.1

Deploy Sensor

input to/input from

input to/input from

Deploy Command

*Note: Work in progress


27

LML Translation• Two types of mapping for tailoring:

– Map names of classes to enable other “schema” models to be used

– Map symbols used (e.g., change from LML Logic to Electrical Engineering symbols)

– Enable diagram translations (e.g., Action Diagram to IDEF 0)

LML Symbol

Electrical Engineering

BPMN …

AND

LML Class DM2 SysML …

Action Activity Activity

Asset Performer Actor


28

Other Diagrams

• Physical Block Diagrams– With option for icon

substitution

• Interface Diagrams– N2 (Assets or Actions)

• Hierarchy Diagrams– Automatically color coded

by class

• Time Diagrams– Gantt Charts– Timeline Diagram

• Location Diagrams– Maps for Earth– Orbital charts

• Risk Chart– Standard

risk/opportunity chart

• Organization Charts– Showing lines of

communication, as well as lines of authority

• Pie/Bar/Line Charts– For cost and

performance

• Combined Physical and Functional Diagram (?)


29 CHARACTERISTIC TIMELOCATION

LOCATION TIMECHARACTER ISTIC STATEMENT

LINK RISK STATEMENT

LINK RISK

causesmitigates

referenced byresolves

based ontakes

occurs

located atdefines protocol

forreferenced by

causesmitigatesresolves

based on occurs

causesincurred bymitigatesresolves

based onincurred by

occurs


ACTION ARTIFACT ASSET COST INPUT/OUTPUT DECISION

ACTION ARTIFACT ASSET COST INPUT/OUTPUT DECISION

referenced by

decomposed by decomposes

related torelates

referenced by

captured byconsumed by

performsproduced by

references

decomposed bydecomposesorbited by

orbitsrelated to

relates

causesreferenced by

resolvesreferenced by

incursreferenced by

referenced byspecified by

specifiesreferencesspecifies

ACTION

ARTIFACT

ASSET

CHARACTER-ISTIC

COST

INPUT/ OUTPUT

DECISION

LINK

LOCATION

ISSUE

LINK

LOCATION

RISK

ARTIFACT

ASSET

CHARACTERISTIC

COST

INPUT/ OUTPUT

RISK

STATEMENT

TIME


related torelates

references

capturesconsumes

performed byproduces

specified by

located at

STATEMENT

TIME

ACTIONincursgeneratesreceives

causesresolves

-

specified by incurs -causes

resolvesresponds to

connected by

occursbased on

referenced bysource of

located atcauses

mitigatesresolves

transferred by located at

specifies

decomposed bydecomposes

related torelates

incursspecifies

causesmitigatesresolvesspecifies

based onspecifies

specifies occurs

specifiescauses

resolvesspecifies

specifieslocated atspecifies

incurred bycauses

incurred byresolves

incurred by located atincurred byincurred byreferences

incurred byincurred byspecified by


related torelates

caused byresolved by

responded by

caused byresolved byspecified by

caused byincurs

resolved by

transferscauses

resolves

generated byreceived by

references - specified by incurs


related torelates

causesresolves

locates locates locateslocates

specified bylocates

based on occurs

caused bycauses

mitigatesresolved by

resolves


occurs

-defined protocol by

referencesconnected to specified by incurs


caused bycauses


related torelates

resolved by


located at


based ondelayed by

occurs


caused byreferences

resolved by

occurs

caused bymitigated by

referencesresolved by

caused bymitigated byresolved by

caused bymitigated byresolved byspecified by

caused byincurs

mitigated byresolved by

caused bycauses


related torelates

resolved by


relates

locates locates locates


related torelates

basis ofincurs


caused bycauses

mitigated byresolved by

resolves


located atmitigated by


related torelates

located at

locatesmitigates

based onlocates



related torelates

relates


taken by occurred by

occurred by occurred byspecified by occurred by

occurred by

basis ofcauses

resolvesbasis of

basis oflocated at

occurred by occurred bydelays

occurred byoccurred by related to related to


related torelates

basis ofbasis of

referencessourced by

basis ofbasis of

specified by

LML Relationships Provide Linkage Needed Between the Classes

• decomposed by/decomposes

• orbited by/orbits• related to/relates


30

LML Summary• LML provides the fundamental foundation for a

tool to support SE in the cloud• LML contains the basic technical and

programmatic classes needed for the lifecycle• LML defines the Action Diagram to enable better

definition of logic as functional requirements• LML uses Physical Diagram to provide for

abstraction, instances, and clones, thus simplifying physical models

• LML provides the “80% solution”– It can be extended to meet specific needs (e.g.

adding Question and Answer classes for a survey tool that feeds information into the modeling)


31

Implementing LML


Nimbus SE Features and Benefits

Features Benefits

Chat/Real-time Notification Enables collaboration worldwide

Lifecycle Modeling Language (LML) schema and Web User Interface

Provides simplicity and ease of use with little or no training

Open feature requests with voting on priority by users

Supports transparency between users and developers

Google App Engine’s cloud computing capability

Can scale design to deal with very large projects that include millions of objects

Nimbus security layer with Google App Engine security layer and SSL

Provides secure

Automatic upgrades; no installation; runs on any computer or device (e.g., iPad)

Reduces IT support costs and trouble significantly

Monthly payment plan Buy what you need, when you need it

32 Please see our booth for more information

steven h. dam, ph.d., esep president, spec innovations 571-485-7805 steven.dam@specinnovations

Documents

cloud computing

cloud systems

computing capabilities

proposal engineering

cloud model

network storage

consumer demand

demand network access