Good morning, everybody. Good morning. I'm Chris Espinos of the Apple Developer Tools team, and I'm here to talk about modeling and design in Xcode. I'd like to thank you for coming out at 9:00 on the Friday morning before a three-day holiday weekend. To reward your perseverance, we're going to be auctioning off this rack of rare iMacs. Your last chance before September to get some. Not really. We will have something for you at the end of the show, though.

So I'm going to be talking to you about the design and modeling tools, and about what models are and what they do for you in your software design process, how they're integrated into your workflow in Xcode, and talk about some of the future directions for design tools. As I mentioned on Monday in TED session, we offer two plugins, and we're going to be talking about those today, but we expect these to be the first two of many to augment your coding workflow with design tools.

What you're going to learn is how to create and navigate the class models, whether you're using C++, Objective-C, or Java, how to save and share the class models with other people in your projects, how to create a data model for the Core Data Framework, build a Core Data schema from it, and deploy an application using it.

You should know something about object-oriented programming. If you're using straight C programming for the command line or the kernel, now would be an excellent time to deplane, because this has nothing to do with you. But if you do object-oriented programming in C++, Objective-C, or Java, stick around. You'll learn something. It will help to know about Core Data Framework for using the data models. If you're not using the Core Data Framework, you might want to look into it. It's very cool and can be used from either Objective-C or from C++.

Why did we put diagrams in Xcode? The thing that really drove it was the Core Data Framework, in that we knew we needed to create schemas for the Core Data Framework, and that the best way to see your schema and to understand it and to create it was with a visual model rather than with a big table or a big hunk of XML. So modeling the data schema for the Core Data Framework was really our driving purpose.

But we also knew that there was a big missing piece in Xcode, in that we didn't have a good class diagram to let you get a bird's-eye view of your class hierarchy of your projects. We decided if we could kill two birds with one stone and have one diagramming tool that did both, that would be really helpful. Especially if we could wire it in so you could use it to browse and navigate your code from the diagram, rather than have it just be a single diagram. Rather than just from the class pop-up or the project symbols list.

So, quick models first. Quick models are: you select something in your project, you choose quick model from the menu, and it shows you a class diagram. It's really simple, it's really straightforward, you don't have to save it with your project, you don't have to commit it to your repository.

It includes all of the things, all of the objects that are in that group you selected, and it includes the first parent outside the group. It doesn't go all the way up the hierarchy, so you don't see, you know, 90% foundation.framework and 10% your project. It only goes to the first root, and that's a tool for clarity rather than, you know, completeness. It will model your whole project, it'll model a group, it'll model a multiple selection of header files or source files, it'll model a target. You can pick anything, just say "quick model." The layout's automatic.

It does a pre-model. It's a pretty nice view, and you can tailor it. You can drag things out, and you can move things around to see them. You can use it to navigate, but it's not stored with your project, so any changes you make are ephemeral. It's like a temp file.

Code models can be pretty big, so we've given you some navigation tools. First, there's a zoom out/zoom in, like any graphic tool, so you can get a bird's eye view or you can hone in on a particular class. There are tooltips, so if you're zoomed out you can actually read it because the type is, you know, like four points when you're zoomed out. There's type select to navigate out, so you can type the name of the class and you can find it in the diagram and then zoom in to where it is.

And you can, as you saw in the presentation on Monday, you can go directly from the class diagram to the interface declaration, to the implementation source code, or to the, it says class browser, but this is in error, you can go to the documentation if it happens to be a class that is built in to an Apple framework.

With the class diagrams, you can customize them, as I mentioned. You can expand and collapse the boxes. You can drag them to rearrange. You can do group selects and things like that. You can relay out the diagram to get the boxes all laid out nice. You can use custom colors in your classes. Once again, for quick models, this is more or less irrelevant because these changes aren't saved. And then there are the standard graphics tools that you might find in the graphics layout program, such as alignment, locking and unlocking, things like that.

