Enterprise Architect version 15.2

download
purchase

enzh-CNcsnlfrdehiiditkoplptruskessv

My Profile

Social Media Channels

facebook  twitter  youtube   linkedin

doug rosenberg

doug rosenberg

doug rosenberg

Parallel Agile, Inc. (Founder, Chief Technology Officer) - formerly ICONIX (CEO)
After running ICONIX for 35 years and writing 7 books on UML, use cases, and agile software development, Doug discovered a new way to improve productivity by leveragng parallel development, and founded Parallel Agile (www.parallelagile.com) in 2018 after 4 years of test projects at the USC Center for Software and Systems Engineering, where he's been working with Prof. Barry Boehm.   A new book "Parallel Agile - Faster Delivery, Fewer Defects, Lower Cost" is mostly written and will be released during 2019.   We're also developing a Parallel Agile Add-In for Enterprise Architect and are available for training and consulting.  
In his previous lifetime...
 
Doug Rosenberg founded ICONIX in his living room in 1984 and began training companies in object-oriented analysis and design around 1990. ICONIX specializes in JumpStart training for UML and SysML, and offers both onsite and open-enrollment courses.
Doug developed a Unified Booch/Rumbaugh/Jacobson approach to modeling in 1993, several years before the advent of UML, and began writing books around 1995. Design Driven Testing is his 6th book on software engineering. He’s also authored numerous multimedia tutorials (including Enterprise Architect for Power Users) and several eBooks, including Embedded Systems Development with SysML.
Doug has spent the last few years doing "deep dive" consulting into cutting-edge technology including cross-platform mobile app development, REST APIs, and NoSQL databases, and gaining first-hand experience on some "hardcore agile" projects of varying sizes.  He's also been working with dozens of graduate students at the University of Southern California Center for Systems and Software Engineering (USC CSSE), managing Directed Research projects and developing/piloting the Parallel Agile process.

 

Doug Rosenberg, ICONIX

 

 

A “Secret Decoder Ring” may be required for Service Oriented Acronyms

Figure 1 - A “Secret Decoder Ring” may be required for Service Oriented Acronyms

Trying to make sense out of the “acronym-scrabble” that engulfs Service Oriented Architectures (SOA) is a major challenge.  We’re going to take a shot at it in this article by defining a process roadmap and following a single example all the way from architecture to code. Along the way we’ll illustrate many of the key features of Enterprise Architect Business and Software Engineering Edition.

The example we’ll follow will be a Service-Oriented Architecture (SOA) car rental system model, developed by the team at Sparx Systems, that’s implemented with a combination of web-services and custom software.  Our SOA Process Roadmap will tie everything together in what we hope will be a clear and understandable manner.

Why a Service-Oriented Architecture Roadmap?

Web services and SOA have become increasingly important in today’s IT universe.  A recent article from IBM Global Technology Services[1] suggests that nearly half the companies in the world are either adopting, piloting, or considering SOA, and that investments in these projects may reach between $18 Billion and $160 Billion in the near future.  With those sorts of numbers, it stands to reason that many readers will be interested in a roadmap and a cohesive example that brings some clarity to the problem.  Hopefully this includes you.

 

A Quick Introduction to SOA

Service-Oriented Architecture (SOA) is an approach to building complex software systems from a set of reusable services that obey service-orientation principles. Many people believe that Service Oriented Architectures can help businesses to be more “agile” -- in other words, enable faster and more cost-effective responses to changing conditions.

SOA enables construction of applications from fairly large chunks of reusable functionality that can built quickly, primarily from existing services.   Thus, SOA promotes reuse at a “macro” level, and, in theory, as an organization publishes more and more business functionality as services over time, the cost of building applications that use those services decreases.

A service that obeys the principles of service-orientation is an autonomous, loosely coupled, and stateless unit of functionality that is made available by a formally defined interface.  The functionality provided by a service is discoverable by applications that use the service.

Services are not allowed to call other services, but may communicate with them via messages.  That is, services are loosely coupled, and each service implements a single action, such as placing an online rental car reservation.

Services are designed without knowing who will be using them. In a service-oriented architecture, applications are built from services which communicate via messages using a process known as orchestration.

A popular approach to implementing a service-oriented architecture is via web services, which make services accessible over the Internet independent of platforms and programming languages. The BPEL language is often used to orchestrate SOA applications.  Building applications from services requires metadata that describes the characteristics of the services, and the data that is used. Typically, XML is typically used describe data, WSDL is used describe the services themselves, and SOAP (Simple Object Access Protocol) describes communication between services.

 

