Object Relation And Composition Hierarchy Diagram Final

Smith, Johnson 1 Matt Smith; Trevor Johnson Max Zhang CS477 11 December 2008 The Object Relation and Composition Hierarchy Diagram

Abstract This paper details a new methodology for mapping objects and their relationships in an object oriented system. The new method is called the Object Relation and Composition Hierarchy Diagram (ORCHiD). In contemporary software development, the standard practice is to model real world situations as the interaction between objects. The ORCHiD model takes this paradigm a step further to include how objects are constructed from other objects. This paper includes examples of previously developed diagram types such as a data flow diagrams and communication diagrams. In addition, several ORCHiD diagrams are included to demonstrate the mechanics of how the diagram works, as well as a complete explanation of how to interpret an ORCHiD diagram.

Introduction Modern object oriented systems are becoming more and more complex. Take for example Microsoft’s latest operating system, Windows Vista. The operating system is coded in C and C# and took more than five years to develop and in the end it contains more than 50 million lines of code (Manes 1). Projects such as these undoubtedly require some form of a model to distinguish between different object types and their relationships.

A key feature of objects is that they are frequently constructed from other objects. This can be seen when dealing with inheritance. If one class inherits from another, all of the methods of the

Smith, Johnson 2 parent class are present within the child class. This type of relationship should be represented within a diagram. Other relationships include associations and aggregations. These are important for showing how closely related objects are. Again, it is essential to include these features within a model.

The realization that modern object oriented methodologies such as class diagrams and communication diagrams do not account for the composition of objects serves as the motivation behind developing ORCHiD. For example, a collection of objects, house and rooms, as represented in an entity-relationship diagram does not directly show that the object house is built of objects of type room. The ORCHiD model takes the concept of modeling real world situations as the interaction of objects and their composition. It can be adapted to a software development process by constructing objects from the inside moving outward.

Definition of an Object In ORCHiD objects are defined a little bit different from traditional definitions. An object is a standalone component of a system as well as the system itself and any other entities that interact with the system. The qualifier standalone basically means that if two objects share a recursive existence, that is to say that object A instantiates object B and conversely object B instantiates object A, they are not considered two separate objects but rather they are considered as one object from a system standpoint.

Objects can further be classified into two sub groups based upon the level or tier in which they reside, this level or tier system will be explained shortly. The first of these groups is the systemlevel components, which consists of objects that do not share a compositional relationship and include the system itself. This means that objects that are system-level components are not part of or built from other system-level components. From the previous example of a house there are

Smith, Johnson 3 two system-level components. House is the first; this can be seen from the definition of a systemlevel component that stated that the system itself was a system-level component. Perhaps surprisingly the second system-level component is person, this is because our person is not a part of a house object nor is it built from a house. The second group of components is the subsystemlevel components. These components can be thought of as any components that share a compositional relationship with one another as well as with system-level components. Abstractly, if object A is a system-level component and object B is a part of object A then object B would be considered a subsystem-level component. Additionally, if object C is a part of object B than object C is also a subsystem-level component. From the example of a house, the kitchen, basement, bathroom, bedroom, fridge, and stove would all be subsystem-level components.

Relationships as Interactions There is a number of different ways to model relationships but in the case of ORCHiD relationships will be modeled via the individual objects’ interactions with one another. These interactions can be any data they may exchange or in an abstract sense any services they perform for one another. The decision to model relationships thusly was made in an effort to eliminate that which was unnecessary for the construction of the objects in the relationship. Utilizing the house example, the typical definition of the relationship between house and person would be that one or more persons own zero or more houses. It is this multiplicity that is unnecessary since house and person are constructed independently of how many of them will be present. In ORCHiD the relationship between house and person is defined as follows: a person asks for admittance to a house via the key and the house allows admittance to itself which would be shown as two separate interactions. It is worth noting that the relationship is unidirectional. This is because they are situations in which an object may exchange data with or perform a service for without sending anything back to the object that initiated this interaction. A very basic example of this would be a chair and a person. The person performs the service of sitting on the chair. The chair

