1 / 32

Steven H. Dam, Ph.D., ESEP President, SPEC Innovations 571-485-7805 Steven.dam@specinnovations

Lifecycle Modeling – A Quick Overview of a New Methodology for Simple, Rapid Development, Operations, and Support. Steven H. Dam, Ph.D., ESEP President, SPEC Innovations 571-485-7805 Steven.dam@specinnovations.com May 15, 2012. Overview. What is Cloud Computing? Why a New Language?

chava
Download Presentation

Steven H. Dam, Ph.D., ESEP President, SPEC Innovations 571-485-7805 Steven.dam@specinnovations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Lifecycle Modeling – A Quick Overview of a New Methodology for Simple, Rapid Development, Operations, and Support Steven H. Dam, Ph.D., ESEP President, SPEC Innovations 571-485-7805 Steven.dam@specinnovations.com May 15, 2012

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

  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. Normal Server Deployment App App App App Hardware 1) Two applications running under normal conditions 2) One application’s demand increased 3) Server crashed, both applications down

  7. Virtualized Server Deployment 3) Added third server, extended virtual server App App 1) Two applications running under normal conditions App App 2) One application’s demand increased 4) Application’s demand increased 5) Application’s demand decreased 6) Hardware server crashes, virtualization continues Hardware Virtualization Hardware Virtualization Hardware Hardware Hardware

  8. Net Cloud Virtualized Servers Disk Box 0 (Controller) App App App App Hardware Virtualization Layer Hardware Hardware Hardware

  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 SysMLmay 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 diagrams The result: Lifecycle Modeling Language

  17. LIFECYCLE MODELING LANGUAGE (LML) OVERVIEW A language to simplify system design description for the cloud

  18. The Lifecycle Current Operations and Maintenance Future Operations and Maintenance Demolition and Disposal Operational T&E and Transition Architecture Development Integration and Test System Design Integration & Verification Design & Analysis Hardware/Software Acquisition Program Management

  19. Systems Engineering During Design Phase System Analysis and Control Requirements Analysis Top Down Note: On the cloud the customer participate in the requirements development process and as such may want to focus on a scenario-based approach Functional Analysis and Allocation Best Use: “Classical SE” Middle Out Best Use: Architecture Development (To-Be) Synthesis Adapted from EIA-632 Bottom Up Best Use: Reverse Engineering (As-Is)

  20. Lifecycle Modeling Language (LML) • LML combines the logical constructs with an ontology to capture information • SysML – mainly constructs – limited ontology • DoDAFMetamodel 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 *Ontology = Taxonomy + relationships among terms and concepts ** Taxonomy = Collection of standardized, defined terms or concepts • 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

  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

  23. LML Sequencing CASE Action B Condition 1 SEQUENTIAL Action A CASE Action A Action B Action C Condition 2 PARALLEL LOOP 1 to n (iterate) Until r < z (loop) Range (e.g.) Action A Range Action C Coordinated by Asset C SYNC Action B Action C (Exit Criteria) Action A LOOP 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

  24. LML Action Diagram Captures Behavior Data 1.4 Element in DecisionAction External Output Data Data 1 1.2 Request ServiceAction OR 1.5 Exit CriteriaAction Loop 7 times 1.6 LOOP Element in LoopAction 1.7 End 1.1 Start Synchronize Information?Action SerialElementAction Data 2 AND Trigger Data Data 3 1.3 Element in ParallelAction Data External Input

  25. LML Physical Block Diagram* Asset (Human) Asset (System) Sensor Systems Operator Sensor Platform P.5.2.1 P.5.2.2 I.1.3 Operator-Sensor Platform Interface connected with/connects used by/uses • capacity (10 Mbits/sec) • Latency (100 millisec) Asset (Resource) Sensor System Memory • maximum quantity (6 Gbytes) • minimum quantity (10 Kbytes) R.5.2.2.1 *Note: Work in progress

  26. LML Combined Physical Behavior Diagram* Enables Instances and Clones Asset (System) Sensor Platform A(3) Asset (Resource) P.5.2.2 Asset (Human) Sensor Systems Operator P.5.2.1 Asset (System) Sensor Platform A(2) Clones provide multiple instances of an Asset for use in simulation Asset (Resource) P.5.2.2 I.1.3 Operator-Sensor Platform Interface A.3.1 Deploy Sensor connected with/connects A.3.1 Action (System Function) Asset (System) Sensor Platform A(1) Asset (Resource) P.5.2.2 input to/input from A.3.2 Sense Targets Deploy Command A.3.1 Action (System Function) input to/input from *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) AND

  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. 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

  32. Nimbus SE Features and Benefits Please see our booth for more information

More Related