As it turns out, an SOA example also serves to illustrate many of the features of the Sparx Systems solution, which supports building “executable business processes” that use WSDL (Web Service Definition Language) to implement their solution.  And, since projects don’t live by web services alone, Enterprise Architect has numerous other useful features for handling those parts of the application that require custom (non-web service) development.  In particular we’ll be spending a significant amount of time exploring in this book include a new and unique capability for “behavioral code generation” for the enforcement of Business Rules, and tight integration with IDEs, including Eclipse and Visual Studio.  We’ve leveraged the power of these capabilities into our SOA Roadmap.

The SOA Roadmap (aka ICONIX Process for SOA Development)

As with all of our ICONIX Process Roadmaps[2], our SOA roadmap is defined as a set of activity diagrams.  In this case, the roadmap provides a “cookbook” set of steps that can be followed for building systems that are based around a Service-Oriented Architecture.

 ICONIX Process Roadmap for Service-Oriented Architecture Development

Figure 2 – ICONIX Process Roadmap for Service-Oriented Architecture Development

Figure 2 shows our top-level roadmap. Some of these top-level activities will expand out to a child diagram showing further detail.   As you can see, the top-level roadmap includes some “common stuff” like figuring out your requirements and modeling the problem domain, and then provides multiple paths for developing different flavors of business processes, all the way to code. 


Getting Ready for SOA

As shown in our top-level roadmap, there are a few “setup” activities that will are necessary at the beginning of our SOA project.  We’ll begin with a simple domain model (also called a fact model), that shows the main objects in the problem domain (Figure 3).

 Domain Model (also called Fact Model) for the Car Rental System

Figure 3 – Domain Model (also called Fact Model) for the Car Rental System

As you can see, the domain model establishes the vocabulary we use to describe our system, and shows relationships between objects in the problem domain.  In most cases these relationships include UML generalization and aggregation relationships (not shown here).

 

Business Rules are represented in Enterprise Architect as stereotyped Requirements.  Figure 4  shows a Requirement Diagram for our Car Rental System that organizes these business rules according to different RuleTasks.  We’ll talk more about RuleTasks (actions that enforce Business Rules) shortly.

 Business Rules for the Car Rental System, organized by RuleTask

Figure 4 – Business Rules for the Car Rental System, organized by RuleTask

The top-level roadmap shown in Figure 2 reflects the philosophy that when you set out to implement a system using a service-oriented architecture, there will effectively be a mix of 3 different kinds of scenarios:

1)     Scenarios that use web services (for which we will develop web service interfaces using WSDL, and orchestrate the use of those web services using BPMN and BPEL.

2)     Scenarios that enforce business rules (for which we will use activity diagrams and the business rule composer)