Smith, Johnson 4 on the other hand remains static and does nothing in return. The two objects still share a loose relationship but it must be defined in a unidirectional fashion.

Compositional Hierarchy Shown With Topography When one thinks of a compositional hierarchy the first thought is usually something of a tree structure in which the system represents the highest node on the tree. The problem with this interpretation is that although there is a vague sense that objects on the same tier or level of the tree are of the same complexity, this not always the case. In addition to this, one node may have several children nodes beneath it while another node at the same level of the original node may be the leaf node of that particular branch. The only object in which the complexity can be inferred is the system. This complexity can be gauged based upon the spread of the tree. This is suboptimal and so in the case of ORCHiD the compositional hierarchy is modeled as a topography rather than a tree. In some sense this can be seen as a bottom-up approach to viewing the hierarchy because now the system node is the base level or tier of the topography.

In a two dimensional representation of such a topography when additional components are added it begins to spread similar to how the tree did but more visual. As individual objects grow more and more complex in the system they too begin to spread. Almost instantly it can be inferred which object is more complex than the next simply based upon the size of said object. For most small to midlevel systems it is fairly straightforward to create a two dimensional representation of a similar topography but as systems become more complex the size of the topography increases linearly. As a result, for large systems we must consider a three dimensional representation of a topography where once again we start with the system as the base level and build objects that it is composed of on top of it essentially creating mountains. Mountains that are separate from one another or just fork from one another are different objects that compose the lower objects. In this interpretation the volume of a mountain, that is, its altitude and spread can be seen as a measure

Smith, Johnson 5 of complexity. It should be noted that drawing a three dimensional topography is very difficult and in most situations would probably require the use of computer modeling software. It may be possible in large systems to break the diagram apart into its smaller subsystems and model them as a two dimensional topography. It is for this reason that from this point on when we mention topography we are speaking solely of a two dimensional topography rather than the previously mentioned three dimensional topography.

ORCHiD as a Method Once a system has been fully translated into an ORCHiD model it can be seamlessly translated further into a loose method for the construction of the system modeled and even into a collection of tasks in a schedule. This is done by considering the aforementioned topography. It can be thought of abstractly as starting at the innermost object and constructing all other objects on the same tier or level and then moving outward tier by tier until the entire system has been constructed. From the standpoint of a hierarchy tree we are starting at the bottommost leaf nodes and then proceeding upward tier by tier. If each object were considered a task that must be completed then all objects that comprise it would be seen as the predecessors that must be completed in order for the task to begin. Using this knowledge and the inferred complexity of each object based upon their size or spread the time required to construct them can be estimated. It is in this way that standard scheduling and critical path calculations can be achieved. This will be seen in further detail after the demonstration of the ORCHiD model is created.

Comparison of ORCHiD to Other Models ORCHiD’s primary objective is to model objects and how they are composed as well as the relationships between them. Other models have been developed that fulfill a similar purpose or need. However, these models are inferior for various reasons. Some examples of these models

Smith, Johnson 6 include: communication diagrams, entity-relationship diagrams, use cases, and data flow diagrams. These, in conjunction with virtual objects will be discussed in the following sections.

Communication Diagram A communication diagram, as its name suggests, shows communication between objects (O’Docherty 122). This diagram shows relationships between objects as interactions between them. On communication diagrams, objects are shown with association connectors between them. Messages are added to the associations and show as short arrows pointing in the direction of the message flow. The sequence of messages is shown through a numbering scheme (Sparx 1). This makes it very easy to understand how messages are passed within a system and in what order the message passing occurs.

An example of a situation where a communication diagram could be used is if you have a Person object telling a House object to allow access to it. This is accomplished by the Person sending a message, useKey() to a Lock object. The lock in turn sends the message verifyKey() to the House. The house determines whether or not the door to the house should be unlocked. The Person can also interact with a Door Knob object by sending a turns() message. The Door Knob then sends an open() message to the House and the door will open if it is unlocked. The following diagram depicts this situation:

