Astah Professional offers several features that will make it easier for you to model using C#.

Pre-installed Template File

Astah Professional has a template file which includes predefined models that would be helpful for modeling with C#. To open it, select [File] – [New By Template] – [b. C_Sharp.asta]

Setting Programming Language

You can select C# as a programming language you model with Astah.

1. Select a root package in the tree view
2. Go to the bottom pane and select [Project Setting] and check [C#]
   
3. This enables you to set C# specific attributes to models (Classes, Attributes and Operations) from [Language Tab]
   
    

    

   Reverse Engineering and source code generation

   By installing this plug-in, you can reverse C# source code into Astah diagrams and also you can generate your models into C# source code from [Export C#] menu.

“A small icon to make your diagrams more expressive”

Did you know that you can add mini icons to UML models and Mind Map topics in Astah?
You can use these mini icons when you want to make a remark to yourself or when you want to add “extra” meaning to specific models when you represent diagrams to someone!

How to add icons to models

To add mini-icons, select a model/Mind Map topic and then click an mini icon shown on top main menu (the top right one), then choose any you want to add to the models!

”

How to add new icons

You can also add new icons to the list.
(1) Open any Mind Map and select a topic (can be any topic)
(2) Click Mini-Icon on main menu to and click [Show Mini Icon List] button at the bottom of the dialog

(3) Another dialog opens, click [Edit User Icon]

(4) Another dialog opens, click [Add] and choose an image file you want to add to this list

In Astah, you can adjust lengths of lifelines and ExecutionSpecifications in UML Sequence diagram easily. You no longer adjust those lengths one by one. You can adjust them all once before you export diagrams to image files or print them out!

  Adjusting ExecutionSpecification length

Right-click on diagram and select [Adjust ExecutionSpecification Length].

All the ExecutionSpecifications will be shown as shortest as possible.

This menu exists on context menu of each execution specification if you want to adjust the size of specific ones by choosing them.

  Adjust Lifeline’s length

To adjust Lifeline’s length, right-click on diagram again and open its context menu.

You can choose how to adjust them from three options below:

1. Default — All lifelines will be shortened as shortest possible
2. Align to Minimum — All lifelines will be same length as the shortest one
3. Align to Maximum— All lifelines will be same length as the longest one

This is the figure after choosing [Default].

Try these options to make it easier to clean out your UML Sequence Diagrams!
 
 
 

Team building, better communication, and faster quality changes are some of the most basic tenets of DevOps. Finding a way to combine all three aspects is a challenge many organizations face. While there is no ‘one-size fits all’ solution a good place to start might be an Application Model.

Our teammate just posted an interesting article on devops.com talking about how an Application Model represents the application as it exists in the real world, with all its benefits and flaws. He further goes on to show how the model can be a great place to start when considering changes to an established application. Even more so if the team is interested or working towards a better DevOps environment.

You can learn more about Application Models and read the entire article at DevOps.com.

 Existing code generators assume that we are professionals – but we wanted one for educational purpose.

Join Friends of Astah!

We welcomed two new members,  Brian Cham and Candice Eckert to
Friends of Astah Program.

They are developers of “LORINI” Plug-in which is an add-on for Astah to convert UML diagrams to executable code for students to learn modeling and object-oriented programming.

Today I interviewed Brian to learn their story and motivation behind the development of this tool.

[SJ] Thanks for your time Brian. I was delighted when I received your email introducing LORINI.OK, let us start!

Q: How did this project begin?

Candice and I were students at the University of Auckland. For the final year, student pairs complete a “Part IV Project” to develop research experiences and apply all the skills we have learned in our studies.
Our project brief was to develop new software which converted modelling diagrams to executable code. It was open-ended and our supervisor Professor Jing Sun left it up to us to decide any details beyond the description.

At the beginning, we researched automatic code generation, and that’s when the idea for Lorini was born. Looking through existing tools, there was a very obvious flaw that they all assumed the user was already a programming professional. They would just take in a model, spit out some code text, and that was that.
We decided to make a tool that assumed the user was only a learner, and that converted models to code for the purposes of education.

Published paper

Lorini isn’t the first tool to convert UML to Java, but it is the first to display the model and code simultaneously and graphically depict the relationship between them for the purposes of learning.

Q: Why did you choose Astah?

We chose Astah because it fulfilled all of our requirements perfectly. To realise our idea, we needed a UML modelling application that was free, popular, cross-platform, easy to use and extensible. After trying out many applications, only Astah featured all of these. It had a well-documented API in the Java language, making it easy to develop a plug-in for. Also, its intuitive GUI meant that learners could easily interact with the UML diagrams, and it gave us a lot of freedom to display what we wanted to show the user.

Q: Great to hear. Experienced difficulties during the development?

Yes, it was a challenging process!
The idea of converting to UML to Java code is definitely easier said than done. The biggest difficulty was converting activity diagrams to method code.

LORINI plugin converts Activity diagrams to source code

If the user made individual actions in a sequence, that’d be simple to convert to lines of code. However, there are if-branches and while-loops which can be nested inside each other. This really complicates the structure of the flowchart. It took us a long time to develop an algorithm that could traverse through the entire activity diagram and accurately sort out how all the branches, loops and statements were arranged, without ending up in an infinite loop.

Q: How long did it take to complete?

Started in March and concluded in October. Sounds a long time, but we had to complete it alongside our other papers, so we were actually quite constrained. In total I would say that it took a few hundred hours, including the other requirements like research, planning, user testing, reports, poster and exhibition. It was a lot of work!

Q: Wow – What was the motivation made you guys going?

The motivation behind this tool was to give programming students a better introduction to modelling and object-oriented programming. Students are trained with functional programming and then moved on to object-oriented programming and then UML, which are big leaps. It is challenging to grasp how they relate to each other and what the purpose is. Some educators have successfully tried an alternative approach where beginner students are introduced to UML and object-oriented programming simultaneously, and there is a strong emphasis on how the code and model are actually just two different manifestations of the same software design. By showing the equivalence between any part of code and the diagram, Lorini is intended to ease the transition from object-oriented programming to modelling, or from modelling to object-oriented programming.

Q: How do you wish LORINI to grow?

We hope that Lorini will lead to a better understanding of UML and therefore to a wider use thereof!

[SJ] Sure will! We give a free license of Astah Professional to students and very reasonable license “Faculty Site License” to schools, so Astah students (students who use Astah) are increasing all over the world. I am sure LORINI will help them with their studies!

Get Astah Professional Free License for Students

Astah Faculty Site License

LORINI Plug-in

Have you had an experience that you had deleted an association line from diagram but when you look into the [Association] tab of models, it’s still there.

The reason is simple, you just deleted its presentation from the diagram, not completely from the project.

In Astah there are two ways to delete models. Let me show you the difference. Let’s say you have two classes with an association between the two.

 Removing its presentation

If you select [Delete from Diagram] from the association’s pop-up menu or hit [Delete] key, an association line will be deleted from the diagram.

But when you go to “Monitor” class’s property view, the association information still exists.

So this menu only deletes the presentation from diagram but the model itself still exists. Sometimes you may represent same model in several diagrams and hide its visibility from one depending on the purpose of the diagram. In that case choose [Delete from Diagram].

 Removing ompletely from project

Selecting [Diagram from Model] from its pop-up menu or hit [Ctrl/Command + D] key will delete the association presentation from diagram and also from the project. So choose this way when you are sure that you want to delete this model completely from the diagram such as when you made a mistake creating this association..etc.

If you want to check our Astah’s shortcut key list, check out the page here.

Cheers,
Satomi

We will be running our maintenance on Change Vision Members site on October 14(Fri) 6am – 16th(Sun) 8pm EDT. (Oct.14 12pm – Oct.17 2am CEST)

Change Vision Members Site

During this time period, you aren’t able to:
– sign up with Change Vision Members service
– register purchased licenses including license renewal
– use product support form
– extend trial licenses
– issue license files
– download older version of Astah (Download of the latest version is available on Astah.net)

We apologize for the inconvenience.

If you are planning to purchase Astah around this time from our online store, make a purchase ahead of time.

Thank you very much for your understanding.

Astah Team

We will be closing our office on October 28th(Friday) due to our internal annual event.

We are unable to provide technical support on the day but bug reports and any feedback submissions are available and will be responded on the following business day.

Send us your bug report/feedback.

Thank you very much for your understanding.

Astah Development Team

 “Mini Icons” make your diagrams communicative!

When you want to add information to a model, you would add text or notes or change its color. In Astah “Mini-icon” is another option. You can a smily faces, check marks, stars or your favorite icons to impart the information visually!

 How to add a mini-icon to a model:

1. Select a model you want to add a mini-icon
2. Click top right icon on Main Menu – if you click the arrow beside it, a list of mini-icons appears.

3. A mini-icon is added at the top-right corner of the model element

How to add customize icon

1. Click [Show Mini Icon List] at the bottom of mini-icon list.

2. A mini icon list appears in a separate dialogue. Click [Edit User Icon] at the bottom

3. A dialogue appears. Click [Add] button and choose an image file you want

4. You can add a name (optional)

5. Added icons are now added in the list under [User Icon]

Some of Astah users draw Fault Tree diagrams using Mindmap with these mini icons. (It will expand horizontally, but it works!

Mini-icons are available in Astah Professional, SysML and GSN. Give it a try!

Astah received both “Bestselling Product Awards for 2016” and “Bestselling Publisher Awards for 2016” today from the ComponentSource, a worldwide software reseller – who’s reselling Astah for us almost for a decade.

Astah is born in Japan, still all been developed in Japan but Astah’s user base has been crossing the border and growing rapidly outside of Japan. This could never happen without the ComponentSource. They not only provide the smooth e-commerce experiences, but also excellent care to our customers which have made it easier for our customers to decide to use Astah.

This is what we recently started – putting yellow stickers on the country where license is sold – and a photo of Astah fans we often talk on the blue paper around the world map!

This award-winning announcement made us very happy today and we thank the ComponentSource for their professional service, customer care and collaboration with us in all these years and also we thank you – users all around the world who have chosen Astah and purchased through the ComponentSource!
You all have made us very happy and we will show our appreciation by making Astah a better tool every day to make your life easier and more productive!

A little history about how we met the ComponentSource 10 years ago…

All the best,
Astah Team

This is a repost of Astah.net’s CEO Kenji Hiranabe’s article on InfoQ from 2013 with updated diagram images.

Modeling in the Agile Age
– What to Keep Next to Code to Scale Agile Teams

– Kenji Hiranabe

Now that Agile methods have become mainstream in software development, working code and automated tests are being considered as the most important team artifacts.
Is modeling obsolete? Is UML dead?
I don’t think so. In this article, I’ll explore the spaces where modelings fits and plays an important role in this Agile age, especially when development scales to multiple teams and a shared understanding of the system’s “Big Picture” becomes essential.

　Where is “Design” in Agile

“While code is the truth, it is not the whole truth.” -Grady Booch

To begin with, let’s describe a minimal process of an Agile team using Scrum. The figure.1 shows an intentionally simplified process with the only essential artifacts left explicit.

1. The “User Requirements” are listed as a “Product Backlog”.
2. The development team picks items from the list and implements them within a short iteration (or “Sprint”).
3. After each Sprint, the team produces “Working Software” (or “Increments”) as “Product Code” and “Test Code”.

Figure1. Simple Scrum Framework

In this minimum framework, the input to the team is “User Requirements” as “Product Backlog” and the output is “Working Software” as code (“Product Code” and “Test Code”). No other design artifacts between them are explicitly described here. All the design intentions generated during the Sprint will hopefully have been deployed into the working codebase as assets of the team, but there will be information which cannot be expressed directly as code. Scrum is a process-framework and intention- ally mentions nothing about design, but we still have design and design activities in our team.

As Grady Booch says, “The code is the truth, but it is not the whole truth.” So if there is information which cannot be expressed or communicated by the code, where can we keep these information assets? That is the question this article attempts to answer.

　Documentation is not Agile?

“Model to have a conversation.” – Craig Larman and Bas Vodde

“In our minds!” would be one answer to the previous question. Daily meetings, pair programming, design workshops, and other social practices act as synchronization and continuous integration of the minds of the team members. But when the team gets bigger, geographically distributed, and people leave the team, “models in minds” will quickly evaporate. We need to maintain the shared understanding of the system somewhere as documentation to share information which is not well communicated and retained only by the code.

One point that Agile makes clear is the value shift from documentation to conversation, so writing heavy design documentation (which often duplicates information from the code) is not the right approach. Documentation that makes conversations effective is the approach that we should take, and it should be the simplest possible set of models which works complementary to the code.

One aspect where models have an advantage over code is visual expression. In other words, text is a poor medium of communication in a certain context. The image below shows how textual communication can fail miserably. (thanks to Jeff Patton for introducing the book to me!)

I guess this “wreck” was likely caused by a message left on the answering machine of the cake shop. If the caller had used a simple picture with text, he or she could have easily avoided the wreck. Sometimes, “a picture is worth 1,000 words.”

So what models can be effectively used, and for what purpose in Agile teams?

 Agile Modeling and Two Categories of Models

“Let’s keep the modeling baby but throw out the bureaucracy bathwater.”
– Scott Ambler

“Agile Modeling” is a set of practices you can use within your Agile teams for effective modeling and documentation. This method aligns with Agile values and principles and still helps you bene t from the power of model- ing. The emphasis is on models for conversation, not for handovers.

We have been using the practices and principles in Agile Modeling with our software development team and found that the most important role of models is to visually communicate the “Big Picture” or the “Bird’s-eye View” of the system design, which is difficult to accomplish via code alone. Without models, the team would be “four blind men touching the elephant”. Each man feels only the part he is touching, and it takes a long time to unify the parts into a meaningful whole – the elephant.

My recommendation of the “Big Picture” models to keep maintained consists of:

1. “Architecture” of the system for the team to get a rough idea of the whole system structure.
2. “Domain Model” to help the team under- stand the concepts used in the problem domain.
3. “Key Use Cases” to help the team under- stand the concepts used in the problem domain.

These are all essential to establish understanding of the system as a whole. Without models, how would you accomplish this understanding? If you have a large codebase, and make a “Big Picture” assumption based on a small incomplete view of it, you will make some poor choices on how to maintain that codebase. The “Big Picture” not only comprises the team’s mental model of the system but also supports the vocabulary they use in the conversation and in the code that they program, i.e. the structures of the code as well as detailed naming of the programming constructs such as classes, methods, variables, fields, data, and configuration. In other words, these models are not only important for the team to establish a shared understanding of the system as a whole, but also for the team to keep the codebase consistent and maintainable.

On the other hand, there are also temporary models which will be thrown away once the information is programmed into the code. Casual class diagrams with few classes and sequence diagrams describing the interaction of them (usually drawn on whiteboards) fall into this categories. Those models are also important to encourage conversation and to burn the information to the codebase before the models are thrown away.

So the core of the idea is to categorize the models into two types — models to keep and maintain as assets and models to draw temporarily to have effective conversation. We call the former “keep models” or “Keeps”, and the latter ”temp models” or “Temps,” as described by the illustration below. Please note that the “Keeps” are not meant to be “frozen”, but are meant to be maintained and changed over time. In the next section, I’ll propose three “Keeps” for Agile teams.

Figure.2 Agile Modeling with “Keeps” and “Temps”

---

　Models to Keep

Depending on the context (the number of people, criticality of the system, stability of requirements, whether it is an enterprise system or embedded), the “Keeps” models will vary. Based upon my experience, here are some good candidates of them:

1. Architecture As Class/Package Diagrams
2. Domain Model As Class Diagram/ER
3. Key Use Cases As Use Case Diagrams + Sequence/Communication Diagrams

We mainly use UML, but you don’t have to stick to strict UML specification. We use it because it includes sufficient standardized diagrams and there are many published educational materials. ERD (Entity-Relation Diagram) and DFD (Data Flow Diagram) for data and processes are also used sometimes for the same reasons.

Figure 3 illustrates the roles of the three “Keeps” models as a picture. In a nutshell, “Architecture” shows the structure, “Domain Model” shows the core concepts of the problem space, and “Key Use Cases” shows examples of the usage of the system.

Figure.3 Architecture, Domain Model and Key Use Cases

I’ll explain the three one by one with concrete examples and pictures from one of my teams.

1. Architectures As Class/Package Diagrams

The architecture is a structural presentation of the whole system. It is often described by class or package diagrams typically to show global tiers (layers). For example, in an application with UI and database, tiers are usually set horizontally from UI to database, and one Use Case walks through them to accomplish its goal.

Other architecture patterns like “MVC” (Model- View-Controller) can also be chosen as a global architecture. Figure.4 is an example of an architecture drawn as a package diagram based on MVC architecture.

Everyone in the team should understand the roles and meanings of the components of the architecture so that team members can write code which fits in the right place in the architecture consistently.

“Dependencies” are often expressed in this diagram between packages to avoid unwanted couplings or circular dependencies. From an architectural view point, inter-package circular dependencies are the evilest problem, and result in harder testing and a longer build time.

Figure.4 Architecture as Class/Package Diagram (Example)

2. Domain Models As Class Diagrams or ER/Diagrams

A Domain Model describes the concept taxonomy of the problem space in which the application works. In the human communication level, the vocabulary of this domain model is to become the “Ubiquitous Language”used in the whole stakeholder community including the users, domain experts, business analysts, testers and developers.

In the programming level, the Domain Model is also essential for selecting names of programming constructs such as classes, data, methods, and other conventions. A large part of the concept taxonomy (often called “entities”) is mapped into a persistent data structure in the database and often has a longer life than the application itself. Typically, the domain model (or entities) re- sides in the “M” package in the logical architecture if you choose an “MVC” architecture for your application. In a RubyOnRails type of applications, an ER diagram is more suitable for expressing an domain model because it is tied more directly to relational databases.

Also note that this domain model grows over time. Because domain is at the heart of understanding and communication of the problem, maintaining the growing domain models in the team (or broader, in the community) is one big topic that is fully discussed in Eric Evans’s DDD (Domain-Driven Devel- opment).

Figure.5 is an example of a Domain Model expressed as a class diagram which presents the domain in one picture.

Figure. 5 Domain Model as Class Diagram (Example)

---

3. Key Use Cases as Use Case Diagrams and Sequence/Communication Diagrams

Key Use Cases are typical usages of the system, from the user’s viewpoint. There are two reasons why we include them in the “Keeps”. The first is that developers often go into the solution and forget who the users of the system are and what they want to accomplish with the system. Use Cases help them recall the users’ viewpoints and are a good way to have conversations with users, as other documents are usually difficult for users to understand.

The other reason is that Key Use Cases, and their mechanics described as sequence or communication diagrams, work as educational examples for developers. They describe how several objects in the system in different tiers in the architecture work together to accomplish the user goal. Draw a concrete example of a vertical slice from UI to database and illustrate how you implement the Use Case in the architecture.

The Key Use Cases don’t have to be complete or cover all situations. Just pick the typical ones and keep them simple.

Figure.6 is an example Use Case diagram which shows the typical users and usage of the system.

 

Figure. 6 Key Use Cases as Use Case diagram (Example)

It doesn’t need to be comprehensive, but should capture the context of the system. The yellow Use Case (“Create Class Diagram”) is chosen as an example Use Case, and the design breakdown is diagrammed as a communication diagram below – Figure.7.

Figure. 7 Key Use Case Mechanics as Communication Diagram (Example)

With this example, the team can share an understanding of how the Architecture and Domain Model (diagrammed in Figure 4 and Figure 5) actually work to accomplish the features described as Key Use Cases. See Figure.3 again, for the relationship of Architecture, Domain Model and Key Use Cases.

You can use tools to draw these diagrams to make maintenance easier, and to print them on a large piece of paper to have posted on the wall. The wall will then become a discussion place of modeling workshops (as I will soon discuss in a later section).

 

　Scaling

“Rather than divide and conquer, an XP team conquers and divides.”
– Kent Beck

With a small team of less than 10 developers, you may not have to maintain any models next to the codebase. As the development scales to multiple teams, you will need to get more benefits from modeling.

But remember, don’t invest too much time to prepare heavy documentation (with ZERO implementation) just to hand it over to someone you don’t know.

Even when the team gets bigger, you need to try to create a thin vertical slice of your implementation to accomplish the Key Use Cases first to make an architecture seed, and then share the knowledge with sub teams using the working code and “Keeps” models. In other words, don’t try to “divide and conquer” by dividing the problem on the desk and throwing the specification over the wall to make sub-teams conquer. Instead, “Conquer THEN divide” (More on this in large-scale agile design & architecture by Craig Larman and Bas Vodde).

Here, I describe how multiple teams communicate the “Big Picture” using the “Keeps.” The first “conquer” should be tried by less than 10 people in one team called the “Tiger Team” at one location. After the first conquer, all the “Keeps” described above can be used as good documentation to communicate the understanding of the system. In Sprint 1, the Tiger Team conquers the Key Use Cases first to establish the first “seed” architecture and makes version 1.0 of the “Keeps” as SAD (Software Architecture Document).

Think of these models not as a specification, but as common ground to create understand- ing. And again, do not just hand the document over to the sub teams.

Figure. 8 Tiger team and Sub Teams

The best way to communicate design intention and create shared understanding is to facilitate a Modeling Workshop with the sub teams as displayed in Figure 8.

In the modeling Workshops, one member of the Tiger Team (Ken, in Figure 8) first explains the SAD and walks through the models. With casual Q & A’s, he communicates the core ideas and the structure of the system. He can use the Key Use Cases to explain how the system components works together to accomplish a user goal. And he jointly designs one or two of their Use Cases with them, using “Temps” mod-els and maybe pair-programming.

Don’t try to make the SAD complete. Use workshops as a way to establish a common understanding by having a rich conversation and without handovers.

An important part of the sub-team workshop is feedback. In Figure 8, Ken in Sub Team 1 and Tom in Sub Team 2 bring the feedback to the Tiger Team and discuss with the other members how to make the “Keeps” models better. Figure.9 is a printed diagram with notes during the workshop. It includes notes for understanding and also notes for feedback.

Figure. 9 Architectures with comments after Workshop

Hold workshops repeatedly. Grow understanding by “modeling,” not by the models. Remember, use “model” as a verb and “Model to have a conversation”.

 

　Modeling Tips

With the ideas and experience described earlier, here are some final tips for you to use in daily modeling sessions or workshops.

“Reverse and Model”

A lot of UML tools support “reverse engineering” features that visualize the codebase in a just-in-time manner. Some of them have a nice “Drag&Drop” from source code and even from Github repository URLs. With the packages and classes which you reverse-engineered from the codebase as a foundation, you can start casual modeling not only with the “Keeps” models, but also with models made directly from the codebase.

“Print and Draw”

As described earlier, good interactive modeling workshops are facilitated with big paper posters on the wall (or on the table) and by having the conversation with them. Draw notes and comments directly on the printed diagram.

“Projector and Whiteboard overlay”

Another way of sharing models in workshops is using an overhead projector and a whiteboard together to simulate “Print and Draw”. Use a overhead projector to project the “Keeps” on a whiteboard and draw comments or put sticky notes on it.

“Retrospectives”

I proposed my version of the simplest set of “Keeps”, but it can vary in your context. So start from my proposal or what you think works as the first “Keeps”, and do retrospectives on models you chose after each Sprint, discussing which models worked well, which didn’t and what to add. Find your “Keeps”.

“Mindmap Modeling”

UML and other software engineering diagrams don’t work well in discussions with users, planning, or other casual but important activities. Use mindmapping for those situations. See “Agile Modeling with Mind Map and UML” for the detail. Here’s an example of “user story exploration” mind map I created with a user.

---

Conclusion

In this article, I explained how modeling fits into an Agile development framework like Scrum, and proposed the models you could keep throughout the lifecycle of the product. And I recommended facilitating a modeling workshop to communicate design intentions and to establish a shared understanding of the system. These practices become more important when the team scales into many sub teams.

Acknowledgement

Special thanks to Craig Larman who first described the importance of modeling workshops (or “model” as a verb) and spent his time on an airplane to give me fundamental suggestions on this article.

Further Readings

The discussion of design in the Agile context is old. See Martin Fowler’s and Jack Reeves’s classics.
• Martin Fowler, 2004 , “Is Design Dead?”
• Martin Fowler, 1997 , “The Almighty Thud”
• Jack Reeves, 1992 , “What is Software Design?” 

The concept of Agile Modeling is first discussed in the book “Agile Modeling”. And 3rd edition of “Applying UML and Patterns” covers the topics again.
•  Scott Ambler, 2002, “Agile Modeling”, John Wiley & Sons Ltd.
• Craig Larman, 2007,“Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development” 

Another InfoQ article that addresses the same problem and context. Still waiting for the part two.
•  Lee Ackerman, 2011, ”Agile Modeling: Enhancing Communication and Understanding, 

Wider topics on Agile and Architecture.
• Bill Opdyke, Dennis Mancl, Steve Fraser, “Architecture in an Agile world, 2010”, SPLASH workshop

Thanks for reading, learn more about modeling and Astah on our site!

– Kenji Hiranabe, CEO of Astah.net

Hello Students!

Hope Astah Free Student license is helping you with your studies!

But submitting a request, renewing it by yourself each year can be frustrating. So let’s make it easy!

“Astah Faculty Site License” is the best licensing option for any academic institution. Flat rate, unlimited installations within school and personal laptops of faculty and students!
Ask your teacher to get one, and get $100 for yourself through this Student Campaign!

No more individual requests, no hassles!

Participate this Campaign!

(Google Translated into Portuguese — does this make sense?)

Olá estudantes!

licença esperança Astah Student grátis é ajudá-lo com seus estudos!

Mas a apresentação de um pedido, renovando-lo por si mesmo a cada ano pode ser frustrante. Então, vamos torná-lo fácil!

“Astah Faculdade do Site License” é para qualquer instituição acadêmica. taxa fixa, instalações ilimitadas em todos os computadores e laptops pessoais de professores e estudantes!
Pergunte ao seu professor para obter um, e receba $ 100 através desta campanha estudante!
Então não mais pedidos individuais, sem aborrecimentos!

Participe desta campanha

Product & Version
– Astah Professional, SysML and GSN

Description
When exporting Mind Map to PowerPoint (version 2016) by [Tools] – [Mindmap] – [Export PowerPoint] from Main Menu, some European alphabets and Euro signs would be turn into question marks.

Solution
Instead of using the export menu, copy and paste Mind Map topics to PowerPoint via Text editor with “Unicode” setting.

1. Open Mind Map, and hit “[Ctrl] + A”  or select [Edit] – [Select All] from Main Menu to copy all the topics
2. Unselect only the root topic
   
3. Paste it onto Notepad – copied topics will shown as below keeping its structure.
   
4. Select “Unicode” for Encoding and save this file with .ppt extension
5. Open this .ppt file with PowerPoint

Then all the slides should appear correctly.
If you want to make a front cover with a root topic, insert a slide in the beginning
and directly type in.

We apologize for the inconvenience.

Bug ID
6709, 6772

Thanks!
Thank you Jarmo for your report!

Product & Version

Astah Professional Version 7.1

Description

Unable to copy Mind Maps if the Mind Map is using a customized style template that was created in version 7.0 or earlier.

About Customized Style Template
In Astah, you can create a style template for Mind Maps to produce your Mind Map in your favorite design, color, font..etc. from [Tools] – [Set Template] – [Mindmap Style].

Create Mindmap Style Template

Solution

Opening through the configuration windows of the Style Template will fix this issue. Please follow the step below.

1. Go to [Tools] – [Set Template] – [Mindmap Style]
   

 

2. [Set Mindmap Template] dialog opens, select the customized one that is used for Mind Maps that wouldn’t let you copy of.
   

 

3. Click through all the menu on the left [Mindmap], [Topic], [Edge], [Boundary] and [Link] to open each setting and then click [Apply] – [OK].
   

 

4. Re-apply this template from Mindmap’s pop-up menu [Select Mindmap Style] menu.
   

Bug ID

6771, 6782

Status

Will fix this in the next release.

Thanks!

Thank you Arnaud for your report.

We will be closing our office for New years holidays.

Holiday

Dec.29 (Thu) – Jan.3 (Tue)

We’ll resume our normal business on January 4th at 9:00 in Japanese Standard Time.

Tech Support/License Transfer/Contact form during the Holiday

We will respond to all of the support requests, emails and orders on Jan.4. However our support staff will be monitoring all the emails and respond to the urgent matters.

Product Support / License Transfer / Contact Form

About Purchase

Purchase is available from our Online Store, however Faculty Site Licenses and Academic Individual Licenses will be delivered on Jan.4 if the order came in during the holiday. So if you are planning to purchase/renew your Faculty Site License, please do so before December 28th!

Students

If you manually request a free student license of Astah Professional during the holiday, you will receive the license on Jan.4.

Cheers,
SJ

What solves communication problems in offshore outsourcing?
Visualizing software design using UML for a communication is one, and if the diagrams were in native languages for both contries, it surely helps the whole team to have the shared understanding more easily and effectively.
To enable this, Astah Professional offers the [Alias Feature].

  Specify Alias for models

1. Click  [Alias] Tab
   

1. [Alias] pane opens and you can directly type Alias for each model
   

You can specify up to two aliases for each model.

  Display alias in diagrams

To display a diagram with alias, go to [View] – [Alias] – [Alias 1 or 2]

The diagram models will be displayed with specified alias.

*The alias example is Japanese.

  Available Edition

Alias feature is available only in Astah Professional edition.
Try it out with 50-day free trial!

If you have multiple Astah licenses in your account either for yourself or your team, now you can export all the info to CSV.
With the list, you can grasp all the license info your team has, add remarks who’s using which license, schedule when to renew and share it with users on Google Spreadsheet..etc!

 How to export your license information

1. Login to ChangeVision Members

2. Go to [License Management] menu

3. Now you see [Export list as CSV] button on the top

4. Click this button to export

You can customize the sheet as the way easier for you to manage all the Astah licenses!

If you’d like to co-terminate all the license your team has, we’d be happy to arrange the co-termination, so feel free to contact us!

What’s “Reference Model Management”?

Astah’s “Reference Model Management” is a very powerful function which allows you to import other project models as read-only. This allows you to alter models locally using other project’s models without worrying about altering the originals.

When there’re any updates on the original models, Astah automatically detects them and informs you; ensuring you’re always working with the latest changes and eliminating the need to manually check an sync.

Useful in what situations?

Team Development

When you are working with a team, you would be breaking down the work per layers, components or packages to assign to each member. Even when you are not working with team, sometimes you may want to divide projects to manage them separately. In both cases, this “Reference Model Management” enables you to work on your model with other project models without a worry about making side effects to them. Also when any change is made on the other models, Astah automatically detects it and you can sync right away.

Watch 2-min demo video

Development with High-level Design

When you have the high-level models provided from your clients, or ones that have been set in a fixed state, you want to make sure that nobody alters them. Making them “read-only” in your project prevents any unexpected alterations or extensions.
Another benefit of “Reference Model Management” is the alert that Astah gives you if an attempted change could affect the high-level model, which can be a hint that the “high-level design” isn’t currently appropriate and some changes may be needed there.

Development using Frameworks and Libraries

When you develop using the framework or libraries, you can’t make any changes to them. So importing the framework as read-only makes sure you won’t change them and create inconsistent dependencies because of changes.
Here’s how to use “Reference Model Management” with Frameworks and Libraries.

1. Reverse Engineering – import the framework source code

There are many open source frameworks available for developers. By using Astah’s reverse engineering capability, you can import the framework source code into Astah to create a “Framework project”.

• How to import Java -1 (Standard)
• How to import Java -2 (Easy Code Reverse Plug-in)
  -> just a drag & drop of .java files or repository URL onto Astah can import the Java source code!
• How to import C++
• How to import C#

2. Import the Framework project to your project

Create a new file for your project, and add the Framework project as read-only from [File] – [Reference Model Management] – [Add].
You can import multiple projects, so create as many projects as needed by reversing the source code and then add them to your projects as read-only.

3. Use and extend the Framework

Now you can work using the framework models. If Astah finds that proposed changes could have negative side effects to the framework models (by adding attributes, operations, parameters and dependencies from the framework to extended classes), it gives an alert, so you can fixe the proposed changes.

4. Update the Framework

When the framework is updated, you can reverse the latest source code to the framework project and update your framework project.
Once the framework project is updated, Astah automatically detects it, so that you can sync the update of the framework.

Try it!

Using Astah’s “Reference Model Management” for team development and to minimize accidental mistakes in designs is only available for Astah Professional edition. Get a free 50-day trial and see how it works! If you’d like to evaluate Astah with your team, you can get a corporate trial license!

Related article: Let’s start collaborative UML modeling with Astah

We will be closing our office on April 21st(Friday) due to our internal annual event.

We are unable to provide technical support on the day but bug reports and any feedback submissions are available and will be responded on the following business day.

Send us your bug report/feedback.

Thank you very much for your understanding.

Astah Development Team

I created a class model, with associations including multiplicities.  I then generated the ERD from this model, and instead of it copying the multiplicities, it made all the associations many to many – any suggestions on how I could make that work?

This is a question we’ve received from our customer:
Well, we’re sorry that this rule is not clear when generating ER Diagram from existing Class Diagram from [Tools] – [ER Diagram] – [Convert UML Models to ER Models] menu. Here’s the current mapping rule how Astah converts UML relationships to Identifying Relationship and Non-Identifying Relationship based on multiplicities -> the key is to add stereotypes to relationships.

Compositions are always converted to Identifying relationship

Relationships with “Identifying” stereotype with one-to-many relation specified by multiplicities are converted to Identifying relationship

Relationships with Non-Identifying stereotype with one-to-many relation specified by multiplicities are converted to Non-Identifying relationship