3)     Regular old software use cases (which we won't discuss in this book because we’ve covered it quite thoroughly in my other books)

Most systems will contain a mix of these different types of scenarios. 


 

In many cases (but not all) the "web-service scenarios" will cross Business To Business (B2B) boundaries.  For example, a car rental reservation system talking to a credit card company to run a payment transaction is a B2B web-service scenario. Where a business process can be implemented via web services, we follow the branch on the left: web service interface definition using WSDL, and orchestration using BPMN and BPEL.

The "business rule scenarios" are more likely to be within the boundaries of one business, for example, the car rental system enforcing eligibility rules on driver age, credit score, etc.  There is little or no user interface in these business rule scenarios, so they can be completely code generated from an activity diagram using the business rule composer. For processes that are primarily focused on enforcing business rules, we take the right branch: Behavioral Code Generation from Activity Diagrams using the Business Rule Composer.


Finally there is the user interface.  These would be the screens of the car rental system that the reservations agent accesses, and which would trigger the business rule checks and B2B transactions.  These parts of the system are best modeled using use cases, following a “use case driven” approach that’s out of scope for this article, but well documented in my other books[3].   

With all of these branches, we can compile and build using either Eclipse or Visual Studio, and use the Sparx “MDG Integration” technology to keep models and code in-synch. 

 

A Short Intro to Web Services and WSDL

Suppose you wrote an interesting application (maybe a program that automatically generated a horoscope based on your birthday and today’s date), and you wanted to publish your application to the Internet so anybody in the world could purchase their horoscope from you.  How would you do that?  Most likely, you’d do it with a web service.

Web services support distributed, platform-independent development. Using web services, you can publish any application you choose to build over the web. A web service can be written in any language and hosted on any computer that’s connected to the Internet. 

The concept behind web services isn’t new; previously developed similar approaches include OMG CORBA, Microsoft DCOM, and Java/RMI. You can think of a web service as something like an Internet-enabled API.

You’d describe your horoscope web service using Web Service Description Language (WSDL); an XML-based language that describes the public interface to the web service.  WSDL tells you only how you can interact with the web service; it says nothing about how the web service works internally.

WSDL defines Services as collections of Network Endpoints, or Ports; a collection of Ports defines a Service. A Port associates a network address with a reusable binding, and a Message is an abstract description of the data that is being exchanged.  A WSDL file has an “abstract” section that describes Ports and Messages, and a “concrete” section that describes specific instances of their usage.  This file structure is shown in Figure 5.

WSDL file structure showing Abstract and Concrete sections

Figure 5 - WSDL file structure showing Abstract and Concrete sections (from Wikipedia[4])

Developing Web Service Interfaces (WSDL) with Enterprise Architect

Before we can use BPMN and BPEL to orchestrate a collaborating group of web services, we first need to be able to define the web services themselves. 

WSDL Packages in Enterprise Architect are organized into Types, Messages, Ports, Bindings, and Services as shown in Figure 6.

A look inside a WSDL Package for the CarRental web service

Figure 6 – A look inside a WSDL Package for the CarRental web service

Generating WSDL

Once we’ve defined our Types, Bindings, Ports, Messages, and Services, it’s time to generate WSDL by right-clicking on our WSDL component and choosing Generate WSDL from the context menu.  Figure 7 shows the WSDL generation in progress.

Enterprise Architect generates WSDL automatically

Figure 7- Enterprise Architect generates WSDL automatically

The result of WSDL generation for our Car Rental component can be seen in Figure 8.

We’ve successfully generated WSDL for the Car Rental component

Figure 8 - We’ve successfully generated WSDL for the Car Rental component

 

Web Service Orchestration using BPEL

The term “orchestration” is often used to describe implementing a business process by using a number of web services in a collaborative way.  We’ll use BPEL to orchestrate web services, and BPMN to model BPEL. 

Note that it’s possible to draw BPMN (Business Process Modeling Notation) diagrams to model business processes without generating BPEL (Business Process Execution Language).  And, you can model BPEL using other graphical notations besides BPMN.  But one of the more interesting strategies, which we’re following in this roadmap, involves using BPMN to model BPEL processes[5].

Figure 9 shows the roadmap basic steps for using BPMN to model BPEL.  

 

Roadmap: We use BPMN to model BPEL, then generate BPEL code

Figure 9 – Roadmap: We use BPMN to model BPEL, then generate BPEL code

A Quick Overview of BPEL

BPEL is short for WS-BPEL, which is short for Web Services Business Process Execution Language.  You can use BPEL to build web services, to write programs that call web services, and to describe high-level business processes that make use of web services.

BPEL business processes are often used to implement business-to-business (B2B) transactions where one business provides a web service and another business uses it.   Our car rental example in this book is an example of this sort of B2B transaction.

BPEL is sometimes referred to as an orchestration language because it supports complex orchestrations (sequences of messages being exchanged) of multiple service applications. Orchestration refers to the central control of the behavior of a distributed system as opposed to choreography, which refers to a distributed system that operates without centralized control. 

There is (intentionally) no standard graphical notation for BPEL, and as a result, some vendors have invented their own notations. However, many people use BPMN (Business Process Modeling Notation) as a graphical front-end to capture BPEL process descriptions.

Modeling BPEL Processes with BPMN

BPMN diagrams show activities, gateways, messages, pools, and events

Figure 10 – BPMN diagrams show activities, gateways, messages, pools, and events

Figure 10 shows a BPMN diagram for our BPEL Car Rental Process.  The process begins with a Start Event: a Request is received from the Customer.  If the customer is of legal age to rent the vehicle, a (B2B) web service is used to check the Customer’s credit card.  If the card is valid, another web service is used to rent the vehicle, and a “Success” message is sent. If either the age or credit card checks fail, a “No” message is sent back to the customer.

 

Mapping BPMN to BPEL

Once we’ve defined our activities, gateways, and events on our BPMN diagram, we can specify additional BPEL details as attributes on our BPMN elements.  In Figure 11, we’re defining that the CheckCreditCard activity will be implemented as a web service, and will take a “request” message and generate a “result” response.

Mapping BPMN to BPEL for interfacing to the creditCardChecker web service 

Figure 11 – Mapping BPMN to BPEL for interfacing to the creditCardChecker web service

Generating BPEL Code

Finally, after we’ve specified our BPEL Process and validated the model, Enterprise Architect will generate the BPEL code to accomplish our business process.

We’ve successfully orchestrated our web services using BPEL 

Figure 12 – We’ve successfully orchestrated our web services using BPEL

Business Processes must satisfy Business Rules

Even in a service-oriented system, not all business processes can be implemented by orchestrating web services.  Some business processes will involve user interfaces, and some will be focused on enforcing business rules.  We won’t discuss GUI-based software use cases in this article, but we will spend a fair amount of time discussing some new ways to implement those processes that are focused on enforcing business rules.

In this section, we’ll introduce you to the unique capabilities of Enterprise Architect’s Business Rule Composer.  Starting from the domain model (fact model) and the requirements that we’ll presented earlier, we’ll take you through the process of creating Activity Diagrams for Business Processes, stereotyping Actions as RuleTasks, and finally, linking the business rules to the rule tasks in preparation for Behavioral Code Generation. 

Figure 13 shows our roadmap for business-rule-centric scenarios.

Developing “business-rule-centric” scenarios using EA’s Business Rule Composer 

Figure 13 – Roadmap: Developing “business-rule-centric” scenarios using EA’s Business Rule Composer

 

Behavioral Code Generation – a quantum leap in tools capability

One of the common themes of all of our ICONIX Process Roadmaps is that they all get you to code.  We’ve always believed that processes that only get you halfway to code (or less) are much better in theory than they are in practice (because in practice, programmers tend to ignore them).  Enterprise Architect, since it’s early days, has excelled at “code engineering” (forward and reverse engineering for a wide range of languages,  powered by customizable code generation templates).  But those already strong capabilities have recently taken a quantum leap in power with the introduction of behavioral code generation from activity diagrams, state diagrams and sequence diagrams.  Behavioral code generation is a major advancement over generation of “class headers” (which has been the de-facto meaning of “code generation” for more than a decade).

RuleFlow diagram for processing a car rental application 

Figure 14 – RuleFlow diagram for processing a car rental application

Let’s take a look at how we’re going to process an application for our Car Rental System.  The first thing we need to do is to create a RuleFlow diagram – in this case ProcessApplication (Figure 14).  We’ll create this diagram “inside” of a class in the Fact Model, just as if we were creating an Operation on that class, since that is, in effect, what we’re doing.  The RuleFlow diagram contains RuleTask actions.  Each RuleTask satisfies one or more business rules with some conditional logic.

Linking Business Rules to RuleTasks

What we’d now like to do, is to specify the conditional logic for each of these RuleTasks, while associating each piece of logic with the specific Business Rules that we’re enforcing.  As you might have guessed by now, that’s where the Business Rule Composer comes into play.  Once we’ve completely specified each RuleTask, we’d like Enterprise Architect to generate 100% complete code for the entire RuleFlow (Activity Diagram).  Using Behavioral Code Generation, that’s exactly what we’ll do. 

Figure 15 shows the Business Rule Composer for the “Eligibility” RuleTask.

Specifying conditional logic for Eligibility using the Business Rule Composer 

Figure 15 – Specifying conditional logic for Eligibility using the Business Rule Composer

There are 2 sections on the Rule Composer screen.  The top panel shows the Business Rules that we’re satisfying within this Eligiblity RuleTask;  the lower section (in this case a Decision Table) has 3 parts: a Condition section to model condition variables, an Action section to model action variables, and a Rule Bind section to link the rule in the rule table.

Generate Behavioral Code from Activity Diagrams

Code generation turns out to be very simple (and yields astonishing results) once all the preliminary work has been done.  Simply right-click on the Fact Model Class in the Project Browser and select “Generate Code”…and…Voila!  No programming required!

EA automatically generates complete behavioral logic for the entire rule flow 

Figure 16 – Enterprise Architect automatically generates complete behavioral logic for the entire rule flow

 

It’s worth examining the code shown in Figure 16 quite carefully.  Here are a few points worth noting:

  • The entire RuleFlow diagram is code generated as if it were a single class Operation on the FactModel Class
  • Each RuleTask is expanded in-turn
  • Within each RuleTask, the Business Rules are automatically propagated forward into the code as comments
  • Attribute and Operation names are taken directly from the Rule Composer
  • No manual programming intervention is required

 

It doesn’t take a whole lot of imagination to see that this capability can be a real “game-changer”.  Many organizations have thousands of business rules to implement, and “errors in translation” between Subject Matter Experts, Business Analysts, and Programmers are the norm, not the exception.  Many of those errors can be eliminated using Behavioral Code Generation and the Business Rule Composer.

 

Integration with IDEs – keeping model and code synchronized

Keeping models synchronized with code is accomplished with MDG Integration 

Figure 17 – Roadmap:  Keeping models synchronized with code is accomplished with MDG Integration

Since well before UML even existed, one of the biggest issues with modeling software has been keeping the model and the source code synchronized.   The typical experience used to be that UML models were most useful in getting the first release of software completed, but after the initial release, the code would evolve independently in a development environment, and the UML model would rapidly grow obsolete. 

With the evolution of agile methodologies, this situation often led to projects abandoning UML modeling entirely, as agile methods specify many frequent releases of the software, and getting to the first release became a smaller and smaller percentage of solving the overall problem.

You can beat this problem entirely by using Sparx MDG Integration for Visual Studio and for Eclipse, both of which are included in the EA Business and Software Engineering Edition.

Conclusion

Most SOA systems will contain a mix of 3 different kinds of scenarios:

1)     Scenarios that use web services

