Good morning, everybody. I'm Chris Espinosa of the Apple Developers 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 o'clock 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'd 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 just from the class pop-up or the project symbols list.

Diagrams are easier to grok in a large scale than looking at your code or even looking at it in the class browser table-wise. We wanted to draw you some beautiful pictures, not just that you could see and visualize, but that you could change and modify yourself so you could use them not just for the tool to communicate to you what your code looks like, but for you to communicate to others what your code looks like. So models are integrated into Xcode. They're not a separate process that you run to take a look at your project. They're not a window you pop up in order to see it that's separate from your workflow. They're deeply integrated into Xcode to the degree that model files are project files in your project. You build them. You save them. You check them in. You commit them. And for data model files, you even build them in your build process. That's how deeply integrated they are.

They're integrated into the SCM system, whether you're using CVS or Perforce or Subversion, so that they can be checked in just like NIV files, just like project files, just like source code files. So let's talk first about the class models. You probably saw the class models in Ted's presentation on Monday. You may not have seen class models since then, so we're going to be doing quite a bit of time with class models today. First of all, they're language agnostic. They show C++, Objective-C, or Java in this first instance. As we extend Xcode to deal with more languages, as we add more design plugins, you'll see class models for other things as well. We have a generic UML2-based framework underneath, so we can model pretty much anything that you want to model. Right now, what you've got on your disk with Xcode 2.0 is C++, Objective-C, and Java. There are two kinds of models, because we knew that you'd have different modes of working depending upon whether you were really down drilling into your code or whether you just wanted to get an overview of something new. So we have quick models, which is here's something I want to see it, and I don't care if it goes away when I close my sessions. And then there are user models, which is here's something I'm really working on. I want to hone it. I want to tailor it. I want to use it as my principal navigation tool, and I want you to save that with my project.

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 90% foundation dot framework and 10% It only goes to the first root, and that's a tool for clarity rather than 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 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 tool tips, 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. work.

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 a 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. And so, let's start and create a quick model from the source group. So, 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 error, 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.

But laid out correctly. And so 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 know, you can just do it yourself. And so, of course, the big question is what happens to the diagram when you change the code. Well, 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.

Of course, the same thing happens when you add a new method. Yeah, so this is how you work with the class diagrams and how to create quick models. - Thanks, Stefan. 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.

So the quick models, I think, are going to be the ones you use all the time just to pick a group, pick a target, pick a framework, model it, figure out what's going on, what's related to what, and navigate. But if you want to, if you've got a lot of people working on a project or if you're going to be spending a lot of time in one part of the code, you can build your own navigation front end to that code with the tools that Stefan described. And you can persist those. You can save those with the project in a user model. You define the content and the layout, the positioning, the direction the arrows run, the colors of the bubbles, what's expanded, what's not expanded, things like that. You can focus on a subset of code by picking either specific source files or groups of source files to model. And you can not only track the changes in the files you're modeling, but if you model at a group level, you can track changes in that group. So that if new classes or new files are added to that group, they're automatically added to the model. It's very cool. And then once again, these changes are stored with the project so that any changes you make, if somebody checks it out from the repository, they go to your model, they can see how you've arranged things, how you've laid them out. So let's go back to demo one, and Stefan can show you user models. STEFAN KUHLMANN: OK, so here are the user models. We create user models a little bit differently than quick models because-- JONATHAN BERG: Demo one, please. 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 gonna 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 difference 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 the 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 subcomponent 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 in File 3 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, Shethan. 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's 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. So if things are missing from your class diagram, file bugs, we know about them. We will fix them by the time the 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. 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 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, 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 wanna 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, and 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 and 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.

And 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 dot H's and dot 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. 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 for class, the message. Your code contains IVARs.

So, we try to be smart and for each Ivar we find in your code we create an attribute inside your entities. Now, there's a little more going on there. We don't just blindly copy attribute names to entity attributes. I'm sorry, Ivar attribute names to entity attributes because you might have underscore attributes that you don't really want persisted. So, we try to be a little smart and what really happens is that we go through your attribute list and we see if we can find setters and getters for those attributes. If we do, we assume that those are attributes that you want that are part of your data model and those are the ones that show up. They're given the right type if we can figure it out. Otherwise, we set them to be the unknown type if there's some special class that you're using. Where do the lines come from? Some classes, for example, receiver here, will have instance variables that point to other classes, for example, message and address. If we determine during reverse engineering that the classes that these things point to are also in the set of classes that you're reverse engineering, we assume that you want those two entities related via to one relationship. So that's where the lines come from.

We also detect inheritance. I don't have it in this particular example, but if you have an inheritance relationship between classes and both of those classes are being reverse engineered, you will see the inheritance line. So the inheritance line looks a little bit like this, except that it's an open arrow.

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 is 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. 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 want to 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 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 going to 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. Thank you, guys. 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. And 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. Please.

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 integers 64s in one stroke, okay?

So that's the motivation of this detail area. And we're still, I think that most of, I think we got everything that, 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. So, if you look at the API for NS attribute description, NS entity description, You'll see you can get to and set a dictionary. So this is where you would be setting a dictionary. And it's the same thing for no matter what I select. So I can select a property or I can select an entity. UserInfoDictionary is just a UserInfoDictionary. So don't be confused by these fields. Remember what part you want to edit. I select an entity. Where is its detail? Well, let's look at the general fields for that entity or the UserInfoDictionary. The last thing, the last kind of property I want to talk about are these things called fetch requests. Let's go to message and look at properties. So think of fetch request as a pre-built query into your data set. So I want to get all of the messages that meet a certain criteria. Now, to build the query, you need a Boolean editor. So 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. 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 data set. 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. You're able to do things like dragging notes between different places. So there's a lot you can do with this editor.

Okay, I think I think that covers the the highlights of the of the data model editing Oh one one last thing andres wanted me to show you here You saw that Andrea 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. So model.

It is the data. So if you move things around, they're moved in the other editor. 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, 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 plug-in 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.

Okay, 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, early 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 gonna 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. I 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 over. We have the same mechanisms that you saw, Stefan, demo in the class diagram, 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? Um, and then we go to address, we add another field. This will be the street.

And it's not optional because it's the only field we have in there. Now here's where multiple selection comes in handy. I can select all my entities. I just added three fields, and I want them all to be strings. So they all become strings. 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 nib that we got. It doesn't have much, it's empty. Let's create a simple UI for this model. So all I'm gonna 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. 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 app. 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.

And let's just put it there. So the same thing happened. We got a multiple UI for editing multiple addresses. The street. So let's create interface builder, get back to our model. 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.ms, 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 'cause 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 archive 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 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 -- explain this in a lot more detail because it gets how many people have used the old deal modeler and old EOF okay so 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 so 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 gonna 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 gonna save it. What I wanna show you is what happens when we save. So I'm gonna save in XML format, my doc. All right, let's go on my data.

We save. We'll quit the application. What I want to show you is where the saving, what happened with the save. So, Where did I put it? I didn't put it. Oh, WWDC. Thank you. Speaker 1: 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. Speaker 1: I hate my data. All 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 it'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. Thank you.

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 in to 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 xcode-feedback at groups.apple.com. you