Diamond problem ( multiple inheritance big problem).

In object-oriented programming languages with multiple inheritance and knowledge organization, the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not overridethe method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?

For example, in the context of GUI software development, a class Button may inherit from both classes Rectangle (for appearance) andClickable (for functionality/input handling), and classes Rectangle and Clickable both inherit from the Object class. Now if the equalsmethod is called for a Button object and there is no such method in the Button class but there is an overridden equals method in bothRectangle and Clickable, which method should be eventually called?

It is called the "diamond problem" because of the shape of the class inheritance diagram in this situation. In this article, class A is at the top, both B and C separately beneath it, and D joins the two together at the bottom to form a diamond shape.

Approaches

Different programming languages have addressed this problem in different ways:

§  C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" (for example, "class B : virtual public A"), C++ takes special care to only create one Aobject, and uses of A's members work correctly. If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A. Please note that nonvirtual derivation of A in this case will be useless as direct access to any part of class A from class D will practically always end up with compile error.

§  Common Lisp attempts to provide both reasonable default behavior and the ability to override it. By default, the method with the most specific argument classes is chosen; then in the order in which parent classes are named in the subclass definition. However, the programmer can override this, by giving a specific method resolution order or stating a rule for combining methods.

§  Eiffel handles this situation by select and rename directives, where the ancestors' methods to use in a descendant are explicitly specified. This allows the methods of the base class to be shared between its descendants or to even give each of them a separate copy of the base class.

§  Perl and Io handle this by specifying the inheritance classes as an ordered list. In the above ambiguity, class B and its ancestors would be checked before class C and its ancestors, so the method in A would be inherited through B. In Perl, this behavior can be overriden using the mro or other modules to use C3 linearization or other algorithms.

§  Python had to deal with this upon the introduction of new-style classes, all of which have a common ancestor, object. Python creates a list of the classes that would be searched in left-first depth-first order (D, B, A, C, A) and then removes all but the last occurrence of any repeated classes. Thus, the method resolution order is: D, B, C, A.

§  Scala resolves method names using a right-first depth-first search of extended 'traits', before eliminating all but the last occurrence of each module in the resulting list. So, the resolution order is: [D, C, A, B, A], which reduces down to [D, C, B, A].

§  JavaFX Script in version 1.2 allows multiple inheritance through the use of mixins. In case of conflict, the compiler prohibits the direct usage of the ambiguous variable or function. Each inherited member can still be accessed by casting the object to the mixin of interest, eg. (individual as Person).printInfo();.

