| History of OOAD |
|
| History of OOAD methods |
|
| What is OOAD? |
|
| Object-Oriented Analysis and Design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML). |
|
| Object-Oriented Analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-Oriented Design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it. |
|
|
| An object-oriented system is composed of objects. The behavior of the system results from the collaboration of those objects. Collaboration between objects involves them sending messages to each other. Sending a message differs from calling a function in that when a target object receives a message, it itself decides what function to carry out to service that message. The same message may be implemented by many different functions, the one selected depending on the state of the target object or objects. |
|
| The implementation of "message sending" varies depending on the architecture of the system being modeled, and the location of the objects being communicated with. |
|
|
| History of OOAD Methods |
|
| The development of computer science as a whole proceeded from an initial concern with programming alone, through increasing interest in design, to concern with analysis methods only latterly. Reflecting this perhaps, interest in object-orientation also began, historically, with language developments. It was only in the 1980s that object-oriented design methods emerged. Object-Oriented Analysis methods emerged during the 1990s. |
| Apart from a few fairly obscure AI applications, up until the 1980s object-orientation was largely associated with the development of graphical user interfaces (GUIs) and few other applications became widely known. Up to this period not a word had been mentioned about analysis or design for object-oriented systems. In the 1980s Grady Booch published a paper on how to design for Ada but gave it the prophetic title: Object-Oriented Design.Booch was able to extend his ideas to a genuinely object-oriented design method by 1991in his book with the same title. |
|
| With the 1990s came both increased pressures on business and the availability of cheaper and much more powerful computers. This led to a ripening of the field and to a range of applications beyond GUIs and AI. Distributed, open computing became both possible and important and object technology was the basis of much development, especially with the appearance of n-tier client-server systems and the web, although relational databases played and continue to play an important role. The new applications and better hardware meant that mainstream organizations adopted object-oriented programming and now wanted proper attention paid to object-oriented design and (next) analysis. Concern shifted from design to analysis from the start of the 1990s. An object-oriented approach to requirements engineering had to wait even longer. |
|
| In 1994 there were over 72 methods or fragments of methods. The OO community soon realized that this situation was untenable if the technology was to be used commercially on any significant scale They also realized that most of the methods overlapped considerably. Therefore, various initiatives were launched aimed at merging and standardizing methods. |
|
| Thus far, to the eyes of the developer there appeared a veritable soup of object-oriented analysis and design methods and notations. It was an obvious development to try to introduce some kind of unification and the Fusion method (Coleman et al., 1994; Malan et al., 1996) represents one of the first attempts to combine good techniques from other published methods, although some commentators have viewed the collection of techniques as poorly integrated. There is a process associated with Fusion although published descriptions of it appear incomplete compared to the proprietary versions sold by Hewlett-Packard. The modern object-oriented developer had to find a way to pick out the noodles from this rich soup of techniques. Because of this and because there were many similarities between methods it began to be felt by most methodologists that some sort of convergence was in order. |
|
| The OPEN Consortium was an informal group of about 30 methodologists, with no common commercial affiliation, that wanted to see greater method integration but felt strongly that methods should include a complete process, should be in the public domain, should not be tied to particular tools and should focus strongly on scientific integrity as well as pragmatic issues. The founding members of OPEN were Brian Henderson-Sellers and myself who began to integrate the MOSES and SOMA process models. The result was published asGraham et al. (1997b). They were soon joined by Don Firesmith who started work on an integrated notation (OML) with the aim of exhibiting a more pure object-oriented character than the OMT-influenced UML and one that would be easier to learn and remember (Firesmith et al., 1997). |
|
| Jim Rumbaugh left GE to join Grady Booch at Rational Inc. These two merged their notations into what became the first version of UML (Booch et al., 1999). |
|
|
|
|
| Introduction to Software Engineering |
|
| Software Engineering Approaches |
|
| Software engineering (SE) is concerned with developing and maintaining software systemsthat behave reliably and efficiently, are affordable to develop and maintain, and satisfy all the requirements that customers have defined for them. It is important because of the impact of large, expensive software systems and the role of software in safety-critical applications. It integrates significant mathematics, computer science and practices whose origins are in engineering. |
|
| Since the dawn of computing in the 1940s, the applications and uses of computers have grown at a staggering rate. Software plays a central role in almost all aspects of daily life: in government, banking and finance, education, transportation, entertainment,medicine, agriculture, and law. The number, size, and application domains of computer programs have grown dramatically; as a result, hundreds of billions are being spent on software development, and the livelihood and lives of most people depend on the effectiveness of this development. Software products have helped us to be more efficient and productive. They make us more effective problem solvers, and they provide us with an environment for work and play that is often safer, more flexible, and less confining. Despite these successes, there are serious problems in the cost, timeliness, and quality of many software products. |
|
|
| The reasons for these problems are many and include the following: |
|
- Software products are among the most complex of man-made systems, and software by its very nature has intrinsic, essential properties (e.g., complexity,invisibility, and changeability) that are not easily addressed.
- Programming techniques and processes that worked effectively for an individual or a small team to develop modest-sized programs do not scale-up well to the development of large, complex systems (i.e., systems with millions of lines of code, requiring years of work, by hundreds of software developers).
- The pace of change in computer and software technology drives the demand for new and evolved software products. This situation has created customer expectations and competitive forces that strain our ability to produce quality of software within acceptable development schedules.
|
|
|
| It has been over thirty-five years since the first organized, formal discussion of software engineering as a discipline took place at the 1968 NATO Conference on Software Engineering [Naur 1969]. The term “software engineering” is now widely used in industry, government, and academia: hundreds of thousands of computing professionals go by the title “software engineer”; numerous publications, groups and organizations, and professional conferences use the term software engineering in their names; and there are many educational courses and programs on software engineering. However, there are still disagreements and differences of opinion about the meaning of the term. The following definitions provide several views of the meaning and nature of software engineering. Nevertheless, they all possess a common thread, which states, or strongly implies that software engineering is more than just coding - it includes quality, schedule and economics, and the knowledge and application of principles and discipline. |
| Software is often found in products and situations where very high reliability is expected, even under demanding conditions, such as monitoring and controlling nuclear power plants, or keeping a modern airliner aloft. Such applications contain millions of lines of code, making them comparable in complexity to the most complex modern machines. For example, a modern airliner has several million physical parts (and the space shuttle about ten million parts), while the software for such an airliner can run to 4 million lines of code. |
|
|
| Definitions of Software Engineering |
|
| Over the years, numerous definitions of the discipline of Software Engineering have been presented. For the purpose of this document, we highlight the following definitions: |
|
- "The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines" [Bauer 1972].
- "Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems." [CMU/SEI-90-TR-003]
- "The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software" [IEEE 1990].
|
|
| There are aspects of each of these definitions that contribute to the perspective of software engineering used in the construction of this volume. One particularly important aspect is that software engineering builds on computer science and mathematics. But, in the engineering tradition, it goes beyond this technical basis to draw upon a broader range of disciplines. |
|
|
|
|
| Introduction to Software Engineering |
|
| Software Engineering Approaches |
|
|
| Responsibility-driven versus data-driven approaches |
|
| It is often said that data are more stable than functions and so data-centred approaches are to be preferred in most cases. However, one of the greatest dangers in adopting a method based too much on structured techniques is that of data-driven design. Two software engineers at Boeing conducted an experiment with internal trainees with similar backgrounds. One group was taught the data-driven Shlaer/Mellor method of object-oriented analysis - a method consciously and deeply rooted in traditional entity-relationship modelling - while the other group was instructed in the Responsibility Driven Design techniques of Wirfs-Brock et al. (1990). The two groups were then asked to design a simplified control application for a brewery. The Shlaer-Mellor group produced a design wherein most of the classes represented static data stores while one class accessed these and encapsulated the control rules for most of the application: in much the same style as amain{} routine in C would do. The other group distributed the behaviour much more evenly across their classes. It was seen that this latter approach produced far more reusable classes: classes that could be unplugged from the application and used whole. It also demonstrated vividly that the method you use can influence the outcome profoundly. It is our firm conviction that data-driven methods are dangerous in the hands of the average developer and especially in the hands of someone educated or experienced in the relational tradition. Furthermore, We hold that the approach taken to requirements engineering can have a huge influence. |
|
| The study by Sharble and Cohen shows convincingly that data-driven methods do influence the thinking of designers and that they tend to produce un-reusable classes as a consequence. |
|
|
| The usual effects are that: |
|
- behavior is concentrated in controller objects that resemble main routines; this makes systems much harder to maintain due to the amount of knowledge that these controllers store about other objects;
- other objects have few operations and are often equivalent to normalized database tables: not reflective therefore of sound object-oriented design.
|
|
| Translational versus elaborational approaches |
|
| Another important way in which we may classify object-oriented methods is as either translational or elaborational. Methods like Booch, OMT and RUP are evangelistically elaborational. They treat the passage from specification to impleTranslational versus elaborational approachesmentation as a matter of creating an initial model and then adding more and more detail (elaborating) until eventually we press a button and the compiled code pops out. |
| Translational approaches, among which Shlaer-Mellor was the paradigm, regard the process as a sequence of separate models together with a procedure for linking them and translating from one to the next. Thus we can use the most appropriate modelling techniques and viewpoints at each stage of our thinking about the problem but still guarantee seamlessness and traceability. Catalysis and SOMA fall inter alia into this camp and the next section will exemplify the approach. |
|
|
| Modeling Language |
|
| A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure. |
|
|
|
|
| Introduction to UML |
|
| Evolution of UML |
|
| Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as various methodologists experimented with different approaches toobject-oriented analysis and design. The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the "method wars." By the mid-1990s, new iterations of these methods began to appear and these methods began to incorporate each other’s techniques, and a few clearly prominent methods emerged. |
|
| The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh ofRational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method. |
|
|
| As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. First, these methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they could bring some stability to theobject-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well. |
|
| The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and0.91 documents in June and October of 1996. During 1996, the UML authors invited and received feedback from the general community. They incorporated this feedback, but it was clear that additional focused attention was still required. |
| While Rational was bringing UML together, efforts were being made on achieving the broader goal of an industry standard modeling language. In early 1995, Ivar Jacobson (then Chief Technology Officer of Objectory) and Richard Soley (then Chief Technology Officer of OMG) decided to push harder to achieve standardization in the methods marketplace. In June 1995, an OMG-hosted meeting of all major methodologists (or their representatives) resulted in the first worldwide agreement to seek methodology standards, under the aegis of the OMG process. |
|
| During 1996, it became clear that several organizations saw UML as strategic to their business. A Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a joint RFP response. Rational established the UML Partners consortium with several organizations willing to dedicate resources to work toward a strong UML 1.0 definition. Those contributing most to the UML 1.0 definition included: Digital Equipment Corp., HP, i-Logix, IntelliCorp,IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, andUnisys. This collaboration produced UML 1.0, a modeling language that was well defined, expressive, powerful, and generally applicable. This was submitted to the OMG in January 1997 as an initial RFP response. |
|
| In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam also submitted separate RFP responses to the OMG. These companies joined the UML partners to contribute their ideas, and together the partners produced the revised UML 1.1 response. The focus of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. It was submitted to the OMG for their consideration and adopted in the fall of 1997. |
|
| 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.0major revision, which is the current OMG standard. |
|
| The first part of UML 2.0, the Superstructure which describes the new diagrams and modeling elements available, was adopted by the OMG in October 2004. Other parts of UML 2, notably the infrastructure, the Object Constraint Language (OCL) and the diagram interchange were yet to be completed and ratified as of November 2005. |
|
| The final UML 2.0 specification has been declared available and has been added to OMG's formal specification library. The other parts of the UML specification, the UML 2.0 infrastructure, the UML 2.0 Diagram Interchange, and UML 2.0 OCL specifications have been adopted. |
|
| The current version available is 2.1.1 (August 2007) and is available in the form of an XMI 2.1 version of the UML 2.1 version. The corresponding XMI 2.1 file is made available from the OMG. The version 2.2 is currently under development. |
| Most of the commercially successful UML tools now support most of UML 2.0, leaving only the rarely used features left to implement. Of course, it will take some time for the tools that are in the hands of the developers to reach this level of compliance. |
|
|
|
|
| Introduction to UML |
|
| Pros and Cons of UML |
|
| Use of the Unified Modeling Language (UML) has quickly spread throughout the software development industry as a concrete foundation for designing and developing software applications. It has become the defacto standard in the world of object-oriented systems and is becoming essential for component-based development (CBD). For IT professionals looking for key career differentiators, UML experience will be a critical element if it isn’t already. |
|
| One benefit of UML is that it greatly improves the communication of system design to all stakeholders of a software system. It achieves this by providing an economy of semantics and notation, as well as a language for constraining designs, called the object constraint language (OCL). Designs are expressed independently of any programming language or development process, allowing analysts, managers, modelers, and developers of varying technical expertise to readily share designs via UML models. |
|
|
| UML provides a standard way of visually modeling object-oriented systems through diagramming views, such as use case, class, interaction, statechart, activity, and implementation diagrams. Each diagram provides a way to express important aspects of the system design. Use case diagrams model the functionality of a system. Class diagrams model the static structure of a system. Interaction diagrams model the collaborations among classes in achieving scenarios, or threads of action, within a use case. Statechart diagrams model the precise behavior of classes, methods, or components. Activity diagrams support business process modeling. Implementation diagrams model the dependencies among software components and the run-time infrastructure that executes them. |
|
| UML is also extensible and customizable through the use of stereotypes and tags.Stereotypes and tags can be grouped into profiles that are applied to specific modeling domains. Profiles add the flexibility to UML that allows modelers to customize UML to specific modeling environments. Several profiles are currently being standardized for UML. These include profiles for enterprise distributed object computing (EDOC), CORBA, EJB,EAI, and Real-Time. |
| UML profiles provide a higher level of abstraction for designing systems. For example,EDOC is an abstraction above CORBA, EJB, or COM+ profiles, which pertain to specific component technologies. Profiles can be stacked on top of one another and related through a mapping. For example, a business model may map to an EDOC model, which can then map to either a CORBA, EJB, or COM+ model. This will allow designers to separate design solutions from implementation technologies, thus preserving these solutions as technologies continue to change. |
|
|
| Pros and Cons of UML |
|
| Pros: |
- Wide Industry Acceptance in comparison to previous Modeling Language.
- Supports OOAD methodology
- Bridges the communication gap between different entities of system development(i.e . System Analyst, Developer, Client etc)
- Constructed models are easy to understand, even for non-programmers
- Unified and Standardize Modeling language.
|
|
| Cons: |
- UML is often criticized as being gratuitously large and complex
- Too Complex to learn and Getting started with
- Tries to be all things to all people.
|
|
|
|
|
| Getting Started With UML |
|
| Diagrams in UML |
|
| UML 2 defines many basic diagram types, divided into two general sets: |
|
| 1. Structural Modeling Diagrams |
| Structure diagrams define the static architecture of a model. They are used to model the 'things' that make up a model - the classes, objects, interfaces and physical components. In addition, they are used to model the relationships and dependencies between elements. |
|
| 2. Behavioral Modeling Diagrams |
| Behavior diagrams capture the varieties of interaction and instantaneous states within a model as it 'executes' over time; tracking how the system will act in a real-world environment, and observing the effects of an operation or event, including its results. |
|
|
| The underlying premise of UML is that no one diagram can capture the different elements of a system in its entirety. Hence, UML is made up of nine diagrams that can be used to model a system at different points of time in the software life cycle of a system. |
|
|
| The UML diagrams are: |
- Use case diagram: The use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases." The use case diagram shows which actors interact with each use case.
- Class diagram: The class diagram is used to refine the use case diagram and define a detailed design of the system. The class diagram classifies the actors defined in the use case diagram into a set of interrelated classes. The relationship or association between the classes can be either an "is-a" or "has-a" relationship. Each class in the class diagram may be capable of providing certain functionalities. These functionalities provided by the class are termed "methods" of the class. Apart from this, each class may have certain "attributes" that uniquely identify the class.
- Object diagram: The object diagram is a special kind of class diagram. An object is an instance of a class. This essentially means that an object represents the state of a class at a given point of time while the system is running. The object diagram captures the state of different classes in the system and their relationships or associations at a given point of time.
- State diagram: A state diagram, as the name suggests, represents the different states that objects in the system undergo during their life cycle. Objects in the system change states in response to events. In addition to this, a state diagram also captures the transition of the object's state from an initial state to a final state in response to events affecting the system.
- Activity diagram: The process flows in the system are captured in the activity diagram. Similar to a state diagram, an activity diagram also consists of activities, actions, transitions, initial and final states, and guard conditions.
- Sequence diagram: A sequence diagram represents the interaction between different objects in the system. The important aspect of a sequence diagram is that it is time-ordered. This means that the exact sequence of the interactions between the objects is represented step by step. Different objects in the sequence diagram interact with each other by passing "messages".
- Collaboration diagram: A collaboration diagram groups together the interactions between different objects. The interactions are listed as numbered interactions that help to trace the sequence of the interactions. The collaboration diagram helps to identify all the possible interactions that each object has with other objects.
- Component diagram: The component diagram represents the high-level parts that make up the system. This diagram depicts, at a high level, what components form part of the system and how they are interrelated. A component diagram depicts the components culled after the system has undergone the development or construction phase.
- Deployment diagram: The deployment diagram captures the configuration of the runtime elements of the application. This diagram is by far most useful when a system is built and ready to be deployed.
|
|
| Now that we have an idea of the different UML diagrams, let us see if we can somehow group together these diagrams to enable us to further understand how to use them. |
|
|
|
|
| Getting Started With UML |
|
| Structural Modeling Diagrams |
|
| Structure diagrams define the static architecture of a model. They are used to model the'things' that make up a model - the classes, objects, interfaces and physical components. In addition, they are used to model the relationships and dependencies between elements. |
|
|
- Package diagrams are used to divide the model into logical containers, or'packages', and describe the interactions between them at a high level.
- Class or Structural diagrams define the basic building blocks of a model: the types, classes and general materials used to construct a full model.
- Object diagrams show how instances of structural elements are related and used atrun-time.
- Composite Structure diagrams provide a means of layering an element's structure and focusing on inner detail, construction and relationships.
- Component diagrams are used to model higher level or more complex structures, usually built up from one or more classes, and providing a well defined interface.
- Deployment diagrams show the physical disposition of significant artifacts within areal-world setting.
|
|
|
|
|
| Getting Started With UML |
|
| Behavioral Modeling Diagrams |
|
| Behavior diagrams capture the varieties of interaction and instantaneous states within a model as it 'executes' over time; tracking how the system will act in a real-world environment, and observing the effects of an operation or event, including its results. |
|
|
- Use Case diagrams are used to model user/system interactions. They definebehavior, requirements and constraints in the form of scripts or scenarios.
- Activity diagrams have a wide number of uses, from defining basic program flow, to capturing the decision points and actions within any generalized process.
- State Machine diagrams are essential to understanding the instant to instant condition, or "run state" of a model when it executes.
- Communication diagrams show the network, and sequence, of messages or communications between objects at run-time, during a collaboration instance.
- Sequence diagrams are closely related to communication diagrams and show the sequence of messages passed between objects using a vertical timeline.
- Timing diagrams fuse sequence and state diagrams to provide a view of an object's state over time, and messages which modify that state.
- Interaction Overview diagrams fuse activity and sequence diagrams to allowinteraction fragments to be easily combined with decision points and flows.
|
|
|
|
|
| Structural Modeling Diagrams |
|
| Package diagrams |
|
| In the Unified Modeling Language(UML), a package diagram depicts how a system is split up into logical groupings by showing the dependencies among these groupings. As a package is typically thought of as a directory, package diagrams provide a logical hierarchical decomposition of a system. |
|
|
| Packages are usually organized to maximize internal coherence within each package and to minimize external coupling among packages. With these guidelines in place, the packages are good management elements. Each package can be assigned to an individual or team, and the dependencies among them indicate the required development order. |
|
|
|
|
| Package diagrams are used to reflect the organization of packages and their elements. When used to represent class elements, package diagrams provide a visualization of thenamespaces. The most common use for package diagrams is to organize use case diagrams and class diagrams, although the use of package diagrams is not limited to these UML elements. |
|
| Packages are represented in UML 2.1 as folders and contain the elements that share a namespace; all elements within a package must be identifiable, and so have a unique name or type. The package must show the package name and can optionally show the elements within the package in extra compartments. |
|
| 1. Package Merge |
| A «merge» connector between two packages defines an implicit generalization between elements in the source package, and elements with the same name in the target package. The source element definitions are expanded to include the element definitions contained in the target. The target element definitions are unaffected, as are the definitions of source package elements that don't match names with any element in the target package. |
|
| 2. Package Import |
| The «import» connector indicates that the elements within the target package, which in this example is a single class, use unqualified names when being referred to from the source package. The source package's namespace gains access to the target classes; the target's namespace is not affected. |
|
| 3. Nesting Connectors |
| The nesting connector between the target package and source packages shows that the source package is fully contained in the target package. |
|
|
|
|
| Structural Modeling Diagrams |
|
| Class Diagram |
|
| In the Unified Modeling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, theirattributes, and the relationships between the classes. |
|
|
| The class diagram models the data elements in the system,the ways in which they are grouped together and the relationships between them. Class diagrams have at their heart data and behaviour that are unlikely to change frequently and are relatively stable. The object instances will change frequently. The class diagram shows the building blocks of anyobject-orientated system. Class diagrams depict a static view of the model, or part of the model, describing what attributes and behavior it has rather than detailing the methods for achieving operations. Class diagrams are most useful in illustrating relationships betweenclasses and interfaces. Generalizations, aggregations, and associations are all valuable in reflecting inheritance, composition or usage, and connections respectively. |
|
| The diagram below illustrates aggregation relationships between classes. The lighter aggregation indicates that the class "User Account" uses UserAddressBook, but does not necessarily contain an instance of it. The strong, composite aggregations by the other connectors indicate ownership or containment of the source classes by the target classes, for example ContactDetails and ContactGroup values will be contained inUserAddressBook. |
|
|
|
|
| Classes are composed of three things: a name, attributes, and operations. Below is an example of a class. Class diagrams also display relationships such as containment,inheritance, associations and others. Below is an example of an associative relationship: |
|
|
|
|
|
| The association relationship is the most common relationship in a class diagram. The association shows the relationship between instances of classes. For example, the class Order is associated with the class Customer. The multiplicity of the association denotes the number of objects that can participate in then relationship. For example, an Order objectcan be associated to only one customer, but a customer can be associated to many orders. |
|
|
|
|
| Another common relationship in class diagrams is a generalization. A generalization is used when two classes are similar, but have some differences. |
|
| Look at the generalization below: |
|
|
|
|
| In this example the classes Corporate Customer and Personal Customer have some similarities such as name and address, but each class has some of its own attributes and operations. The class Customer is a general form of both the Corporate Customer and Personal Customer classes. This allows the designers to just use the Customer class for modules and do not require in-depth representation of each type of customer. |
|
|
| When to Use: Class Diagrams |
| Class diagrams are used in nearly all Object Oriented software designs. Use them to describe the Classes of the system and their relationships to each other. |
|
| How to Draw: Class Diagrams |
| Class diagrams are some of the most difficult UML diagrams to draw. To draw detailed and useful diagrams a person would have to study UML and Object Oriented principles for a long time. |
|
| Before drawing a class diagram consider the three different perspectives of the system the diagram will present; conceptual, specification, and implementation. Try not to focus on one perspective and try see how they all work together. |
|
| When designing classes consider what attributes and operations it will have. Then try to determine how instances of the classes will interact with each other. These are the very first steps of many in developing a class diagram. However, using just these basic techniques one can develop a complete view of the software system. |
|
|
|
|
| Structural Modeling Diagrams |
|
| Object Diagrams |
|
| In the Unified Modeling Language (UML), an object diagram is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time. This snapshot focuses on some particular set of object instances and attributes, and the links between the instances. A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. Object diagrams are more concrete than class diagrams, and are often used to provide examples, or act as test cases for the class diagrams. Only those aspects of a model that are of current interest need be shown on an object diagram. |
|
|
| An object diagram may be considered a special case of a class diagram. Object diagrams use a subset of the elements of a class diagram in order to emphasize the relationship between instances of classes at some point in time. They are useful in understanding class diagrams. They don’t show anything architecturally different to class diagrams, but reflect multiplicity and roles. |
|
| Although we design and define classes, in a live application classes are not directly used, but instances or objects of these classes are used for executing the business logic. A pictorial representation of the relationships between these instantiated classes at any point of time (called objects) is called an "Object diagram". It looks very similar to a class diagram, and uses the similar notations to denote relationships. |
|
| If an object diagram and a class diagram look so similar, what is an object diagram actually used for? Well, if you looked at a class diagram, you would not get the picture of how these classes interact with each other at runtime, and in the actual system, how the objects created at runtime are related to the classes. An object diagram shows this relation between the instantiated classes and the defined class, and the relation between these objects, in the logical view of the system. These are very useful to explain smaller portions of your system, when your system class diagram is very complex, and also sometimes recursive. |
|
|
| Class and Object Elements |
|
| The following diagram shows the differences in appearance between a class element and an object element. Note that the class element consists of three parts, being divided intoname, attribute and operation compartments; by default, object elements don’t have compartments. The display of names is also different: object names are underlined and may show the name of the classifier from which the object is instantiated. |
|
|
|
|
|
| Run Time State |
|
| A classifier element can have any number of attributes and operations. These aren’t shown in an object instance. It is possible, however, to define an object’s run time state, showing the set values of attributes in the particular instance. |
|
|
|
|
|
| Example Class and Object Diagrams |
|
| The following diagram shows an object diagram with its defining class diagram inset, and it illustrates the way in which an object diagram may be used to test the multiplicities of assignments in class diagrams. The car class has a 1-to-many multiplicity to the wheel class, but if a 1-to-4 multiplicity had been chosen instead, that wouldn’t have allwed for the three-wheeled car shown in the object diagram. |
|
|
|
|
|
|
|
| Structural Modeling Diagrams |
|
| Composite Structure diagrams |
|
| A Unified Modeling Language (UML) composite structure diagram shows the internal structure of a class and the collaborations that this structure makes possible. This can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration. |
|
|
| Part |
|
| A part is an element that represents a set of one or more instances which are owned by acontaining classifier instance. So for example, if a diagram instance owned a set ofgraphical elements, then the graphical elements could be represented as parts; if it were useful to do so, to model some kind of relationship between them. Note that a part can be removed from its parent before the parent is deleted, so that the part isn't deleted at the same time. |
|
|
|
|
|
|
| Port |
|
| A port is a typed element that represents an externally visible part of a containing classifier instance. Ports define the interaction between a classifier and its environment. A port can appear on the boundary of a contained part, a class or a composite structure. A port may specify the services a classifier provides as well as the services that it requires of its environment. |
|
|
|
|
|
| Interfaces |
|
| An interface is similar to a class but with a number of restrictions. All interface operations are public and abstract, and do not provide any default implementation. All interface attributes must be constants. However, while a class may only inherit from a single super-class, it may implement multiple interfaces. |
|
|
| Delegate |
|
| A delegate connector is used for defining the internal workings of a component's external ports and interfaces. A delegate connector is shown as an arrow with a «delegate»keyword. It connects an external contract of a component as shown by its ports to the internal realization of the behavior of the component's part. |
|
|
|
|
|
| Collaboration |
|
| A collaboration defines a set of co-operating roles used collectively to illustrate a specific functionality. A collaboration should only show the roles and attributes required to accomplish its defined task or function. Isolating the primary roles is an exercise in simplifying the structure and clarifying the behavior, and also provides for re-use. A collaboration often implements a pattern. |
|
| A collaboration element is shown as an ellipse. |
|
|
|
|
|
|
|
| Structural Modeling Diagrams |
|
| Component diagrams |
|
| In the Unified Modeling Language, a component diagram depicts how a software system is split up into physical components and shows the dependencies among these components. Physical components could be, for example, files, headers, link libraries, modules,executables, or packages. Component diagrams can be used to model and document any system’s architecture. |
|
|
| Note that components are types and only executable components may have instances. |
|
|
|
|
|
|
| Components are similar in practice to package diagrams, as they define boundaries and are used to group elements into logical structures. The difference between package diagrams and component diagrams is that Component Diagrams offer a more semantically rich grouping mechanism. With component diagrams all of the model elements are private, whereas package diagrams only display public items. |
|
|
| Representing Components |
|
| Components are represented as a rectangular classifier with the keyword «component»; optionally the component may be displayed as a rectangle with a component icon in theright-hand upper corner. |
|
|
|
|
|
| Assembly Connector |
|
| The assembly connector bridges a component’s required interface (Component1) with the provided interface of another component (Component2); this allows one component to provide the services that another component requires. |
|
|
|
|
|
|
|
| Structural Modeling Diagrams |
|
| Implementation Diagram |
|
| In the Unified Modeling Language, a deployment diagram serves to model the hardware used in system implementations, the components deployed on the hardware, and the associations between those components. The elements used in deployment diagrams arenodes (shown as a cube), components (shown as a rectangular box, with two rectangles protruding from the left side) and associations. |
|
| In UML 2.0 components are not placed in nodes. Instead artifacts and nodes are placed in nodes. An artifact is something like a file, program, library, or data base constructed or modified in a project. These artifacts implement collections of components. The inner nodes indicate execution environments rather than hardware. |
|
|
| A deployment diagram models the run-time architecture of a system. It shows the configuration of the hardware elements (nodes) and shows how software elements and artifacts are mapped onto those nodes. |
|
|
| Node |
|
| A Node is either a hardware or software element. It is shown as a three-dimensional box shape, as shown below: |
|
|
|
|
|
|
| Node Instance |
|
| A node instance can be shown on a diagram. An instance can be distinguished from a node by the fact that its name is underlined and has a colon before its base node type. An instance may or may not have a name before the colon. The following diagram shows anamed instance of a computer. |
|
|
|
|
|
| Node Stereotypes |
|
| A number of standard stereotypes are provided for nodes, namely «cdrom», «cd-rom»,«computer», «disk array», «pc», «pc client», «pc server», «secure», «server»,«storage», «Linux Web server», «user pc». These will display an appropriate icon in the top right corner of the node symbol. |
|
|
|
|
|
| Association |
|
| In the context of a deployment diagram, an association represents a communication pathbetween nodes. The following diagram shows a deployment diagram for a network, depicting network protocols as stereotypes, and multiplicities at the association ends. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
0 comments: