Html/Javascript widget

Monday, 2 October 2017

critical path method (CPM)

The critical path method (CPM) is a progressive project management technique to separate critical and non-critical tasks in order to avoid bottlenecks and missed deadlines due to lack of priorisation. It's best suited for projects with a diverse range of activities in a way that enables their solving in an ordered manner. ideally, a flowchart is used for displaying how the tasks relate to each other (e.g.: how the output of an activity is the input of a subsequent process). It's also tops to determine beforehand the expected completion time for each task.

An activities model designed for project management, common elements of this model include time for the completion of each activity, the dependencies therein, milestones and deliverables. It makes use of the presentation capabilities of an operation flowchart, the outcomes pictured as knots while the accompanying relationships are represented by arrows. For this model to make sense, all individual project operations should be plotted with their respective durations.
Using the dynamics of the operation-duration relationships, CPM calculates the longest path of planned activities to logical end points or to the end of the project, and the earliest and latest that each activity can start and finish without delaying the whole project, as a means of providing a safe margin for work within a given deadline. This procedure distinguishes activities between "critical" and which have "total float", meaning, allowed some delay without compromising the project overall. This network of activities and their matching duration defines the shortest possible time to carry a project through to completion, with total float being unused time within the critical path.

Monday, 11 September 2017

Object-oriented analysis

Object–Oriented Analysis means gathering software requirements according and identifying the elements of the problem domain. The requirements and domain problem are created with an object model in mind, which ultimately guides the whole process through to completion.

Although the object-oriented approach started as a programming methodology since 1960 with Simula, it wasn't until later that this became a major software design paradigm with Xerox Park and an published article by Grady Booch in 1980 that emphasised the features of an object-oriented mindset for software developers.
Codd eventually expanded upon this study to create what is known today as object-oriented methods.

In object-oriented approach, requirements are based on objects that the system interacts with. Grady Booch has defined OOA as a method for identifying requirements from the perspective of the classes and objects found in the vocabulary of the problem domain.

The primary tasks in object-oriented analysis are:

-Identifying objects;
-Organising them through some standard model diagram;
-Defining their attributes and methods;
-describing they interact with user, external agents and each other

In OOD, concepts in the analysis model are technology−independent so they can modelled into classes, constraints and interfaces to provide a suitable solution to the domain problem. The implementation includes restructuring of the class its associations.
Grady Booch has defined object-oriented design as "a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design".
Object-oriented programming uses these advantages to achieve great gains suc has modularity and reusability.

According to Grady Booch "object–oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships".

Sunday, 27 August 2017

Unified Process

Unified Process is one of the most important software industry patterns as of late. This software process was spearheaded by 3 experts in object-oriented analysis in the 1990's: Jacbson, Booch and Rumbaugh). This is the first ever model to be designed after the UML notation. It started to find wide acceptation as a best practice for market ROI. Among the UP features one could quote:
-Clear and precise instructions;
-promotes accountability;
-activities that stress out input and output artefacts
-defines the dependency relationships among activities;
-comprises a well understood life cycle model;
-emphasises the use of the right procedures with the available resources;
-strong correlation with UML.

As a framework, UP is easily adapted to a variety of processes, encompassing the needs of different businesses. Its main features are:

1- Use case-driven- This is process understood from the user's viewpoint, without touching on implementation details. This means a comprehensive collection of all functional requirements that the proposed system has to include. Non-functional requirements might be noted along matching use cases, while extra requirements are kept in a different document.

2- Archiecture-centred - This implies gathering the requirements collected during the use cases and think of them as classes organised in components with defined roles within a system. Archiecture might be thought of as the information structure as well as the likely operations of said system. The system architecture starts with the user's viewpoints through use cases influenced by implementation factors.

3- Incremental iterations - At each iteration, relevant use cases are analysed according to the chosen architecture. The artefact resulting at the end of every iteration is a system module or an executable version.  The next stage of the iteration involves the next system component to be implemented provided that the current one meets the user's expectations.

4- focus on risk- This means that the most critical use cases are dealt with early in order to solve the most difficult problems first. The highest risk requirements or use cases are usually the ones most likely to be unpredictable in their interaction with the remainder of the components. Thus, understanding them first emables is important to ensure tighter system cohesion.

UP stages

1- Inception: This stage seeks to establish a broad picture of the system. Here the main priorities are limited to requirements, conceptual models and high level use cases. A development plan is also drawn up at this point in order to anticipate the amount of resources needed into the proposed project. The use cases will be incorporated into iterative cycles. Tests and implementation might occur during this stage in case an early prototype is deemed necessary to avoid greater risks, but otherwise these are kept to a minimum.

2- elaboration- Use cases are expanded upon in order to plot a basic architectural model. This means that the use cases are given more details to decide which artifacts will serve as the input/output of the incoming iterations. The conceptual model is revised and gives rise to the logical and physical design of the intended system.

3- construction- With the basic system architecture established, the first release of the software product is the aim of this stage, which is almost entirely dedicated to coding and testing. At this point a basic should have been reached between managers and users about the intended system.