Other examples
Languages that allow only single inheritance (such as Ada, Objective-C, PHP, C#, Delphi/Free Pascal and Java) allow the multiple inheritance of interfaces (called protocols in Objective-C). Interfaces are essentially abstract base classes with all abstract methods and no data members. The problem is therefore avoided since there is always only one implementation of a specific method or property and no ambiguity arises.

The diamond problem is not limited to inheritance. It also arises in languages such as C and C++ when header files A, B, C, and D #include one another in a diamond as above and separate precompiled headers are created from B and C. If these two precompiled headers are combined, declarations in A are duplicated and the #ifndef include guard is ineffective. It also is found when composing middleware stacks; for example, if A is a database and B and C are caches, D may ask both B and C to commit a transaction, resulting in duplicate commit calls to A.

Software Reliability

The IEEE defines reliability as “The ability of a system or component to perform its required functions under stated conditions for a specified period of time.”   

Reliability is equated to correctness, that is, they look to testing and the number of “bugs” found and fixed. While finding and fixing bugs discovered in testing is necessary to assure reliability,

 a better way is to develop a robust, high quality product through all of the stages of the software lifecycle. That is, the reliability of the delivered code is related to the quality of all of the processes and products of software development; the requirements documentation, the code, test plans, and testing.

Software cannot be seen nor touched, but it is essential to the successful use of computers. It is necessary that the reliability of software should be measured and evaluated, as it is in hardware.

IEEE 982.1-1988 defines Software Reliability Management : “The process of optimizing the reliability of software through a program that emphasizes software error prevention, fault detection and removal, and the use of measurements to maximize reliability in light of project constraints such  as resources, schedule and performance.”

Using these definitions, software reliability is comprised of three activities:

1. Error prevention

2. Fault detection and removal

3. Measurements to maximize reliability, specifically measures that support the first two activities There has been extensive work in measuring reliability using mean time between failure and mean time to failure :

Successful modeling has been done to predict error rates reliability . These activities address the first and third aspects of reliability, identifying and removing faults so that the software works as expected with the specified reliability. These measurements have been successfully applied to software as well as hardware. But in this paper, we would like to take a different approach to software reliability, one that addresses the second aspect of reliability, error prevention.

System Analyst @ UNEPP Technology

Job Responsibilities


• Participate in gathering functional & technical requirements to the Integrated System (conduct interviews with business domain experts, map business processes, draft functional requirements specification and obtain counterpart’s concurrence).

• Gathering and documenting functional software requirements as well as other system analysis documentation.

• Evaluate and plan integration between different software packages components. •Define interfaces between system’s components.

• Lead and coordinate requirements elicitation by developing stakeholder requests.

• Prepare Vision documents.

• Prepare Glossary documents.

• Prepare Software Requirements Specifications (SRS).

• Model Use-cases by outlining the system's functionality and delimiting the system.

• Model Sequence diagrams.

• Model Activity diagrams.



Qualifications:

• B.Sc. in Computer Science or Computer Engineering.

• 1+ years directly working as system/business analyst

• Familiar with several analysis patterns.

• Excellent innovation and problem solving skills.

• Excellent communication and leadership skills.

• Excellent documentation and facilitation skills

• Ability to understand new information quickly.

• Knowledge of the business and technology domains are useful additional skills.

• Must have a solid working knowledge of the following:

.- UML modeling

.- Object-Oriented Analysis and Design techniques

.-Hardware and network workload balancing is a plus

.- Hands-on experience with SQL Database is an advantage

•Very Good English both oral and written

http://www.unepp-eg.com/careers/75/system-analyst.html

Junior Software Engineer @ Tawasol INC (0+ years experience)

Tawasol Inc. is one of the leading companies in the Middle East in the field of intelligent mobile solutions. We are looking for innovative people who want to create the greatest application which will be used by millions of users.

We are looking for a motivated and talented fresh graduates who has good experience with numerous mobile OS's and can help shape the direction of our future mobile products. We are looking for someone that isn't afraid to get their hands dirty with some C/C++ code one day and JEE/J2ME code the next day, then turn around and talk to a carrier about the future direction of our mobile products. The ideal candidate will have experience in developing market applications that had successful consumer adoption and shown the ability to architect solutions across several different mobile platforms.

Requirements/Qualifications:

0+ years experience in C/C++ or Java

Experience managing project within a version control system

Must have excellent problem solving skills and love technical challenges.

B.S. Computer Science or Computer Engineering is a must

Further, the ideal junior Developer will have strong verbal and written communication skills, will be a true team player with a commitment to success, and will be able to thrive in a fast-paced, rapidly-changing development environment.

mohamed.galal@tawasolit.com

Uml

Unified Modeling Language
From Wikipedia, the free encyclopedia
Jump to: navigation, search

A collage of UML diagrams.Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering.

UML includes a set of graphical notation techniques to create abstract models of specific systems.

Contents [hide]
1 Overview
2 History
2.1 Before UML 1.x
2.2 UML 1.x
2.3 Development toward UML 2.0
3 Unified Modeling Language topics
3.1 Software Development Methods
3.2 Modeling
3.3 Diagrams overview
3.3.1 Structure diagrams
3.3.2 Behavior diagrams
3.3.2.1 Interaction diagrams
3.4 Meta modeling
4 Criticisms
5 See also
6 References
7 Further reading
8 External links



Overview
The Unified Modeling Language (UML) is an open method used to specify, visualise, construct and document the artifacts of an object-oriented software-intensive system under development.[1] UML offers a standard way to write a system's blueprints, including conceptual components such as:

actors,
business processes and
system's components, and activities
as well as concrete things such as:

programming language statements,
database schemas, and
reusable software components.[2]
UML combines the best practice from data modeling concepts such as entity relationship diagrams, business modeling (work flow), object modeling and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies.[3] UML has succeeded the concepts of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language. UML aims to be a standard modeling language which can model concurrent and distributed systems. UML is not an industry standard, but is taking shape under the auspices of the Object Management Group (OMG). OMG has initially called for information on object-oriented methodologies, that might create a rigorous software modeling language. Many industry leaders have responded in earnest to help create the standard.[1]

UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG. UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 1.0 major revision.


History

History of Object Oriented methods and notation.
[edit] Before UML 1.x
After Rational Software Corporation hired James Rumbaugh from General Electric in 1994, the company became the source for the two most popular object-oriented modeling approaches of the day: Rumbaugh's OMT, which was better for object-oriented analysis (OOA), and Grady Booch's Booch method, which was better for object-oriented design (OOD). Together Rumbaugh and Booch attempted to reconcile their two approaches and started work on a Unified Method.

They were soon assisted in their efforts by Ivar Jacobson, the creator of the object-oriented software engineering (OOSE) method. Jacobson joined Rational in 1995, after his company, Objectory, was acquired by Rational. The three methodologists were collectively referred to as the Three Amigos, since they were well known to argue frequently with each other regarding methodological preferences.

In 1996 Rational concluded that the abundance of modeling languages was slowing the adoption of object technology, so repositioning the work on a Unified Method, they tasked the Three Amigos with the development of a non-proprietary Unified Modeling Language. Representatives of competing Object Technology companies were consulted during OOPSLA '96; they chose boxes for representing classes over Grady Booch's Booch method's notation that used cloud symbols.

Under the technical leadership of the Three Amigos, an international consortium called the UML Partners was organized in 1996 to complete the Unified Modeling Language (UML) specification, and propose it as a response to the OMG RFP. The UML Partners' UML 1.0 specification draft was proposed to the OMG in January 1997. During the same month the UML Partners formed a Semantics Task Force, chaired by Cris Kobryn and administered by Ed Eykholt, to finalize the semantics of the specification and integrate it with other standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in August 1997 and adopted by the OMG in November 1997[4]....


UML 1.x
As a modeling notation, the influence of the OMT notation dominates (e. g., using rectangles for classes and objects). Though the Booch "cloud" notation was dropped, the Booch capability to specify lower-level design detail was embraced. The use case notation from Objectory and the component notation from Booch were integrated with the rest of the notation, but the semantic integration was relatively weak in UML 1.1, and was not really fixed until the UML 2.0 major revision.

Concepts from many other OO methods were also loosely integrated with UML with the intent that UML would support all OO methods. For example CRC Cards (circa 1989 from Kent Beck and Ward Cunningham), and OORam were retained. Many others also contributed, with their approaches flavoring the many models of the day, including: Tony Wasserman and Peter Pircher with the "Object-Oriented Structured Design (OOSD)" notation (not a method), Ray Buhr's "Systems Design with Ada", Archie Bowen's use case and timing analysis, Paul Ward's data analysis and David Harel's "Statecharts"; as the group tried to ensure broad coverage in the real-time systems domain. As a result, UML is useful in a variety of engineering problems, from single process, single user applications to concurrent, distributed systems, making UML rich but also large.

The Unified Modeling Language is an international standard:

ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2

Development toward UML 2.0
UML has matured significantly since UML 1.1. Several minor revisions (UML 1.3, 1.4, and 1.5) fixed shortcomings and bugs with the first version of UML, followed by the UML 2.0 major revision that was adopted by the OMG in 2005[5]. There are four parts to the UML 2.x specification: the Superstructure that defines the notation and semantics for diagrams and their model elements; the Infrastructure that defines the core metamodel on which the Superstructure is based; the Object Constraint Language (OCL) for defining rules for model elements; and the UML Diagram Interchange that defines how UML 2 diagram layouts are exchanged. The current versions of these standards follow: UML Superstructure version 2.1.2, UML Infrastructure version 2.1.2, OCL version 2.0, and UML Diagram Interchange version 1.0[6].

Although many UML tools support some of the new features of UML 2.x, the OMG provides no test suite to objectively test compliance with its specifications.


Unified Modeling Language topics
Software Development Methods
UML is not a development method by itself,[7] however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch method, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notations (for example OMT), and new methods have been created based on UML. The best known is IBM Rational Unified Process (RUP). There are many other UML-based methods like Abstraction Method, Dynamic Systems Development Method, and others, designed to provide more specific solutions, or achieve different objectives.


Modeling
It is very important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The model also contains a "semantic backplane" — documentation such as written use cases that drive the model elements and diagrams.

UML diagrams represent two different views of a system model[8]:

Static (or structural) view: Emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams.
Dynamic (or behavioral) view: Emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.
UML models can be exchanged among UML tools by using the XMI interchange format.


Diagrams overview
UML 2.0 has 13 types of diagrams divided into three categories.[9] Six diagram types represent the structure application, seven represent general types of behavior, including four that represent different aspects of interactions. These diagrams can be categorized hierarchically as shown in the following class diagram:


UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams. This flexibility has been partially restricted in UML 2.0.

In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is always allowed in a UML diagram.
Structure diagrams
Structure diagrams emphasize what things must be in the system being modeled:

Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.
Component diagram: depicts how a software system is split up into components and shows the dependencies among these components.
Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible.
Deployment diagram serves to model the hardware used in system implementations, and the execution environments and artifacts deployed on the hardware.
Object diagram: shows a complete or partial view of the structure of a modeled system at a specific time.
Package diagram: depicts how a system is split up into logical groupings by showing the dependencies among these groupings.
Class diagram
Component diagram
Composite structure diagrams
Deployment diagram

Object diagram
Package diagram


Since structure diagrams represent the structure of a system, they are used extensively in documenting the architecture of software systems.


[edit] Behavior diagrams
Behavior diagrams emphasize what must happen in the system being modeled:

Activity diagram: represents the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
State machine diagram: standardized notation to describe many systems, from computer programs to business processes.
Use case diagram: shows the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.
UML Activity Diagram
State Machine diagram
Use case diagram


Since behaviour diagrams illustrate the behaviour of system, they are used extensively to describe the functionality of software systems.


Interaction diagrams
Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
Interaction overview diagram: are a type of activity diagram in which the nodes represent interaction diagrams.
Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.
Timing diagrams: are a specific type of interaction diagram, where the focus is on timing constraints.
Communication diagram
Interaction overview diagram
Sequence diagram


The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.


[edit] Meta modeling

Illustration of the Meta-Object Facility.The Object Management Group (OMG) has developed a metamodeling architecture to define the Unified Modeling Language (UML), called the Meta-Object Facility (MOF). The Meta-Object Facility is a standard for model-driven engineering, designed as a four-layered architecture, see image. It provides a meta-meta model at the top layer, called the M3 layer. This M3-model is the language used by Meta-Object Facility to build metamodels, called M2-models. The most prominent example of a Layer 2 Meta-Object Facility model is the UML metamodel, the model that describes the UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe real-world objects.

Beyond the M3-model, the Meta-Object Facility describes the means to create and manipulate models and metamodels by defining CORBA interfaces that describe those operations. Because of the similarities between the Meta-Object Facility M3-model and UML structure models, Meta-Object Facility metamodels are usually modeled as UML class diagrams. A supporting standard of Meta-Object Facility is XMI, which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer.


[edit] Criticisms
Although UML is a widely recognized and used modeling standard, it is frequently criticized for the following deficiencies:

Language bloat
UML is often criticized as being gratuitously large and complex.[10] It contains many diagrams and constructs that are redundant or infrequently used. This criticism is more frequently directed at UML 2.0 than UML 1.0, since newer revisions include more design-by-committee compromises.[citation needed]
Weak visualization
[neutrality disputed] UML employs many line styles that are graphically very similar; the meaning resides in permutations of line (dotted or solid) and arrow head (open or closed, filled or empty). The same line style can mean different things in different diagram types.[dubious – discuss] The asterisk is used to signify iteration in behavioural models and parallel multiplicity in structural models.[dubious – discuss] The multiplicity of an association is shown by an annotation disconnected from a line (unlike conventional data model notations).
Problems in learning and adopting
The problems cited above can make learning and adopting UML problematic, especially when required of engineers lacking the prerequisite skills.[11] In practice, people often draw diagrams with the symbols provided by their CASE tool, but without the meanings those symbols are intended to provide.
Only the code is in sync with the code
UML has value in approaches that compile the models to generate source or executable code. This however, may still not be sufficient since it is not clear that UML 2.0's Action Semantics exhibit Turing completeness.[citation needed]
Cumulative Impedance/Impedance Mismatching
As with any notational system, UML is able to represent some systems more concisely or efficiently than others. Thus a developer gravitates toward solutions that reside at the intersection of the capabilities of UML and the implementation language. This problem is particularly pronounced if the implementation language does not adhere to orthodox object-oriented doctrine, as the intersection set between UML and implementation language may be that much smaller.
Aesthetically Inconsistent
This argument states that the adhoc mixing of abstract notation (2-D ovals, boxes, etc) make UML appear jarring and that more effort could have been made to construct uniform and aesthetically pleasing representations.[neutrality disputed]
Tries to be all things to all programmers
UML is a general purpose modeling language that tries to achieve compatibility with every possible implementation language.[dubious – discuss] In the context of a specific project, the most applicable features of UML may be tailored to accomplish the specific goal but the means of tailoring the scope of UML to a particular domain is through formalisms (stereotypes and profiles) that are not completely formed.[12]
Dysfunctional interchange format
While the XMI (XML Metadata Interchange) standard is designed to facilitate the interchange of UML models, it has been largely ineffective in the practical interchange of UML 2.x models. Defining a UML 2.x model in one tool and then importing it into another tool typically leads to loss of information.[citation needed] This interoperability ineffectiveness is attributable to two reasons. Firstly, XMI 2.x is large and complex in its own right, since it purports to address a technical problem more ambitious than exchanging UML 2.x models. In particular, it attempts to provide a mechanism for facilitating the exchange of any arbitrary modeling language defined by the OMG's Meta-Object Facility (MOF). Secondly, the UML 2.x Diagram Interchange specification lacks sufficient detail to facilitate reliable interchange of UML 2.x notations between modeling tools. Since UML is a visual modeling language, this shortcoming is substantial for modelers who don't want to redraw their diagrams.[13]
Modeling experts have written sharp criticisms of UML, including Bertrand Meyer's "UML: The Positive Spin",[10] and Brian Henderson-Sellers in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0