BILL GATES: What's the key technology that's going to let that designer, tester, or IT person, that's going to allow them to connect in one way?
BRIAN HARRY: One of the key areas we're investing in to do that is in modeling. Applications get very large, they get very complex, and very soon they're very hard to understand what they are, and modeling allows you to conceptualize applications at a higher level, and be able to make sense of them. So, in fact, I'm going to show you some of the really great stuff we're doing.
BILL GATES: Take it away.
BRIAN HARRY: All right. I've got an application here, which is a customer service application. It's a simple application that allows me to enter a customer, and look up that customer. And it shows me their information. But, we want to add cell phone to this, you can see the cell phone is empty, the application doesn't manage cell phone numbers yet. And someone has updated the Web page, and my job is to go and update the application.
Well, I've never worked on this application before, so I don't really know where to start. There is a bunch of code, and I could start poking around through that code trying to figure it out, but wouldn't it be nice if there were a better way to sort of get into this application and figure out what to do. Well, let me show you. We've got a new tool called the Architecture Explorer. Actually what it does is it goes through your solution, parses all of the code and visualizes that to allow you to see your application.
So here you can see that we've got five major components represented by these gray boxes. These are the projects in your solution. Those contain different interfaces, classes, and methods. Over on the left hand side, I'm going to zoom in a little bit, over on the left hand side is the client side of the application. And over on the right hand side is the server side of the application.
You know, as I'm looking at this I'm seeing that my customer card Web page that we were just looking at references some customer helper in my server application. That doesn't look right to me. This is supposed to be a three-tier application, but I'm not sure. So I'm wondering, is this code actually conforming to the way it was designed. Well, let's go look at another tool called the Architecture Layer Diagram. This allows me to describe my application as I intend it to be.
As you can see, this application has a presentation layer, which talks through a Web service proxy, to a service facade, a business logic layer, and a data access layer. And I can associate components of my application with each of these parts of my architecture, and that's represented by these little gray boxes. Now, what I saw in that picture was a dependency between the page here, and the data access layer here, and I can look at the architecture diagram and tell that's not right.
|
|
|
Now, I happened to catch that by looking at it, but I'm not always going to do that, so wouldn't it be nice if there were a way to tell automatically. Well, there is. I can run I can validate my actual code against the architecture. So I do that, sure enough, it tells me that there's a dependency validation error. The class customer card, in layer pages, has a call to customer helper in the database layer. Well, okay, that's clearly not right. So before I go and start making changes to sorry, before I start making the cell phone changes, let's fix that. I don't want to leave that in here. So let's go to the customer card Web page, sure enough I can look at this code and I can see that it accesses the database directly, and in fact, it looks like the developer probably even knew what they were doing was not quite right.
So let's replace that with some code that actually goes through the Web service proxy, and fix that architectural problem. Okay. With that done, my next job is to add the cell phone field, I need to add it to the data access layer. Well, as an interesting thing, this application is written in DB2. So I don't have a DB2 the database is written in DB2. I don't have a DB2 development tool in hand, but I do have Visual Studio Team System for Database Professionals. And wouldn't it be nice if I could stay in Visual Studio and do my DB2 development, in addition to my C# development, my SQL Server development, et cetera.
Well, now you can. With our upcoming release of the database professional GDR later this year, you will be able to do DB2 development directly inside Visual Studio without leaving the IDE. Let me show you how that works. So you'll see the DB2 artifacts in the solution explorer. I can drill down into the tables, and I can find the customer table. I can open it, and here's the schema for that table. Well, I want to add the cell phone, so I'll just copy that. And there I am, I've added it.
|
|
|
Now, in addition to integration into the Solution Explorer, we also have integration into the schema view, so that I can drill down and confirm that, sure enough, cell phone has been added. I also have a phone field here, and I'm a little concerned that that will be confusing to people, to have a cell phone and a phone. So let's change phone to work phone. I can use database refactoring, the same feature that we have today in Database Professional, on DB2, to very easily change that to work phone.
And that will go through all of my code, find all the places that need to be changed, and change it, provide me a preview pane, where I can review the changes that need to be made. There's the schema change, here's changes to my stored procedures, it will find my strongly typed data sets and update those. And when I'm happy, when I've reviewed it, I can simply say apply, and I'm done.
So my application has now been updated. Let's go back to the layer diagram, and let's confirm that I've fixed the architectural problem that I had before. I'm going to rerun the validation, and sure enough, I no longer have an architecture violation showing a bad dependency.
Now, I showed you that I can manually validate this, but wouldn't it be nice if I never got the problem in the first place. So another feature is the ability to create a check in policy associated with architectural validation, so that I can actually validate it before the code ever gets checked into the system, and avoid creating spaghetti code in the first place.
Let's go back one more time and look at sorry. I'm going to show you one more view for looking at your application dependencies. This is a nice summary view that allows me to see all of the dependencies in my application, and here I've got my customer card class, and we can now see that it only has one dependency, and that dependency is on the customer service client, instead of on the data helper. So that's good. And just to complete it we'll go back to the original view, and show that I now have all of my client and all of my server separated with no cross-dependencies, other than the Web service dependencies.
|
|
|
So what I've showed you is that you can take an application that you've never worked on before. You can use the modeling tool to parse that application, and show you a visual representation of it. You can then go in and understand how that application compares to the architecture as it was designed. And you can make your changes and validate that your changes conform to your design.
I've also showed you that you can use our database professional tools against a DB2 database without leaving Visual Studio. So you no longer have to manage two IDE environments for doing your application development. This is a big step forward. And further, as we go forward, we're making a lot more investments in the modeling space. This is just step one in a wave of modeling products that we're doing that you might have heard is something code named Oslo. It represents a set of investments both in modeling tools, and in a new modeling language for describing models, and in a modeling repository for being able to store models and manipulate them.
Дата добавления: 2018-05-12; просмотров: 238; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!