Modeling Languages and Tools

--Originally published at Hackerman's house

A modeling language is a graphical or textual computer language that is used to design models of new software or system.

Graphical modeling

Graphical modeling languages use diagrams, symbols and arrows to represent relations, real life concepts or even steps.

The most popular is the Unified Modeling Language (UML) this is also the most popular modeling language in general. Thanks to its popularity there is a lot of software that supports this language.

Another one is the flowchart, is a diagram used to represent an algorithm, workflow or process.

Both of these languages are supported by https://www.draw.io/ 

Textual modeling

The textual modeling languages are formalized natural languages. TMLs have the ability to describe whole software. The language has to be readable, this is really important because is common that the programmer needs feedback from the user, the model needs to be easy to understand. It is also important that it is unambiguous.

Some examples of these languages are, PlantUML that is an adaptation of UML into a text only format. TextUML does not suppose the user knos UML concepts, it requieres a large amount of information about classes and relations. Umple is model-oriented programming, it is integrated in Eclipse IDE.

Writing

Photo by Chris Campbell

References:

Martin, M; Macek, O (2012) On General-purpose Textual Modeling Languages, recovered from: http://ceur-ws.org/Vol-837/paper10.pdf

Unified Software Process

--Originally published at Computer Systems Engineering

“The Unified Process fits the general definition of a process: a set of activities that a team performs to transform a set of customer requirements into a software system. However, the Unified Process is also a generic process framework that people can customize by adding and removing activities based on the particular needs and available resources for a project.”  (Scott, K. 2001)

With the previous definition we made clear that it is not just a process, but a framework that can be modified to fit the needs that we have, it is an iterative process that allows an increasing understanding of the problem through refinement each time we go around in the process.

We can visualize the Unified Process as the image below:

Development-iterative

 

We can see the discilpines like Business Modeling, Requirements, etc. and we also can see the 4 main phases in which it is divided: Inception, Elaboration, COnstruction and Transition. Different amounts of work for each discipline vary depending on which phase of the developement we are in, we can see that symbolized in the image as the area that covers each respective space.

Let’s take a look into each discipline:

  1. Business Modeling: it focuses on understanding the organization and how the way this one works may impact the software that is being developed, taking into account the enterprise rules, mission, vision, organization model, etc.
  2. Requirements: listing the requierements like in any other process but focusing on making them in the form of use cases or UML models.
  3. Analysis and Design: Here we understand and analyze the requirements for the system, define an architecture, conceptualize a prototype and focus on the design of our system.
  4. Implementation: it consists of coding the system, the fun part 🙂
  5. Testing: this focuses on assuring the quality of the software, we
    software-process-models-36-638
    Continue reading "Unified Software Process"

Use Cases

--Originally published at Hackerman's house

Use cases is a methodology used to identify, clarify and organize system requirements. Use cases describe the step by step process a user goes to complete a goal using a software system, each use case has an specific goal and it has to consider the things that can go wrong, creating this way not only one path for the user but many paths.

Main characteristics of a use case:

  • Organizes functional requirements
  • Models the goal of the user
  • One main flow of events, and other possible ones (alternate courses of action)
  • Multi-level, this means one use case can use the functionality of another one

21 Steps to Success

Photo by Bernard Goldbach

How to write a use case

You need to have a clear actor, and describe the scope of the use case.

Describe the set of steps the actors take to accomplish the goal of the use case. In case there are alternate flows you have to describe it as well. There is another type of flow, exception flows are the things that prevent the user from achieving their goal, this steps should also be in the use case. The alternate and exception flows must be marked as not part of the main path.
Path less travelled

Photo by Kate Rusell

References:

Brandenburg, L (2018) How to write a use case. Bridging the gap. Retrieved from: https://www.bridging-the-gap.com/what-is-a-use-case/

Use Cases

--Originally published at Computer Systems Engineering

Use cases are a tool for organizing system requierements when we want to develope a program. A way to define what a use case is a descripion of all the ways that the user wants to use the system, this way we define the limits of the system by taking into account what the user will be able and will not be able to do.

A use case is different from a requirement definition in the sense that it adds a flow of how the program should work in a specific situation, makin us think beyond and not just on the first step, they make us think of the ways that the program could go wrong in each step of use and make us more cautious about those kind of things. They mark the goals that we should aspire to achieve. We can say that a use case is a diferent scenario for how things could go.

We need to be clear on what should and shouldn’t be included when doing the use cases: we need to think of the user, what type of user is and what is hin/her gonna do in the system, the steps that they will take to fulfill their desires and how the program should respond to those actions. This must not include technical stuff about what programing language to use or the specifics of interfaces.