2)     Scenarios that enforce business rules

3)     User interface scenarios

Our SOA roadmap takes all these different types of scenarios into account.  We use WSDL, BPMN, and BPEL for web-service-centric scenarios, we use the Sparx Behavioral Code Generation and Business Rule Composer capabilities for business-rule-centric scenarios, and we use normal use cases where there are users and systems interacting.

We hope you find the roadmap useful in your development efforts.  For more information visit ICONIX on the web at www.iconixsw.com, or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .

 

 


[1]Realizing Business Value from an Integrated Service-Oriented Architecture System in a Multivendor World” – IBM Global Technology Services, April 2008

[2] These now include roadmaps for Embedded Systems, Testing (aka Design-Driven Testing), Algorithm Intensive Development, and Business Modeling, in addition to ICONIX Process for Software (the original “Use Case Driven ICONIX Process”).  See www.iconixsw.com for more details.

[3] See “Use Case Driven Object Modeling with UML – Theory and Practice” by Doug Rosenberg and Matt Stephens

[4] Wikipedia:  Web_Services_Description_Language

[5] We found Using BPMN to model a BPEL Process by Stephen A. White, IBM Corporation, to be a very useful article.

 

 

Doug Rosenberg, ICONIX

 

At ICONIX, we’ve had pretty good success when we defined an unambiguous development process, and presented that development process in “roadmap” form. We’ve developed process roadmapsfor use case driven software development, business modeling, design-driven testing, and algorithm-intensive software design. In this article we’re going to do it again, this time using SysML to describe embedded systems that involve a combination of hardware and software.

