Category: Sin categoría

Strong entity types

A strong entity is one that doesn’t depend on the existence of another entity. For each strong entity create a new table. This relation will contain all simple attributes of the entity. For composite attributes such as name only include its simple attributes such as first name and last name.

Weak entity types

Also create a table from every weak entity. But the primary key will be composite. Consisting on the primary key of the strong entity and the weak entity.

Binary relationships

one-to-many (1:*)

The one to many is easy. The entity on the many side will have a foreign key. This will be the primary key of the one side. For example: if a cashier registers many sales. But a sale is registered by one cashier. The primary key of the cashier; let’s say cashier_id, will be a foreign key in the sales table. Because if it where otherwise, you will need a list of keys in the cashier table consisting of all the sales that this cashier made.

One-to-one (1:1)

The one to one relationship is a little bit more complicated. It will have three cases.

(a) mandatory participation on both sides of 1:1 relationship;

(b) mandatory participation on one side of 1:1 relationship;

(c) optional participation on both sides of 1:1 relationship.

mandatory participation on both sides

In this case both entities are merged into one table. We choose one of the primary keys as primary key and left the other one as an alternate key.

mandatory participation on one side

This case is a little bit like the one to many case. The entity that has mandatory participation will have a copy of the primary key of the entity that has optional participation. Why? This is because mainly we don’t want null values in our tables. So the mandatory entity we know will exist and thus its primary key. So if the optional exists it will always have the foreign key of the mandatory entity. If it were otherwise the primary key of the optional would be referenced in the mandatory entity. And the optional entity may not exists. So there’s a risk that there’s a null value on the mandatory entity.

optional participation on both sides

In this case one can choose. However, if we can identify a way that would lower the risk of null values. For example; let’s say that a company has cars that the staff can use if they choose to. A car may or may not have a staff. And a staff may or may not use a car of the company. However, the mayority of cars have a staff. And only a privileged minority uses a car. So in the cars table if we reference the staff id that uses that car there will be a few null values. If we would do otherwise, we would reference the car id in the staff table. Since a lot of staff don’t have a car associated with them then there will be a lot of null values in the staff table.

Many-to-many (*:*)

This is different from any other binary relationship. Becuase we create a completely new table. The primary key of this new table will be a composite key that will include the keys of both entities. Likewise, there will be a foreign key for each entity’s primary key.

References

I retrieved this information from the book of my relational database course pages 530-536

Database Systems A Practical Approach to Design, Implementation, and Management. SIXTH EDITION

Thomas Connolly adn Carloyn Begg

What is LISP?

When I first started reading I knew that Lisp is a programming language. But I don’t know more things about it. So I decided to investigate a little about it before I read the whole essay. Lisp is actually a family of programming languages. It is the second oldest high level programming language, Fortran is just one year older.

Standardization

One of the things that Lisp did right was it’s ability to became standardized. This effort started wy back in the early 80’s. There were efforts to make a standard version of Lisp even outside the US.

Good Performance

Many Common Lisp implementations have multitasking and non-intrusive garbage collection. This made Lisp very competitive in terms of performance. These features were regarded as impossible on stock hardware ten years ago. Lisp was competitive even to C.

Good Environments

In this essay. The case is made that modern programming environments are a result of the Lisp and AI tradition. Some of the examples listed on the essay are: the first bit-mapped terminals, the mouse pointing device, full-screen text editors, and windowed environments. These all came from laboratories engaged in AI research.

Good Integration

C, Pascal and Fortran can be invoked from Lisp code. Likewise, these programs can invoke Lisp. Such interfaces allow the programmer to freely mix foreign and Lisp functions.

Object-oriented Programming

According to this essay Lisp has the most powerful object-oriented extensions of any language. One can do things such as multplie inheritance that Java can’t do but C++ can. It has First-class classes and First-class generic functions. Along with a lot of other features. The author predicted that this Lisp will be the first standardized object-oriented programming language.

State diagrams

State machine diagram are usually implemented to describe state-dependent behavior for an object. An object responds differently to the same event depending on what state it is in. That means that it is important to define the state that you object is in to accurately predict its behaviour.

What is a state?

A state is an abstraction of the attribute values and links of an object. Sets of values are grouped together into a state according to properties that affect the gross behavior of the object.

Package diagram

In this technique each class is put into a single package. If a class wishes to use another class in the same package, all is well. If a class wants to use a class in a different package it must draw a dependency to that package. The overall picture of the system is the picture of packages and their dependencies, the aim is to keep the dependencies down to a minimum.

Component Diagram

Component diagrams are used to visualize the organization of system components and the dependency relationships between them. They provide a high-level view of the components within a system.

