Tiffany Granath Taringa

Keeping the lines of the two previous publications, today I will make another incision concepts Software Engineering. Specifically, I will make a brief introduction to object-oriented analysis .

As usual, the first thing will be to define some basic concepts first. This time, on Object Oriented (OO ) ...

basic OO features

• Abstraction: denotes features essential object that allow differentiation from other types of objects, thus defining the conceptual point of view of the user. Modularity
• : property is to decompose a complex system into more manageable independent.
• Encapsulation: hide implementation allows . It complements the abstraction, since the abstraction is concerned with the external view of an object and the encapsulation prevents customers to see the internals. Hierarchy
• : abstractions are ordered hierarchically . General objects are defined and their subcategories. Generalization (inheritance ) and Aggregation / Composition ( become or be composed of something ).

OO Basics

1. Object: an entity that exists in the real world and behave.
2. Object Class: describes a set of objects with the same properties (attributes), behavior (operations), relationships and semántica.Implementa the principle of abstraction and serves as a template to create objects.
3. Attributes: properties are shared by the class objects and have value depending on the object instance. May be basic or derived (data displayed in other information)
4. Operations: Functions that can be applied to objects of a class. It must recognize the arguments and results.
• Methods. implementation of an operation within a class.
• polymorphism. allow the same operation can be applied in different classes, so that its implementation depends on each class.
5. Relations:
• Associations. define how to connect objects different classes. We go from one object to another by following the link.
• Aggregation. model a relationship "part-whole."
• composition. is a type of aggregation, with the difference that the party does not exist without the whole.
• Generalization. represents a relationship "to be such." Defined hierarchy of abstractions.
• Heritage. allows data structures and operations of a class are accessible to its subclasses.
  

- Multiplicity : define how many objects participate in the relationship. " many of these objects are related to many of these "

- Navigation : associations and aggregations are bi-directional by default, but sometimes we need to restrict the meaning and use arrows to indicate the direction of navigation.


UML: Unified Modeling Language
is a visual language object-oriented modeling. It helps us to understand the system and specifying the functions that should have, and shows us models of the system to have a global perspective on it.

modeling languages \u200b\u200bare beginning to emerge between '70s and late '80s, and get to create many different types, which creates dissatisfaction on the part of users. Of all the existing three to choose unification began in 1994 including: Booch, OMT i OOSE. The first version of UML (1.1) adopted for standardization does not appear until 1997. The emergence of UML
objectives were, mainly, the modeling of systems regardless of the size of these, from beginning to end, in a simple manner and can be used both by people and machines

UML Definition. Is a language for visualizing , specify, build , document elements of a complex system from an object-oriented vision. This is not a process, not tell us how to do things, simply a notation (written, formal and graphics) with well-defined semantics.
multiple models are needed to meet the different views of the system architecture. Features

• specifies all decisions of analysis, design and implementation to build accurate models, clear and complete.
• can be used in any programming language. We can design for UML to code thanks to engineering directly, and vice versa through reverse engineering.
• to document all elements of a development process.

How To Put Dick Inside Underwear

Object Oriented Analysis Requirements Analysis (Part 2)

TECHNICAL REQUIREMENTS DETERMINATION

- conversations, interviews, meetings with the client . We may find several problems:

• the differences between users, get diverse views . The idea is completion of all interviews possible to cover all these points and look better.
• users not usually have experience or knowledge system.
• get an idea of \u200b\u200bthe system, defining only the technique is complicated. You need to use alternative techniques for more information. INTERVIEW PHASES

1. Preparation. Determine the questions going to be (get a study on the problem domain), select a subset of people to get as many details as possible, determine the purpose and content the same and planned. Making
   
2. . It has 3 parties. In the opening made clear to the user what the purpose of the interview and clarify concepts or specific notation to be used during the meeting. In the development , up to 2 hours, we have to maintain control and allow the user to explain, we must avoid monologues by the interviewers. Al final to do a recap of the information given by the user.
3. Analysis of the interviews, we extract the information gathered by my

- Get requirements from Information System (synonymous with computer system) developed. We can use this technique as a complement to the previous one since it can give much more useful information (in some cases users will not work with specific data). That if the problem lies in complex systems and systems that have never existed.

- Get the requirements from the same information system. analysts need to know what already exists in the company where we will put the new system. The problem with this technique is that it is expensive as it is added to this phase an analysis of what is already there and that takes time and more staff to do so.

- Construction of a prototype . We define a prototype with the general characteristics of the system and we meet the requirements based on the versions. This technique is very expensive.

- Use Cases. It identifies the functional and nonfunctional requirements and relate to them. We ask ourselves what are the functions of the system for each actor (person connected to the system.)