Figure 1 – ICONIX Process Roadmap for Embedded Systems Development

Figure 1 – ICONIX Process Roadmap for Embedded Systems Development

Figure 1 shows the top level roadmap for ICONIX Process for Embedded Systems.  As you can see, our roadmap starts off by defining requirements, proceeds through modeling of system behavior and block structure, and then through definition of constraints and parametrics, simulation, and then implementation in both hardware and software. We’ll illustrate our roadmap using an example model, developed by Sam Mancarella from Sparx Systems, that describes an Audio Player.

We’ll also introduce you to some unique capabilities of Enterprise Architect Systems Engineering edition, which supports advanced features such as executable code generation from UML models (including support for hardware description languages such as Verilog and VHDL), executable SysML Parametric diagrams and advanced scripting.

Each of these capabilities, taken standalone, adds a significant amount of “horsepower” to a systems engineering effort. We’ll combine these capabilities into a single process roadmap that’s greater than the sum of its parts.

The Four Pillars of SysML - Requirements, Structure, Behavior, and Parametrics

Our Embedded System Development Process Roadmap is built around producing a SysML model that is organized into four sections. These parts of the overall system model (Requirements, Structure, Behavior, and Parametrics) are sometimes referred to as “The Four Pillars of SysML”.[1] As with UML, Packages are used to organize the model.

SysML Pillar #1: Requirements

Requirements are generally categorized as Functional Requirements, which represent capabilities of a system, and Non-Functional Requirements, which cover such areas as Performance and Reliability. You can organize Requirements into hierarchies on requirement diagrams (see Figure 2).

EA supports allocation of requirements to other elements using a simple drag-and-drop, and automatic generation of traceability matrices.

Figure 2 – Requirements for the Audio Player include Performance, Durability and

Figure 2 – Requirements for the Audio Player include Performance, Durability and User Friendliness

 

Figure 3 shows the steps for Requirements definition from our process roadmap. Note that allocation of Requirements to System Elements is really an ongoing process as the model is developed, and largely occurs within other roadmap activities.

Figure 3 – Roadmap: Define System Requirements

Figure 3 – Roadmap: Define System Requirements

SysML Pillar #2: Structure

Blocks can be used to represent hardware, software, or just about anything else. Block definition diagrams represent system structure. Internal block diagrams describe the internals of a block such as parts, ports, and connectors.

Figure 4 – Block Structure for the Audio Player

Figure 4 – Block Structure for the Audio Player

 

Figure 5 shows how our process roadmap approaches defining system structure.

Figure 5 – Roadmap: Model System Structure

Figure 5 – Roadmap: Model System Structure

If you think of a Block as an electronic circuit (one of many things that a Block can describe), the Ports define the input/output signals to and from the circuit. SysML allows you to describe the I/O signals and transformations in great detail, and EA contains a built-in simulator that allows you to plot the output graphically.


SysML Pillar #3: Behavior

SysML provides four main constructs to represent different aspects of system behavior; use cases, activity diagrams, sequence diagrams, and state machines. As shown in Figure 6, our roadmap shows two parallel branches for modeling system behavior.

Figure 6 – Roadmap: Model System Behavior

Figure 6 – Roadmap: Model System Behavior

One branch starts with use cases[2], which describe scenarios of how users will interact with the system. Use cases generally consist of a “sunny-day” part, which describes a typical success-path for the scenario, and multiple “rainy-day” parts which describe unusual conditions, exceptions, failures, etc. Figure 7 shows a Use Case Diagram which organizes the scenarios in listening to the Audio Player.

Figure 7 – Audio Player Use Cases

Figure 7 – Audio Player Use Cases

Use cases are typically detailed on Interaction (Sequence) Diagrams, which can also be drawn at a higher level.  Figure 8 shows Interactions between the Listener and the Audio Player.  Note the use of parallel paths on the Interaction Diagram.

Figure 8 – Audio Player Interactions, showing interactions occurring in parallel

Figure 8 – Audio Player Interactions, showing interactions occurring in parallel

 

The other branch on the roadmap involves defining event-driven, finite-state behavior of some part of a system using state machines. As a simple example, Figure 9 shows some finite state behavior associated with Playlist Maintenance for our Audio Player.

Figure 9 – Finite State Behavior for Playlist Maintenance

Figure 9 – Finite State Behavior for Playlist Maintenance

One of EA’s unique capabilities is the ability to generate functional (algorithmic) code from state machines. As you’ll see, these state machines can be realized in software or in hardware using Hardware Description Languages (HDLs).

Requirements are allocated to both use cases and states.

 

 

SysML Pillar #4: Parametrics

Parametrics allow us to define detailed characteristics, physical laws, and constraints on system blocks that allow us to simulate how a system will behave, then make engineering tradeoffs, and re-simulate until our design meets the specified requirements.

Figure 10 – Roadmap: Define Constraints and Parametrics

Figure 10 – Roadmap: Define Constraints and Parametrics

Our roadmap provides two high-level activities in this area; the first to define constraint blocks and parametric diagrams (shown in Figure 10 and illustrated in Figures 11 and 12), and the second to configure and execute the simulations (shown in Figure 13).

Figure 11 – Constraint Blocks for the Audio Player’s “Echo” signal processing fu

Figure 11 – Constraint Blocks for the Audio Player’s “Echo” signal processing function

 

Figure 12 – Parametric model for the Audio Player’s “Echo” signal processing fun

Figure 12 – Parametric model for the Audio Player’s “Echo” signal processing function


Simulation

The ability to configure and execute simulations within EA, eliminating the need to export the model to external simulation software, is one of the unique capabilities of the Sparx SysML solution.

Figure 13 – Roadmap: Simulate

Figure 13 – Roadmap: Simulate

EA’s built-in support for scripting and graphical display of simulation results tightens the feedback loop on making engineering tradeoffs in the model to rapidly ensure that all system requirements are met.

Figure 14 – Results of simulating the “Echo” function are displayed within Enter

Figure 14 – Results of simulating the “Echo” function are displayed within Enterprise Architect and do not require the use of external simulation software.

Implement Hardware

Hardware Description Languages allow the specification of electronic circuits in a software-like representation. According to Wikipedia[3]:

In electronics, a hardware description language or HDL is any language from a class of computer languages and/or programming languages for formal description of electronic circuits, and more specifically, digital logic. It can describe the circuit's operation, its design and organization, and tests to verify its operation by means of simulation.

 

Figure 15 – Roadmap: Implement Hardware

EA’s long-proven ability to generate code has been extended to support code generation in VHDL, Verilog, and System C in the Systems Engineering Edition. While code generation is independent of SysML usage, from a process roadmap standpoint, this means we can drive both hardware and software implementation from our SysML model. Once code is generated in an HDL, it’s possible to “compile to silicon” to realize the hardware solution on a chip.  This process is shown in Figures 16 and 17, which show how a playback controller can be generated in VHDL.

Figure 16 – SysML model of hardware component for controlling audio playback

Figure 16 – SysML model of hardware component for controlling audio playback

 

Figure 17 – Audio playback controller, generated in VHDL

Figure 17 – Audio playback controller, generated in VHDL

Implement Software

Software implementations can leverage a variety of powerful capabilities that are included with the System Engineering Edition of EA. Two of the more important and unique capabilities are:

  • The ability to generate functional (algorithmic) code from behavioral models (state machines, activity diagrams,  and interaction diagrams)
  • The ability to integrate EA models into development environments such as Eclipse and Visual Studio.

Figure 18 shows a high-level look at the Software Implementation activity from the roadmap.

 

Figure 18 – Roadmap: Implement Software