So now we're going to give a demo of quick models, and this is Stefan Reich of my group to show you what the quick models are like. Good morning everybody. I would like to show you how to create quick models and how to work with the class diagrams in general. So, as Chris mentioned, you can create quick models from individual files, from groups, from frameworks, and even from targets.

Let's create a quick model from the source group. You see this handy design menu, class model, and we go to quick model. And here we are. For those of you who know UML, you will notice that this is the standard UML2 notation. We have different colors for the different objects, which means classes are in blue. Protocols or interfaces, depending on the language you're actually using or modeling, are in red.

And then finally, categories are displayed in the green. So it's easy to distinguish the different types and get an overview of your structure of the project. You see that inheritance is modeled or is displayed with a solid arrow, whereas the implements relationship is modeled with the dotted line. So this means derived class, for example, implements derived protocol, and derived protocol in turn extends base protocol.

The initial diagram that comes up is very... well, it doesn't contain much detail. This is on purpose because it gives you a quick overview of the product. And so what you do is, you can select individual operations to show, properties, or if you want to show more, you select them all, and bring up the context menu.

The context menu contains all of the items that Chris already mentioned: alignment, many of the graphic functions, locking, unlocking, and then working with the compartments. So we're going to expand the compartments here, and you see this looks a little bit messy. So we just trigger the layout algorithm again.

This is a good way of exploring unknown projects or getting an overview of code that somebody else wrote and so on. You can also see that it is easy to hand optimize the layouted diagram. If you think that the layout algorithm did a bad job, or it just is not easy to understand, you can just do it yourself. And so, of course, the big question is what happens to the diagram when you change the code? Let's have a look at what happens.

And so, we're looking at the base protocol here. Not there. And for everybody to see, we'll zoom in on it. You see there's two methods defined, and on the right-hand side, here's the source code. So we just emulate deleting a method by commenting it out. And you see that the diagrams are actually inside.

I love this tool. It is clear, it's instant, it's really responsive, and I've used it to figure out what the heck Stefan and Miguel have been writing if I try to look at the underlying frameworks they've built to make this all work. The first thing I did was, well, I used the modeling tool to model the modeling tool framework so I could figure it out.

It was really terrific.

Okay, here we go. So, user models are created a little bit differently because we hook them up in the new file assistant. And you see the design option here, and we chose class model. And I'm going to name this A static user model.

And so this is the core of creating user models. On the left hand side you see basically the option of what kind of model you create. It's either a static or a tracking model. In this case we choose the static model. And for now, we create the static model based on the source group again, which will pick up all of the source files. So we click "Add", and you see that all of the source files that are contained in the source group are actually added. And we hit "Finish".

And here they are. So we have a little bit larger view of this. This is actually a mixed language project. It contains both C++ and Objective-C files. And, well, this is how the general user model looks like. So, the important thing is, once you create a user model, it stays the same way regardless of if you change the source code, or if you add new classes to the group, or if you even add new classes to the source files that you created the model from. So, it's a little bit like a snapshot. It's very handy if you want to document the evolution in your project, for example. Now let's have a look at how the tracking models work. Of course, they are very different. So we create them the same way.

and choose Tracking. Now, one of the differences with tracking models is that they are mostly based on a group. And so, the idea is that you organize your code depending on your internal structure. You organize them in groups so that they make actually sense to you, so that it's easy for you to understand certain components of your application.

And so, we will model this by, in this case, using the offline sources group, which models a separate aspect of this application. And you see, on the right-hand side, you don't see individual files, but you see selected groups. So in this case, there's only one file and two classes in the offline sources group. And so, what happens if you rearrange your code, or if you add new classes to the group that you're modeling, is this. Let me put a separate model here.

To the right. And so I move these two files in this group, and you see they're added automatically to your model. So it becomes very easy to track the groups that define a specific sub-component of your application. and obviously if I drag them out, they will disappear as well.