There are several elements that we need to take into acount when doing use cases:

  1. Actor: the subject that is using the system, the one that performs an action.
  2. Pre-conditions: the things that must be true before the use case runs
  3. Post-conditions: it’s what resulted of the use case
  4. Triggers: the event that causes the use case to iniciate
  5. Main sucess sceanrios: normal path of the use case in
    Restaurant_Model
    Continue reading "Use Cases"

Unified Software Process

--Originally published at Hackerman's house

The Unified Process is a iterative and incremental software development framework, from which a customized process can be defined. The most popular variation is the Rational Unified Process (RUP), there are others like the Open Unified Process (OpenUP).

There are some key characteristics in the Unified Process;

  • Iterative and incremental development framework
  • Architecture-centric
  • Risk focused
  • Highest risk factors should be adressed as early as possible
  • Use case and UML driven

Each cycle is broken into four different phases, this can have multiple iterations within the phase.

Inception Phase

In this phase you have to establish the goals of the project. The core requirements and features are defined here, as well as the main risks. This phase also includes the initial project plan and early use cases.
planning

Photo by Mike Cohen

Elaboration Phase

The architecture foundation of the system is established. In this part is taken a more detailed analisys and planning. The architecture must consider the most important requirements and risks.

Construction Phase

This is the phase where the software is built, integrated and tested. The user manuals are created and details of the software are ready to be provided to the user.
Day 2 | "The Claw" | 20 December 2007

Photo by Dan Simpson

Transition Phase

Is where the software is deployed to end users, it has a beta testing stage to ensure the software is ready for the user, retroalimentation from the user is really important in this phase.

References

David Olson (2014) Unified Process, recovered from: http://bawiki.com/wiki/concepts/sdlc-process-models/unified-process/

Life Cycles

--Originally published at Computer Systems Engineering

When we want to develope a program, the best thing we could do is follow this phases that we call program developement life cycle. This cycle consists of 6 steps:

  1. Problem definition
  2. Analysis
  3. Algorithm Developement
  4. Coding and Documentation
  5. Testing and Debugging
  6. Mantainance

1) The planning is the most fundamental part, we need to analize the problem, this is the key: focusing on defining the problem before thinking about the solution. It has to be very clear what are we  trying to solve, put boundaries to the issue, understand the problem and what the solution must or mustn’t do. Unfortunately, this is often the most rushed part for us young developers because we just want to start working right away and we throw a solution really quickly without taking our time to understand the problem that we have to resolve for the client.

2) On the next phase, analysis, we start defining the goals as functions for the program. This is when we link problem-solution, we also need to look into posible issues that could rise when meking the project. It’s in this moment that a Software Requirement Specification document should be created, but in reality as students, if the teacher doesn’t ask for it, who actually bothers to  make one?
giphy (7)

3) In the design phase we see more technical stuff like data flow, modules and the architecture of the problem solution overall, when we make this of course we need to take into account the things that were defined on the previous phases

4) Implementation is the phase we look forward the most (or at least that’s waht i think) because we start creating the solution and we can actually see progress. We see code being written as work being completed which is different then the previous

tenor (3)
tenor (4)
tenor (2).gif
Continue reading "Life Cycles"

Life cycle

--Originally published at Hackerman's house

The Software Development Lyfe Cycle is a sequence of stages to develop a software product. Some of these stages are:

  • Planning
  • Analysis
  • Design
  • Building
  • Testing
  • Deployment
  • Maintenance

A diagram of the SDLC life cycle.

The main point of Life Cycle is to detect errors in software creation before they are discovered later in the development of the project, this way you can save time and money, this also can improve the quality of the software.

There are many different lifecycle methodologies with different approaches.

Agile

The agile model is relatively new, but in the present is one of the main methodologies used by many software organizations. The agile model is used to satisfy the rapidly changing demands of the clients, being flexible and delivering faster. The projects are divided into short manageable segments, with shorter deadlines and more basic requirements, each segment follows the basic stages managed in short sprints.

Resultado de imagen para agile lifecycle

Waterfall

The waterfall model is the oldest of the methodologies, it is very straightforward, you have a sequence of stages, when you finish one you move on to the next one, you don’t go back and every stage relies on what has been done before. This model is very rigid, which is why it has many cons, an early delay can carry huge loses, and the problems can’t be fixed until you get to the maintenance stage, this can be very expensive as one problem may have caused others in the way.