Figure 18 – Roadmap: Implement Software

Conclusion

This article has presented a high-level overview of ICONIX Process for Embedded Systems, which leverages Enterprise Architect System Engineering Edition to build hardware/software models that are structured around the “four pillars of SysML”.  We’ve illustrated our process roadmap with diagrams from Sam Mancarella’s Audio Player Example.

This topic will soon be expanded into an “eBook”: Embedded Systems Development using SysML and Enterprise Architect.

For more information, visit ICONIX on the web at www.iconixsw.com, or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.

 

 

 


[1] OMG Systems Modeling Language Tutorial, INCOSE 2008

[2] See Use Case Driven Object Modeling with UML: Theory and Practice by Doug Rosenberg and Matt Stephens for a lot more information about use cases.

[3] http://en.wikipedia.org/wiki/Hardware_description_languages

(Article originally published in SDJournal)

This article presents an easy step-by-step formula that will get from code to a comprehensive test plan, that includes a complete set of unit test code, using the free Agile/ICONIX add-in for EA.  

Here are the 6 steps that we’ll follow:

1)Reverse engineer some code

2)Generate tests from Class Operations

3)Add test scenarios in EA’s testing view

4)Transform the test cases to test classes

5)Generate the unit test code from the test classes

6)Generate a test plan report

We’ll illustrate this approach one step at a time in this article, using some reverse engineered ActionScript (Flex) code from the example project we built while writing  Design Driven Testing.  

 

This article gives an overview of how to use Enterprise Architect's new Structured Scenario capability to generate acceptance tests by expanding "use case threads". If you consider a use case with one “sunny day” scenario and four “rainy day” scenarios, you can expand that use case into at least five “threads”, each of which defines a potential acceptance test for some part of your system...

 


ICONIX is pleased to announce the availability of a beta version of the latest Agile/ICONIX Add-in.

The beta installer can be downloaded from http://www.sparxsystems.com/bin/Iconix_AgileDev2.0.exe.

 

There are 3 notable new capabilities of the new add-in:

1) Support for "DDT/Systems" - Design Driven Testing for SysML models, including automatic generation of interface tests from SysML IBDs, and automatic generation of state machine testing, including Trigger/Do/Entry/Exit behaviors.

2) "More agile" automatic test case generation from class operations.  Agilists will like this one, because it's now possible to reverse engineer your as-built code, and autogenerate a complete set of JUnit test stubs.

3) Inclusion of the "ICONIX Technology" which includes process roadmaps and project templates for use case driven projects using UML, embedded systems projects using SysML, Business Process Modeling using Structured Scenarios, and Service-Oriented Architecture projects.

Betatesters of the new add-in are invited to send us feedback at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

 

I’ve never believed in teaching tools, notation, or modeling in the absence of a process. The reason this book has so many process roadmaps is that there are lots of different kinds of software and systems being developed. 

Which roadmap fits the problem you are trying to solve? The following guidance might be helpful:

For embedded system development follow ICONIX Process for Embedded Systems(SysML)

For SOA and web service development follow ICONIX Process for Service Oriented Architectures

For business process modeling follow the ICONIX Business Modeling Roadmap

For algorithm intensive develoment follow ICONIX Process for Algorithms

For normal GUI-based software follow ICONIX Process for Software (use case driven object modeling)

 


 

This book documents several roadmaps and illustrates their use by example. I hope you find them helpful.

Doug Rosenberg

ICONIX's upcoming Open Enrollment Class in Washington DC has had a date change. New dates are May 16-20, 2011.  


 

 

Course agenda follows.

Monday:  Business Process Modeling with Structured Scenarios

Students will use Enterprise Architect's "structured scenario editor" to model business processes for a bookstore warehouse, following the "ICONIX Business Modeling Roadmap" as defined in the article "Business Process Modeling with Structured Scenarios"

Tuesday: Getting from Use Cases to Code with ICONIX Process

Students will use Enterprise Architect to model an interactive hotel mapping system, starting from the ICONIX Project Template model, and following "ICONIX Process for Software" roadmap as described in "Use Case Driven Object Modeling, Theory and Practice".  Exercise will include a Domain Model, Requirement Model, User Interface Storyboards, Use Cases, Robustness Diagrams, Sequence Diagrams, and Class Diagrams.

Wednesday: Design Driven Testing

Students will use Enterprise Architect to generate test cases, test code, and test plans for the interactive hotel mapping system, as described in the book "Design Driven Testing".  Exercise will include Unit Tests, Controller Tests, Scenario Tests, and Requirement Tests and will use the Agile/ICONIX Add-In (for unit, controller, and requirement tests) and the Structured Scenario Editor (for scenario tests).

Thursday: Modeling Service Oriented Architectures.