Now, if I would add one class, an additional class here, it will also show up in the diagram as well. So, you get basically two things for free. Rearranging your code will update the model. I mean, rearranging the files in the group and file tree will update your model. But also adding new classes, new categories, new interfaces in existing classes will also show up in the model. That's it so far. Thank you.

Thanks, Stefan. I think class modeling is going to be a great help to you in your everyday work with Xcode. It's going to give you a bird's eye view of your project so that you can figure out what's going on in a big lump of source code. It will help you make custom diagrams to communicate the architecture or the function of your code to other people on your team, and it'll help you learn about third-party frameworks or Apple frameworks just by picking the Apple framework and getting an overview. There are some limitations in the version that you have on your Tiger disk with Xcode 2.0.

The chief thing to remember is that the class diagramming works off of the project index. If you have turned off CodeSense, if you've turned off indexing, you will not get class diagrams. If the index hasn't completed, you won't get class diagrams, or you will get a partial class diagram to the degree that the index is completed. So make sure that your index is complete before trying to build class diagrams.

And if you've structured your project in a way that exploits some of the shortcomings in the indexer, for example, you're including header files that have C++ classes, but they're included from a .c file, the indexer will think that, well, that header must be a C header, and so it can't possibly contain index files. If your classes don't show up in your project symbols smart group, they won't show up in the class diagram. File bugs, we know about them. We will fix them by the time it ships.

So let's talk about core data models now. How many people went to the introduction or advanced core data sessions yesterday? You've all seen this demo. Great. OK. So we will go a little more in depth than what Andreas showed in those, but you've probably seen this two or three times by now.

Core data models are kind of like class user models, but they model data objects in a persistent store rather than modeling classes in your source code. Instead of inheritance relationships, they have to-one and to-many relationships, like you'd find in a database or in an XML datastore file, rather than in the structure of an object-oriented piece of code.

Just to recap what core data is about, I probably don't need to tell you this again, but it's object graph management for document-based applications. It'll manage your object lifecycle. It manages undo/redo. It manages validation and relations between data objects. And it persists a graph of objects either to a binary archive store, to an XML format, or to a SQLite database.

And it's driven by schemas. And that's why we have this design tool, because we need a good way for you to create those schemas instead of having to write a hunk of XML or to write a lot of code to create the schema. Schema is a model of your persistent store. It's what objects are in your store and how they relate to each other, structured by the containment relationships between the objects, rather than by the class relationships in your source code.

And it's keyed to your applications classes. But you can, of course, have objects that aren't backed up by application classes, but are instead interpreted by other pieces of source code. Entities in a data model are like classes in a class model. Attributes in a data model are like class variables. Relationships are like inheritance or cap inheritance or category or protocol or whatever. And there's this new thing called a fetch spec, which is essentially a database query.

You make a schema in one of three ways. You can derive it from an XML. Now, you may-- I've gotten this question several times this week. I have tried to feed XML into the importer in the design tool, and it crashes, or it breaks, or it doesn't work.

Well, you're trying to feed it somebody else's XML, not ours. Right now, the only XML we import is the XML we've exported, because it's tagged correctly to create a schema. We'll look at extending that in the future and doing a more generic job of looking at an XML schema or a DTD or something like that. But right now, when you read in the XML, it's only the special XML that we ourselves have created on exporting it.

You can, however, derive it from your application sources. If you have an Objective-C application with a bunch of classes that represent your data model, you can take those classes and bring them right into the data model and create a data model from them. That's probably the most useful thing. If you've got an existing application.

Or if you're writing an application from scratch and you want to start with the data model and then build the classes up from there, you can start with a blank diagram and then create the model from scratch. If you create it from scratch, then you can just create new entities in the diagram with New Entity from the Design menu, and then you enter the attributes and you enter the relationships, and it's right there in your model. Then you can back it up with code.