2.0 turns()

1.0 useKey() Person

Door Knob

1.1 verifyKey()

2.1 open() House

Lock

Smith, Johnson 7

As mentioned previously, this diagram is useful for showing how different objects interact. However, it does not show the complexity of how objects are composed. Its simplistic nature allows one to interpret the diagram easily and its sole purpose is to show message passing. This type of diagram is not very useful from a programming standpoint. As one codes a certain piece of software, the communication between objects becomes self evident. Seemingly, only the most complex communication sequences should require some sort of model thus limiting the need for communication diagrams.

Entity Relationship Diagram Generally speaking, an entity-relationship diagram (referred to as an ER diagram) describes the structure of a system. To be more specific, an ER diagram illustrates the interrelationships between entities in a database. ER diagrams often use symbols to represent three different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes (Chapple 1). Another feature of ER diagrams is cardinality. It defines the number of occurrences of one entity for a single occurrence of the related entity. E.g. an employee may process many payments but might not process any payments depending on the nature of her job (CQU 1).

The following ER diagram portrays the properties of a house. As with the communication diagram, the House and Person objects are included in the diagram. Taking it a step further, Bedroom, Bathroom, Basement, Kitchen, Refrigerator, and Stove objects have been added. This style of ER diagram is somewhat different from the one mentioned above, but they achieve the same goal. The boxes represent entities and lines represent relationships between entities. There are three sections within each box. One for the title, one for the primary key, and one for other attributes. The symbols on the lines represent the cardinality. || denotes a one, and a O or |

Smith, Johnson 8 combined with a forked line represent a zero or more, or one or more cardinality, respectively. For instance, the relationship between a Person object and a House object is one to zero or more, or simply one to many. The attributes of the entities have been omitted for simplicity reasons.

The cardinality characteristic of the diagram seems unnecessary. Theoretically, it is up to the programmer to decide how the cardinality works out. Not only that, the information is irrelevant. If two entities have a relationship, the number of entities of each type that can be instantiated does not need to be explicitly known.

Use Case Diagram A use case describes a systems behavior in response to an outside request. A use case diagram captures the functional aspects of a system. More specifically, it captures the business processes carried out in the system. Use case diagrams define the requirements of the system being modeled

Smith, Johnson 9 and hence are used to write test scripts for the modeled system (Chitnis 1). A key benefit of use cases is that they contain no technical aspects. Thus they are highly practical for presenting to stakeholders who have very little technical knowledge. In addition, another facet of use cases is that they consist of a series of steps. This makes tracing a request from start to finish fairly straightforward.

Use case diagrams consist of three main components: actors, the use case itself, and the system boundary. An actor portrays any entity (or entities) that perform certain roles in a given system (Chitnis 1). Examples of actors are users and other systems. They are represented as objects placed outside of the system boundary. A use case in a use case diagram is a visual representation of a distinct business functionality in a system (Chitnis 1). The use case represents a single process that starts with an actor and ends with a resulting system state. A system boundary defines the scope of what a system will be. A system cannot have infinite functionality (Chitnis 1). The system boundary is represented by a rectangle enclosing the use case.

In the house example, the House represents the system boundary. A person acts from outside this system. The person sends a request to use a key on the House. The house then proceeds to verify the key and it will either lock or unlock the door depending on if the key has been determined to be the correct key, and whether or not the door was previously locked or unlocked before the request. The uses key, verify key, lock door, and unlock door portions of the process all occur within the system. In this case, the system does not send a message to any other actor outside the system, but this is a possible scenario depending on the particular use case in question. The subsequent diagram demonstrates this scenario:

Smith, Johnson 10