Other examples of SDLC methodologies

  • Lean
  • Spiral
  • Iterative
  • DevOps

References:

Arkasoftwares (w.d) Agile model software development lifecycle, Recovered from https://www.arkasoftwares.com/blog/agile-model-software-development-lifecycle/

Robert Half (2017) 6 basic sdlc methodologies: Which one is best?, Recovered from https://www.roberthalf.com/blog/salaries-and-skills/6-basic-sdlc-methodologies-which-one-is-best

Chapter 5 HFOOAD

--Originally published at Hackerman's house

This chapter talks about the importance of making software that is flexible that is prepared for change.

The abstract class defines behavior, and the subclasses implement that behavior

The first topic is the abstraction. We can use abstract classes as a mold for objects that share the same behavior, this is later implemented in the subclass following the precise requirements for that class, taking as a base the behavior of the abstract class. The subclass can implement or override what’s in the abstract class. The first step to create an abstract class is determining when objects share the same behavior.

By coding to an interface your code will work with all of the interface’s subclasses-even ones that haven’t been created yet

The interfaces have been a common topic since I began studying this career, the classes inherit common behavior from this interface, interfaces make software easier to extend, this is important as it adds flexibility to the software.

In this chapter I noticed that I usually see encapsulation just as a way to avoid repeated code but it is more than that, encapsulation can prevent unnecesary changes in the classes. A good practice is to separate behaviors of an app that can change a lot from those behaviors that won’t.

Finally one of the things that impacted me the most in this chapter was that you have to analyze your own code and recognize when you have made a mistake, design is iterative and you have to change your own design in case it’s needed.

Warmup

Photo by Mr. Nixter

Finally I want to talk a little about my project. We have decided our project and it’s main requirements but we need to define better what the reach of the project is going to be, the design until now is very Continue reading "Chapter 5 HFOOAD"

Nothing Ever Stays The Same

--Originally published at Computer Systems Engineering

Let’s get started with this LONG chapter 5 of the book.

Software needs to change, that is innevitable, let it be because some new features need to be added, some need to be updated, some need to be added, deleted, or whatever.  They tell us to be ready for the change but in reality we are all panicked about change.

giphy (6)

In object oriented programing a way we can prepare for that change in software is using abstract classes that can act as placeholders that when we put to use we can modify to fit our needs. The abstract classes defines the behaviour and the sublcasses are the ones that implement the behaviour.

Another alternative to make software chaengable is using interfaces, which makes it more flexible and addaptable, perfect for the case that the book brings up about needing to add various instruments, by creating an interface you can be ready even for those sublcasses that doesn’t exist yet but if you try to make your code bigger they for sure will be usefull to avoid code duplication.

Joke break. On the left we see how flexible we want our code to be, on the right we see how flexible our code actually is:

yoga toes.gif

Encapsulation is important to leave some parts of your code unbothered while at the same time you leave some other parts run free for every change necesary. It’s vital to know and analize your code to diferenciate which will actually stay as it is and which will need an update every hour.

update-gif-11.gif

Everything is about following the OO design principles, make your code more flexible and think things trough. We shouldn’t be stubborn about keeping our design as it is only because at a given moment it worked, we need to improve and better to

P7wa.gif
😦
giphy (5).gif
🙂
giphy67.gif
Continue reading "Nothing Ever Stays The Same"

Chapter 4 HFOOAD

--Originally published at Hackerman's house

This chapter is really interesting, as it talks about how your project will not be in the perfect situation when you release it in the real world, so you have to take into consideration all the bad things that could happen and the external factors and situations that may arise in the environment where your software is. In the case that your system only works on the perfect scenario you will have a lot of problems with your customer, because the external factors may cause the software to become useless.

This chapter talks about two more things, first, in relation with the use cases we have been working on for a couple of chapters, it talks about how important is to detect the nouns and verbs in this use cases, this can be useful to determine which classes we are going to need to develop our system, it is important to notice that not all the nouns are going to become classes as some of these are external agents and the software doesn’t have the need to include them. The verbs help us define the methods that we’ll use.

Resultado de imagen para class diagram

Example of class diagram by TutorialsPoint

At last, this chapter introduces UML diagrams, to visually represent the system and how their parts relate to each other. This can be used after the analysis and can help us to have a nice transition between this stage and the development or code stage. This UML is used when you already have the vision of how the software should work.

Now I want to talk a little bit about the project, we have finally decided what we are going to do, the Robodoggo is a robot that will help the people take care of their dogs. I really like my team, I’ve known Max

Pug
Continue reading "Chapter 4 HFOOAD"