If you start with an existing data schema, you import it from the XML. Once again, it's the XML we export. And if you create it from code, then you just specify the code files to model just like you specified the code files to create a class model from. The classes are mapped into entities in the model, the instance variables become attributes, and the pointers to other classes in that model become the relationships.

Once you've created a model, you can change the attributes, you can change the classes, you can set values on them, you can do a lot more than just use it for navigation. So we've added a data model browser that lets you look at your objects, your entities, in tabular view, and actually go in and inspect and change their values. And there's a detail editor that lets you set the values on those entities in a very detailed way, in a very powerful way. And here to demonstrate that is Miguel Sanchez.

Can you guys hear me? So my name is Miguel Sanchez, and I'm here to walk you through the creation of a data model based on reverse engineering code. I won't focus so much on what we do with the code. For that, I ask that you review the advanced core data session that we did yesterday, because this is a tool session. I'm going to go more into detail as to what is really going on at the tool level and behind the scenes.

So what we have here is... Classes represent a very simple mail system. We have things like account, headers, mailbox, messages. We want to create the data model that represents the entities for these classes. So, as we've seen before, data models are just another type of file type. So, we can do "Add New File". You will see a new file type called "Data Model". It's called this "My Model".

This is where I'm going to slow down a little bit. We have an assistant that allows you to reverse engineer your code for data models. If you wanted an empty data model, you would just click "Finish" without selecting any classes, and that's how you get... There is no new empty model option anywhere, so you just click "Finish". What we see here on the left-hand side is your Groups and Files tree that you have in your Xcode window behind this assistant. So here we have all the .h's and .m's you can find in your project.

As I select a group, for example in this case I'm going to select my "Data Classes" group, We get in the second table view the list of classes that are contained in these files. Okay, so an important thing is happening here. We're using the indexer to figure out what classes really are contained inside those .h's and those .m's. So, if you happen to try this at home and you see a little spinning wheel right about here, I believe, that's because the indexing is not yet done.

So, it's not that the assistant is broken or anything, just wait for the indexing to be done, and then that's how we can figure out the information. So, we select the group, we get classes, we add all of the classes, because that's what we want the model to contain, and we click finish.

So here's a reversed engineer model. Let me hide the detail area there. For our classes. Now, the lines are not inheritance, unlike the class demo you just saw. I'll talk a little bit more about that. So what was reverse engineering? What happened here? For each class that we found in your files, we obviously created an entity. So we have the person entity for the person class, the message. Your code contains IVARs.

So that's what's going on with the reverse engineering process. Now let's bring up the browser view to get a little more detail into the editing of the model. A browser view contains the same information that you see in your diagram, it's just in a tabular form. Let me hide this detail area first, I'm going to talk about it later.

So what you have here is a very simple master-detail relationship. You have the list of entities that you have in your model, and for each entity we display the properties that are contained inside that entity. So as I select an entity here, I'm going to get a different set of properties for each one of the entities. Now properties can either be attributes or relationships. Let's look at the more complex entity we have here, for example, message.

Where's message here? We can sort on this. Message. So here are the combined properties for message. We can sort by kind. We have attributes and relationships. So, properties can either be attributes or relationships. But you might want, structurally they're different things. Attributes have certain fields that you can access, and relationships have certain things you can do with them. So here we're showing you things as properties combined, so we have a minimum set of common fields for them. But if you click on this corner area right here, you can choose to see only the attributes.

or only relationships, or fetch requests, which we don't reverse engineer right now. But we have attributes. So it's not just a filtering mechanism, we're actually changing, notice that we changed the available columns that you have for you, because structurally they're different things. Now speaking of columns, you don't start out seeing everything that you have available for simplicity reasons. We don't wanna confuse you, but there's a lot more stuff in there.