WHAT IS IN THE ANALYSIS OF REQUIREMENTS?

1. Understanding the problem through understanding (forgive the redundancy) of the software within the context and the assessment and synthesis of the problem itself (definition of flows, structure and content of information understanding of roles and behavior) modeling system
3. system specification using a formal representation comprovación that what the analyst has collected is what the customer really needs. Issue

- One of the first conflicts with what we have is in deciding which people can give us the information we need to raise the client's needs. We found that a high percentage of people who asked not really give us.
- Probably for the same function we find different information from different people, so which becomes inconsistent information.
- We can find problems in time to integrate our new system because of the operation and performance of other system elements. For example, I can meet with errors when I decide to connect to other software for data.
- The perception of the objectives may change over time.
- As the problem size grows, the analysis becomes more complex.
- The client does not usually value the analysis stage.

modeling methods
Each method of analysis is a notation and an own point of view, but always has to be 3 rules:

1. Partition . a complex system can only be understood if divided into smaller parts that relate to each other, this allows us to see the problem into smaller parts and then, their relationship, come to have an overview of it. Abstraction
2. . should allow us to see the system in general, regardless of how we generate inputs and outputs of the system. Projection
3. . to define the problem taking into account the different points of view.

requirements specification is the result of the analysis. This is a document which serves as a contract between the developer and the customer base and work for the designer.

- Explains what the system, not the how.
- a document should be understandable to anyone. It requires the explanation of the technicalities in the case of any.
- explain the concepts should be clear.
- The information must be complete, must collect all the requirements and in turn, these must be verified by the customer.
- There should be no conflicting requirements.
- Must be a document easily editable.
- must have an index.
- Duty to be usable during the design and implementation, and maintenance system.

- A standard of this document is to ANSI / IEEE.

- then the document should be reviewed and validated at two levels: macroscopic (full specification, consistent and accurate) and detailed (state specific topics).

Ex Naval Ships For Sale

Requirements Analysis (Part 1)

theoretical advantage that I'm studying and I am a refusal to hold things like a parrot, I wanted to write a little about requirements analysis for the subject of Software Engineering. I think it's the only way to learn concepts as theoretical.

The post will have two parts: the first is the one shown below, inserting few basic concepts and explaining what is the analysis of the system and things should be taken into account, the second one will go up later, or tomorrow, and will include techniques for determination of requirements, further analysis and how to be specified.

For starters, let's define a few concepts ...

A computer system is a set of elements arranged to perform a method, procedure or control by information processing. Within a computer system not only find software or hardware , but also different roles people , databases, documents or procedures.

A requirement, itself, is the condition or capacity needed by the user to reach solve a problem (or meet objectives.) In other words, you have to make the system reach.

The solution to a problem can be solved in 4 ways: manually, by software, by hardware or by combining the three.
This simple solution can be (via a simple software) or composite (through a more complex to automate all the actions.) In the case of the composite system is necessary to design the overall system before designing the software that integrates . The

systems engineering is the activity that is responsible for solving these problems. It is therefore necessary that the client integration asks us to participate in the development (in general) of the product by providing targets and constraints that must have the system. The engineer 's who developed the solution initially will be he who analyze system delimiting the area of \u200b\u200boperation, performance and functions. With this information you will need to define a set of solutions among which will choose the best considering, among other things, the existence of a product on the market that meets your needs (" is the case for the need for a road calculation, not develop it because there "), the cost might expect, the type of technology or to meet real needs.

TEST SYSTEM STAGE

1. Identify customer needs. We set the objectives to be achieved. If it is a product that is expected much impact among users, it should make a study of market.
2. study the feasibility of the system. This includes economic (analyzing impact of cost-benefit), technique (see if you can do or not), legal (or illegal determine violations that may cause the system) and alternative (to study the different solutions presented). Make
3. economic and technical analysis deeper.
4. determine the necessary functions and assign them to elements of the system.
5. Create a document that specifies the system definition. This document will serve as the basis for all subsequent system development.

Whether the solution is simple, as if made (system complex) have to make a analysis software requirements. Once we understand the problem by studying the system we have to reflect this understanding is a document. This is what is called requirements specification. The requirements that we considered could be:

• Functional: describes the inputs and outputs of the system, and the operations that take place between them. No functional
• : define the general qualities that must have the system. In other words, we can define these requirements and the limits of the possible solutions. These can be performance of design (standards compliance, hardware requirements, error handling, security) of external interfaces (everything related to the interaction of people, hardware or other software), quality of ( it is easy to use, maintain, that is expandable ...) or design decisions (module implementations).