As previously mentioned, modern object oriented systems are becoming more and more complex. This results in the use case diagram becoming less and less effective. The use case represents an individual request for a service performed by a system. As a system becomes larger the amount of use cases grows exponentially. Although they are useful for performing testing, the sheer number of use cases required for complex systems serves as a deterrent for using them in a practical sense. On top of that, there are also misuse cases, which model actors who are hostile toward the system. They serve as good indicators of weaknesses in a system, but when combined with use cases they simply add more to the total number of cases and also to development costs.

Data Flow Diagram Data flow diagrams, as the name suggests, display the flow of data through a system. They are used to describe how the system transforms information. In addition, they define how information is processed and stored and identify how the information flows through the processes (Borysowich 1). Data flow diagrams consist of a number of components including: processes and functions, external entities, data stores, and data flows. Processes and functions take data as input,

Smith, Johnson 11 do something to it, and output it (Ambler 1). These are represented by rectangles with rounded edges. External entities are sources or destinations of data represented by squares (Ambler 1). Data stores simply contain stored data. The data contained within a store could be a database, a list of items, or virtually any other type of raw data stored in some manner. They are represented by an open ended rectangle. Data flows are arrows that show where and in which direction data travels between entities.

In a simple version of the house example there are two entities, House and Person, and one data store, Lock. The Person sends data called “Key” to the House. The House proceeds to send the “Key” data to the Lock data store. The Lock decides whether the “Key” is valid or not and sends the response back to the House. The House will then open the door, or the door will remain locked and the data will be sent back to the Person. The following diagram displays this situation:

Key

Person

House

Key Lock

Key Response

Data flow diagrams are useful for small and medium sized systems, but for large systems they are not. Tracing the flow of data across a large and complicated system can be difficult. One piece of data could potentially travel across every entity and data store within a system until finally stopping at an entity or reaching an external data source.

Smith, Johnson 12 The data store component of a data flow diagram is unimportant. The data store basically represents a set of data that can be referenced if an entity needs to give or take data to or from the data store, or verify that data is correct, such as checking login information. These steps do not need to be modeled as it is fairly obvious that these things should occur within a system at certain stages. Also, where certain data from outside of an entity comes from does not need to be known, the purpose of a data flow diagram is to show how data is passed between entities.

Virtual Object With a pure virtual object it has no default implementation and must be implemented in a subclass via inheritance. This is the concept behind an interface in Java and C# (Blanchette 633). A virtual object is a more generic version of the object traditionally modeled in a diagram. An example of inheritance is a situation where there is a generic class Room that will never actually be instantiated but will be implemented in subclasses such as Bedroom, Kitchen, etc. The following pseudocode demonstrates the concept of a virtual object:

public class Room() { public int numberOfOutlets; public int roomSize(int length, int width) { // calculate room size in square feet } public class Bedroom() inherits from Room { // Code for class Bedroom }

The class Room() represents a virtual object. It defines an integer numberOfOutlets that stores the amount of electrical outlets contained within a room. It also defines a method called roomSize(int

Smith, Johnson 13 length, int width) that calculates the size of a room in square feet based on the length and width of the room. These two properties are common to all types of rooms and thus the code should not have to be rewritten every time a new type of room is created. This is where inheritance comes in to play. The class Bedroom() inherits from Room() and thus it can use the aforementioned variable and method. All of the models previously discussed do not show virtual objects or inheritance. These concepts become important when dealing with project estimation early in the system development process. When trying to estimate the size and complexity of a system early in the design phase, it is crucial to be aware of and model as many facets as possible. Virtual objects are no exception to this rule. If they are not taken into account an underestimation of the effort required for a project is likely to occur.

ORCHiD The models previously described all serve a specific purpose for modeling a specific facet of a system. The ideas behind these models can be combined to create a completely new model that encompasses several different aspects of system development. The ORCHiD model does just that. The subsequent sections describe the steps involved in creating an ORCHiD diagram. Although the steps do not necessarily have to be performed in this specific order it is strongly recommended.

Step 0: Identifying the scope Upon identifying the system that will be developed it is helpful to understand the true scope of said system. This can be accomplished by listing all objects that are related to the system being developed. In this part it is not necessary to identify the relationships. Once this is achieved all objects must be classified into the two groups mentioned earlier. The first was the system-level components. These are the components that include the system being developed but do not include any objects which have a compositional relationship with one another. This again means

Smith, Johnson 14 that a system-level object is not a part of or composed of other system-level objects but which are in some way related via interactions. The second group was subsystem-level components. These objects do share a compositional relationship which one another and the system-level objects. Any objects which do not maintain compositional relationships with one another and do not interact with the system being developed are considered outside of the scope. Consider the running example of a house, after identifying all objects and classifying them based upon their compositional relationships it will look like this:

System-Level Components House

Subsystem-Level Components Basement

Person

Bathroom Bedroom Fridge Kitchen Stove

Step 1: System-Level Composition Begin by pulling all subsystem-level components inside the system-level components that they compose. It is at this step that we begin the formation of a diagram in which all objects regardless of tier or level are represented as circles. For the sake of simplification any system-level components that are not composed of any subsystem-level components may be ignored for the moment. We will come back to them in step 3. Doing this for the example house gives the following diagram:

Smith, Johnson 15

As you can see all objects that were listed as subsystem-level have been placed inside the systemlevel component house. Person has been left off of the diagram since it is not composed of any subsystem-level components and isn't need until we begin mapping relationships.

Step 2: Subsystem-Level Composition In much the same way that subsystem-level components were pulled inside system-level components in step 1 we will proceed to replicate this for subsystem-level components. This can be done by selecting a single subsystem-level component and pulling all other subsystem-level components that compose it into its interior. This is repeated at the next subsystem-level component until they have all been dealt with. Now the model has the trappings of a topography representing a leveled compositional hierarchy.

All that is left of the second step is modeling the participation constraints on individual objects and the objects they compose. Objects with optional participation are considered to have an association relationship with the object they compose. This means that they are not necessary for the super object to exist. A Super object is the object directly composed of the object in question.

Smith, Johnson 16 The opposite of this would be those objects with mandatory participation. These are considered to have an aggregation relationship in that they are required for the super object to exist. Those objects that have an association with their super objects are shown with a dotted line around them rather than the solid line which indicates an aggregation.

As you can see from the example shown above, the only object in house that is composed of further subsystem-level objects is the kitchen which for our example consists of a stove object and a fridge object. They have subsequently been pulled inside of their super object, the kitchen. Also shown at this step is the addition of participation constraints. As such the only object that does not share a mandatory or aggregation with its super object is the object basement since a house need not have a basement to be a house. This is in contrast to say the bathroom which a house must have to be considered a house. The basement is thusly seen with a dotted line rather than a solid line so that it can be instantly differentiated from those objects that share aggregation with their super objects.

Smith, Johnson 17 In short, the first and second steps of the ORCHiD modeling process firmly establish the compositional hierarchy of the system being developed much in the same way that step zero establishes the scope of the system. It is this step that compositional relationships are modeled in the form of participation constraints between subsystem-level components and their respective super objects. All that is left is to model the relationships between system-level components and add support for virtual classes as discussed earlier.

Step 3: System-Level relationships It is in this step that system-level relationships are added in the form of unidirectional interactions which can be recalled as the exchange of data or services between objects. It is at this stage that any system-level objects that were previously ignored since they did not have a compositional structure must be put into the model. Remembering step zero we still omit any system-level components that do not interact with the system as they are still outside the scope of the project. This can be seen below:

Smith, Johnson 18 From the house example our two system-level objects are house which in steps one and two we constructed through its compositional hierarchy and person which until this point we have ignored. These two objects interact with one another via two unidirectional interactions. The first being the person sending house the data key which then must be verified by the house before it returns the second interaction in the form of locking or unlocking. In this scenario the first interaction shows the exchange of data from person to house but the second shows the exchange of a service from house to person. In reality there are a number of other interactions that can take place between house and person but for the sake of simplification we have chosen to just show the act of locking or unlocking the house. Thanks to the circular nature of our objects it is easy to add as many unidirectional interactions as necessary without cluttering the diagram as would be the case if objects were represented as rectangles.

Step 4: Adding Virtual Objects Although this step could be considered optional by the definition of ORCHiD as a model for object relations and compositional hierarchies it should still be included in the diagram if possible. Remember our definition of a virtual object as any object that will never be instantiated but will be inherited by other objects that may or may not themselves be instantiated. The biggest reason that it is important to include these virtual objects in our model is that from a programming perspective they still need to be constructed just like any other object even though they don't interact with other objects. Also, the goal of ORCHiD is to easily and visually allow for an estimation of how complex a system is. It is for this reason that virtual objects must be added to the model; however, if the models intent is to be a loose framework to build a time or cost estimate it is not always needed. Conversely, if the model is intended to be used as a blue print for the construction of the system then it is highly recommended that this step be included.

Smith, Johnson 19 Since virtual objects are different from other objects in the system they must be visually represented differently. We have chosen to represent any virtual object as a rectangle for this purpose. To tether the objects that inherit a virtual object to it we use something visually distinct from the arrows used in modeling interactions. In this case the metaphor applied is that an object that inherits from another object is anchored to it and as a result an anchor is used to show this inheritance. This can be seen in the model below:

As seen in the above figure the objects bedroom, bathroom, kitchen and basement are all inherited from the virtual object room. It may also be import to note that this inheritance does not affect the participation constraints enforced on the objects of the system and it is unimportant to show whether house and room share an association or aggregation since room will never be instantiated.

Smith, Johnson 20 ORCHiD as a method for time and cost estimation The use of ORCHiD as a method for creating time or cost estimates can at best be considered a loose estimation as it is essentially based on the practice of consensual estimation. Each object is considered a task that must be accomplished and a selection of seasoned system developers can estimate the time it might take to construct the objects in the system.

The process of creating the task schedule is more straightforward and requires less estimation as long as we work under the assumption that before an object can begin being constructed all sub objects - that is, the objects that compose it - must first be completed. When we are defining predecessors we are only concerned with sub objects on the tier directly below the object in question. If this method is undertaken to determine the schedule for the house example the table of predecessors should be the following:

Task

Object

Predecessors

Time

A

Stove

2

B

Fridge

5

C

Room

4

D

Basement

C

1

E

Bedroom

C

2

F

Bathroom

C

3

G

Kitchen

A,B,C

4

H

House

D,E,F,G

Note that we have included the room object in this schedule despite it not being necessary to produce an estimation. Its inclusion however should allow the estimate to be more accurate. The inclusion of virtual objects is again recommended but completely at the discretion of the user.

Smith, Johnson 21 Assuming that consensual estimation has provided valid numbers for the length of time required to construct each object, this information can be used to create many different kinds of tools such as Gantt charts, Activity on Arrow Diagrams and Activity on Node Diagrams. For the sake of our example we will construct the latter in order to perform critical path calculations.

A brief recap of the critical path method - The critical path can be thought of as the path that connects objects that if one falls behind the entire project falls behind. It is useful to highlight problem areas or tasks that must be given extra care to keep on schedule. The critical path is determined by objects with zero slack time and the path that connects them. Slack time is the difference between the latest start time and the earliest in which the project will still be completed on schedule.

Now that it is apparent what objects must be constructed before others can begin, approximately how long it will take to construct these objects, and using the aforementioned activity on node diagram we can construct the figure below:

Smith, Johnson 22

4 A

2

G

F

B

3

5 H 2 E

C

4

1 D

4

We perform a forward pass to indicate the earliest start times for each task and the earliest completion time for the system. This is then followed up by performing a backward pass to determine the latest start time for each task in which the system as a whole will still be developed on time. After this is complete the calculation of slack time can easily be done and it becomes apparent which tasks represent the critical path. All of this can be seen in the following figure:

Smith, Johnson 23

A |2 | 3 0| 5 0| 5

2

G|4|0 5| 9 5| 9

4

B |5 | 0 0| 5 0| 5

5

F|3|2 4| 7 6| 9

3

H Duration: 9

C | 4 |1 0| 4 1| 5

4

E |2 | 3 4| 6 7| 9

2

4

D | 1 |4 4| 5 8| 9

1

In the preceding figure each task is represented in terms of its numerical data. The task name, task duration, and slack time are on the first row. The earliest start time and the earliest ending time are on the second row. The latest start date and latest end date are on the third row. The critical path is represented by the tasks linked with the bolded arrows. The final piece of information that can be obtained from the diagram is that the development of the house system will take an estimated 9 Days as per the times given by the experts during the consensual estimation.

Conclusions The complex nature of modern object oriented systems makes it increasingly difficult to model these systems. Frequently objects are being constructed from other objects. This leads to the objects themselves becoming increasingly complex. As software evolves and increases in size and complexity, new modeling solutions are required to keep up with the ever changing nature of software systems.

Smith, Johnson 24 Current software models are inadequate for modeling contemporary systems. Although the particular models that were discussed earlier fulfill a certain objective, they fail to combine several functions as the ORCHiD model does. A diagram that shows multiple roles is essential for showing the true nature of a system. For instance, a communication diagram shows communication between objects. This information may be helpful but the scope of the system cannot be grasped from this single diagram that serves a single purpose.

The ORCHiD model combines several features of existing models into one relatively simple diagram. It takes into consideration the interactions between objects similar to a communication diagram and use case diagram, the modeling of objects similar to an ER diagram, and the possibility of virtual objects that are not modeled in traditional diagrams. Additionally, it models the exchange of data or services similar to a data flow diagram. This, along with the compositional hierarchy of objects is the basis of the ORCHiD model.

ORCHiD is directly translatable into a software process. To reiterate, the diagram shows how individual objects are composed of other objects. Again, the size of each component within the diagram conveys the relative complexity of each object. The combination of these two features results in the ability to create a task schedule through consensual estimation.

The ORCHiD model is flexible in the sense that it can be applied to systems of varying size. Small, easy to understand systems can be represented with ease as can large, complicated systems. The ORCHiD model combines several aspects of systems modeling to produce an easy to understand diagram but every aspect of a system cannot be modeled in a logical and coherent manner within a single diagram. ORCHiD has its shortcomings as does any other model currently available but ORCHiD’s design allows it to be well equipped for the demands of modern systems.

Smith, Johnson 25 References Ambler, Scott W. “Data Flow Diagrams (DFDs). AgileModeling.com. 8 December 2008. . Blanchette, Jasmin, and Summerfield, Mark. C++ GUI Programming With QT4 2nd Edition. Prentice Hall, 2008. Borysowich, Craig. 19 February 2007. “Data Flow Diagrams (DFDs). Toolbox.com. 8 December 2008. . Central Queensland University. “Developing Entity Relationship Diagrams (ERDs). CQU.edu. 7 December 2008.. Chapple, Mike. “Entity-Relationship Diagram”. About.com. 7 December 2008. . Chitnis, Mandar, Tiwari, Pravin, Ananthamurthy, Lakshmi. “Creating Use Case Diagrams”. Developer.com. 7 December 2008. . Manes, Stephen. 26 February 2007. “Dim Vista”. Forbes. 6 December 2008. . O’ Docherty, Mike. Object Oriented Analysis and Design. John Wyley and Sons Ltd, 2005. Sparx Systems. “UML 2 Communication Diagrams”. SparxSystems.com. 7 December 2008.

.

Smith, Johnson 26