So for example, here in the entities table view, we're only showing you the name of the entity. If you option click, I'm sorry, control click on the column name, you get to see all the other columns that you can add, whether the entity's abstract, a class that it maps to, I'm gonna add all of them in this case. So that's how you add. Remember, if you don't see the columns you might expect to see there, just add them. So, let's go back to message.

I'm going to see attributes. What kind of columns do I have available for my attributes? Well, the attribute, the type, whether it's optional or not, transient, minimum value, maximum value, I'm going to show all of them. And for relationships, we have the destination, the inverse relationship, min count, max count, let's show all of them.

Now, the columns inside the table views here are editable. So, for example, for a relationship here, Here's the relationship to address, the relationship to mailbox. I can change the destination by just selecting the appropriate entity here. So you have all the content is editable both in the table views and in the diagram view. Now let's go to the detail editor, which I hit before. Let me bring it up again.

So here, this is another area where you can edit your information. It behaves in a particular way because you can have two kinds of details, right? You can have the detail for the entity if you're clicking here. So if I click on an entity, you'll notice that this little "e" here highlights, and the fields that you see over here correspond to the entity. So it's the entity name, the class, the parent. If I click, let me go back to a class that has a lot of properties.

If I click on a property, the little "p" here highlights, and the detail here being shown is the detail for the property I'm editing. So, I can be editing a property and then want to go back to the entity that it belongs to and edit the entity detail or go back to the property detail.

And of course, if you select a relationship, the detail looks different. Now, you might ask, "Why do I want an extra editable area here if I can do a lot of the stuff in the diagram view or right here, right in the tables?" Well, this comes in handy for multiple selections. Let's say I select all of my entities.

And I look at all the properties inside all of those entities. So now, this middle area here is showing me the list of all the available properties in all the entities I selected. You'll notice that we added a column here, "Entity", automatically when we detected multiple selections, so that you know which entity you're dealing with. Now, let's look at properties as attributes. And let's sort by type. And let's look at all the attributes that were reversed engineered to be integers 32. If I multiple select these, I can set all of them to be integer 64s in one stroke, okay?

So that's the motivation of this detail area. And we're still... I think we got everything, all of the fields in here in the table view in an editable form. Let's see, one last thing about the detail area. So you have the entities area, the properties, these two icons here.

The one on the left shows you the detail which I've been talking about all this time. The "i" stands for User Info Dictionary. Now, entities and properties, and properties whether they be attributes or relationships, can contain a User Info Dictionary. This is just an area where you can add your own keys and values for however you want to use them in your code.

If you look at the API for NSAttributeDescription and NSEntityDescription, you'll see you can get to and set a dictionary. This is where you would be setting a dictionary. It's the same thing for no matter what I select. I can select a property or I can select an entity. User Info Dictionary is just a User Info Dictionary. Don't be confused by these fields. Remember what part you want to edit. I select an entity. Where is its detail?

Let's look at the general fields for that entity or the User Info Dictionary. The last kind of property I want to talk about are these things called FetchRequest. Let's go to Message and look at Properties. Think of fetch requests as a pre-built query into your dataset. I want to get all of the messages that meet a certain criteria. To build the query, you need a Boolean editor. Let's add a fetch request here. My request.

So we have something called a Predicate Builder. A Predicate Builder is a graphical Boolean equation editor. So you can add nodes and combine them with ANDs and ORs and... I'm not going to go into detail of creating a sophisticated Boolean expression here, but basically this is where you would define criteria that you will eventually use at runtime to fetch your dataset.

Now, the Boolean equation is simply made up by key-value comparisons. The keys come from the entity that you selected, and depending on the kind of key you're selecting, you have a set of values that you can query on. You can query on dates, on a Boolean value, on strings, on numbers. So this is a pretty nifty graphical editor. I mean, you're able to do things like dragging nodes between different places. So there's a lot. you can do with this editor, okay?