What is a component?

The components can be a software component such as a database or user interface; or a hardware component such as a circuit, microchip or device; or a business unit such as supplier, payroll or shipping.

References

http://www.cs.unc.edu/~stotts/145/CRC/package.html

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-state-machine-diagram/

The Easy Guide to Component Diagrams

This chapter

This chapter has been my favourite chapter so far. It’s been the one that I’ve acquired the most knowledge about things related to a proyect I’m involved with outside of school. I’ll later talk about what was the most useful information for me in this chapter.

Good things about this chapter

I like the case example that this chapter uses. The other ones have felt kind of gimmicky. They were kind of boring and I didn’t think they would be real applications that I could be involved in. This one feels a little bit more real. It’s kind of complex in my opinion because the initial vision statement really felt very ambiguous ang general. It feels like a really big project. And I like that. I’m very interested to see how they’ll tackle such a large project.

The project that I’m involved in

Right now I’m involved in a project outside school. It’s an app that my team has been developing. Right know we’re more in the testing phase. This chapter has been really useful. Reading this chapter I was always thinking how we could have done a better job if we thought the way that the book encourages us to.

Start thinking big

One of the principles that the book talks about is that you always have to start thinking about how your app works in a larger scale. I think it is really useful for me because I always want to rush it and start coding right away.

What is it?

UML is a modeling language, these things are mainly used in the field of computer science and enginering for designing models of new pieces of software.

UML

Easily one of the most famous modeling language. UML is short for Unified Modeling language is a standardized modeling language consisting of a set of diagrams. UML is meant to facilitate communication and reduce confusion among project stakeholders. It helps developers in the task of visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.

Why use UML?

Companies now are larger and more complex than ever before, not only that but our code is becoming more and more complex. Companies look for ways to automate the production of software and to improve quality as well as reducing costs. The importance of UML can be boiled down to one work. Comunication. At first one might thing that comunicating isn’t that hard. But someone who has experience in sofware development can tell you how hard it is to communicate even in a small project. The difficulty arises because we must communicate with multiple developers. The UML is important because it can help software developers communicate. We have to use it in a way that helps communication and does not hinder it.

Sequence Diagrams

A sequence diagram, as its name sugests, describes the order in which the interactions between objects take place. Sequence diagrams describe how and in what order the objects in a system function. These diagrams are widely used by businessmen and software developers to document and understand requirements for new and existing systems.

Class vs Object diagram

At first glance you might thing that they are the same thing. But they are completely different things.

A class diagram depicts which objects your program consists of. So for example. The image below is a class diagram I did for my mid-term Object Oriented Programing class. It represents the Contact class. You can see first you write the parameters of the object. A minus sign stands for private and a plus sign stands for public. The next thing you have is the name of the parameter. Then the type. After the parameters we write the class methods. First we write a plus or a minus sign, like the parameters, then the name of the method. Inside the parenthesis are the parameters it recieves. And after that is the return type.

In contrast, an object diagram describes the interaction between the objects, also it can be like a snapshot of your program at a point in time. For example: the diagram below is an example of the class Customer in a certain point in time. It shows the the values of the paramteres of the customer id and the customer name. As well as his different orders.

References

UML Diagram Types Guide: Learn About All Types of UML Diagrams with Examples

https://www.sqa.org.uk/e-learning/SDM01CD/page_08.htm

Change – my experience

This chapter is all about change. Sometimes change to your code can be relatively easy. Sometimes, you feel like you broke your application entirely. I think one basic type of change is just refactoring your code. For example: I am currently working in an app. I’m in charge of the API. I use MySQL so I write a lot of queries. Most of them are simple. However, there are some queries that require a lot of other quieres.

In the beginning I only had simple queries, so when a query was succesfully made I made a callback function to retrieve the data from the query. When you have multiple queries this starts to become really messy. A calback function within a callback function within a calback function is not easy to read or to debug. The obvious solution was using async await. This really made the code a lot easier to read and debug.

This chapter

This chapter also dives into class diagrams. It talkes about concepts that are really useful to keep in mind. Such as aggregation. I like the cheat sheet that the book includes. I helps you contextualize UML in an eviromnent that I’m used to work in.

Aggregation

The book uses the concept of aggregation. It is shown when the UML of ricks program is described. To say that something is an agregation of another thing the line with the diamond is used. Agregation is an association. It means that something is made up (in part) of another thing. The example that the book uses is with the instrument astract class. The concept of an abstract class will be explained shortly. An instrument (in ricks program) has assigned to it an InstrumentSpec. Because an instrumetn needs specifications in ricks program. To be precise one instrumentSpec.

