welcome to the course introduction of 1dv 607 object-oriented analysis and design using uml in this lecture i will try to place the topic in the everyday life of a developer explain what analysis and design is really about and what object orientation is it's not meant as a replacement for the chapters in the book so read the book the course literature and use these materials as a complement so maybe then first of all we should place analysis and design in the everyday life of a software developer but then maybe the question becomes what is software development you can think about this for a few minutes and try to think about your own definition of software development what is software development for you there are probably many definitions going around but uh think about it for a little bit and i will present mine uh so when i think about software development i think about people collaborating so as a software developer you need to collaborate with a lot of different people so of course your co-worker your fellow developers are people that you need to collaborate with and also you need to collaborate with other developers that make the libraries that you use that make the modules that you import into your project you need to collaborate with them and understand how theirs their libraries are supposed to be used you also need to collaborate with end users to understand what they want from the software or what the market wants from your software so collaboration is important i think one of the fundamental aspects of professional software development at least i also think that when you do software development you create something you create something new something that has not really existed before maybe it's new for you in your little world but uh it can also be something that is really novel and new if you're working on a new feature for example in in a software it's something that has not existed before really if if software development was just manufacturing we would just copy software and if there was no novel novelty in our software it would be easier to just copy and already existing software because that is essentially free we also need to have a need for the software that we develop so someone maybe ourselves or or a market or maybe you even have a customer or end user for your software so they have a problem you need to fulfill this problem you need to solve this problem for for them and i also think that uh another key aspect here is that the world of of software development is rapidly changing we have new methods we have new libraries we have new technologies we have new platforms we have everything is changing and the requirements for our software the the needs that need to be fulfilled are also forever changing so my definition of software development is the collaborative creation of software that fulfills a need in a novel way in a rapidly changing environment maybe not the best definition but it's my definition at least so now that we know what software is kind of at least we need to have a way to to manage this creation this novel creation in a rapidly changing environment and we need to be able to collaborate with a lot of people so it's not that easy to develop software it's quite complex and to handle complex things we need some form of process so my next question is what do you think you will do at work so you will graduate here in in maybe two or three years what what do you think a working day will be like what will you actually do or what would you like to do uh maybe that is the best a better question you can take a few minutes and think about that so uh basically i hope that you answered uh something about programming or coding that you would like to to to solve problems and by by implementing by programming because that's what your education is is a lot about i think uh but in order to be able to know what to program you cannot just randomly write if statements i guess even though it could be a fun exercise you need to have some kind of idea of what it is that this software that you are supposed to implement is supposed to do what are the requirements of the software what what's the problem here that's supposed to be solved uh in some cases the problem is also not trivial it's maybe an area that you're not familiar with maybe it's a banking software that you're supposed to develop and you you need to understand everything about stock markets and option trades and interest rates and different types of accounts and a lot of laws and regulations and things so you need to understand this area also that you're supposed to work in uh so you do some requirements to understand what it is you're supposed to do you do some analysis to understand the problem area and when you have understood the problem area to some degree at least then you can start thinking about all right how do we solve this from a technical standpoint maybe you are 50 programmers how can we develop this software efficiently using 50 programmers maybe our five programmers then you have other needs for a technical solution maybe what libraries are you supposed to use and how are they supposed to work together with your implementation so you need to have some common ground of the technical solution in order to be able to implement things efficiently then of course you need to test and you need to ship the software to your uh end users in some way and of course you will be googling stack overflow and struggling with git in the processor hopefully having a lot of coffee and fika also so this process the basic development process that you can find in many areas is requirements analysis design implementation test and deployment and if you do this one step after the other it's called the waterfall model we won't be talking really anymore about that because it's an ancient model that doesn't really work that well for software just because of this rapid changing environment instead we have been focusing on iterative and incremental models the recent recent years it's uh you can find a lot of different process that has at heart the the idea of an incremental and and iterative development scrum kanban unified process what not the idea is that you work with all of these activities a little bit every day during your working your working time in a project so do a little bit of requirements a little bit of analysis and design a little bit of implementation a little bit of testing and deployment so instead of doing all the requirement first we do what's important first and we add things later as we go along and we change maybe things as we understand the problem better because we have deployed it to the end users so they can try it and they can give us feedback so we can iteratively incrementally grow the system over the time of the project this has proven to be a much more successful way of developing software so you come into your office you sit down and the first thing you need to do is figure out what to do that day so you need to work read some requirements work something with with the requirements you need to understand the requirements know how they fit in into your overall understanding of of the problem that you are working on so you work a little bit with requirements you work a little bit with analysis then you need to understand how am i supposed to implement this so you need to understand the technical aspects of the software you are working on also how does this feature fit in what is the most efficient way i can implement this without destroying something else without impacting some other part of the system so you work a little bit with the sign and maybe now it's time for the first vika break and you head off to the coffee room and you discuss these things with your fellow developers and kind of get some feedback on your ideas for for how to to implement this and uh maybe you discover that you have misunderstood something about the problem and it's really not supposed to to be in that way and maybe you even need to to call up your end user and ask them about the requirement or the product manager about the requirement or something like that anyway after the feed guy you feel more secure about your technical solution so you do some implementation and you write some test cases also to support this implementation so that you know that you are not breaking anything and you know that your feature at least works on your computer before you commit it to your branch and you integrate the branch in in a merge request and it finally gets deployed uh towards the end of the day to the end users and so on and so forth the the system incrementally grows a little bit for for every day that passes and you work a little bit with requirements analysis design implementation test and deployment every day these shapes are supposed to communicate a little bit about the focus of each activity during the process so in the beginning it's naturally that you probably spend more time trying to understand a little bit more about the requirements and the analysis and maybe the technical solution make some decisions here during the middle of the project there is a lot of implementation going on uh testing effort maybe becomes more and more towards the end because there is more of the system to test and vice versa with deployment uh at least this is kind of like the traditional a little bit blocky view that i have done in this slide but you you probably get the the main idea here uh something that has happened in recent years is the automation of different steps in this process so automation of deployment is is quite common in our days and maybe that hasn't skewed this diagram in some way maybe there is actually more effort for setting up the automatic deployment in the beginning of the project this is more of a technical thing now than a manual laborious thing um and also test automation has has really come a long way in in the last in the last year so maybe this this diagram here is is starting to look a little bit different really one thing that has happened quite recently with with open ai is that they released a demo of their codex implementation that is automatic code generation based on natural language input so you basically can tell the ai what you want from an implementation and the ai produces the source code for you so you don't need to google stack overflow for doing these kind of mundane boring tasks in implementation you can just tell the ai i would like this to happen in this function and the ai will present the source code snippet to do that this is really interesting i think and it it actually shifts the focus from knowing the details of a programming language and how you really program these kind of boring functions that you often have kind of like 90 percent of programming is often more or less the same things over and over again and and can let us focus more on how are we actually going to do this in an efficient way in a novel way how are we going to solve the problem in a good way so maybe this will shift focus even more towards analysis and design if implementation can be more or less automated interesting we will see what happens in the coming years i guess so a little bit about analysis and design then so uh in this course we will do domain modeling as analysis and domain modeling is something that we can use to understand the problem better we understand the requirements in a kind of a context so we don't look at a requirement in isolation we look at a bunch of requirements and try to create a model that can support these requirements so we can understand the problem better we can use the domain model to visualize and to communicate this understanding to someone else or to ourselves in when we need a reminder of we get a common vocabulary we get a common set of rules for this domain and maybe we can even reuse this in coming projects for the design we will create something called the design model and uh basically it's a a technical solution uh for the requirements that we are working on so uh it's also something that we use a visual model for and we use it for communication so that we as developers can understand how we are going to collaborate how we together are going to develop a software system that that works and so we have common solutions that so everyone can understand them we have standards that we follow so basically that's analysis and design analysis is what design is how so object orientation it's basically a coherent way of doing analysis design and implementation using the same ideas the same way of thinking about the problem and this is very powerful because it creates a mapping from the requirements the entire way to the implementation so we can find commonalities so we can understand how the implementation works by knowing something about the problem domain about the requirements about reality one of the main ideas about object orientation is also that it should support the human way of thinking about things and basically this boils down to three three things it's abstraction as humans we like abstraction because that lets us focus on details when we need them and not add them when we don't for example i can ask someone to go and get a cup of coffee and i don't need to tell that person the exact way to the coffee machine and the exact way to get the coffee the exact mug to get and things like that things that are not important should not need to be added so this is something that object orientation supports object orientation also supports hierarchies basically there are two types of hierarchies that we human humans use whole and part hierarchies that is we construct things based on smaller things and we put these together and we often slap an interface on the thing so that it can be useful at a high level of abstraction we can for example imagine a car a car is created using many different complicated parts that can hardly be understood in detail at least by a single human anymore but almost any human can use a car for what it's supposed to be used for we can drive a car using this common interface of a steering wheel and some gear shifts and knobs and buttons so abstraction and whole part hierarchies another way we use hierarchies as humans is this is a kind of hierarchy so we understand that a dog is a kind of animal and a monkey is a kind of animal and we can understand our reality based on these types of hierarchies that we that we quickly build inside our minds finally we have the idea of encapsulation that an object owns its own information of sorts so if i ask someone to change his or her name it's up to that person to do that so i send basically a message to the object please change your name to something else but it's up to that object to accept this or not so as a another object i cannot interfere with the other object's information it's encapsulated and owned by the object itself this is also something that's supported and quite important in object orientation so using object orientation we can get a shared vision of a problem and a solution we have this common vocabulary and we base this off reality and object orientation is supposed to make things easier for you if it makes things harder for you you're probably not using it optimally throughout the course we will be using a small subset of the unified modeling language the uml is a visual modeling language where we create different diagrams showing our models visually visual modeling has an advantage in that we are quite visual beings and we like visual information we can spot strange things in visual images quite quickly while looking at text for example we are not really that fast at reading so we tend to focus on visual models so that we can show things to our peers or to ourselves in in some time we will be using a small subset as as i said we will be doing class diagrams object diagrams and sequence diagrams so it's um not really that advanced the language that we will be using so let's take a small example we start with a requirement because that's where we need to start and this requirement is small and quite easy and maybe by reading it you get this mental model inside your head of what this is all about you get some idea of the items that are used in this small game and what's really happening here requirements are often behavioral that is they have some description of what is supposed to happen in a certain situation maybe they even have a flow of events that that happen in sequence so uh requirements describe the behavior of the system to complement this behavioral review we do the analysis the domain model so we create a structural or static view based on our requirements in this case we only have one requirement so it's a little bit easy but as you see here we have made some decisions or found some problems in our requirements when we try to make this analysis so we understand that we have player we have a dice game and we have dice classes and these communicate with each other in some way and we need to keep track of of the dice is inside the dice game and we need to know the player that plays the dice game uh but looking at the requirement we don't really know that there are two dices and that the number of uh faces on on the dice are our six faces uh it could be something else of course but when we build our mental model it's quite easy to to jump to conclusions and make assumptions uh so doing the analysis we can realize where we have done some assumptions and typically this is a very good thing if you find things that are wrong with your requirements while you do your analysis you're doing it right and then you need to go back to the requirement understand it better or ask the person that actually stated the requirement from the beginning are we supposed to use two dices are the dice is supposed to have be have six faces after we have understood the requirement we have done our analysis we can move on to designing the behavior of the system and now we are talking about objects here and we can see that we have five different objects a program object a player object a dice game object and two dice objects the program object is a little bit special because we couldn't find a class for that object in in the analysis uh it's a technical kind of object that is needed for the program to work and that's quite common for the design here we introduce software things things that are not really part of the problem per se but is part of the technical solution you can see that the objects send messages to each other and they send these messages in sequence so that we have a sequence of messages that are sent to the objects so that the requirement can be fulfilled for example the dice game tells the dice to roll itself and it collects the value from the dice and it returns true or false based on this condition if the sum is seven and the player outputs something on the screen for the end user to see and we can also take a look at the structural design view here a class diagram for for the design it's quite similar to the analysis uh in this case maybe a little bit more detailed only because we have added these messages that needs to be sent between the objects so that the requirement can be fulfilled what we can see here is that we have the same concepts in the requirements in the analysis in the design both the behavioral and the stat static side of the design so we get this advantage by thinking about objects thinking about the classes of the objects and of course also we have the implementation where we have the dice and the player and the dice game so by having all of this we get this mapping between the problem domain between the problem area and the actual implementation so how do we do this well we use our experience and if we don't have experience ourselves we need to use guidelines patterns and principles that is the experience of others so this is basically what we will be doing in this course we will be learning guidelines patterns and principles on how to create object oriented models for analysis and design that then can be implemented and create a good implementation a good implementation is something that we can discuss what that is but typically we are talking talking about things that it should be easy to change changes should not affect other parts of the system that are not related to this change we should be able to divide the work among several developers we should be able to understand the system as a whole and as the individual parts object orientation has received a fair bit of criticism and i think that's good and in some cases and it's the criticism is perfectly valid this is not a comprehensive list of criticism but some points that i like to to discuss a little bit so the first thing is that inheritance is hard to get right and i agree with that statement it is hard to do inheritance in a good way and i also think that it has been downplayed quite a lot in recent design thinking when doing object-oriented designs uh basically in this course we will only use inheritance if we feel that we have some some opportunity in the source code to do uh inheritance we have some duplicated code in two classes that are common they seem to have some common base then we can create a new base class and inherit the the common implementation from that i think that's the probably the best way to to try to do inheritance it's super hard to do inheritance from just analysis and design and not doing any implementation so uh well object orientation is of course not a silver bullet no method is a silver bullet no process is a silver bullet no language is a silver bullet you can write perfectly bad programs in object-oriented programming languages you can do perfectly bad designs even though you use the uml or this tool that you have you need to be a good developer to develop good software and you can only become a good developer by training so just using a method will not save you in any way also this thing about object orientation that it's supposed to mimic reality well it's it's not always all problems have have a base in reality or are suitable for being implemented as they work in reality uh software is software and it's special because it's soft so in some cases it's maybe better maybe from a performance standpoint to do things uh differently and not do it as it works in reality uh can be a little bit of a lost opportunity if we are kind like locked into how reality works and that's how our software is also supposed to work i think that's an interesting criticism to object orientation spending too much time on diagramming is of course a waste at doing these detailed blueprints for the complete systems it's not realistic to do in real projects especially not in large software systems you need to spend your time wisely and do the analysis and design of the parts that really matter as and especially if you're supposed to document this in a diagram because doing diagrams takes a lot of time and that time needs to be well spent so think in in reality you need to think once and twice about what the purpose of the diagram is i don't think time spent on analysis and design is a waste per se and you always do analysis and design maybe you do it in your head you do it in the discussion with your colleagues then you do an analyze and you design things so i think this is a criticism towards the waterfall thinking about we need to do a complete blueprint over the whole system before implementation can start kind of thing something that some other thing that is quite tricky in object oriented implementations or designs is state management and this i think is because objects are most often shared between between functions or methods so if you send an object as a parameter to a method it's actually a reference to to an object that exists in memory and if if you send the same reference those all all point to the same object and this can be a little bit tricky at times because sometimes you don't want to do that sometimes you want to copy an object and there is not always it is not always clear on when you need to do a copy or when you can actually change the state of of an object and it can be a tricky to manage that and the confusion often gets even more so because you have these primitive data types often in object oriented programming languages that are always copied so objects are always references primitive data types are always copied and that's a little bit strange too many so you need to manage your state even though you have this encapsulation and thing going on you need to really try to use that as good as possible so my goal is of course that you should become better developers by attending this course and we will practice a lot of analysis design and implementation during the course so that's it for now bye-bye you