Friday, October 25, 2013

Software Dictionary

Activity diagram: An activity diagram is a special case of a state chart diagram  in which all of them are action states and the flow of control  is triggered by the completion of actions in the source state.

Actor: In a use case diagram (use case diagram: A diagram that shows the external actors who will interact with your system and how they will use it. The diagram consists of a system boundary, actors, use cases, and use case relationships (communicates, uses, and extends).), an actor represents a role played by an outside object. One physical object, therefore, can be represented by several actors

Association: a relationship between an actor and a use case in which an interaction occurs between them.
Attribute: a descriptive property or characteristic of an entity.

Behavior: the set of things that an object and that correspond to functions that act on the object’s data (or attributes).

Class diagram: a graphical depiction of a system’s static object structure, showing object classes that the system is composed of as well as the relationships between those object classes.

Component Diagram: Component diagrams are implementation-level diagrams that show the structure of the code itself. A component diagram consists of components such as source code files, binary code files, executable files, or dynamic-link libraries (DLLs), connected by dependencies

Constraint: any factor, limitation or restraint that may limit a solution or the problem solving process. It is something that limits your flexibility in defining a solution to your objectives. Essentially constraints cannot be changed.

Context diagram: a process model used to document the scope for a system. It may also be referred to as an environmental model.

Control object: an object that contains application logic that is not the responsibility of an entity object. Control objects coordinate messages between interface objects and entity objects and the sequence in which the messages occur.

Data: raw facts about people, places events and things that are of an importance in an organization. Each fact, by itself is meaningless.

Data entry: the process of translating data into a computer readable format.

Data flow: data that is input or output to or from a process.

Database: a collection of interrelated files.

Design Class diagram: a diagram that depicts classes that correspond to software components that are used to build the software application.

Design pattern: a common solution to a given problem in a given context, which supports reuse of proven approaches and techniques.

Documentation: the ongoing activity of recording facts and specifications for a system for current and future reference.

Deployment Diagram: Deployment diagrams are implementation-level diagrams that show the structure of the run-time system. From a deployment diagram, you can understand how the hardware and software elements that make up an application will be configured and deployed.

Entity: a class of persons places, objects, events or concepts about which we need to capture and store data.

Interface object: an object that provides the means by which an actor can interface with the system.

Method: the software logic that is executed in response to a message.

Model: a representation of ether reality or vision. Most models use pictures to represent the reality or vision.

Multiplicity: the minimum and maximum number of occurrences of one object/class for a single occurrence of the related object/class.

Object: something that is or is capable of being seen, touched, or otherwise sensed and about which users store data and associate behavior.

Object/Class relationship: a natural business association that exists between one or more objects and classes.

Package Diagram: A package is the basic organizing element of a UML system model. One package can contain subordinate packages, diagrams, or single elements.

Problem: an undesirable situation that prevents the organization from fully achieving its mission, vision, goals, and/or objectives.

Problem statement: a statement and categorization of problems, opportunities, and directives. It may also include constraints and an initial vision for the solution. It may also be referred to as a preliminary study and feasibility assessment.

Procedure: step by step set of instructions and logic for accomplishing a business process.

Process: work performed by a system in response to incoming data flows or conditions. It may also be referred to as a transform.

Prototype: a small scale, representative, or working mode of the user’s requirements or a proposed design for an information system. Any given prototype may omit certain functions or features until such a time as the prototype has sufficiently evolved into an acceptable implementation of requirements. It is basically a small-scale, incomplete, but working sample of a desired system.\

Record: a collection of fields arranged in a predetermined format.

Relationship: a natural business association between one or more entities.

Scope: the boundaries of a project-the areas of a business that a project may or may not address.

Sequence diagram: A type of interaction diagram, a sequence diagram shows the actors or objects participating in an interaction and the events they generate arranged in a time sequence.

System analysis: the study of a business problem domain to recommend improvements and specify the business requirements and priorities for the solution.

System analysis use case: a use case that documents the interaction between the system user and the system. It is highly detailed in describing what is required but is free of most implementation details and constraints.

System design: the specification of a detailed computer-based solution.

System designer: a technical specialist who translates system user’s business requirements and constraints into technical solutions. He or she designs the computer databases, inputs, outputs, screens, networks and software that will meet the system user’s requirements.

System development process: a set of activities, methods, best practices, deliverables and automated tools that stakeholders use to develop and maintain information systems and software.

System implementation: the construction, installation, testing and delivery of a system into production which means day to day operation.

System initiation: the initial planning for a project to define initial business scope, goals, schedule and budget.

Systems analysis: a problem solving technique that decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact to accomplish their purpose.

Systems analyst: a specialist who studies the problems and needs of an organization to determine how people, data, processes, and information technology can best accomplish improvements for the business.

Systems design: A complimentary problem solving technique to systems analysis that resembles a system’s component pieces back into a complete systems:- hopefully, and improved system. This may involve adding, deleting, and changing pieces relative to the original system.

Systems Development Process:  A set of activities, methods, best practices, deliverables and automated tools that stake holders use to develop and continuously improve information systems and software.

Systems Implementation: The installation and delivery of the entire system into production.

Trigger: A program embedded within a table to automatically invoke updates to another table.

UML: A set of modeling conventions that is used to specify or describe a software system in terms of objects.

Use case: A business scenario or event for which the system must provide a define response.  It is a behaviorally related sequence of steps, both automated and manual, for the purpose of completing a single business task.  It may also be referred to has an analysis tool for finding an identifying business events and responses.

Use case dependency diagram:  A graphical depiction of the dependencies among use cases.

Use case diagram: defines the lines of communication between a particular actor  and a use case.

Use case modeling: The process of modeling a system’s functions in terms of business events, who initiated the events, and how the system responds to those events.


Work flow: The flow of transaction through business processes to ensure appropriate checks and approvals are implemented.


No comments:

Post a Comment