Oh, okay, I think that covers the highlights of the data model editing. Oh, one last thing Andreas wanted me to show you here. You saw that Andreas, Stefan, in his previous demo kept opening these things up. Now, this is your same document now, right? The data is now your model. You're used to opening multiple windows of your text information, and as you type things in one area, you obviously see them updated in the other area.

The model information is your model, is the data. So, if you move things around, they're moved in the other editor. Okay, so that's the whole thing is your model, including the browser area. So, for the next demo, after a few more slides from Chris, we're going to build an actually running application, but that's it for this demo. Thanks, Miguel.

So you've seen two ways in which the data models are different from the class models. First, that they model the data elements and are heavily editable so that you can go in and change things and set settings on them. There's another way in which they're different in that data models are essentially source files in your project, and they are built into object files using the standard Xcode build system.

This is important not just for data models for Core Data Framework, but for other models we'll add in the future where you need to model something, run it through a process at build time, and create an artifact, a compiled thing that you deliver with your application for other data-driven frameworks. For example, well, just say Cocoa Scripting comes to mind.

So we have built that structure into the plugin architecture of the design tools so that any design tool can have a built-in compiler. Or have a compiler spec that runs some other process on the system to process its model at build time and create something in your deployed executable. So in just the same way that a C file is transformed into a .o file at build time, a model file is transformed into, in this case, a .mom file, a managed object model schema file.

And when you build a Core Data Application, just like your object code is combined into an executable that's in the Mac OS folder in your bundle, the MOM file is tossed into the resource file, and it's just built there by the standard Xcode build rules. So Miguel's going to show you how to build a Core Data Application and how the pieces go together.

Hi everyone, it's me again. So now we're going to build a functioning Core Data application. You've seen this again in the Core Data sessions before, earlier in the week. But we're going to go through it again in a lot more detail as to what's really happening at the tool level.

So I'm going to create a new project. You'll notice that there's two new templates. They're analogous to the pre-existing Cocoa templates that we have, we've always had. So we have now a core data application template and a core data document-based application template. I'm going to create one of these. Let's call it "demo."

What's new in this template? What do you get? Well, you get three big things. The first is that you're automatically linked against the Core Data Framework, obviously, because you'll be using it. You get a slight change in your document class. Oh, let me fix the font here. There's a problem with the tree view. I have to reset the font for it to redraw.

Okay, that's better. So we're linked against the Core Data Framework, first difference. Second difference, we give you a document file, just like we give you in the other template, except that this document file inherits from this new class called NS Persistent Document. I'm not going to go into the details of the class, just want to show you the difference. And the third difference with this template is that we give you a blank model where you'll be putting your entities, either by reverse engineering or creating new entities. But we're going to do everything from scratch here.

Let's bring up the browser area. I'm going to create a very simple model that has two entities, a person entity and an address entity, and they'll be related. So let's create two entities. I'm also showing you the editing features here. So the first entity I'll edit here in the table view, it's called Person. The second entity we'll edit in the diagram view, it's called Address.

Let's add two attributes to the entity, to the person entity. Let me expand all of my compartments here. We have the same mechanisms that you saw, Stefan, demo in the class diagrams, so we can expand all. So we're in person. This one, this will have a field called First Name. And this will have a field called Last Name. Oops. Did I just write the whole thing backwards there? And then we go to Address. We add another field. This will be the street.

And this will have a field called Last Name. Oops. Did I just write the whole thing backwards there? And then we go to Address. We add another field. Now let's add a relationship between these two entities. So we select person, we click on this little plus R here, We now have a relationship. The relationship will be called the main address of the person.

The destination will obviously be the address entity. You get the line, and it's a one-to-one relationship, and that's about all I'm gonna do with the relationship right now. So let's look at the NIV that we got. It doesn't have much. It's empty. Let's create a simple UI for this model.

So, all I'm going to do is... I'm going to option drag person into the .niv file, and I'm going to drop it there. And Interface Builder comes up and says, "Do you want a UI that handles many objects or one object?" So I want a UI that handles many objects. So there's the UI. Now... We've only shown you this three times before, but thanks for clapping.