Students will use Enterprise Architect Business and Software Engineering Edition to model a service-oriented Car Rental System, using the ICONIX SOA Project Template, and following the "ICONIX Process for Service Oriented Architecture" roadmap as described in the book "ICONIX Process Roadmaps".  Exercise will include BPMN and WSDL modeling, BPEL code generation, and Behavioral Code Generation from Business Rules.

Friday: Embedded Systems Modeling with SysML

Students will use Enterprise Architect Systems Engineering Edition to model a 2-way wristwatch TV in SysML, using the ICONIX SysML Project Template, and following "ICONIX Process for Embedded Systems" roadmap as described in the book "ICONIX Process Roadmaps".  Exercise will include: Block Definition Diagrams, Internal Block Diagrams, State Machines, Use Cases, Interaction Diagrams, and Constraint/Parametric Diagrams.

Registration information on the ICONIX website at http://www.iconixsw.com/EA/PublicClasses_WDC.html

Or contact This email address is being protected from spambots. You need JavaScript enabled to view it. for further details.

 

Because different people use Enterprise Architect to do different things, ICONIX has developed a series of "process roadmaps" to guide you through a variety of development problems.  In addition to use case driven object modeling, we've developed roadmaps for modeling Service Oriented Architectures, Modeling Embedded Systems using SysML, Business Process Modeling, and Design Driven Testing.  

Now we're delivering a 5 day series of "training modules" called Hands On ICONIX Process where you can go hands-on and work through whichever processes you need for your projects.  I'll be teaching these workshops personally, and if there's enough demand, I might be accompanied by my co-author Matt Stephens.

 

Agenda

Monday: Business Modeling using Structured Scenarios

Students will use Enterprise Architect's "structured scenario editor" to model business processes for a bookstore warehouse, following the roadmap defined in the article Business Process Modeling with Structured Scenarios

Tuesday: ICONIX Process: Getting from Use Cases to Code

Students will use Enterprise Architect to model an interactive hotel mapping system following ICONIX Process as described in Use Case Driven Object Modeling, Theory and Practice.  

Wednesday: Design Driven Testing

Students will use Enterprise Architect to generate test cases, test code, and test plans for the interactive hotel mapping system, as described in the book Design Driven Testing.  

Thursday: Modeling Service Oriented Architectures (SOA):

Students will use Enterprise Architect Business and Software Engineering Edition to model a service-oriented Car Rental System, following roadmap as described in the eBook Modeling Service Oriented Architectures.

Friday: Embedded Systems Modeling using SysML

Students will use Enterprise Architect Systems Engineering Edition to model a 2-way wristwatch TV in SysML, following the roadmap described in the eBook Embedded Systems Development using SysML

Pricing:

Students may enroll for whichever days they choose at the following price schedule (price includes books):

1 day: $995
2 days: $795/day
3-5 days: $595/day

More details are available on the ICONIX website here.

 

The groundbreaking book Design Driven Testing brings sanity back to the software development process by flipping around the concept of Test Driven Development (TDD)—restoring the concept of using testing to verify a design instead of pretending that unit tests are a replacement for design. Anyone who feels that TDD is “Too Damn Difficult” will appreciate this book. Design Driven Testing shows that, by combining a forward-thinking development process with cutting-edge automation, testing can be a finely targeted, business-driven, rewarding effort. In other words, you’ll learn how to test smarter, not harder.

  • Applies a feedback-driven approach to each stage of the project lifecycle.
  • Illustrates a lightweight and effective approach using a core subset of UML.
  • Explains how to use Enterprise Architect to generate automatically acceptance test cases from structured scenarios
  • Explains how to use Enterprise Architect and the Agile/ICONIX add-in to generate JUnit and FlexUnit test code
  • Follows a real-life example project using Java and Flex/ActionScript.
  • Presents bonus chapters for advanced DDTers covering unit-test antipatterns (and their opposite, “test-conscious” design patterns), and showing how to create your own test transformation templates in Enterprise Architect.

What you’ll learn

  • Create unit and behavioral tests using JUnit, NUnit, FlexUnit.
  • Generate acceptance tests for all usage paths through use case thread expansion.
  • Generate requirement tests for functional requirements.
  • Run complex acceptance tests across the enterprise.
  • Isolate individual control points for self-contained unit/behavioral tests.
  • Apply Behavior Driven Development frameworks like JBehave and NBehave

Design Driven Testing should appeal to developers, project managers, testers, business analysts, architects…in fact anyone who builds software that needs to be tested. While equally applicable on both large and small projects, Design Driven Testing is especially helpful to those developers who need to verify their software against formal requirements. Such developers will benefit greatly from the rational and disciplined approach espoused by the authors.

 

Design Driven Testing

Page 3 of 4