DevOps ++ (2/5)

Hello again, its been a weird long weekend and right now it seems like I’m getting sick again. But a different kind of sickness, probably a virus. I will keep you tuned about that.

Today’s music:

In this second part of the series of activities of DevOps we will start working with our enviroment and preparing the necesary tools for a software testing and quality focus. As I already told you in the first part, my current and only OS available is linux, guess it’s the perfect time for getting use to it and it’s tools. I will guide you to the steps I followed and the final status of this part.

BASE OS

First of all, we need a linux machine, it can be the host OS or a virtual machine, as you wish. In my case I have installed  UBUNTU 18.04. You can download the 18.04 version on https://www.ubuntu.com/download/desktop and if you need a virtual machine I really recommend you to use virtual box. It has been my virtualization software since I was in highschool (7 years at least). And you can download it from: https://www.virtualbox.org/wiki/Downloads

LANGUAGE ENVIROMENT

What its next, we need to add support to our coding language. In my case Python 3.6 which you can install with:

$ sudo apt install python3-minimal

Simple right? (for more info look at https://linuxconfig.org/how-to-install-python-in-ubuntu-18-04-bionic-beaver-linux)

GIT

Well, after we have our language, we need to install git on our linux distribution. For that we only need to put the next command in the terminal:

As it it always recommended, we start with the OS and package updates.

$ sudo apt-get update

Next goes git

$ apt-get install git-core

And to verify that  it is correctly installed we look at the installed version with:

$ git --version

Which should output something like:

$ git version 3.6

(For more info. about git on linux go to: https://www.liquidweb.com/kb/install-git-ubuntu-16-04-lts/)

Web Deployment

I chose to use nodejs since its a js engine developed by Google, famous and powerful but I have never had the chance of working hardcore on it and think this is the perfect opportunity for it.

First lets start with nodejs. I looked for some tutorials but keep crushing into issues while trying the instalation command to I simply tried with:

$ sudo apt install nodejs

and then

sudo apt install npm

Guess what? It worked like a charm so I don’t see why you would have issues with this commands. You can always verify the installation with:

$ nodejs -v

$ npm -v

I already told you i’m not really familiar with this kind of tools so I decided to go on a noobs tutorial for the basics. I recommend you this tutorial where at the end, you end up with a server deployed on the port you defined. This will help us in the future.

CRON

And finally we will need to setup this tool called CRON. This helps us for automation purposes and the next part. It works by setting custom processes and activities scheduled for their execution in linux.

Again we need to to de updates and upgrade for our server by doing

$ sudo apt-get update

$ sudo apt-get upgrade

To know if we have the package installed we use the next command:

$ dpkg -l cron

If we don’t have it, we just use:

$ sudo apt-get install cron

And verify that the service is running with

$ systemctl status cron

In order to set new jobs for cron, you can look how in the next link:

https://www.rosehosting.com/blog/ubuntu-crontab/

The edgy: Its not a goodbye, its a see you later

 

Well, this time its time to say Thank you. In our lives, we can regret plenty of different things. But I am sure  one of the biggest regrets you, me and I will have, are also the most difficult ones. Not saying things on time.

Always be sure to say what you feel. Either you are happy, sad, angry, even hungry. Shout it. Never shut it up. This is really a small post but what I am feeling, what I want to say is:

THANK YOU KEN. THANK YOU FOR BEING THIS AWESOME TEACHER THAT GETS OUT THE ROUTINE TO TRY TO TEACH US SOMETHING BIGGER THAN A SIMPLE SCHOOL SUBJECT. YOU TRIED TO TEACH US A LIFE LESSON (AS IS SELF-LEARNING AND RESPONSIBILITY TO SAY AN EXAMPLE).

I CAN SAY FROM EVERYONE THAT WE ALL HAD GROWN ON A WAY. SOME PEOPLE MORE THAN OTHERS BUT AT THE END IS LEARNING AND GROWING WHICH IS THE IMPORTANT THING IN LIFE.

ALWAYS KEEP MOVING, ALWAYS KEEP LIVING, EXPLORING, LEARNING. HAVE THAT CHILD SOUL AND REMEMBER, IF THINGS ARE NOT SO GOOD; NO WORRIES. SOON EVERYTHING IS GOING TO BE ALL RIGHT.

YOU HAVE A FRIEND IN ME 😉

 

 

 

Feel romantic? You should listen to this 😉

Software verification and validation

If of testing we are talking, the verification and validations are our next targets.

The terms ‘Verification‘ and ‘Validation‘ are frequently used in the software testing world but the meaning of these terms are mostly vague and debatable. You will encounter (or have encountered) all kinds of usage and interpretations of those terms, and it is our humble attempt here to distinguish between them as clearly as possible.

First of all.

Software Verification

The process of evaluating work-products (not the actual final product) of a development phase to determine whether they meet the specified requirements for that phase. Its objective is to ensure that the product is being built according to the requirements and design specifications. In other words, to ensure that work products meet their specified requirements.

We constantly should be asking to our self: Are we building the product right? How are we going to do this? Simple, by:

• Reviews
• Walkthroughs
• Inspections

And evaluating plans, requirement specs, design specs, code and test Cases

Software Validation

The process of evaluating software during or at the end of the development process to determine whether it satisfies specified business requirements. Its objective is to ensure that the product actually meets the user’s needs, and that the specifications were correct in the first place. In other words, to demonstrate that the product fulfills its intended use when placed in its intended environment.

This time we need to ask: Are we building the right product? Our evaluation item is the product (software) and the way of doing it is by testing, testing testing testing.

————————————————————————

This blog is the most relevant information extracted from the bottom source. Day by day I will try to be eliminating the source words and add my own content but for practice purposes (for now) will be as that.

For instance this is the way I will be working, using the original blogs as layouts for my post development. Thanks for the comprehension and all credits to the original authors.

Source: http://softwaretestingfundamentals.com/verification-vs-validation/

 

Beautify Me ;)

So now, lets talk about one important aspect when building software. We gotta have always in mind that helping the regular user have this intuitive way of using the app-software will lead us to a more successful development.

Here is where the User Interface Design comes to matter.

User Interface (UI) Design focuses on anticipating what users might need to do and ensuring that the interface has elements that are easy to access, understand, and use to facilitate those actions. UI brings together concepts from interaction design, visual design, and information architecture.

Users have become familiar with interface elements acting in a certain way, so try to be consistent and predictable in your choices and their layout. Doing so will help with task completion, efficiency, and satisfaction.

• Input Controls: buttons, textfields, checkboxes, radio buttons, dropdown lists, list boxes, toggles, date field
• Navigational Components: breadcrumb, slider, search field, pagination, slider, tags, icons
• Informational Components: tooltips, icons, progress bar, notifications, message boxes, modal windows
• Containers: accordion

Everything stems from knowing your users, including understanding their goals, skills, preferences, and tendencies.  Once you know about your user, make sure to consider the following when designing your interface:

• Keep the interface simple. The best interfaces are almost invisible to the user. They avoid unnecessary elements and are clear in the language they use on labels and in messaging.
• Create consistency and use common UI elements. By using common elements in your UI, users feel more comfortable and are able to get things done more quickly.  It is also important to create patterns in language, layout and design throughout the site to help facilitate efficiency. Once a user learns how to do something, they should be able to transfer that skill to other parts of the site.
• Be purposeful in page layout.  Consider the spatial relationships between items on the page and structure the page based on importance. Careful placement of items can help draw attention to the most important pieces of information and can aid scanning and readability.
• Strategically use color and texture. You can direct attention toward or redirect attention away from items using color, light, contrast, and texture to your advantage.
• Use typography to create hierarchy and clarity. Carefully consider how you use typeface. Different sizes, fonts, and arrangement of the text to help increase scanability, legibility and readability.
• Make sure that the system communicates what’s happening.  Always inform your users of location, actions, changes in state, or errors. The use of various UI elements to communicate status and, if necessary, next steps can reduce frustration for your user.
• Think about the defaults. By carefully thinking about and anticipating the goals people bring to your site, you can create defaults that reduce the burden on the user.  This becomes particularly important when it comes to form design where you might have an opportunity to have some fields pre-chosen or filled out.

This blog is the most relevant information extracted from the bottom source. Day by day I will try to be eliminating the source words and add my own content but for practice purposes (for now) will be as that.

For instance this is the way I will be working, using the original blogs as layouts for my post develoment. Thanks for the comprehension and all credits to the original authors.

Source: https://www.usability.gov/what-and-why/user-interface-design.html

Lets keep it up moving

Software development efforts result in the delivery of a software product that satisfies user requirements. Accordingly, the software product must change or evolve. Once in operation, defects are uncovered, operating environments change, and new user requirements surface. The maintenance phase of the life cycle begins following a warranty period or postimplementation support delivery, but maintenance activities occur much earlier

.

Software maintenance is an integral part of a software life cycle. However, it has not received the same degree of attention that the other phases have. Historically, software development has had a much higher profile than software maintenance in most organizations. This is now changing, as organizations strive to squeeze the most out of their software development investment by keeping software operating as long as possible. The open source paradigm has brought further attention to the issue of maintaining software artifacts developed by others.

Maintenance is needed to ensure that the software continues to satisfy user requirements. Maintenance is applicable to software that is developed using any software life cycle model (for example, spiral or linear). Software products change due to corrective and noncorrective software actions. Maintenance must be performed in order to

• correct faults;
• improve the design;
• implement enhancements;
• interface with other software;
• adapt programs so that different hardware, software, system features, and telecommunications facilities can be used;
• migrate legacy software; and
• retire software.

Five key characteristics comprise the maintainer’s activities:

• maintaining control over the software’s day-to-day functions;
• maintaining control over software modification;
• perfecting existing functions;
• identifying security threats and fixing security vulnerabilities; and
• preventing software performance from degrading to unacceptable levels.

This blog is the most relevant information extracted from the bottom source. Day by day I will try to be eliminating the source words and add my own content but for practice purposes (for now) will be as that.

Source: http://swebokwiki.org/Chapter_5:_Software_Maintenance

Software design patterns

As software engineers, we all should already know that, when working on a new project, you start by establishing the way of attacking-solving the problem or software to develop. So it is important to get there are these things called patterns (software design patterns) which may help you as a guide to your way of working.

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

There are three design patterns we are going to talk about.

Structural

In Software Engineering, Structural Design Patterns are Design Patterns that ease the design by identifying a simple way to realize relationships between entities, making it easier for these to work together.

• Adapter
  Match interfaces of different classes
• Bridge
  Separates an object’s interface from its implementation
• Composite
  A tree structure of simple and composite objects
• Decorator
  Add responsibilities to objects dynamically
• Facade
  A single class that represents an entire subsystem
• Flyweight
  A fine-grained instance used for efficient sharing
• Private Class Data

  Restricts accessor/mutator access

• Proxy
  An object representing another object

Creational

In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

• Abstract Factory
  Creates an instance of several families of classes
• Builder
  Separates object construction from its representation
• Factory Method
  Creates an instance of several derived classes
• Object Pool
  Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
• Prototype
  A fully initialized instance to be copied or cloned
• Singleton
  A class of which only a single instance can exist

& finally

Behavioral

These design patterns are all about Class’s objects communication. Behavioral patterns are those patterns that are most specifically concerned with communication between objects.

• Chain of responsibility
  A way of passing a request between a chain of objects
• Command
  Encapsulate a command request as an object
• Interpreter
  A way to include language elements in a program
• Iterator
  Sequentially access the elements of a collection
• Mediator
  Defines simplified communication between classes
• Memento
  Capture and restore an object’s internal state
• Null Object
  Designed to act as a default value of an object
• Observer
  A way of notifying change to a number of classes
• State

  Alter an object’s behavior when its state changes

• Strategy
  Encapsulates an algorithm inside a class
• Template method
  Defer the exact steps of an algorithm to a subclass
• Visitor
  Defines a new operation to a class without change

If you are a more listener boy, girl or apache helicopter, then you should watch-listen this video 😉

 

Source: https://sourcemaking.com/design_patterns

One brick at a time- Software Architecture

What is software architecture?

Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.

Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definition is:

“Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.”

Architectural Landscape

• User empowerment. A design that supports user empowerment is flexible, configurable, and focused on the user experience. Design your application with appropriate levels of user personalization and options in mind. Allow the user to define how they interact with your application instead of dictating to them, but do not overload them with unnecessary options and settings that can lead to confusion. Understand the key scenarios and make them as simple as possible; make it easy to find information and use the application.
• Market maturity. Take advantage of market maturity by taking advantage of existing platform and technology options. Build on higher level application frameworks where it makes sense, so that you can focus on what is uniquely valuable in your application rather than recreating something that already exists and can be reused. Use patterns that provide rich sources of proven solutions for common problems.
• Flexible design. Increasingly, flexible designs take advantage of loose coupling to allow reuse and to improve maintainability. Pluggable designs allow you to provide post-deployment extensibility. You can also take advantage of service orientation techniques such as SOA to provide interoperability with other systems.
• Future trends. When building your architecture, understand the future trends that might affect your design after deployment. For example, consider trends in rich UI and media, composition models such as mashups, increasing network bandwidth and availability, increasing use of mobile devices, continued improvement in hardware performance, interest in community and personal publishing models, the rise of cloud-based computing, and remote operation.

At the end we will have the whole perspective and an splendid job done.

The goals of architecture

• Expose the structure of the system but hide the implementation details.
• Realize all of the use cases and scenarios.
• Try to address the requirements of various stakeholders.
• Handle both functional and quality requirements.

The principles of Architecture Design

• What are the foundational parts of the architecture that represent the greatest risk if you get them wrong?
• What are the parts of the architecture that are most likely to change, or whose design you can delay until later with little impact?
• What are your key assumptions, and how will you test them?
• What conditions may require you to refactor the design?

Key Architecture principles

Consider the following key principles when designing your architecture:

• Build to change instead of building to last. Consider how the application may need to change over time to address new requirements and challenges, and build in the flexibility to support this.
• Model to analyze and reduce risk. Use design tools, modeling systems such as Unified Modeling Language (UML), and visualizations where appropriate to help you capture requirements and architectural and design decisions, and to analyze their impact. However, do not formalize the model to the extent that it suppresses the capability to iterate and adapt the design easily.
• Use models and visualizations as a communication and collaboration tool. Efficient communication of the design, the decisions you make, and ongoing changes to the design, is critical to good architecture. Use models, views, and other visualizations of the architecture to communicate and share your design efficiently with all the stakeholders, and to enable rapid communication of changes to the design.
• Identify key engineering decisions. Use the information in this guide to understand the key engineering decisions and the areas where mistakes are most often made. Invest in getting these key decisions right the first time so that the design is more flexible and less likely to be broken by changes.

Source: https://msdn.microsoft.com/en-us/library/ee658098.aspx

Bibidi Badi-Software Design

What is software design?

It is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints.

Software design may refer to either «all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems» or «the activity following requirements specification and before programming, as a stylized software engineering process.»

Software design usually involves problem solving and planning a software solution. This includes both a low-level component and algorithm design and a high-level, architecture design.

There are several basic design principles that enable the software engineer to navigate the design process:

• The design process should not suffer from «tunnel vision.» A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job.
• The design should be traceable to the analysis model. Because a single element of the design model can often be traced back to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model.
• The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited; design time should be invested in representing truly new ideas and integrating patterns that already exist when applicable.
• The design should «minimize the intellectual distance» between the software and the problem as it exists in the real world. That is, the structure of the software design should, whenever possible, mimic the structure of the problem domain.
• The design should exhibit uniformity and integration. A design is uniform if it appears fully coherent. In order to achieve this outcome, rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components.
• The design should be structured to accommodate change. The design concepts discussed in the next section enable a design to achieve this principle.
• The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Well- designed software should never «bomb»; it should be designed to accommodate unusual circumstances, and if it must terminate processing, it should do so in a graceful manner.
• Design is not coding, coding is not design. Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than the source code. The only design decisions made at the coding level should address the small implementation details that enable the procedural design to be coded.
• The design should be assessed for quality as it is being created, not after the fact. A variety of design concepts and design measures are available to assist the designer in assessing quality throughout the development process.
• The design should be reviewed to minimize conceptual (semantic) errors. There is sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of the design model.

TIME FOR A BREAK

Things to consider when software designing

There are many aspects to consider in the design of a piece of software. The importance of each consideration should reflect the goals and expectations that the software is being created to meet. Some of these aspects are:

• Compatibility – The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backward-compatible with an older version of itself.
• Extensibility – New capabilities can be added to the software without major changes to the underlying architecture.
• Modularity – the resulting software comprises well defined, independent components which leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project.
• Fault-tolerance – The software is resistant to and able to recover from component failure.
• Maintainability – A measure of how easily bug fixes or functional modifications can be accomplished. High maintainability can be the product of modularity and extensibility.
• Reliability (Software durability) – The software is able to perform a required function under stated conditions for a specified period of time.
• Reusability – The ability to use some or all of the aspects of the pre existing software in other projects with little to no modification.
• Robustness – The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with a resilience to low memory conditions.
• Security – The software is able to withstand and resist hostile acts and influences.
• Usability – The software user interface must be usable for its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users.
• Performance – The software performs its tasks within a time-frame that is acceptable for the user, and does not require too much memory.
• Portability – The software should be usable across a number of different conditions and environments.
• Scalability – The software adapts well to increasing data or number of users.

We will extend this topic in another blog I will be uploading soon, so be patient and enjoy life.

Source: https://en.wikipedia.org/wiki/Software_design

Let’s learn about some requirements

In software engineering, we have plenty kind of requirements, but in this blog we are really interested in to kinds of them. The software requirements elicitation and software requirements specification.

Requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as «requirement gathering».

The requirements elicitation process may appear simple: ask the customer, the users and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of business, and finally, how the system or product is to be used on a day-to-day basis. However, issues may arise that complicate the process.

In 1992, Christel and Kang identified problems that indicate the challenges for requirements elicitation:

1. ‘Problems of scope’. The boundary of the system is ill-defined or the customers/users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.
2. Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.
3. Problems of volatility. The requirements change over time. The rate of change is sometimes referred to as the level of requirement volatility

Requirements quality can be improved through these approaches:

1. Visualization. Using tools that promote better understanding of the desired end-product such as visualization and simulation.
2. Consistent language. Using simple, consistent definitions for requirements described in natural language and use the business terminology that is prevalent in the enterprise.
3. Guidelines. Following organizational guidelines that describe the collection techniques and the types of requirements to be collected. These guidelines are then used consistently across projects.
4. Consistent use of templates. Producing a consistent set of models and templates to document the requirements.
5. Documenting dependencies. Documenting dependencies and interrelationships among requirements.
6. Analysis of changes. Performing root cause analysis of changes to requirements and making corrective actions.

A guideline of steps for doing this would be:

1. Identify the real problem, opportunity or challenge
2. Identify the current measure(s) which show that the problem is real
3. Identify the goal measure(s) to show the problem has been addressed and the value of meeting it
4. Identify the «as-is» cause(s) of the problem, as it is the causes that must be solved, not the problem directly
5. Define the business «whats» that must be delivered to meet the goal measure(s)
6. Specify a product design how to satisfy the real business requirements

This is a sequence that Goldsmith suggested in 2004.

————————————————————————-

A software requirements specification (SRS) is a description of a software system to be developed. It lays out functional and nonfunctional requirements, and may include a set of use cases that describe user interactions that the software must provide.

Software requirements specification establishes the basis for an agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do. Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules.Software requirements specification prevents software projects from failure.

SRS STRUCTURE 

An example organization of an SRS is as follows:^[5]

• • Purpose
  • Definitions
  • System overview
  • References
• Overall description
  • Product perspective
    • System Interfaces
    • User Interfaces
    • Hardware interfaces
    • Software interfaces
    • Communication Interfaces
    • Memory Constraints
  • Design constraints
    • Operations
    • Site Adaptation Requirements
  • Product functions
  • User characteristics
  • Constraints, assumptions and dependencies
• Specific requirements
  • External interface requirements
  • Functional requirements
  • Performance requirements
  • Logical database requirement
  • Software System attributes
    • Reliability
    • Availability
    • Security
    • Maintainability
    • Portability
  • others..

GOALS

The Software Requirements Specification (SRS) is a communication tool between stakeholders and software designers. The specific goals of the SRS are:

• Facilitating reviews
• Describing the scope of work
• Providing a reference to software designers (i.e. navigation aids, document structure)
• Providing a framework for testing primary and secondary use cases
• Including features to customer requirements
• Providing a platform for ongoing refinement (via incomplete specs or questions)

Reliability Availability Security Maintainability Portability.

Extending what we learn. I will leave 2 videos that will help you get all the ideas together.

Software Requirements Elicitation Introduction

Software Requirements Specification

The bast mayority of information gathered in here was extracted from: https://en.wikipedia.org/wiki/Requirements_elicitation#Sequence_of_steps & https://en.wikipedia.org/wiki/Software_requirements_specification

 

Un modelo para gobernarlos a todos (Lenguaje Unificado de Modelado).

Sus siglas en ingles (UML) Unified Modeling Language es un estándar para desarrollo de software. Tiene como objetivo mejorar la comunicación entre programadores, hacer saber de las necesidades servidor cliente, crear un modelado de la estructura para el diseño de un programa.

Los pioneros de  UML fueron: Grady Booch, James rumbaugh e Ivar Jacobson. En la época de los 80s, al desarrollar individualmente una metodología para el análisis y diseño orientado objeto, donde posterior mente (en el inicio de los 90s) juntaron su trabajo. De ahi nacio la idea de un lenguaje unificado.

Es importante que entendamos que UML no es programación, no son sentencias ni codigo; no esta asociado a ningún lenguaje de programación. Ni es metodología.

DIAGRAMAS UML

• Define la estructura y el comportamiento del programa.
• Organizar características y funciones de un proceso para su mejor funcionamiento.
• Se utiliza para hacer el análisis del sistema.
• Presentar diversas perspectivas de un sistema
• Se pueden correlacionar un diagrama con otro.
• Genera muchas formas de organizarlos y extenderlos.

DIAGRAMA DE CLASES

Una clase es una categoría o grupo de cosas que tienen atributos y acciones similares.

DIAGRAMA DE OBJETOS

Es una entidad que tiene valores específicos de los atributos y acciones.

DIAGRAMA DE ESTADOS

Es el estado en particular que se encuentra el objeto. Establece condiciones. Realiza actividad o espera algún evento.

DIAGRAMA DE SECUENCIAS

Son interacciones entre objetos que suceden con el tiempo.

DIAGRAMA DE ACTIVIDADES

Las actividades que ocurren dentro de un caso de uso. Lo que se hace en un estado o grupo de estados. Orden, donde, tiempo, cuando, quien y que harán.

Entre estos y mas conceptos los podemos ver junto con sus respectivos ejemplos en la playlist Curso UML de Ingenio y Tecnología. Toda la información del blog fue extraída de dicha playlist y plasmada en texto (las partes que considero más importantes) para su mayor entendimiento.