So what happened here? For each app, for the person, we gave you a table view where you can see multiple people. That's the kind of UI I chose to create. Where did the columns come from? I got a column for each one of the attributes I have in my person, and of course a detail selection area here to edit whatever I have selected in my table view here. Add/remove buttons.

So let's do the same thing for the add. Notice that because we have a relationship, I don't think we had shown you this in the other demo. I don't remember the relationship part. We have the main address as a pop-up here. But we need a UI to enter addresses too. So let's go over here, click on address, also drag it there. Yeah, I want the same thing. There's the UI.

Let's just put it there. Okay. So the same thing happened. We got a multiple UI for editing multiple addresses. The street. So let's create an interface builder, get back to our model. Okay. So here's where some new stuff happens. I'm going to build. What is happening when we're building?

We're compiling, obviously, your source code. You're all familiar with that. But we're also compiling this. We're also compiling the data model. I don't think we have mentioned that in any other session. If you go into your targets area here, and you look at your sources, you'll notice that as a source you have your .ems, but now you have this new type of file, which are your actual model files. Now, what does it mean to compile a model file?

Well, let's look at it and see what's in it. Let's reveal this model file in the finder. So, these are your project classes. This is the model file you're editing. Let's look at it. You shouldn't do this at home because it's private, but I'll show it to you here.

So, what you'll see inside that model file are the internal files we use in the tool to keep track of what you're editing. So, we have an archived version of your elements and the layout. And all this extra private secret stuff that we have to make the editing experience nice for you. But the runtime doesn't need this thing.

The runtime is simply interested in the structural information of your entities. So, that is what compiling means. Compiling means translating this data model file into a highly optimized runtime version of the file. And the extension of that compiled version is what we've been calling the .mom file. So, if we look into the build, we'll see that the file is actually a .mom file. So, if we look into the build, we'll see that the file is actually a .mom file. So I build output here. Here's my compiled application.

Let's go look into it inside. The content, you'll see that in the resources directory, you will have a file that has the same name as the model you were creating in the tool, but it has the extension .mom. So this is the file that the framework loads at runtime. It's found in the resources directory.

And if you have multiple files, we load all of them and we combine them and you get all of the entities. Okay, so I wanted to... How many people have used the old DO Modeler and old DOF? The main difference here is that the tool model and the runtime model are different things. It used to be the same file in the past. Now let's run the application.

So here's our UI. When I did the Dragon Interface Builder, all of the bindings were set for me and everything works. It might seem like magic, but it's all there for you. We just do the work for you. We don't really hide anything. You can always go into the NIV and change things. So I can add... We've demoed this before, so I'm just going to go quickly and... Here I can add myself.

I need to have an address, so I add an address. I live in 1 Main Street. You'll notice at the moment I add an address, it shows up in the pop-up here, because this is all being handled by the Core Data Framework. So I have my address, and I'm going to save it. What I want to show you is what happens when we save. So I'm going to save in XML format. My doc. Let's go in my data.

We save. We'll quit the application. What I want to show you is where the saving, what happened with the save. Where did I put it? I didn't put it... Oh, WWDC. Thank you. Speak as one. So, here's our XML file. What I wanted to show you was what's inside it. So let's open it in... I hate my data. Oh, right. That's a different one. My data one. Everything was going so well.

So that's the XML. It's a human-readable representation of your file. You have structural information as to the last name, first name, and the actual content. Now, why did I show you this file? So you have the three files, right? You have the file that you're editing the tool, the thing that's compiled to a .mom, and where the data is actually stored. I just wanted to briefly mention something, highlight something that Chris had mentioned.

You've seen that in other sessions we do this thing called, we use this import function, right? What does importing do? Importing, now that you know what all of the files are about, if you want to experiment with the import function, the only things that you can import are the .mom file or the XML files, okay?