Abstract Class

An abstract class is a generalization of a class. It means that it has subclasses that share a common behaviour with eachother. It’s important to note that an abstract class should not be instantiated. It is just used as a common template between classes. The example that the book gives is with the instrument. A mandolin has a lot of similarities with a guitar. So the abstract class from which both classes inherit from is instrument. An instrument alone can’t be an object. You need to specify what instrument.

New kind of thinking

It is really interesting to think about your application in a real world scenario. I am currently developing a mobile app and so far we’ve only tested it in a controled environment. As a developer, you know how your application works and you know the steps to replicate a bug if you do some silly thing and it is the case that you ignore it thinking that your customer wouldn’t be dumb enough to emulate that. But I don’t think that’s the kind of thinking that the book tries to encourage.

Bark recognizer

I really didn’t like the implementation of the bark recognizer. I don’t think the software should be part of that process in the first place. The hardware should be in charge of this task. I think the hardware should only be capable of listening to sounds that have high intensity. That way, only dogs that are close enough to the machine can be recognized.

Delegation

It is good to review the concept of delegation. I understand the concept of delegation. However, the implementations are not always clear to me. Delegation means to pass the work onto another class. This with the purpose of making your code independent of other classes. So changes on one object don’t require changes to other objects.

What is it?

A modeling language is mainly used in the field of computer science and enginering for designing models of new pieces of software. It is also used to design systemas and devices. A modeling language uses textual and graphical tools to explain and define these sort of things in order to better explain them better.

Why are they important?

As the functional and operational necessities on these systems are expanding, the difficulty to make them is turning into an important factor. As an outcome, these kinds of systems may only be able to be made by the unified effort of people and by the division of labour. Reducing this complexity is very important to succesfully developing whatever system you want.

UML

Easily one of the most famous modeling language. UML is short for Unified Modeling language is a standardized modeling language consisting of a set of diagrams. UML is meant to facilitate communication and reduce confusion among project stakeholders. It helps developers in the task of visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.

References

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-uml/

http://www.informit.com/store/unified-modeling-language-user-guide-9780321267979

‘Real’ Programmers

The author sounds like a stereotypical old man who thinks everything good is from his generation and everything else is just garbage. This is my first impression of the essay. However, it’s difficult to criticize this macho mentality because back then it was really hard. The story of Seymour Cray is amazing. To program an Operating System on your own is a feat in and of itself. But without errors is just unheard of.

The Early Hackers

It’s really interesting to see the history of the word hacker. Right now the word has a really skewed meaning that hollywood films gave them. It’s also interesing that research in AI dates back to the 1980s.

It’s also intersting to know a little bit more about LISP. I’ve heard some things about this programming language and it’s intersting for me to know more about because it really was (and still is) an important programming language

The Rise of Unix

This chapter talks a lot about things that I actually know. In the previous chapter there was a lot of talk about ITS and other computers from the MIT, they talk about how big and famous these are but I have not heard about none of those machines. However, in this chapter they talk (obviously) about the ‘C’ programming language. I really like that they talk about C because I can relate it with my Operating Systems course. The Operating System that we are using is compiled also in C.

The End of Elder Days

This chapter was really boring. Nothing in the chapter really captured my attention. The only cool thing about it is the recursive acronym. UNG. I’ve never heard about a recursive acronym.

The Great Web Explosion

It’s interesting that in this chapter the focus is the rise of the internet as we know it today. It feels like it was a long time ago but Amazon was killing it by 1999 Amazon had 1.6 billion dollars in revenue.

References

Amazon vs walmart revenues and profits 1995 2014 from revenuesandprofits

My experience with change

On this chapter we saw how requirements ultimately change. This is an inevitable part of software development. I’ve been developing an app this winter and I’ve seen how much the requirements have changed, even before releasing the app. This happened to me when I realised that one of the requirements conflicted with another requirement. That’s when I decided to call my friend who was responsible for the app and asked him about it. He decided to change requirements that we have already established. Then I had to change a lot of what I’ve made.

Alternate paths

I liked the “interview” of the Alternate path. I had the same thoughts when I was reading the use case. If the bark recognizer opens the door for them, why bother with the alternate path of the remote control? But it is true that without that alternate path the use case would feel incomplete . The analogy with the credit card use case is very good. Because just like the credit card, the bark recognizer can fail. To be solely dependent of the bark recognizer doesn’t make the program robust. So it makes sense to have that alternate path that takes care of that potential problem.

Retrieved from https://www.bridging-the-gap.com/what-is-a-use-case/