How to "think" (and design) like a Software Architect at Silicon Valley Code Camp 2019

Oh am I being recorded Oh too bad I was gonna say something well anyway so I was gonna say and no offense to anybody but if you if you're if you're a software architect who was never programmed right is kind of like a priest at a wedding he he does you know he he performs the service but he can only imagine what comes after if you're if you're an architect and you don't know how to program your design will reflect the fact that it may be very difficult to implement so there's that a lot of the best software architects are coming up from from programming that's recorded wonderful okay we have about two minutes any uh any any questions or anything - okay yeah all right so I I have a I'm kind of retired for my day job I was at the toward the end I was um I was with son for 20 years I was with them when they were a startup a start down and start writing your resume the the startup period was the most fun for sure I was technical I wound up eventually as technical director of the company and I supported I did an awful lot of work and that's how this thing started an awful lot of work with standards bodies in specific industries like how do retail all the systems that go on in a retail enterprise you really want to be doing plug-and-play which means we want to have interfaces for the you know the point-of-sale system and the item inventory and and working out those so that vendors would would do these api's and so you could plug and play and ax turned out it was more plug and pray but I was doing that in a lot of different industries and looking at how software architects sitting on those committees and realizing that a lot of what they were doing in different industries already know about it was a lot the same so that's kind of where this came from I actually started object oriented analysis and design at the Anza because they introduced some object languages and I said to a student how did you what how did you find it and the answer was oh it's great C++ it's great i / / as a comment you know it's like no you're not using a language so anyway that started this and and and he ran yes absolutely absolutely and will show an examples here one one slide on here is the complete evolution of computer languages so like I said it's a lot of but because they're of they evolved in a certain way and when you look at the series of language as you start seeing what drove the evolution of languages and it's so I think are we good we we start okay so the the priest thing is down on tape okay so here we go how to think like a like a Software Architect now this goes back to 2015 which is admittedly the dark ages in computer science but CNN Money Magazine and I was I love this it was the number one best job in the United States was Software Architect and the analysis to understand what it is you think about the way that an architect designs a house a software architect lays out plans for new programs an architect uses blueprints a software architect may use UML which is unified media language diagrams there's a lot of them the ones that really matter are the ones that don't document you thought but actually help you think about the the problem and we'll look at a few of those you know new problems come up all the time and new technologies arise making each state difference in keeping professionals in demand and and and that is true one other thing but we're going to talk about are the kinds of applications that are ubiquitous everywhere but in the valley because in the valley it's all about eyeball capture and customer capture and front end and this and that the systems that we're going to talk about being architectured in an object-oriented fashion are the back-office stuff most of the programming jobs in this country are working as in the IT department of a major corporation now that corporation is located in Kansas City or you know minute Minneapolis and you don't see it here or working for companies that sell to major companies not customer facing companies and and the the systems we're going to be talking about are the way the world works every company every school has a plethora of programs that interoperate and and are designed in the way that we're going to we're going to talk about it it's one of if you're in everybody knows this but people in the valley so let's let's take a look if you're building a house are we building anything really there's a customer planning documents some physical design decisions and and then the actual installation and if it's a house you have a buyer and you have an architect who does the blueprints you have a general contractor who makes decisions like what type of plumbing are we going to use probably better to use copper than lead right what kind of wiring are we going to do what kind of plug-in are we going to have for the speakers and then you have the skilled workers come in and they do the electricity and the installation of the actual wiring and the plumbing and they make it real and in a software application this parallels the development of the software application the buyer is the domain expert so if you're in retail the buyer of that particular system might be the you know the head had retailed data person if it's in a college and the example we're going to do is from a college it might be the Registrar someone who knows the application doesn't know the programming the software architect functions as the architect does in a house the blueprints are these UML artifacts and we'll see two of them before of the big five chances two of them general contracting that's the aspect of any application it's the thing that says you've got your application right how did you do security is your data going to be local in the cloud is your application going to be in the cloud or in the data center those are major decisions that you that you have to make and the people who do that are sometimes a Software Architect sometimes it's like the designer and then when it's everything's laid out programmers come in and implement it now sometimes admittedly the programmer can be wearing a lot of hats you can you know if you're on a small project you do most of that yourself but for large projects they really are different but what does the Software Architect actually do when developing a new application so the first thing is read understand and clarify the functional spec this is typically a one-on-one interaction with the domain expert what is his system trying to do to identify and document the problem the requirements the constraints and so on now the next slide is an example this was an enrollment system at the ends of college my thinking here is when I presented this that I knew that everybody in the audience had actually used a system like that because otherwise they wouldn't actually be sitting in the room people here I'm sure have enrolled in courses at different schools and so we're going to take a look at what's involved with something like that and how you think about it so I'm again this is a very quick read and I'm just gonna spend it highlighted the ends of courses are offered by its departments and available quarterly each course has an identifying number a name this is in my case object oriented analysis and design a description number of credits optional set of prereqs each course is assigned a set of times when it meets assigned a teacher qualified and willing you can be willing but you may not be qualified and who is free during the assigned times its assigned a room which also must be free students may then attempt to enroll and then there's some requirements on that and depending upon the size of the course the number of students the students enrollment requests may either be accepted and the student may be wait-listed or this request would be denied if the student is accepted or attendance will be tracked at the end of the academic quarter she will receive a final grade this is a very high-level and brief functional description of a combination of class scheduling and enrollment it's a system you must produce a working solution where do you begin this is the wrong answer you don't start coding in fact everything between what I give an entire course on what occurs between the functional spec and this okay it's the the thinking about the problem that's really the the interesting thing so this is a diagram for how systems are developed using feature driven design and we are we start out with the functional specification this is the piece we're going to get to today going through and thinking about what are the basic abstractions in the problem and how do they interact interact and how do they how do they relate together when you have the the basic abstractions you then flesh out the behavior remember I said that the section you could you you could know every interface to ascend to I'm sorry of course you could know every interface to a course object but you wouldn't know if you said I want to enroll you wouldn't know whether what the reaction was going to be because the course could be filled or the course could be empty you know so sometimes you'd be rejected other cases you'd be put on a waitlist that's behavior and behavior is stateful information so once you get your objects and they're stateful then the various use cases like enroll student and section are taken and analyzed against the the objects that you have to make sure that you can you can do the application is defined so we're gonna we're going to concentrate on the first part to give you an idea of the thinking that goes into a typical application so again number one identify the basic abstractions referred to in the functional spec and in the functional spec we looked at there were some words that must be further refined to determine exactly what the proposed system is actually required to do so we do that we go the ends of college college sounds like a thing I'm going to be manipulating right courses courses are offered by its departments so I'm thinking okay I've got colleges I've got courses I've got departments how hard is this right let the flu to go eat it is also assigned a teacher okay who is both qualified and willing it is also assigned a room students and I look at this and I'm saying okay I I kind of have at least conceptually some of the abstractions that I'm going to be dealing with course college teacher department room in Section and I start out and I say okay so far so good right and then I start thinking about it because one of the things that's true when you are designing systems is that words have meaning and everybody on that system designed whether it's the architect the designers the programmers the customer everybody has to have a very clear and crisp definition for what the names that you're assigning these abstractions what they think they fully mean in the context of the application because the same word can mean totally different things and for an applications you know the one example I give is a birth record system we're one of the things in there's an attribute that's like blood type and that attribute is like a string it's always positive whatever if that application is a blood bank blood type is this huge object with all of the capabilities same word but in a different application it means something totally different so here I start asking questions can a room and a teacher be assigned to a course in other words how many people have enrolled in a course at a college I'm people that's it yeah okay good good thank you one of the things I find in in my classes like I'll do exactly that I'll say how many people have in have enrolled in this course and in the class of forty people I'll get fifteen hands and and I'll reel and then I say and how many haven't and then I get no hands and I got 15 votes out of 40 people and I always tell them that's why we have the president we do okay but but anyway thank you that's on the tape too of course so the question is how can you know can a room teacher be assigned to a course and you think about it and then you know you go well that's tough right because you know you've got a course and like introduction to Python and it meat you know it's given it four times during the the week in four different rooms with four different teachers how can they all be assigned to that course it's not you know it's just it's a little strange you know because the course might be taught in several rooms course might be taught in by several teachers if you enroll in a course which teacher are you getting and which room are you're getting and you start to think you know I'm missing something here it's that uneasy feeling that you get when you you like that that your vision of the problem doesn't really match up with the actual reality reality on the ground so we need a new abstraction there has to be there's an object or an abstraction that's missing from the initial set of objects that we that we had and we need a section and a section has a room teacher students hours to meet a course has the rest of it has description name credits the textbook that you might have what you know again what quarter is it offered and there's a relationship between the two and it's a one to end relationship and that is a course has multiple sections and a section each section is a section of one course so you've got an end to one relationship between course and section and relationship is instantiates in the same way that that an object will instantiate a class so if you have a class scientist an object of that class is Albert Einstein or Isaac Newton it instantiates the concept an object Senshi AIT's a class in the same way you know conceptually at least a section instantiate the course it's the relationship now again one of the things you could say is well you know you could carry what do you even need a course you could carry all this information in each section every section could have the name of the course and the textbook and you know but then if you have five sections of one course you've repeated the information five times it's much better to keep the abstractions separate and relate them through an instantiate relationship refining the extractions so now we've got a problem here when we start thinking about it more we've got sections now right and the question now is how does do teachers rooms and students the text scheduling conflicts want to sign the new section because one of the requirements is obviously you can't attend to sections that overlap you can't teach to sections that overlap and you can't host in a given room two sections that overlap so there's obviously going to have to be some scheduling stuff you're going to have to do and you're gonna have to do it for teachers rooms and students and so you're looking at this and you're saying you know the same logic is going to be presented three times I'm gonna have to write the same logic three times it to be able to schedule teachers rooms and students you have duplicate functionality in in three objects and that seems wrong and at that point you think well you should think if you're a software architect duplicate functionality in three separate objects this is a design challenge I cannot possibly be the first person to encounter this problem and you're not there's a thing and and and I'll ask for show of hands seriously voting how many people have heard of design patterns Oh fantastic that's fantastic okay design patterns for the two people that didn't raise their hand design patterns are kind of like object libraries it gives you a chance instead of reusing code it gives you a chance to reuse thinking and so a design pattern here is each assigned their own schedule when in doubt when you've got and you can refactor when you're when you have the same logic that's being repeated again and again what you realize or what you could do is to incorporate all of that in an object one object and have everybody else use it this doesn't sound like a great step forward but schedule is a particularly good example of this because with schedule you don't even have to know how to how to write that you don't have to know how it was set up you know the only thing the scheduled object does from externally right as you could say here's a schedule for the section here's my schedule they're a problem and the schedule comes back your schedule live - comes back and says nope or yep and and if there's no you could say to your schedule object please add this schedule and it does you have no idea how that was done the person who implemented schedule has the idea how that was done that's why they're objects the thing about objects is they encapsulate their their implementation so we started with these six and now we've got two more we we said you know in terms of the abstractions in the enrollment system we've just added schedule which is going to save us a lot of problems in in figuring out how how to make sure that both teachers rooms and and students don't have schedule conflicts and we have a section which is distinct from what we thought was a course and we're starting now that's been the morning staring at the ceiling okay what's a pre-record prerequisite means it's a requirement you know right so we look and we say well you know a prereq it's a course it has of course identifier right like you can't take CS 28 until you took cs3 and so the prereq is cs3 probably the pre records of course prereqs might have other prereqs cool cs3 might have CS one is a prereq and so on so it's it's going to be of course no it's not right because the if you look at most catalogs prerequisites re the courses or and they could be advisory in mandatory you've got to have this or you maybe you need this would be good if you had it and in fact they can be text rings you can either have this course or you can have some prior experience with an object-oriented language so what a prereq is when when you think about it in this particular application thinking about the application of how it's going to get solved a prereq is it's probably an object optionally containing a course ID among other elements so we're now at nine just in terms whoops sorry just in terms of thinking about the the the enrollment and the fleshing out creating section we've now got nine objects that we that we thought about and the so the second piece of this determine the relationships between the abstractions often involves selecting incorporating design patterns the this URL it's a marvelous URL nobody in my classes on but I get the feeling here if people have how many people know that have heard of the Gang of Four okay how many people think that was China right after Mao no okay there's a second Gang of Four okay it's the Gang of Four who wrote the book on object-oriented actually actually on design patterns who took the collection of designer successes and found a formal formalistic way to to define them so that they can be reused easily now the book the Gang of Four book was a landmark and you don't have to know the contents but you really want to know the index because the index tells you what's there and if you need it you know you're going oh man I've you know I've got all of this code we duplicated and you look and there's the pattern that says why don't you put it refactor and get a separate object and put the code in there so this is free on the web it's a PDF file now it's really cool and and I would urge you know if you're serious about programming this is the original one there's now a lot more because every grad student wants to get his own pattern you know her pattern but this is the original these were the ones that were felt to be important if again if you're doing something specific like you know the cloud or something there's books on cloud patterns and so on which are going to help you think about reuse the thinking of those that that come before it's it's very much like in science they would say you know I stand on the shoulders of the generations that have that have gone before in programming it's more like you stand on the feet of the generation that have gone before and you're always you don't get up very high and you're always tripping and falling over each other but design patterns are supposed to be the way that you you really do reuse the thinking of others so this is a diagram it's the conceptual class diagram it is a UML diagram and if you're starting an application in fact if you're coming into a company that has an application this is the thing you want to look at yes this it probably does you know the people that put together the unified modeling language were using the work of the people that had come before them this but in this particular diagram if I was starting work at the company that was making enrollment systems and so on this tells me what kind of what I'm dealing with one college has n departments each department employees and teachers teacher tends to be employed more for the department than the college each department owns rooms sometimes they don't sometimes the rooms are owned by the college but in our particular case we're going to find out that that's true each department offers courses courses may have prereqs each course is instantiated by n sections and notice section room and Peter incorporates schedules and if you look at this it it's an overview and a teacher and one teacher instructs multiple sections now you could say well maybe it's team teaching and stuff and there's a little bit of arm waving here but in general if you're trying to get your mind around what it is that the application is doing and what are the basic abstractions that are going to be manipulated this is not a bad not a bad diagram well we don't here you know and this is this is where this is the the high level conceptual and and now again where it gets interesting right is let's say that we are all this is a company meeting of the enrollments you know we are enrollment company right and we sell these things and and your point is well-taken we've sold it into three colleges and now the fourth college says well wait a minute we allocate rooms to multiple departments and how is that going to work and we have to think about that that that yeah stuff moves right it's not that this is just in our in our simple case because we could clearly spend a day refining this with all of the things but conceptually this is at least the first pass if you came in then at least you now because look at what you did you looked up here and you said I don't think that fully reflects a requirement I have but at least we've all got the same thing to shoot for we're all talking about the same you know description of what the of what the problem is so so the question was for the people that couldn't pick that up on the on the under video thing the question was it makes sense to the domain expert you can show this to the registrar and he or she can look at this and say yeah that's right and if in fact you said something like well you know we have some some sections that are virtual okay and you're now so you're looking at saying great we're gonna have a virtual room that's always free and you know and and the point is you can you can take the requirement that the Registrar has said and you can map that into the particular object or objects that are gonna be affected by trying to meet that requirement because you're thinking about the problem in the same way that the domain expert is thinking about the problem that's the key thing it's why if an architect for a house you know if if the you know if the if the user says you know and I want an aquarium in the bathroom well you kind of know where the bathroom is and you kind of know what an aquarium is and you mumble mumble mumble and now you start but the point is that's kind of what this is and requirements change right there's one of my favorite cartoons which I had hanging over my desk a couple of years was it was a there was it's ancient Egypt and there's a pyramid and it's not quite filled it's it's huge in the distance but the top is still not quite done and there's lines of men in the distance heading toward that pyramid and going up the sides to fill it in you know building this huge pyramid and there's a gentleman on standing on a hill overlooking all of this and he's got a megaphone and he's screaming into the megaphone stop work there's been a small change of spec the Pharaoh wants to be cremated okay now that's that's an example of a rather a larger change aspect than we normally see on these things but your your point was was valid well you know what if you had virtual sections what if you had rooms that are shared what if you had and you're trying to expand your your application but conceptually at the top layer this is what you're what you're saying yes yes I can so the arrows typically the way the arrows work is the arrows indicate how the word applies so one room locates and sections right but here and sections instantiates one course had I said instantiate by the arrow would have been the other way like one course is instantiated by in sections yeah yeah sure so relationships if a relationship and these are some C++ coding examples but they're very small it's not necessarily that you need to know how to write C++ code but you should know how to read a couple of lines so this is a class teacher and inside of class teacher is a private schedule object that's a one-to-one relationship every teacher has a scheduled one to end like every teacher can teach many sections but a section only has one teacher so in this particular and simple case you have a teacher and it had teacher every teacher has an array of this is really bad code has an array of up to 20 sections well and basically has an array of up to 20 section pointers because the teacher object isn't going to contain two sections it's going to point to 20 sections that the teacher might teach one teacher in sections what you're really saying is a teacher has a collection class of sections and the collection class and it depends and if you're the architect you'll specify right there's the vector which is everything that an array always wanted to be when it grew up you know there's hash tables there's a linked lists there's queues and stacks and these are all ways that one thing can collect other things and the architect will determine and there's you know if we had another hour we talked about the appropriate use of collection classes but this is one to end right into one is in this particular case every teacher and teachers point to a department so if the department name changes and and that at the ends it may be happening we may be going from CIS finally to see us from computer information systems to computer science if we did that it's not like every teacher would have to every teacher would see that immediately because teacher points the department and department names change so if you're asked to teach you what department are you you change the name of the department and you don't have to run around in world teacher objects and change the name because you just end things are pointing to the same thing and that's an example of into one end to end this is the bad one a student may be enrolled in many sections and every section can have many students so if if you're a student you're enrolled in five sections 110 if you're a section you have 40 students that's end to end that's called the interrelationship and here we are you have a student and it's got a schedule and you've got a section it's got a schedule it's an end to end relationship one student and sections every section has in students how do we implement this well the first thought is why not why not um why not have a raise of pointers just like we did before so you're a student you point to all of the sections that you're thinking and if you're a section you point to all the students that are enrolled and if you're a programmer you're done and if you're an architect you're not done because you're thinking about it right and you're saying well wait a minute you solve the problem for interrelating and to end but this problem is a little different because each relationship has its own data so if you're a student in a section you have a final grade that's assigned you have an attendance records you have exam grades you have teachers comments you know works and plays well with others I don't know the point is all of that goes along with your relationship to the section now the arrays where do you carry this information if do I carry it in student do I carry it in section for each one of these for each each student in a section I have this or for each section that a students take I have that or worst of all do I have it in both places right and you're thinking I have an end-to-end relationship with Associated data what am I going to do I'm probably the first person in the world that ever ran into this and you slowly think wait a minute wait a minute wait a minute there's probably a design pattern so you go to the Gang of Four or whatever you're you're using for your thing and you say ah a Junction class put something in the middle so you know now every student has any of these things and every section has entities things and this thing whatever that whatever it is has a pointer to the student and appointed to the section because it's an into one relationship with both of them and it has the Associated data of the relationship so one student can walk through these things and find out everything for every section it's in it now can find out okay I can get the section to find out the section information and I can also find out how I did in that section and every section says okay for all the students that I've got I can come in here and find out what their grades where I can get the name of the student and we saw that the question is what is a thing let's talk about that so someone said it's the enrollment but the problem is enrollment works for the section and in fact enrollment is probably the name of the collection of these things you know if you have 40 students enrolled right each one of these it's an enrollment but yeah I mean it is but typically enrollment is all is the collection of I mean it's not bad but it's a collection of all of the students in sections usually what enrollment is a data table the meta table so you you could say every student has n meta tables you know I mean it you could write but it may that may be how its implemented and particularly are you a database guy okay that was a lucky guess on my part because many tables typically I mean that's there is a different thinking between database people and and and object-oriented designers because the database is you know they're they're in two Junction they know Junction anyway in they're different and and sometimes you you you trip over it but that I mean because many they metadata in a way it may apply it may not apply but that's not the name of it well you're looking here for the thing that binds yes we use the word great and a great it's just a part of this what it is it is I'm and and yeah right and and if you're an architect you people who say guys don't understand relationships well if you're if you're if you're a software architect yes you do you know but but yeah but I mean that wouldn't help it's like because what are you going to say you're going to say to the domain into the registrar every one of your students is involved in many relationships you know it's not it's not what you what you you want to say something to the to the registrar that's gonna you know he or she is gonna go yeah okay I get that what binds you to every section you ever you ever sat in hint as a seat if you if you a student occupies and seats and a section has n seats that gets occupied by student and every seat says this is a student that's the section that's the final grade tenant you that you got in that seat that I mean the point is I guess the point here is if you had the junction set right but it's if you can find a name that absolutely nails what this abstraction is you're way ahead of the curve because this is something that the domain expert will like the Registrar will understand immediately yeah we open up a section with 40 seats 27 of them are allocated to students so you've got the 40 seats but only 27 of them have a reference to show that there's actually a student there and again seat is a very useful abstraction an example would might be well you know kind of you think of it like well an airline right an airline seat an airline seat is very different than this kind of seat because an airline seat has an identity you walk into a room to sit down you're just going to sit down in any room but that's not true on a plane unless you're flying Southwest but so that's a that's a difference the other difference is you know how many of you are in a first-class seat here you know what you know so the same name the same seat name and in fact but it very different abstraction we need to define what a seat is and once we do that a lot of the problems we had go away we used the design pattern and we've now got a new abstraction and so guess what we're now up to ten we originally had six we've thought about how we're developing things and we're up to and we're up to ten and so now we go back to the functional description and we put in our abstractions and we go back to the register and we say this is what we're solving in the ends of college courses are offered by departments instead of prereqs each offered courses instantiated by one or more sections each section designed right and it has a schedule which defines a set of times it is also assigned a teacher and someone and so on it is also assigned a room students may then attempt to enroll in a section if they are paid up and so on and so on depending upon the number of students may be accepted the student may be wait-listed or it may be denied if the student is accepted she will be signed to seek this is the same description except this is now a description that we can implement because we have an eeeh of what the abstractions mean in terms of the application that we're trying to solve it's it's the the first step because typically you get a functional spec and you're going I don't understand that I don't understand what this means I don't say what that means so the first step is at least getting the functional specification define using words that you understand how to build and use in solving the application yes sir yeah maybe I mean if a quarter is isn't my first thought would be to say a quarter is an enumerated variable that has you know four values summer winter spring and fall and I'm not sure what else it has with it at least as far as enrollment goes yeah you you could have that I'm and that might be a division the other or you might just say I don't need that because of every course indicates when it's it's offered so typically that it depends how you're looking for it if your average user is going to come in saying what's available in the fall right as opposed to saying when is this available they're coming into a course trying to see that's it that'll be the use cases and and that will determine whether that object exists yes sir sure so the question was what about date and time date and time are great objects because you in capsule it's like what do you want from a date and time what do you want it to print out right guess what today is okay no it's not it's not going to work today but typically you see four eleven right and we go that's April 11th and every European says that's November 4th so if you because they do it differently so you'd like your object to print itself out internationally right you'd also like an object to say how many days between yourself and this other date object there's all kinds of things you could want so you're going to go down you encapsulate all of that and you now make the calls and you only have to do that once and it's in an object library and it it carries over from application application name is another good example of you know last name first name what about middle initial you know we got to change the name object because now gender can change you know things that you hadn't expected the point is you encapsulated it and there's only one place where you have to deal deal with it so you've got your basic abstractions and you know you've defined them you now kind of know hey there in into 1 or 1 to N or 1 to 1 now you want to flush it out so what you're saying really is what are the specific elements that comprise a given object of this class and are not found in any other class and and this is key object-oriented analysis stuff right you have a client which connects in some way to an object an object service the client and service the the connection can be and by the way oh it's just kind of hibernating the connection can be anything from across the net to calling into an object library to whatever the interface again if you're if you're in C++ coder or even if you're not objects tend to be divided into two things one well three things one is what attributes what physical elements do they manipulate the second is the code to do the manipulation and the third is the interface the public methods that you can call and the goal of an object is to encapsulate the implementation which is the data and the code behind the interface so you're going to be defining for every object that we looked at the set of public methods that other objects can call to to change you know to effect and use that data that's in that object encapsulation because all of this the implementation is encapsulated hidden behind the interface which means you can change the data in the code and as long as you don't change the interface nobody else breaks one of the design goals of object-oriented design is you know robustness extensibility in the face of change very easy to do that one of the goals is not performance dirty little secret right if you because you're going to be calling methods instead of going to get the data directly and that means if you're if your systems running too slow you know wait six months they'll be a fast a computer if your system can't be extended that's the thing we're trying to fix there was a question yes so this this is we're gonna look we're gonna look if we get how much time ago we're gonna get to the point where we're going to look at how this actually fits into a three tier and a four tier architecture and user interfaces are not what this is okay the the the applicant I'll talk to in a minute but the applications that we're talking about pieces that are being designed like this it's for when you say do it right it's when you say it's not to say I'm browsing all of the sections that are offered or the for that quarter for example and I'm I'm you know and I'm looking and I'm getting reviews you know of I've gone to rate my profit my review is up there whatever you know and now I've made the decision now I'm going to say enroll or buy it or book that ticket and or far away from the user interfaces which are external to what we're doing this is the back end stuff that's going to make the world work so that's and we'll see examples of that yes NFR oh well if the performance is too slow then it doesn't function right no but I mean you know not yeah it's it's it's it's it's it's important people worry about performance the programmers mostly worry about performance but when you're doing a design that's not your primary concern your primary concern is usually encapsulating things so that change doesn't knock everything everything over and here's an example right you know you've got some in a student record you've got the cumulative average right it's one of the variables inside the object and now if everybody could see that and go at it directly if you then decided no I'm going to calculate it you're going to break everybody who ever thought the cumulative average was an element in the structure of a student whereas if you encapsulated it with get cume right which is a function you call to get the cumulative average you could decide I don't want to store it here I'm going to calculate it you totally change the the code and remove the object of the the attribute from the the object and nobody else sees to change it because they only ever were calling the function to get it and the function has now changed the way it's going to get it but it still has the same interface so all of the clients never never see the change that's one of the advantages of encapsulation so having said that we're sitting looking at one of the objects that we've talked about now we're it we've stopped staring at the ceiling right now we're coming in and we're saying okay we've got this room we've defined this room what exactly is a room what are some of the attributes of a room sorry size absolutely size capacity twelth capacity would be so right the location right does you wandering around you so it has a location has a size it has equipment absolutely right and it has some other stuff it has a schedule this is great you take my course anything else actually let's look right so this is room attributes it's got a schedule it's got a location it's it's got an owning department a capacity it has equipment list where equipment is there's an enumerated type of all the equipment that we have in the mount it doesn't show a couple of things and again this isn't directly this talk but if you're looking at an object you're and you're saying I'm looking at an object there should be three things you should be looking for they're not always present but you got to consider them and it's every object you ever have one is the unique ID what's the unique ID of this thing if it doesn't have a unique ID I got to start thinking of it's an object it turns out there's one object we looked at that doesn't that's seat seat doesn't have a unique ID but it it joints so this the ID of the seat is the student in that section but there's still an ID there right if you if your object doesn't have a unique ID then it's not an object second is there's no it the capacity yeah yeah Oh in the room no I wouldn't want to you used a room doesn't really have the seats too tied to the section a room yeah that's true how could it will not have seats you everybody sitting on the floor know that but the seed abstraction is the thing that we call that ties you so it's a virtual seat and you're as opposed to sitting on the virtual floor yes there there is your China you right you wouldn't you would say a room has seats it has a capacity thank you you're absolutely correct the other thing is so that one is does it have a unique ID the second one is does it have types so for example on room there could be a lab that could be a lecture room there could be there would be different types and whenever you get into types that's the key to say oh god do I have to subclass this right because it has different kinds of types and there's ways or not have time to get into design criteria for deciding when you should subclass it and one of the obvious ones is does it kind of shift back and forth you know a part-time teacher can you become a full-time teacher then don't subclass them but but so that's the second one and the third one is state does this object have state room typically doesn't but a student certainly does enrolled or not or a section certainly does wait-listed and so on so those are the three things type state and ID and and when you look at creating objects those are some cool things to start thinking about in your objects that you define so we've kind of come from here we said okay object oriented abstraction classification we've looked at a conceptual class diagram which is the high level things and UML artifact and we've looked at a class list which is again the thing we were just looking at for a room it says take one of these abstractions and figure out all the stuff that has to be in there and now you at this point you kind of oh you've identified the basic set of stuff and you're now filling in you're getting a better idea about what these abstractions are now the next which we're not going to go to is event state diagrams where you start describing the behavior and then again when use cases come in like enroll student in section you you have to then map to the objects with the attributes and the interfaces and the behaviors that you've defined how those objects handle each of the use cases and that gets you into sequence flows well okay I don't need this anymore because I'm gonna point that okay great okay so let's let's take a look at how do you implement this stuff because everything we've been talking about has been kind of staring at the ceiling and thinking right if we can't implement it then it's like a house that we've designed that we forgot the foundation so this is in one slide right up through the 90s okay I'm Python you could add java and a whole bunch of language to and they had reasons but the evolution of the 20-year frame was all driven by object-oriented requirements if you think about it in you know the basic basic right which was the thing that you know Bill Gates is now a very very rich man what was you had a basic program a headline numbers and it got helpless and you would you would write this is where I usually use a board you would write go sub 600 and in the in the in the the code at line 600 would be a bunch of code and then you would say return this is considered a major step forward advantage from go-to right where you just go to back forth and it but the idea was to take a chunk of code and reuse it that was the original vision that chunk of code was at 600 but worse than that you could always remember that you know but what you couldn't do was change the variables and the reason was that every variable in basic was global so if you changed a dollar sign any other application or any other sub program in that application just had a dollar sign creamed it meant that you would have to when you try to resell your gosub whatever the name of it was to anybody else you'd have to say oh and by the way here are the variables you can't use which was ludicrous and so Fortran came along and Fortran said okay you know we can fix this and they did subroutines had a name that was cool but more importantly subroutines had variables that were relative to the subroutine so if you in a subroutine used the variable in a 3 if you use a variable a 3 anybody else using a 3 was not going to get hurt because that variable only had scope was only defined inside the subroutine that you that you've defined so it meant that I could legitimately write for the very first time subroutines and I give him a name I could sell him or put him in a in a library and people could reuse them it was the ability to cut a project into chunks and do some of those and deliver it have separate people delivering it and then reuse it on other projects ok and that that was the beginning of subroutine libraries and that was cool what you were doing was you're encapsulating the details of how you did it and you just had the arguments that were in the call so you it was the implementation was hidden and the interface was whatever arguments to use and whatever was going to be done to those arguments and that was the the state of things till C came along and it was genius the moment I saw how many people have programmed in C oh yeah just great so you're going to understand that what I'm about to say next I I saw this I've been programming the semi language and they and I found out what malloc was they said if you want more memory you asked Malik and I went right and I figured malloc was this ancient Semitic God Oh Malik Prius correct because because it was magic it was magic right it was ingenious ok but but more than that and more than the register variable which when I could actually put into a machine register something in a high-level language was the struct and the struct was awesome because the struct said you have a teacher what are the components of that and you could say well a teacher has an ID has a salary now in a better world that salary would require a double precision but it has a salary would be an alternative universe in addition and it has you know you could define the abstraction in the language before that you couldn't do it you had the variables you had you know we're you have to combine them into these overlapped unions it was disgusting you know you couldn't represent what a student was suddenly with see the good news was you could say here is what this student is and you can point to it you can have it ray of them you can have a rays of pointers to them they're like any other variable will actually no they're not the reason that they're not like any other variable is because you can't operate on them directly there's a thing called polymorphism which I I heard first time years and years ago there was an object-oriented conference when object-oriented was as hot as machine languages today and by the way thank you for being here the words machine language is not in this talk and yet we still fill the room I'm just I'm just so pleased but they had a parrot there and the parrot was it it could say the words it was going inheritance brach polymorphism broth and then the guy said we're not just parroting these words we understand anyway the point is that that polymorphism says a very important rule if you're an object-oriented developer which is every operation takes on meaning every operation takes on meaning from the things that its operating on and like plus you add two numbers right but it has a very different if what you're adding at two integers or two floats very different things happen conceptually it's plus right so what what you start realizing is well adding a student to a section is telling the section please add this student right and it would be good and and you're going to be using the internals of both a section and maybe a student to do that but then if any of those details change everything breaks wouldn't it be cool to have all of the data inside of a struct private to the set of operations that use it and that's what an object is basically the all of the data and the struct is now private and all of the the the methods that use it are now the public methods of that operation and can see the it always is right you know yes the public methods are the only things that can see the private parts of the object right so and it's shielded and the compiler will protect you against that so what you had in all in all these cases was it was heading toward objects right first you could cut off a piece of code in return without knowing who called you then you had a name and arguments that were your own then you had data that represented the abstractions you were thinking of and finally you had objects that combine the two to say all of the good things we got about subroutines we're now going to put all of the subroutines that had to do with this data together and we're going to wrap it and we're going to call it an object and you're going to manipulate those and and so the languages were heading toward supporting the things that an architect data and a data and systems Software Architect excuse me needed in the language it provided the foundation for the house so this is a typical use case once you have your objects and once you have your performance define and so on this question how are we doing for time we still have we almost outer five minutes okay moving through thank you okay yeah here's what you know well I got a little bit more I was I was winging it so the the this is a typical use case but this isn't really the that's critical to what I wanted to say this is what I wanted to say where is this stuff working right so you've got a three-tier architecture and your users are out here and they're going into us a web service and typically there were servlets and how many people know what servlets are okay less but still good it's threads and it operates in a web service and so out here you're gathering things like user ID and password that set up a session and then you're going to say oh by the way you're going to one of your application you're going to be sitting at your terminal or your registrar desk or tablet you're gonna go register me in sections you know see us 2807 and that's going to come across the internet and it's going to be validated here in in tier into this is Tier one it's just here - and what could be bringing this over is JavaScript movie on Rails whatever over here for the most part you're now and and so that that will then put a stack of things to do there's a thread sucking that off and shooting it out to tier three which is the application service what comes across this is typically rest and Jason four between the tiers between the web service and the app service and they had the author of Jason speaking yesterday was cool and then what you get in is basically enroll student ID in section so that these are strings that's all it comes over that's your command that's your use case enroll that student in that section the client is the main line of the program this is an application service and that's the thing that's that people a lot of people don't see the client receives the commands coming in from the web service the requests coming in each request is a use case it's a thing that and there's maybe 30 of them for this particular application oh yeah here we go use cases assigned teacher to section assigned room those are commands coming into our applications the client is the main line and to do enroll student in section what the client says is it asks the college get me the student object given the ideas one two three four then it says to the college get me the section whose ID is CS 2873 it's got both objects and then it says to this section enroll that student the client is the ones making commands on the object library the thing to understand is that the object library unlike a regular object library like date where you say what's the date here's the date here you say enroll students section and it looks like a pinball game objects calling objects calling objects to to do that enrollment because you're doing all the things in the use case are the schedules okay is the student paid up you know it is the student qual to have all the prereqs all of that's being happened because we've understood and we've designed the objects to handle methods and most of those methods are being called by other objects and eventually what comes back is yes or no okay but so that's and now the question is this is one application in an application service in an enterprise with many many applications how do we connect it in to the other applications in an enterprise environment there's only a couple of more slides so you think about the things that we draw on in student enrollment you know there's a here are some of the applications there's a ton of applications even in a simple college right there's a student information system there's a student portal there's a thing that schedules classes there's facility management system that takes care of the rooms you know this employee management system that has things about the teachers all of this we're going to be drawing on this on how do we get all the information that we need about a student we have a student's ID so we can go and get the information we need about the student because somehow we're linked into these systems and there's two ways to do that one is through a met it's broker which involves middleware where we make a request and the message broker figures out where it goes this is an architecture where each application has its own data and the only way you can get at is through requesting it and so we are basically sitting in an environment on an application server where we are calling the message broker to call other application servers giving them the requests the one thing you know if you're in application servers the requests wouldn't have gotten to you if it wasn't valid so it solves a lot of the security issues that you might otherwise see and also we have things like the things that we maintain other schedules and who's in a room so the sections in a room and so on and there's an emergency contact system that says you know armed shooter in school who's in that room and they want they're gonna use our stuff our schedule because they know that room has a schedule it's this section okay who's enrolled in that section they get data from us all of these things play together and this is the other way to do it you'd have a common database in tier 4 and your applications make it's easy to make SQL requests to get the data it's not so easy to tell the database I'm updating these fields but I'm so but but this is a second alternative to to you know if you enrolled in a section with changing data in multiple places you know like you you're you're being billed for it your schedule is changing the section seat is filled all of those with changes that are recurrent and have to be reflected in a database and they can be reflected by the individual objects that on those databases or they can be reflected by you going into the database system so how to become a software developer there's exactly two more slides this one in the next one which is a Lollapalooza so the the software developer you might start with getting Opie programming skills learning about design patterns and then everything a Software Architect is by definition in one domain if you're it you need the adjective you are a retail software architect you are a travel industry software architect because you're architecting in a space of applications what I just showed you was something that an educational software architect would live and breathe but other other industries wouldn't know and so you know you'll you are you you are you know how to design houses or you know how to design bridges but the two don't necessarily carry over I wanted to show you I'm hoping this is the next slide it is so here is the model for retail if you are a retail architect you live and breathe this stuff and and you can this is where I wanted the light pen of course but what the help you look at this and you go what is this these are the systems and the data stores for the things that are in retail and in architect knows this and knows how to fit stuff in so here's you can look at this thing with a hundred things coming out of it that's point-of-sale all God's children want to know what happened at the point-of-sale all the systems want to know because you're going to decrement inventory you're going to reward the clerk who's really moving sales through if it's a if it's in a store you're gonna want to deal with coupons you're gonna want to deal with loyalty cards and discounts you're gonna want to deal with you know again keeping track of inventory price optimization we've detected that it's raining outside so let's increase the price of umbrellas yeah hey that just did it by itself that must be my time has run out but but that last slide was supposed to convey the fact that everything we're talking about working your way up to Software Architect it happens inside of an industry and you become and your career path is in that industry so you know you you better pick one and they're different they are very different and the 30 seconds left and I'm going to do this because it's interesting you know like retail is is just kind of basically a bunch about a bunch of white guys smoking cigars okay education and health care are very different you've got people in those industries who care and want to make a difference and they also have one thing that other industries don't have the end users cooperate if you're an insurance or you're in travel or so on and you find a good solution you don't tell anyone whereas in education and health care you're up on the stage talking about it so it's a it's a you know again it's a good one to do you know and and how do you in the other one how do you how do you tell if you you're talking to an extroverted research scientist and the answer was he looks at your shoes when he's talking to you instead of his own point is you can find out a lot different different industries and track different types so the last point is if you're good looking it's become a software architect pick your industry and then start working your way up and that's that's how it's done thank you [Applause] [Music]

Channel: Silicon Valley Code Camp

Views: 22,830

Rating: 4.9478259 out of 5

Keywords:

Id: mCM6QVHD08c

Length: 72min 57sec (4377 seconds)

Published: Fri Dec 13 2019