Because they don't have any visual information. They're kind of optimized or compiled versions of your data. But if you want to kind of reverse engineer the entities that are inside those files, you can always import them back in. And you need to import into a blank file, so you first need to create the model and then do the import. So that was the secret that we've been using for the last two days or three days in the demos, the importing functionality. And that's it for this demo. Great. Thanks, Miguel.

If you want to see more of how that magic worked, we'll all be in the Xcode lab at the end of the hall on the left after this session. So you can come play with the tool. We'll show you how to use it. Most of the stuff that you've seen here you can do at home. We've made some changes in the version that we're using here at the show, but you've got pretty much everything you need to recreate these demos on your Tiger Preview disk and with Xcode 2.0, so you can try this at home.

Data modeling, as you can see, really helps you build and navigate your schemas graphically, create models directly from code or from XML that we've exported, and to build your entire core data application in the Xcode tool without having to go out to separate tools. I think you'll find that the integration of the design tool into your workflow is really going to significantly help and accelerate your experience in building core data applications.

So, I've given you a taste of the two main plugins that you get with Xcode 2.0. As you can see, we put in a pretty big architecture, the diagramming architecture, the modeling architecture, the building architecture, to make it possible for us to extend the design tools over time.

Matt Formica is here, and so I'm going to give the obligatory Matt Formica "we are not talking about anything beyond Tiger at this point" explanation, but I want to give you some idea of where we think it's going. Just so we don't have to listen to you come up to the mic and say, "You know, it would be a great idea if you..." and then we'd say thank you for the feedback, which will happen anyway. There are a lot of data-driven frameworks in Mac OS X, and it would make sense to model these things with a modeling tool rather than having you write XML files or configuration files.

Doing your Apple scriptability for your Cocoa application in a model would make a lot more sense. We wanted a modeling tool for scriptability for a long time. We think that we can move this in that direction. The preferences, the iSync kit, those are all great candidates for having modeling tools added, and we're looking at those. And even looking at your interface builder nib file as a diagram of the objects rather than as things on the screen. I see there's demand for that. This is what we want.

We're also going to improve the plugins we've got and extend the class modeling. The primary thing that we know you're going to ask for, because it's kind of obvious and we do it in Interface Builder and other tools do it, is, well, if I can do detailed editing of the data model with that browser, well, why don't you have one of those so I can do it in the class model as well, so I can actually change my source code or even create new classes right in the diagram and have the source files created? It is harder than it sounds. It's easier than it looks.

We will go in that direction and give it a try. But the main thing we want to do... Code creation partisans over there. That's great. The main thing we want to do, though, is we want to, along with the rest of the Xcode plugins, open this plugin API so you can create your own design plugins. So if you have your own data-driven framework, or you have your own direction that we are laggards in going in, you can add that to yourself. And we're working in that direction as well.

So in summary, design and modeling is now an integral part of Xcode. It's not a bag hanging off the side. It's not a separate tool you have to launch. It's part of your workflow. And it works the way you do. Rather than having a design and modeling tool impose the workflow on you, you can integrate into whatever workflow you like.

You can choose whichever one of the Xcode multi-window or single window layouts you'd prefer to use. The design tools work just like documents in those workflows. It's a versatile diagramming view. You've seen it already applied to two very different kinds of models. We expect to be able to apply it to different kinds of models in the future.

The core data, it's built into the build system so that it works for models that create artifact files that are loaded by data-driven frameworks. And that's something we can extend in the future. The class models, I think, are very versatile and useful right now for letting you analyze, letting you explore, and letting you communicate. What your classes do in your application. And it's an extensible architecture, so we have a lot of room for growth in the future.

Matt Formica is our tools evangelist. He's the key contact. All feedback should go to the Xcode feedback group. Once this tool is released, the standard Xcode discussion groups will apply. But this is in Xcode 2.0 only. It is covered under the non-disclosure. So send us feedback on [email protected].