4- transition - The system is deployed to the user's work environment. Usually data transfer from the former system takes place along with the obligatory training course. Any discrepancy picked by the end users are reported to the developers so they can work on the necessary improvements. It's still possible for requirements and code to undergo some minor revisions.

Thursday, 17 August 2017

Linked List

Introduction to linked list.

A linked list is a data structure that looks a lot like a regular list, except that it's a sequence of nodes. Each node comprises of two parts: data field and data reference. The latter is what defines nodes in a linked list as they're needed to point to the next node in the sequence. Without the data reference, the elements of a linked list wouldn't be bound at all; they'd be only loose entities without any connecting feature to relate them. A head pointer is used to track the first element in the linked list, always pointing to it.

The linked list data structure is tops for insertion or removal at any position in the list. However finding elements according to some specified criterium is made more difficult when compared to other compound data structures such as arrays and lists because it requires going through the whole list in order to find the desired item.

We can model a node of the linked list using a structure as follows:

typedef struct node{
    int data;
    struct node* next;

It should be noted that a linked list element is basically a struct, an object-esque entity in C which shares some similarities with a bona fide object from OO programming. For instance, a struct can store other values using common data types such as ints and chars, which can be referred to later on down the project.  Also, notice how data stores information while the next pointer holds the address of the next node.

First we declare a head pointer that always points to the first node of the list.

To add a node at the beginning of list we need to create a new node. We will need to create a new node each time we want to insert a new node into the list so we can develop a function that creates a new node and return it.

node* create(int data,node* next)
    node* new_node = (node*)malloc(sizeof(node));
    if(new_node == NULL)
        printf("Error creating a new node.\n");
    new_node->data = data;
    new_node->next = next;

    return new_node;

Then we need to point the next pointer of the new node to the head pointer and point the head pointer to the new node.

node* prepend(node* head,int data)
    node* new_node = create(data,head);
    head = new_node;
    return head;

TRaversing the linked list

To traverse the linked list, we start from node 1, and move to the next node until we reach a NULL pointer.

typedef void (*callback)(node* data);
The following is the traverse() function:

void traverse(node* head,callback f)
    node* cursor = head;
    while(cursor != NULL)
        cursor = cursor->next;

Sunday, 4 June 2017

A Short Definition for weighted graph

A weighted graph is a graph that ssigns a numerical weight to each branch. As each branch is made up of vertices (or nodes) and edges, they are assigned weigts if they have labelled values: a vertex-weighted graph has weights on its vertices and an edge-weighted graph has weights on its edges.

obs.: Weight is just a numerical value assigned as a label to a vertex or edge of a graph. The weight of a subgraph is the sum of the weights of the vertices or edges within that subgraph.

Quick Introduction to Pointers

A pointer is a variable containing the address of another variable.

Take for instance the declared variable variable1 in C:

int Variable1;
, store the number ‘96’ in it with

and print it out with


Instead of referring to this data store by name (in this instance, variable1), it can be done so by its computer memory address, which can be in a pointer, which is another variable in C. Using the operator '&' means "to take the adress of" while the operator * means to give the pointer whatever is in said address. A pointer to the code above could look like this:


This stores the address of variable1 in the variable Pointer1.

To take the value, we would use *:


which would have the same effect as


or print it out with


So far it should be clear that for pointers we need to use & to take the memory address of a variable while * takes hold of its value.

A pointer is created as below:

int *Pointer1;

The reason that the symbol * comes after the type when delcaring pointers is because it's necessary to specify the type that the pointer has to point to. An int *pointer points only to integer. A char *var points only to chars and so on.

Pointers are necessary for dynamic memory location, data structures and efficient handling of large amounts of data. Without pointers, you'd have to allocate all the program data globally or in functions or the equivalent, resulting in a lot of waste for variables that are not being used but are still taking up memory space.

Interpreter and Compiler

A compiler is a computer program responsible for translating a source code into a language form that can be directly run by the computer. There's though a minor difference between translator and compiler: a translator converts a program from its formal source code to a specific target language. Compilers are a special sort of translators which take program code often written in a high level language to run as machine code or intermediate code (e.g.: Bytecode, .NET-Code etc). This difference between translator and compiler isn't always pronounced in all cases. Programming languages such as C and C++ are compiler-based as they generate an exe file (if you're using windows) after being successfully compiled. An interpreter, on the other hand, doesn't convert source code into a portable format that can be run in a specific platform or system. Rather, an interpreter reads a code line by line and produces an output on a client or server platform. Interpreters need a specific environment setup in order to work properly. Examples of interpreted languages include Javascript and PHP.

Translates code line by line.Runs through whole program to generate an .exe file.
Reads faster but executes slower.It takes more time to scan code but afterwards execution is faster than with an interpreter. 
No intermediate code generated.Intermediate object code that calls for linking, which in turn uses up more memory.
Translation stops at first error.It throws an error message after scanning the entire code.
Input in the form of Single statements The whole program is the input in compiled languages.